쿠키와 세션편집자 확인

쿠키는 웹 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각이다. 이 데이터는 브라우저에 저장되었다가, 동일한 서버에 대한 후속 요청 시 함께 전송된다. 쿠키의 주요 역할은 HTTP 프로토콜의 기본적인 상태 비저장성을 보완하여, 사용자와 웹 애플리케이션 간의 상태 정보를 유지하는 것이다.

쿠키는 주로 세 가지 목적으로 사용된다. 첫째, 세션 관리이다. 로그인, 장바구니, 게임 점수 등 서버가 기억해야 할 사용자 정보를 저장한다. 둘째, 개인화이다. 사용자 선호도, 테마, 언어 설정 등을 기억하여 맞춤형 환경을 제공한다. 셋째, 트래킹이다. 사용자의 행동을 기록하고 분석하여 광고 타겟팅이나 사용자 경험 분석에 활용된다.

쿠키의 동작은 서버의 HTTP 응답 헤더에 Set-Cookie를 포함시키는 것으로 시작한다. 브라우저는 이 값을 받아 저장한 후, 해당 서버로 보내는 모든 이후 요청의 Cookie 헤더에 자동으로 포함시킨다. 이를 통해 서버는 요청을 보낸 사용자를 식별하고 이전 상태를 인지할 수 있다.

쿠키의 동작 방식은 기본적으로 클라이언트와 서버 간의 HTTP 요청과 응답 헤더를 통해 이루어진다. 서버는 클라이언트에 데이터를 저장하도록 지시하고, 이후 클라이언트는 해당 데이터를 자동으로 서버에 전송한다.

구체적인 동작 과정은 다음과 같다.

1. 쿠키 생성 및 전송: 클라이언트(예: 웹 브라우저)가 서버에 최초 요청을 보내면, 서버는 응답 시 Set-Cookie 헤더에 쿠키 정보(이름, 값, 속성)를 담아 전송한다.

2. 쿠키 저장: 클라이언트는 이 응답을 받아, 지시된 속성에 따라 쿠키를 로컬 저장소(일반적으로 브라우저 관리)에 저장한다.

3. 쿠키 자동 전송: 이후 동일 서버에 대한 모든 요청에는, 브라우저가 자동으로 Cookie 요청 헤더에 저장된 쿠키 정보를 포함시켜 전송한다.

4. 쿠키 갱신 또는 삭제: 서버는 필요시 새로운 Set-Cookie 헤더로 기존 쿠키 값을 갱신하거나, 만료 날짜를 과거로 설정하여 삭제를 요청할 수 있다.

이 과정을 표로 정리하면 다음과 같다.

이러한 방식으로 쿠키는 HTTP의 상태 비저장성을 보완하여, 사용자의 상태 정보를 여러 요청에 걸쳐 유지할 수 있게 한다. 동작의 핵심은 서버가 설정 명령을 내리면 클라이언트가 이를 충실히 이행하고, 이후 모든 통신에 그 정보를 담아 보내는 데 있다.

쿠키는 수명과 저장 방식에 따라 주로 세션 쿠키와 지속 쿠키로 구분된다.

세션 쿠키는 사용자가 웹 브라우저를 종료하면 삭제되는 임시 쿠키이다. 이 쿠키는 메모리에만 저장되며, 만료 날짜(Expires 속성)나 최대 수명(Max-Age 속성)이 명시되지 않는다. 주로 로그인 상태나 장바구니 내용처럼 브라우징 세션 동안만 필요로 하는 일시적인 정보를 저장하는 데 사용된다. 브라우저 탭을 닫거나 브라우저를 완전히 종료하면 해당 쿠키는 자동으로 소멸한다.

지속 쿠키는 파일로 사용자의 디스크에 저장되어 브라우저를 닫거나 컴퓨터를 재시작해도 지정된 만료일까지 유지되는 쿠키이다. 서버가 쿠키를 설정할 때 'Expires' 또는 'Max-Age' 속성을 함께 전송하여 수명을 정의한다. 이 쿠키는 자동 로그인 기능, 사이트 언어 설정, 테마 선호도 등 사용자의 장기적인 선호도를 기억하는 데 활용된다.

