블로그7분 읽기

클로드가 대화를 봉인하기 시작했다 — 증류 공장을 겨냥한 API 변경

페이블 5.1 Messages API가 thinking 블록을 대화에 서명으로 묶습니다. 새 계정부터 앞 턴을 고치면 증류 통로가 닫혀요.

클로드가 대화를 봉인하기 시작했다 — 증류 공장을 겨냥한 API 변경 대표 이미지

페이블 5.1 발표 스레드에서 벤치마크와 가격 다음, 여섯 번째 트윗에 이런 문장이 있습니다.

"증류 공격의 흔한 기법은 모델의 사고 연쇄(chain of thought)를 추출하는 것이다. 이 공격을 더 어렵게 만들기 위해 Messages API에 변경을 도입한다. 멀티턴 대화에서 클로드의 thinking 블록 앞에 오는 컨텍스트를 편집하는 것은 더 이상 불가능하다."

발표 스레드 첫 트윗이 조회 6만을 넘기는 동안 이 여섯 번째 트윗은 5천 회 남짓 — 대부분이 지나친 항목입니다. 그런데 헬프센터 문서와 플랫폼 문서를 뜯어보면, 이게 프런티어 API의 설계 문법을 바꾸는 변경이에요. 'preserved thinking'이라는 이름이 붙었습니다.

공격의 해부 — 앞 턴을 고치면 금고가 열렸다

배경 지식 두 개가 필요합니다.

첫째, thinking 블록. 클로드가 응답을 만들며 수행하는 추론의 기록입니다. API에서는 멀티턴 대화를 이어갈 때 이 블록을 시스템 프롬프트, 도구, 이전 메시지와 함께 매 요청마다 되돌려보내는 구조예요.

둘째, 이 추론은 암호화돼 있습니다. 앤트로픽은 추론 원문이 밖으로 새지 않도록 thinking 블록을 암호화해서 내보냅니다.

구멍은 그 사이에 있었습니다. 헬프센터 문장을 그대로 옮기면 — "thinking 블록 앞의 대화를 편집하면, 사용자는 클로드가 자기 추론을 복호화해 출력하게 만들 수 있었다." 앞 턴의 지시문을 바꿔치기한 채 암호화된 블록을 돌려보내는 방식으로, 금고 안의 사고 과정을 끄집어내는 겁니다.

이게 왜 문제냐. 그렇게 추출한 사고 연쇄로 다른 모델을 학습시키는 게 무단 증류(illicit distillation)입니다. 앤트로픽의 표현으로는 "종종 공장 돌리듯 가짜 계정 수천 개를 동원해" 벌어지고, 결과물은 "능력은 물려받되, 사이버 공격과 무기 개발 같은 광범위한 오용을 막기 위해 구축한 안전장치는 물려받지 않은" 시스템입니다. 앞 턴 편집은 이 캠페인의 "흔한 기법"이라고 명시돼 있어요.

방어의 구조 — 서명으로 대화에 묶는다

새 메커니즘의 이름이 내용을 요약합니다. 보존된 사고(preserved thinking) — thinking 블록이 자기가 태어난 대화에 묶입니다.

페이블 5.1의 thinking 블록에는 서명(signature)이 붙습니다. 블록을 돌려보내면 API가 이 서명으로 두 가지를 검사해요. 이전 대화가 바뀌지 않았는지, 그리고 현재 모델이 이 블록을 읽을 자격이 있는지.

검사는 세 항목입니다.

하나, 모델. 블록은 그걸 만든 모델과 그보다 최신 모델만 읽을 수 있습니다. 페이블 5.1은 오퍼스 5, 페이블 5 등 이전 모델의 블록을 읽지만, 역방향은 안 됩니다 — 구모델은 5.1의 블록을 못 읽어요. 고급 모델의 추론을 안전장치가 약한 저능력 모델로 흘려보내는 경로를 끊는 설계입니다.

둘, 앞부분(prefix). 최상위 시스템 프롬프트, 도구 목록, 그 블록보다 앞선 모든 메시지. 하나라도 바뀌면 서명이 안 맞습니다.

셋, thinking 체인의 연속성. 각 thinking 블록은 자기 앞의 블록을 기록합니다. 히스토리 앞쪽에서 블록을 걷어내는 건 되지만, 중간에서 하나를 빼면 그 뒤의 모든 블록이 무효가 됩니다.

검사에 실패하면 기본 동작은 400 에러 — "이 블록은 다른 대화 소속이다"는 메시지와 함께 요청 거부입니다. 개발자가 베타 헤더로 옵트인하면 에러 대신 해당 블록(과 그 이후 thinking)을 모델 입력에서 조용히 제거하고 요청을 성공시키는 drop_block 모드도 있습니다. 어떤 블록이 왜 떨어졌는지는 응답의 input_transformations 배열이 알려주고, 떨어진 블록은 과금되지 않아요.

목적을 못 박은 문서 문장이 이 변경의 척추입니다.

"이 검사는 한 지시문 집합 아래서 생산된 추론이 다른, 잠재적으로 적대적인 지시문 집합 아래서 재생될 수 없도록 하기 위해 존재한다."

누가 걸리고 누가 안 걸리나

시행 범위가 정교하게 잘려 있습니다.

