Handoff 큐: 사람 판단이 남은 작업만 따로 빼기

2026년 5월 6일 | 바이브코딩 Tips

---

코딩 에이전트가 작업을 넘길 때 가장 흐려지는 건 결과물이 아니라 남은 판단의 위치다. 파일은 바뀌었고 테스트도 몇 개 돌았는데, 다음 사람이 다시 열었을 때 “그래서 내가 먼저 봐야 하는 게 뭐지?”에서 시간이 새는 경우가 꽤 많다. 나는 이걸 그냥 TODO 목록으로 남기면 다시 섞인다는 쪽에 가까워졌다. 그래서 요즘은 handoff를 남길 때 TODO가 아니라 handoff 큐를 따로 만든다.

여기서 말하는 큐는 거창한 시스템이 아니다. 에이전트가 끝냈다고 말한 뒤에도 사람 판단이 남은 항목을 같은 종류끼리 묶어 두는 작은 장부다. “테스트 더 돌리기”, “요구사항 다시 묻기”, “배포 전 위험 보기”, “나중에 읽을 자료”를 한 줄에 몰아넣지 않고, 다음 행동의 성격별로 분리한다. 이 차이가 작아 보여도 긴 세션을 두 번 이어 붙일 때 꽤 크게 느껴진다.

handoff 큐를 따로 두는 이유

에이전트 작업의 마지막 답변은 보통 잘 정돈되어 있다. 문제는 정돈된 말이 실제 의사결정 순서와 같지 않다는 데 있다. “A를 수정했고, B를 검증했고, C는 남았습니다”라는 문장은 읽기에는 편하지만, 다음 실행자가 바로 무엇을 눌러야 하는지까지 보장하지 않는다. 특히 모바일 빌더, 웹 IDE, 브라우저 에이전트처럼 preview와 코드 변경이 같이 움직이는 작업에서는 남은 항목의 종류가 섞이는 순간 재개 비용이 올라간다.

내 기준에서 handoff 큐의 목적은 완벽한 기록이 아니라 다음 첫 행동을 좁히는 것이다. 다음 사람이 테스트부터 돌려야 하는지, 요구사항을 먼저 확인해야 하는지, 위험한 변경을 되돌릴 기준을 봐야 하는지, 아니면 그냥 배경 자료로 미뤄도 되는지를 한눈에 갈라 주면 된다. 전체 맥락을 길게 요약하려고 하면 오히려 다시 읽어야 할 문서가 하나 더 생긴다.

Figure 1. 작업 세션의 마지막 답변을 바로 믿기보다, 남은 판단을 네 칸 큐로 나눠 다음 실행 순서를 고정한다.

내가 쓰는 네 칸

내가 자주 쓰는 칸은 네 개다. 이름은 팀마다 바꿔도 되지만, 중요한 건 “미완료”라는 한 단어로 뭉개지 않는 것이다.

큐 이름	넣는 항목	다음 첫 행동
verify_first	테스트, preview, 로그처럼 확인 순서가 먼저인 항목	실행하거나 눈으로 확인한다
decision_needed	요구사항, 범위, UX 선택처럼 사람이 정해야 하는 항목	질문을 던지거나 범위를 잠근다
rollback_watch	배포 전 위험 신호, 되돌릴 기준, 보호해야 할 흐름	위험 조건을 먼저 대조한다
parked_context	지금 작업에는 필요 없지만 다음 가설에 쓸 수 있는 배경	당장 열지 말고 보관한다

verify_first와 decision_needed를 나누는 게 특히 중요했다. 에이전트는 종종 “확인 필요”와 “결정 필요”를 같은 말처럼 쓴다. 하지만 테스트를 돌리면 닫히는 문제와 사람이 제품 방향을 골라야 닫히는 문제는 전혀 다르다. 둘을 섞으면 다음 세션은 실행 가능한 일을 두고도 질문부터 하거나, 반대로 질문해야 할 일을 테스트로 덮어 버린다.

작게 남기는 형식

나는 handoff 큐를 길게 쓰지 않는다. 길어지면 결국 또 하나의 보고서가 된다. 보통은 아래 정도면 충분하다.