세션은 웹 서버가 특정 클라이언트(일반적으로 사용자의 웹 브라우저)와의 일련의 상호작용 상태를 유지하기 위해 사용하는 메커니즘이다. 기본적으로 HTTP 프로토콜은 상태를 저장하지 않는(Stateless) 특성을 가지므로, 서버는 각 요청을 독립적인 트랜잭션으로 처리한다. 이로 인해 사용자가 페이지를 이동하거나 새로 고침할 때마다 서버는 해당 사용자를 식별할 수 없다. 세션은 이러한 한계를 극복하기 위해 도입되었다. 서버는 클라이언트가 최초로 접속할 때 고유한 세션 ID를 생성하고, 이 ID를 키로 하여 서버 측에 사용자의 상태 정보(예: 로그인 정보, 장바구니 내용, 설정값)를 저장한다.

세션의 필요성은 상태 유지가 필수적인 웹 애플리케이션에서 명확히 드러난다. 예를 들어, 인증(Authentication)이 필요한 서비스에서 사용자는 로그인 후 여러 페이지를 이동하며 작업한다. 세션이 없다면 매 페이지 요청마다 사용자는 아이디와 비밀번호를 다시 입력해야 한다. 또한 전자상거래 사이트의 장바구니 기능은 사용자가 상품을 추가하고 결제하기까지의 상태를 유지해야 하며, 이는 세션 없이는 구현이 매우 복잡해진다. 따라서 세션은 사용자 경험을 향상시키고 복잡한 웹 애플리케이션 로직을 구현하는 데 필수적인 기반 기술이다.

세션은 일반적으로 다음과 같은 방식으로 관리된다.

세션은 서버 측에 사용자별 상태 정보를 저장하고, 클라이언트에게는 이 정보를 식별할 수 있는 세션 ID를 부여하는 방식으로 동작한다. 일반적인 동작 흐름은 다음과 같다.

1. 클라이언트(예: 웹 브라우저)가 서버에 최초 요청을 보낸다.

2. 서버는 요청을 받은 후, 고유한 세션 ID를 생성한다. 이 ID는 보통 암호화된 난수 문자열이다.

3. 서버는 생성된 세션 ID와 연결된 저장 공간(메모리, 데이터베이스, 파일 등)을 내부에 마련하고, 필요한 사용자 데이터를 저장한다.

4. 서버는 응답 시 생성한 세션 ID를 클라이언트에게 되돌려준다. 이 전달은 주로 응답 헤더의 Set-Cookie 필드를 통해 이루어지며, 쿠키의 이름은 일반적으로 JSESSIONID(Java)나 PHPSESSID(PHP)와 같다.

5. 클라이언트는 이후 서버에 요청을 보낼 때마다, 받은 세션 ID를 요청 헤더의 Cookie 필드에 담아 서버로 전송한다.

6. 서버는 수신한 요청에서 세션 ID를 추출하여, 해당 ID와 연결된 저장 공간에서 사용자 상태 정보를 찾아낸다. 이를 통해 사용자를 식별하고 이전 상태를 유지한다.

세션 저장소는 서버의 메모리에 저장되는 방식이 가장 일반적이지만, 서버를 여러 대 운영하는 로드 밸런싱 환경이나 서버 재시작 후에도 데이터를 유지해야 할 경우에는 Redis나 Memcached 같은 외부 저장소나 데이터베이스를 사용하기도 한다. 세션은 서버에 데이터를 저장하기 때문에 클라이언트에 직접 노출되는 쿠키보다 보안상 유리하지만, 서버의 자원을 사용한다는 점과 동시 접속 사용자가 많을 경우 관리 부담이 커진다는 특징이 있다.

