과잉 공학은 때로 무공학보다 나쁘다
앞 장에서 Harness의 다섯 구성요소를 보았다면 자연스러운 반응은 모든 구성요소를 더 정교하게 만드는 것이다. 원문은 바로 그 직관을 뒤집는다. 여러 독립 팀이 서로 다른 환경에서 같은 결론에 도달했다. 지나치게 두꺼운 Harness는 정보와 규칙과 계산을 늘리지만, Agent의 실제 수행에는 오히려 장애가 될 수 있다.
더 많이 넣는다
규칙, 문서, 추론, 컨텍스트, 평가 단계를 계속 추가한다. 겉으로는 안전해 보이지만 중요한 신호가 희석되고, token·시간·주의력이 실제 작업에서 빠져나간다.
필요한 것만 남긴다
실제 실패에서 검증된 규칙, 프로젝트 고유 정보, 안전·품질의 경계, 그리고 필요한 순간 더 깊이 들어갈 수 있는 포인터만 남긴다.
Context Anxiety — 모델도 컨텍스트의 끝을 의식한다
Anthropic은 장시간 실행 Agent를 개발하면서 Claude Sonnet 4.5가 자신의 컨텍스트 창을 의식하는 듯한 행동을 관찰했다고 원문은 설명한다. 문제는 그 인식이 침착함이 아니라 조급함을 만들었다는 점이다.
보이는 현상
모델이 컨텍스트 한계에 가까워졌다고 판단하면 일찍 마무리하려 하고, 진행 상황을 먼저 요약하고, 수정 작업을 더 성급하고 단정적으로 진행한다. 겉으로는 결단력이 높아진 듯 보이지만 원문은 이를 ‘서두름’으로 본다.
Harness의 대응
단순 compaction만으로 충분하지 않아 Sonnet 4.5에서는 컨텍스트를 완전히 비우고 구조화된 handoff 상태로 새 Agent를 시작하는 context reset까지 추가했다고 서술된다. 이후 Opus 4.5에서는 이 행동이 사라져 해당 장치를 제거할 수 있었다.
컨텍스트는 무료 자원이 아니다
원문은 Anthropic의 엔지니어링 글을 인용해, 기술적으로 더 큰 창이 가능하더라도 약 100만 token 부근에서 뚜렷한 성능 상한이 나타난다고 설명한다.
관련 없는 여러 작업을 한 세션에 섞어 컨텍스트를 불필요하게 팽창시킨다.
실패한 접근의 흔적이 누적되어 이후 판단 공간을 오염시킨다.
지시가 너무 많아지면 정작 중요한 규칙이 모델의 주의에서 밀려난다.
범위를 정하지 않은 조사와 탐색이 컨텍스트 창을 소모한다.
설명서가 아니라 지도를 준다
OpenAI의 원칙은 분명하다.
짧은 AGENTS.md를 입구에 두고,
상세한 전문 지식은 필요할 때 찾아가도록 포인터를 둔다.
원문은 약 100줄을 상징적인 기준으로 반복해서 제시한다.
얇고 안정적인 입구 + 깊은 전문 문서로의 포인터
OpenAI Codex 팀은 모든 규칙과 관례와 아키텍처 결정을 한 파일에 담는 거대한 AGENTS.md를 시도했지만
결과가 좋지 않았다고 서술한다.
Boris Cherny의 CLAUDE.md도 약 100줄이며,
500~1000줄 이상의 비대한 파일은 핵심 지시를 오히려 묻을 수 있다는 경험을 제시한다.
Reasoning Sandwich — 끝까지 최고 강도로 생각하면 오히려 진다
LangChain이 Terminal Bench 2.0에서 비교한 결과는 이 장의 또 다른 역설을 보여준다. 최고 추론 강도를 전 구간에 적용한 구성이 가장 낮은 점수를 냈다. 이유는 모델이 덜 똑똑해서가 아니라 많은 작업이 시간 제한을 넘겼기 때문이다.
Terminal Bench 2.0
추론 샌드위치
처음에는 충분히 깊게 생각해 방향과 계획을 세운다.
이미 정한 계획을 구현하는 구간에서는 추론 강도를 낮춰 token과 시간을 아낀다.
마지막 검증에서 다시 최고 수준의 추론을 투입해 오류와 누락을 확인한다.
규칙은 언제 더하고, 언제 벨 것인가
“적게 하라”는 말만으로는 실무가 되지 않는다. 문제는 그 ‘적음’의 경계다. 원문은 Mitchell Hashimoto의 귀납적 방법을 출발점으로 둔다. 빈 파일에서 시작해 실제 Agent의 실수가 발생했을 때만 규칙을 추가한다.
AI가 스스로 발견할 수 있는가?
발견할 수 있다면 적지 않는다. 코드와 프로젝트 파일만 보고는 알 수 없는 정보만 입구 규칙에 남긴다.
Sonnet 4.5에서 필요했던 Sprint 분해와 매 Sprint 평가가 Opus 4.6에서는 제거됐다는 사례처럼, 옛 모델의 약점을 위한 규칙은 새 모델에서 잡음이 될 수 있다.
표준 언어 관례, 상세 API 튜토리얼, “깨끗한 코드를 써라” 같은 일반론, React 사용 여부나 TypeScript 파일 확장자처럼 코드에서 추론 가능한 정보는 컨텍스트 낭비가 될 수 있다.
버전 번호, 현재 Sprint 작업, 오늘 회의 기록처럼 수명이 짧은 정보는 안정적인 지시 파일과 맞지 않는다.
규칙이 누적되면 오래된 지시와 새 지시가 맞부딪힌다. 원문은 정기적인 garbage collection으로 오래된 규칙 삭제, 중복 병합, 충돌 해소를 권한다.
원문은 AGENTS.md가 일부 조건에서 Agent 성능을 돕지 못하고 오히려 방해할 수 있다는 연구를 소개한다. 연구자의 권고를 “사람이 코드만 보고는 추론하기 어려운 정보만 적어라”로 요약한다. 특수 도구 체인, 사용자 정의 빌드 명령, 비표준 프로젝트 규약이 그 예다.
감산 체크리스트
원문 28쪽은 앞선 논의를 바로 적용할 수 있는 보존·삭제 목록으로 정리한다. 이 목록은 Harness의 품질을 규칙 수가 아니라 신호의 밀도로 평가하게 만든다.
남겨야 할 규칙
- Agent가 반복해서 실제로 저지른 오류
- 프로젝트 고유의 아키텍처 결정과 관례
- 기본 행동과 다르게 동작해야 하는 규칙
- 핵심 안전·품질 레드라인
- 깊은 전문 문서로 연결하는 포인터
걷어내야 할 규칙
- 이전 모델의 약점을 보완하던 패치
- AI가 코드만 읽어도 알 수 있는 관례
- 한 번도 실제로 발동하지 않은 ‘혹시 몰라서’ 규칙
- 버전·Sprint·당일 메모처럼 자주 변하는 구체 정보
- 튜토리얼 성격의 장문 설명
모델이 강해지면 Harness는 얇아져야 한다
감산은 지시 파일에만 적용되지 않는다. 원문은 Anthropic의 Evaluator 구조도 모델의 능력 변화에 맞춰 줄어들었다고 설명한다. Harness는 고정된 제품이 아니라 모델과 과제의 관계에 따라 두께가 달라지는 구조다.
Sonnet 4.5 시기
- Sprint 단위 작업 분해 필요
- 각 Sprint마다 평가 필요
- context reset 필요
Opus 4.6 시기
- Sprint 메커니즘 제거
- context reset 제거
- Evaluator를 전체 종료 후 1회 평가로 축소
규칙을 추가하는 일은 쉽다
실패 직후에는 원인이 선명하고, 새로운 규칙이 안전감을 준다. 그래서 Harness는 자연스럽게 두꺼워진다.
규칙을 삭제하는 일에는 판단이 필요하다
삭제한 뒤 문제가 생기면 즉시 후회하지만, 쓸모없는 규칙을 남겨둔 비용은 눈에 잘 보이지 않는다. 그러나 그 규칙은 매 실행에서 중요한 신호의 비중을 낮춘다.
더하는 일은 흔적을 남긴다.
덜어내는 일은 판단을 남긴다.
좋은 Harness는 크기로 증명되지 않는다.
모든 규칙이 필요한 까닭을 가지고 있고,
모든 문장이 제 자리에서 일하고 있을 때
비로소 가볍고 단단해진다.
적음은 부족함이 아니라, 중요한 것을 남길 수 있는 여백이다.