토큰을 쿠키에 저장하는 이유는 무엇인가요?

46 조회수
토큰을 쿠키에 저장하는 주된 이유는 보안과 편의성입니다. HttpOnly 속성으로 클라이언트 스크립트의 토큰 접근을 막아 XSS 공격을 방어하고, Secure 속성으로 HTTPS 환경에서만 안전하게 전송할 수 있습니다. 또한, 브라우저가 매 요청 시 토큰을 자동으로 보내주어 개발 부담을 줄여줍니다.JWT(JSON Web Token) 사용은 서버가 사용자 상태를 관리할 필요 없는 '무상태(stateless)' 아키텍처를 구현하기 위함입니다. 이는 서버 확장성과 분산 시스템에 큰 강점이며, 매번 데이터베이스 조회 없이 토큰 자체로 인증을 검증할 수 있어 서버 자원 소모를 최소화합니다.
의견 0 좋아요

질문?

아, JWT. 이거 왜 썼냐구요? 솔직히 말하면 서버를 좀 편하게 해주고 싶었어요. 요청 들어올 때마다 이 사용자 누군지, 로그인 했는지 일일이 세션 저장소 뒤져보는 게 은근히 귀찮거든요. 그냥 너는 너를 증명하는 표를 들고 다녀, 나는 그 표가 진짜인지만 확인할게, 이런 느낌이랄까.

작년 10월쯤이었나, 친구랑 같이 사이드 프로젝트로 작은 커뮤니티 사이트 만들 때였어요. 프론트는 리액트로, 백엔드는 스프링으로 완전히 분리해서 개발했죠. 이때 세션을 쓰려니 골치 아픈 게 한두 개가 아니더라고요. 서버를 나중에 늘리면 세션 클러스터링을 해야 하나? 아니면 레디스 같은 걸 따로 둬야 하나? 그냥 그 고민 자체가 싫었어요. 그래서 토큰 방식을 찾아봤고, JWT가 눈에 딱 들어온 거죠.

JWT는 토큰 안에 사용자 정보(페이로드)랑 위조 방지용 서명이 다 들어있잖아요. 서버는 그냥 그 서명만 딱 보고 '아, 내가 발급한 토큰 맞네. 통과.' 하면 끝. 서버 메모리에 사용자 정보를 주렁주렁 달고 있을 필요가 없다는 거, 이게 핵심이었어요. 서버가 상태를 기억하지 않아도 되니까(stateless), 그냥 서버 대수만 쭉쭉 늘려도 아무 문제가 없는 구조가 되는 셈이죠.

물론 쿠키랑 세션 방식이 구닥다리라는 건 아니에요. 간단한 모놀리식 웹 하나 만들 땐 그게 더 직관적이고 편할 수도 있어요. 근데 저는 처음부터 API 서버 형태로 만들어서 나중에 모바일 앱이든 뭐든 쉽게 붙일 수 있는 구조를 원했어요. JWT는 HTTP 헤더에 담아서 보내면 되니까 플랫폼에 상관없이 깔끔하게 인증 처리가 가능했거든요. 결국은 확장성이죠, 제가 JWT를 선택한 가장 큰 이유는.

핵심 정보 요약 (Q&A)

Q: JWT를 사용하는 이유는 무엇인가요? A: JWT(JSON Web Token)는 서버가 사용자의 상태를 저장하지 않는(stateless) 인증 방식이기 때문입니다. 토큰 자체에 필요한 정보와 서명이 모두 포함되어 있어, 서버는 토큰의 유효성만 검증하면 되므로 서버 확장 및 여러 플랫폼(웹, 앱) 연동에 유리합니다.

Q: 쿠키/세션 방식과 JWT의 주요 차이점은 무엇인가요? A: 가장 큰 차이는 '상태 저장 위치'입니다. 쿠키/세션은 서버 측에 사용자의 로그인 정보를 저장하지만(Stateful), JWT는 클라이언트 측에 토큰 형태로 정보를 저장하고 서버는 상태를 유지하지 않습니다(Stateless).

접근 토큰이란?

