** 📌 PART 4.1 세션(Session) 객체의 메모리 문제와 클러스터링 전략 **

“로그인 상태를 유지하면서도 서버 메모리를 안전하게 쓰는 법”

---

🟢 1단계. 세션(Session)이 뭐야?

💬 세션이란 사용자가 웹사이트에 들어왔을 때,

서버가 그 사용자를 기억하기 위해 만들어주는 저장 공간이야.

---

✅ 예시로 쉽게 설명:

• 홍길동이 로그인했어 → 서버는 “홍길동 로그인 정보”를 메모리에 저장
• 홍길동이 다음 페이지로 이동해도 → 로그인 상태를 기억하고 있어!
• 이 저장공간이 바로 👉 세션(Session)

---

✅ 코드 예시

HttpSession session = request.getSession();
session.setAttribute("loginId", "hong123");

→ 사용자의 로그인 정보를 세션에 저장하는 코드

---

🧠 세션은 서버 메모리에 저장됨!

항목	설명
저장 위치	WAS (Tomcat 등) 메모리
관리 대상	사용자별 데이터 (로그인, 장바구니 등)
삭제 시점	브라우저 종료 or 시간 초과 or session.invalidate()

---

🔥 2단계. 세션의 메모리 문제 (실제 실무 이슈)

❗ 문제 상황: 세션이 너무 많으면?

• 사용자가 많아지면 → 사용자 수만큼 세션 객체도 메모리에 생성됨

• 로그인만 해놓고 사이트 안 닫는 사람 많음

  → 세션이 계속 살아 있음 → 메모리 계속 차지함

• 심하면 서버가 느려지거나 다운됨 😱

---

📦 세션 메모리 흐름

[사용자 접속] → Session 객체 생성
→ setAttribute("loginId", "hong123");
→ 서버 메모리에 로그인 정보 저장됨
→ 아무 행동 없이 30분 지남 → 세션 삭제 (GC 대상)

---

✅ 세션 유지 시간 (Session Timeout)

항목	설명
기본 시간	30분 (서버 설정에 따라 다름)
설정 방법	web.xml 또는 코드에서 설정 가능
설정 예시

<!-- web.xml -->
<session-config>
    <session-timeout>15</session-timeout> <!-- 분 단위 -->
</session-config>

---

✅ 세션 메모리 누수 방지 전략

전략	설명
자동 만료 시간 설정	10~30분 추천
수동 종료	session.invalidate() 로 직접 종료
세션 최소화	큰 데이터를 세션에 넣지 않기 (이미지, 목록 등은 DB에 보관)
전역 캐시 대신 로컬 세션 사용	서버에 불필요한 공용 객체 보관 금지

---

✅ 실무에서 많이 터지는 실수

session.setAttribute("productList", hugeList); // ❌ 메모리 터질 수도 있음

→ 대량 객체는 DB나 캐시에 저장하고, 세션에는 ID만 저장하세요!

---

🌐 3단계. 대규모 사용자 대비: 세션 클러스터링 전략

---

🧩 왜 클러스터링이 필요해?

💬 웹사이트에 접속한 사용자가 10만 명이라면…?

서버 하나로는 감당 불가! 그래서 여러 대의 서버를 묶어서 처리하는데,

이때 서버끼리 세션을 공유해야 로그인 정보가 유지됨.

---

✅ 세션 클러스터링 구조

[사용자 로그인]
→ 서버 A에 접속 → 세션 생성

[다음 요청은 서버 B로 갔을 때]
→ B도 로그인 상태를 알아야 함!

→ A와 B가 세션 정보를 공유해야 함 → 이것이 "세션 클러스터링"

---

✅ 대표적인 세션 클러스터링 방식

방식	설명	특징
Sticky Session	한 사용자는 무조건 같은 서버로 유지	구현 쉬움, 부하 불균형 발생
Session Replication	모든 서버가 세션을 복제해 공유	신뢰도 높음, 네트워크 부하 ↑
External Session Storage	Redis, DB 등 외부 저장소에 세션 저장	성능/확장성 우수, 가장 추천

