Akamai Bot Manager 쿠키는 Akamai가 클라이언트에 대해 이미 내린 판단을 기록해 두는 수단입니다. bm_sz가 가장 먼저, 보통 첫 HTML 응답에서 발급되며 약 4시간 유지됩니다. ak_bmsc와 bm_sv는 약 2시간짜리 짧은 세션 쿠키입니다. _abck는 영속 쿠키로 대개 1년 기한으로 설정되며, 브라우저의 클라이언트 측 검사가 승인되었는지를 기록합니다. 값은 암호화되어 있고 문서화되어 있지 않습니다. 쿠키에서 읽어 낼 수 있는 것은 어떤 쿠키를 보유하고 있는지, 쿠키가 언제 바뀌는지, 그리고 하나의 클라이언트와 하나의 IP에 계속 묶여 있는지입니다.
Akamai Bot Manager 쿠키 한눈에 보기
Akamai는 이 쿠키들의 필드별 사양을 공개하지 않습니다. 가장 신뢰할 수 있는 공개 정보는 쿠키 고지 문서로, Akamai의 제품 문서와 쿠키 페이지, 그리고 Bot Manager를 사용하는 사이트의 쿠키 정책이 여기에 해당합니다. 아래 표는 이를 종합한 것이며, 출처 간에 내용이 다른 경우 표에 그대로 적었습니다.
| 쿠키 | 고지 문서의 설명 | 일반적인 유효 기간 | HttpOnly 여부 | 주로 보이는 시점 |
|---|---|---|---|---|
bm_sz | Akamai Bot Management 서비스 지원 | 약 4시간 | 양쪽 모두 보고됨. Set-Cookie를 확인할 것 | 보호된 호스트의 첫 응답 |
_abck | 봇 탐지 / 사기 방지. 검증 상태를 담음 | 약 1년(영속) | 대체로 페이지 스크립트에서 읽을 수 있음(아래 참고) | 첫 응답에서 발급된 뒤 클라이언트 검사가 끝날 때마다 재작성 |
ak_bmsc | 사람과 봇을 구별. Akamai 자체 문서는 성능 쿠키라고도 설명 | 약 2시간 | Akamai Identity Cloud 문서는 HttpOnly: false로 기재. 일부 글은 true로 보고 | 세션 초반 |
bm_sv | "사람이 생성한 웹 요청과 봇이 생성한 웹 요청을 구별하는 데 도움을 주기 위해 Akamai Bot Manager가 사용" | 약 2시간 | Akamai Identity Cloud 문서는 HttpOnly: false, Secure: true로 기재 | 일부 배포 환경에서 세션 후반 |
bm_mi | Bot Management 지원(세부 내용 미공개) | 한 고지 문서에서는 약 2시간, 다른 곳은 제각각 | 문서화되지 않음 | 일부 배포 환경에서만 |
출처: RIPE NCC 쿠키 목록은 다섯 개 모두를 필수 쿠키로 분류하고 _abck는 1년, bm_sz는 4시간, ak_bmsc, bm_sv, bm_mi는 2시간으로 기재합니다. cookie.is도 _abck, bm_sz, ak_bmsc, bm_sv에 같은 유효 기간을 제시합니다. Akamai의 Identity Cloud 쿠키 표는 bm_sv 설명과 함께 ak_bmsc, bm_sv의 HttpOnly/Secure/SameSite 플래그를 제공합니다. Akamai 자체의 쿠키 설정 페이지는 _abck, ak_bmsc, bm_sv를 필수 쿠키로, bm_sz를 성능 쿠키로 분류합니다.
실무상 주의할 점이 두 가지 있습니다. 첫째, 이 속성들은 모두 배포 환경마다 설정되므로 위의 유효 기간은 일반적인 값일 뿐 보장되지 않습니다. 작업 대상 사이트의 실제 Set-Cookie 헤더를 확인하세요. 둘째, 최신 배포 환경에서는 DevTools에서 이름을 볼 수 있는 추가 쿠키가 설정되기도 합니다. 이에 대한 신뢰할 만한 공개 설명은 찾지 못해 여기서는 다루지 않습니다.
_abck: 판정을 담는 쿠키
_abck는 브라우저가 Akamai의 클라이언트 측 검사를 통과했는지를 반영하는 영속 쿠키입니다. 처음에는 미검증 상태로 발급되고, Bot Manager 스크립트가 보고할 때마다 서버가 다시 씁니다. 보통 만료 기한은 1년이지만, 그 안에 담긴 "검증됨" 상태는 쿠키 자체보다 훨씬 짧게 유지됩니다.
값은 물결표(~)로 구간이 나뉜 긴 암호화 문자열입니다. 사람들이 이야기하는 부분은 ~-1~, ~0~ 같은 짧은 마커뿐입니다. 아래 내용은 커뮤니티의 관찰로 받아들이세요. Akamai는 이 마커를 문서화한 적이 없으며, 상세한 분석 글 중 하나인 Scrapfly의 글은 값에서 고정된 필드를 추론하는 것 자체를 하지 말라고 분명히 권고합니다. 독립적인 출처들이 대체로 동의하는 해석은 다음과 같습니다.
- 앞쪽 위치의
~-1~: 클라이언트가 아직 클라이언트 측 검사를 충족하지 못한 상태입니다. 새로 발급된_abck가 이 상태이며, 받아들일 만한 텔레메트리가 끝내 도착하지 않으면 계속 이 상태로 남습니다. - 같은 위치의
~0~: 당분간 검사가 충족된 상태입니다. 흔히 페이지 스크립트에 텔레메트리 전송을 멈춰도 된다고 알리는 클라이언트 측 "중지 신호"로 설명됩니다. - 검증된 쿠키도 초기화될 수 있습니다. 보호된 엔드포인트는 로그인이나 결제 직전처럼 새
_abck를 발급해 미검증 상태로 되돌릴 수 있습니다.
Crawlex의 분석 글도 같은 해석을 제시하면서, 이것이 "전적으로 쿠키가 바뀌는 모습을 지켜본 사람들에게서" 나온 것임을 강조합니다. 중요한 결론은 ~0~이 무엇을 뜻하지 않는지입니다. 이것은 통행증이 아닙니다. Akamai는 여전히 모든 요청을 IP 평판, 프로토콜 핑거프린트, 요청 패턴으로 평가하며, 다른 클라이언트나 네트워크에서 제시된 ~0~ 쿠키는 실패할 수 있습니다. Akamai의 Bot Manager 빠른 시작 문서에는 Cookie Integrity Failed라는 탐지 항목이 있으며, 이는 "봇 운영자가 Bot Manager 쿠키를 변조하거나 복제하려 하지 않았음을 확인"합니다. 즉 복사한 _abck야말로 이 시스템이 잡아내도록 설계된 대상입니다.
페이지 스크립트가 이 마커를 읽어야 하므로 _abck는 대체로 HttpOnly가 아니며, 보통 document.cookie에서 볼 수 있습니다. 이에 대한 Akamai의 공식 언급은 찾지 못했으니 테스트하는 사이트에서 직접 확인하세요.
bm_sz: 세션의 시드
bm_sz는 보통 Bot Manager JavaScript가 실행되기도 전인, 보호된 호스트의 맨 첫 HTML 응답에서 설정되며 약 4시간 유지됩니다. Crawlex의 bm_sz 분석 같은 기술 문서는 이를 클라이언트 측 스크립트가 사용하는 세션별 입력값으로 설명합니다. 다른 세션이나 오리진의 bm_sz를 쓰면 이후 과정이 모두 깨지는 이유가 이것입니다. 클라이언트가 bm_sz를 전혀 받지 못했다면 보호된 페이지가 아예 Bot Manager를 거치지 않았을 가능성이 높으며, 디버깅할 때 알아 두면 유용합니다.
ak_bmsc: 수명이 짧은 세션 쿠키
ak_bmsc는 약 2시간짜리 세션 쿠키입니다. 고지 문서들은 사람과 봇을 구별하는 쿠키라고 설명하고, Akamai Identity Cloud 문서는 "성능 최적화에 사용"된다고도 설명합니다. HttpOnly 플래그에 대해서는 글마다 말이 다릅니다. Akamai의 Identity Cloud 표는 HttpOnly: false라고 하지만 여러 스크레이핑 블로그는 HttpOnly라고 하므로, 배포 환경마다 설정이 다른 것으로 보입니다. 세션 도중 사라졌다면 대개 2시간이 지났거나 클라이언트가 쿠키를 버린 것이 원인입니다.
bm_sv와 bm_mi
bm_sv는 Akamai가 직접 설명하는 유일한 쿠키입니다("사람이 생성한 웹 요청과 봇 또는 기타 자동화된 프로세스가 생성한 웹 요청을 구별하는 데 도움을 주기 위해 Akamai Bot Manager가 사용"). 약 2시간 유지됩니다. Akamai 빠른 시작 문서에는 "클라이언트에서 오는 HTML 페이지 요청과 AJAX 요청의 수를 센다"는 Session Validation 탐지 항목도 있습니다. 이름으로 보아 bm_sv와 관련이 있을 것 같지만 이를 확인해 주는 공개 자료는 없으니 그렇다고 단정하지 마세요. bm_mi는 일부 배포 환경의 고지 문서에 2시간 유효 기간으로 나올 뿐 그 이상의 설명은 없습니다.
센서 흐름의 개념적 구조
Bot Manager는 여러 계층으로 동작합니다. 엣지가 모든 요청을 개별적으로 평가하고, 브라우저 안의 JavaScript 계층이 클라이언트 측 증거를 더해 _abck에 기록합니다. Akamai 빠른 시작 문서는 주요 탐지 항목을 다음과 같이 제시합니다.
- 알려진 봇 사칭: 가짜 Googlebot 등.
- User-agent 기반 탐지와 요청 이상 탐지: 요청 내부의 불일치.
- 웹 스크레이퍼 평판: "최근 스크레이핑 활동을 한 IP 주소에 나쁜 평판 점수"를 부여.
- 쿠키 무결성, 세션 검증, 브라우저 검증: "요청이 실제 웹 브라우저에서 왔음을 확인".
- 행동 이상 탐지: Premier 전용으로, 로그인이나 결제 같은 트랜잭션 엔드포인트에 적용.
Akamai의 현재 탐지 방법 페이지도 같은 구분을 설명합니다. 투명(transparent) 탐지는 "순서가 어긋난 헤더와 브라우저 버전 불일치"를 잡아내고, 능동(active) 탐지는 "요청이 웹 브라우저에서 오는지 확인하기 위해 상호작용을 사용"합니다.
쿠키의 수명 주기는 이 설계에서 비롯됩니다.
- 보호된 호스트의 첫 응답이
bm_sz와 미검증_abck를 설정하고, 페이지가 Akamai 스크립트를 로드합니다. - 스크립트가 브라우저에서 클라이언트 신호(환경, 타이밍, 일부 페이지에서는 상호작용)를 수집해 같은 사이트의 퍼스트파티 엔드포인트로 전송합니다.
- Akamai가 전송된 데이터를 요청 수준 신호와 함께 평가하고,
_abck를 갱신하는Set-Cookie를 반환합니다. - 이후 요청에는 쿠키가 함께 전송됩니다. 엣지는 쿠키가 온전한지, 이 세션의 것인지, 그 밖에 관찰되는 내용과 들어맞는지 확인합니다.
다루지 않는 내용: 이 글은 센서 페이로드나 그 생성 방법, 쿠키 값을 만드는 방법을 설명하지 않습니다. Akamai 텔레메트리 위조는 Cookie Integrity를 비롯한 관련 탐지가 잡아내려는 바로 그 행위이며, 저희가 돕는 일이 아닙니다. TLS 및 HTTP/2 핑거프린트를 포함한 전체 신호 구성은 Akamai Bot Manager 심층 분석을 참고하세요.
HTTP 전용 클라이언트가 무효한 _abck에 갇히는 이유
requests, httpx, Go의 net/http 같은 HTTP 라이브러리는 JavaScript를 실행하지 않으므로 Bot Manager 스크립트가 실행되지 않고, _abck를 갱신하는 주체도 없습니다. 클라이언트는 첫 응답에서 받은 미검증 쿠키를 계속 보냅니다. Akamai가 브라우저 검증을 요구하는 페이지에서는 당연한 결과입니다.
TLS를 고쳐도 달라지지 않습니다. 임퍼소네이션 라이브러리는 핸드셰이크와 HTTP/2 프레임을 Chrome처럼 보이게 만들 수 있지만, 스크립트가 생성했을 클라이언트 측 증거는 만들어 내지 못합니다. 실제로는 보통 투명 계층만 쓰는 페이지는 계속 작동하고, 능동 검증이 필요한 페이지(로그인, 장바구니, 일부 사이트의 검색 API)는 403이나 챌린지 페이지를 반환하기 시작합니다.
도구를 고르기 전에 실제로 필요한 페이지가 무엇인지 따져 보세요. 공개 데이터 상당수는 능동 계층 없이도 얻을 수 있으며, 사이트의 공식 API나 데이터 피드가 브라우저 자동화보다 나은 해답인 경우도 많습니다.
깨끗하고 일관된 연결 위의 실제 브라우저는 무엇이 다른가
실제 브라우저는 스크립트를 실행하고, 쿠키를 유지하고, 일관된 TLS 및 HTTP/2 핑거프린트 하나를 보내며, 세션 내내 하나의 네트워크에 머뭅니다. 이 조합이 _abck를 검증 상태로 옮기고 그 상태를 유지시킵니다. 각 요소가 모두 중요합니다.
- 세션 내내 쿠키 저장소를 유지하세요. 요청 사이에 쿠키를 버리면 모든 요청이 첫 방문처럼 보입니다. 새
bm_sz, 미검증_abck가 발급되고 스크립트가 다시 실행되어야 합니다. Playwright에서는 브라우저 컨텍스트 하나가 쿠키 저장소 하나입니다. 페이지마다 새 컨텍스트를 열지 마세요. - 세션당 출구 IP를 하나로 유지하세요. 한 IP의 세션에 발급된 쿠키를 다른 IP에서 재사용하면 Cookie Integrity가 잡아내도록 설계된 복제처럼 보입니다. 세션 도중 IP를 교체하면 쿠키가 발급된 네트워크와 더 이상 일치하지 않습니다. 상태가 있는 작업(카테고리 탐색, 장바구니, 로그인 흐름)에는 sticky 세션을 쓰고, IP 교체는 세션과 세션 사이에만 하세요. 세션 길이를 정하는 방법은 sticky 세션과 로테이팅 세션 비교 가이드에서 다룹니다.
- 깨끗한 IP에서 시작하세요. 웹 스크레이퍼 평판은 IP 단위로 매겨집니다. 스크레이핑 이력이 있는 데이터센터 대역은 쿠키가 설정되기도 전에 의심받는 상태에서 출발합니다. 레지덴셜 IP와 모바일 IP는 평판 기준선이 서로 다르며, 이 점수가 어떻게 만들어지는지는 IP 평판 심층 분석에서 설명합니다.
- 사람이 할 법한 속도로 요청하세요. Session Validation은 말 그대로 클라이언트당 HTML 및 AJAX 요청 수를 셉니다. 1분에 수백 페이지를 요청하는 세션은 유효한
_abck가 있어도 살아남지 못합니다.
이 규칙을 지키는 최소한의 Playwright 설정은 다음과 같습니다. 영속 컨텍스트 하나, sticky 레지덴셜 출구 하나, 그리고 다음 실행이 처음부터 다시 시작하지 않고 같은 세션을 이어 가도록 상태를 저장합니다.
from pathlib import Path
from playwright.sync_api import sync_playwright
STATE = Path("state.json")
PROXY = {
"server": "http://gate.proxyhat.com:8080",
"username": "USERNAME-sid-abc123-ttl-10m", # sticky: 이 세션 동안 같은 출구 IP
"password": "PASSWORD",
}
with sync_playwright() as p:
browser = p.chromium.launch(proxy=PROXY)
context = browser.new_context(
storage_state=str(STATE) if STATE.exists() else None
)
page = context.new_page()
page.goto("https://www.example.com/", wait_until="load")
# ... 사람 속도로 적은 수의 페이지 이동 ...
names = sorted(c["name"] for c in context.cookies())
print(names) # 보유한 Akamai 쿠키 확인
context.storage_state(path=str(STATE)) # 다음 실행을 위해 쿠키 저장소 보존
browser.close()저장한 상태는 해당 세션 ID와 묶어 두세요. state.json을 다른 출구 IP로 이어서 쓰면 피하려던 IP 변경 문제를 그대로 재현하게 됩니다.
문제 해결: 증상, 예상 원인, 확인할 점
| 증상 | 예상 원인 | 확인할 점 |
|---|---|---|
| 맨 첫 요청부터 403 / "Access Denied", 쿠키 설정 없음 | 요청 수준 차단: IP 평판, 브라우저가 아닌 TLS/HTTP 핑거프린트, 헤더 이상 | 출구 IP의 유형과 이력, 클라이언트의 JA4 및 HTTP/2 핑거프린트, 헤더 순서 |
많은 요청을 보내도 _abck가 ~-1~ 상태에 머묾 | Bot Manager 스크립트가 실행되지 않거나 전송 데이터가 승인되지 않음 | JavaScript가 켜진 실제 브라우저를 쓰고 있는가? 광고 차단기나 요청 가로채기로 스크립트 요청이 막히지 않았는가? |
| 몇 페이지는 되다가 403 발생 | 요청 속도(Session Validation) 또는 보호된 엔드포인트의 _abck 초기화 | 세션당 분당 요청 수, 실패가 로그인·검색·장바구니 URL에 몰리는지 여부 |
요청마다 새 bm_sz를 받음 | 클라이언트가 쿠키를 버리거나 요청마다 새 컨텍스트를 엶 | 쿠키 저장소 유지 여부, 세션당 컨텍스트 하나 |
유효해 보이던 _abck가 IP 변경 후 작동하지 않음 | 한 IP에서 발급된 쿠키를 다른 IP에서 재사용 | sticky 세션이 설정되어 있는가? 프로바이더가 세션 도중 IP를 교체하지 않았는가? |
| 세션이 2시간 무렵에 끊김 | ak_bmsc / bm_sv 만료 | DevTools에서 쿠키 만료 시각 확인, 가장 짧은 유효 기간보다 짧게 세션 계획 |
| 같은 IP에서 headless 브라우저는 차단되고 headed 브라우저는 정상 | 브라우저 환경의 자동화 신호 | 프레임워크가 노출하는 자동화 플래그, 두 실행의 쿠키와 응답 비교 |
| 같은 코드가 로컬에서는 되는데 서버에서는 차단 | 데이터센터 IP 평판 또는 컨테이너의 다른 TLS 스택 | 두 환경의 JA4와 출구 IP 비교 |
한 번에 변수 하나씩 확인하세요. "Akamai에 막혔다"는 사례 대부분은 결국 처음 세 행 중 하나로 밝혀집니다. 도움은 안 되지만 정직한 답도 이 표에 포함되어야 합니다. 때로는 사이트가 해당 경로에서 자동화 트래픽을 제공하지 않기로 결정한 것이며, 이때 올바른 대응은 중단하거나 접근 권한을 요청하는 것입니다.
사이트 운영자를 위해: 자체 로그에서 이 쿠키 읽기
Bot Manager를 운영한다면 쿠키 값이 아니라 쿠키 이름과 _abck 상태 마커를 기록하고, 판단은 Akamai 자체의 봇 판정 결과로 내리세요. 값은 암호화되어 있고 형식은 예고 없이 바뀔 수 있습니다. 일반적인 액세스 로그에서 얻을 수 있는 패턴은 다음과 같습니다.
bm_sz나_abck가 전혀 없는 깊은 URL 요청. 쿠키가 없는 클라이언트로, 첫 방문이거나 쿠키를 버리는 도구입니다. 상품이나 검색 URL에서 이 비율이 높고 이에 대응하는 랜딩 페이지 방문이 없다면 스크립트 접근을 의심할 수 있습니다.- 여러 IP나 ASN에서 같은
_abck값이 관찰되는 경우. 쿠키 공유 또는 재사용입니다. Akamai의 Cookie Integrity 탐지가 바로 이를 위해 만들어졌습니다. 로그를 보면 문제의 규모와 영향받는 경로를 파악할 수 있습니다. - 많은 요청 동안 미검증 상태로 남는 세션. 대개 페이지의 JavaScript를 전혀 실행하지 않는 클라이언트입니다. 개인정보 보호 확장 프로그램이나 스크립트 전송 장애도 같은 현상을 일으키므로, 규칙을 강화하기 전에 확인하세요.
- 오리진 측 봇 판정 결과. Akamai는 판정 결과를 요청 헤더로 오리진에 전달할 수 있습니다. Auth0의 통합 가이드는
akamai-bot와akamai-user-risk헤더를 문서화하고 Akamai의 "Forward Bot Results to Origin" 설정을 안내합니다. 이처럼 공식 지원되는 필드가 쿠키 내부를 파싱하는 것보다 낫습니다.
개인정보 측면: 이 쿠키들은 기기에 연결된 식별자입니다. RIPE NCC 같은 고지 문서는 이를 필수 쿠키로 분류하며, EU에서는 일반적으로 동의가 필요 없다는 뜻입니다. 그래도 원래 값을 IP와 함께 보관하는 로그는 개인정보이므로, 마커와 이름 목록을 확보한 뒤에는 값을 해시 처리하거나 삭제하세요.
이 쿠키들이 알려 주지 않는 것
쿠키는 클라이언트 측 검증이 아직 이루어지지 않았다는 사실은 보여 줄 수 있지만, 요청이 허용될 것인지는 보여 주지 못합니다. 요청 수준 탐지(IP 평판, 프로토콜 핑거프린트, 헤더 이상, 요청 속도)는 _abck와 독립적으로 실행되며, 사이트 운영자는 외부에서는 볼 수 없는 경로별 정책을 설정합니다. 디버깅할 때는 쿠키를 여러 신호 중 하나로 보고, 응답 코드, 챌린지 페이지, 타이밍을 함께 살피세요.
