여러 코딩 에이전트를 함께 운용하는 팀에서는 태스크(Task)의 담당자가 수시로 바뀝니다. Sonnet 작업자 에이전트가 코드 변경 사항을 작성하면 Opus 리뷰어 에이전트가 이를 검토합니다. Claude Code 에이전트가 진행 중 멈추면 해당 태스크는 Codex 에이전트로 넘어갑니다. 지난 9월 28일 출시된 Claude Sonnet 5.5는 그동안 어느 정도 암묵적인 사실이었던 점을 공식 문서에 명시했습니다. 바로 모델의 추론 과정(reasoning)은 작업 결과물과 함께 전달되지 않는다는 점입니다. Anthropic의 Sonnet 5.5의 새로운 기능(what’s new in Sonnet 5.5) 페이지에 따르면, 모든 씽킹 블록(thinking block)에는 "어떤 모델이 이를 생성했는지가 기록"되며, 다른 모델은 Sonnet 5.5의 블록을 읽을 수 없습니다.
문제는 이 과정이 아무런 경고 없이 조용히 일어난다는 점입니다. 요청에 모델이 읽을 수 없는 블록이 포함되어 있으면, API는 모델이 이를 확인하기 전에 해당 블록을 삭제(drop)합니다. API 요청 자체는 성공하고 삭제된 블록에 대해서는 비용이 청구되지 않으며, 유일한 흔적은 input_transformations 항목뿐입니다. 이마저도 thinking-binding-controls-2026-08-01 베타 헤더를 보냈을 때만 표시됩니다. 결국 리뷰어 에이전트는 이유를 모른 채 변경 사항(diff)만 전달받게 되며, 에러가 발생하지 않기 때문에 실제보다 리뷰가 더 충분한 정보를 바탕으로 진행된 것처럼 보이게 됩니다.
요약 (TL;DR)
서로 다른 모델 간의 에이전트 인수인계(handoff) 컨텍스트에는 한 가지 절대적인 규칙이 적용됩니다. 인수인계 과정에서 살아남는 유일한 컨텍스트는 누군가가 태스크에 직접 기록해 둔 내용뿐이라는 점입니다. 씽킹 블록은 이를 생성한 모델과 정확히 일치하는 대화 세션에 바인딩되며, Sonnet 5.5의 경우 계정에도 바인딩됩니다. 따라서 모든 에이전트가 실행을 마칠 때 인수인계 코멘트를 남기도록 설정하세요. 여기에는 결정 사항과 그 이유, 전제 조건, 시도했다가 실패한 방법, 미해결 질문, 수정한 파일, 실행한 검증 단계가 포함되어야 합니다. 자체 하네스(harness)를 구축하는 경우 히스토리는 반드시 추가 전용(append-only)으로 유지해야 합니다.
씽킹 블록이 바인딩되는 세 가지 방식
씽킹 블록은 모델이 한 턴(turn) 동안 생성한 추론 내용으로, 이후의 요청에서 재사용하기 전에 API가 검증할 수 있는 서명(signature)과 함께 반환됩니다. 추론 보존(preserved thinking) 문서에서는 세 가지 바인딩을 설명하고 있으며, 각각은 여러분의 팀에서 이미 일상적으로 진행하고 있는 인수인계 상황과 정확히 일치합니다.
모델(Model). Sonnet 5.5는 Sonnet 5, Opus 4.8, Haiku 4.5 및 이전 모델에서 생성된 블록을 읽을 수 있지만, Opus 5, Opus 5.5, Fable, Mythos의 블록은 읽을 수 없습니다. 전환 방향도 중요합니다. 대화 도중 모델을 전환하는 것에 관한 Anthropic의 설명에 따르면, Sonnet 5에서 Sonnet 5.5로 전환된 대화는 추론 내용을 유지하지만, Sonnet 5.5에서 다른 모델로 전환된 대화는 이전 추론 없이 이후 턴을 진행합니다. 이는 거부된 일부 Sonnet 5.5 요청을 Sonnet 5로 재시도하는 Anthropic 자체의 서버 측 폴백(fallback)에도 동일하게 적용됩니다.
대화(Conversation). 씽킹 블록은 이를 생성할 때 사용된 것과 정확히 일치하는 시스템 프롬프트, 도구, 메시지 시퀀스 뒤에 올 때만 재사용할 수 있습니다. 공식 문서의 FAQ에서는 이에 따른 결과를 명확히 밝히고 있습니다. 추론은 다른 대화로 이전할 수 없으므로, 새 대화를 시작할 때는 태스크 상태에 대한 요약(목표, 내린 결정, 지금까지의 파일 및 결과, 다음 단계)을 기반으로 시작해야 한다는 것입니다. 태스크가 다른 에이전트로 넘어가면 런타임은 새 세션을 시작하며, 이는 동일한 모델을 사용하더라도 완전히 새로운 대화에 해당합니다. AI 세션 간 컨텍스트 유지하기에서 다룬 것처럼, 도구의 새 세션이 아무런 사전 지식 없이 콜드 스타트(cold start)하는 것도 바로 이 때문입니다.
계정(Account). Sonnet 5.5의 블록은 해당 블록을 생성한 계정 또는 이에 연결된 계정에서만 동작합니다. Anthropic의 출시 안내 포스트에서는 이러한 제약이 드러나는 대표적인 예로 Claude Code 세션 도중 계정을 전환하는 경우를 언급하고 있습니다.
종합해 보면, 애초에 에이전트 간에는 추론 내용이 전달된 적이 없습니다. Sonnet 5.5는 이를 API 규약(contract)의 일부로 공식화했을 뿐입니다.
추론 내용이 조용히 삭제되는 세 가지 인수인계 상황
| 인수인계 유형 | 전달되는 것 | 유실되는 것 | 유실 여부를 알려주는 신호 |
|---|---|---|---|
| Sonnet 5.5 작업자 에이전트에서 Opus 5.5 리뷰어 에이전트로 | diff, 저장소, 태스크 설명 및 코멘트 | Sonnet 5.5의 씽킹 블록. 다른 어떤 모델도 이를 읽을 수 없으며, 리뷰 작업 자체가 새로운 세션임 | 에이전트 간에는 아무런 알림 없음. 단일 API 대화 내부에서는 베타 헤더 사용 시 model_binding_mismatch 항목 표시 |
| Claude Code 에이전트에서 Codex 에이전트로 | diff, 브랜치, 태스크 기록, 저장소의 공유 규칙 파일 | Claude의 모든 추론 내용 및 Claude Code 세션 상태. Codex는 자체 대화를 새로 시작함 | 알림 없음 |
| 동일 모델, 다른 계정 (Claude Code 세션 도중 계정 전환, 또는 저장된 세션을 다른 계정의 인증 정보로 재생) | 눈에 보이는 트랜스크립트: 메시지, 도구 호출, 결과 | 첫 번째 계정에서 생성된 모든 Sonnet 5.5 씽킹 블록 | Claude API 및 Google Cloud에서 베타 헤더 사용 시 organization_binding_mismatch 항목 표시. 그 외에는 알림 없음 |
문제는 마지막 열에 있습니다. 세 가지 인수인계 모두 정상적으로 성공하며, 인계받은 에이전트는 이전 에이전트가 알고 있던 것보다 적은 정보를 가지고도 확신에 차서 답변합니다. 다른 모델을 사용하는 리뷰어는 작업자 에이전트가 의구심을 가졌던 변경 사항을 그대로 승인할 수도 있습니다. 그 의구심은 리뷰어가 결코 보지 못한 씽킹 블록 안에만 존재했기 때문입니다.
저희는 이전 글에서 코딩 에이전트 간 전환 시 컨텍스트를 유지하는 방법을 다루며 에이전트 전환은 "코드는 보존하지만 추론은 버린다"고 언급한 바 있습니다. 이제 이 원칙은 API 레벨에서도 동일하게 적용됩니다. 이는 단일 코드베이스에서 Claude Code와 Codex를 함께 운용하거나 에스컬레이션 라우팅 규칙을 사용하는 팀에게 매우 중요한 문제입니다. 만약 Sonnet 5.5 대 Opus 5.5: 어떤 에이전트에게 태스크를 맡길 것인가에서 설명한 것처럼 고난도 태스크가 Sonnet 5.5 작업자에서 Opus 5.5로 넘어간다면, 모든 에스컬레이션은 위 표의 첫 번째 행에 해당하는 인수인계가 됩니다.
추론이 전달되지 않을 때 인수인계 노트에 반드시 담아야 할 내용
코딩 에이전트 인수인계 노트의 역할은 단 하나입니다. 다음 작업자가 읽을 수 있도록 중요한 추론 내용을 명문화하여 남기는 것입니다. 아래의 항목들은 씽킹 블록에는 담겨 있었지만 diff에서는 절대 볼 수 없는 두 가지, 즉 '특정 접근 방식을 선택한 이유'와 '이미 배제된 접근 방식'을 추가하여 Anthropic의 요약 형식을 확장한 것입니다. 태스크를 다음으로 전달할 수 있는 모든 에이전트의 지침(instructions)에 이 내용을 추가하세요.
Before you finish, post one comment on the Task that starts with "Handoff".
Write it for a reader who has this Task and the diff, and nothing else.
Decisions: each choice you made and the reason for it, one line each
Assumptions: what you took as true without verifying it
Tried, failed: approaches you ruled out and why, so nobody retries them
Open questions: what a person or the next Agent has to decide
Files touched: paths changed, and which ones are unfinished
Checks run: exact commands and their results; name any check you skipped
Next step: the one action you would take next
이 인수인계 노트가 실질적인 효과를 발휘하도록 돕는 세 가지 핵심 디테일이 있습니다.
추론 과정 자체가 아닌 결정을 요청하세요. Sonnet 5.5는 추론 추출(reasoning extraction)을 방지하는 안전 분류기(safety classifier)가 적용된 최초의 Sonnet 모델로, reasoning_extraction 거부 카테고리는 응답 텍스트에 내부 추론 과정을 그대로 재현하도록 요구하는 요청을 차단합니다. "코멘트에 당신의 씽킹 내용을 붙여넣으라"는 식의 요청이 바로 여기에 해당합니다. 반면 "각 결정 사항과 그 이유를 나열하라"는 요청은 일반적인 보고에 불과하므로 안전하게 처리됩니다.
"시도했다가 실패한 방법(Tried, failed)"이 시간을 가장 많이 절약해 줍니다. 막다른 길에 부딪혔던 과정은 diff에 나타나지 않습니다. 인수인계 노트가 없다면 다음 에이전트도 똑같은 막다른 길로 들어서게 됩니다.
검증은 명령어와 실제 출력을 의미합니다. "테스트 통과함"은 단순한 주장에 불과합니다. 실제로 실행한 명령어와 테스트 통과/실패 수치는 리뷰어가 직접 다시 실행해 볼 수 있는 명확한 증거가 됩니다.
인수인계 노트를 작성할지 여부는 다음 기준에 따라 판단하면 됩니다. 단일 실행에서 한 에이전트가 태스크 할당부터 리뷰까지 모두 완료하고 최종 승인자가 어차피 diff를 직접 검토하는 경우에는 노트를 생략해도 무방합니다. 반면 태스크의 담당자(Assignee)가 바뀌거나, 모델이 변경되거나, 리뷰어 에이전트로 전달되는 순간에는 반드시 노트를 작성하도록 해야 합니다. 코딩 에이전트 인수인계 템플릿이 사람과 에이전트 사이의 접점을 다룬다면, 이 노트는 두 에이전트 사이의 접점을 다룹니다.
자체 하네스를 구축하는 경우: 이제 히스토리 수정은 에러를 발생시킵니다
대부분의 독자는 이 섹션을 건너뛰셔도 좋습니다. 추론 보존 문서에 따르면 Claude Code, claude.ai, Claude Managed Agents 또는 Claude Agent SDK가 요청을 생성하는 경우에는 변경되는 사항이 없습니다. 하지만 자체 작성한 코드가 Messages API를 직접 호출할 때는 이 내용이 매우 중요합니다.
2026년 8월 31일 00:00 UTC 이후에 생성된 계정의 경우, Claude API, Amazon Bedrock, Google Cloud에서 Sonnet 5.5 씽킹 블록 이전의 내용(시스템 프롬프트, 도구, 이전 메시지 등)을 변경한 후 해당 씽킹 블록을 재생(replay)하면 400 에러가 반환됩니다. 이전 계정에서는 요청에서 명시적으로 옵트인(opt-in)했을 때만 이 검증이 수행되는데, 이 때문에 함정에 빠지기 쉽습니다. 개발자 자신의 API 키로는 정상 동작하지만, 더 최근에 생성된 계정의 키로 도구를 실행하는 사용자는 가장 먼저 400 에러를 겪게 되는 것입니다. 해결책은 대화를 추가 전용(append-only)으로 유지하는 것입니다.
- 세션 시작 시 시스템 프롬프트와 도구를 고정(freeze)하세요. 지침을 변경해야 한다면 대화 중간에 시스템 메시지를 추가(append)하는 방식을 사용하세요. 이는 Sonnet 5.5에서는 지원되지만 Sonnet 5에서는 지원되지 않는 기능입니다.
- 비어 있는 씽킹 블록을 포함하여, 어시스턴트의 각 턴을 API에서 반환된 그대로 다시 전송하세요.
- 이전 턴을 직접 재작성하지 말고 API를 통해 압축(compact)하세요. 온디맨드 압축(베타
compact-2026-09-04)은 요약 대상 메시지를 대체하여 전송할 수 있는 서명된 요약 블록을 반환합니다. 문서에서 권장하는 단순 압축 방식은 하나의 요약 메시지와 다음 지침만 전송하므로 이전 씽킹 블록이 재전송(replay)되지 않습니다.
{ "role": "system", "content": "Review found a race in the retry path. Do not change the public API." }
베타 헤더를 사용할 때 prefix_mismatch_behavior: "drop_block"을 설정하면 에러를 발생시키는 대신 검증에 실패한 블록을 삭제합니다. 하지만 공식 문서에서도 명시하듯, 이는 문제를 해결하는 것이 아니라 수정한 사실을 감추는 것에 불과합니다.
Anthropic이 권장하는 압축 방식의 구조를 주목해 보세요. 추론 과정을 재사용할 수 없을 때 Anthropic이 제시하는 해결책은 바로 명문화된 요약문입니다. 이는 이름만 다를 뿐 사실상 인수인계 노트와 동일합니다.
Sharkly에서 인수인계가 관리되는 방식
태스크는 팀 전체가 공유하는 단일 기록 저장소이며, 세션이 종료된 후에도 유지되는 유일한 수단이므로 인수인계는 반드시 태스크에 기록되어야 합니다. Sharkly의 태스크에는 대화(코멘트 기반 대화), 코멘트 및 변경 이력을 보여주는 활동(Activity) 타임라인, 모든 작업 실행 기록인 실행(Executions) 히스토리가 보관됩니다. 팀에 전달해야 할 에이전트의 텍스트는 해당 실행과 연결된 코멘트로 저장됩니다. 에이전트에게 확인이 필요한 질문이 생기면 태스크에 코멘트로 등록되고, 태스크 상태는 사용자의 답변 대기 중으로 변경되며, 질문은 해당 담당자의 수신함(Inbox)으로 전달됩니다.
이 구조의 진가는 담당자 재지정(reassignment) 시에 드러납니다. 담당자를 Sonnet 5.5 에이전트에서 Opus 5.5 리뷰어나 Codex 에이전트로 변경하면, 다음 실행은 이전 대화 트랜스크립트가 아니라 태스크 기록을 기반으로 시작됩니다. Sharkly 문서에는 태스크 기반 실행에 포함될 수 있는 항목들이 명시되어 있습니다. 제목과 설명, 최근 코멘트 및 실행을 트리거한 코멘트, 에이전트 지침, 연동 저장소 등이 여기에 해당합니다. 인수인계 코멘트 역시 이 목록에 포함됩니다. 이전 에이전트의 씽킹 블록은 여기에 포함되지 않으며, 어차피 모델이 변경되면 API 수준에서 삭제되었을 것입니다.
이에 따라 두 가지 실천 습관이 요구됩니다. 첫째, 문서에서는 팀 전체가 확인해야 하는 결론을 코멘트나 태스크 설명에 기록하도록 권장하므로, 에이전트와의 개별 대화(side chat)에서 결정된 모든 사항은 태스크를 이관하기 전에 해당 위치에 반영해야 합니다. 둘째, 각 실행은 최근 코멘트를 가져오므로, 태스크 전체에 걸쳐 지속적으로 유지되어야 하는 결정 사항은 태스크 설명에 통합해 두어야 합니다.
바로 이 지점에서 플랫폼 중립성(provider neutrality)의 진정한 가치가 발휘됩니다. 에이전트는 런타임의 기본 모델을 따르므로, 인수인계 규칙은 에이전트 지침에 작성되어 다음 런타임이 Sonnet 5.5 기반의 Claude Code이든 다른 모델 기반의 Codex이든 상관없이 동일하게 동작합니다. 설정 방법은 Sharkly에서 Claude Sonnet 5.5 에이전트 실행하기에서 확인하실 수 있습니다. 에이전트는 조사, 실행, 테스트 및 보고를 수행합니다. 사람은 다음 에이전트가 읽게 될 것과 동일한 서면 기록을 바탕으로 방향을 설정하고, 권한을 부여하며, 결과를 최종 승인합니다. 이것이 바로 에이전트 작업에 대한 인간의 오너십이 성립하는 핵심 원리입니다.
추론 보존 기능은 Fable 5.1에서 시작되어 현재 Opus 5.5 및 Sonnet 5.5까지 확대 적용되었습니다. 추론 내용이 전달되는 것에 전혀 의존하지 않는 인수인계 체계를 구축해 두면, 향후 모델이 변경되더라도 작업 워크플로가 중단되지 않습니다. 이미 여러 에이전트를 운용하고 계시다면, Sharkly를 통해 에이전트들의 태스크와 결과를 단일 플랫폼에서 체계적으로 관리해 보세요.
