HTTP 쿠키 사용하기

쿠키(웹 쿠키 또는 브라우저 쿠키라고도 불려요)는 서버가 사용자의 웹 브라우저로 보내는 작은 데이터 조각이에요. 브라우저는 쿠키를 저장하고, 새로운 쿠키를 만들고, 기존 쿠키를 수정하고, 나중에 같은 서버로 보내는 요청에 이 쿠키들을 다시 보낼 수 있어요. 쿠키는 웹 애플리케이션이 제한된 양의 데이터를 저장하고 상태 정보를 기억할 수 있게 해줘요. 기본적으로 HTTP 프로토콜은 상태를 유지하지 않거든요.

이 문서에서는 쿠키의 주요 사용 사례를 살펴보고, 쿠키를 사용하는 모범 사례를 설명하며, 쿠키의 프라이버시 및 보안 영향에 대해 알아볼 거예요.

이 문서의 내용

• 쿠키가 사용되는 용도
• 쿠키 생성, 제거 및 업데이트
• 보안
• 프라이버시와 추적
• 쿠키 관련 규정
• 참고 자료

쿠키가 사용되는 용도

일반적으로 서버는 HTTP 쿠키의 내용을 사용해서 서로 다른 요청들이 같은 브라우저/사용자로부터 왔는지 판단하고, 그에 따라 개인화된 응답이나 일반적인 응답을 보내요. 다음은 기본적인 사용자 로그인 시스템을 설명하는 예시예요:

1. 사용자가 로그인 자격 증명을 서버로 보내요. 예를 들어 폼 제출을 통해서요.
2. 자격 증명이 올바르다면, 서버는 사용자가 로그인했다는 것을 나타내도록 UI를 업데이트하고, 브라우저에 로그인 상태를 기록하는 세션 ID를 담은 쿠키로 응답해요.
3. 나중에 사용자가 같은 사이트의 다른 페이지로 이동하면, 브라우저는 세션 ID를 담은 쿠키를 해당 요청과 함께 보내서 여전히 사용자가 로그인되어 있다고 생각한다는 것을 알려줘요.
4. 서버는 세션 ID를 확인하고, 여전히 유효하다면 사용자에게 새 페이지의 개인화된 버전을 보내줘요. 유효하지 않다면 세션 ID가 삭제되고 사용자에게는 일반 버전의 페이지가 표시되거나(또는 "접근 거부" 메시지가 표시되고 다시 로그인하라는 요청을 받을 수도 있어요).

쿠키는 주로 세 가지 목적으로 사용돼요:

• 세션 관리: 사용자 로그인 상태, 장바구니 내용, 게임 점수, 또는 서버가 기억해야 하는 기타 사용자 세션 관련 세부 정보들이에요.
• 개인화: 표시 언어 및 UI 테마와 같은 사용자 환경 설정이에요.
• 추적: 사용자 행동을 기록하고 분석하는 거예요.

데이터 저장

웹 초기에 다른 옵션이 없을 때는 쿠키가 일반적인 클라이언트 측 데이터 저장 목적으로 사용됐어요. 하지만 이제는 웹 스토리지 API(localStorage와 sessionStorage) 그리고 IndexedDB와 같은 최신 저장소 API가 권장돼요.

이런 API들은 저장을 염두에 두고 설계됐고, 서버로 데이터를 전송하지 않으며, 저장 용도로 쿠키를 사용할 때의 다른 단점들도 없어요:

• 브라우저는 일반적으로 도메인당 최대 쿠키 개수(브라우저마다 다르지만 일반적으로 수백 개)와 쿠키당 최대 크기(보통 4KB)로 제한돼요. 저장소 API는 더 많은 양의 데이터를 저장할 수 있어요.
• 쿠키는 모든 요청과 함께 전송되므로 성능을 저하시킬 수 있어요(특히 느린 모바일 데이터 연결에서). 특히 설정된 쿠키가 많은 경우에 그래요.

참고:
저장된 쿠키(및 웹 페이지가 사용하는 다른 저장소)를 보려면 Firefox 개발자 도구의 스토리지 인스펙터나 Chrome 개발자 도구의 Application 패널을 사용할 수 있어요.

