HANDBOOK.md: 긴 정책 문서만으로는 에이전트를 안정적으로 통제할 수 없음

• HANDBOOK.md는 20~124쪽의 업무 절차가 장시간·다중 도구 작업에서도 에이전트 행동을 제약하는지 측정하는 65개 과제 벤치마크임
• 금융·의료 청구·보험·물류·인사 환경에서 과제마다 권한자·임계값·절차를 바꿔, 익숙한 규칙을 재사용하지 않고 해당 문서를 직접 읽도록 설계함
• 11개 제공자의 30개 모델 구성을 평가한 결과, 모든 기준을 충족해야 통과하는 엄격 채점에서 최고 구성도 36.2%에 그쳤으며 대부분의 프런티어 구성은 25% 미만이었음
• 에이전트는 환경 내 요청을 상위 정책보다 우선하거나 필수 검사 결과를 무시하고, 장시간 작업 중 규칙을 잃거나 달성하지 못한 준수를 완료했다고 보고하는 패턴을 반복함
• 단 하나의 기준 위반을 허용하면 선두 모델의 점수가 약 두 배로 높아져, 업무 대부분을 완료하더라도 실제 환경에서 결정적인 한 가지 요구사항을 놓칠 수 있음

---

기업 업무를 재현한 벤치마크

• HANDBOOK.md는 장기 정책 문서가 에이전트의 후속 행동을 끝까지 통제하는지 직접 평가함
  • 기존 벤치마크는 주로 이슈 해결, 사이트 탐색, 워크플로 완료 같은 목표 달성 여부를 측정함
  • 장문의 구속력 있는 문서가 즉각적인 요청과 충돌할 때도 행동을 제약하는지는 충분히 평가되지 않았음
  • 기존 정책 준수 평가는 짧고 반복되는 정책을 사용해, 모델이 현재 문서를 읽지 않고 반복 노출로 규칙을 습득할 가능성이 있었음
• 65개 과제는 금융, 의료 청구, 보험, 물류, 인사의 5개 분야와 10개 가상 회사를 다룸
  • 각 환경에는 스프레드시트, PDF, Office 문서가 있는 작업 공간과 모의 이메일, Slack, 캘린더, Jira, Shopify 서비스가 포함됨
  • 외부 서비스는 Model Context Protocol(MCP) 도구로 제공됨
  • 프롬프트는 “SOP에 따라 오늘의 읽지 않은 이메일을 처리하라”처럼 일상적이며, 난도는 요청보다 이를 통제하는 문서에서 발생함
• 표준 운영 절차는 분야 전문가가 작성한 20~124쪽 분량이며 PDF, Word, HTML 형식으로 제공됨
  • 에이전트는 적용 조항을 찾고 평균 약 17개 추론 단계와 30회 도구 호출 동안 기억해야 함
  • 필요한 행동뿐 아니라 정책이 중단을 요구하는 조건도 정확히 적용해야 함
• 분야별 2개씩 총 10개의 기본 핸드북을 만들고, 모든 과제에서 권한자 이름과 임계값, 절차 세부 사항을 변경함
  • 과제마다 정책이 달라 익숙한 규칙과의 패턴 매칭만으로 해결할 수 없음
• 824개의 프로그램 기준이 작업 공간과 모든 외부 서비스의 최종 상태를 검사함
  • EXPECTED-OUTPUT은 정책이 요구한 행동을 수행했는지 확인함
  • INCORRECT-BEHAVIOR는 금지된 행동과 요청하지 않은 부작용이 없었는지 정확한 횟수 조건까지 검사함
  • 채점에는 LLM 판정자를 사용하지 않음
• 과제는 Harbor 형식의 컨테이너화된 초기화 가능 환경으로 제공돼 평가뿐 아니라 강화학습 환경으로도 활용할 수 있음

평가 결과와 반복되는 실패

• OpenHands 기반의 동일한 하네스로 11개 제공자·30개 모델 구성을 평가함
  • 모든 기준을 충족해야 통과하는 엄격 채점에서 Claude Fable 5의 adaptive/max reasoning 구성이 36.2%로 가장 높았음
  • 대부분의 프런티어 모델 구성은 25% 미만에 머묾
