에이전트 팀의 evaluation — 시스템이 살아있다고 말할 수 있는 기준
1인 PO와 에이전트 팀을 1년 굴리면서 만든 측정 지표를 정리합니다. '에이전트가 일을 잘하는가'가 아니라 '시스템이 무너지지 않고 있는가'를 보는 다섯 개의 차원.
지금까지 1인 PO와 에이전트 팀 운영에 대해 여러 글을 썼어요. 회의 0번으로 일 34개 마감하는 운영 규칙, 대시보드 하나로 굴리는 워크플로우, 기획 프로세스를 에이전트에 넘기는 법, 권한과 승인 경계 — 전부 “어떻게 운영하나”가 주제였어요.
운영을 한참 하다 보니 그 다음 질문이 떠올랐어요.
무엇을 봐야 이 시스템이 살아있다고 말할 수 있나?
에이전트가 일을 잘하고 있는지, 못하고 있는지는 사실 명확한 신호로 잡기 어려워요. 산출물 하나하나를 사람이 다 보는 건 1인 PO 운영의 전제와 모순돼요. 자동으로 굴러간다는 건 — 나쁘게 굴러갈 때도 자동으로 굴러간다는 뜻이에요. 사람이 일일이 안 봐도 무너짐을 감지할 수 있는 기준이 필요해요.
이 글은 그 기준을 다섯 개 차원으로 정리해요. 핵심은 “에이전트가 일을 잘하는가”가 아니라 “시스템이 무너지지 않고 있는가” 를 보는 거예요.
1) 자기완결성 — 한 사이클 안에서 끝나는 비율
가장 먼저 봐야 하는 건 한 작업이 한 사이클 안에서 끝나는지예요.
- 에이전트가 받은 요청을 자기 턴 안에서 완료했는가
- 아니면 사람에게 되묻거나, 다른 에이전트에 의존하거나, 다음 사이클로 넘겼는가
이걸 단순히 “완료/미완료”로 나누지 않아요. 세 단계로 봐요.
- A — 자기 턴 안에 완료 (이상적 상태)
- B — 사람에게 한 번 되묻고 완료 (모호함이 있었지만 잘 처리)
- C — 사람이 끼어들어 직접 끝냄 (실패 신호)
A 비율이 떨어지지 않는지가 첫 번째 지표예요. 이 비율이 한 주 동안 꺾이기 시작하면 — 보통은 매니페스트가 낡았거나, 도메인 변경이 있었는데 학습되지 않았다는 신호예요.
B는 나쁜 게 아니에요. 오히려 모호함을 사람에게 되묻는 능력은 운영 자산이에요. C가 늘어나는 게 진짜 위험 신호예요.
2) 사고율 — 사고가 났을 때 회수까지 걸리는 시간
두 번째 차원은 사고 자체가 아니라 사고 후 회수예요.
사고는 어느 시스템에서나 나요. 측정해야 하는 건 사고가 났을 때:
- 얼마나 빨리 발견됐는가
- 얼마나 빨리 회수됐는가
- 같은 사고가 다시 나지 않게 어디에 학습됐는가
세 가지를 묶어 MTTR(Mean Time To Recovery) 로 추적해요. 단 그 회수가 “땜빵”인지 “재발 방지”인지를 구분해서 봐요.
- 임시 회수만 하고 룰로 안 박힌 사고는 잠재 부채로 따로 적어두기
- 룰로 박힌 사고는 자산으로 카운트
자산 카운트가 부채 카운트보다 빠르게 자라야 해요. 부채가 부풀어 오르면, 운영이 곧 무너져요.
3) 게이트 작동률 — 자동승인과 사람 승인의 비율
권한 경계 글에서 다뤘던 주제의 운영 측면이에요. 자동승인과 사람 승인이 어디서 어떤 비율로 작동하는지를 봐요.
기준 두 개를 같이 봅니다.
- 자동승인 비율 — 너무 낮으면 사람이 게이트 직무에 묶여요. 너무 높으면 사고의 가시성이 떨어져요.
- 사람 승인 응답 지연 — 사람 게이트가 평균 몇 분 안에 응답하는가. 길어지면 게이트가 사실상 마비된 거예요.
여기서 자주 보는 함정이 있어요. 자동승인 비율이 100%에 가까워질수록 안전한 게 아니라, 사고의 신호가 안 보이는 상태에 가까워져요. 어떤 액션은 영구히 사람 게이트를 거치게 두는 게 옳아요. 라이브 배포, 외부 발송, 권한 변경, canonical 지식 promotion이 그런 자리예요.
비율 자체보다 “어떤 액션이 자동, 어떤 액션이 사람”을 의도적으로 설계하고 있는가가 진짜 지표예요.
4) 정기 작업 건전성 — 조용히 죽지 않는가
자동으로 돌아가는 cron, 스케줄러, 폴링이 늘어날수록 조용히 죽는 사고가 늘어요. 사람이 안 보면 한참을 모르고 지나가요.
세 가지를 같이 봐요.
- 성공 streak — 각 정기 작업의 연속 성공 횟수. 어제는 100이었는데 오늘 0이면 갑자기 깨졌다는 거예요.
- 실패 streak 임계치 — 연속 실패가 N회를 넘으면 알림. 우리는 3을 기본값으로 잡았어요. 15회까지 가면 보통 사람이 발견할 때 이미 일이 며칠 밀려있어요.
- 결과 유무 검증 — “성공으로 종료”가 아니라 “기대한 산출물이 실제로 생성됐는가”까지. 종료 코드 0인데 결과 파일이 비어 있는 경우가 의외로 잦아요.
운영에서 가장 흔한 사고 유형이 이 차원이에요. 모델 alias가 한 번 바뀌면서 cron 여러 개가 조용히 멈춘 사례가 있었는데, 발견까지 며칠이 걸렸어요. 그 사고 이후로 실패 streak 알림 임계치를 더 짧게 잡고, 모델 alias는 한 자리에서 통일 관리하게 바꿨어요.
5) 의사결정 지연 — 사람이 묶이고 있는가
마지막 차원은 사람 쪽이에요. 1인 PO 운영의 가장 중요한 자원이 사람의 시간이에요. 그 시간이 어디에 묶이는지를 봐요.
- 승인 대기 평균 시간 — 사람 게이트 앞에서 작업이 평균 얼마나 기다리는가
- 재요청 발생률 — 같은 요청이 다시 들어오는 비율. 사람이 한 번 결정한 게 다시 돌아오면, 결정의 자산화가 안 된 거예요.
- 하루의 응답 횟수 — 사람이 하루에 게이트 응답을 몇 번 하는가. 우리는 30회 미만을 목표로 잡았어요. 그 이상이면 운영 룰 자체를 다시 봐야 해요.
이 차원이 무너지면 사람이 운영의 병목이 돼요. 에이전트가 빠르더라도 마지막 게이트가 사람이라서, 사람의 가용 시간이 곧 시스템 처리량의 상한이에요. 의사결정 지연이 길어지면 — 게이트 위치를 다시 조정해야 한다는 신호예요.
다섯 차원을 한 대시보드 위에
이 다섯 차원이 한 화면에 같이 보여야 의미가 있어요. 각각 따로 보면 트레이드오프가 안 보여요.
예를 들면 — 자동승인 비율을 올리면 의사결정 지연이 줄어요. 좋아 보여요. 그런데 같은 화면에서 사고율의 회수 시간이 같이 올라가고 있으면, 그건 게이트를 너무 멀리 옮긴 거예요. 두 지표를 같이 봐야 결정이 옳게 돼요.
대시보드의 구성은 단순할수록 좋아요. 우리는 다섯 차원에 각각 한 줄짜리 상태 표시를 두고, 색으로 안전/주의/경고를 표시해요. 깊은 분석은 클릭해서 들어가요. 한눈에 “오늘 시스템이 살아있는가”가 보이는 게 핵심이에요.
측정의 함정 — 지표가 행동을 비틀어요
지표는 한 번 만들면 그 자체로 행동을 비틉니다. 자기완결성 비율을 올리려고 사람에게 되묻는 걸 줄이면, B가 줄어드는 만큼 C가 늘어요. 사고율을 0에 가깝게 만들려고 도전적인 작업을 줄이면, 산출량이 줄어요.
그래서 우리는 지표를 목표가 아니라 감지기로 써요.
- 지표가 안 좋게 움직이면 → “왜 그런지” 보는 트리거
- 지표를 잘 보이게 만드는 것이 목적이 아니라 → 시스템의 무너짐을 빨리 발견하는 것이 목적
이걸 분명히 안 하면, 지표 자체가 운영의 적이 돼요. 보여주기 좋은 숫자를 만드느라 진짜 사고 신호가 묻혀요.
정리
기존 글들이 “어떻게 운영하나”였다면, 이 글은 “무엇을 봐야 운영이 무너지지 않고 있는지 알 수 있나” 예요.
다섯 차원으로 정리하면 이래요.
- 자기완결성 — A/B/C 비율로 모호함 처리 능력 추적
- 사고 회수 — MTTR + 자산/부채 카운트
- 게이트 작동 — 자동승인 비율과 사람 응답 지연
- 정기 작업 건전성 — 성공/실패 streak + 결과 유무 검증
- 의사결정 지연 — 사람이 어디에 묶이는가
이 다섯 개를 한 화면에 같이 두고, 지표는 목표가 아니라 감지기로 써요.
에이전트가 일을 잘하는가는 사람이 일일이 봐야 알 수 있어요. 그건 1인 PO 운영의 전제와 안 맞아요. 그래서 우리는 한 단 위로 올라가요. 시스템이 살아있는가가 진짜 봐야 하는 것이고, 그게 살아있으면 그 안에서 에이전트가 일을 한다고 가정해도 돼요.
다음 글에서는 — 이 다섯 지표를 실제로 어떤 대시보드 위에 어떻게 띄우고, 알림은 어떻게 설계했는지 운영 노트를 정리할 예정이에요.
링크