쿠키와 세션, 토큰: 웹사이트가 사용자를 ‘기억’하는 기술

웹사이트는 왜 로그인 상태를 “기억”할 수 있는가

쇼핑몰에서 로그인한 뒤 페이지를 이동해도 계속 로그인 상태가 유지되고, 장바구니에 담아둔 상품이 사라지지 않는 경우가 많다. 인터넷 뱅킹이나 회사 업무 사이트에서도 일정 시간 동안은 다시 비밀번호를 입력하지 않아도 된다. 사용자는 이를 당연하게 느끼지만, 전산학 관점에서는 중요한 질문이 남는다. 웹(HTTP)은 원래 연결을 유지하지 않는 구조인데, 웹사이트는 어떻게 사용자를 “기억”하는가.
이 글은 웹사이트가 사용자를 기억하는 핵심 기술인 쿠키(cookie), 세션(session), 토큰(token)을 중심으로 설명한다. 또한 각각이 언제 쓰이고, 어떤 장단점이 있으며, 로그인 유지 문제나 보안 사고를 예방하기 위해 사용자가 무엇을 이해해야 하는지도 함께 다룬다.

---

쿠키·세션·토큰의 개념과 기본 원리

1) 먼저 알아야 할 전제: HTTP는 “상태가 없는(stateless)” 통신이다

웹 브라우저가 웹사이트에 요청을 보내면 서버는 응답을 돌려주고, 그 요청은 끝난다. 기본적으로 서버는 “이전 요청과 다음 요청이 같은 사람인지”를 자동으로 알지 못한다. 이를 무상태(stateless)라고 한다.
따라서 로그인 유지, 장바구니, 사용자 설정 같은 기능을 만들려면 “사용자를 식별하는 정보”를 요청마다 함께 보내야 한다. 그 역할을 담당하는 것이 쿠키, 세션, 토큰이다.

2) 쿠키(cookie)란 무엇인가: 브라우저에 저장되는 작은 데이터다

쿠키는 웹사이트가 브라우저에 저장하도록 지시하는 작은 데이터 조각이다. 브라우저는 이후 같은 사이트에 요청을 보낼 때 쿠키를 자동으로 함께 전송한다. 이 특성 때문에 쿠키는 “사이트가 사용자를 구분하는 표식”으로 활용된다.

쿠키에 들어갈 수 있는 정보는 다양하지만, 중요한 점은 보통 “사용자 정보를 그대로 저장”하기보다는 “식별자”나 “인증에 필요한 값”을 저장한다는 것이다. 예를 들어 로그인 상태를 유지하기 위해 쿠키에 세션 ID를 담는 방식이 흔하다.

쿠키에는 보안과 동작을 제어하는 속성이 붙는다.

• 만료 시간(Expires/Max-Age): 언제까지 유지할지
• 도메인/경로(Domain/Path): 어떤 범위 요청에 붙을지
• Secure: HTTPS에서만 전송
• HttpOnly: 자바스크립트에서 접근 불가(XSS 방어에 유리)
• SameSite: 다른 사이트 요청에 쿠키가 붙는 범위 제어(CSRF 방어에 유리)

3) 세션(session)이란 무엇인가: 서버가 들고 있는 “로그인 상태 기록”이다

세션은 사용자의 상태 정보를 서버 쪽에 저장하는 방식이다. 사용자가 로그인하면 서버는 “이 사용자는 로그인됨”이라는 상태를 서버 메모리나 세션 저장소에 기록하고, 그 세션을 찾기 위한 세션 ID를 발급한다. 그리고 그 세션 ID를 보통 쿠키로 브라우저에 저장한다.
즉, 세션을 한 문장으로 정리하면 다음과 같다.

• 세션 데이터는 서버에 있고, 브라우저에는 세션 ID만 있다.
• 브라우저는 요청마다 세션 ID를 보내고, 서버는 그 ID로 상태를 조회한다.

이 구조는 “중요한 정보가 브라우저에 남지 않는다”는 장점이 있지만, 서버가 세션 저장소를 관리해야 한다는 비용이 생긴다. 서버가 여러 대로 늘어나는 환경에서는 세션을 공유하기 위한 설계(공유 세션 저장소, 세션 스티키 등)가 필요하다.

 