---

☁️ 클라우드/대기업에서 쓰는 방식

대부분 Redis + Spring Session 구조 사용

→ 서버 수십 대로 확장해도 세션 공유 OK

→ GC 부담도 줄고, 확장성 최고!

---

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

질문	모범 답변 요약
세션은 어디에 저장되나요?	WAS 서버 메모리에 저장됩니다
세션이 많아지면 어떤 문제가 생기나요?	메모리 부족, GC 부담, 서버 느려짐
세션 타임아웃은 어떻게 설정하나요?	web.xml 또는 session.setMaxInactiveInterval()
대규모 시스템에서 세션 공유는 어떻게 하나요?	세션 클러스터링 (Replication, External Store)
세션을 GC로 정리하려면 어떻게 해야 하나요?	타임아웃 또는 invalidate() 호출, 참조 제거 필수

---

✅ 마무리 요약표

항목	설명	메모리 영향
Session	사용자별 데이터 저장소	사용자 수 많으면 메모리 폭증
Timeout 설정	자동 삭제 가능	설정이 짧을수록 안전
클러스터링	서버 간 세션 공유	확장성 ↑, 복잡도 ↑
External 저장소	Redis, DB로 세션 이동	메모리 ↓, 속도 ↑

✅ PART 4.2 응답 캐시(Cache-Control)와 서버 메모리 절약

“브라우저와 서버가 똑똑하게 캐시를 써서 빠르게 보여주는 법 + 메모리도 아끼기”

---

🟢 1단계. 캐시(Cache)란 뭐야?

💬 캐시란 자주 쓰는 데이터를 미리 저장해두는 저장소야.

웹에서는 “브라우저” 또는 “프록시 서버”가

이전 결과를 저장해두고, 똑같은 요청이 오면 새로 안 불러오는 기술이야!

---

✅ 예시

[처음 요청]
→ 서버에서 이미지 전송 (logo.png)

[다음 요청]
→ 브라우저가 "어? 전에 받은 거랑 같네!" → 저장된 걸 그대로 씀!

→ 서버에 다시 요청 X → 속도 ↑, 트래픽 ↓

---

🧠 캐시가 중요한 이유

항목	효과
속도 ↑	서버 재요청 없이 빠르게 보여줌
트래픽 ↓	서버 리소스 절약
메모리 관리 ↑	서버에서 동일한 데이터를 여러 번 생성하지 않음

---

📦 2단계. HTTP 캐시 헤더 + GC와의 관계

---

✅ 핵심 캐시 헤더

헤더	설명
Cache-Control	어떻게 캐시할지 설정
Expires	언제까지 캐시 유효한지
ETag	파일이 바뀌었는지 확인하는 ID
Last-Modified	마지막 수정 시간 (비교용)

---

✅ 예시: 캐시를 1시간 유지하는 헤더

Cache-Control: public, max-age=3600

→ 3600초(1시간) 동안 브라우저가 새로 요청하지 않고, 저장된 파일을 그대로 씀

---

🔍 서버 메모리(GC) 관점에서 왜 좋을까?

항목	설명
정적 파일 캐시	서버가 매번 파일 읽을 필요 없음 → 메모리/CPU 부담 ↓
동적 페이지 캐시	동일한 데이터 렌더링 결과를 재사용 → GC 대상 객체 생성 ↓
GC 효율	매 요청마다 새로 객체 생성 안 하므로 GC 발생 횟수 ↓

---

⚙️ 3단계. 정적 리소스 vs 동적 페이지 캐시 전략

---

✅ 정적 리소스 (이미지, CSS, JS 등)