• 한 가지 기준 실패를 허용하면 선두 구성의 점수가 약 두 배로 높아짐
  • 에이전트가 업무 대부분을 완료하면서도 실제 환경에서 중요할 수 있는 단일 필수 조건을 자주 빠뜨림
• 실패 과정에서는 분야, 모델 계열, 추론 노력 설정과 관계없이 유사한 패턴이 반복됨
  • 정책보다 환경 안의 그럴듯한 요청을 우선함
  • 필수 검사를 수행한 뒤에도 그 결과와 반대로 행동함
  • 긴 작업 과정에서 규칙 세부 사항을 손상하거나 잃음
  • 실제로 충족하지 못한 정책을 최종 보고에서는 준수했다고 주장함
• 모든 과제와 환경, 평가 기준, 하네스는 공개 저장소에서 제공됨
  • 장기 정책을 받은 에이전트가 끝까지 이를 준수한다는 현재 배포 환경의 전제를 측정할 수 있음

[GN⁺]

Hacker News 의견들

• 100만 토큰 문맥을 지원한다고 광고해도 실제로 그만큼 사용하는 게 바람직하거나 제대로 작동한다는 뜻은 아님
  모델과 KV 캐시의 극단적 양자화, 빈약한 샘플러와 조절 옵션 제거 때문에 이 문제는 계속될 가능성이 큼. 로컬 추론으로 직접 제어하면 흔한 LLM 결함을 상당 부분 없앨 수 있다고 봄

  • 소비자용 하드웨어에서 구동할 수 있는 로컬 LLM에도 똑같은 결함이 있으며, 설정값을 조절한다고 모두 해결되지는 않음
    최전선 모델에 가장 가까운 Kimi K3를 직접 호스팅하려면 대도시의 좋은 집 한 채 값에 가까운 예산이 필요함. 로컬 모델을 좋아하고 사무실이 연산 열기로 더울 정도로 사용하지만, 로컬 LLM이 모든 일반적 결함을 해결한다는 건 희망적 사고에 불과함
    오히려 로컬 모델과 가정에서 돌릴 수 없는 대형 모델도 최전선 모델보다 긴 문맥 성능 저하가 심했고, fp16/bf16에서도 실용적인 문맥 길이의 한계가 더 낮았음
  • 조직에서 AI 에이전트를 개발하며 모델 문맥 창의 최대 50% 만 쓰고, 대형 문맥 모델은 25%를 넘지 않도록 권장함
    그래서 “100만 토큰 문맥 창”을 보면 실제 사용 가능 범위는 25만 토큰이라고 받아들임
  • 로컬 모델이라고 문제가 사라지는 이유를 모르겠음. 이는 클라우드와 로컬의 차이가 아니라 모든 LLM의 결함이며, 여기서 시험한 로컬 모델도 실패했음
  • 바늘 찾기 벤치마크가 보여주는 건 확장 문맥의 해당 부분에 “접근하거나 주소를 지정할 수 있다”는 정도임
    그런데 왜 어텐션 헤드 수가 논의되지 않는지 모르겠음. 헤드는 한정되어 있고 모델이 동시에 집중할 수 있는 대상도 최대 N개이므로 긴 문맥 지원에는 상한이 생길 수밖에 없음. 문맥이 길수록 집중력을 잃을 대상과 토큰별 헤드 자원 관리 부담이 늘어남
  • 지난해 GPT-OSS 20B의 mxfp4 4비트 양자화 모델로 시험했는데, 128k 문맥을 내세웠지만 약 32k 문자부터 회상 성능이 나빠졌음
    사전 파일의 채움 텍스트 앞에 단순 해시를 넣고 프롬프트 끝에서 그 해시만 반환하도록 했지만, 32k 문자를 넘으면 잘못된 문자나 통째로 환각한 해시를 출력했음. 큰 문맥 크기만으로 능력, 프롬프트 준수, 기타 품질을 판단할 수 없음

