마지막 게이트는 사람이에요 — 에이전트 산출물의 QA를 PO가 어디서 잡나

권한과 승인 경계 글에서 “무엇을 자동, 무엇을 사람”을 그렸어요. evaluation 글에서 “무엇을 봐야 시스템이 살아있는지”를 그렸고요. 그 두 글의 교차점에 이 글의 주제가 있어요.

마지막 게이트가 사람이라면, 그 게이트에서 PO는 정확히 무엇을 봐야 하나?

“꼼꼼히 본다”는 답은 1인 운영에선 성립하지 않아요. 모든 산출물을 다 보는 것은 시간이 안 되고, 안 보는 것은 책임이 안 돼요. 그래서 게이트의 위치와 검증 항목을 분리해서 설계해야 해요.

이 글은 그 설계예요. 검증을 세 축으로 쪼개고, 게이트를 어디에 둘지를 네 기준으로 정리해요.

검증의 세 축 — 결과, 과정, 외부 영향

산출물 검증을 한 덩어리로 보면 무엇을 봐야 할지 흐려져요. 세 축으로 쪼개야 PO가 다 안 봐도 되는 자리가 보여요.

축 1) 결과 검증 — 산출물 자체가 요구를 만족하는가

가장 흔한 자리예요. 코드면 동작 여부, 문서면 정합성, 디자인이면 시안 부합 여부.

결과 검증은 자동화 가능 비중이 가장 큼
테스트, 스키마 검사, 정합성 체크, smoke 테스트 — 다 결과 검증의 자동화
PO가 직접 봐야 하는 건 “테스트가 잡지 못하는 결과” — 톤, 미세한 UX 판단, 정성적 품질

여기서 게이트를 사람으로 두면 비용이 가장 크고 회수가 가장 적어요. 결과 검증의 게이트는 가능한 한 자동으로 옮기는 게 옳아요.

축 2) 과정 검증 — 도달 방식이 룰을 따랐는가

같은 결과여도 도달 방식이 다르면 다음 사고의 위험이 달라져요.

사양서 → 구현 → 테스트 순으로 갔는가
권한 바깥은 안 건드렸는가
의존성/도구 변경이 정당한 절차로 이뤄졌는가
임시 회수와 룰 박기를 분리했는가

과정 검증은 trail이 남으면 자동화 가능해요. 사양서 commit 시점, 변경 파일 목록, 권한 도메인 체크, 룰 박기 항목 — 다 trail에서 검사할 수 있어요. PO가 봐야 할 건 “trail에 안 남는 과정” — 결정의 맥락, 트레이드오프 선택 근거 같은 거예요.

축 3) 외부 영향 검증 — 산출물이 외부에 어떤 신호를 보내는가

가장 PO가 직접 봐야 하는 축이에요.

대고객 문서/메시지의 톤과 식별자 노출
라이브 배포의 사용자 영향
외부 발송(이메일, SNS, 알림)의 도달 범위
파트너/API 호출의 비용·쿼터 영향

외부 영향은 한 번 나가면 회수가 어렵고, 자동 검증이 “옳음”을 판단하기 어려운 자리예요. 그래서 외부 영향 게이트는 거의 영구히 사람에 둬요.

게이트 배치의 네 기준

세 축을 알면 “어디를 사람 게이트로 둘지”가 보여요. 네 기준으로 판단해요.

기준 1) 되돌릴 수 있는가 (reversibility)

되돌릴 수 있으면 자동으로 옮길 수 있어요. 되돌리기 어려우면 사람 게이트.

dev 배포 → 되돌리기 쉬움 → 자동
라이브 배포 → 되돌리기 어려움 → 사람
외부 발송 → 되돌리기 불가 → 사람 + 추가 확인 절차

기준 2) 외부에 노출되는가 (external exposure)

내부 산출물은 자동 비중을 높일 수 있어요. 외부 산출물은 사람 게이트.

내부 메모, 코드 리팩터링 → 자동
외부 문서, 대고객 페이지, 외부 API 응답 변경 → 사람

기준 3) 영향이 지속되는가 (lasting impact)

순간적 영향은 자동에 가깝게, 지속적 영향은 사람 게이트로.