항목	특징
바뀌지 않음	자주 안 바뀜 (logo.png, app.css 등)
캐시 전략	오래 저장해도 안전 (max-age=31536000 등)
GC 영향	캐시 서버 or 브라우저에 있음 → 서버는 메모리 사용 안 함

💡 설정 예시 (Apache / Nginx)

Cache-Control: public, max-age=31536000

→ 1년 동안 다시 안 받아도 됨!

---

✅ 동적 페이지 (JSP, 로그인 화면, 검색 결과 등)

항목	특징
요청마다 결과가 다를 수 있음	사용자 상태나 DB에 따라 다름
캐시 전략	안 하거나 짧게 설정
GC 영향	매 요청마다 객체 생성 → GC 자주 발생

💡 캐시 금지 설정

Cache-Control: no-store
Pragma: no-cache
Expires: 0

→ 민감 정보(로그인, 주문, 결제 등)는 절대 캐시하면 안 됨!

---

🧠 실무 전략 요약

리소스 유형	캐시 전략
이미지, JS, CSS	오래 캐시 (max-age)
API 응답	ETag, Last-Modified 활용
로그인/장바구니	no-cache, no-store 설정
검색 결과	짧은 캐시 or 사용자별 Key 캐시 (예: Redis)

---

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

질문	모범 답변 요약
HTTP 캐시는 왜 필요한가요?	속도 ↑, 트래픽 ↓, 서버 메모리 사용 ↓
GC와 캐시는 어떤 관계가 있나요?	캐시를 쓰면 객체 생성 줄어들어 GC 횟수도 ↓
정적 리소스는 왜 오래 캐시하나요?	바뀌지 않기 때문에 다시 받을 필요 없음
동적 페이지는 왜 캐시하면 안 되나요?	사용자마다 결과가 다르기 때문에 보안 위험 있음
ETag는 뭔가요?	리소스 변경 여부 확인용 고유 ID (변경 시 새 요청 허용)

---

✅ 마무리 요약표

항목	설명	메모리 효과
Cache-Control	캐시 여부/시간을 지정하는 HTTP 헤더	재요청 방지로 메모리 ↓
정적 리소스	캐시 적극 사용 (max-age)	서버 요청 감소, GC 줄어듦
동적 페이지	민감 정보는 no-store 설정	보안 강화, GC 유도 가능
GC 관점	캐시로 인해 생성되는 객체 ↓	Full GC 횟수 감소

✅ PART 4.3 보안 + 메모리 관점: XSS/CSRF vs 필터 처리 구조

---

🟢 1단계. 필터(Filter)란 뭐야? 중학생도 이해하는 핵심 개념

💬 필터(Filter)는 웹 요청(Request)과 응답(Response) 사이에서

중간에 끼어들어서 검사하거나 가공하는 자바 코드야.

---

📦 비유

[사용자 요청] → (🛡️ 필터 검사) → 컨트롤러 실행 → (🛡️ 필터 마무리 처리) → 응답

예를 들어:

• 누군가 로그인도 안 하고 글쓰기 페이지 들어오려고 해 → 🚫 필터에서 차단!
• 누가 이상한 스크립트(XSS) 넣으려고 해 → ✂️ 필터에서 제거!

---

✅ 필터 동작 구조

public class MyFilter implements Filter {
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
        // 💡 요청 가로채기
        System.out.println("요청 전 처리");

        chain.doFilter(request, response); // 📌 다음 단계로 전달

        // 💡 응답 가로채기
        System.out.println("응답 후 처리");
    }
}

---

🧠 2단계. 필터 체인(Filter Chain)의 메모리 흐름

✅ FilterChain이란?

여러 개의 필터가 순서대로 실행되게 해주는 필터 연결 고리

---

🔁 예시 흐름 (3개 필터가 있을 때)

[사용자 요청]
 → AuthFilter
   → XSSFilter
     → EncodingFilter
       → Controller 실행
     ← 응답 처리
   ← 응답 처리
 ← 응답 처리

---

