브라우저의 Cookie는 무엇이고 언제 어떻게 써야 할까
프론트엔드 개발을 하다 보면 쿠키는 거의 언젠가 반드시 만나게 됩니다.
- 로그인 상태를 유지할 때
- 사용자 식별 정보를 잠깐 기억할 때
- 서버가 브라우저에 상태를 심어둘 때
HttpOnly,SameSite,Secure같은 옵션을 볼 때
그런데 쿠키는 이름은 익숙해도, 실제로는 생각보다 헷갈리는 개념이 많습니다.
document.cookie로 읽는 쿠키와 서버가 내려주는 쿠키는 무엇이 다른지- 왜 어떤 쿠키는 자바스크립트에서 읽히고 어떤 쿠키는 안 읽히는지
Expires,Max-Age,Path,Domain은 정확히 무엇을 바꾸는지- 왜 인증에서는 쿠키를 쓰면서도
CSRF를 같이 이야기하는지
이 글에서는 브라우저의 Cookie를 아래 흐름으로 정리해보겠습니다.
- 쿠키는 무엇인지
- 브라우저와 서버가 쿠키를 어떻게 주고받는지
- 주요 속성은 무엇인지
- 언제 쓰면 좋고 언제는 조심해야 하는지
한눈에 보면
먼저 짧게 정리하면 이렇습니다.
- 쿠키는 브라우저가 저장하고 요청에 함께 보낼 수 있는 작은 상태 조각입니다.
- 서버는
Set-Cookie로 쿠키를 내려주고, 브라우저는 이후 요청에Cookie헤더로 보냅니다. - 자바스크립트에서는
document.cookie로 일부 쿠키만 읽고 쓸 수 있습니다. HttpOnly,Secure,SameSite는 보안상 특히 중요한 속성입니다.- 쿠키는 브라우저와 서버 사이 상태를 이어주는 데 강하지만, 자동 전송 특성 때문에 보안 설계가 같이 필요합니다.
즉, 쿠키는 단순 문자열 저장소가 아니라 브라우저와 서버가 상태를 주고받는 오래된 기본 메커니즘에 가깝습니다.
쿠키는 정확히 무엇일까?
가장 단순하게 말하면 쿠키는 브라우저가 저장하는 작은 key-value 데이터입니다.
예를 들어:
sessionId=abc123
theme=dark
locale=ko같은 값이 쿠키가 될 수 있습니다.
중요한 점은 이 데이터가 단순히 브라우저에만 저장되는 것이 아니라, 조건이 맞으면 요청과 함께 서버로 자동 전송될 수 있다는 점입니다.
즉, 쿠키는 localStorage처럼 단순 저장소라기보다 HTTP 요청 흐름과 연결된 브라우저 저장 방식입니다.
쿠키는 누가 만들까?
보통 두 가지 경로가 있습니다.
1. 서버가 Set-Cookie로 내려주는 경우
예를 들어 서버 응답 헤더는 이렇게 생길 수 있습니다.
Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure; SameSite=Lax이 경우 브라우저는 이 쿠키를 저장하고, 이후 조건이 맞는 요청에 함께 보냅니다.
2. 자바스크립트가 document.cookie로 쓰는 경우
예를 들어:
document.cookie = 'theme=dark; Path=/';이렇게 브라우저 스크립트가 직접 쿠키를 쓸 수도 있습니다.
하지만 여기서 중요한 차이가 있습니다. 자바스크립트가 쓸 수 있는 쿠키와, 서버만 다룰 수 있는 쿠키는 완전히 같지 않다는 점입니다.
Set-Cookie와 document.cookie는 무엇이 다를까?
이 부분이 실무에서 매우 중요합니다.
Set-Cookie
- 서버 응답 헤더에서 내려줍니다
- 인증 관련 쿠키를 설정할 때 자주 씁니다
HttpOnly같은 중요한 속성을 줄 수 있습니다
document.cookie
- 브라우저 자바스크립트에서 접근합니다
- 자바스크립트로 읽고 쓸 수 있는 쿠키만 다룰 수 있습니다
HttpOnly쿠키는 읽을 수 없습니다
즉, 인증처럼 민감한 정보는 보통 서버가 Set-Cookie로 내려주고, 자바스크립트는 그 값을 직접 읽지 못하게 만드는 방향이 더 자주 나옵니다.
브라우저는 쿠키를 어떻게 보내나?
서버가 쿠키를 내려준 뒤, 조건이 맞으면 브라우저는 이후 요청에 Cookie 헤더를 붙입니다.
예를 들어:
Cookie: sessionId=abc123; theme=dark즉, 쿠키의 핵심은 저장 그 자체보다 브라우저가 요청에 자동으로 붙일 수 있다는 점입니다.
이 자동 전송 특성 때문에:
- 로그인 세션 유지에 편하고
- 브라우저 중심 인증과 잘 맞지만
CSRF같은 보안 관점도 같이 봐야 합니다
document.cookie는 왜 불편하게 느껴질까?
한 번 읽어보면 이유를 금방 알 수 있습니다.
console.log(document.cookie);
// "theme=dark; locale=ko"문자열 하나로 들어오기 때문입니다.
즉:
- key별로 구조화된 객체가 아니라
- 세미콜론으로 이어진 문자열로 다뤄야 합니다
쓰기 역시 대입 방식입니다.
document.cookie = 'theme=dark; Path=/';이 문장은 "쿠키 전체를 덮어쓴다"기보다, 하나의 쿠키를 설정하는 동작에 가깝습니다.
그래서 document.cookie는:
- 읽기도 번거롭고
- 파싱도 직접 해야 하고
- 실수하기도 쉽습니다
즉, Cookie는 널리 쓰이지만, 자바스크립트 API 자체는 현대적인 의미에서 아주 편한 편은 아닙니다.
주요 속성은 무엇을 의미할까?
쿠키를 이해할 때 가장 중요한 부분입니다.
1. Expires
만료 시각을 절대 시점으로 지정합니다.
Expires=Wed, 21 Oct 2026 07:28:00 GMT즉, 이 시간이 지나면 쿠키가 만료됩니다.
2. Max-Age
현재 시점부터 몇 초 동안 유지할지 지정합니다.
Max-Age=3600즉, 1시간 뒤 만료 같은 식의 상대 시간 표현입니다.
실무에서는 Expires와 함께 보기도 하지만, 의미를 분리해서 이해하면 좋습니다.
Expires: 절대 시각Max-Age: 상대 시간
3. Path
어떤 경로에서 이 쿠키를 보낼지 정합니다.
Path=/예를 들어 /admin 경로에서만 유효한 쿠키처럼 범위를 제한할 수 있습니다.
즉, Path는 쿠키의 경로 적용 범위에 가깝습니다.
4. Domain
어떤 도메인 범위까지 쿠키를 보낼지 정합니다.
예를 들어:
Domain=example.com이 값은 서브도메인 정책과도 연결되기 때문에 신중하게 봐야 합니다.
즉, Domain은 쿠키의 도메인 적용 범위에 가깝습니다.
5. Secure
HTTPS 연결에서만 쿠키를 보내게 합니다.
즉, 민감한 쿠키는 보통 Secure를 함께 보는 편이 맞습니다.
6. HttpOnly
이 옵션이 붙은 쿠키는 자바스크립트에서 읽을 수 없습니다.
즉:
document.cookie로 보이지 않고- XSS가 있어도 쿠키 문자열을 직접 꺼내가기 어려워집니다
그래서 인증용 쿠키에서 매우 중요합니다.
7. SameSite
쿠키가 어떤 cross-site 요청에 포함될지 제어하는 속성입니다.
대표적으로:
StrictLaxNone
같은 값을 가집니다.
이 속성은 CSRF와 아주 깊게 연결됩니다.
즉, SameSite는 단순 편의 옵션이 아니라 브라우저 자동 전송 범위를 조절하는 보안 옵션이라고 보는 편이 맞습니다.
session cookie와 persistent cookie는 무엇이 다를까?
이 구분도 자주 나옵니다.
session cookie
명시적인 만료 정보가 없고, 브라우저 세션에 더 가깝게 유지됩니다.
persistent cookie
Expires나 Max-Age가 있어 일정 기간 유지됩니다.
즉:
- 브라우저 세션 동안만 잠깐 필요한 값
- 다시 방문해도 유지할 값
을 구분해 설계할 수 있습니다.
쿠키는 언제 잘 맞을까?
대표적으로 아래 상황입니다.
1. 로그인 세션 유지
브라우저가 요청에 자동으로 인증 쿠키를 붙이는 구조는 웹 앱과 잘 맞습니다.
2. 서버가 상태를 브라우저에 심어야 할 때
예를 들어:
- 세션 식별자
- CSRF 토큰 일부 전략
- 국가/언어 설정
같은 값은 쿠키와 잘 맞을 수 있습니다.
3. 자바스크립트가 직접 읽을 필요 없는 값
특히 인증 관련 값은:
- 브라우저는 보내기만 하고
- 자바스크립트는 직접 읽지 않는 구조
가 더 자연스러울 수 있습니다.
즉, 쿠키는 서버-브라우저 간 상태 전달에 강합니다.
쿠키는 언제 조심해야 할까?
이 부분도 중요합니다.
1. 자동 전송 특성
쿠키는 편하지만, 자동으로 보내질 수 있습니다.
이 때문에:
SameSite- CSRF 방어
- origin/referer 검증
같은 설계가 함께 필요할 수 있습니다.
2. 자바스크립트에서 다루기 불편한 API
document.cookie는 문자열 기반이라 파싱이 번거롭고, 값 하나만 바꾸는 것도 직관적이지 않을 수 있습니다.
즉, 클라이언트에서 복잡한 상태 저장소처럼 쓰기엔 좋은 API가 아닙니다.
3. 용량과 구조의 한계
쿠키는 큰 데이터를 저장하는 용도가 아닙니다.
또한 요청마다 같이 전송될 수 있으므로, 불필요하게 큰 값을 넣는 것은 더 비효율적일 수 있습니다.
즉, 쿠키는 작고 필요한 값에 더 적합합니다.
Cookie와 Web Storage는 어떻게 다를까?
자주 비교되는 지점입니다.
쿠키
- 요청에 자동으로 포함될 수 있음
- 서버와 상태를 주고받는 데 강함
- 보안 속성(
HttpOnly,SameSite,Secure)이 중요
localStorage / sessionStorage
- 요청에 자동 포함되지 않음
- 자바스크립트가 직접 읽고 씀
- 브라우저 내부 상태 저장에 더 가까움
즉, 쿠키는 단순 브라우저 저장소라기보다 HTTP 흐름과 연결된 저장 방식이라는 점이 가장 큰 차이입니다.
React나 Next.js에서는 무엇을 조심해야 할까?
1. 브라우저와 서버의 역할 구분
쿠키는 서버에서도 다루고, 브라우저에서도 일부 다룰 수 있습니다.
즉, 어느 시점에 누가 쿠키를 읽고 쓰는지 구분해야 합니다.
2. document.cookie는 브라우저 전용
당연하지만 서버 환경에서는 바로 접근할 수 없습니다.
즉, 브라우저 실행 시점에만 안전합니다.
3. 인증 쿠키는 프론트엔드가 직접 읽지 않는 구조가 더 자연스러울 수 있다
특히 HttpOnly 쿠키 전략에서는 프론트엔드가 쿠키 값을 모른 채 요청만 보내는 흐름이 흔합니다.
즉, 인증 구조를 설계할 때 "`쿠키 값을 읽어야 하나?"부터 다시 보는 편이 좋습니다.
자주 하는 실수
정리하면 아래 실수가 정말 자주 나옵니다.
- 쿠키를 단순 브라우저 저장소 정도로만 생각한다
HttpOnly,Secure,SameSite의미를 정확히 구분하지 않는다- 민감한 쿠키에
Secure나 적절한SameSite정책을 같이 두지 않는다 document.cookie로 모든 인증 흐름을 직접 제어하려 한다- 큰 데이터를 쿠키에 넣으려 한다
즉, 쿠키는 오래된 기술처럼 보여도 HTTP, 브라우저 자동 전송, 보안 속성을 함께 이해해야 제대로 다룰 수 있습니다.
실무 체크리스트
실제로 적용할 때는 아래 질문으로 빠르게 점검하면 도움이 됩니다.
- 이 값은 서버와 브라우저가 자동으로 주고받아야 하는가?
- 자바스크립트가 직접 읽어야 하는 값인가?
HttpOnly,Secure,SameSite정책이 명확한가?- 이 쿠키는 얼마나 오래 유지돼야 하는가?
- 굳이 쿠키보다
Web Storage가 더 맞는 값은 아닌가?
이 질문에 답하면 쿠키가 정말 필요한지, 그리고 어떤 속성 조합이 맞는지도 훨씬 선명해집니다.
정리하면
Cookie를 한 줄로 줄이면, 브라우저가 저장하고 조건이 맞는 요청에 자동으로 함께 보낼 수 있는 작은 상태 데이터입니다.
실무 기준으로 기억할 핵심은 이렇습니다.
- 쿠키는 서버-브라우저 상태 연결에 강하고
Set-Cookie와document.cookie는 역할이 다르며HttpOnly,Secure,SameSite는 특히 중요한 보안 속성이고- 클라이언트 상태 저장소처럼 남용하기보다 작은 상태와 인증 흐름에 맞게 쓰는 편이 좋습니다
쿠키는 오래된 기술이지만, 여전히 브라우저와 서버가 상태를 주고받는 핵심 메커니즘입니다. 그래서 이 개념을 제대로 이해하면 인증, 세션 유지, 보안 옵션, 브라우저 요청 흐름까지 훨씬 자연스럽게 연결해서 볼 수 있게 됩니다.
