** 📌 PART 8.1 Memory Safe MVC 구조로 개선하기 **

“메모리도 안전하고, 유지보수도 쉬운 구조로 코드를 정리해보자!”

---

🔧 핵심 목표:

• 동시 사용자 수가 늘어나도 안전한 구조
• GC가 잘 정리할 수 있도록 객체 수명 조절
• 재사용 가능한 객체는 효율적으로 공유

---

🟢 1단계. MVC2 구조에서 메모리 위험 지점은 어디?

📦 기본 구조

[Client] → Controller → Service → DAO → DB
                       ↓
                    View(JSP)

---

❗ 메모리 위험 포인트

레이어	잘못된 사용	문제점
Controller	매 요청마다 객체 생성	GC 대상 많아짐
Service	상태 있는 객체 공유	Thread-safe 문제 발생 가능
DAO	DB 연결을 직접 관리	Connection 누수, 메모리 과다 사용

---

✅ 리팩토링 전략 1: Controller / Service / DAO 메모리 안전 설계

---

✅ [1] Controller: 상태 없는 싱글톤 + 메소드 단위 처리

@WebServlet("/member/list")
public class MemberController extends HttpServlet {
    private MemberService service = new MemberService(); // ✅ 상태 없음!

    protected void doGet(HttpServletRequest req, HttpServletResponse res) {
        List<Member> list = service.getAll();
        req.setAttribute("list", list);
        req.getRequestDispatcher("memberList.jsp").forward(req, res);
    }
}

💡 핵심

• Controller는 싱글 인스턴스로 유지됨 (서버 시작 시 1회 생성)
• 인스턴스 변수에 사용자별 데이터를 저장하지 않는다!

---

✅ [2] Service: 상태 없는 객체, 요청마다 동작만 수행

public class MemberService {
    private MemberDao dao = MemberDao.getInstance(); // ✅ DAO는 싱글톤

    public List<Member> getAll() {
        return dao.selectAll();
    }
}

💡 핵심

• Service는 상태를 저장하지 않음
• 데이터는 메서드 매개변수/리턴값으로만 전달 → GC 수거 쉬움

---

✅ [3] DAO: 싱글톤 + 커넥션 풀 사용 + 상태 없음

public class MemberDao {
    private static final MemberDao instance = new MemberDao();
    private MemberDao() {} // 생성자 private
    public static MemberDao getInstance() {
        return instance;
    }

    public List<Member> selectAll() {
        try (Connection conn = DBConnection.getConnection();
             PreparedStatement pstmt = conn.prepareStatement("SELECT * FROM member")) {
            ...
        }
    }
}

💡 핵심

• DAO는 싱글톤으로 한 번만 생성됨 → 메모리 효율 ↑
• DB 연결은 항상 try-with-resources로 자동 정리

---

✅ 리팩토링 전략 2: ServletContextListener로 자원 로딩 최적화

---

❓ ServletContextListener란?

💬 톰캣 서버가 시작하거나 종료될 때,

공통 자원(DB, 설정값, DAO 등) 을 미리 로딩하거나 정리할 수 있게 해주는 기능

---

✅ 구조

@WebListener
public class AppInitListener implements ServletContextListener {

    @Override
    public void contextInitialized(ServletContextEvent sce) {
        System.out.println("✅ 서버 시작: 공통 자원 로딩 중...");
        ServletContext ctx = sce.getServletContext();
        ctx.setAttribute("appName", "JSP포털");
    }

    @Override
    public void contextDestroyed(ServletContextEvent sce) {
        System.out.println("🧹 서버 종료: 자원 정리 중...");
    }
}

---

📦 활용 예시

• DAO 공용 설정값 로딩
• 공용 HTML경로, 업로드 폴더 경로 설정
• DB 커넥션 풀 초기화
• 로깅 설정

---

✅ 메모리 최적화 포인트

전략	설명
서버 시작 시 공용 객체 1번만 생성	매 요청마다 새로 만들지 않아 메모리 절약
필요 없을 땐 context.removeAttribute()	수명 조절 가능 (GC 대상 유도)
서버 종료 시 연결 해제 (contextDestroyed)	파일 핸들, 로그 등 자원 누수 방지 가능

---

🎓 면접 포인트 정리

질문	모범 답변
Controller는 왜 상태를 가지면 안 되나요?	모든 사용자가 같은 인스턴스를 공유하므로, 인스턴스 변수에 사용자 데이터를 저장하면 충돌 발생합니다
DAO는 왜 싱글톤으로 설계하나요?	재사용 가능한 객체이며, DB 연결을 효율적으로 관리하기 위함입니다
ServletContextListener는 왜 쓰나요?	서버 시작/종료 시점에 필요한 자원(DB, 설정 등)을 로딩하고, 메모리를 절약하기 위해서입니다
GC가 Controller 구조에 영향을 미치나요?	상태가 있는 Controller는 메모리 누수 가능성이 크기 때문에 상태 없는 구조가 GC에 유리합니다

---

✅ 마무리 요약표

항목	개선 전략	메모리 효과
Controller	상태 없는 구조	Thread-safe, GC 수거 쉬움
Service	Stateless 구조	재사용 가능, 메모리 누수 없음
DAO	싱글톤 + 커넥션풀 + try-with-resources	리소스 안정성 최고
ServletContextListener	서버 시작 시 자원 1회 로딩	메모리 낭비 ↓, 초기화 비용 ↓

