Molayo

© 2026 Molayo

Zenn헤드라인2026. 05. 16. 10:03

handoff.md로 충분할까? AI 에이전트의 작업 인수인계에 A2CR을 사용하는 이유

요약

AI 에이전트의 작업 인수인계 시, 단순한 로컬 파일(`handoff.md`)은 작은 단발성 작업에는 충분하지만, 작업 기간이 길어지거나 여러 AI 클라이언트를 거치게 되면 한계를 드러냅니다. A2CR(Agent-to-Agent Context Relay)은 이러한 문제를 해결하기 위해 '작업 상태'와 '보조 메모'를 분리하는 MCP 대응 레이어를 제공합니다. 핵심 개념인 WorkBaton에는 다음 작업에 필요한 최소한의 상태만 담고, 나머지 보조 정보는 WorkStash로 분리하여 인수인계의 명확성과 안전성을 높입니다.

핵심 포인트

  • 작은 단발성 작업에서는 로컬 `handoff.md`가 가장 간단하고 효과적인 시작점이다.
  • 작업이 복잡해지면, 최신 상태 파악의 어려움, 보조 메모와 핵심 정보의 혼재, 클라이언트 이동 시 수작업 증가 등의 문제가 발생한다.
  • A2CR은 작업 상태(WorkBaton)와 참조용 보조 메모(WorkStash)를 분리하여 인수인계 과정을 구조화하고 자동화하는 레이어이다.
  • A2CR은 비밀 정보 저장소(Secret Manager)가 아니며, 오직 AI 작업을 재개하기 위한 '상태' 전달에 초점을 맞춘다.

AI 에이전트와의 작업이 길어지면, 마지막에 곤란해지는 것은 코드 그 자체가 아니라 「다음 AI에게 무엇을 전달해야 이어서 동작할 수 있는가」 하는 점입니다.

그때, 우선 가장 간단한 방법은 로컬에 handoff.md를 만드는 것입니다.

결론부터 말하자면, handoff.md로 충분하다면 그것으로 충분합니다. 작은 작업, 단발성 조사, 동일한 리포지토리(Repository) 내에서 완결되는 수정이라면 수기로 작성한 인수인계 메모는 상당히 강력합니다.

반면, 작업이 며칠에 걸쳐 이어지거나, Codex / Claude Code / Roo Code와 같은 여러 MCP 대응 클라이언트(Client)를 오가거나, 보조 메모가 늘어나기 시작하면 단순한 handoff.md만으로는 조금씩 힘들어집니다.

이 기사에서는 로컬 handoff.md와 A2CR의 차이점을 가능한 한 공정하게 정리합니다.

우선은 handoff.md로 충분한 상황

handoff.md는 매우 좋은 출발점입니다.

예를 들어, 다음과 같은 메모를 리포지토리에 두는 것만으로도 다음 AI 세션은 상당히 재개하기 쉬워집니다.

# Handoff
Goal: Fix the failing login test.
Current state:
...

이 형태의 장점은 명쾌합니다.

  • 즉시 만들 수 있다
  • 인간이 읽기 쉽다
  • Git으로 차이(Diff)를 추적할 수 있다
  • 추가 도구나 계정이 필요 없다
  • 작업 리포지토리 안에 자연스럽게 둘 수 있다

짧은 작업이라면 우선 handoff.md부터 시작하는 것이 가장 좋습니다. A2CR을 사용하기 전에, 애초에 「대화 이력을 통째로 넘기는 것이 아니라, 작업 상태를 짧게 전달한다」는 습관을 만드는 것만으로도 효과가 있습니다.

handoff.md가 힘들어지는 상황

다만, 수기로 작성한 인수인계 파일은 작업이 길어지면 조금씩 모호해집니다.

최신 상태가 무엇인지 알 수 없게 된다

handoff.md를 업데이트하는 것을 잊거나, 다른 파일에 메모가 늘어나거나, 채팅 측에도 중요한 판단 내용이 남은 채로 있게 됩니다.

그 결과, 다음 AI에게 전달할 때 「이 파일이 정말 최신인가」를 인간이 판단해야 하는 상황이 발생합니다.

보조 메모가 섞이기 쉽다

처음에는 짧은 인수인계 메모였던 것이 점점 다음과 같은 정보로 부풀어 오릅니다.

  • 조사 로그
  • 에러 출력
  • URL 목록
  • 파일 경로 목록
  • 시도했지만 채택하지 않은 안
  • 나중에 볼지도 모르는 메모

물론 이것들은 도움이 될 때가 있습니다. 문제는 다음 AI가 가장 먼저 읽어야 할 「재개에 필요한 상태」와, 필요할 때만 보면 되는 「보조 정보」가 같은 장소에 섞이는 것입니다.

클라이언트를 넘나들면 수작업이 된다

동일한 리포지토리를 열고 있는 상태라면 handoff.md는 편합니다.

하지만 다른 AI 클라이언트, 다른 채팅, 다른 작업 환경으로 옮기면 다음과 같은 수작업이 늘어납니다.

  • 어떤 파일을 읽게 할지 지정하기
  • 최신 메모가 무엇인지 설명하기
  • 긴 보조 메모를 붙여넣을지 말지 판단하기
  • 중요한 판단 내용만 다시 요약하기

이 수작업이 늘어날수록 인수인계의 품질은 인간의 주의력에 의존하게 됩니다.

