많은 팀이 아직도 handoff를 “대화 로그를 다음 실행자에게 넘기는 일” 정도로 생각합니다. 하지만 긴 대화는 정보가 많아도 작업 전달물로는 부정확한 경우가 많습니다. 이미 끝난 가설과 아직 살아 있는 가설이 섞이고, 승인된 범위와 아직 금지된 범위가 섞이고, 실제 실행 결과와 앞으로 할 일이 섞입니다. 그래서 최근 잘하는 팀들은 transcript를 그대로 넘기기보다, 작업 단위 패킷(handoff packet) 을 만들어 넘기는 방향으로 가고 있습니다.

저는 이 흐름이 Context Contract Registry가 입력 조각을 계약화한 흐름의 다음 단계라고 봅니다. 입력이 계약화됐다면, 이제 실행자 간 전달도 계약화돼야 합니다. 또 Execution Receipt, Capability Lease, Stateful Sandbox Snapshot과도 자연스럽게 연결됩니다. 입력 계약이 무엇을 넣을지 정하고, lease가 무엇을 할 수 있을지 정하고, receipt가 무엇을 했는지 남긴다면, handoff packet은 다음 실행자가 무엇을 이어받아야 하는지를 명확히 하는 계층입니다.

이 글에서 얻는 것

• 왜 긴 transcript 공유만으로는 멀티에이전트 handoff 품질이 안정되지 않는지 이해할 수 있습니다.
• handoff packet에 어떤 필드가 있어야 다음 실행자가 재조사 없이 바로 움직일 수 있는지 판단할 수 있습니다.
• packet을 도입할 때 우선 봐야 할 지표와 운영 기준을 숫자 중심으로 가져갈 수 있습니다.

핵심 개념/이슈

1) 지금 문제는 컨텍스트 부족보다 “전달 경계가 흐린 것"이다

현장에서 handoff가 실패하는 가장 흔한 이유는 정보량 부족이 아닙니다. 오히려 정보가 너무 많고, 그중 무엇이 현재 유효한 상태인지 구분되지 않는 경우가 많습니다.

• 이미 기각된 가설이 여전히 중요한 단서처럼 남아 있다.
• 승인받은 범위와 아직 승인 전 범위가 같이 섞여 있다.
• 수정 완료 항목과 미완료 항목이 같은 문단에 적혀 있다.
• 임시 workaround와 최종 의사결정이 구분되지 않는다.
• 어느 아티팩트가 최신인지 불분명하다.

이 상태에서 다음 에이전트가 받는 것은 풍부한 문맥이 아니라 판단 비용이 큰 혼합물입니다. 그래서 handoff packet의 핵심은 더 많은 문장을 보내는 것이 아니라, 지금 시점에 유효한 실행 단위만 남기는 것입니다.

2) handoff packet의 핵심 객체는 transcript가 아니라 “재개 가능한 작업 상태"다

좋은 handoff packet에는 보통 아래 요소가 들어갑니다.

• intent: 이 작업이 무엇을 끝내려는지
• current_state: 어디까지 끝났는지, 무엇이 미완료인지
• constraints: 금지 범위, 승인 필요 조건, 예산 상한
• artifacts: diff, 테스트 결과, 스냅샷, 문서 링크, receipt ref
• freshness: 언제 생성됐고 언제부터 재검증이 필요한지
• next_action: 다음 실행자가 바로 해야 할 1~3개 행동
• success_criteria: handoff를 받은 실행자가 끝났다고 볼 조건

핵심은 “요약문"이 아니라 재개 가능한 상태 모델이어야 한다는 점입니다. 그냥 긴 요약을 넘기면 다음 실행자가 다시 정리해야 합니다. 반대로 packet이 있으면 다음 실행자는 “무슨 일을 해야 하지?“가 아니라 “정해진 다음 행동을 실행할 수 있는가?“만 판단하면 됩니다.

3) 왜 지금 중요해졌나: 세션이 길어지고, 실행자가 많아지고, 런타임이 섞이기 때문이다

최근 워크플로는 아래 특성을 같이 가집니다.

• 한 작업이 수십 분에서 수시간 이어진다.
• 조사, 수정, 검증, 승인 대기가 다른 실행자로 분리된다.
• 스레드 기반 세션, sandbox snapshot, 외부 툴 런타임이 섞인다.
• 승인 후 실제 실행까지 시간차가 생긴다.