쿠키와 세션의 관계(세션 ID가 쿠키로 전달되는 구조)

4) 토큰(token)이란 무엇인가: “내가 누구인지 증명하는 값”을 들고 다니는 방식이다

토큰은 사용자를 인증하거나 권한을 확인하기 위한 문자열 값이다. 토큰 기반 인증은 세션처럼 서버에 상태를 저장하지 않거나(무상태에 가깝게) 상태 저장을 최소화하는 방식으로 설계되는 경우가 많다.
대표적으로 API 서버나 모바일 앱, SPA(단일 페이지 앱) 환경에서 토큰이 자주 쓰인다.

토큰은 형태에 따라 의미가 달라질 수 있다.

• 무작위 토큰: 서버가 토큰을 보고 서버 저장소에서 상태를 조회한다(세션 ID와 유사).
• 자체 포함 토큰(예: JWT): 토큰 안에 사용자 식별 정보, 만료 시간 등이 서명된 형태로 들어가며, 서버는 서명을 검증해 신뢰할 수 있다.

여기서 중요한 점은 “토큰을 어디에 저장하고 어떻게 전송하느냐”가 보안에 큰 영향을 준다는 것이다. 토큰이 유출되면 공격자가 사용자처럼 행동할 수 있다.

5) 핵심 비교: 쿠키·세션·토큰을 헷갈리지 않는 기준

세 가지를 가장 단순하게 구분하면 다음과 같다.

• 쿠키: 브라우저 저장 방식이며, 서버로 자동 전송되는 “그릇”에 가깝다.
• 세션: 서버에 저장되는 로그인 상태이며, 세션 ID로 조회한다.
• 토큰: 인증/권한을 증명하는 값이며, 요청에 포함되어 서버가 신뢰 여부를 판단한다.

쿠키는 기술 자체가 “인증”이 아니라 “저장과 전송”의 메커니즘이라는 점을 분명히 해야 한다. 쿠키에 무엇을 담느냐(세션 ID, 토큰 등)에 따라 목적이 달라진다.

---

실제 사용 사례와 문제 해결, 그리고 주의할 보안 포인트

1) 사례 1: “로그인이 자꾸 풀린다”는 문제의 원인 분류

로그인 유지가 자주 끊기는 문제는 사용자 경험에서 흔하다. 원인은 크게 다음으로 나뉜다.

• 쿠키가 삭제되거나 차단됨: 브라우저 설정, 시크릿 모드, 확장 프로그램, 쿠키 자동 삭제 기능
• 쿠키 만료 시간이 짧음: 사이트 정책상 보안 강화로 세션 유지 시간을 짧게 설정
• 세션 만료 또는 서버 재시작: 서버가 세션 저장소를 잃거나, 일정 시간 활동이 없으면 만료
• 토큰 만료: 토큰에 내장된 만료 시간이 지나 재발급이 필요

이 문제를 사용자가 현실적으로 점검할 때는 다음 순서가 효율적이다.

1. 시크릿 모드에서 동일 증상이 반복되는지 확인한다(쿠키 저장 환경 차이 확인).
2. 특정 브라우저에서만 발생하는지 확인한다(확장 프로그램/설정 영향 분리).
3. 같은 계정이 다른 기기에서도 자주 풀리는지 확인한다(사이트 정책/서버 이슈 가능성).
4. “자동 로그아웃 시간이 짧은 사이트”인지 안내 문구를 확인한다(정책 문제일 수 있음).

2) 사례 2: “장바구니가 사라진다”는 현상은 쿠키 의존 설계일 수 있다

어떤 쇼핑몰은 로그인하지 않아도 장바구니를 사용할 수 있게 한다. 이때 장바구니 식별자를 쿠키에 저장하는 방식이 흔하다. 쿠키가 지워지면 장바구니가 초기화될 수 있다.
반대로 로그인 기반으로 장바구니를 서버에 저장하는 사이트는 쿠키가 지워져도 다시 로그인하면 복원될 수 있다. 즉, 장바구니 지속성은 “쿠키에만 의존했는지, 서버 계정에 저장했는지”에 따라 달라진다.