세션 ID는 서버가 각 클라이언트의 세션을 식별하기 위해 생성하는 고유한 문자열이다. 일반적으로 암호학적으로 안전한 난수 생성기를 사용하여 만들어지며, 예측이 불가능해야 한다. 이 ID는 서버 측에 저장된 세션 데이터(예: 사용자 ID, 권한, 장바구니 정보)를 찾는 열쇠 역할을 한다.

세션 ID는 주로 쿠키를 통해 클라이언트에게 전달되고 이후 요청마다 서버로 회신된다. 가장 일반적인 방식은 JSESSIONID(자바), PHPSESSID(PHP), sessionid(파이썬 Django)와 같은 이름의 쿠키에 ID 값을 저장하는 것이다. 쿠키를 사용할 수 없는 환경을 대비하여 URL 재작성(URL Rewriting) 방식도 존재한다. 이 방식은 모든 하이퍼링크의 URL 끝에 ?sessionid=고유값 형태로 세션 ID를 붙여서 상태를 유지한다.

서버 측 세션 관리 방식은 다음과 같이 구분할 수 있다.

현대의 분산 웹 애플리케이션에서는 여러 대의 웹 서버가 세션을 공유해야 하는 경우가 많으므로, Redis와 같은 외부 인메모리 저장소를 세션 저장소로 사용하는 것이 일반적인 추세이다. 이는 서버의 확장(Scale-out)을 용이하게 한다.

쿠키는 클라이언트, 즉 사용자의 웹 브라우저에 텍스트 파일 형태로 저장된다. 이는 서버의 부하를 줄일 수 있지만, 클라이언트 측에서 쉽게 접근하고 조작할 수 있어 보안에 취약한 구조이다. 특히 중요한 인증 정보를 평문으로 쿠키에 저장하는 것은 세션 하이재킹 등의 공격에 노출될 위험이 크다.

반면, 세션 정보는 주로 서버의 메모리나 데이터베이스와 같은 저장소에 보관된다. 클라이언트에게는 실제 데이터가 아닌, 해당 데이터를 찾을 수 있는 키인 세션 ID만 전달된다. 따라서 중요한 사용자 정보가 네트워크를 통해 직접 노출되거나 클라이언트 측에서 변조될 위험이 상대적으로 적다.

보안 측면에서 이 차이는 매우 중요하다. 쿠키는 HttpOnly 속성을 설정하지 않으면 자바스크립트를 통해 접근이 가능해 XSS(크로스 사이트 스크립팅) 공격에 취약할 수 있다. 또한 Secure 속성이 없으면 암호화되지 않은 HTTP 연결을 통해 전송될 위험이 있다. 세션 방식은 서버에서 세션 데이터를 통제할 수 있으므로, 유효 기간 관리나 강제 로그아웃과 같은 보안 정책을 적용하기에 더 유리하다.

쿠키와 세션은 각각 고유한 수명 주기와 저장 용량 제한을 가진다. 이러한 차이는 데이터의 지속성과 저장 가능한 정보의 양에 직접적인 영향을 미친다.

쿠키의 수명은 클라이언트 측에서 관리된다. 세션 쿠키는 브라우저를 닫으면 즉시 삭제되는 반면, 지속 쿠키는 서버에서 설정한 Expires 또는 Max-Age 속성에 따라 하드 디스크에 저장되어 지정된 기간 동안 유지된다. 쿠키의 저장 용량은 일반적으로 도메인당 약 4KB로 제한되며, 개수도 브라우저별로 제한이 있다(예: 도메인당 20개). 이는 클라이언트에 과도한 데이터를 저장할 수 없음을 의미한다.

반면, 세션의 수명은 서버 측에서 제어된다. 세션은 일반적으로 사용자가 일정 시간(예: 30분) 활동이 없으면 서버에 의해 자동으로 만료되거나, 사용자가 명시적으로 로그아웃할 때 종료된다. 세션 데이터는 서버의 메모리나 데이터베이스에 저장되므로, 쿠키에 비해 훨씬 더 큰 용량의 데이터(수 MB 이상)를 저장할 수 있다. 그러나 이는 서버 자원을 소모한다는 단점이 된다.

