에이전트가 사람에게 인계하는 순간 — *그 한 화면* 의 설계
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 카드 패턴 (또는 그 변형) 으로 처음부터 설계하는 게 훨씬 싸다.
비슷한 글
에이전틱 DevOps 12개월 후 — 첫 가설 중 무엇이 *맞았고* 무엇이 *틀렸나*
12개월 전 다음 10년의 DevOps는 에이전틱이다 의 가설들. 12개월의 데이터로 어느 가설이 맞고 어느 게 틀렸는지의 정직한 평가.
백재민
3 pillars 그 후 — 4 추가 신호의 *6개월 후* 운영 노트
3 pillars 가 더 이상 충분하지 않은 이유 발행 후 6개월. 4 추가 신호 (events / user journeys / deploy correlation / similarity) 가 운영에서 어떻게 작동했는지의 후속.
백재민
GitHub Actions vs 자체 호스팅 — *진짜 비용* 비교 (12개월 데이터)
GitHub Actions 가 *비싸 보임* 은 표면. 12개월 자체 호스팅 vs SaaS 비교 — 단순 *분당 비용* 이 아니라 *총 운영 비용* 으로.
백재민