🧠 메모리 흐름 설명

항목	설명
필터 객체	서버 시작 시 1번만 생성 (싱글톤)
Request/Response 객체	요청마다 생성 (매 요청마다 새 객체)
필터 체인 실행 시	각 필터가 request/response 객체를 참조하거나 감싸서 전달

→ 요청이 많아지면 필터가 계속 request를 조작하므로 메모리 사용량 증가 가능

---

🔐 3단계. XSS/CSRF 보안 필터 구현 구조

---

✅ XSS (Cross Site Scripting)란?

💥 사용자가 입력한 값에

다른 사용자의 브라우저에서 실행되게 하는 공격

예시 공격 코드:

<input value="<script>alert('해킹!')</script>">

---

✅ 방어 방법: 입력값에서 <, >, " 등을 필터로 차단

public class XSSFilter implements Filter {
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
        // ✅ 감싼 request 객체를 전달
        chain.doFilter(new XSSRequestWrapper((HttpServletRequest)request), response);
    }
}

---

✅ XSSRequestWrapper 예시

public class XSSRequestWrapper extends HttpServletRequestWrapper {
    public XSSRequestWrapper(HttpServletRequest request) {
        super(request);
    }

    @Override
    public String getParameter(String name) {
        String value = super.getParameter(name);
        return sanitize(value);
    }

    private String sanitize(String input) {
        return input.replaceAll("<", "&lt;").replaceAll(">", "&gt;");
    }
}

---

✅ 메모리 측면 핵심

항목	설명
Wrapper 객체	요청마다 새로 생성됨 (XSSRequestWrapper)
메모리 증가	요청 수가 많을수록 Wrapper 객체도 많아짐
GC 영향	응답 후 GC 대상이 되지만, 응답 중 오류 발생 시 누수 가능성 존재

---

✅ CSRF (Cross Site Request Forgery)란?

💥 사용자가 모르게 다른 사이트에서 위조된 요청을 보냄

예: 로그인 상태에서 공격자가 자동 요청을 보내 데이터 삭제

---

✅ 방어 방법: CSRF 토큰을 발급하고, 요청 시 검증

String token = UUID.randomUUID().toString();
session.setAttribute("CSRF_TOKEN", token);

• 요청할 때 <input type="hidden" name="csrf_token" value="...">
• 서버 필터에서 토큰 비교해서 맞으면 통과, 아니면 차단

---

🧠 필터에서 보안 검사 시 주의할 메모리 포인트

항목	설명
XSS 필터	매 요청마다 request 래퍼 객체 생성 → GC 부담 주의
CSRF 필터	세션에 토큰 저장 → 세션 메모리 낭비 방지 필수
다단계 필터 구조	FilterChain이 깊을수록 응답 속도/메모리 소비↑

---

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

질문	모범 답변 포인트
필터는 메모리적으로 어떤 구조인가요?	필터 자체는 싱글톤, request/response는 요청마다 새로 생성됨
XSS 필터는 어떻게 동작하나요?	request를 감싸는 Wrapper 객체를 만들어 input 값을 정리함
필터 체인은 어떻게 작동하나요?	여러 필터가 순서대로 연결되어 하나씩 요청을 처리하고 넘김
필터가 많아지면 어떤 문제가 생기나요?	처리 시간 증가 + 요청 객체가 계속 감싸지므로 메모리 부하↑
보안 필터를 만들 때 주의할 점은?	쓰레드 세이프하게 설계하고, Wrapper 객체 생명주기 고려

---

✅ 마무리 요약표

항목	설명	메모리 영향
Filter	요청 전/후에 실행되는 검사기	객체 감싸기 많아지면 메모리 사용 ↑
FilterChain	순차 연결 구조	필터 많을수록 스택 깊이 ↑
XSS Wrapper	요청마다 생성	정리 안 하면 누수 가능
CSRF 토큰	세션에 저장	유효 시간 제한 설정 필수