AI 로그를 공유하기 전: 암호화된 추론 상태는 공개본에서 분리하세요

동료에게 에이전트 실행 기록을 전달하려고 최종 답변의 API 키를 가렸다면, 다음에는 원시 응답에 남은 불투명한 추론 상태를 확인해야 합니다. 권장하는 출발점은 간단합니다. 이어 쓰는 데 필요한 비공개 원본과, 사람이 읽고 검토할 공개용 사본을 서로 다른 산출물로 취급하세요. 공개용 사본에 필요 없는 추론 상태를 내보내지 않는 정책과, 실행 중인 API가 요구하는 상태를 온전히 돌려주는 규칙은 동시에 지킬 수 있습니다.

이 글은 지금 통하는 공격을 알리는 글이 아닙니다. 아래 논문은 2026년 7월 초의 API·모델을 실험했고, 책임 공개 후 같은 공격을 수행하지 못했다고 보고했습니다. 2026년 8월 재현성 문구도 공급업체의 완화 뒤 해당 공격이 재현되지 않는다고 명시합니다. 여기서 가져올 실무 판단은 “암호화가 깨졌다”가 아니라 “공개할 로그와 재개할 상태는 같은 파일이어야 하는가”입니다.

비공개 실행 원본의 필수 상태 보존과 공개용 export의 불필요한 불투명 상태 제외를 나란히 구분한 개념도

비공개 원본과 공개 사본을 분리하는 편집자 개념도입니다. 공개본의 제외 규칙은 필수 signature를 실행 원본에서 삭제하라는 뜻이 아닙니다. 출처: arxiv.org/html/2608.09867v1.

먼저 결정할 것: 이 파일을 읽을 것인가, 다시 실행할 것인가

아래 표는 논문과 공식 API 문서를 바탕으로 작성한 편집자 결정표입니다. 공식 보안 인증이나 제품의 자동 정리 기능을 재현한 결과가 아닙니다.

사용 목적 전달할 대상 구분해서 검토할 것 피할 판단
외부 협업자에게 작업 설명 별도로 만든 공개용 export 필요한 텍스트·도구 출력·메타데이터를 검토하고, 불필요한 추론 블록·불투명 필드를 제외 답변만 가렸으니 원시 응답 전체도 공유 가능하다는 판단
같은 도구 사용 턴 이어가기 접근 통제된 실행 원본 해당 API의 필수 상태·블록 순서·원형 보존 요구 공개본 정리 규칙을 실행 원본에 그대로 적용
외부에서 받은 실행 기록 살펴보기 재개하지 않는 검토용 사본 출처와 신뢰 경계, 필요한 정보, 불투명 상태 포함 여부 남이 공유한 서명 블록을 검토 없이 내 실행 상태로 승격
재현 자료 보관 권한과 보관 기간을 정한 비공개 원본, 별도 공개 설명 재개 가능성과 공개 범위를 따로 기록 재현성을 이유로 원시 API 기록을 공개 저장소에 그대로 커밋

공개본에서 추론 상태를 제외하면 그 사본으로 동일한 실행을 이어가지 못할 수 있습니다. 이것은 결함을 숨기는 일이 아니라 공개 목적을 좁힌 선택입니다. 반대로 재현·장애 분석에 필요한 원본을 보관한다면 접근 권한, 보관 기간, 공유 승인과 검토 비용을 별도로 다뤄야 합니다. “무조건 전부 삭제”도 “재현하려면 전부 공개”도 이 표의 결론이 아닙니다.

예를 들어 공개본에는 검토한 요청 의도와 답변 요약, 필요한 도구 출력만 담고, 재개 가능한 상태는 권한이 있는 사람에게만 남기는 식으로 목적을 나눌 수 있습니다. 이것은 개념적 전후 예시이며 실제 로그를 정리하거나 보안 효과를 측정한 결과는 아닙니다. 추론 필드를 제외한 뒤에도 텍스트·파일명·도구 결과·메타데이터에 민감한 정보가 있는지 따로 봐야 합니다.

텍스트를 가려도 불투명 추론 상태가 남은 사본과, 검토한 텍스트만 공개하고 재개 원본은 비공개로 둔 합성 전후 예시

실제 로그가 아닌 합성 예시입니다. 불투명 상태를 공개본에서 제외해도 보이는 텍스트·도구 출력·메타데이터 검토는 남으며 완전한 비식별화를 보장하지 않습니다. 출처: arxiv.org/html/2608.09867v1.

왜 읽을 수 없는 필드까지 공유 범위에 넣어야 할까