handoff_queue:
  verify_first:
    - preview에서 결제 직전 화면만 다시 확인
    - 실패한 테스트 1개를 같은 조건으로 재실행
  decision_needed:
    - 자동 삭제 버튼을 이번 변경에 포함할지 결정
  rollback_watch:
    - 로그인 후 첫 진입 화면이 비어 보이면 직전 diff 되돌리기
  parked_context:
    - 모바일 빌더가 만든 컴포넌트 이름 규칙은 다음 리팩터링 때만 보기

핵심은 항목마다 다음 동사가 보여야 한다는 점이다. “확인 필요”라고만 쓰면 다시 생각해야 한다. “preview에서 결제 직전 화면 확인”이라고 쓰면 바로 실행할 수 있다. “위험 있음”이라고만 쓰면 불안만 남는다. “로그인 후 첫 진입 화면이 비어 보이면 되돌리기”라고 쓰면 위험을 관찰 가능한 조건으로 바꾼다.

종료 체크와 다른 점

이 패턴은 종료 체크와 겹치지만 같은 것은 아니다. 종료 체크는 에이전트의 마지막 답변을 변경·검증·위험으로 접는 장치다. 반면 handoff 큐는 그중 아직 닫히지 않은 항목을 다음 실행 순서로 다시 나누는 장치다. 종료 체크가 “무엇을 했나”에 가깝다면, handoff 큐는 “다음 사람이 무엇부터 봐야 하나”에 가깝다.

세션 스냅샷과도 조금 다르다. 스냅샷은 context compaction이나 모델 전환 전에 현재 좌표를 보존한다. handoff 큐는 작업자가 바뀌거나, 모바일 초안을 데스크톱 검증으로 넘기거나, 에이전트가 만든 결과를 사람이 병합 판단해야 할 때 더 유용하다. 즉 같은 내가 이어서 할 수도 있지만, 다른 실행자에게 넘겨도 순서가 유지되는 형태를 목표로 한다.

자주 망가지는 지점

• 모든 TODO를 넣는 경우: handoff 큐가 작업 관리 도구처럼 변하면 다시 무거워진다. 다음 실행에 필요한 판단만 넣는다.
• 증거 없이 결론만 넣는 경우: “위험함”보다 어떤 화면, 어떤 로그, 어떤 입력에서 위험한지 남기는 편이 낫다.
• 소유자가 없는 경우: 사람이 결정할 일인지, 에이전트가 검증할 일인지, 다음 세션이 보관만 할 일인지 구분해야 한다.
• 되돌릴 기준이 없는 경우: 위험을 적었으면 어떤 신호가 나오면 멈출지도 같이 적는다.

이 네 가지가 무너지면 handoff 큐는 다시 긴 완료 보고서가 된다. 나는 그래서 큐를 만들 때마다 “이 항목을 읽은 다음 30초 안에 뭘 할 수 있나?”를 본다. 바로 실행할 수 없으면 문장을 줄이기보다 칸을 잘못 골랐을 가능성이 크다.

정리

바이브코딩이 빨라질수록 handoff는 더 자주 생긴다. 모바일에서 초안을 만들고, 웹 IDE에서 고치고, 로컬에서 테스트하고, 다시 에이전트에게 넘기는 흐름이 자연스러워질수록 마지막 답변 하나에 모든 판단을 맡기기 어렵다. 그래서 나는 handoff를 “잘 요약하기”보다 남은 판단을 줄 세우기로 보는 쪽이 더 안전하다고 느낀다.

작업을 넘길 때 네 칸만 남겨도 다음 세션의 첫 5분이 꽤 달라진다. 검증할 것은 검증으로, 사람이 정할 것은 결정으로, 위험한 것은 되돌릴 기준으로, 지금 볼 필요 없는 것은 보관으로 빠진다. 이 정도만 지켜도 에이전트가 끝냈다는 말과 내가 실제로 이어받을 수 있는 상태 사이의 간격이 훨씬 좁아진다. 특히 여러 도구를 오가며 만든 결과일수록, 이 작은 큐가 작업의 책임선을 다시 잡아 주는 역할을 한다. 다음 세션이 긴 설명 없이도 같은 기준에서 시작할 수 있으면, 에이전트의 속도는 덜 불안해진다.