다음 표는 수명과 용량 측면에서의 주요 차이를 요약한다.

이러한 특성으로 인해, 장기간 유지되어야 하는 간단한 설정 정보는 쿠키에, 보안이 중요하거나 대용량의 임시 데이터는 세션에 저장하는 것이 일반적이다.

쿠키와 세션은 각각의 특성에 따라 적합한 사용 사례가 다르다. 일반적으로 간단한 상태 정보나 사용자 편의성 기능에는 쿠키가, 보안이 중요한 인증 정보나 민감한 데이터 처리에는 세션이 주로 활용된다.

요약하면, 쿠키는 클라이언트에 의존하는 가벼운 정보 저장에, 세션은 서버가 통제해야 하는 보안 중심의 상태 관리에 적합하다. 현대의 웹 애플리케이션은 보통 두 기술을 조합하여 사용한다. 예를 들어, 로그인은 세션으로 처리하지만, 로그인 식별자나 세션 ID 자체는 쿠키를 통해 주고받는 방식이 일반적이다.

세션 하이재킹은 공격자가 합법적인 사용자의 세션 ID를 탈취하여 해당 사용자의 권한으로 시스템에 접근하는 공격 기법이다. 주로 쿠키에 저장된 세션 ID가 유출될 때 발생하며, 이를 통해 공격자는 사용자의 개인정보를 열람하거나 불법적인 작업을 수행할 수 있다.

세션 하이재킹의 주요 공격 경로와 그에 따른 방지법은 다음과 같다.

효과적인 방지를 위해서는 단일 방법보다는 여러 방법을 조합하여 적용하는 것이 중요하다. 예를 들어, HTTPS를 사용하면서도 HttpOnly와 Secure 속성을 함께 설정하고, 세션 타임아웃을 짧게 유지하며, 중요한 작업 전에는 재인증을 요구하는 다중 방어 전략이 필요하다. 또한, 정기적인 보안 감사와 취약점 점검을 통해 새로운 공격 벡터에 대비해야 한다.

쿠키는 편리한 기능을 제공하지만, 잘못 설정되면 세션 하이재킹이나 사이트 간 스크립팅(XSS)과 같은 보안 위협에 노출될 수 있다. 이를 완화하기 위해 쿠키에는 여러 보안 속성을 설정할 수 있다.

주요 보안 속성으로는 HttpOnly, Secure, SameSite가 있다. HttpOnly 속성이 설정된 쿠키는 자바스크립트의 document.cookie API를 통해 접근할 수 없으며, 오직 HTTP 요청을 통해서만 서버로 전송된다. 이는 XSS 공격으로 인해 쿠키 값이 탈취되는 위험을 크게 줄인다. Secure 속성은 쿠키가 HTTPS 프로토콜을 통한 암호화된 연결에서만 전송되도록 강제한다. 따라서 민감한 정보를 담은 쿠키는 반드시 이 속성을 설정하여 중간자 공격(MitM)을 방지해야 한다. SameSite 속성은 사이트 간 요청 위조(CSRF) 공격을 방지하는 데 핵심적인 역할을 한다. 이 속성은 쿠키가 어떤 상황에서 외부 사이트로 전송될 수 있는지를 제어한다.

SameSite 속성은 Strict, Lax, None 세 가지 값으로 설정할 수 있다. 각 값의 동작 방식은 다음과 같다.

이러한 속성들을 적절히 조합하여 설정함으로써, 쿠키를 통한 사용자 상태 관리를 보다 안전하게 구현할 수 있다.

사용자가 웹사이트에 로그인한 상태를 브라우저를 닫거나 다른 페이지로 이동해도 일정 기간 동안 유지하는 기능은 쿠키와 세션을 조합하여 구현하는 대표적인 사례이다.