프리프린트 「Stealing Reasoning Traces from Proprietary LLM APIs」 v1의 §4.1은 공개된 에이전트 기록에서 가져온 암호화 추론 블록으로 정보가 노출될 수 있었던 조건을 다룹니다. 당시 연구진이 보고한 핵심은 호환 가능한 블록을 다른 세션·사용자·모델 문맥에서 처리할 수 있었고, 호환되는 디코더 모델이 존재했다는 점입니다. 암호 알고리즘 자체를 수학적으로 깼다는 결과로 읽으면 안 됩니다. 공급업체 내부 키 관리 구조를 직접 감사한 결과도 아닙니다. 논문 §§2.1–2.3, 4.1

독자 입장에서 중요한 차이는 가릴 대상을 볼 수 있느냐입니다. 보이는 문장에서는 비밀값을 찾아 제거할 수 있지만, 사용자가 해석할 수 없는 암호화된 추론 내용은 같은 방식으로 부분 마스킹하기 어렵습니다. 논문은 민감한 정보가 에이전트에 노출된 세션을 공개할 때 추론 블록과 불투명 추론 필드를 제거하라고 권고하고, 서명이 포함된 원시 API 기록을 공유 저장소에 보관·커밋하는 관행도 경계합니다. 이 권고는 공개 사본의 경계에 관한 것이지, 필수 실행 상태를 임의로 훼손하라는 지침이 아닙니다. 논문 §5.4

숫자는 피해자 수가 아니라, 집계 대상을 붙여 읽기

연구진은 공개 에이전트 궤적 6,708개를 수집해 추론 블록 315,320개를 재구성했다고 보고했습니다. 이것은 연구진이 수집한 표본의 범위입니다. 전체 서비스의 이용자 수나 현재 취약한 계정 수가 아닙니다. 공개 기록을 대상으로 한 비포괄적 분석이므로 서비스 전체의 사고 확률로 바꿀 수도 없습니다. 논문 §4.1

특히 Appendix D.1의 Table 4에서 API key 행을 보면, 비벤치마크 세션에서 범주·값 기준으로 중복 제거된 API 키 값은 62개입니다. 그중 파싱된 보이는 기록에는 없고 추론에만 나타난 값인 reasoning-only는 11개입니다. 따라서 “62명이 피해를 봤다”, “62개가 모두 추론에만 있었다”는 설명은 맞지 않습니다. 전체 범주의 reasoning-only 합계 64를 API 키 개수로 쓰는 것도 잘못입니다. 아래 그림은 바로 이 한 행의 구분만 보여줍니다.

논문 Table 4 API key 행의 비벤치마크 키 값 62개와 그중 보이는 기록에 없는 값 11개를 동일한 영 기준 축으로 비교한 도표

연구진 보고값으로, 단위는 범주·값 기준 중복 제거된 API 키 값 개수입니다. 11은 비벤치마크 값 62의 하위 집합이며 사용자 수나 실제 유효 키 수가 아닙니다. 출처: arxiv.org/html/2608.09867v1.

이 분류는 연구진의 자동 라벨링과 집계입니다. 이 글에서는 복구된 값을 보거나 실제 인증이 되는지 검사하지 않았으며 연구를 독립 재현하지 않았습니다. 원문이 없는 추론 복원의 정확성을 모든 토큰에서 확정할 수 없다는 한계도 논문이 밝힙니다. 표본 집계와 현재 유효한 자격 증명 검증은 다른 작업입니다.

원문의 초록·본문·부록에는 집계 범위나 총계가 맞지 않는 부분도 있습니다. 이 글은 이를 임의로 합산하거나 하나의 확정 총계로 정리하지 않습니다. 판단에 필요한 표의 특정 행과 그 분모만 제한적으로 인용합니다. 따라서 이 글을 전체 유출 규모를 감사한 보고서로 읽어서는 안 됩니다.

실행 원본에서는 공식 프로토콜이 우선입니다

현재 수집된 Claude 공식 문서의 Thinking encryption 절은 full thinking이 암호화되어 각 thinking 블록의 signature 필드에 반환되며, 이 값은 해석하거나 파싱할 대상이 아니라고 설명합니다. 도구 사용 턴을 계속할 때는 받은 thinking 블록을 완전하고 변경 없이 넘겨야 하며, redacted_thinking도 해당 보존 규칙에서 빠뜨리면 안 됩니다. 읽기 쉬운 텍스트가 없다는 이유로 실행 원본에서 제거하면 프로토콜을 깨뜨릴 수 있습니다. Claude Thinking encryption / Preserving thinking blocks

