에이전트 상황판에서 완료율보다 단계 이벤트를 먼저 둔 이유

에이전트 상황판을 만들 때 완료율부터 크게 띄우고 싶은 마음이 생겨요. 그런데 혼자 운영하면서 직접 만들어 보니, 그 숫자는 나중에 봐도 늦지 않았어요. 지금 필요한 건 일이 끝났는지보다 어디에서 멈췄는지였어요.

완료율은 늦게 보이는 숫자였어요

상황판의 핵심 흐름은 6단계였어요. pick → goal-parse → agent-run → verify → eval → close예요. 테스트해 보면 완료율은 마지막에 1번 움직이지만, 단계 이벤트는 중간마다 바로 남아요. 로그에 1줄이 추가될 때마다 새 항목이 보여야 운영자가 다음 판단을 할 수 있었어요.

pick→goal-parse→agent-run→verify→eval→close

직접 만들어 보니 success 한 단어보다 verify에서 오래 머무는지, eval에서 다시 돌아가는지가 더 빨리 보였어요. 돌려 보니 이 차이가 컸어요. 완료율은 회고에 가깝고, 단계 이벤트는 대응에 가까웠어요.

상황판은 정답표보다 발자국에 가까워야 했어요

에이전트 작업은 끝난 뒤보다 진행 중에 더 많은 신호를 줘요. pick이 안 찍히면 일이 안 잡힌 거고, verify에서 멈추면 검증 마찰을 의심할 수 있어요. close가 늦으면 마지막 정리가 막힌 걸 먼저 봐야 해요. 이런 흐름은 완료율 1개로는 잘 안 보여요.

라이프케어로그도 비슷해요. 작은 도구를 만들수록 한 번의 화려한 숫자보다 사용자가 남기는 단계 흔적이 더 중요했어요. 플랜씨(plan-c)는 대출이자·연봉 실수령·복리·저축 4가지 계산기를 로그인 없이 바로 쓰게 했고, 플랜엘(plan-l)은 법령·판례 검색을 월 3건 무료로 열어 두고 있어요. 적용해 봤더니 이런 제품은 "끝까지 썼는가"만 보면 늦을 수 있었어요. 어디에서 멈췄는지 먼저 보여줘야 반복을 줄일 수 있었어요.

• ✓막힌 지점 확인
• ✓다음 액션 결정
• ✓나중에 완료율 회고

플랜비(plan-b)처럼 멤버, 회비, 출전 로테이션을 다루는 도구도 같아요. 사용자는 한 번에 전체 여정을 보지 않고, 눈앞의 다음 단계만 지나가요. 그래서 상황판도 그 순서를 따라가야 했어요. 작은 도구일수록 완료율보다 단계 이벤트를 먼저 보여주는 편이 운영과 개선에 더 도움이 됐어요.