일반적인 로그인 상태 유지 흐름은 다음과 같다. 먼저, 사용자가 아이디와 비밀번호를 입력하여 로그인 요청을 보내면 서버는 인증을 수행한다. 인증이 성공하면 서버는 해당 사용자를 식별할 수 있는 고유한 세션 ID를 생성하여 서버 측 저장소(예: 메모리, 데이터베이스)에 저장한다. 이때, 생성된 세션 ID를 클라이언트에게 전달하기 위해 응답 헤더의 Set-Cookie 필드를 이용한다. 브라우저는 이 세션 쿠키를 받아 저장한 후, 해당 사이트에 대한 모든 후속 요청에 Cookie 헤더를 통해 세션 ID를 자동으로 포함시킨다. 서버는 매 요청마다 전달받은 세션 ID를 검증하여 해당 사용자의 인증 상태와 정보를 확인하고 요청을 처리한다.

로그인 상태 유지 방식은 크게 두 가지로 구분된다. 첫째는 위에서 설명한 세션 기반 인증으로, 주요 상태 정보는 서버에 저장되고 클라이언트에는 식별자만 전달된다. 둘째는 JWT와 같은 토큰 기반 인증이다. 이 방식은 인증 정보 자체를 쿠키나 로컬 스토리지에 저장된 암호화된 토큰에 담아 클라이언트가 보관하고, 서버는 별도의 상태 저장 없이 토큰의 유효성만 검사한다. 세션 방식은 서버에 부하가 발생할 수 있지만 세션을 쉽게 무효화할 수 있는 장점이 있고, 토큰 방식은 서버 확장성이 좋지만 토큰이 탈취당할 경우 대처가 어려운 단점이 있다.

로그아웃은 이 상태를 종료하는 과정이다. 세션 기반 방식에서는 서버 측에서 해당 세션 ID를 저장소에서 삭제하여 무효화한다. 동시에 클라이언트에게는 세션 쿠키의 만료 날짜를 과거로 설정하는 응답을 보내 브라우저가 쿠키를 삭제하도록 유도한다. 토큰 기반 방식에서는 일반적으로 클라이언트 측에서 토큰을 단순히 삭제하지만, 서버 측에서 블랙리스트를 관리하는 등 추가 조치가 필요할 수 있다.

장바구니 기능은 사용자가 웹사이트에서 상품을 선택해 임시로 모아두고, 나중에 한꺼번에 결제할 수 있게 하는 전자상거래의 핵심 요소이다. HTTP 프로토콜의 상태 비저장성 때문에, 사용자가 페이지를 이동하거나 브라우저를 닫았다 열면 일반적으로 이전에 선택한 상품 정보가 사라지게 된다. 쿠키와 세션은 이러한 문제를 해결하여 장바구니 정보를 사용자별로 유지하는 데 사용된다.

초기 웹사이트들은 주로 쿠키를 이용해 장바구니 데이터를 클라이언트 측에 저장했다. 선택한 상품의 ID와 수량 같은 간단한 정보를 쿠키에 담아 사용자의 브라우저에 저장하는 방식이다. 이 방법은 서버의 부하를 줄일 수 있지만, 저장 용량이 제한적(보통 4KB)이고, 사용자가 쿠키를 삭제하면 정보가 사라지며, 보안에 취약할 수 있다는 단점이 있다.

보다 일반적이고 안전한 방법은 세션을 사용하는 것이다. 서버는 사용자가 장바구니에 상품을 추가할 때마다 해당 사용자의 세션 저장소(예: 메모리, 데이터베이스, Redis 등)에 상품 목록을 저장한다. 사용자를 식별하기 위한 세션 ID만 쿠키를 통해 클라이언트에게 전달한다. 이 방식은 모든 데이터가 서버에 저장되므로 보안성이 높고, 저장 공간 제한이 없으며, 여러 기기에서의 동기화 같은 복잡한 로직 구현이 가능하다.