💡 강사 팁: 실무에서는 쿠키를 데이터 저장 용도로 사용하는 것은 정말 피해야 해요. 제가 초보 개발자들의 코드를 리뷰할 때 가장 많이 보는 실수 중 하나가 사용자 설정이나 장바구니 데이터를 쿠키에 저장하는 거예요. localStorage는 훨씬 간단하고 용량도 크며, 불필요한 네트워크 트래픽을 발생시키지 않아요. 쿠키는 오직 서버가 알아야 하는 정보만 저장하세요!

쿠키 생성, 제거 및 업데이트

HTTP 요청을 받은 후, 서버는 응답과 함께 하나 이상의 Set-Cookie 헤더를 보낼 수 있어요. 각각은 별도의 쿠키를 설정하죠. 쿠키는 다음과 같이 이름-값 쌍을 지정해서 설정돼요:

Set-Cookie: <cookie-name>=<cookie-value>

다음 HTTP 응답은 수신 브라우저에게 한 쌍의 쿠키를 저장하도록 지시해요:

HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: yummy_cookie=chocolate
Set-Cookie: tasty_cookie=strawberry

[page content]

참고:
다양한 서버 측 언어/프레임워크에서 Set-Cookie 헤더를 사용하는 방법을 알아보세요: PHP, Node.js, Python, Ruby on Rails.

새 요청이 만들어질 때, 브라우저는 보통 현재 도메인에 대해 이전에 저장된 쿠키를 Cookie HTTP 헤더 안에 담아서 서버로 다시 보내요:

GET /sample_page.html HTTP/2.0
Host: www.example.org
Cookie: yummy_cookie=chocolate; tasty_cookie=strawberry

제거: 쿠키의 수명 정의하기

쿠키가 삭제되어 더 이상 전송되지 않아야 하는 만료 날짜나 기간을 지정할 수 있어요. Set-Cookie 헤더에서 쿠키가 생성될 때 설정된 속성에 따라 쿠키는 영구 쿠키 또는 세션 쿠키가 될 수 있어요:

• 영구 쿠키는 Expires 속성에 지정된 날짜가 지나면 삭제돼요:

Set-Cookie: id=a3fWa; Expires=Thu, 31 Oct 2021 07:28:00 GMT;

또는 Max-Age 속성에 지정된 기간이 지나면 삭제돼요:

Set-Cookie: id=a3fWa; Max-Age=2592000

참고:
Expires가 Max-Age보다 더 오래됐지만, Max-Age가 오류가 덜 발생하고 둘 다 설정되어 있을 때 우선권을 가져요. 그 이유는 Expires 날짜와 시간을 설정할 때, 쿠키가 설정되는 클라이언트를 기준으로 하기 때문이에요. 서버가 다른 시간으로 설정되어 있으면 오류가 발생할 수 있어요.

• 세션 쿠키 – Max-Age나 Expires 속성이 없는 쿠키 – 는 현재 세션이 끝날 때 삭제돼요. 브라우저는 "현재 세션"이 끝나는 시점을 정의하는데, 일부 브라우저는 재시작할 때 세션 복원을 사용해요. 이로 인해 세션 쿠키가 무기한으로 지속될 수 있어요.

참고:
사이트에서 사용자를 인증하는 경우, 사용자가 인증할 때마다 세션 쿠키를 재생성하고 다시 보내야 해요. 이미 존재하는 쿠키라도요. 이 방법은 제3자가 사용자의 세션을 재사용할 수 있는 세션 고정 공격을 방지하는 데 도움이 돼요.

쿠키를 즉시 제거하려면 같은 이름, 경로, 도메인(지정된 경우)으로 쿠키를 다시 설정하고, Expires 속성을 과거 날짜로 설정하거나 Max-Age 속성을 0 또는 음수로 설정하세요. 이렇게 하면 브라우저에게 쿠키를 즉시 삭제하도록 지시해요. 예를 들어:

Set-Cookie: id=a3fWa; Max-Age=0

등록 가능한 도메인과 관련된 모든 쿠키를 Clear-Site-Data 응답 헤더를 사용해서 지울 수도 있어요.
예를 들어, https://foo.example.com/에서 전송된 다음 헤더는 example.com과 all.bar.example.com과 같은 모든 하위 도메인에서 전송된 모든 쿠키를 지울 거예요.

Clear-Site-Data: "cookies"