이 구조에서는 “대화 히스토리 전달"만으로는 부족합니다. 어느 시점의 사실이 최신인지, 어느 권한이 아직 유효한지, 어떤 산출물이 최종인지 구분해야 하기 때문입니다. 그래서 Harness Engineering, Action Lineage Graph, Execution Receipt 같은 흐름이 같이 나옵니다. handoff packet은 이 구조에서 실행 경계마다 붙는 운영용 전달물입니다.

4) 좋은 packet은 무엇을 “넣나"보다 무엇을 “빼나"에서 품질이 갈린다

초기 도입 팀은 packet에 모든 맥락을 넣으려는 경향이 있습니다. 하지만 실무에서는 packet이 커질수록 다시 transcript처럼 변합니다. 그래서 좋은 팀은 packet을 아래처럼 강하게 제한합니다.

• 열린 TODO는 최대 3개
• evidence 링크는 핵심 것만 5개 이내
• 금지 범위와 승인 대기 항목은 별도 필드 분리
• 오래된 논의는 원문 링크만 남기고 packet 본문에서는 제거
• freshness TTL을 넘긴 내용은 재검증 요구 상태로 표시

이 방식은 Context Contract Registry와 닮아 있습니다. 좋은 입력 거버넌스가 “무엇을 넣을 수 있나"보다 “무엇을 빼야 하나"를 먼저 다루듯, 좋은 handoff도 과잉 문맥을 줄이는 쪽이 더 중요합니다.

5) packet validation이 없으면 handoff는 문서화만 늘고 운영 품질은 안 오른다

handoff packet이 실제로 효과를 내려면 수동 메모를 잘 쓰는 문화만으로는 부족합니다. 경계에서 자동 검증이 붙어야 합니다.

예를 들어 아래는 자동 검증 대상이 될 수 있습니다.

• packet 생성 시점으로부터 30분 이상 지났으면 freshness 재검증 요구
• approval ref가 없는 쓰기 작업은 packet 승격 금지
• receipt나 artifact hash가 없는 완료 항목은 done으로 표시 금지
• capability lease가 만료되었으면 next_action=execute packet 발급 금지
• 관련 snapshot id가 없으면 환경 재현 가능 상태로 간주하지 않음

즉 packet은 예쁜 handoff 메모가 아니라, 다음 실행자의 출발 조건을 검증하는 계약물이어야 합니다.

실무 적용

1) 최소 handoff packet 스키마는 작게 시작하는 편이 낫다

처음부터 거대한 workflow schema를 만들 필요는 없습니다. 아래 8개 정도로 시작해도 충분히 효과가 납니다.

• packet_id
• task_id 또는 intent_id
• owner와 target_executor
• current_state
• constraints
• artifacts
• next_action
• success_criteria
• fresh_until

실무에서는 여기에 approval_ref, lease_ref, snapshot_ref 정도만 추가해도 품질이 크게 좋아집니다. 중요한 건 필드 수보다, 다음 실행자가 재탐색 없이 바로 착수할 수 있느냐입니다.

2) 의사결정 기준(숫자·조건·우선순위)

초기 KPI는 자동화율보다 handoff 품질에 두는 편이 맞습니다.

추천 출발값:

• handoff_recovery_time_p95: 5분 이내
• ambiguous_handoff_rate: 3% 미만
• stale_packet_rate: 2% 미만
• packet_validation_coverage: 쓰기/운영 액션 handoff는 95% 이상
• rework_after_handoff_rate: 10% 미만
• missing_artifact_rate: 5% 미만

우선순위는 보통 아래 순서가 안전합니다.

1. 승인/권한/범위 정보 누락 방지
2. 최신 artifact와 snapshot 연결
3. 다음 행동 1~3개 고정
4. transcript 링크는 보조 자료로만 유지
5. packet TTL과 재검증 규칙 적용

핵심은 많이 자동화하는 것이 아니라, 애매한 handoff를 먼저 줄이는 것입니다.

3) 어디서부터 도입할까: 멀티스텝 쓰기 작업부터 시작하는 편이 효과가 크다

추천 도입 순서는 아래와 같습니다.

