JWT는 어디에 저장해야 하나 — localStorage vs HttpOnly 쿠키 비교

1. JWT 저장 위치를 고민하게 되는 이유

1) 로그인 유지와 보안 사이의 균형

JWT저장은 프론트엔드와 백엔드를 함께 다루는 프로젝트에서 자주 고민하는 주제입니다. 로그인 상태를 오래 유지하고 싶으면서도, 토큰이 탈취되는 위험은 줄이고 싶기 때문입니다. 특히 웹 서비스가 단순한 정보 조회를 넘어서 결제, 개인정보, 관리자 기능까지 포함하게 되면 토큰보안에 대한 고민이 더 중요해집니다.

2) 왜 localStorage보안이 자주 검색되는가

많은 개발자가 처음에는 구현 편의성 때문에 localStorage를 떠올립니다. 하지만 localStorage보안은 XSS 공격과 연결해서 같이 살펴봐야 하는 경우가 많습니다. 브라우저에 저장된 값이 스크립트에 접근 가능한 구조이기 때문에, “편하게 저장해도 괜찮은가”라는 질문이 자연스럽게 따라오게 됩니다.

3) 이 글에서 비교할 내용

이 글에서는 JWT를 어디에 저장할지 고민할 때 가장 많이 비교되는 localStorage와 HttpOnly쿠키의 차이를 설명합니다. 각각 어떤 장단점이 있는지, 어떤 상황에서 더 적합한지, 그리고 실제로는 어떤 기준으로 선택하는 것이 좋은지 정리해보겠습니다. 마지막에는 토큰보안을 기준으로 어떤 선택이 현실적인지도 함께 살펴보겠습니다.

2. JWT를 localStorage에 저장하는 방식

1) 구현이 쉬워서 선택되는 경우가 많음

JWT저장을 처음 설계할 때 localStorage는 접근이 간단해서 많이 선택됩니다. 로그인 성공 후 받은 토큰을 저장해두고, 이후 API 요청 때마다 꺼내 쓰는 방식입니다. 프론트엔드에서 상태를 다루기 쉬워 개발 속도 측면에서는 장점이 있습니다.

2) localStorage보안에서 가장 큰 주의점

문제는 localStorage보안이 완전히 안전하다고 보기 어렵다는 점입니다. localStorage에 저장된 값은 자바스크립트로 읽을 수 있기 때문에, XSS가 발생하면 토큰이 그대로 노출될 수 있습니다. 즉, 페이지 내에 악성 스크립트가 주입되는 순간 JWT도 함께 유출될 수 있어 토큰보안 측면에서 약점이 생깁니다.

3) 적합한 상황과 한계

localStorage는 내부용 도구나 보안 민감도가 낮은 서비스에서 임시로 활용되는 경우가 있습니다. 다만 사용자 계정 정보나 권한이 중요한 서비스라면 localStorage보안만 믿고 가는 방식은 부담이 있을 수 있습니다. 또한 브라우저 탭 간 공유는 편하지만, 자동 만료 처리나 강제 로그아웃 제어는 별도 설계가 필요합니다.

3. HttpOnly 쿠키에 저장하는 방식

1) 브라우저가 대신 관리하는 구조

HttpOnly쿠키는 자바스크립트에서 직접 읽을 수 없도록 설정할 수 있어 JWT저장 방식 중 보안 관점에서 자주 언급됩니다. 토큰이 스크립트에 노출되지 않기 때문에, XSS 상황에서의 직접 탈취 위험을 줄이는 데 도움이 됩니다. 이 점 때문에 토큰보안을 우선하는 서비스에서 많이 검토됩니다.

2) 보안상 장점이 분명함

HttpOnly쿠키의 가장 큰 강점은 localStorage보안보다 스크립트 기반 탈취에 강하다는 점입니다. 여기에 Secure, SameSite 같은 옵션을 함께 적용하면 전송 경로와 교차 사이트 요청 위험도 함께 줄일 수 있습니다. 그래서 “토큰을 사용자가 직접 건드리지 못하게 관리하고 싶다”는 요구에 잘 맞는 편입니다.

3) 설계할 때 함께 고려할 점

다만 HttpOnly쿠키가 모든 문제를 자동으로 해결하는 것은 아닙니다. CSRF 대응, 도메인 설정, CORS 정책, 프론트와 백엔드의 인증 흐름을 함께 설계해야 합니다. 즉, JWT저장을 쿠키로 옮긴다고 끝나는 것이 아니라, 인증 전체 구조를 조금 더 정교하게 구성해야 하는 경우가 많습니다.

4. localStorage vs HttpOnly 쿠키 핵심 비교

1) 접근 방식의 차이

localStorage는 자바스크립트에서 직접 읽고 쓰는 방식이라 구현이 단순합니다. 반면 HttpOnly쿠키는 브라우저가 자동으로 관리하며, 스크립트 접근을 막을 수 있습니다. 이 차이 때문에 localStorage보안은 편의성 중심, HttpOnly쿠키는 토큰보안 중심으로 보는 경우가 많습니다.

2) 공격 위험의 차이

localStorage는 XSS에 취약해질 수 있다는 점이 가장 큰 단점입니다. 반면 HttpOnly쿠키는 XSS로 인한 직접 토큰 탈취 가능성을 낮추는 대신, CSRF 대응이 중요해집니다. 따라서 “어느 쪽이 무조건 안전하다”기보다, 어떤 공격을 더 신경 써야 하는지에 따라 선택이 달라집니다.

