🍪 웹사이트를 이용할 때마다 아이디와 비밀번호를 매번 입력할 필요가 없는 것은 바로 '인증' 정보를 웹이 기억해 주기 때문입니다. 이 인증 정보를 다루는 세 가지 대표적인 방식이 **쿠키(Cookie), 세션(Session), 토큰(Token)**입니다. 이들은 모두 사용자의 신분을 증명하지만, 정보를 '어디에, 어떻게' 보관하고 확인하는지에 따라 보안 강도와 작동 방식이 완전히 달라집니다. 이 포스팅에서는 이 세 가지 방식을 일상적인 비유를 통해 초보자 눈높이에서 쉽게 설명하고, 보안상 어떤 차이가 있는지 알아보겠습니다.
✨ 핵심 원리: '정보 보관 위치'와 '신분 확인 방식' 🕵️
쿠키, 세션, 토큰은 모두 **'로그인 상태를 유지'**하는 목적을 가지지만, 각각 '신분증을 몸에 지니고 다니는지', '직원이 보관하는 보관함 열쇠를 가지고 있는지' 등 완전히 다른 방법을 사용합니다.
🔥 1. 쿠키 (Cookie): '내 몸에 붙이는 이름표' 📛
쿠키는 사용자의 브라우저(클라이언트)가 웹 서버로부터 받은 정보를 사용자의 컴퓨터에 파일 형태로 저장해 두는 방식입니다. 마치 여러분이 놀이공원에 입장할 때 **'손목에 붙이는 띠'**나 **'옷에 붙이는 이름표'**와 같습니다.
- 정보 보관 위치: 클라이언트(사용자 브라우저)
- 작동 방식: 브라우저가 웹사이트를 방문할 때마다 이 이름표를 서버에 함께 보냅니다.
- 보안 취약점: 이름표가 외부에 그대로 노출되어 있기 때문에, 누군가 이 파일을 탈취하면 내 신분 정보를 그대로 복사하여 위조할 수 있습니다. 특히 **크기 제한(4KB)**이 있고, 민감한 정보를 직접 담으면 보안에 매우 취약합니다.
👉 관련 글 : 웹사이트 접속 시 '쿠키'를 허용해야 하는 이유와 위험성
웹사이트 접속 시 '쿠키'를 허용해야 하는 이유와 위험성
💡 혹시 웹사이트에 처음 접속할 때마다 '쿠키(Cookie) 허용' 팝업 때문에 잠시 망설여 보신 적 있으신가요? 🧐 그냥 무시하고 '동의' 버튼을 누르거나, 때로는 왠지 모르게 불안해서 '거부'를 눌
praymeyer2025.tistory.com
🧘 2. 세션 (Session): '안전한 보관함 열쇠' 🔑
세션은 인증 정보를 쿠키처럼 사용자 컴퓨터에 저장하는 대신, **웹 서버의 안전한 저장소(서버 메모리/DB)**에 보관하는 방식입니다. 사용자의 브라우저는 단지 서버가 발행한 **'세션 ID'**라는 보관함 열쇠만 쿠키에 담아 가지고 다닙니다.
- 정보 보관 위치: 서버 (인증 정보), 클라이언트 (세션 ID)
- 작동 방식:
- 사용자가 로그인하면 서버는 사용자의 모든 정보(세션)를 안전한 보관함에 저장합니다.
- 서버는 사용자에게 **보관함 열쇠 번호(세션 ID)**만 줍니다.
- 사용자가 재방문할 때마다 이 열쇠 번호를 서버에 제시하면, 서버는 열쇠로 보관함을 열어 신분을 확인합니다.
- 보안 장점: 실제 민감 정보는 서버에만 보관되므로, 중간에 열쇠 번호(세션 ID)가 탈취되더라도 정보 자체가 유출되지는 않습니다.
- 보안 취약점: 열쇠 번호(세션 ID)가 탈취되어 서버에 제시되면, 서버는 진짜 사용자로 오인할 수 있습니다 (세션 하이재킹). 또한, 서버의 자원(메모리)을 많이 사용하여 서버가 확장될 때 관리가 복잡합니다.
💪 3. 토큰 (Token): '암호화된 신분 증명서' 📜
토큰 방식(주로 JWT: JSON Web Token)은 쿠키나 세션 ID처럼 서버에 아무것도 저장하지 않습니다. 대신, 로그인할 때 서버가 사용자의 신분 정보 자체를 암호화하고 서명한 **'봉인된 신분 증명서'**를 발행해 사용자에게 줍니다.
- 정보 보관 위치: 클라이언트 (암호화된 토큰)
- 작동 방식:
- 서버가 사용자 정보를 담아 토큰을 **암호화하고 서명(Secret Key)**합니다.
- 사용자는 이 봉인된 증명서를 가지고 다니다가, 서버에 요청할 때마다 제시합니다.
- 서버는 토큰을 받으면 **'비밀 열쇠'**로 서명을 확인하여 변조되지 않았음을 검증합니다.
- 보안 장점: 서버에 상태 정보를 저장할 필요가 없어 서버 확장(Scale-out)에 유리하며, 토큰에 만료 시간을 설정하여 탈취되어도 일정 시간이 지나면 무효화됩니다. 또한 서명이 되어 있어 중간에 내용 변조가 불가능합니다.
- 보안 취약점: 토큰 자체에 정보가 담겨 있기 때문에, HTTPS(암호화 통신)를 사용하지 않으면 토큰 내용이 노출될 위험이 있고, 토큰이 탈취되면 만료되기 전까지는 막기 어렵습니다.
✅ 요약 및 보안 차이 비교 💯
| 🆔 구분 | 쿠키 (Cookie) | 세션 (Session) | 토큰 (Token) (JWT) |
| 비유 | 몸에 붙이는 이름표 | 보관함 열쇠 | 암호화된 신분 증명서 |
| 인증 정보 저장 위치 | 클라이언트 (브라우저) | 서버 (안전 저장소) | 클라이언트 (토큰 자체) |
| 서버 부하 | 낮음 (서버에 상태 없음) | 높음 (모든 세션 저장) | 매우 낮음 (Stateless) |
| 보안 레벨 | 가장 취약 (정보 노출) | 중간 (세션 ID 탈취 가능) | 강함 (변조 불가, 만료 시간) |
| 주요 용도 | 간단한 설정 저장, 장바구니 | 전통적인 웹 서비스 인증 | MSA, 모바일, API 인증 |
HTTPS를 통해 통신을 암호화하는 것은 기본이고, 이 세 가지 방식 중 어떤 것을 선택하느냐에 따라 서비스의 확장성과 보안 수준이 결정됩니다. 토큰이 가장 최신 기술이며 보안과 확장성에서 유리하여 최근의 MSA(마이크로서비스) 환경에서 가장 많이 사용됩니다.
📚 출처
- 웹 통신 표준: HTTP 쿠키의 작동 원리
- 웹 보안 개론: 세션 하이재킹 및 쿠키 보안 속성
- JWT(JSON Web Token) 표준: Stateless 인증 원리
👉 함께 보면 도움되는 글: 모놀리식 → MSA → 모듈러 모노리스, 아키텍처 진화 흐름
모놀리식 → MSA → 모듈러 모노리스, 아키텍처 진화 흐름
소프트웨어 아키텍처가 모놀리식에서 MSA를 거쳐 모듈러 모노리스로 진화한 기술적 흐름을 중급 개발자 관점에서 분석합니다. 각 아키텍처의 구조적 특징, 장단점을 명확히 비교하고, 확장성 및
praymeyer2025.tistory.com
'💡 IT 핵심 지식 (Core) > 🔒사이버 보안' 카테고리의 다른 글
| 패킷 스니핑이 가능한 이유와 차단 기술 : 네트워크 도청 원리와 방어 메커니즘 (0) | 2025.12.13 |
|---|---|
| TLS 핸드셰이크의 실제 과정 : 신원 확인과 비밀 암호 교환 (0) | 2025.12.12 |
| HTTPS는 왜 안전할까? 인증서·암호화 쉽게 정리 (0) | 2025.12.10 |
| 제로 트러스트 이후 주목받는 접근제어 방식, ABAC란? (0) | 2025.11.28 |
| OAuth2·JWT 인증 흐름 완전 분석: 현대 웹 서비스의 권한 및 인증 표준 (0) | 2025.11.09 |