1순위, 코드/문서 수정 후 검증으로 넘어가는 handoff
조사 에이전트가 수정안과 증거를 남기고, 검증 에이전트가 이어받는 구조에 packet이 잘 맞습니다.

2순위, 승인 대기 후 재개되는 작업
승인 전후로 컨텍스트가 자주 흔들리기 때문에 packet 가치가 큽니다.

3순위, 런타임이 바뀌는 작업
스레드 세션에서 sandbox 실행으로 넘어가거나, 다른 도구 런타임으로 넘길 때 경계가 분명해집니다.

반대로 단발성 질의응답에는 packet이 과할 수 있습니다. 모든 작업에 억지로 붙이면 운영 문서만 늘어납니다.

4) 실전 예시, transcript handoff 대신 packet handoff

예를 들어 어떤 팀이 “버그 원인 조사 → 수정 → 테스트 → 리뷰 요청” 흐름을 에이전트 여러 개로 나눈다고 가정해 보겠습니다. transcript 기반 handoff에서는 조사 에이전트가 긴 설명을 남기고 끝나며, 수정 에이전트는 그 안에서 진짜 결론과 버린 가설을 다시 골라야 합니다. 그러면 재조사 시간이 길어지고, 이미 끝난 분석을 또 반복하기 쉽습니다.

packet 기반 handoff라면 구조가 달라집니다.

• current_state: 재현 완료, 원인 후보 3개 중 2개 기각, 남은 원인 1개 확정
• artifacts: 실패 테스트 링크, 관련 파일 2개, snapshot id, receipt ref
• constraints: 설정 파일 변경 금지, 외부 전송 금지, 승인 없는 배포 금지
• next_action: service_a/config.go 수정, 단위테스트 3개 실행, diff 요약 작성
• success_criteria: 테스트 3개 통과, diff 80줄 이내, 설정 파일 무변경

이렇게 넘기면 다음 실행자는 더 많은 맥락을 읽지 않아도 움직일 수 있습니다. 즉 handoff packet의 목적은 설명을 아름답게 쓰는 것이 아니라, 다음 실행자의 시작 비용을 강하게 줄이는 것입니다.

5) 바로 가져다 쓸 수 있는 최소 packet 템플릿

실무에서는 거대한 표준보다, 현장 팀이 바로 복붙해서 쓸 수 있는 템플릿이 먼저 필요합니다. 아래처럼 state / constraint / evidence / next step 중심으로 시작하면 대부분의 handoff 비용을 바로 줄일 수 있습니다.

packet_id: hp_2026_04_17_001
task_id: incident-4217
intent: "결제 API 타임아웃 원인 확정 후 수정안 검증까지 완료"
current_state:
  done:
    - "재현 완료"
    - "원인 후보 3개 중 2개 기각"
  remaining:
    - "connection pool 누수 수정"
    - "회귀 테스트 3개 실행"
constraints:
  - "설정 파일 변경 금지"
  - "승인 없는 production 배포 금지"
  - "외부 고객 안내문 수정 금지"
artifacts:
  - "failing test: tests/payment_timeout_test.go"
  - "snapshot_ref: sandbox-2026-04-17-09"
  - "receipt_ref: exec-receipt-1882"
next_action:
  - "service/payment/pool.go 수정"
  - "go test ./... -run PaymentTimeout"
  - "diff 요약 5줄 작성"
success_criteria:
  - "회귀 테스트 3개 통과"
  - "diff 120줄 이하"
  - "설정 파일 무변경"
fresh_until: "2026-04-17T10:30:00Z"

중요한 건 예쁘게 적는 것이 아니라, 다음 실행자가 다음 5분에 무엇을 해야 하는지를 바로 알 수 있게 만드는 것입니다. 이 템플릿은 Execution Receipt와 붙이면 실행 증거를, Capability Lease와 붙이면 권한 유효성을, Context Contract Registry와 붙이면 입력 경계를 함께 고정할 수 있습니다.

6) 어떤 신호가 보이면 packet 설계가 실패하고 있는가

packet을 도입했는데도 운영 체감이 좋아지지 않는 팀은 보통 비슷한 신호를 보입니다.