3) 개발과 운영의 차이

localStorage는 프론트엔드 상태 관리가 쉬워 초기 개발이 빠른 편입니다. HttpOnly쿠키는 서버와의 연동, 보안 옵션, 배포 환경까지 더 신경 써야 해서 처음엔 복잡하게 느껴질 수 있습니다. 하지만 운영 단계에서는 HttpOnly쿠키가 토큰보안 측면에서 더 선호되는 경우가 많습니다.

5. 어떤 상황에서 어떤 방식을 고려할까

1) 빠른 개발이 우선인 경우

프로토타입이나 내부 도구처럼 보안 요구가 상대적으로 낮고, 빠르게 기능을 만들어야 하는 상황이라면 localStorage가 선택되기도 합니다. 다만 이 경우에도 localStorage보안을 아예 무시하면 안 되고, XSS 방지와 입력값 검증은 기본으로 챙겨야 합니다. JWT저장은 단순 저장 문제가 아니라 전체 보안 구조와 연결된다는 점을 기억하는 것이 좋습니다.

2) 사용자 정보와 권한이 중요한 서비스

쇼핑몰, 대시보드, 관리자 페이지, 금융 관련 서비스처럼 계정 보호가 중요한 경우에는 HttpOnly쿠키가 더 적합한 편입니다. 특히 토큰보안을 우선해야 하는 서비스라면, 브라우저 스크립트에서 토큰이 직접 노출되지 않는 구조가 유리합니다. 이런 환경에서는 JWT저장 방식 자체보다 인증 흐름 전체를 안전하게 설계하는 것이 핵심입니다.

3) 프론트엔드와 백엔드가 분리된 경우

SPA 구조나 API 기반 서비스에서는 localStorage보안과 HttpOnly쿠키 방식이 모두 검토됩니다. 다만 프론트엔드와 백엔드가 다른 도메인에 있거나, CORS와 쿠키 정책이 복잡해지는 경우에는 추가 설계가 필요합니다. 이럴 때는 단순히 “어디에 저장할까”보다 “어떤 공격을 막고 싶나”를 먼저 정하는 것이 좋습니다.

6. 실무에서 자주 놓치는 포인트

1) 저장 위치보다 더 중요한 것

JWT저장은 눈에 보이는 선택지지만, 실제 보안은 토큰 수명, 갱신 방식, 로그아웃 처리와 함께 봐야 합니다. 만료 시간이 너무 길면 탈취 시 피해가 커지고, 갱신 토큰 관리가 허술하면 보안 수준이 떨어질 수 있습니다. 즉, localStorage보안이나 HttpOnly쿠키만으로 토큰보안을 판단하면 부족합니다.

2) XSS와 CSRF를 함께 생각하기

localStorage를 쓸 때는 XSS 방어가 특히 중요하고, HttpOnly쿠키를 쓸 때는 CSRF 방어를 함께 고려해야 합니다. 둘 중 하나를 고르면 나머지 위험이 사라지는 것이 아니라, 다른 유형의 위험을 더 의식해야 합니다. 따라서 보안 헤더, 입력 검증, CORS 설정 같은 기본 항목도 같이 점검하는 것이 좋습니다.

3) 서비스 구조에 맞는 선택이 필요함

정답은 한 가지가 아닙니다. 서비스 규모, 민감도, 운영 방식, 프론트와 백엔드 분리 여부에 따라 적절한 JWT저장 방식이 달라집니다. 그래서 개발 초기에는 구현 편의성만 보지 말고, 이후 유지보수와 보안 대응까지 고려해 선택하는 것이 현실적입니다.

7. 정리: 어떤 기준으로 선택하면 좋을까

1) 편의성과 보안 중 무엇이 우선인지 정하기

JWT저장을 고민할 때는 localStorage보안의 편의성과 HttpOnly쿠키의 토큰보안 중 어떤 기준이 더 중요한지 먼저 정하는 것이 좋습니다. 빠른 개발이 중요하면 localStorage를 검토할 수 있지만, 보안 민감도가 높다면 HttpOnly쿠키가 더 적합한 편입니다. 결국 선택은 기능보다 서비스 성격에 맞춰져야 합니다.

2) 직접 전화보다 구조적으로 관리되는 방식

인증 흐름을 운영할 때는 매번 사람이 직접 확인하는 방식보다, 브라우저와 서버가 정해진 규칙대로 처리하는 구조가 훨씬 안정적입니다. 직접 전화처럼 수동으로 상태를 확인하는 방식은 번거롭고 실수가 생기기 쉽지만, JWT저장과 쿠키 기반 인증은 일정한 규칙으로 관리할 수 있다는 차이가 있습니다. 다만 어떤 방식을 택하든 토큰보안은 결국 설계와 설정의 문제라는 점을 함께 봐야 합니다.

3) 선택이 어렵다면 기본 보안 점검부터

만약 지금 서비스의 JWT저장 방식이 적절한지 헷갈린다면, localStorage보안과 HttpOnly쿠키 중 하나만 고르기보다 현재 사이트의 HTTPS, 인증서, 보안 헤더, 쿠키 설정, 노출된 정보부터 점검해보는 것이 좋습니다. 이런 기본 상태를 먼저 확인하면 어떤 저장 방식이 더 맞는지 판단하기 쉬워집니다. 결국 JWT저장은 단독 결정보다 전체 토큰보안 전략의 일부로 보는 것이 가장 현실적인 접근입니다.