또한 같은 문서는 Claude Sonnet 5.5와 Haiku 5.5의 thinking 블록이 생성한 계정 또는 연결된 계정에서만 동작한다는 예외를 명시합니다. 과거 논문에서 보고된 사용자 간 호환성을 오늘의 모든 모델에 그대로 적용할 수 없다는 구체적인 이유입니다. 이 글은 공급업체 전체의 완화 상태를 보증하거나, 모든 과거 블록이 이제 무해하다고 단정하지 않습니다.

Gemini 문서는 적용 API를 구분해야 합니다. Interactions API의 stateful 모드에서는 서버가 thought 블록과 signature를 포함한 상태를 관리합니다. stateless 모드에서 전체 기록을 직접 넘긴다면 받은 thought 블록을 그대로 다시 보내야 합니다. 이것을 모든 generateContent SDK에 대한 일괄 삭제·보존 처방으로 확대하면 안 됩니다. Gemini Thought signatures

외부 로그 공유, Claude 도구 턴 계속, Gemini Interactions의 stateful 및 stateless 목적별 처리 원칙을 구분한 결정도

논문 §5.4와 공식 문서를 바탕으로 한 편집자 판단입니다. Claude는 도구 사용 턴의 블록 보존, Gemini는 Interactions API 범위이며 과거 공격 완화 보고와 현재 프로토콜을 구분합니다. 출처: platform.claude.com/docs/en/build-with-claude/thinking.

공개 경계가 바뀌면 포기하는 것도 기록하세요

공개용 export를 별도로 만들면 원시 응답을 그대로 공유할 때보다 검토·문서화 작업이 생깁니다. 사본에 없는 상태 때문에 제삼자가 동일한 지점에서 실행을 재개하지 못할 수 있고, 비공개 원본을 유지한다면 그 보관 책임도 남습니다. 반면 공개의 목적이 동작 설명이나 결과 검토라면, 재개 가능한 모든 내부 상태를 공개본에 포함해야 할 이유는 따로 입증해야 합니다. 이는 문서와 논문에서 도출한 편집상 판단이지, 특정 조직에서 절감한 비용이나 측정한 보안 성능이 아닙니다.

실무에서 남길 결론은 “어떤 필드를 지웠는가”만이 아닙니다. 누구에게 어떤 목적의 사본을 전달하는지, 그 사본은 재개용이 아닌지, 실행 원본의 접근·보관 정책은 무엇인지 함께 적어야 합니다. 외부에서 받은 불투명 상태 역시 진짜 서명이 붙었다는 이유만으로 내 워크플로에서 신뢰할 수 있는 과거 생각으로 취급하지 않는 편이 합리적입니다. 논문 §4.2가 설명하는 위협을 반영한 판단이며 여기서는 공격 프롬프트나 재생 절차를 제공하지 않습니다.

이 결정표는 문헌에 근거한 편집자 분석이며, 실제 API 공격 재현이나 완전한 비식별화 보장이 아닙니다. 논문은 심사 통과 여부가 확인되지 않은 v1 프리프린트이고, 실험 시점과 공급업체 완화 이후의 현재 동작은 구분해야 합니다. 지금 할 수 있는 작은 결정은 최종 답변을 한 번 더 가리는 일보다, 공개 사본과 비공개 실행 원본의 경계를 먼저 정하는 것입니다.

함께 읽으면 좋은 글

보이는 비밀값의 탐지와 불투명 상태의 공개 판단은 서로 보완합니다. Claude 키를 GitHub에 넣기 전: 탐지 유형과 push 차단 조건은 텍스트로 드러나는 자격 증명 차단의 조건을 다룹니다. 그 조건을 통과했다고 불투명한 추론 내용까지 검토된 것은 아닙니다.

반대로 Claude Code가 갑자기 둔해졌다면: 오래된 세션의 추론 기록 버그 구별하기는 실행 연속성에서 추론 기록이 갖는 역할을 보는 글입니다. 공개 사본에서 제외할 정보와 실행에 필요한 상태를 혼동하지 않는 관점으로 읽으면 연결됩니다.

출처와 확인 범위

문서와 그림은 2026년 10월 17일 수집된 출처 증거를 사용했습니다. 그림은 이 글을 위해 만든 개념도·합성 예시·원문 표 기반 도표이며 제품 화면이나 실제 공격 결과가 아닙니다.

댓글

이 블로그의 인기 게시물

체크아웃은 분리됐는데 Git 상태는 공유된다: Codex 0.154 worktree의 세 경계

잠근 작업이 커밋 뒤 다시 나온다: PostgreSQL 에이전트 큐의 소유권 설계

코딩 에이전트는 API 문서보다 AGENTS.md를 먼저 읽었다