대부분의 멀티 에이전트 워크플로는 어려운 작업 자체에서 실패하지 않습니다. 에이전트는 코드를 작성하고, 테스트를 실행하며, 풀 리퀘스트(PR)를 생성합니다. 정작 실패가 발생하는 곳은 바로 작업과 작업 사이의 ‘이음새’, 즉 한 에이전트가 끝낸 작업이 다음 대상으로 넘어가야 하는 순간입니다. 백엔드 에이전트가 엔드포인트 구현을 마쳐도 프론트엔드 에이전트는 준비가 끝났다는 사실을 전혀 알지 못합니다. 리팩터링 작업이 워크트리에 반영되어 테스트를 통과(green)한 채 그대로 방치되기도 합니다. 확인해야 할 사람에게 아무런 알림도 가지 않았기 때문입니다. 문제가 생긴 것은 작업이 아닙니다. 바로 ‘핸드오프(인수인계)’가 실패한 것입니다.
AI 에이전트 핸드오프란 작업 결과물과 그 맥락(context)을 다음 작업자에게 전달하는 과정을 의미합니다. 에이전트에서 에이전트로 전달될 수도 있고, 에이전트에서 사람으로 전달될 수도 있습니다. 하나의 터미널에서 코딩 에이전트 한 대만 실행할 때는 인수인계할 대상이 없으므로 핸드오프가 눈에 띄지 않습니다. 하지만 에이전트 두 대를 실행하거나 에이전트 한 대와 리뷰어 한 명을 두는 순간부터, 완료된 모든 작업 단계는 다음 작업자가 찾을 수 있는 어딘가에 안착해야 합니다. 그리고 이 ‘안착 지점’을 어떻게 마련하느냐가 성패를 좌우합니다.
이 글에서는 실제 실무 환경에서 안정적으로 작동하는 핸드오프 패턴을 살펴봅니다. 여기서는 코딩 에이전트 상위에서 동작하며 요청부터 릴리스까지 맥락, 진행 상황, 차단 요소(blocker), 결과물, 그리고 사람의 검토 과정을 투명하게 가시화하는 워크플로 레이어인 Sharkly를 바탕으로 설명합니다. 여러분은 이미 코딩 에이전트를 사용하고 계실 것입니다. 이 글이 다루는 핵심 문제는 바로 에이전트 사이의 '공백'에서 발생하는 일들을 해결하는 것입니다.
핵심 요약
핸드오프는 작업과 그 맥락이 한 작업자에서 다음 작업자로 이동하는 접점입니다. 에이전트 간 핸드오프는 완료된 하위 작업(sub-task)을 다음 에이전트로 넘겨주며, 에이전트-사람 간 핸드오프는 자율 작업을 검토 게이트에서 멈추도록 합니다. 이 두 가지를 상태(status)를 통해 명확히 구분하세요. 에이전트는 태스크(Task)를 Ready for review로 이동시키고, 사람은 이를 Done으로 이동시킵니다. 핸드오프가 터미널 속 메시지가 아닌 공유된 태스크의 상태 변경으로 이루어지면, 어떤 작업도 조용히 누락되지 않습니다.
에이전트 핸드오프란 정확히 무엇인가
핸드오프는 세 가지 요소로 구성되며, 이 중 하나라도 빠지면 작업이 유실됩니다. 바로 아티팩트(diff, PR, 마이그레이션 등), 맥락(요청 사항, 변경 사항, 아직 불확실한 부분), 그리고 수신자(다음 단계를 담당할 특정 에이전트 또는 사람)입니다.
터미널 기반 워크플로는 아티팩트만 전달하고 나머지 두 가지를 잃어버립니다. 커밋은 존재하지만 그 판단 근거는 에이전트 한 대만 보았던 스크롤백 버퍼 속에 남겨지며, '다음 담당자'는 우연히 터미널을 확인한 누군가가 됩니다. 에이전트 오케스트레이션에서 중요한 것이 단순히 에이전트를 실행하는 일이 아니라, 에이전트가 만들어낸 결과물을 올바르게 라우팅하는 일인 이유가 바로 여기에 있습니다.
깔끔한 핸드오프는 이 세 가지를 함께 전달합니다. 즉, 변경 사항, 완료된 작업과 완료되지 않은 작업에 대한 요약, 그리고 다음 수신자의 차례임을 알리는 명확한 시그널입니다. Sharkly 기준으로 설명하자면 실행 내용, 차단 요소, 결과물, 후속 논의가 모두 태스크 타임라인으로 모이기 때문에, 다음 작업자는 세 군데를 번거롭게 재구성할 필요 없이 하나의 기록만 확인하면 됩니다.
두 가지 핸드오프 패턴
두 패턴은 겉보기에 비슷해 보이지만 기본 동작 방식은 정반대입니다. 에이전트 간 핸드오프는 자동으로 흘러가야 합니다. 다음 에이전트가 준비된 하위 작업을 가져와 계속 작업을 진행합니다. 반면 에이전트-사람 간 핸드오프는 기본적으로 멈춰 서야 합니다. 사람이 직접 판단하고 결정해야 하므로, 에이전트는 맡은 부분을 완료한 뒤 대기해야 합니다.
| 에이전트 간 | 에이전트-사람 간 | |
|---|---|---|
| 트리거 | 하위 작업이 준비 완료로 표시됨 | 작업이 검토 게이트에 도달함 |
| 기본 동작 | 자동으로 계속 진행 | 중단 후 대기 |
| 전달 항목 | 아티팩트 + 맥락 + 인수 조건 | Diff + 변경 사항 요약 + 알려진 한계점 |
| 누락 시 위험 | 중복 작업 또는 충돌 발생 | 검토되지 않은 코드가 그대로 병합됨 |
혼선을 방지하기 위한 명확한 판단 기준은 다음과 같습니다. 다음 단계가 명확하게 정의되어 있고 "테스트 스위트 실행", "마이그레이션 생성", "OpenAPI 사양 업데이트"처럼 인수 조건이 이미 작성되어 있다면 에이전트 간 핸드오프를 자동화하세요. 반면 다음 단계에 에이전트가 자체적으로 결정할 수 없는 판단이 필요한 경우, 즉 main 브랜치 병합, 퍼블릭 인터페이스 변경, 인증이나 결제 로직 수정, 최종 결과 승인 등에는 에이전트-사람 간 핸드오프를 필수로 적용해야 합니다.
흔히 저지르는 실수는 모든 핸드오프를 동일하게 다루는 것입니다. 모든 것을 자동으로 흘러가게 두면 검토되지 않은 작업이 병합되고, 반대로 모든 단계에 게이트를 두면 불필요한 단계만 늘어난 느린 수동 파이프라인을 다시 만드는 꼴이 됩니다. 이는 사소한 작업마다 멈추는 것이 아니라 비용이 많이 드는 치명적인 실수 직전에 에이전트를 멈추게 하는 승인 게이트 배치 위치를 파악하는 것과도 맞닿아 있습니다.
상태(Status): 핸드오프를 막연한 기대가 아닌 확실한 게이트로 만드는 방법
운영 모델은 결국 네 가지 핵심 동사와 각 역할의 주체로 귀결됩니다. 즉 누가 할당하고, 누가 실행하며, 누가 검토하고, 누가 승인하는가입니다. 에이전트는 조사, 실행, 테스트, 보고를 담당합니다. 사람은 방향을 설정하고, 권한을 부여하며, 결과를 최종 승인합니다. 팀 차원의 판단이 필요한 지점에서 자동화는 멈춰야 합니다.
상태(Status)는 이러한 원칙을 단순한 바람에 그치지 않고 시스템적으로 작동하게 만드는 장치입니다. 모든 태스크는 동일한 흐름을 거칩니다.
- Todo: 할당되었으나 아직 시작되지 않은 상태입니다. 사람 또는 리더 에이전트가 이곳에 등록합니다.
- In progress: 에이전트가 작업을 가져가 격리된 워크트리에서 작업 중인 상태입니다.
- Ready for review: 에이전트의 책임 경계입니다. 타입 체크, 테스트, 빌드를 실행하고 변경 사항 요약과 알려진 한계점을 첨부한 뒤 작업을 멈춥니다.
- Done: 사람의 책임 경계입니다. 담당자가 결과를 승인하고 병합 및 릴리스를 결정한 상태입니다.
전체 워크플로를 명확하게 유지해 주는 핵심 규칙은 다음과 같습니다. 에이전트는 태스크를 Ready for review로 이동시키고, 사람은 이를 Done으로 이동시킵니다. 에이전트는 결코 자신의 작업을 스스로 Done으로 표시하지 않으며, 사람 역시 테스트를 통과(green)한 태스크가 정말 안전한지 막연히 짐작할 필요가 없습니다. 상태 자체가 곧 핸드오프입니다. 10대의 에이전트가 실행 중일 때 10개의 터미널을 일일이 확인할 필요가 없습니다. 보드 하나만 보면 내 검토를 기다리는 작업, 다른 에이전트를 기다리는 작업, 현재 실행 중인 작업이 무엇인지 한눈에 알 수 있습니다. 이러한 가시성은 에이전트가 완료한 작업을 실시간으로 추적하는 것과 나중에 커밋 로그만 보고 상황을 짐작해야 하는 것의 결정적인 차이입니다.
실전 적용 사례: 티켓 생성부터 PR 병합까지
실제 업무 형태의 태스크인 SH-312 "공개 API에 속도 제한(rate limiting) 추가"를 예로 들어보겠습니다. 코드 자체가 아니라 핸드오프가 어떻게 일어나는지 주목해 보세요.
사람이 요구사항을 자연어로 작성하여 할당합니다. 리더 에이전트는 코드베이스와 이전 작업 기록을 조사하고 작업 범위와 인수 조건(API 키별 제한, Retry-After 헤더와 함께 429 반환, 트래픽이 가장 많은 상위 3개 엔드포인트 지원)을 작성한 뒤, SH-312를 실행 가능한 세 개의 하위 작업으로 분할합니다. 이것이 첫 번째 에이전트 간 핸드오프입니다. 목표가 입력되고, 바로 실행할 수 있는 하위 작업들이 도출됩니다.
하위 작업은 자동으로 이어집니다. 백엔드 에이전트가 속도 제한 로직을 가져가고, 테스트 에이전트가 테스트 작성을 가져갑니다. 각 에이전트는 격리된 워크트리에서 실행되므로 같은 파일에서 충돌하지 않으며, 각 결과물은 개별 세션이 아닌 SH-312로 반환됩니다. 백엔드 에이전트는 작업을 마쳤을 때 사람을 호출하지 않습니다. 하위 작업을 준비 완료로 표시하면, 테스트 에이전트가 스텁(stub) 대신 실제 구현 코드를 가져와 테스트 작업을 진행합니다.
이후 핸드오프 유형이 전환됩니다. 속도 제한 로직이 작성되고, 타입 체크 통과, 테스트 통과, 빌드 성공(green)이 확인되면 작업은 에이전트-사람 검토 게이트에 도달합니다. 에이전트는 SH-312를 Ready for review로 이동시키고 diff, 변경 사항 요약, 그리고 한 가지 알려진 한계점("Redis 기반 카운터는 단일 리전을 전제로 함. 멀티 리전 대응은 후속 작업 필요")을 첨부합니다. 사람은 한곳에서 이를 확인하고 429 동작을 검증한 뒤 태스크를 Done으로 이동시키며, 이에 따라 병합이 트리거됩니다. 티켓 생성부터 PR 병합까지 모든 이음새마다 누가 무엇을 했는지 기록이 남습니다. 이것이 바로 처음부터 끝까지 추적 가능한 요구사항에서 코드까지의 경로입니다.
핸드오프가 실패하는 원인과 해결 방안
핸드오프는 예측 가능한 세 가지 방식으로 실패하며, 각각은 '주의하기' 식의 다짐이 아닌 구조적인 해결책을 필요로 합니다.
맥락의 증발: 에이전트는 자신이 왜 그런 결정을 내렸는지 알지만, 리뷰어는 알지 못합니다. 해결책: 나중에 덧붙이는 것이 아니라 Ready for review로 이동하는 과정 자체에 변경 사항 요약과 알려진 한계점을 반드시 포함하도록 합니다. 소유권의 모호함: 두 에이전트가 같은 작업을 가져가거나, 아무도 가져가지 않는 문제가 발생합니다. 해결책: 모든 태스크와 하위 작업에 담당자(Assignee)를 지정하여 '다음 차례'가 모호한 분위기가 아니라 명확한 필드 값으로 관리되도록 합니다. 리뷰 누락: 아무도 멈추라고 지시하지 않아 자율 작업 결과물이 검토 없이 병합됩니다. 해결책: 에이전트가 단독으로는 넘어설 수 없는 검토 상태 단계를 둡니다.
워크트리, 네이밍 규칙, 팀의 철저한 규율을 통해 이 모든 것을 직접 수동으로 구축할 수도 있습니다. 하지만 에이전트, 태스크, 리포지토리 수가 늘어나면 이러한 규율은 가장 먼저 무너지기 마련입니다. 이미 여러 에이전트를 운영하고 있다면, Sharkly를 통해 태스크와 결과를 한곳에서 관리할 수 있습니다. 공유 태스크, 태스크별 담당자 지정, 격리된 워크트리, 그리고 에이전트는 Ready for review까지만 도달하고 사람은 Done을 결정하는 상태 레인을 제공합니다. 현재 사용 중인 코딩 에이전트는 그대로 두고, 에이전트 간 핸드오프를 투명하게 시각화하는 레이어만 더해 보세요. 에이전트 사이의 이음새를 관리하는 비용이 작업 자체의 비용보다 커지기 시작했다면 Sharkly를 다운로드해 보세요.
자주 묻는 질문 (FAQ)
AI 에이전트 핸드오프란 무엇인가요? 작업 결과물과 그 맥락, 그리고 이제 다음 사람의 차례라는 신호를 다음 작업자에게 전달하는 과정입니다. 완료된 하위 작업이 다음 에이전트로 이어지는 '에이전트 간(agent-to-agent)' 전달과, 자율 작업이 검토 게이트에서 멈추는 '에이전트-사람 간(agent-to-human)' 전달 두 가지 형태가 있습니다.
에이전트 간 핸드오프와 에이전트-사람 간 핸드오프의 차이점은 무엇인가요? 에이전트 간 핸드오프는 다음 단계의 인수 조건이 이미 정의되어 있을 때 자동으로 계속 진행되어야 합니다. 반면 에이전트-사람 간 핸드오프는 병합, 퍼블릭 인터페이스 변경, 최종 결과 승인 등 사람이 직접 판단을 내려야 하므로 작업을 멈추고 대기해야 합니다.
에이전트가 자신의 작업을 직접 완료(Done)로 표시해도 되나요? 안 됩니다. 에이전트는 테스트를 실행하고 요약본을 첨부한 뒤 태스크를 Ready for review로 이동시키는 역할까지만 수행해야 하며, Done으로의 이동과 최종 병합 결정은 사람에게 맡겨야 합니다. 이 두 경계를 분리해야만 검토되지 않은 코드가 배포되는 사고를 방지할 수 있습니다. 자세한 내용은 인간 참여형(human-in-the-loop) 코딩 에이전트를 참고하세요.
상태(Status) 관리가 어떻게 작업 누락을 방지하나요? 핸드오프가 터미널 메시지가 아닌 공유 태스크의 상태 변경으로 이루어지면, 다음 작업자는 자신을 기다리고 있는 작업이 무엇인지 명확하게 확인할 수 있습니다. 적절한 순간에 누군가 터미널 스크롤을 제때 확인해주기만을 바랄 필요가 없습니다. 에이전트 수신함(agent Inbox)을 통해 사람의 확인이 필요한 작업들을 즉시 확인할 수 있습니다.
이를 위해 별도의 도구가 필요한가요, 아니면 수동으로도 가능한가요? 워크트리와 공유 보드를 활용해 수동으로도 운영할 수 있습니다. 하지만 여러 리포지토리에서 여러 에이전트를 조율해야 하고 수동 추적이 병목이 되기 시작하면 전용 레이어를 도입하는 것이 훨씬 효과적입니다. 결정하기 전에 보조 도구(Assistant)와 팀원(Teammate) 멘탈 모델 비교를 참고해 보세요.