✅ PART 8.2 Spring MVC vs JSP 모델2 구조 비교 + 한계

“왜 JSP Model2에서 Spring MVC로 넘어가야 할까?”

---

🟢 1단계. 기본 개념부터 시작 – Model2란?

💬 JSP Model2는 “서블릿이 컨트롤러 역할”을 하고,

JSP는 뷰(view) 역할만 맡는 구조야.

[사용자 요청] → Controller(Servlet) → Service → DAO → JSP(View)

📌 이 구조만으로도 MVC 패턴은 되지만, Spring처럼 자동화, 설정 주입은 없음!

---

🔁 Spring MVC는 어떻게 다를까?

---

✅ Spring MVC 구조 (IoC + DI + AOP)

[DispatcherServlet] → [Controller] → [Service] → [DAO]
                     ↘               ↗
                      [IoC Container] (객체 자동 관리)

• DispatcherServlet: 요청을 받고 라우팅
• IoC Container: 필요한 객체를 자동으로 만들어서 넣어줌 (DI)
• AOP: 로그, 트랜잭션 처리 등을 핵심 코드 바깥에서 처리

---

⚙️ 2단계. Spring의 IoC / DI / AOP 구조가 메모리에 미치는 긍정적 영향

---

✅ IoC (제어의 역전)란?

객체를 직접 만들지 않고, Spring이 대신 만들어주는 방식

// Model2 방식
MemberService service = new MemberService();  // 직접 new ❌

// Spring 방식
@Autowired
MemberService service;  // ✨ 자동 주입 (DI)

---

✅ DI (의존성 주입)으로 얻는 이점

항목	설명	메모리 효과
재사용성 ↑	하나 만든 객체를 여러 클래스에 주입	중복 객체 생성 ↓
테스트 쉬움	Mock 객체도 쉽게 주입 가능	유지보수 비용 ↓
GC 유리	객체 생명주기를 IoC가 관리 → 필요 없으면 GC로 자연 정리됨 ✅

---

✅ AOP (관점 지향 프로그래밍)

로그 출력, 트랜잭션, 보안 처리 같은 걸 비즈니스 로직 바깥에서 자동 처리

// AOP 미사용 시
log.info("시작");
memberService.register(member);
log.info("종료");

// AOP 사용 시
@Loggable
public void register(Member member) {
    ...
}

🧠 핵심:

• 코드 중복 제거 → 코드량 ↓
• 객체 처리 단순화 → 메모리 할당 ↓
• 필요 없는 로직을 조건부로 분리 가능

---

🚫 3단계. JSP Model2 구조에서 DI 불가능한 병목 지점

---

❗ 문제 1: 직접 new 생성

public class BoardController extends HttpServlet {
    private BoardService service = new BoardService(); // ❌ 항상 new
}

문제점	설명
객체 재사용 불가	요청마다 새로운 객체를 생성하면 GC 부담 ↑
테스트 어려움	다른 객체를 넣을 수 없음 (Mock 불가)
순환 의존 방지 불가	의존성 관계가 꼬이면 해결 어려움

---

❗ 문제 2: 상태 있는 Controller 설계 위험

@WebServlet("/board/write")
public class WriteController extends HttpServlet {
    private List<String> tempList = new ArrayList<>(); // ❌ 공유됨
}

• 모든 사용자에게 공유되는 인스턴스 변수 → Thread-safe X
• 메모리 누수 + 데이터 충돌 위험

---

❗ 문제 3: 공통 처리(AOP 불가)

기능	JSP Model2에서 불편한 이유
로그인 체크	컨트롤러마다 코드 삽입해야 함
트랜잭션 처리	모든 DAO에 try-catch 반복
로깅	중복 코드 발생, 성능 저하

→ Spring에서는 AOP로 한 번에 처리 가능 → 성능 + 메모리 최적화

---

🎓 4단계. 면접 포인트 정리

질문	모범 답변 요약
JSP Model2에서 DI가 어렵다는 건 무슨 뜻인가요?	객체를 new로 직접 만들기 때문에 IoC 컨테이너가 없어서 의존성 주입이 불가능합니다
Spring이 메모리적으로 더 유리한 이유는?	IoC 컨테이너가 객체를 하나만 생성해 공유하고, 불필요한 객체 생성을 줄여 GC 효율이 높습니다
JSP Model2는 어떤 구조적 한계가 있나요?	코드 재사용성 부족, 테스트 어려움, 공통 처리 어려움, GC 부담 증가 등이 있습니다
AOP가 왜 성능에 좋은가요?	로그, 보안, 트랜잭션 같은 비핵심 로직을 분리해 코드량과 메모리 부담을 줄여줍니다

---

✅ 마무리 요약표

항목	JSP Model2	Spring MVC
객체 생성	직접 new	IoC가 자동 생성
DI(의존성 주입)	불가	자동 주입 (@Autowired)
AOP 적용	수동, 복잡	간단히 적용 (로그, 보안, 트랜잭션 분리)
메모리 관리	직접 관리 → 누수 위험	Spring이 생명주기 자동 관리 → GC 효율 ↑
테스트 용이성	낮음	높음 (Mock 주입 가능)