일회성 알림 → 자동
매뉴얼 변경, 사양서, 룰 변경 → 사람
canonical 지식 promotion → 사람 (절대 자동 금지)

기준 4) 자산 등급이 결정되는가 (asset grade)

산출물이 자산으로 굳을 때는 사람 게이트가 필요해요.

일회성 실험 → 자동
운영 룰로 박히는 사고 회고 → 사람
신규 패턴/포맷이 표준으로 굳을 때 → 사람

1인 PO의 QA 운영 — 시간 예산

세 축과 네 기준을 다 적용해도, PO의 시간은 한정돼 있어요. 그래서 시간 예산을 명시적으로 잡아야 해요.

우리는 하루 게이트 응답을 30회 미만으로 잡았어요. 그 안에 들어가야 운영이 유지돼요. 30회를 넘기 시작하면 — 게이트가 너무 많거나, 자동화 비중이 낮거나, 룰이 모자란 거예요.

시간 예산을 지키기 위한 운영 룰:

묶음 처리: 비슷한 게이트는 묶어서 한 번에. 매번 끊지 않음.
선결정 룰: 비슷한 결정이 반복되면 룰로 박아 자동으로 옮김.
응답 지연 알림: N시간 안 응답하면 자동 알림. 잊어서 묶이는 것 방지.
게이트 자체 재검토: 분기마다 한 번씩 “이 게이트가 여전히 사람이어야 하는가” 검토.

특히 마지막 게 중요해요. 게이트는 한 번 사람에 두면 그대로 굳기 쉬워요. 그런데 운영이 성숙하면서 일부는 자동으로 옮길 수 있게 돼요. 그 재배치를 안 하면 사람이 영구히 묶여요.

게이트의 함정 — “사람이 봤다”가 알리바이가 되지 않게

사람 게이트의 위험은 “사람이 보긴 봤어요”가 알리바이가 되는 거예요. 형식적으로 통과시키고 사고가 나면, 사람 게이트가 있었으니 자동 게이트보다 책임이 무거워져요. 그런데 무거운 만큼 잘 본 게 아니에요.

이걸 막으려면 게이트의 체크리스트를 분명히 해야 해요.

이 게이트에서 무엇을 “꼭” 봐야 하는지 (3~5개 항목)
그 항목이 통과 못 하면 자동 거절되는지
통과 시점의 근거가 trail에 남는지

체크리스트가 없으면 “봤어요”가 그냥 도장 찍기가 돼요. 그러면 게이트는 형식상의 게이트일 뿐, 실제로는 사고를 못 막아요. 사고를 못 막는 게이트는 게이트가 아니에요.

정리

마지막 게이트가 사람이라면, 그 자리는 의도적으로 설계돼야 해요. 무엇을 보는지를 세 축으로 쪼개고, 어디에 둘지를 네 기준으로 결정해요.

축 1) 결과 검증 — 자동화 우선, PO는 톤/정성적 품질만
축 2) 과정 검증 — trail 자동 검사, PO는 결정 맥락만
축 3) 외부 영향 검증 — PO 직접, 영구 사람 게이트
기준 1) 되돌릴 수 있는가 — 어려우면 사람
기준 2) 외부에 노출되는가 — 노출되면 사람
기준 3) 영향이 지속되는가 — 지속되면 사람
기준 4) 자산 등급이 결정되는가 — 자산화 자리면 사람

그리고 게이트는 한 번 두고 끝이 아니에요. 시간 예산을 두고, 분기마다 재검토하고, 체크리스트를 명시해서 형식적 통과가 안 되게 만들어요.

에이전트가 빠를수록 마지막 게이트가 중요해져요. 빠른 시스템에서 마지막 게이트가 흐릿하면, 빠르게 사고가 나요. 게이트의 정확한 위치와 정확한 항목이 곧 운영의 안전 마진이에요.

링크

에이전트에게 뭘 맡기고, 뭘 직접 승인할 것인가

무엇을 봐야 시스템이 살아있는지 — 다섯 차원의 evaluation

회의 0번, 일 34개를 끝내는 법

PO 1명이 기획팀이 되는 법