Session 과 Cookie

JWT라는 '현대식 신분증'을 보셨으니, 이제 그 전설의 시작이자 지금도 여전히 강력하게 쓰이는 전통의 강자, Session(세션)과 Cookie(쿠키)를 정복할 차례입니다.

이 둘은 바늘과 실 같은 존재예요. 하나씩 뜯어볼게요!

---

1. Cookie (쿠키): "사용자 주머니에 넣어둔 메모지"

쿠키는 서버가 사용자의 브라우저(크롬, 사파리 등)에 저장해두는 아주 작은 데이터 조각입니다.

• 특징: 서버가 "이거 나중에 다시 올 때 보여줘"라며 사용자 주머니(브라우저)에 넣어주는 메모지라고 생각하면 됩니다.
• 작동: 브라우저는 동일한 서버에 요청을 보낼 때마다 주머니 속 쿠키를 자동으로 꺼내서 서버에 같이 전달합니다.
• 용도: "오늘 이 창 다시 보지 않기", "장바구니 담아둔 상품 기억하기", "로그인 상태 유지" 등.

2. Session (세션): "서버 금고에 보관된 장부"

세션은 사용자의 정보를 브라우저가 아니라 서버 쪽 메모리나 DB에 직접 저장하는 방식입니다.

• 특징: 중요한 정보는 서버 금고(세션 저장소)에 보관하고, 사용자에게는 그 금고를 열 수 있는 '열쇠 번호(Session ID)'만 쿠키로 전달합니다.
• 보안성: 쿠키에는 아무런 개인정보가 없고 의미 없는 문자열(열쇠 번호)만 들어있기 때문에, 쿠키만 털려서는 사용자가 누구인지 알기 어렵습니다.

---

3. 세션과 쿠키의 합작 과정 (로그인 흐름)

1. 로그인: XX님이 ID/PW를 보냅니다.
2. 세션 생성: 서버가 "오, XX님 맞네!" 하고 서버 메모리에 XX님 전용 공간(세션)을 만들고 정보를 기록합니다.
3. 열쇠 발급: 그 공간의 번호인 Session ID: ABC123을 발행합니다.
4. 쿠키 전달: 서버는 브라우저에게 "이 ABC123 번호를 쿠키에 저장해둬"라고 보냅니다.
5. 재방문: XX님이 다음 페이지로 이동할 때, 브라우저가 자동으로 쿠키(ABC123)를 서버에 보냅니다.
6. 확인: 서버는 자기 장부에서 ABC123이 누구 건지 찾아보고 "아, XX님이네!" 하고 서비스를 제공합니다.

---

📊 JWT vs Session/Cookie (아키텍트의 선택)

이게 제일 중요합니다. 왜 요즘은 세션보다 JWT를 많이 쓸까요?

구분	Session / Cookie	JWT (Token)
저장 위치	서버 메모리/DB (중앙 관리)	사용자 브라우저 (분산 관리)
서버 부담	사용자가 많아지면 서버 메모리가 터짐	서버는 검증만 하면 끝 (부담 없음)
확장성	서버를 여러 대 늘리면 세션 공유가 힘듦	어떤 서버로 가든 토큰만 있으면 오케이!
제어권	서버가 강제로 로그아웃 시킬 수 있음	발급 후에는 제어가 힘듦 (만료 대기)

---

🏠 비유로 한눈에 정리

• Session/Cookie 방식: 놀이공원 '시즌권'과 같습니다. 매표소(서버) 장부에 내 사진과 정보가 있고, 나는 '회원번호'가 적힌 이름표만 들고 다닙니다. 입장할 때마다 매표소 직원이 장부를 확인해야 합니다.
• JWT 방식: 놀이공원 '자유이용권 팔찌'와 같습니다. 팔찌 안에 "이 사람은 VIP고, 언제까지 이용 가능함"이라는 정보와 '위조 방지 도장(서명)'이 찍혀 있습니다. 직원은 장부를 볼 필요 없이 팔찌의 도장만 확인하면 바로 통과시켜 줍니다.

---

🔗 다음 공부의 연결고리

이제 인증의 두 산맥을 다 넘으셨어요! 그런데 말이죠...

"우리가 직접 ID/PW를 안 만들고, 구글이나 카카오 아이디로 로그인하는 건 대체 어떤 원리야? 걔네도 세션이나 JWT를 쓰나?"

이 질문에 대한 답이 바로 다음 단계인 [OAuth 2.0]입니다. 남의 집 열쇠를 안전하게 빌려 쓰는 기술이죠.

세션과 쿠키의 역할 분담이 확실히 이해되셨나요? 이해되셨다면 이제 '로그인의 끝판왕' [OAuth 2.0]으로 가보겠습니다!