쿠키가 삭제된 후 재생성하도록 설계된 몇 가지 기술이 있어요. 이것들은 "좀비" 쿠키로 알려져 있어요. 이러한 기술은 사용자 프라이버시와 제어의 원칙을 위반하고, 데이터 프라이버시 규정을 위반할 수 있으며, 이를 사용하는 웹사이트를 법적 책임에 노출시킬 수 있어요.

💡 강사 팁: 제가 실무에서 가장 많이 본 실수 중 하나는 쿠키를 삭제할 때 Path나 Domain 속성을 빼먹는 거예요. 쿠키를 삭제하려면 설정할 때 사용했던 모든 속성을 정확히 똑같이 지정해야 해요. 그렇지 않으면 브라우저는 다른 쿠키로 인식하고 원래 쿠키는 그대로 남아있게 돼요!

쿠키 값 업데이트

HTTP를 통해 쿠키를 업데이트하려면, 서버는 기존 쿠키의 이름과 새 값으로 Set-Cookie 헤더를 보낼 수 있어요. 예를 들어:

Set-Cookie: id=new-value

여러 가지 이유로 이렇게 하고 싶을 수 있어요. 예를 들어 사용자가 환경 설정을 업데이트했고 애플리케이션이 클라이언트 측 데이터에 변경 사항을 반영하려는 경우예요(웹 스토리지와 같은 클라이언트 측 저장소 메커니즘으로도 할 수 있어요).

JavaScript를 통해 쿠키 업데이트하기

브라우저에서는 Document.cookie 속성이나 비동기 Cookie Store API를 통해 JavaScript로 새 쿠키를 만들 수 있어요. 아래의 모든 예시는 가장 널리 지원되고 확립된 옵션인 Document.cookie를 사용해요.

document.cookie = "yummy_cookie=chocolate";
document.cookie = "tasty_cookie=strawberry";

기존 쿠키에 접근해서 새 값을 설정할 수도 있어요:

console.log(document.cookie);
// logs "yummy_cookie=chocolate; tasty_cookie=strawberry"

document.cookie = "yummy_cookie=blueberry";

console.log(document.cookie);
// logs "tasty_cookie=strawberry; yummy_cookie=blueberry"

보안상의 이유로, 요청을 시작할 때 업데이트된 Cookie 헤더를 직접 보내서 쿠키 값을 변경할 수 없어요. 예를 들어 fetch()나 XMLHttpRequest를 통해서요.

JavaScript가 쿠키를 수정하는 것을 전혀 허용하지 않아야 하는 충분한 이유가 있어요. 쿠키를 생성할 때 HttpOnly 속성을 지정해서 JavaScript의 접근을 방지할 수 있어요. 자세한 내용은 보안 섹션을 참조하세요.

💡 강사 팁: Document.cookie API는 정말 사용하기 불편해요. 문자열 파싱을 직접 해야 하거든요. 실무에서는 js-cookie 같은 라이브러리를 사용하는 걸 추천해요. 훨씬 직관적이고 실수할 가능성이 적어요. 하지만 학습 단계에서는 직접 해보는 것도 좋은 경험이에요!

보안

쿠키에 정보를 저장할 때, 기본적으로 모든 쿠키 값은 최종 사용자가 볼 수 있고 변경할 수 있어요. 쿠키가 오용되는 것을 정말 원하지 않을 거예요. 예를 들어 나쁜 행위자가 접근/수정하거나 보내지 말아야 할 도메인으로 전송되는 거요. 잠재적인 결과는 짜증나는 것부터 – 앱이 작동하지 않거나 이상한 동작을 보이는 것 – 재앙적인 것까지 다양할 수 있어요. 예를 들어 범죄자가 세션 ID를 훔쳐서 다른 사람으로 로그인한 것처럼 보이게 하는 쿠키를 설정하고, 그 과정에서 은행이나 전자상거래 계정을 장악할 수 있어요.

다양한 방법으로 쿠키를 보호할 수 있는데, 이 섹션에서 검토할 거예요.

쿠키에 대한 접근 차단

Secure 속성과 HttpOnly 속성, 두 가지 방법 중 하나로 쿠키가 안전하게 전송되고 의도하지 않은 당사자나 스크립트에 의해 접근되지 않도록 할 수 있어요:

Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly

• Secure 속성이 있는 쿠키는 HTTPS 프로토콜을 통한 암호화된 요청에서만 서버로 전송돼요. 안전하지 않은 HTTP(localhost는 제외)로는 절대 전송되지 않아요. 즉, 중간자 공격자가 쉽게 접근할 수 없다는 뜻이죠. URL에 http:가 있는 안전하지 않은 사이트는 Secure 속성으로 쿠키를 설정할 수 없어요. 하지만 Secure가 쿠키의 민감한 정보에 대한 모든 접근을 막는다고 가정하지 마세요. 예를 들어, 클라이언트의 하드 디스크에 접근할 수 있는 사람(또는 HttpOnly 속성이 설정되지 않았다면 JavaScript)은 정보를 읽고 수정할 수 있어요.

• HttpOnly 속성이 있는 쿠키는 JavaScript로 접근할 수 없어요. 예를 들어 Document.cookie를 사용해서요. 서버에 도달했을 때만 접근할 수 있어요. 예를 들어 사용자 세션을 유지하는 쿠키는 HttpOnly 속성이 설정되어야 해요. JavaScript에서 사용할 수 있게 하는 것은 정말 안전하지 않아요. 이 예방 조치는 크로스 사이트 스크립팅(XSS) 공격을 완화하는 데 도움이 돼요.

참고:
애플리케이션에 따라, 쿠키에 민감한 정보를 직접 저장하는 대신 서버가 조회하는 불투명한 식별자를 사용하거나, JSON Web Tokens와 같은 대체 인증/기밀 유지 메커니즘을 조사하고 싶을 수 있어요.

💡 강사 팁: 제가 보안 감사를 할 때 가장 많이 발견하는 취약점 중 하나가 바로 HttpOnly를 설정하지 않은 세션 쿠키예요. 특히 JWT를 쿠키에 저장하면서 HttpOnly를 빼먹는 경우가 많아요. XSS 공격이 발생하면 이런 토큰들이 바로 탈취당할 수 있어요. 반드시 세션 관련 쿠키에는 HttpOnly를 설정하세요!

쿠키가 전송되는 위치 정의

Domain과 Path 속성은 쿠키의 범위를 정의해요. 즉, 쿠키가 전송되는 URL이 무엇인지요.

• Domain 속성은 어떤 서버가 쿠키를 받을 수 있는지 지정해요. 지정되면 지정된 서버와 그 하위 도메인에서 쿠키를 사용할 수 있어요. 예를 들어, mozilla.org에서 Domain=mozilla.org를 설정하면, developer.mozilla.org와 같은 하위 도메인에서도 쿠키를 사용할 수 있어요.

Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly; Domain=mozilla.org

Set-Cookie 헤더가 Domain 속성을 지정하지 않으면, 쿠키는 쿠키를 설정한 서버에서 사용할 수 있지만 그 하위 도메인에서는 사용할 수 없어요. 따라서 Domain을 지정하는 것이 생략하는 것보다 덜 제한적이에요.
참고로 서버는 Domain 속성을 자신의 도메인이나 상위 도메인으로만 설정할 수 있고, 하위 도메인이나 다른 도메인으로는 설정할 수 없어요.
예를 들어, 도메인이 foo.example.com인 서버는 속성을 example.com이나 foo.example.com으로 설정할 수 있지만, bar.foo.example.com이나 elsewhere.com으로는 설정할 수 없어요(쿠키는 여전히 bar.foo.example.com과 같은 하위 도메인으로는 전송되지만요).
자세한 내용은 잘못된 도메인을 참조하세요.

• Path 속성은 Cookie 헤더를 보내기 위해 요청된 URL에 존재해야 하는 URL 경로를 나타내요. 예를 들어:

Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly; Path=/docs

%x2F("/") 문자는 디렉토리 구분 기호로 간주되며, 하위 디렉토리도 일치해요. 예를 들어 Path=/docs를 설정하면, 다음 요청 경로들이 일치해요:

• /docs
• /docs/
• /docs/Web/
• /docs/Web/HTTP

하지만 다음 요청 경로들은 일치하지 않아요:

• /
• /docsets
• /fr/docs

참고:
path 속성을 사용하면 사이트의 여러 부분에 따라 브라우저가 전송하는 쿠키를 제어할 수 있어요.
이것은 보안 조치로 의도된 것이 아니며, 다른 경로에서 쿠키를 무단으로 읽는 것을 보호하지 않아요.