• handoff를 받는 쪽이 첫 5분을 읽기와 재해석에만 쓴다.
• next_action이 명령이 아니라 배경 설명 문단으로 변한다.
• 완료 항목에 receipt나 테스트 결과 링크가 없다.
• constraints가 금지 범위보다 일반 원칙 문장으로 채워진다.
• stale packet이 계속 재사용되는데도 아무도 경고를 받지 않는다.

이 다섯 가지 중 두세 개만 보여도 packet은 사실상 transcript의 다른 이름이 됩니다. 그래서 저는 도입 초기에 handoff_recovery_time뿐 아니라, 첫 질문이 몇 번 다시 발생하는지도 같이 보는 편을 추천합니다. 같은 packet을 받은 실행자가 계속 “지금 뭘 해야 하지?”, “이건 승인된 범위인가?”, “어느 artifact가 최신인가?“를 다시 묻는다면 구조가 아직 약한 겁니다.

7) 4주 도입 플랜

1주차: handoff 실패 사례 10건 수집
재조사, 중복 실행, 범위 초과, 오래된 artifact 사용 같은 문제를 유형별로 나눕니다. 이때 단순 불편이 아니라 왜 다음 실행자가 바로 착수하지 못했는가를 같이 기록해야 합니다.

2주차: 최소 packet 스키마와 TTL 정의
current_state, constraints, artifacts, next_action만 먼저 강제해도 좋습니다. 특히 fresh_until을 빠뜨리지 않는 것이 중요합니다.

3주차: validation 연결
approval, lease, receipt, snapshot과 packet을 연결해 유효성 검사를 붙입니다. 이 단계에서 Stateful Sandbox Snapshot이나 Action Lineage Graph 같은 추적 계층과 엮으면 운영 체감이 훨씬 좋아집니다.

4주차: 리뷰와 검색 인덱스 연결
사람이 packet 기준으로 리뷰하고, 나중에 packet 단위로 재검색할 수 있게 합니다. 검색이 transcript 전체가 아니라 packet 단위로 되기 시작하면, 같은 유형의 handoff 실패를 훨씬 빠르게 학습할 수 있습니다.

트레이드오프/주의점

1. packet을 너무 크게 만들면 다시 transcript가 된다
   요약을 구조화하지 못하면 오히려 중복 문서만 생깁니다.

2. TTL 없는 packet은 조용히 낡는다
   오래된 승인, 오래된 snapshot, 오래된 테스트 결과를 들고 다음 실행자가 시작하면 사고가 납니다.

3. 사람 책임과 자동 검증 책임을 분리해야 한다
   런타임이 채울 필드와 사람이 해석할 필드를 섞으면 운영 비용이 커집니다.

4. packet만 있고 receipt, lease, snapshot 연결이 없으면 반쪽짜리다
   작업 전달은 정리됐는데 실행 가능성 검증이 안 되면 결국 다시 사람이 해석해야 합니다.

5. 모든 작업에 동일 포맷을 강요하면 반발이 생긴다
   멀티스텝, 장시간, 멀티실행자 작업부터 적용해야 효과가 큽니다.

체크리스트 또는 연습

체크리스트

• handoff를 transcript 전달이 아니라 작업 상태 전달로 보고 있다.
• current_state, constraints, artifacts, next_action이 분리돼 있다.
• approval, lease, snapshot, receipt 같은 경계 정보가 packet에 연결된다.
• packet TTL과 stale 재검증 규칙이 있다.
• 열린 TODO 수와 evidence 수를 제한해 packet 비대화를 막는다.
• handoff recovery time과 ambiguous handoff rate를 측정한다.

연습 과제

1. 최근 멀티스텝 작업 3개를 골라, 실제 transcript handoff가 어디서 애매했는지 상태/제약/산출물/다음 행동 네 칸으로 다시 써보세요.
2. 승인 대기 뒤 재개되는 작업 1개를 골라, fresh_until을 몇 분으로 둘지 근거와 함께 정해보세요.
3. 조사 에이전트에서 수정 에이전트로 넘어가는 흐름을 가정하고, 다음 실행자가 5분 안에 착수할 수 있는 packet 예시를 직접 만들어 보세요.

관련 글

• Context Contract Registry
• Execution Receipt
• Capability Lease
• Stateful Sandbox Snapshot
• Action Lineage Graph
• Harness Engineering