에이전트가 사람에게 인계하는 순간 — *그 한 화면* 의 설계
AI 에이전트가 *내가 못 한다* 라고 결정하는 순간 사람에게 인계한다. 그 인계 화면이 *제대로 설계되지 않으면* 사람이 *처음부터 다시* 한다.
에이전트가 모든 것을 풀지 않는다. 어느 시점에 나는 못 한다 또는 권한 밖이다 라고 결정하고 사람에게 인계. 그 인계의 한 화면 한 줄 이 전체 자동화 가치 를 정한다.
인계가 잘못 설계되면 사람이 상황 정리부터 처음 부터 한다. 그러면 에이전트가 시간을 옮긴 게 아니라 지연 시킨 것.
우리가 부서뜨린 인계 4가지
지난 9개월 동안 4가지 인계 패턴을 시도하고 부서뜨렸다.
패턴 1 — 원시 trace dump
처음. 에이전트가 자기가 한 모든 액션 + 시도한 옵션 + 외부 API 응답 을 raw 로 dump. 사람이 받은 화면은 47줄의 JSON.
부서진 이유 — 사람이 47줄을 읽는 시간 이 처음부터 자기가 보는 시간 과 같음. 에이전트의 시간 절감 = 0.
패턴 2 — 요약만
다음. 에이전트가 3 문장 요약 만 인계. 짧고 빠름.
부서진 이유 — 사람이 그 요약을 신뢰하지 못함. 진짜 원인 이 요약에 들어 있는지 확인 하려면 원시 데이터로 돌아감. 결국 raw + 요약 둘 다 봄 — 시간 증가.
패턴 3 — 결정 트리 표시
다음. 에이전트가 어떤 가지를 따라가서 어디서 막혔는지 의 트리 를 보여줌. 시각적.
부서진 이유 — 트리가 너무 큼. 에이전트는 수십 가지를 시도 한다. 그걸 다 보여주면 raw dump 와 같음. 핵심 가지만 보여주려면 어느 가지가 핵심인지 자체가 어려운 문제.
패턴 4 — 5 W 카드 (지금의 답)
지금 작동하는 것. 인계 시 고정된 5 W 카드:
WHAT happened?
새 배포 (2026-04-01 14:23 KST) 후 결제 성공률이 -2.3% (SLO -1% 위반)
WHEN did the agent stop?
14:31. 가설 3개 시도 후 모두 inconclusive.
WHY couldn't the agent proceed?
1. 새 코드의 카드사 X 호출이 *분기 후 다른 카드사 동작* 과 다른 패턴
2. 그 패턴이 *우리 staging 환경에서 재현 X*
3. *production rollback 권한* 은 사람만
WHERE to look?
service: payment-validator-v2
related deploy: PR#4823, commit a3f7e1
similar past incident: 2025-11-08 (같은 카드사, 다른 코드 경로)
WHAT should the human decide?
결정 1: 즉시 rollback (5분, 영향 0)
결정 2: hot fix (가설 1 기반, 30분, 추가 위험 있음)
결정 3: 추가 조사 의뢰 (트리아지 자료 더 모음)이 카드가 한 화면 안에 들어감. 사람이 30초 안에 결정 가능 한 형태.
5 W 카드의 진짜 핵심
위 카드의 진짜 가치는 마지막 줄 — "WHAT should the human decide". 에이전트가 결정 자체 를 사람에게 넘기되, 고를 선택지 까지 정리.
이게 빠지면 사람이 조사를 다시 시작. 있으면 결정만 함.
인계 정확도 = 에이전트 정확도
위 4 패턴을 거치면서 깨달은 것 — 인계 화면의 정확도 가 에이전트 정확도 와 직접 같음. 에이전트가 덜 똑똑해도 인계가 잘 되면 사람이 빨리 마무리. 에이전트가 똑똑해도 인계가 나쁘면 그 똑똑함이 사람 시간으로 안 옮겨짐.
에이전트의 진짜 산출물 은 행동 이 아니라 인계 카드 다.
인계 주체 의 디자인 결정
5 W 카드의 생성 자체 가 LLM 작업. 인계 결정 시점에 별도 LLM 호출 로 카드 생성. 이게 추가 비용이지만, 사람의 조사 시간 절감 으로 항상 양수.
대안 — 카드를 결정형 룰 로 생성. 우리가 시도했지만 카드의 가독성 이 너무 낮아져서 폐기. LLM 으로 카드 텍스트만 생성하는 게 답.
AI 에이전트의 사람-인계 화면이 raw dump 또는 요약만 이면, 에이전트가 절감한 시간은 사람의 조사 시간 으로 그대로 증발 한다. 지금 인계 흐름을 설계 중인 팀이라면, 5 W 카드 패턴 (또는 그 변형) 을 처음부터 박는 게 나중에 갈아엎는 것보다 훨씬 싸다.
비슷한 글
기획자가 코드를 배포하면, 장애는 누가 책임질까
AI로 제품 담당자가 직접 코드를 만들고 여러 에이전트가 동시에 작업하는 조직에서, 운영에 나가는 변경을 누가 무엇으로 확인해야 하는지. NIST SSDF, SLSA provenance, Google SRE 포스트모템 문화를 근거로 작성자와 분리된 검증·승인·복구의 역할 설계를 정리했다.
백재민
에이전트 시대의 Eclipse 플러그인 — 작업 컨텍스트는 20년 전에도 문제였다
Mylyn 이 2000년대에 풀려던 문제와 지금 에이전트 컨텍스트 문제는 같습니다. 달라진 건 그 컨텍스트를 읽는 쪽에 사람만 있는 게 아니라는 점입니다.
김영상
에이전트 시대의 VS Code 확장 — 개발자는 에디터에서 무엇을 보는가
코드 작성 비용이 무너진 뒤 개발자의 시간은 판단과 승인으로 옮겨갔습니다. 그 일들이 왜 에디터 밖에 있으면 안 되는지, VS Code 확장을 만들며 내린 선택들.
이승백