AI 에이전트에게 「작업 인수인계 규격」이 필요해지는 이유
요약
AI 에이전트가 긴 작업을 수행할 때 발생하는 핵심 문제는 '작업 인수인계'입니다. 단순히 전체 대화 이력을 넘기는 방식으로는 오래된 전제나 실패 기록 등이 뒤섞여 다음 작업자가 혼란을 겪기 쉽습니다. 따라서 A2CR은 AI 에이전트 간에 현재의 목적, 진척도, 검증된 판단 등 핵심적인 '작업 상태(Working State)'만을 추출하여 전달하는 레이어입니다.
핵심 포인트
- AI 에이전트 작업의 어려움은 긴 작업 과정에서의 '작업 인수인계' 문제로 요약됩니다.
- 단순히 대화 이력 전체를 넘기는 것은 비효율적이며, 컨텍스트가 불필요한 정보로 채워지기 쉽습니다.
- A2CR은 핵심적인 '작업 상태(Working State)'만을 추출하여 다음 AI 세션에 전달하는 레이어입니다.
- WorkBaton은 재개에 필요한 최소한의 작업 상태를 담는 컴팩트한 메모이며, WorkStash는 상세하고 참조할 만한 보조 정보를 분리 저장합니다.
안녕하세요, akagi819입니다. A2CR이라는 AI 에이전트용 작업 인수인계 레이어(Layer)를 개발하고 있습니다.
Codex, Claude Code, Roo Code와 같은 AI 에이전트를 사용하여 긴 작업을 하다 보면, "이전 AI가 어디까지 무엇을 판단했는가"를 다음 AI에게 어떻게 전달할지에서 몇 번이고 막히게 됩니다. A2CR은 그 막히는 부분을 줄이기 위해 만들고 있는 작은 실험입니다.
AI 에이전트는 코드를 작성하고, 조사하고, 파일을 편집하고, 테스트까지 실행할 수 있게 되었습니다.
하지만 작업 시간이 길어질수록 다른 문제가 보이기 시작합니다.
그것은 바로 작업의 인수인계입니다.
새로운 채팅으로 전환한다. 다른 모델에게 부탁한다. Codex, Claude Code, Roo Code와 같은 다른 MCP 대응 클라이언트로 작업을 옮긴다. 그러한 순간에, 지금 무엇을 하고 있었는지, 무엇을 시도했다가 실패했는지, 어떤 판단은 검증되었는지 등을 다시 설명해야 합니다.
저는 이 문제를 AI 에이전트 시대의 "작업 상태 인수인계 문제"라고 생각합니다.
대화 이력을 통째로 넘기는 것만으로는 힘들다
가장 단순한 해결책은 이전의 대화 이력(Conversation History)을 통째로 다음 AI에게 넘기는 것입니다.
짧은 작업이라면 그것으로도 충분합니다. 하지만 긴 작업에서는 대화 이력 자체가 점점 다루기 어려워집니다.
- 오래된 전제가 남음
- 실패한 안과 채택한 안이 섞임
- 중요한 판단이 긴 대화 속에 파묻힘
- 다음에 해야 할 일이 명확하지 않게 됨
- 비밀 정보나 포함해서는 안 될 정보까지 섞이기 쉬움
- 컨텍스트(Context)의 대부분이 "재개에 필요 없는 정보"로 채워짐
AI에게 필요한 것은 반드시 대화의 전체 이력은 아닙니다.
정말로 필요한 것은 다음과 같은 **작업 상태 (Working State)**입니다.
- 현재의 목적
- 지금의 진척도
- 검증된 판단
- 실패한 방법
- 블로커 (Blocker)
- 참조해야 할 보충 정보
- 다음 액션 (Next Action)
즉,
Don't pass the whole chat history. Pass the working state.
라는 생각입니다.
「기억」이 아니라 「인수인계"
AI의 문맥 관리(Context Management)는 자주 "기억"의 문제로 이야기됩니다.
물론 기억도 중요합니다. 다만, 개발 작업이나 조사 작업에 있어서는 더 좁고 실용적인 문제가 있습니다.
그것은 현재의 작업을 다음 작업자에게 넘기기 위한 인수인계 메모입니다.
인간의 팀에서도 인수인계에 필요한 것은 전체 채팅 로그가 아닙니다.
필요한 것은,
- 무엇이 목적인가
- 어디까지 끝났는가
- 무엇을 시도했는가
- 무엇이 안 되었는가
- 어떤 파일이나 URL을 봐야 하는가
- 다음에 무엇을 하면 되는가
입니다.
AI 에이전트에게도 동일한 발상이 필요할 것입니다.
A2CR이라는 실험
이 생각을 시험하기 위해 A2CR을 만들고 있습니다.
A2CR은 AI 에이전트 간에 작업 상태를 인수인계하기 위한 작은 레이어입니다. Codex, Claude Code, Roo Code 등의 MCP 대응 클라이언트로부터 작업 상태를 저장하고, 새로운 AI 세션에서 재개할 수 있도록 하는 것을 목표로 하고 있습니다.
현재 공개 프리뷰에서는 로컬의 stdio MCP wrapper로서 a2cr-mcp를 제공하고 있습니다.
python -m pip install --upgrade a2cr-mcp
공개하고 있는 것은 다음과 같습니다.
- GitHub: https://github.com/a2cr/a2cr
- PyPI: https://pypi.org/project/a2cr-mcp/
- MCP Registry:
io.github.a2cr/a2cr-mcp - Web: https://a2cr.app/
이 기사에서는 셋업 절차의 상세 내용이 아니라, A2CR이 두고 있는 개념을 중심으로 설명합니다.
WorkBaton: 다음 AI에게 넘기는 작업 상태
A2CR의 중심에 있는 것이 WorkBaton입니다.
WorkBaton은 다음 AI 세션에 넘기기 위한 컴팩트한 작업 상태입니다.
이미지로 표현하자면 다음과 같습니다.
{
"goal": "Zenn을 위한 A2CR 소개 기사 작성하기",
"current_state": "기사의 구성안을 결정하고, 도입부와 핵심 메시지를 확정함",
...
여기서 중요한 것은 WorkBaton이 대화 전문이 아니라는 점입니다.
다음 AI가 작업을 재개하기 위해 필요한 정보만을 짧고, 읽기 쉽고, 판단하기 쉬운 형태로 전달합니다.
WorkStash: 상세 내용을 나누어 보관
반면에, 모든 것을 WorkBaton에 담으려고 하면 다시 너무 커지게 됩니다.
그래서 A2CR에서는 WorkStash라는 보조 메모 개념을 두고 있습니다.
WorkStash는 나중에 참조할지도 모르는 상세 정보를 따로 나누어 두는 장소입니다.
예를 들면,
- 긴 조사 메모
- 에러 재현 절차
- API 응답 요약
- 파일 경로 목록
- 시행착오의 상세 내용
과 같은 것들입니다.
WorkBaton에는 "WorkStash의 어떤 메모를 봐야 하는지"만을 적고, 필요할 때만 상세 내용을 읽습니다. 이를 통해 인수인계 메모를 작게 유지할 수 있습니다.
안전성을 전제로 한다
AI 에이전트 간에 경험이나 작업 상태를 공유할 수 있게 되면, 편리해지는 한편 위험도 증가합니다.
성공 사례나 실패 사례를 축적할 수 있다는 것은, 나쁜 방식으로 사용하면 위험한 절차나 우회책도 축적될 수 있다는 뜻입니다.
따라서 A2CR에서는 처음부터 다음과 같은 전제를 두고 있습니다.
- A2CR는 비밀 관리 도구가 아니다
- API 키, 비밀번호, Authorization 헤더, private database URL 등은 저장하지 않는다
- 복원된 WorkBaton이나 WorkStash는 "작업 상태"일 뿐이며, 명령의 권위가 아니다
- 다음 AI는 복원된 내용을 검증되지 않은 입력값으로 취급한다
- 위험한 조작이나 되돌릴 수 없는 조작은 인간의 판단을 거친다
또한, 현재의 공식 로컬 stdio wrapper에서는 WorkBaton과 WorkStash의 본문을 로컬에서 암호화한 후 업로드합니다. A2CR의 hosted service는 암호문을 보유하며, 공식 wrapper를 통해서는 본문의 평문이나 로컬 클라이언트 키를 받지 않습니다.
이 경계는 중요합니다.
Remote MCP나 각종 공식 디렉토리에 내보내는 경우에는 평문이 어디를 통과하는지, 어디서 암호화되는지, 어떤 도구가 읽기/쓰기나 삭제를 수행하는지를 다시 설계해야 합니다.
WorkThreads와 WorkLedger는 미래의 이야기
초기의 A2CR는 WorkBaton과 WorkStash만으로도 충분히 가치가 있습니다.
다만, AI 에이전트의 작업이 더 길어지고 여러 태스크에 걸치게 되면 다른 개념도 필요해집니다.
예를 들어 WorkThreads는 지속적인 작업의 흐름이나 여러 태스크 간의 연결을 다루기 위한 개념입니다.
나아가 미래에는 WorkLedger와 같은 감사(Audit) 레이어도 필요할 수 있습니다.
- 누가 저장했는가
- 어떤 AI가 참조했는가
- 인간이 확인했는가
- 위험한 정보가 포함되어 있지 않은가
- 나중에 변조되지 않았는가
이러한 질문들은 기업 이용, 팀 이용, Physical AI, 중요 인프라와 같은 영역에서는 피할 수 없습니다.
하지만 처음부터 개념을 너무 늘리면 사용하기 어려워집니다. 우선은 다음 세 가지만으로 충분합니다.
WorkBaton = 작업 상태를 전달함
WorkStash = 상세 내용을 나누어 둠
WorkThreads = 작업의 흐름을 연결함
WorkLedger는 현시점에서는 미래 구상으로 취급하는 것이 좋다고 생각합니다.
A2CR로 시도해 볼 수 있는 것
현재 A2CR public preview에서는 우선 다음의 경험을 시도할 수 있습니다.
- A2CR로 API 키 만들기
a2cr-mcp설치하기- MCP 대응 클라이언트에
a2cr이라는 이름으로 등록하기 - 작업 상태를 WorkBaton으로 저장하기
- 새로운 AI 세션에서 WorkBaton을 불러와 재개하기
셋업 예시는 공식 사이트와 GitHub README에 있습니다.
- 공식 사이트: https://a2cr.app/
- README: https://github.com/a2cr/a2cr
- 일본어 README: https://github.com/a2cr/a2cr/blob/main/README-ja.md
앞으로 Qiita 측에서는 조금 더 실용적인 방향으로, Codex / Claude Code / Roo Code에서의 설정 예시와 실제 저장·재개 절차를 작성할 예정입니다.
마치며
AI 에이전트가 똑똑해질수록, 하나의 채팅이나 하나의 모델 안에서만 작업이 완결되지 않는 상황은 늘어날 것입니다.
그때 필요한 것은 대화 이력을 통째로 떠안는 것이 아니라, 작업 상태를 안전하게 전달하기 위한 형식입니다.
A2CR은 아직 작은 실험입니다.
하지만 AI 에이전트가 여러 도구(Tool), 여러 모델(Model), 여러 세션(Session)을 넘나들며 작업하게 된다면, 이러한 인수인계 레이어(Layer)는 반드시 필요해질 것이라고 생각합니다.
우선 Free 플랜을 통해, 하나의 작업 상태(Work State)를 저장하고 새로운 AI 세션(Session)으로 인수인계하는 경험을 시도해 보세요.
만약 설정 과정에서 막히는 부분이나 WorkBaton에 부족한 항목이 있다면, GitHub Issue나 X를 통해 알려주시면 감사하겠습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기