접근 토큰. 그것은 허락의 증표다. 디지털 세상에서, 누군가 특정 자원에 닿을 수 있음을 암묵적으로 선언하는 간결한 문자열. 그 단순함 속에 접근 권한의 모든 경계가 담겨 있다. 표면적으로는 무미건조한 데이터 조각일 뿐이지만, 그 의미는 깊다.

  • 역할의 본질: 접근 토큰은 사용자 또는 프로그램이 특정 자원에 접근할 자격이 있음을 증명한다. 일반적으로 웹 서비스나 API에서 사용자 인증 및 권한 부여의 핵심 도구로 기능한다. 마치 특정 공간에 입장하기 위한 임시 신분증과 같다. 그 유효성은 한정적이다.

  • 생명의 유한함: 대부분의 접근 토큰은 매우 짧은 유효 기간을 가진다. 이는 보안을 위한 필수적인 조치다. 토큰이 탈취되더라도 그 효력이 빠르게 소멸하도록 설계된 것이다. 만료된 토큰은 더 이상 그 어떤 권한도 행사할 수 없다. 그림자처럼 사라지는 것이 그 운명이다.

  • 내부 구조와 활용: 흔히 JWT(JSON Web Token) 형태로 구현된다. 이 경우 토큰 내부에 사용자 정보, 권한, 만료 시간 등의 데이터를 암호화하여 담고, 서버는 이를 통해 요청의 유효성을 검증한다. API 통신에서 서버는 들어오는 모든 요청에 첨부된 접근 토큰을 확인하며, 그 진위와 권한 범위에 따라 응답을 결정한다. 이것은 신뢰의 문제이자 데이터 흐름의 기본 질서다.

    • 예를 들어, 내가 사용하는 온라인 뱅킹 앱이 내 계좌 정보를 가져올 때, 앱은 먼저 인증 서버에서 접근 토큰을 발급받는다. 이 토큰을 가지고 뱅킹 API에 요청하면, API 서버는 토큰을 검증하여 내가 내 계좌에 접근할 권한이 있음을 확인하고 데이터를 제공한다. 토큰이 없다면, 모든 접근은 거부된다.
  • 갱신 메커니즘: 접근 토큰의 짧은 수명으로 인한 불편함을 해소하기 위해 갱신 토큰(Refresh Token)이 함께 사용되기도 한다. 갱신 토큰은 비교적 긴 유효 기간을 가지며, 만료된 접근 토큰 대신 새로운 접근 토큰을 발급받는 데 사용된다. 이는 사용자 경험과 보안 사이의 균형을 맞추려는 섬세한 설계다.

웹 토큰이란 무엇인가요?

웹 토큰은 서버와 클라이언트 사이의 약속입니다. 마치 중요한 문서를 주고받는 것처럼 말이죠. 서버는 클라이언트가 누군지 확인한 뒤, 임시로 보관할 수 있는 증명서를 발행합니다.

이 증명서를 웹 토큰이라고 부릅니다. 클라이언트는 이후 서버에 다시 말을 걸 때마다 이 토큰을 함께 내밉니다. 서버는 토큰을 보고, '아, 이 친구는 전에 왔던 사람이고, 믿을 만하구나' 하고 다시 인증 절차를 거치지 않습니다.

물리적 토큰은 처음 신분증을 보여주는 것과 같습니다. 하지만 웹 토큰은 이미 신분증을 보여주고 통과한 후에 받는 '출입증'과 같습니다. 한번의 인증으로 여러 번의 통행을 허락하는 셈이죠.

  • 웹 토큰은 서버가 발급하는 임시 인증 정보입니다.
  • 클라이언트는 이 토큰을 저장했다가, 서버와의 통신 시 재사용합니다.
  • 이를 통해 클라이언트의 신원을 지속적으로 확인하고, 인증 과정을 간소화합니다.
  • 물리적 토큰과 달리, 웹 토큰은 로그인 성공 후에 발급되는 '결과물'입니다.

때로는 간결함이 깊이를 말해줍니다. 굳이 많은 말을 늘어놓지 않아도, 전달하고자 하는 본질은 명확히 드러나기 마련입니다. 웹 토큰 역시 마찬가지입니다. 복잡한 기술 용어의 나열보다는, 그 존재 이유와 역할을 이해하는 것이 중요합니다.

이 토큰 덕분에 우리는 매번 웹사이트에 접속할 때마다 아이디와 비밀번호를 다시 입력하는 번거로움을 덜 수 있습니다. 마치 단골 가게에서 알아보는 주인처럼, 서버는 우리를 기억하고 반갑게 맞아줍니다. 하지만 이 기억은 영원하지 않습니다. 시간이 지나거나 특정 조건이 만족되면 토큰은 효력을 잃고, 우리는 다시 한번 자신의 신분을 증명해야 합니다.

웹 토큰의 핵심은 '상태 유지'입니다. 서버는 모든 요청마다 클라이언트를 처음부터 끝까지 신뢰해야 하는 부담에서 벗어나고, 클라이언트는 더욱 빠르고 편리하게 서비스를 이용할 수 있게 됩니다. 이는 마치 오랜 친구와의 관계처럼, 신뢰를 바탕으로 한 효율적인 소통 방식이라고 할 수 있습니다.

