웹 서핑을 하다 보면 '로그인 유지', '장바구니', '최근 본 상품' 같은 기능들을 자주 마주치는데요. 여러분이 로그인하지 않아도 내가 뭘 봤는지 기억하고, 심지어는 내 취향에 맞는 광고까지 띄워주잖아요?
신기하게도 이런 기능들 뒤에는 쿠키(Cookie), 세션(Session), 그리고 JWT(JSON Web Token)라는 세 명의 핵심 키워드가 숨어 있답니다.
이 친구들이 없으면 웹 서비스는 마치 기억상실증에 걸린 것처럼 매번 "너 누구니?" 하고 물어봐야 할 거예요. 자, 그럼 웹 개발에서 사용자 인증과 상태 관리를 책임지는 이 세 친구들을 지금부터 파헤쳐 볼까욧!!!!!
1. 🍪 쿠키 (Cookie): 브라우저 속 비밀 쪽지!
쿠키는 말 그대로 브라우저에 저장되는 아주 작은 '쪽지' 같은 데이터로 이해하시면 편한데요. 서버가 여러분의 브라우저에게 "이 정보 좀 가지고 있어줘!" 하고 부탁하면, 브라우저는 고분고분 그 쪽지를 보관해 뒀다가, 다음에 같은 서버에 접속할 때 그 쪽지를 '슬쩍' 함께 보내줍니다.
세부적으로는,
- 어디에 살까? : 여러분의 브라우저에 살아요.(내 컴퓨터 안에)
- 크기는? : 아주 작아서 4KB 정도밖에 안 됨. 작은 메모지.
- 수명은? : 서버가 "이 쪽지는 며칠 뒤에 버려줘!" 하고 알려주면 그 기간 동안만 살아있고, 아니면 브라우저를 닫을 때 사라지는 일회성 쪽지일 수도 있습니다.
- 쓰임새는? :
- 1)로그인 유지 : "아이디 기억하기" 기능에 쓰이는 단골손님
- 2)장바구니 : 그래서 비회원도 물건을 담아둘 수 있습죠.
- 3)사용자 설정 : 내가 좋아하는 테마나 언어를 기억하는 비서 역할
- 4)트래킹 : 어떤 페이지를 보고 갔는지 몰래 기록하는 역할
- 조심할 점: 브라우저에 저장되기 때문에 해킹 당할 위험이 있어요! 그래서 HttpOnly (자바스크립트 접근 금지)나 Secure (HTTPS에서만 전송) 같은 안전장치를 꼭 걸어줘야 해요.
2. 🔑 세션 (Session): 서버가 지켜주는 VIP 라운지!
세션은 쿠키랑 비슷해 보이지만 결정적인 차이가 있어요. 바로 사용자 정보가 '서버'에 저장된다는 점인데요!
세션을 이해하려면 VIP 라운지를 떠올려 보세요. 여러분이 라운지에 입장하면 직원(서버)이 여러분에게 고유한 '회원 카드 번호'(세션 ID)를 줍니다. 이 카드 번호는 작지만, 실제 VIP 정보(여러분 개인 정보)는 라운지 내부(서버)에 안전하게 보관되어 있죠. 여러분이 라운지를 돌아다닐 때마다 그 카드 번호만 보여주면, 직원은 내부 정보를 확인하고 여러분을 VIP로 대접해 줍니다.
- 어디에 살까? : 오직 서버에만 살아요. (클라이언트는 회원 카드 번호=세션ID만 가짐!)
- 크기는? : 서버에 저장되니 데이터 양에 제한이 없음
- 수명은? : 서버에서 "일정 시간 동안 활동 없으면 VIP 자격 박탈!" 하고 관리
- 쓰임새는?
- 1) 강력한 로그인 인증: 웹 서비스 로그인에 가장 오랫동안, 그리고 많이 쓰인 방식. 쿠키보다 보안성 좋음.
- 2) 임시 데이터 저장: 회원 가입 중 여러 단계에 걸쳐 입력하는 정보처럼, 잠시만 보관해야 할 데이터 저장에도 좋음.
- 조심할 점: 사용자가 많아지면 서버가 기억해야 할 정보도 많아지니, 서버가 힘들어할 수 있어요. 여러 서버를 동시에 쓸 땐 '세션 공유'라는 복잡한 문제를 해결해야 함!
잠깐!!! 여기서 드는 질문 1
Q. 세션 정보는 웹 서버에 있고, 클라이언트는 세션ID를 가진다고 했는데, 그러면 세션 ID는 어디에 저장됨?
→ A. 대부분의 경우 이 세션 ID는 쿠키의 형태로 클라이언트 브라우저에 저장됨. 세션 ID가 클라이언트와 서버를 이어주는 연결 고리인 것.
잠깐!!! 여기서 드는 질문 2
Q. 그러면 그냥 쿠키만 써도 되지 않음? 세션을 사용하면서도 결국 쿠키가 등장하잖슴~~
→ A. 편의성만 놓고 보면 쿠키가 더 간단해 보일 수 있지만, 보안성, 저장할 수 있는 용량, 관리의 용이성 측면에서는 세션을 쓰는게 좋기 때문임
- 보안성 : 쿠키만 사용하면, 사용자 인증에 필요한 모든 정보(예: userid=kimchulsu, is_admin=true)가 브라우저에 저장되게 되고, 탈취 시도에 의해 주요 정보가 탈취되기 쉬움. 그러나, 세션을 사용하는 경우 (쿠키 + 서버 세션) 오직 '세션 ID'만 쿠키 형태로 저장되고,실제 사용자의 민감한 정보(로그인 여부, 사용자 ID, 권한 등)는 서버에 안전하게 보관됨! 탈취되더라도 의미없는 세션ID 문자열만 탈취됨!
- 저장 용량 : 쿠키는 용량 제한(약 4KB)이 있어서 저장할 수 있는 정보의 양이 매우 적지만, 세션은 서버에 저장되므로 용량 제한이 없음.
- 관리의 용이성: 세션을 사용하면 서버에서 사용자 상태를 중앙 집중적으로 관리하기 용이한데요. 사용자가 로그아웃하면 해당 사용자의 세션을 바로 서버에서 삭제해버려도 되고, 일정 시간 동안 활동 없는 세션을 서버에서 자동으로 만료시켜도 되죠. 그리고 동시 접속을 제한하거나 여러 기기에서 로그인 시 이전 세션을 만료시키기도 편하죠. 근데 이걸 쿠키만 쓴다고하면 서버에서 만료시킬 수가 없겠죠.
3. 🛡️ JWT (JSON Web Token): 도장 찍힌 신분증!
JWT는 최근 웹 개발 트렌드에서 가장 핫한 인증 방식인데요. 세션처럼 서버가 사용자의 상태를 직접 기억하는 대신, 모든 정보를 토큰이라는 하나의 암호화된 신분증에 담아 클라이언트에게 줘 버리는 방식인데요.
JWT는 여러분이 공항에서 여권을 보여주면, 직원이 여러분의 모든 정보를 바로 확인하고 입국시켜주는 것과 비슷한 방법입니다. 서버는 이 신분증(JWT)이 진짜인지 도장(서명)만 확인하면 되거덩요.
JWT는 세 부분으로 나뉘는데요.
1) 헤더 (Header): 이 신분증이 JWT라는 것과, 어떤 도장(암호화 알고리즘)으로 찍었는지 정보가 있음.
2) 페이로드 (Payload): 여러분의 이름, 권한, 유효기간 등 진짜 '정보'가 여기에 담김. 여기 담긴 정보는 암호화된 게 아니라 '인코딩'된 거라서 쉽게 볼 수 있어요. 그래서 민감한 정보는 담지 않는 게 좋음.
3) 서명 (Signature): 여기가 가장 중요! 헤더와 페이로드, 그리고 서버만 아는 '비밀 키'를 가지고 찍은 도장이에요. 이 도장이 없거나 위조되면 "이건 가짜 신분증이야!" 하고 바로 알 수 있음.
그러면 어떤 방식으로 작동할까요?
→ 사용자가 로그인을 성공 or 소셜 로그인 연동 or Refresh Token을 이용한 Access Token 재발급
→ 서버는 사용자 정보가 담긴 JWT를 생성(헤더, 페이로드, 서명 포함)
→ 생성된 JWT를 클라이언트에게 바로 전달(서버는 JWT를 DB나 메모리에 저장하지 않음)
→ 클라이언트는 이걸 로컬 스토리지/세션스토리지 /쿠키 같은 곳에 저장
→ 클라이언트가 뭔가를 요청
→클라이언트로부터 JWT를 받으면 서버는 JWT의 서명을 비밀 키로 검증
→ 검증이 통과되면 JWT의 페이로드에서 정보를 추출해 요청 처리
여기서 핵심은 JWT 방식에서 서버는 JWT를 DB나 메모리에 저장하지 않는다는 것이죠.
쿠키랑 세션에서처럼 정리를 좀 해보자면,
- 어디에 살까? : 주로 클라이언트(브라우저 Local Storage, Session Storage, 또는 쿠키)에 삶.
- 크기는? : 담긴 정보량에 따라 달라짐
- 수명은? : 신분증처럼 '만료 시간'이 있어서, 시간이 지나면 새로 받아야 함. (이 만료 시간을 잘 관리하는 게 JWT의 핵심)
- 쓰임새는? :
- 1) 모바일 앱/SPA(단일 페이지 앱) 인증: 서버와 클라이언트가 명확히 분리된 요즘 웹 서비스에 안성맞춤
- 2) 마이크로서비스: 여러 개의 작은 서비스들이 서로 사용자를 인증할 때, 서버 간에 상태를 공유할 필요 없이 토큰만 넘겨주면 돼서 너무 편리함.
- 3) OAuth 인증: Google이나 Facebook으로 로그인할 때 사용되는 OAuth의 핵심 기술
- 조심할 점: 신분증이 탈취되면 큰일남. 그래서 짧은 유효기간의 토큰(Access Token)과 이를 재발급받는 토큰(Refresh Token)을 함께 쓰는 전략이 일반적.
🤔 그래서, 언제 뭘 써야 할까
요 세녀석은 각자의 장단점이 명확해서, 웹 서비스의 규모, 복잡성, 그리고 가장 중요한 보안 요구사항에 따라 현명하게 선택해야합니다.
- 가장 전통적이고 안정적인 로그인: 세션이 답이죠. 서버가 모든 상태를 관리해서 보안 측면에서 강점이 있음.
- 최신 웹/모바일 앱, 분산 시스템: JWT가 좋음. 서버 부담을 줄이고 확장에 유리하지만, 토큰 탈취에 대한 보안 전략이 필수.
- 간단한 정보 저장이나 세션/JWT ID 전달: 쿠키는 여전히 쓸만함.
근데 세션의 질문 부분에서 말씀드렸지만, 세션 쓸때도 쿠키가 쓰이고, JWT 쓸때도 이게 쿠키를 활용하거등요. 그래서 결국 이 셋은 웹 개발에서 서로 협력하며 시너지를 내는 느낌이라, 이번 글을 통해 셋 다 알아두시면 좋을 것 같습니다.
'웹개발' 카테고리의 다른 글
WAI-ARIA와 웹 접근성 (0) | 2025.02.19 |
---|---|
DTD가 뭐에요?(feat. !DOCTYPE html) (0) | 2025.02.19 |
포트(Port)는 무엇일까? (2) | 2025.01.18 |
GET 방식에서 URL에 데이터를 전달하는 두 가지 방법 : params, query (0) | 2025.01.18 |
GET 방식과 POST 방식 차이(feat. REST) (0) | 2025.01.18 |