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을 반환해 규칙 파일 없이도 해당 차례를 계속 진행함

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

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

큰 명세와 에이전트 구현 사이의 드리프트는 매우 큼. 많이 시험해 봤지만 모델 종류와 무관하게 Fable이나 Sol도 세부 사항을 대량으로 놓치고 벗어남
명세와 구현의 간극을 닫고 구현이 명세와 일치하게 만드는 http://engine.build를 개발 중임. 직접 코드로 복잡한 문제를 해결할 때와 같은 만족감은 아니지만, 명확한 명세를 작성하고 문제를 깊이 생각하는 일도 충분히 만족스러움

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