안 걸리는 쪽부터. 클로드 코드, claude.ai, 코워크, 서드파티 제품 사용자는 영향 없습니다 — 공식 제품들은 원래 prefix를 그대로 유지하니까요. 페이블 5.1이 아닌 모델도 무관합니다. 흥미로운 예외 하나: 쌍둥이 미토스 5.1은 같은 서명을 찍지만 대화 검사를 돌리지 않습니다.

걸리는 쪽은 2026년 8월 31일 00:00 UTC 이후 생성된 새 API 계정입니다. 클로드 플랫폼 조직, 베드록 계정, 버텍스 AI 프로젝트, 애저 파운드리 프로젝트까지. 이유도 명시돼 있어요 — "증류 관련 남용이 가장 집중되는 곳이 새 계정"이라서. 트윗의 표현으로는 "증류는 종종 다수의 새 가짜 계정을 이용한다."

기존 계정은 페이블 5.1 기간 동안 유예입니다. API가 불일치를 기록만 하고 막지는 않아요. 하네스를 손볼 시간을 주는 겁니다. 단, 유예는 이번 모델까지 — "미래 모델 릴리스에서는 모든 계정에 적용된다"가 헬프센터와 트윗 양쪽에 박혀 있습니다.

개발자의 숙제 — append-only 시대

Messages API로 직접 에이전트 루프를 짜는 개발자에게 이건 손이 가는 마이그레이션입니다. 문서가 꼽은 '이제 깨지는 패턴'이 곧 업계의 흔한 습관 목록이에요.

  • 오래된 턴을 잘라내거나 클라이언트에서 요약해 갈아끼우기
  • 앞 턴에 리마인더를 주입했다가 다음 요청에서 지우기
  • 매 요청마다 시스템 프롬프트 재조립 (현재 시각, 토큰 예산, 모드 플래그…)
  • 세션 중간에 tools 배열 편집

전부 prefix를 다시 쓰는 행위라 서명 검사에 걸립니다. 대화 히스토리는 사실상 append-only가 됐어요.

대신 대체재가 공식 기능으로 정리돼 있습니다. 지시 변경은 대화 중간의 system 역할 메시지로, 턴 한정 리마인더는 clear_at 필드로, 도구 변경은 tool_addition/tool_removal로, 히스토리 축소는 서버 측 압축이나 컨텍스트 편집으로. 클라이언트 압축 자체가 금지된 것도 아닙니다 — 규칙은 좁아요. "다시 쓴 prefix 뒤에 thinking 블록을 남겨두지 마라." 히스토리 전체를 요약 하나로 교체하고 thinking을 재전송하지 않으면 됩니다.

부수 효과도 명시돼 있습니다. prefix를 안 건드리는 구조는 프롬프트 캐시 재사용률을 올려서 비용과 응답 시간을 같이 줄입니다. 안전 요구와 비용 최적화가 같은 방향을 가리키는, 드물게 잘 정렬된 변경이에요.

주의 조항 하나가 눈에 박힙니다 — "사용자가 자기 API 키로 돌리는 도구나 프레임워크를 유지보수한다면, 새 계정의 사용자들이 당신보다 먼저 이 검사에 부딪힌다. 당신의 키는 아마 구계정일 테니까." 오픈소스 에이전트 프레임워크 관리자들을 정확히 겨냥한 문장입니다.

남는 생각

저는 이 변경을 API 사양 업데이트가 아니라 선언으로 읽었습니다. 사고 연쇄가 프런티어 랩의 방어 자산이 됐다는 선언.

지금까지 증류 방어는 분류기와 약관의 영역이었습니다. preserved thinking은 그걸 프로토콜 층으로 내렸어요. 추론이 태어난 대화에 암호 서명으로 묶이고, 그 바깥에서는 재생 자체가 안 되는 구조. 능력 유출 방지가 '탐지'에서 '설계'로 넘어간 겁니다.

새 계정부터 한 칸씩 조이는 시행, 기존 개발자에게 준 유예, 옵트인 드롭 모드까지 — 마찰을 줄이려는 손길은 곳곳에 보입니다. 그래도 방향은 명확해요. 트윗의 마지막 문장이 오히려 솔직합니다. "길게 보면 증류 공격을 막을 더 나은 해법을 찾기를 희망한다." 아직 끝난 싸움이 아니라는 뜻입니다.

다음 모델부터는 전 계정 적용입니다. Messages API 위에 뭔가를 짓고 있다면, 유예 기간이 곧 마감 기한이에요.


원문·소스

FAQ

자주 묻는 질문

preserved thinking이 막는 공격은 무엇인가요?
thinking 블록 앞 대화를 바꿔치기해 암호화된 추론을 꺼내는 기법입니다. 그 연쇄로 다른 모델을 학습시키는 무단 증류의 흔한 입구예요.
누가 걸리고 누가 안 걸리나요?
2026년 8월 31일 이후 새 API 계정이 대상입니다. 클로드 코드·claude.ai·코워크와 페이블 5.1이 아닌 모델은 영향이 없어요.
개발자가 고칠 패턴은요?
앞 턴 요약 교체, 리마인더 주입 후 삭제, 매 요청 시스템 프롬프트 재조립, 세션 중 tools 배열 편집입니다. 대화는 사실상 append-only가 됩니다.