안전 규칙도 인간의 습관에 의존한다

handoff.md는 자유롭게 쓸 수 있는 만큼 위험한 정보도 들어가기 쉽습니다.

예를 들어, 다음과 같은 것들은 넣어서는 안 됩니다.

  • API 키
  • 비밀번호
  • Authorization 헤더
  • Cookie
  • private database URL
  • .env의 내용
  • 대화 전문
  • 긴 로그
  • 커다란 소스 코드 본문

로컬 파일이라고 해서 무엇을 써도 안전한 것은 아닙니다. 리포지토리에 포함하면 커밋(Commit)이나 공유에 섞일 가능성이 있고, AI에게 읽게 하면 다음 세션의 입력값이 됩니다.

A2CR은 무엇을 바꾸는가

A2CR은 AI 에이전트 간에 작업 상태를 인수인계하기 위한 MCP 대응 레이어(Layer)입니다.

중심에 있는 것은 WorkBaton이라는 작은 인수인계 체크포인트입니다. WorkBaton에는 다음 AI가 재개하기 위해 필요한 정보만을 넣습니다.

반면, 나중에 참조할지도 모르는 보조 메모는 WorkStash로 분리합니다.

WorkBaton = 다음 AI가 가장 먼저 읽는 작업 상태
WorkStash = 필요할 때만 참조하는 보조 메모

이러한 분류를 통해 인수인계의 입구를 작게 유지하기 쉬워집니다.

A2CR은 현재 로컬 stdio MCP wrapper인 a2cr-mcp와 A2CR의 hosted service를 조합하여 사용하는 공개 프리뷰(Public Preview) 단계입니다. 완전히 로컬에서만 완결되는 도구는 아닙니다.

공식 wrapper는 WorkBaton / WorkStash의 본문을 로컬에서 암호화한 후 업로드합니다. hosted service는 암호문을 저장하며, 공식 wrapper를 통해서는 본문의 평문(Plaintext)이나 로컬 client key를 받지 않습니다. 저장 및 재개를 위해서는 A2CR의 API 키와 https://a2cr.app으로의 접속이 필요합니다.

이 경계는 중요합니다. A2CR은 시크릿 매니저(Secret Manager)가 아닙니다. 비밀 정보나 긴 로그를 저장하는 장소가 아니라, AI 작업을 재개하기 위한 상태를 짧게 남기기 위한 도구입니다.

비교표

관점로컬 handoff.mdA2CR
시작 용이성매우 간단함. 파일을 만들기만 하면 됨MCP 설정과 API 키가 필요함
인간의 가독성매우 읽기 쉬움WorkBaton 자체는 읽기 쉽지만, 도구를 통해 다룸
.........

같은 작업을 두 가지 형태로 전달하기

로컬 handoff.md라면 다음과 같이 작성할 수 있습니다.

# Handoff
Goal: Fix login error.
Current state:
...

A2CR의 WorkBaton이라면 동일한 내용을 다음과 같은 형태로 저장합니다.

{
"goal": "Fix login error",
"current_state": "Confirmed the API returns 401 after token refresh.",
...
}

둘 다 본질은 같습니다. 중요한 것은 다음 AI가 작업을 재개할 수 있는 상태로 내용을 압축하는 것입니다.

차이점은 A2CR을 통해 이러한 형식을 MCP 도구의 흐름에 태워, 저장·재개·보조 메모 참조를 하나의 습관으로 다루기 쉽게 만든다는 점입니다.

어떤 것을 선택해야 하는가

저는 처음부터 A2CR을 사용해야 한다고 생각하지는 않습니다.

우선은 handoff.md로 충분한 상황이 있습니다.

  • 일회성인 짧은 작업
  • 동일한 리포지토리(Repository) 내에서 완결되는 작업
  • 사람이 명확하게 최신 메모를 관리할 수 있는 작업
  • 오프라인에서 완결시키고 싶은 작업
  • 아직 MCP 설정을 늘리고 싶지 않은 단계

반면, A2CR이 적합한 상황은 다음과 같습니다.

  • 작업이 며칠에 걸쳐 이어지는 경우
  • 여러 AI 세션(Session)을 오가는 경우
  • Codex / Claude Code / Roo Code 등 여러 MCP 대응 클라이언트를 사용하는 경우
  • 보조 메모가 늘어나 인수인계 메모가 비대해지기 시작한 경우
  • "다음에 어느 상태에서 재개할지"를 명확히 하고 싶은 경우
  • WorkBaton과 WorkStash를 분리하여 보안 규칙도 의식하며 운용하고 싶은 경우

요약

handoff.md는 좋은 출발점입니다. AI 작업 인수인계에서 가장 중요한 것은, 우선 "대화 이력 전체를 넘기는 것"을 그만두고, "다음 AI가 재개하기 위한 작업 상태"를 짧게 전달하는 것입니다.

그 후에 작업이 길어지고, 여러 AI 클라이언트나 며칠에 걸친 작업이 되며, 보조 메모가 늘어난다면 A2CR의 WorkBaton / WorkStash 방식의 분리를 시도해 볼 가치가 있습니다.

작게 시작하려면 handoff.md.

지속적으로 인수인계하려면 A2CR.

그 정도의 거리감을 가지고 생각하는 것이 현재의 공개 프리뷰 단계에는 적절하다고 생각합니다.

링크

AI 자동 생성 콘텐츠

본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0