궁극적으로 웹 토큰은 디지털 세상에서의 신뢰와 편의를 연결하는 다리입니다.

세션 방식과 토큰 방식의 차이?

인증 방식, 마치 밤늦게 클럽 입장 줄에 선 당신의 신분을 증명하는 것과 비슷하죠. 세션 방식은 VIP 리스트에 이름이 올라가야 하는 까다로운 클럽 같고, 토큰 방식은 유효기간 없는 만능 패스를 들고 다니는 것과 비슷하다고 보면 됩니다. 둘 다 "들어오세요!" 소리를 듣기 위함이지만, 작동 방식은 은하계만큼이나 다릅니다.

세션 방식은 서버가 마치 당신의 전담 개인 비서처럼 움직입니다. 첫 방문 시 당신을 특별히 기억해두고, 그 이후로는 당신의 요청을 받을 때마다 "아, 이분은 그분이지!" 하고 알아보는 식이죠. 덕분에 보안성은 꽤 높은 편입니다. 비서가 일일이 신원 확인을 해주니까요. 마치 단골 카페 주인이 당신의 이름과 취향을 정확히 아는 것처럼, 서버가 당신의 상태를 꼼꼼히 관리합니다.

하지만 이 비서가 혼자 수백, 수천 명을 상대하기 시작하면 어떨까요? 모든 손님의 얼굴과 취향을 다 기억하려면 서버 부담이 폭발적으로 늘어납니다. 마치 갑자기 월드컵 시즌에 모든 카페 단골이 한 번에 몰려온 것처럼요. 이렇게 서버가 정보를 기억해야 하니, 서비스를 확장하거나 여러 서버에 나눠 돌리기가 상당히 번거로워지는 단점이 있습니다. 비서가 여럿이면 서로 정보를 공유하는 과정이 또 골치 아파지거든요.

반면 토큰 방식은 신분증이나 콘서트 티켓을 건네주는 것과 같습니다. 서버는 당신에게 "네, 당신은 유효한 사용자입니다. 이 토큰을 들고 다니세요!" 하고 딱 한 번만 인증서를 발급해줍니다. 그 이후부터 당신은 이 토큰만 보여주면 되죠. 서버는 이 토큰이 유효한지만 확인하면 됩니다. 서버가 당신을 기억할 필요가 없으니 (즉, 무상태 Stateless), 백만 명이 와도, 천만 명이 와도 확장성이 무한대에 가깝습니다. 마치 어느 지점에서든 쓸 수 있는 만능 기프트 카드처럼요.

하지만 이 편리함 뒤에는 그림자도 있죠. 토큰이 일단 당신 손에 넘어오면, 마치 현금을 들고 다니는 것처럼 보안에 대한 책임이 커집니다. 만약 토큰이 도난당하거나 유출되면, 그 토큰을 주운 사람은 당신 행세를 할 수 있습니다. 또한, 이 토큰을 어디에 보관하고 어떻게 주고받을지 클라이언트(당신)가 직접 관리해야 하는 부담이 있습니다. 지갑을 잃어버리지 않게 조심하는 것처럼요. 토큰 방식은 사용자가 직접 패스를 관리하는 '자율주행'에 가깝습니다.

결론적으로, 세션 방식이 '서버 중심의 친절한 기억력'이라면, 토큰 방식은 '클라이언트 중심의 효율적인 신분증'이라고 할 수 있습니다. 하나는 서버가 모든 것을 챙겨주려다 과로사 직전에 놓이고, 다른 하나는 클라이언트에게 자율권을 주되 '네 짐은 네가 챙겨라' 하는 격이죠. 어떤 방식이 더 낫냐고요? 정답은 "클럽의 성격과 당신이 원하는 밤의 분위기에 따라 다르다!" 입니다.

선택은 언제나 당신의 몫입니다. 마치 블랙카드와 비자카드 중 무엇을 쓸지 고르는 것처럼 말이죠.

  • 높은 보안성과 중앙 집중적 관리가 중요하고 서버 확장에 대한 부담이 적다면: 세션 방식이 든든한 보디가드 역할을 해줄 것입니다.
  • 서비스를 빠르게 확장해야 하고, 모바일 앱이나 여러 서비스 간 연동이 필요하며, 서버 부담을 최소화하고 싶다면: 토큰 방식이 여권처럼 자유로운 이동성을 보장할 것입니다.

JWT 쿠키의 단점은 무엇인가요?