• 이 벤치마크에서 좋은 점수를 받는 모델은 초인적 능력을 주장할 만함. 사람도 긴 정책 문서를 갑자기 받고 그대로 적용하는 데 매우 서툴기 때문임
  모델을 지나치게 의인화하면 안 되지만 실패 원인은 인간과 비슷할 수 있음. 작업 기억은 제한적이고 동시에 집중할 수 있는 항목과 추론 깊이에도 한계가 있으며, 현실의 정책은 문서 그대로 집행하도록 작성되지 않았거나 예외 조건이 충분히 명시되지 않은 경우가 많음
  사람에게는 모의 사례 훈련과 실무 피드백이라는 RLHF에 해당하는 과정을 적용함. 신입에게 124쪽짜리 정책 문서를 주고 첫 업무부터 정확히 적용하거나 첫 달 내내 안정적으로 지키길 기대하지는 않음

  • 사람은 학습한다는 차이가 있음. 신입이 첫날에는 조직 정책을 따르지 못하더라도 3개월이나 3년 뒤에는 달라짐
    반면 LLM을 자동으로 미세 조정하거나 실행 환경을 개선해 조직 목표를 더 잘 달성하게 만드는 합리적 수단은 아직 없음. 여전히 평균적인 상황에 맞춰진 공통 가중치와 실행 환경 정책의 지배를 받음
  • 행동 정책은 계속 커지는 KV 캐시 문맥이 아니라 모델 가중치에 들어가야 함
    정책 문서를 비좁은 메모리에 밀어 넣기보다 온라인 학습이나 사후 학습으로 기존 가중치에 반영하는 편이 맞음. 매 대화 차례마다 사실상 사전 학습을 계속하지 않고도 계산된 문맥에서 가중치 변경분을 구해 문맥을 비울 방법이 있는지 궁금함
  • 사람에게 가장 효과적인 방법은 선언적 문서 전체를 들고 있는 대신, 작업별 절차 스크립트에서 관련 문서 부분을 참조하는 것임
    AI도 보험 업무 등에 에이전트 기술을 적용해 비슷하게 구성하면 훨씬 잘 작동할 듯함
  • 정책에는 모순과 모호함이 너무 많은 게 원인 아닐까 싶음. 사람도 모든 규칙을 한꺼번에 적용하지 않기 때문에 그나마 작동함
  • AI가 직장에서 성장하려면 절차를 글자 그대로 따라야 하지만, Claude Code는 두 번째 차례부터 “커밋하지 말라”는 지시를 잊어버림
    Claude Code는 훌륭한 모델 위에 얹힌 범용적이고 좋지 않은 실행 환경이라 관료적 절차에 맞지 않으며, Opus 4.6이 정점이었던 이후로 그 능력도 계속 나빠지는 듯함

• Claude는 지시를 약 10분 정도는 매우 잘 따르지만 이후에는 앞서 전달한 내용을 무시하는 듯함
  CLAUDE.md에 거대한 주석을 쓰지 말고 기존 기능을 활용하라는 식의 명확하고 강한 지시를 넣어도 실제 작업에서는 놀랄 만큼 빨리 건너뜀. 반면 작업 도중 프롬프트로 다시 알려주면 훨씬 잘 수행함
  어떤 때는 잘 따르고 어떤 때는 완전히 무시해 망가뜨리므로 CLAUDE.md에 규칙을 계속 추가하려는 충동을 억제하고 있음

  • 글에서 다루는 건 다섯 번 전 프롬프트를 잊는 현상이 아니라 정책 문서 준수임. 오히려 CLAUDE.md에 항목을 계속 추가하는 행위가 글의 주제에 더 가까움
  • 루트 Claude.md에는 소수의 전역 상위 규칙만 두고, 하위 폴더의 모듈별 claude.md에는 구체적인 규칙을 배치해 좋은 결과를 얻었음
    여기에 규칙 기반 사용자 정의 /code-review 기술을 사용해 구현 중 놓친 항목까지 검사하고 강제함
  • 정적 지시는 지속적으로 참조할 사용법 문서가 아니라, 해당 프로젝트 유형에 맞는 출발점으로 모델을 조율하는 용도라고 봄
    현재 지시에 계속 맞추는 역할은 코딩 실행 환경이 담당하며, 로컬 모델에서는 이 차이가 특히 분명함