💡 강사 팁: Path 속성을 보안 메커니즘으로 착각하는 개발자들을 많이 봤어요. 예를 들어 /admin 경로에만 쿠키를 설정하면 안전하다고 생각하는데, JavaScript로 다른 경로에서도 접근할 수 있어요. Path는 단지 편의를 위한 거예요. 진짜 보안은 서버 측에서 처리해야 해요!

SameSite로 서드파티 쿠키 제어하기

SameSite 속성을 사용하면 서버가 쿠키가 크로스 사이트 요청과 함께 언제 전송될지 지정할 수 있어요. 즉, 서드파티 쿠키예요. 크로스 사이트 요청은 사이트(등록 가능한 도메인) 및/또는 스키마(http 또는 https)가 사용자가 현재 방문 중인 사이트와 일치하지 않는 요청이에요. 여기에는 다른 사이트에서 클릭한 링크로 사이트로 이동할 때 전송되는 요청과 임베드된 서드파티 콘텐츠가 전송하는 모든 요청이 포함돼요.

SameSite는 정보 유출을 방지하고 사용자 프라이버시를 보호하며 크로스 사이트 요청 위조 공격에 대한 일부 보호를 제공하는 데 도움이 돼요. 세 가지 가능한 값을 가져요: Strict, Lax, None:

• Strict는 브라우저가 쿠키의 출처 사이트에서 시작된 요청에 대한 응답으로만 쿠키를 보내도록 해요. 인증이나 쇼핑 카트 정보 저장과 같이 항상 초기 탐색 뒤에 있는 기능과 관련된 쿠키가 있을 때 사용해야 해요.

Set-Cookie: cart=110045_77895_53420; SameSite=Strict

참고:
민감한 정보에 사용되는 쿠키는 짧은 수명을 가져야 해요.

• Lax는 비슷하지만, 사용자가 쿠키의 출처 사이트로 이동할 때도 브라우저가 쿠키를 보내요(사용자가 다른 사이트에서 온 경우라도). 사이트 표시에 영향을 미치는 쿠키에 유용해요. 예를 들어 웹사이트에 제휴 링크와 함께 파트너 제품 정보가 있을 수 있어요. 해당 링크를 따라 파트너 웹사이트로 이동하면, 제휴 링크를 따랐다는 쿠키를 설정하여 보상 배너를 표시하고 제품을 구매하면 할인을 제공할 수 있어요.

Set-Cookie: affiliate=e4rt45dw; SameSite=Lax

• None은 쿠키가 원본 요청과 크로스 사이트 요청 모두에서 전송되도록 지정해요. 다른 사이트에 임베드된 서드파티 콘텐츠에서 만든 요청과 함께 쿠키를 보내려는 경우 유용해요. 예를 들어 광고 기술이나 분석 제공업체요. SameSite=None이 설정되면 Secure 속성도 설정되어야 해요. SameSite=None은 보안 컨텍스트가 필요하거든요.

Set-Cookie: widget_session=7yjgj57e4n3d; SameSite=None; Secure; HttpOnly

SameSite 속성이 설정되지 않으면, 쿠키는 기본적으로 Lax로 처리돼요.

💡 강사 팁: SameSite 속성은 최근 몇 년간 보안에서 가장 중요한 발전 중 하나예요. 예전에는 CSRF 공격을 막기 위해 토큰을 사용하는 등 복잡한 방법을 써야 했는데, 이제는 SameSite=Strict만 설정하면 대부분의 CSRF 공격을 막을 수 있어요. 다만 사용자 경험에 영향을 줄 수 있으니 신중하게 선택해야 해요!

쿠키 접두사

쿠키 메커니즘의 설계상 서버는 쿠키가 보안 출처에서 설정되었는지 확인할 수 없고, 심지어 쿠키가 원래 어디서 설정되었는지조차 알 수 없어요.

하위 도메인의 애플리케이션은 Domain 속성으로 쿠키를 설정할 수 있고, 이를 통해 다른 모든 하위 도메인에서 해당 쿠키에 접근할 수 있게 해요. 이 메커니즘은 세션 고정 공격에서 악용될 수 있어요.

심층 방어 수단으로 쿠키 접두사를 사용해서 지원하는 사용자 에이전트에서 쿠키 속성에 특정 제한을 부과할 수 있어요. 모든 쿠키 접두사는 이중 밑줄(__)로 시작하고 대시(-)로 끝나요. 네 가지 접두사를 사용할 수 있어요:

• __Secure-: __Secure-로 시작하는 이름을 가진 쿠키는 보안 페이지(HTTPS)에서 Secure 속성과 함께 설정되어야 해요.
• __Host-: __Host-로 시작하는 이름을 가진 쿠키는 보안 페이지(HTTPS)에서 Secure 속성과 함께 설정되어야 해요. 또한 Domain 속성이 지정되면 안 되고, Path 속성은 /로 설정되어야 해요. 이렇게 하면 이러한 쿠키가 해당 쿠키를 설정한 호스트로만 전송되고 도메인의 다른 호스트로는 전송되지 않는 것이 보장돼요. 또한 해당 호스트 전체에 설정되고 해당 호스트의 어떤 경로에서도 재정의될 수 없도록 보장해요. 이 조합은 출처를 보안 경계로 취급하는 데 가능한 한 가까운 쿠키를 생성해요.
• __Http-: __Http-로 시작하는 이름을 가진 쿠키는 보안 페이지(HTTPS)에서 Secure 플래그와 함께 설정되어야 하고, 또한 HttpOnly 속성이 설정되어 Set-Cookie 헤더를 통해 설정되었다는 것을 증명해야 해요(Document.cookie나 Cookie Store API와 같은 JavaScript 기능을 통해 설정하거나 수정할 수 없어요).
• __Host-Http-: __Host-Http-로 시작하는 이름을 가진 쿠키는 보안 페이지(HTTPS)에서 Secure 플래그와 함께 설정되어야 하고, HttpOnly 속성이 설정되어 Set-Cookie 헤더를 통해 설정되었다는 것을 증명해야 해요. 또한 __Host- 접두사 쿠키와 동일한 제한 사항도 있어요. 이 조합은 HTTP 요청으로 범위가 제한되어 있음을 개발자와 서버 운영자가 알면서 출처를 보안 경계로 취급하는 데 가능한 한 가까운 쿠키를 생성해요.

브라우저는 이러한 접두사가 있는 쿠키가 제한 사항을 준수하지 않으면 거부할 거예요. 애플리케이션 서버는 사용자가 인증되었는지 또는 CSRF 토큰이 올바른지 판단할 때 특정 쿠키 이름만 확인하므로, 이것은 사실상 세션 고정에 대한 방어 수단으로 작동해요.

참고:
서버에서 웹 애플리케이션은 접두사를 포함한 전체 쿠키 이름을 확인해야 해요. 사용자 에이전트는 요청의 Cookie 헤더에서 쿠키를 보내기 전에 접두사를 제거하지 않아요.

쿠키 접두사와 브라우저 지원의 현재 상태에 대한 자세한 내용은 Set-Cookie 참조 문서의 접두사 섹션을 참조하세요.

💡 강사 팁: 쿠키 접두사는 상대적으로 최근에 추가된 기능이라 아직 많은 개발자들이 모르고 있어요. 하지만 보안에 정말 중요한 기능이에요. 특히 __Host- 접두사는 서브도메인 공격을 막는 데 매우 효과적이에요. 제가 보안 컨설팅을 할 때는 항상 세션 쿠키에 __Host- 접두사 사용을 권장해요!

프라이버시와 추적

앞서 SameSite 속성을 사용해서 서드파티 쿠키가 언제 전송되는지 제어하는 방법과 이것이 사용자 프라이버시를 보호하는 데 도움이 될 수 있다는 이야기를 했어요. 프라이버시는 웹사이트를 구축할 때 매우 중요한 고려 사항이에요. 제대로 하면 사용자와의 신뢰를 쌓을 수 있어요. 잘못하면 그 신뢰를 완전히 잃고 다른 온갖 문제를 일으킬 수 있어요.

서드파티 쿠키는 <iframe>을 통해 사이트에 임베드된 서드파티 콘텐츠에 의해 설정될 수 있어요. 사용자 프로필 정보 공유, 광고 노출 횟수 계산, 또는 여러 관련 도메인에 걸쳐 분석 수집과 같은 많은 합법적인 용도가 있어요.