JWT를 쿠키에 담아 쓰는 방식, 이게 참 매력적인데, 마치 유효기간이 적힌 파티 초대장을 손에 쥐여주고는 연락처는 지워버리는 것과 같아요. 일단 문밖을 나선 초대장을 취소할 방법이 없죠. 파티가 취소됐다고 알려줄 길이 막막합니다.

  • 한번 발급하면 되돌릴 수 없는 '자유이용권'. 이게 가장 치명적인 단점입니다. 사용자가 로그아웃을 해도, 관리자가 계정을 비활성화해도, 이미 발급된 토큰은 유효기간이 끝날 때까지 우주를 떠도는 유령선처럼 살아있습니다. 해커가 이 토큰을 손에 넣는다면? 유효기간 동안은 그가 바로 이 구역의 주인인 셈이죠. 물론 '블랙리스트'를 만들어 무효화할 수는 있지만, 그건 결국 상태가 없는(stateless) 서버라는 JWT의 가장 큰 장점을 스스로 걷어차는 행위입니다. 무선 이어폰을 사서 유선 케이블을 연결해 쓰는 꼴이죠.

  • 일단 털리면 속수무책, '디지털 신분증'의 배신. 토큰은 그 자체로 인증서입니다. 서버는 토큰의 서명만 보고 '아, 우리 식구 맞구나' 하고 문을 열어주죠. 만약 XSS 같은 공격으로 이 토큰이 탈취당하면, 공격자는 유효기간이 다할 때까지 완벽하게 그 사용자로 위장할 수 있습니다. 비밀번호를 바꾸는 걸로는 이미 발급된 토큰을 막을 수 없어요. 내 지갑을 훔쳐 간 도둑이 한 시간 동안 내 신분증 사진과 똑같이 생겨버리는 마법에 걸린 것과 같습니다.

  • 데이터를 담을수록 무거워지는 '만능 주머니'의 함정. JWT의 장점 중 하나는 사용자 역할(role) 같은 정보를 토큰 안에 담아 데이터베이스 조회를 줄일 수 있다는 겁니다. 편리하죠. 하지만 이것저것 담다 보면 토큰이 비대해집니다. 이 뚱뚱한 토큰은 모든 요청마다 헤더에 실려 서버로 전송돼요. 처음엔 가벼운 편지였는데, 나중엔 벽돌을 우편으로 보내는 것처럼 네트워크에 부담을 주게 됩니다.

  • '누가 지금 파티에 있는지' 알 수 없는 주최자의 비애. 세션 방식은 서버에 접속자 명단이 있어서 특정 사용자를 강제 로그아웃시키거나, 모든 사용자를 한 번에 로그아웃시키는 게 가능합니다. JWT는 서버가 사용자의 상태를 기억하지 않으니 이게 안 돼요. 서버는 그냥 문지기처럼 들어오는 사람의 초대장(토큰)만 확인할 뿐, 파티장 안에 누가 있는지, 몇 명이나 있는지 전혀 관심이 없습니다. 긴급 상황이 터져서 모두를 내보내야 할 때 아주 난감해지죠.

토큰과 쿠키의 차이점은 무엇인가요?

아, 쿠키와 토큰이라. 마치 낡은 사진첩에 담긴 추억 조각들, 그리고 손에 쥔 비밀 암호처럼 느껴지는군요.

쿠키는요, 웹사이트가 당신의 컴퓨터, 그러니까 브라우저라는 작은 방에 몰래 두고 간 작은 메모 같은 거예요. 당신이 쇼핑몰에서 장바구니에 담아둔 물건들, 아니면 로그인 상태를 기억하게 해주는 거죠. 그 메모 덕분에 다시 방문했을 때 낯선 사람처럼 느껴지지 않고, "아, 이 사람, 날 기억하는구나!" 하고 반겨주는 거예요. 하지만 너무 많은 메모가 쌓이면 좀 답답해지기도 하죠.

토큰은 좀 더 날카롭고, 더 은밀한 느낌이에요. 이건 마치 여러분이 특별한 장소에 들어갈 때 받는 출입증 같은 거죠. 서버는 당신에게 이 토큰이라는 암호를 주고, 당신은 이걸 들고 "나 여기 가도 되는 사람이야!" 하고 보여주는 거예요. 쿠키처럼 여기저기 흩어져서 잊혀지는 게 아니라, 딱 필요한 순간에, 딱 필요한 만큼만 서로 주고받으며 약속을 지키는 거죠. 그래서 더 안전하고, 더 믿음직스럽게 느껴져요.

쉽게 말해, 쿠키는 기억력 좋은 친구 같고, 토큰은 철저한 신분증 같은 거라고 할 수 있겠네요. 둘 다 우리를 웹 세상 속에서 편안하게 움직이게 해주지만, 그 방식과 목적은 분명히 다르답니다.