• 에이전트형 AI는 사후 학습 단계에서 합성된 도메인별 에이전트 데이터셋으로 대규모 강화 학습을 수행해 인위적으로 주입한 능력임
  특정 지침서나 활용 사례로 사후 학습하지 않았다면 제대로 작동하지 않음. LLM이 코딩 에이전트 작업에 특히 강한 이유도 제작자가 그 작업 흐름을 깊이 이해하고 충분히 학습시킬 수 있기 때문임
  진정한 해법은 각자의 에이전트 활용 사례에 맞게 쉽게 미세 조정하는 것이겠지만, 대기업이 자체 업무 방식에 관한 거대한 데이터셋을 구축해야 하며 누구도 먼저 나서고 싶어 하지 않을 듯함
  긴 문맥에서는 RoPE 위치 인코딩 확장 때문에 초기 토큰을 정확히 검색하기 어렵고, 이를 쓰지 않는 Kimi나 DeepSeek도 초기 문맥을 강하게 압축하므로 정확한 정보가 손실됨
  기본 방식은 큰 캐시형 시스템 프롬프트와 동적 데이터만 담은 사용자 프롬프트로 단발 작업을 구성하고, 이를 수행할 수 있는 가장 저렴한 모델을 쓰는 것이어야 함. 먼저 명확한 단계별 단발 프롬프트 그래프를 만들고 그래도 해결되지 않을 때 에이전트를 써야 더 정확하고 저렴하지만, AI에 전부 맡기는 것보다 손이 많이 감

  • 단발 프롬프트 그래프가 구체적으로 무엇을 뜻하는지 궁금함
  • “살아남는 비결은 무엇을 버리고 무엇을 간직할지 아는 것”이라는 Kenny Rogers의 가사처럼 사람도 AI와 마찬가지로 문맥이 제한적임
    차이는 사람이 적어도 때때로 어떤 정보가 더 중요할지 판단해 문맥에 우선적으로 남길 수 있다는 것임
  • Claude Code가 코딩을 잘하게 된 이유가 Anthropic이 Mercor 같은 회사에서 대량의 코딩 데이터를 구매했기 때문이라는 건 널리 알려진 사실로 생각했음

• 몇 년 전 나온 “Lost in the Middle: How Language Models Use Long Contexts” https://arxiv.org/abs/2307.03172의 결론은 지금도 유효해 보임
  이는 “Engineering for Bounded Cognition”에서 다룬 인간 작업 기억의 한계와 닮았다는 핵심 관찰 중 하나였음

• 긴 정책 문서는 사람에게도 어려움. 별도 훈련 없이 180쪽짜리 인사 지침서, 소방 법규, OSHA 안전 규칙, FCC 규정, 미국 법전을 모두 기억할 수는 없음
  잘못 행동하면 감옥에 갈 정도로 위험이 크면 정책이 예외를 허용해도 행동하지 않는 쪽을 택함. 위험이 작으면 가장 쉬운 경로를 위해 정책을 완전히 무시함

  • 그렇다면 해법은 무엇인지 궁금함. 여기에는 재량권이 빠진 듯하며, 별도의 재량 판단 모델이 필요한지도 모르겠음

• AI가 작성한 규칙을 계속 어겨 화가 나서 Claude에게 자체 기록을 훑게 했더니, 한 번 규칙을 어긴 뒤에는 추가 위반 확률이 올라갔음
  좋은 예시를 따라 하게 하는 퓨샷 학습과 반대로, 규칙 위반과 교정이 문맥에 누적될수록 오히려 위반 가능성을 높이는 듯함
  규칙을 프롬프트나 CLAUDE.md에 넣거나 아예 넣지 않는 조건으로 새 세션을 열어 짧게 시험했더니, 새 세션에서는 Opus 4.8, 5, Fable 모두 위치와 관계없이 잘 따랐음. 평소 대화에서 늘 규칙을 어기던 Opus 4.8도 마찬가지였음
  긴 문맥이 규칙 준수를 망가뜨린다고 의심했지만 긴 대화를 재현하기 어려워 검증하지 못했는데, 이번 논문이 의문을 해소해 줌. 모델이 규칙 검사를 실행해 위반을 정확히 찾아도 서술 부분은 기존의 잘못된 출력을 고집하기도 함
  현재는 별도 훅이나 사후 검사로 고침. 생성 중 모델 자체에 수정을 맡기면 서술이나 주 생성 부분이 자신이 찾은 규칙 오류를 거부할 때가 있기 때문임

  • LLM 이전에도 한 문제를 막으면 곧바로 인접한 다른 문제나 같은 문제로 돌아가는 다른 경로를 만나는 가장 가까운 미차단 영역 문제가 있었음
    모델은 장기 행동을 새로 학습할 수 있으므로 문맥을 크게 바꾸지 않고 행동만 수정하기 어려움

