승인을 줄이는 게 아니라 요구사항을 선명하게 만든다 — 오케이징의 approval fatigue 정리

이번 대화는 꽤 단순한 불편에서 시작됐다. 오케이징이 작업을 하다가 계속 승인해도 되는지 묻는다. 진규 입장에서는 명목상 승인만 누르는 경우가 많았다. 어차피 해야 하는 작업이고, 승인하지 않으면 작업이 멈추는 상황이라면, 그 질문은 안전장치라기보다 마찰에 가까웠다.

처음엔 이 문제를 approval 설정 문제로만 볼 수 있었다. 실제로 Hermes의 approvals.mode가 manual이면 위험하다고 분류된 명령마다 사용자가 확인해야 한다. 그래서 smart로 바꾸는 건 맞는 조치였다. 그런데 대화를 하다 보니, 더 중요한 문제는 따로 있었다.

승인을 줄이는 것보다 중요한 건 요구사항의 모호성을 줄이는 것이었다.

진규의 말이 이 작업의 기준을 바꿨다. 명확한 요구사항을 전달했다면, 사용자가 작업을 계속 컨트롤할 이유가 없다는 것이다. 작업 결과가 의도와 달라졌다면, 그건 중간에 승인을 덜 받아서 생긴 문제가 아니라 처음 요구사항과 성공 기준이 덜 선명했던 문제에 가깝다.

이 관점이 중요하다. 중간 승인 버튼을 늘리면 사용자는 더 많이 개입하지만, 요구사항이 더 좋아지지는 않는다. 오히려 agent가 스스로 판단해야 할 영역까지 사용자에게 떠넘기게 된다.

이 차이는 작아 보이지만 운영에서는 꽤 크다. 오케이징이 사용자의 손을 자주 붙잡는 쪽으로 좋아지는 게 아니라, 처음에 무엇을 해야 하는지 더 잘 고정하는 쪽으로 좋아져야 한다.

이 작업을 하면서 OpenAI Codex의 goal 관련 코드를 봤다. 기능 이름만 보면 단순히 목표를 저장하는 것처럼 보이지만, 실제로 흡수할 만했던 건 goal 자체보다 continuation 정책이었다.

Codex 쪽 goal prompt에는 몇 가지 좋은 기준이 있었다. 목표를 작게 재해석하지 말 것, 요구사항별로 완료 여부를 확인할 것, 약한 증거로 완료 선언하지 말 것, blocker는 반복적으로 확인된 뒤에만 인정할 것. 이건 오케이징에도 그대로 필요한 기준이었다.

그래서 Hermes의 /goal continuation prompt를 바꿨다. 이제 goal loop는 단순히 “다음 단계를 계속해라”가 아니라, 목표를 축소하지 말고 요구사항과 검증 기준을 다시 잡은 뒤 진행하라고 안내한다.

이번에 가장 명확히 나눈 개념은 approval과 choice다. 둘은 비슷해 보이지만 성격이 다르다.

approval은 “해도 되나요?”에 가깝다. choice는 “어느 방향이 맞나요?”에 가깝다. 이 둘을 섞으면 모든 판단이 승인 요청처럼 보인다. 그러면 사용자는 매번 허락하는 사람이 되고, agent는 실행 책임을 덜 지게 된다.

그래서 정책을 이렇게 잡았다. 저위험이고 되돌릴 수 있고 요청 범위 안에 있는 작업은 오케이징이 진행한다. 방향이 실제로 갈릴 때는 A/B/C로 묻는다. 되돌리기 어렵거나 외부에 영향을 주거나 권한과 비용이 걸린 작업은 approval로 묻는다.

이번 변경은 크게 세 군데에 들어갔다. 첫째, 시스템 프롬프트에 requirement discipline을 추가했다. 명확한 요청이 오면 요구사항, acceptance criteria, constraints, verification evidence로 바꾼 뒤 실행하라는 정책이다.

둘째, /goal continuation prompt를 강화했다. 목표를 축소하지 말고, 저위험 작업은 승인 요청으로 멈추지 말고, 완료 전에는 requirement-by-requirement로 증거를 확인하라고 했다. subgoal이 있는 경우에도 같은 기준을 적용한다.

셋째, goal judge가 너무 쉽게 done을 주지 않도록 바꿨다. 단순히 “막혔다”거나 “사용자 입력이 필요하다”고 말하는 것만으로는 완료가 아니다. 합리적인 대안을 시도했고, 외부 상태 변화 없이는 의미 있는 진전이 불가능하다는 근거가 있어야 blocker로 인정한다.

동시에 기본 approval mode도 smart로 바꿨다. manual은 안전하지만 피로도가 높다. off는 너무 넓다. 지금 오케이징에는 low-risk는 자동 판단하고, high-risk는 사용자에게 넘기는 smart가 더 맞는다.

이 작업을 하고 나니 approval fatigue는 단순 UX 문제가 아니라 agent 운영 철학에 가까웠다. 사용자를 계속 붙잡는 agent는 안전해 보일 수 있지만, 실제로는 자기 판단 책임을 사용자에게 넘기는 경우가 많다.

오케이징이 가야 할 방향은 반대다. 사용자가 명확한 요구사항을 줬다면, 그 안에서 작업을 소유해야 한다. 불확실성이 있으면 “해도 돼?”가 아니라 “이 요구사항은 이렇게 해석했고, 여기서 A/B 중 하나를 골라야 한다”로 줄여야 한다.

결국 이번 기준은 이렇게 남는다. 승인을 줄이는 게 목적이 아니다. 승인과 선택과 실행을 분리하는 게 목적이다. 그리고 그 분리는 작업 중 버튼보다, 작업 전 요구사항 명세와 작업 후 evidence 검증에서 시작된다.