AI 에이전트에게 handoff.md가 더 이상 충분하지 않을 때
요약
장기적인 AI 에이전트 작업에서 초기에는 `handoff.md`와 같은 로컬 파일이 유용한 '작업 상태' 전달 수단이지만, 프로젝트가 복잡해지고 시간이 지남에 따라 이 방식은 관리하기 어려워집니다. 문제는 파일 자체가 아니라, 여러 노트, 이슈, 스크래치 파일 등 주변의 방대한 정보들이 쌓여 핵심 재개 지점(checkpoint)이 노이즈 속에 묻히는 현상입니다. 따라서 AI 에이전트가 다음 작업을 수행할 때 '명시적인 체크포인트'를 제공하는 것이 중요하며, 이는 단순한 마크다운 파일을 넘어선 구조화된 접근 방식을 요구합니다.
핵심 포인트
- AI 에이전트 작업의 핵심은 전체 대화 기록 전달이 아닌, 목표(Goal), 현재 상태(Current State), 결정 사항(Decisions) 등 구조화된 '작업 상태'를 전달하는 것이다.
- 초기에는 `handoff.md`가 유용하지만, 장기 프로젝트에서는 여러 노트와 정보들이 쌓여 핵심 재개 지점이 모호해지는 문제가 발생한다.
- AI 에이전트 작업의 핸드오프는 단순히 파일 위치의 문제가 아니라, 다음 에이전트가 명확하게 재개해야 할 '명시적인 체크포인트'를 정의하는 문제이다.
- 핸드오프 노트에는 API 키, 비밀번호, 전체 채팅 기록 등 민감하거나 방대한 정보(노이즈)를 포함해서는 안 된다.
만약 당신이 장기적인 AI 에이전트 작업을 수행하고 있다면, 가장 먼저 시도해야 할 핸드오프 (handoff) 도구는 아마 서비스가 아닐 것입니다. 그것은 바로 파일입니다. 당신의 저장소 (repository)에 handoff.md를 생성하고 다음 AI 세션이 알아야 할 내용을 작성하세요:
핸드오프 목표 (Handoff Goal): 실패하는 로그인 테스트 수정
현재 상태 (Current state):
- 토큰 갱신 후 401 에러 재현됨.
- 갱신 (refresh) 브랜치가 원인일 가능성이 높음.
시도한 내용 (Tried): - 픽스처 (fixture) 업데이트를 시도했으나 해결되지 않음.
결정 사항 (Decision): - 아직 데이터베이스 스키마 (database schema)를 변경하지 말 것.
다음 작업 (Next action): - src/auth 갱신 로직을 조사하고 집중 테스트를 다시 실행할 것.
많은 작업에서 이것만으로도 충분합니다. 이것은 로컬 (local)에 있고, 읽기 쉬우며, Git과 함께 작동합니다. 또 다른 계정, 또 다른 대시보드 (dashboard), 또는 당신의 툴체인 (toolchain) 내의 또 다른 움직이는 구성 요소를 필요로 하지 않습니다. 그 습관 하나만으로도 다음 AI 세션에 전체 채팅 기록을 붙여넣는 것보다 이미 더 낫습니다.
하지만 더 긴 코딩 작업에 AI 에이전트를 사용한 후, 저는 계속해서 동일한 문제에 부딪혔습니다. handoff.md는 단순하게 시작되지만, 점차 당신이 수동으로 관리해야 하는 또 다른 무언가로 변하기 시작합니다. 그것이 바로 제가 A2CR을 구축한 영역입니다.
handoff.md가 잘하고 있는 점
로컬 핸드오프 파일은 유용한 규율을 강제하기 때문에 훌륭한 시작점입니다: 대화 전체를 전달하지 말고, 작업 상태 (working state)를 전달하십시오. 다음 AI 세션은 보통 이전에 발생한 모든 프롬프트 (prompt), 모든 실패한 명령, 모든 스택 트레이스 (stack trace), 그리고 모든 논의 내용을 필요로 하지 않습니다. 대신 다음과 같은 더 작은 형태가 필요합니다:
- 목표 (goal)
- 검증된 현재 상태 (current state)
- 결정 사항 (validated decisions)
- 피해야 할 실패한 시도들 (failed attempts worth avoiding)
- 차단 요소 (blockers)
- 참조 (references)
- 검증 상태 (validation status)
- 다음 작업 (the next action)
이러한 형태는 마크다운 (Markdown)으로 작성하기 쉽습니다. 또한 사람이 검토하기에도 쉽습니다. 따라서 짧은 작업, 단일 저장소, 하나의 활성 AI 클라이언트, 그리고 명확한 최신 노트가 있다면, handoff.md가 당신에게 필요한 전부일 수 있습니다.
문제가 발생하는 지점
문제는 handoff.md가 나쁘다는 것이 아닙니다. 문제는 장기적으로 실행되는 AI 작업이 그 주변에 압박을 가한다는 것입니다.
최신 상태가 모호해짐
처음에는 파일이 하나뿐이고 모두가 그것이 핸드오프 파일임을 알고 있습니다.
나중에는 채팅 내의 노트, 이슈 (issues) 내의 노트, 스크래치 파일 (scratch files) 내의 노트, handoff.md 내의 오래된 섹션들, 그리고 어제는 맞았지만 오늘은 더 이상 맞지 않는 몇 가지 가정들이 존재할 수 있습니다. 새로운 AI 세션이 시작될 때, 누군가는 여전히 다음 질문에 답해야 합니다: '어떤 상태가 의도된 재개 지점인가?' 만약 그 답이 사람이 모든 것을 읽고 무엇이 현재 상태인지 결정하는 것에 달려 있다면, 핸드오프 (handoff)는 다시 수동적인 방식이 되어버린 것입니다.
보조 노트가 재개에 중요한 상태와 섞임
긴 작업은 다음과 같은 유용한 보조 세부 정보를 생성합니다:
- 조사 노트 (investigation notes)
- 에러 출력 (error outputs)
- 링크 (links)
- 파일 목록 (file lists)
- 거부된 접근 방식 (rejected approaches)
- 설정 관찰 사항 (setup observations)
- "나중에 유용할지도 모를" 컨텍스트 (context)
이 정보 중 일부는 중요하지만, 그 전부가 다음 AI가 가장 먼저 읽어야 할 내용에 포함되어서는 안 됩니다. 모든 것이 하나의 마크다운 (Markdown) 파일에 들어가게 되면, 압축된 재개 노트는 또 다른 노이즈가 가득한 문서가 될 수 있습니다.
클라이언트 간 핸드오프 시 마찰 발생
한 대의 머신에서 하나의 리포지토리 (repository) 내에 머문다면 로컬 파일이 편리합니다. 하지만 AI 에이전트 (AI-agent) 작업은 종종 다음과 같이 이동합니다:
- 하나의 AI 세션에서 다른 세션으로
- 하나의 MCP 지원 클라이언트에서 다른 클라이언트로
- 로컬 코딩 세션에서 원격 또는 브라우저 기반 워크플로우로
- 오늘의 작업에서 며칠 후의 연속 작업으로
이 시점에서 핸드오프는 "파일이 어디에 있는가?"의 문제라기보다 "다음 에이전트가 재개해야 할 명시적인 체크포인트 (checkpoint)가 무엇인가?"의 문제가 됩니다.
안전성은 메모리에 달려 있음
마크다운 파일은 그 안에 넣는 무엇이든 저장합니다. 이러한 유연성은 유용하지만, 매번 규율이 필요하다는 것을 의미하기도 합니다. 다음과 같은 항목들은 핸드오프 노트에 넣어서는 안 됩니다:
- API 키 (API keys)
- 비밀번호 (passwords)
- 액세스 토큰 (access tokens)
- 권한 헤더 (Authorization headers)
- 쿠키 (cookies)
- 프라이빗 데이터베이스 URL (private database URLs)
- 로컬 클라이언트 키 (local client keys)
- 전체 채팅 트랜스크립트 (full chat transcripts)
- 긴 로그 (long logs)
- 방대한 소스 코드 본문 (large source-code bodies)
이는 핸드오프가 로컬 파일이든 도구 기반의 체크포인트이든 마찬가지입니다. 차이점은 도구 흐름 (tool flow)을 통해 경계를 더 명시적이고 반복 가능하게 만들 수 있다는 점입니다.
A2CR이 추가하는 것
A2CR은 AI 에이전트를 위한 MCP 호환 핸드오프 레이어 (handoff layer)입니다. 핵심 아이디어는 여전히 동일합니다: 전체 채팅 기록을 전달하지 마세요. 작업 상태 (working state)를 전달하세요.
A2CR는 해당 작업 상태 (working state)에 더 의도적인 구조를 부여할 뿐입니다. 오늘 소개할 주요 개념은 다음과 같습니다:
- WorkBaton: 다음 AI 세션이 재개해야 할 압축된 체크포인트 (checkpoint)
- WorkStash: 세부 사항이 체크포인트를 너무 크게 만들 경우, WorkBaton에서 참조하는 임시 지원 노트 (supporting notes)
다시 말해:
WorkBaton = 다음 AI가 가장 먼저 읽어야 할 것
WorkStash = 필요할 때만 열어보는 지원 노트
이러한 분리가 중요한 이유는 새로운 AI 세션의 초기 몇 초가 매우 중요하기 때문입니다. 만약 재개 노트 (resume note)가 너무 광범위하면, 에이전트 (agent)가 오래된 가정이나 무관한 세부 사항에 휘말릴 수 있습니다.
호스팅 서비스 경계 (The Hosted-Service Boundary)
한 가지 중요한 경계가 있습니다: A2CR는 완전히 로컬 전용이거나 오프라인 전용인 도구가 아닙니다. 현재 공개 프리뷰 (public preview) 버전은 https://a2cr.app 에 있는 호스팅된 A2CR 서비스를 기반으로 하며, 로컬 stdio MCP 래퍼 (wrapper)인 a2cr-mcp를 사용합니다. 공식 래퍼는 업로드 전 로컬에서 WorkBaton과 WorkStash 본문을 암호화합니다. 호스팅 서비스는 암호문 (ciphertext)을 저장합니다. 핸드오프 (handoff)를 저장하고 재개하려면 A2CR API 키와 호스팅 서비스에 대한 액세스가 필요합니다. A2CR은 비밀 관리자 (secret manager)가 아니며, 가공되지 않은 로그 (raw logs), 자격 증명 (credentials), 또는 전체 채팅 기록을 보관하는 장소도 아닙니다.
링크
A2CR 앱: https://a2cr.app/
GitHub: https://github.com/a2cr/a2cr
사용 가이드: https://github.com/a2cr/a2cr/blob/main/docs/usage.md
MCP 설정: https://github.com/a2cr/a2cr/blob/main/docs/mcp-setup.md
Zenn의 일본어 비교 기사: https://zenn.dev/a2cr/articles/86612e29894ea6
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기