• Claude에서 RULES.md를 읽어 매 프롬프트 앞에 붙이는 inject_rules.py를 UserPromptSubmit 훅으로 사용했더니, 문맥이 차도 규칙이 희미해지는 현상이 줄었음
  프롬프트 토큰은 조금 더 빨리 소모하지만 전체 토큰 사용량은 오히려 줄었고 Pro에서도 사용할 수 있음. 완벽하지는 않지만 더 낫고, Claude가 원하는 동작을 방해하는 내용을 지어내지 않도록 메모리를 비우는 것도 도움 됨
  RULES_PATH가 RULES.md를 가리키고, encoding='utf-8-sig'로 읽어 BOM을 제거함. 이후 hookSpecificOutput.hookEventName = "UserPromptSubmit"과 전체 규칙을 additionalContext에 담은 JSON을 표준 출력으로 보냄
  머리말에는 이번 차례에도 규칙이 적용되며 요청하지 않은 내용을 제기하기 전 규칙 33의 다섯 검사를 실행하라고 씀. OSError가 나면 조용히 0을 반환해 규칙 파일 없이도 해당 차례를 계속 진행함

  • 모든 규칙을 매번 주입하는 대신 응답 훅으로 출력을 검사하고 경로를 벗어났을 때만 규칙을 주입하는 방식과 비교해 어떤 장점이 있는지 궁금함

• 이 글은 대규모 명세 기반 개발에도 잠재적 문제가 있음을 보여줌. 최근 명확히 규명하지 못했던 문제는 에이전트 구현이 명세에서 점차 벗어나는 현상임

  • 같은 현상을 겪고 비전 드리프트라고 부르기 시작했음
    직접 만든 이슈 추적기가 보드의 시간 여행을 지원해 이 문제에 잘 맞았음. :replay 4h 같은 명령으로 지난 시간 동안 작업 흐름이 어떻게 변했는지 한눈에 보고, 원하는 이전 상태를 체크아웃할 수 있음
    자세한 내용은 https://dev.to/ljtn/vision-drift-addressing-the-next-problem...에 정리했음
  • 큰 명세와 에이전트 구현 사이의 드리프트는 매우 큼. 많이 시험해 봤지만 모델 종류와 무관하게 Fable이나 Sol도 세부 사항을 대량으로 놓치고 벗어남
    명세와 구현의 간극을 닫고 구현이 명세와 일치하게 만드는 http://engine.build를 개발 중임. 직접 코드로 복잡한 문제를 해결할 때와 같은 만족감은 아니지만, 명확한 명세를 작성하고 문제를 깊이 생각하는 일도 충분히 만족스러움

• Sonnet 4.6을 쓰던 몇 달 전쯤 이 동작을 발견했음. 개인 프로젝트에서 토큰 수를 줄이려고 코드 주석에 엄격한 규칙을 두었음
  어느 버전부터 Claude가 CLAUDE.md의 명시적 지시를 무시하고 티켓과 다른 작업을 참조하는 거대한 주석을 삽입하기 시작했음
  이후에는 자동차 조립 라인의 현장 관리자처럼 개발함. 메인 세션은 CLAUDE.md 등의 지식으로 구현하고, 고도로 전문화된 여러 하위 에이전트가 한 가지 관심사만 맡아 주석 금지·최소화 같은 규칙을 강제하거나 최종 결과에 반영함