3) 사례 3: 앱과 API에서는 왜 토큰이 많이 쓰이는가

모바일 앱이나 프론트엔드가 분리된 서비스에서는 서버에 매번 세션 상태를 관리하기보다, 토큰 기반으로 인증을 처리하는 구조가 자주 선택된다. 이유는 다음과 같다.

• 서버가 여러 대로 확장되어도 상태 공유 부담이 줄어든다.
• API 호출마다 인증 정보를 명시적으로 전달하기 쉽다.
• 만료 시간과 재발급 정책을 일관되게 적용하기 좋다.

다만 토큰은 보관과 유출 위험을 신중히 다뤄야 한다. 특히 토큰이 브라우저 스크립트에서 쉽게 접근 가능한 위치에 저장되면 XSS 공격에 취약해질 수 있다.

 

세션 기반 인증 vs 토큰 기반 인증의 요청 흐름 비교

4) 보안 관점에서 꼭 알아야 할 위험: 쿠키 탈취와 XSS, CSRF

쿠키·세션·토큰은 사용자 경험을 위해 필수지만, 공격자에게도 매력적인 목표다. 대표적인 위험을 간단히 정리하면 다음과 같다.

• 세션 탈취(session hijacking): 세션 ID가 유출되면 공격자가 로그인한 사용자처럼 행동할 수 있다.
• XSS(스크립트 삽입): 공격자가 페이지에 스크립트를 심어 쿠키나 토큰을 훔치거나, 사용자를 대신해 요청을 보낼 수 있다. HttpOnly 쿠키는 스크립트 접근을 막는 데 도움이 된다.
• CSRF(요청 위조): 사용자가 로그인된 상태를 악용해 사용자가 의도하지 않은 요청을 보내게 하는 공격이다. SameSite 설정이나 CSRF 토큰으로 방어한다.

여기서 사용자가 할 수 있는 실질적 예방은 단순하다.

• HTTPS를 사용하는 사이트인지 확인한다(자물쇠 표시).
• 공용 PC에서는 로그인 유지 옵션을 피하고, 사용 후 로그아웃한다.
• 브라우저 확장 프로그램을 최소화하고, 의심스러운 사이트에서 로그인하지 않는다.

5) “기억해 주는 기능”을 이해하면 개인정보 관리도 쉬워진다

쿠키는 단지 로그인 유지뿐 아니라 사용자 설정, 언어 선택, 최근 본 상품 같은 기능에도 쓰인다. 반면 광고 추적이나 분석에도 사용될 수 있으므로, 사용자는 “쿠키 삭제”가 어떤 효과를 가지는지 이해할 필요가 있다. 쿠키를 지우면 일부 편의 기능이 초기화될 수 있고, 자동 로그인도 풀릴 수 있다. 이것은 오류가 아니라 원리의 결과다.

---

웹은 무상태이지만, 쿠키·세션·토큰이 ‘기억’을 만들어낸다

웹(HTTP)은 기본적으로 무상태 통신이므로, 로그인 유지와 사용자 맞춤 기능을 위해 별도의 “기억 장치”가 필요하다. 쿠키는 브라우저에 저장되고 요청마다 자동 전송되는 데이터이며, 세션은 서버가 사용자 상태를 저장하고 세션 ID로 조회하는 방식이다. 토큰은 사용자가 누구인지 증명하는 값으로, 특히 API 중심 환경에서 자주 사용된다. 세 가지는 목적과 저장 위치, 확장성, 보안 위험이 다르므로 상황에 맞게 선택된다.
사용자 관점에서는 로그인 유지가 풀릴 때 쿠키 삭제, 만료 시간, 서버 세션 만료, 토큰 만료 같은 원인을 단계적으로 분리해 점검하면 문제를 빠르게 좁힐 수 있다.

다음으로 이어서 보면 좋은 주제는 두 가지다. 첫째, HTTPS와 TLS가 쿠키·세션·토큰 보호에 어떤 역할을 하는지에 대한 설명이다. 둘째, CORS와 동일 출처 정책이 웹 보안과 API 통신에서 왜 중요한지에 대한 정리다.