현대의 대규모 전자상거래 사이트들은 성능과 확장성을 위해 세션 데이터를 서버의 메모리가 아닌 외부 인메모리 데이터베이스에 저장하는 경우가 많다. 또한, 사용자가 로그인하기 전의 장바구니 항목과 로그인 후의 장바구니 항목을 병합하는 등 더 나은 사용자 경험을 제공하기 위한 복잡한 로직이 세션 관리 백엔드에 구현된다.

JWT(JSON Web Token)는 당사자 간에 정보를 JSON 객체로 안전하게 전송하기 위한 개방형 표준(RFC 7519)이다. 이 토큰은 디지털 서명되어 있어 신뢰할 수 있으며, 주로 인증(Authentication)과 권한 부여(Authorization)에 사용된다. 쿠키와 세션이 서버 측에 상태를 저장하는 방식과 달리, JWT는 필요한 모든 정보를 토큰 자체에 포함하는 자기 수용적(self-contained) 방식으로 동작한다.

JWT는 점('.')으로 구분된 세 부분으로 구성된다.

* 헤더(Header): 토큰의 유형(예: JWT)과 사용된 서명 알고리즘(예: HMAC SHA256 또는 RSA)을 지정한다.

* 페이로드(Payload): 클레임(claim)을 포함한다. 클레임은 엔티티(일반적으로 사용자)와 추가 데이터에 대한 진술이다. 등록된 클레임, 공개 클레임, 비공개 클레임으로 나뉜다.

* 서명(Signature): 헤더와 페이로드가 비밀 키로 서명되어 생성된다. 이 서명은 토큰이 중간에 조작되지 않았음을 검증하는 데 사용된다.

동작 방식은 일반적으로 클라이언트가 로그인 자격 증명을 서버에 보내면, 서버는 이를 검증하고 사용자 정보가 담긴 JWT를 생성하여 응답한다. 클라이언트는 이후 요청의 Authorization 헤더에 이 토큰을 담아 보낸다. 서버는 토큰의 서명을 검증하고 페이로드의 정보를 신뢰하여 사용자를 인증하고 권한을 부여한다. 서버 측에서 세션 상태를 유지할 필요가 없으므로 상태 비저장성(Stateless)을 유지하며 확장성이 좋다는 장점이 있다. 그러나 토큰이 한번 발급되면 만료 시간 전에는 취소하기 어렵고, 페이로드 정보가 암호화되지 않은 경우(일반적임) 중요한 데이터를 담으면 안 된다는 주의점이 있다.

캐시는 데이터나 자원의 임시 복사본을 저장하여 이후 동일한 요청에 대한 응답 속도를 높이는 기술이다. 주로 정적 자원인 HTML, CSS, JavaScript 파일, 이미지 등을 클라이언트 측(브라우저)이나 중간 프록시 서버에 저장하여 사용한다.

쿠키/세션과 캐시의 주요 차이점은 저장 목적과 위치, 수명 관리 방식에 있다. 쿠키와 세션은 주로 사용자 식별과 상태 정보를 관리하기 위해 사용되며, 그 정보는 주로 서버 측(세션)이나 클라이언트 측(쿠키)에 저장된다. 반면 캐시는 성능 최적화를 목표로 하며, 저장된 데이터는 사용자와 무관하게 자원 자체의 재사용을 위해 활용된다. 또한 캐시의 수명은 일반적으로 자원의 변경 주기나 서버에서 설정한 Cache-Control 헤더와 같은 정책에 의해 결정된다.

다음 표는 쿠키/세션과 캐시의 주요 특성을 비교한 것이다.

실제 웹 애플리케이션에서는 이 두 기술이 상호 보완적으로 사용된다. 예를 들어, 사용자는 캐시 덕분에 빠르게 웹 페이지의 레이아웃과 이미지를 로드할 수 있으며, 동시에 쿠키에 저장된 세션 ID를 통해 서버에 개인화된 요청(예: 장바구니 확인)을 보낼 수 있다.