하지만 서드파티 쿠키는 소름 끼치고 침입적인 사용자 경험을 만들 수도 있어요. 서드파티 서버는 여러 사이트에 접근할 때 같은 브라우저가 보내는 쿠키를 기반으로 사용자의 탐색 기록과 습관 프로필을 만들 수 있어요. 전형적인 예는 한 사이트에서 제품 정보를 검색하면 어디를 가든 유사한 제품 광고가 쫓아다니는 거예요.

브라우저 제조사들은 사용자들이 이런 행동을 좋아하지 않는다는 것을 알고 있어요. 그래서 모두 기본적으로 서드파티 쿠키를 차단하거나, 적어도 그 방향으로 가는 계획을 세우고 있어요. 서드파티 쿠키(또는 그냥 추적 쿠키)는 다른 브라우저 설정이나 확장 프로그램에 의해서도 차단될 수 있어요.

참고:
쿠키 차단은 일부 서드파티 구성 요소(예: 소셜 미디어 위젯)가 의도한 대로 작동하지 않게 만들 수 있어요. 브라우저가 서드파티 쿠키에 더 많은 제한을 가하면서, 개발자들은 서드파티 쿠키에 대한 의존도를 줄이는 방법을 찾기 시작해야 해요.

서드파티 쿠키, 그것과 관련된 문제, 그리고 어떤 대안이 있는지에 대한 자세한 정보는 서드파티 쿠키 문서를 참조하세요. 프라이버시 일반에 대한 자세한 정보는 프라이버시 랜딩 페이지를 참조하세요.

💡 강사 팁: 서드파티 쿠키의 종말은 웹 개발에서 가장 큰 변화 중 하나예요. Google Analytics, Facebook Pixel 등 우리가 당연하게 여기던 많은 도구들이 영향을 받고 있어요. 앞으로는 서버 측 추적이나 First-Party 데이터 수집 같은 대안적인 방법들을 배워야 할 거예요. 이미 많은 기업들이 이런 전환을 준비하고 있어요!

쿠키 관련 규정

쿠키 사용을 다루는 법률이나 규정은 다음과 같아요:

• 유럽연합의 일반 데이터 보호 규정(GDPR)
• EU의 ePrivacy 지침
• 캘리포니아 소비자 프라이버시법

이러한 규정은 전 세계적인 범위를 가져요. 이러한 관할권(EU와 캘리포니아, 단 캘리포니아 법은 총수익이 2,500만 달러 이상인 기업 등에만 적용됨)의 사용자가 접근하는 월드 와이드 웹의 모든 사이트에 적용돼요.

이러한 규정에는 다음과 같은 요구 사항이 포함돼요:

• 사이트가 쿠키를 사용한다는 것을 사용자에게 알리기.
• 사용자가 일부 또는 모든 쿠키를 받지 않도록 선택할 수 있게 하기.
• 사용자가 쿠키를 받지 않고도 서비스의 대부분을 사용할 수 있게 하기.

지역에 따라 쿠키 사용을 관리하는 다른 규정이 있을 수 있어요. 이러한 규정을 알고 준수하는 것은 여러분의 책임이에요. 이러한 규정을 준수하는 데 도움이 되는 "쿠키 배너" 코드를 제공하는 회사들이 있어요.

참고:
회사는 투명성을 위해 그리고 규정을 준수하기 위해 사이트에서 사용하는 쿠키 유형을 공개해야 해요. 예를 들어 Google이 사용하는 쿠키 유형에 대한 공지와 Mozilla의 웹사이트, 커뮤니케이션 및 쿠키 프라이버시 공지를 참조하세요.

💡 강사 팁: GDPR 준수는 정말 중요해요. 벌금이 엄청나거든요(연 매출의 4% 또는 2천만 유로 중 큰 금액). 쿠키 배너를 구현할 때 많은 개발자들이 실수하는 게, 단순히 배너만 보여주고 실제로는 사용자의 선택을 존중하지 않는 거예요. 사용자가 거부하면 정말로 추적 쿠키를 설정하지 말아야 해요. Cookiebot, OneTrust 같은 전문 솔루션을 사용하는 것도 좋은 방법이에요!

참고 자료

• 관련 HTTP 헤더: Set-Cookie, Cookie
• 관련 JavaScript API: Document.cookie, Navigator.cookieEnabled, Cookie Store API
• 서드파티 쿠키
• 쿠키 명세: RFC 6265
• 쿠키, GDPR 및 ePrivacy 지침