결정 모델로 에이전트를 지켜보기

코딩 에이전트는 이 모델들이 가장 밀도 높게 쓰이는 곳이며, 그 용도는 세 곳에 모입니다. 셋 모두 하나의 구조를 공유합니다. 생성 모델에서 판단을 떼어내고, 더 저렴하고 빠른 무언가에 맡기고, 코드가 타입이 있는 답에 따라 행동하게 합니다.

1. 도구 호출 전: 허용할 것인가

가장 직접적인 지점입니다. Claude Code PreToolUse 훅이 하는 일입니다.

Noul에게 묻습니다. 이 셸 명령이 엄격히 읽기 전용인가? 0.95면 자동 승인하고, 그렇지 않으면 평소의 권한 프롬프트로 되돌립니다 —— 그리고 절대 거부하지 않습니다.

세 가지 설계 결정은 짚어둘 가치가 있습니다.

• 0.95는 높습니다. 자동 승인 기준은 “위험해 보인다”의 기준보다 훨씬 위에 있습니다. 잘못 허용하면 기계 하나가 날아가지만, 잘못 차단하면 확인 한 번이 더 필요할 뿐입니다. 비대칭 비용은 비대칭 임계값에 속합니다.
• 절대 거부하지 않습니다. 승인만 추가할 뿐이고, 나머지는 모두 원래 시스템으로 돌아갑니다. 능력만 더하는 게이트는 테스트하기 훨씬 쉽습니다 —— 최악의 경우가 “도움이 안 됐다”이기 때문입니다.
• 위험한 명령은 모델에 도달하지 않습니다. 로컬 하드 거부 목록과 인젝션 필터가 먼저 잡습니다. 이것이 임계값보다 더 중요합니다 —— 코드에 두어야 하는 것을 보십시오.

실측 결과: 상태를 바꾸는 명령 8건 중 0건이 자동 승인되었습니다.

2. 에이전트가 멈추려 할 때: 끝난 것인가

또 하나 자주 나오는 지점입니다. Stop 훅은 에이전트가 너무 일찍 끝내려 하는지를 결정 모델에 묻습니다. 평문으로 된 완료 규칙을 모델에 제시해서입니다.

더 절제된 버전은 이렇게 동작합니다.

파일이 바뀌었고 그 이후로 통과하는 검사가 실행되지 않았을 때만 네 질문짜리 호출 한 번을 씁니다. 어떤 오류에서도 fail-open입니다.

“물어볼 가치가 있을 때만 묻기”가 이 부류의 핵심입니다 —— 이 훅들은 매 턴 실행되고, 조건 없이 호출하면 비용이 턴 수만큼 곱해집니다. 위의 조건은 “검증되지 않은 변경”이며, 이는 에이전트가 확인도 하지 않고 승리를 선언할 가능성이 가장 높은 순간입니다.

관련 훅 하나는 에이전트의 자기 주장을 믿는 대신 평문 완료 규칙을 판정함으로써 에이전트가 일찍 끝나는 것을 막습니다.

3. 컨텍스트가 찰 때: 아직 필요한 것은 무엇인가

세 번째 지점은 컨텍스트 압축이며, 접근이 가장 크게 갈리는 곳입니다.

전통적인 압축은 요약합니다. 대화의 한 구간을 모델에 넘기고 산문을 돌려받습니다. 원본은 사라지고, 요약은 되돌릴 수 없습니다.

결정 모델 접근은 다시 쓰지 않습니다 —— 점수만 매깁니다.

공통된 문장은 이것입니다. 여기서 결정 모델의 일은 다시 쓰기가 아니라 유지/버리기의 이진 판단입니다. 그것이 바로 이 모델이 잘하고 생성 모델이 못하는 일이며, “삭제 대신 접기”는 잘못된 판단을 “정보가 영원히 사라짐”에서 “확장 한 번 더”로 바꿔 줍니다.

반론: 안전 게이트와 효율 게이트는 반대 방향으로 실패합니다

이 생태계에서 가장 교훈적인 대비입니다. “오류 시 어떻게 되는가”라는 같은 질문에 프로젝트들은 반대 답을 골랐고, 둘 다 옳습니다.

• 권한 판정기: 오류나 타임아웃 시 거부합니다.
• Stop 훅: 어떤 오류에서도 허용합니다.

기준은 “어느 쪽이 더 안전한가”가 아니라 이 게이트가 위험을 지키는가 처리량을 지키는가입니다. 위험을 지키는 게이트(권한, 비밀, 위험한 명령)는 나쁜 것을 통과시키기보다 좋은 것을 막는 편이 낫고, 처리량을 지키는 게이트(완료 검사, 형식 검사)는 흐름을 교착시키기보다 무언가를 통과시키는 편이 낫습니다.

한 문장으로

에이전트는 이 모델들에게 가장 자연스러운 집입니다. 결과가 코드에 즉시 소비되는 아주 많은 저렴한 판단이 필요하기 때문입니다. 그러나 그 모든 지점에서 먼저 정해야 합니다. 이 게이트는 깨질 때 어느 쪽으로 기울어야 하는가?