쿠키 · 세션

쿠키란?

쿠키와 세션이 실제로 바꾸는 것은 '사용자를 기억한다'는 기능이 아니라, 그 기억을 어디에 둘 것인가라는 설계 결정입니다. 정보를 브라우저에 들려 보내면 서버는 가벼워지지만 그 내용은 사용자가 열어보고 고칠 수 있고, 서버가 들고 있으면 안전한 대신 동시 접속자 수만큼 저장 공간과 만료 관리가 따라붙습니다. 로그인 유지 기능 하나가 보안·서버 비용·인프라 구조를 한꺼번에 건드리는 이유가 여기 있습니다.

쿠키는 몇 가지로 갈립니다. 브라우저를 닫으면 사라지는 세션 쿠키와, 만료일(Max-Age)을 박아 몇 주씩 남는 영속 쿠키가 다르고, 내가 접속한 사이트가 심는 퍼스트파티 쿠키와 광고사가 심는 서드파티 쿠키는 성격이 완전히 다릅니다. 용량도 하나당 4KB 안팎이라 데이터를 통째로 담는 용도가 아닙니다. 대신 HttpOnly(자바스크립트 접근 차단)·Secure(HTTPS에서만 전송)·SameSite(타 사이트 요청 시 전송 제한) 같은 속성을 어떻게 걸어두느냐가 실질적인 보안선입니다.

세션도 보관 방식이 나뉩니다. 서버 메모리에 두는 전통적 방식, Redis 같은 공용 저장소에 모아 두는 방식, 그리고 아예 서명된 토큰(JWT)에 상태를 담아 서버가 저장하지 않는 방식이 있습니다. 서버를 여러 대로 늘리는 순간 이 선택이 장애로 드러납니다. 토큰 방식은 확장은 쉽지만 발급된 토큰을 즉시 무효화하기 어렵다는 대가가 있어, 퇴사자 계정 차단 같은 요구가 있으면 별도 장치가 필요합니다.

현장에서 가장 흔한 오해는 '쿠키 동의 배너를 띄우면 개인정보 처리는 끝'이라는 생각입니다. 로그인 유지에 쓰는 필수 쿠키와 광고 추적 쿠키를 한 덩어리로 묶어 '전체 동의'만 받아두면, 거부한 이용자에게도 추적 스크립트가 그대로 돌아 동의 없는 수집이라는 지적을 받습니다. 반대로 서드파티 쿠키 폐지 소식에 놀라 자사 로그인까지 걱정하는 경우도 많은데, 그건 남의 도메인 쿠키 이야기입니다. 또 하나, '로그인 30일 유지'를 편의로 켜두고 HttpOnly를 빼먹으면 스크립트 한 줄로 세션 쿠키가 통째로 털리는 사고로 이어집니다.