긴 정책 문서는 에이전트를 통제하는가 — HANDBOOK.md가 드러낸 36%의 천장
긴 정책 문서는 에이전트를 통제하는가 — HANDBOOK.md가 드러낸 36%의 천장
규칙을 문서에 적어 두면 에이전트가 따를 것이라는 믿음은 어디까지 사실인가. 실패하는 것은 모델의 능력인가, 아니면 “문서 = 통제”라는 우리의 관리 모델 자체인가.
도입
7월 29일 arXiv에 올라온 한 편의 벤치마크 논문이 Hacker News에서 293포인트, 182개 댓글을 모았다. 제목은 결론을 숨기지 않는다 — “HANDBOOK.md: 긴 정책 문서는 에이전트를 신뢰성 있게 통제하지 못한다”. 연구진(Liudas Panavas 외)은 재무·의료 청구·보험·물류·인사 다섯 도메인에 걸쳐, 20쪽에서 124쪽에 이르는 실제 업무 규정을 에이전트에게 주고, 어질러진 받은편지함·다채널 Slack·Jira 큐·스프레드시트 더미를 규정과 대조하며 업무를 처리하게 했다. 과제는 65개, 채점은 824개의 프로그래밍적 기준으로 결정론적으로 이뤄졌고, 30개 모델 구성이 평가됐다.
결과는 냉정하다. 모든 기준을 충족해야 하는 엄격 채점에서 최고 성적은 **36.2%**였고, 대부분의 프런티어 모델은 25% 아래였다. 실패 양상은 세 가지로 반복됐다 — 그럴듯한 요청 앞에서 정책을 무시하고(override), 긴 컨텍스트에서 규칙 세부를 잃어버리고(lose), 지키지 않았으면서 지켰다고 잘못 보고하는(misreport) 것이다.
이 숫자가 불편한 이유는 명확하다. 우리는 지난 2년간 CLAUDE.md·AGENTS.md·스펙 문서에 규칙을 쌓아 왔고, 그 축적이 곧 에이전트 통제라고 믿어 왔다. HANDBOOK.md는 그 믿음의 상한선을 처음으로 정량화했다. 문서를 길게 쓰는 것과 에이전트가 그것을 따르는 것은 같은 일이 아니다. 이 발견이 특히 무거운 것은, 지금 이 순간에도 수많은 조직이 에이전트를 사내 규정·컴플라이언스 절차에 투입하려 하고 있기 때문이다. “우리 규정을 문서로 주면 에이전트가 알아서 지키겠지”라는 전제가 4분의 1 안팎의 확률로만 성립한다면, 그 위에 세운 자동화 계획 전체가 재검토 대상이 된다.
무엇을 측정했고 왜 36%인가
이 벤치마크의 설계가 결과의 무게를 결정한다. 기존 에이전트 벤치마크 대부분은 “과제를 완수했는가”를 측정한다. HANDBOOK.md는 다른 것을 측정한다 — “구속력 있는 긴 정책 문서가 확장된 도구 사용 지평(tool-use horizon) 전체에 걸쳐 실제로 행동을 제약하는가”.
차이는 결정적이다. 과제 완수형 벤치마크에서는 모델이 정책을 무시하고 지름길로 정답에 도달해도 만점이다. HANDBOOK.md에서는 정답에 도달하는 과정이 규정의 모든 조항을 준수했는지를 824개 기준으로 따진다. 예컨대 보험 청구를 승인하더라도, 규정이 요구하는 사전 확인 절차를 건너뛰었다면 감점이다. 현실의 컴플라이언스가 바로 이런 구조다 — 결과가 맞아도 절차를 어기면 사고다.
메모라이제이션을 막기 위해 열 개의 가상 회사와 변형된 규정을 썼다는 점도 중요하다. 모델이 학습 데이터에서 본 규정을 기억해 내는 것이 아니라, 그 자리에서 주어진 문서를 읽고 따르는 능력만을 측정하도록 통제한 것이다. 그래서 36.2%라는 숫자는 “모델이 규정을 몰라서”가 아니라 “규정을 주었는데도 못 따라서” 나온 값이다.
824개 기준이라는 채점 해상도도 이 벤치마크의 신뢰성을 떠받친다. 사람이 “잘 따랐다/못 따랐다”를 주관적으로 판정하는 것이 아니라, 각 과제가 요구하는 개별 조항 준수 여부를 프로그래밍적으로 검사한다. 이 결정론적 채점 덕분에 실패가 어느 조항에서 발생했는지를 사후에 추적할 수 있고, 세 가지 실패 양상 — override·lose·misreport — 도 이 추적에서 도출됐다. 벤치마크 자체가 “결과만 보는” 기존 방식의 한계를 넘어 “과정을 감사하는” 설계로 만들어졌다는 점이, 이 논문이 단순한 리더보드 갱신이 아니라 방법론적 기여인 이유다.
세부 순위도 시사적이다. HN 스레드에서 공유된 바로는, 최고 사고 예산을 준 Opus 4.8이 최상위였고 Grok 4.3이 최하위였다 (HN 코멘트 요지 발췌). 한 코멘터는 Grok의 부진을 흥미롭게 짚었다 — 요지를 옮기면, Grok은 x.com/grok.com 환경에서 웹 검색과 “이거 사실이야?”류 질의에 최적화되도록 훈련된 나머지, API를 통한 문서 워크플로·도구 사용·코드 생성 같은 작업에서는 완전히 무너지는 것처럼 보인다는 것이다 (HN 코멘트 요지 발췌). 같은 파라미터 규모라도 후처리(post-training)가 어떤 워크플로를 겨냥했느냐에 따라 지시 준수 능력이 갈린다는 관찰이다.
왜 문서는 통제에 실패하는가
이 실패를 구조적으로 읽으면, 세 개의 서로 다른 원인이 겹쳐 있다.
첫째, 롱컨텍스트의 실질적 열화. HN에서 가장 많은 지지를 받은 계열의 지적은 이것이다 — 요지를 옮기면, 모델이 100만 토큰 컨텍스트를 광고한다고 해서 그 전부를 실제로 활용할 수 있다는 뜻은 아니라는 것이다. 극단적 양자화와 KV 캐시 압축, 그리고 사용자에게 제공되는 빈약한 샘플러 탓에 긴 컨텍스트의 후반부는 사실상 흐려진다 (HN 코멘트 요지 발췌). 124쪽 규정을 컨텍스트에 넣을 수 있다는 것과, 그 124쪽의 37조 3항을 200번째 도구 호출 시점에 정확히 상기한다는 것은 전혀 다른 문제다. “규칙 세부를 잃어버린다”는 실패 양상은 이 열화의 직접적 증상이다.
둘째, 지시 준수의 시간적 감쇠. 한 코멘터의 경험담이 실무자들의 공감을 샀다 — 요지를 옮기면, Claude는 지시를 잘 따르지만 그것은 약 10분 동안이고, 그 후에는 앞서 말한 것들을 무시하는 듯하다는 것이다. CLAUDE.md에 “거대한 주석 쓰지 마라”, “기존 기능을 재사용하라” 같은 강한 지시를 넣어도 실제 작업 중에는 놀랍도록 빨리 우회되는데, 같은 것을 작업 도중 프롬프트로 다시 말하면 훨씬 잘 수행한다는 것이다 (HN 코멘트 요지 발췌). 이 관찰은 정책 문서 관리에 대한 뼈아픈 함의를 담는다 — 문서에 규칙을 더 쌓을수록 통제가 강해지는 것이 아니라, 오히려 각 규칙의 실효 밀도가 희석될 수 있다.
셋째, 에이전트성의 합성적 본질. 가장 근본적인 지적은 에이전트 능력의 기원을 겨눈다 — 요지를 옮기면, ‘에이전트형 AI’는 사후 훈련 단계에서 도메인별 합성 데이터로 대량의 강화학습을 먹여 억지로 주입한 능력이며, LLM이 특정 핸드북을 준수하도록 후처리되지 않았다면 그냥 작동하지 않는다는 것이다. 에이전트가 코딩 과제에서 유독 뛰어난 이유는 그 워크플로가 만든 사람들 자신의 작업 방식이어서 훈련하기 쉬웠기 때문이라는 관찰이다 (HN 코멘트 요지 발췌). 이 관점에서 재무·의료·보험 규정 준수의 저조한 성적은 놀랍지 않다 — 그 도메인의 규정 준수 워크플로를 겨냥한 합성 데이터가 코딩만큼 풍부하지 않기 때문이다. 이 진단이 옳다면, HANDBOOK.md의 낮은 점수는 모델의 근본적 한계가 아니라 훈련 커버리지의 공백을 반영하는 것일 수 있다. 다만 그 함의는 양날의 검이다 — 점수를 올리는 길이 “해당 도메인의 합성 준수 데이터를 대량 생성해 후처리에 먹이는 것”이라면, 우리는 다시 벤치마크 과적합의 문제로 돌아간다. 특정 핸드북 형식에 맞춰 훈련된 모델이 그 형식을 벗어난 실제 규정 앞에서 다시 무너질 위험은 그대로 남는다.
또 하나 주목할 것은 사고 예산(thinking budget)의 효과다. 최고 사고 예산의 Opus 4.8이 최상위였다는 사실은, 지시 준수가 단순 검색이 아니라 추론 자원을 소모하는 작업임을 시사한다. 규정의 조항 하나를 현재 상황에 적용할지 판단하려면, 조항의 조건절과 눈앞의 맥락을 대조하는 능동적 추론이 필요하다. 컨텍스트 후반부에서 규칙 세부를 잃는 것도, 추론 자원이 도구 호출과 상황 파악에 소진되어 규정 재확인에 배분되지 못하는 현상으로 읽을 수 있다.
세 원인을 종합하면 한 문장이 된다. 문서는 지식을 전달할 뿐, 그 지식이 확장된 행동 지평 전체에 걸쳐 구속력을 유지하도록 보장하지 못한다. 인간 직원에 대한 흥미로운 비교도 스레드에서 나왔다 — 요지를 옮기면, 애초에 인간도 긴 정책 문서를 던져 주고 그대로 따르라고 하면 형편없으며, 이 벤치마크에서 좋은 점수를 내는 모델이 있다면 그것은 초인적 능력을 주장할 만하다는 것이다 (HN 코멘트 요지 발췌). 인간 조직은 이 문제를 문서가 아니라 훈련·감독·체크리스트·감사로 푼다. 문서는 통제의 한 요소일 뿐 통제 그 자체가 아니라는 상식을, 우리는 에이전트 앞에서 잠시 잊고 있었다.
실무자에게 주는 시사점
이 결과를 받아들이면 에이전트 운용 설계가 바뀐다.
규칙을 문서에서 게이트로 옮겨라. “지켰다고 잘못 보고한다”는 실패 양상이 가장 위험하다 — 에이전트의 자기 보고를 신뢰할 수 없다는 뜻이기 때문이다. 중요한 제약은 프롬프트 속 문장이 아니라 실행 가능한 검사로 구현해야 한다. 승인 전 필수 확인은 규정 문장이 아니라 도구 호출을 막는 프리컨디션으로, 컴플라이언스 준수는 사후 감사 스크립트로. 이것은 지난 글에서 다룬 “검증자가 있는 범위로 위임을 자른다”는 원칙의 정책 버전이다.
핵심 규칙은 상시 재주입하라. 지시가 10분 만에 감쇠한다면, 긴 문서 맨 앞에 한 번 적는 것으로는 부족하다. 가장 중요한 소수의 규칙은 매 턴 또는 매 도구 호출 직전에 다시 프롬프트에 삽입하는 편이 낫다. CLAUDE.md를 무한정 늘리는 대신, 진짜 지켜야 할 대여섯 줄을 추려 반복 주입 지점에 배치하는 설계가 실증적으로 더 효과적이다.
문서 길이를 통제의 지표로 착각하지 마라. 124쪽 규정이 20쪽 규정보다 에이전트를 더 잘 통제하지 않는다 — 오히려 반대일 수 있다. 관리자가 “우리는 상세한 정책 문서가 있으니 안전하다”고 느끼는 그 안도감이야말로 HANDBOOK.md가 겨냥한 착각이다. 문서는 감사의 근거이자 인간의 참조물로서 여전히 필요하지만, 그것이 실행 시점의 행동을 보장한다는 가정은 폐기해야 한다.
전망 시나리오를 나누면 — 낙관적으로는, 이런 벤치마크가 표준이 되면서 랩들이 “지시 준수의 시간적 안정성”을 명시적 훈련 목표로 삼고, 롱컨텍스트 지시 준수가 다음 세대의 경쟁 지표가 된다. 비관적으로는, 벤치마크 점수를 올리기 위한 과적합이 일어나 HANDBOOK.md류 과제에는 강하지만 실제 사내 규정에는 여전히 약한 모델이 나온다. 현실적 중간값은, 문서 기반 통제의 한계가 상식이 되면서 조직이 에이전트용 컴플라이언스를 문서가 아니라 도구 게이트와 감사 파이프라인으로 재구축하는 — 즉 관리의 무게중심이 프롬프트에서 인프라로 이동하는 — 방향일 것이다.
결론
리드 질문에 답하자면, 실패하는 것은 모델의 능력만이 아니라 “문서 = 통제”라는 관리 모델 자체다. 36.2%라는 천장은 모델을 더 키우면 얼마간 올라가겠지만, 문제의 본질 — 긴 문서에 적힌 규칙이 긴 행동 지평 끝까지 구속력을 유지하도록 보장하는 메커니즘이 문서 안에는 없다는 것 — 은 파라미터로 풀리지 않는다. 인간 조직이 핸드북만으로 돌아가지 않는 것과 같은 이유다.
HANDBOOK.md가 주는 교훈은 비관이 아니라 재설계의 좌표다. 규칙을 문서에서 게이트로, 통제를 서술에서 실행으로 옮기는 것. 당신의 에이전트 설정에서 CLAUDE.md에 적힌 규칙 중 몇 개가 실제로는 실행 시점에 강제되고 있는가 — 그리고 나머지는 그저 지켜지기를 바라는 기도문은 아닌가. 이 질문에 정직하게 답하는 것이, 36%의 천장 아래에서 일하는 모든 이의 출발점이다.
출처: