기본 설정을 의심하라 — 모델과 하네스의 과적합이 당신의 에이전트를 느리게 만든다
이 시리즈의 3편에서 흥미로운 사실을 언급했다. Terminal Bench 2.0에서 Claude Opus 4.6은 Claude Code — 자신이 훈련된 하네스 — 안에서 33위였지만, 다른 하네스에서는 5위권으로 올라갔다.
이 숫자가 의미하는 바를 제대로 소화하지 않고 넘어갔다. 4편에서 Anthropic의 아키텍처를, 5편에서 실전 가이드를 다루면서, 가장 반직관적이고 실전적으로 중요한 인사이트를 놓쳤다.
기본 하네스를 그대로 쓰는 것이 최적이 아닐 수 있다.
이 글에서 그 이야기를 마무리한다.
과적합은 어떻게 발생하는가
프론티어 코딩 모델은 자신의 하네스 안에서 후훈련(post-training)된다. Claude는 Claude Code 환경에서, Codex 모델은 Codex 환경에서 수천 시간의 코딩 작업을 수행하며 최적화된다.
이 과정에서 모델은 특정 하네스의 패턴에 적응한다.
- Claude Code가 도구를 호출하는 방식
- 에러를 반환하는 형식
- 컨텍스트를 구성하는 순서
- 파일 편집 도구의 인터페이스
모델은 이 특정 환경에서의 성능을 극대화하도록 훈련된다. 문제는 극대화가 일반화를 보장하지 않는다는 것이다.
머신러닝에서 과적합(overfitting)이란, 훈련 데이터에 너무 잘 맞춰져서 새로운 데이터에 대한 성능이 오히려 저하되는 현상이다. 모델-하네스 관계에서도 같은 일이 일어난다. 모델이 기본 하네스의 특이점(quirk)에까지 적응하면서, 다른 구성에서의 잠재력이 묻힌다.
구체적 사례: Codex와 apply_patch
OpenAI의 Codex 모델이 apply_patch라는 파일 편집 도구에 극도로 결합된 사례가 있다. Codex 모델을 다른 하네스(OpenCode)에서 사용하려 했을 때, 별도의 apply_patch 도구를 추가해야 했다. 모델이 그 특정 도구 인터페이스 없이는 파일 편집을 제대로 수행하지 못했기 때문이다.
모델이 "파일을 편집하는 법"을 배운 게 아니라, "apply_patch를 호출하는 법"을 배운 것이다.
구체적 사례: Hashline 실험의 역설
Can Boluk의 Hashline 실험을 다시 보자. 각 줄에 해시를 붙여 모델이 줄 번호로 위치를 참조하게 했더니, Grok Code Fast 1이 6.7%에서 68.3%로 뛰었다.
이 모델의 "실력"이 갑자기 10배 좋아진 게 아니다. 기존 하네스의 파일 편집 인터페이스가 이 모델의 잠재력을 억누르고 있었던 것이다. 하네스 인터페이스 하나를 바꿨을 뿐인데, 묻혀 있던 능력이 드러났다.
"33위"의 함의
Claude Opus 4.6이 Claude Code에서 33위라는 것은, Opus 4.6이 나쁜 모델이라는 뜻이 아니다. Claude Code의 기본 하네스가 Opus 4.6의 잠재력을 최대한 끌어내지 못하고 있다는 뜻이다.
왜 이런 일이 생기는가? 몇 가지 가설이 있다.
1. 하네스가 이전 모델에 맞춰져 있다
Claude Code의 기본 설정은 여러 모델 세대에 걸쳐 점진적으로 발전해왔다. 초기에 Opus 4.5의 "컨텍스트 불안"을 해결하기 위해 도입한 스프린트 분할, 강제 체크포인팅 같은 메커니즘이 아직 남아 있을 수 있다. Opus 4.6은 이런 보조 장치 없이도 장기 작업을 처리할 수 있는데, 기본 하네스가 불필요한 제약을 가하고 있는 것이다.
Anthropic 스스로 이것을 인정했다. 3-에이전트 하네스 논문에서 Opus 4.6으로 전환한 후:
- 스프린트 분해 구조를 제거할 수 있었다
- 평가자가 단일 패스 검증으로 전환됐다
- 복잡도가 줄어들면서도 성능은 유지됐다
"하네스가 인코딩하는 가정은 모델이 발전하면 낡아진다." 이것은 Anthropic의 공식 입장이다.
2. 기본 도구 인터페이스가 범용적이지만 최적은 아니다
Claude Code의 파일 편집 도구, 검색 도구, bash 실행 도구는 범용성을 위해 설계됐다. 어떤 프로젝트에서든 작동해야 하기 때문이다. 하지만 당신의 프로젝트에 최적화된 건 아니다.
3. 컨텍스트 구성이 일반적이다
기본 하네스는 CLAUDE.md를 로드하고, 도구 설명을 주입하고, 이전 대화를 유지한다. 하지만 당신의 작업에 정말 필요한 컨텍스트가 무엇인지는 기본 하네스가 알 수 없다.
실전 지침: 기본 설정을 의심하는 법
5편에서 다룬 실전 가이드에 빠져 있던 것이 이것이다. "하네스를 구축하라"뿐만 아니라, "기본 하네스부터 의심하라."
1. 기본 도구를 작업에 맞게 래핑하라
Claude Code의 기본 도구를 그대로 쓰지 말고, 프로젝트에 특화된 래퍼를 만들어라.
## 도구 사용 규칙 (CLAUDE.md)
- 파일 검색 시 Glob 대신 `npm run find-component [name]` 사용
(프로젝트의 컴포넌트 구조에 맞춘 검색)
- 테스트 실행 시 `npm test` 대신 `npm run test:affected` 사용
(변경된 파일에 관련된 테스트만 실행)
- 빌드 확인 시 전체 빌드 대신 `npm run typecheck` 사용
(타입 에러만 빠르게 확인)
LangChain이 Terminal Bench에서 25단계를 뛰어오른 비결이 이것이다. 기본 도구를 그대로 쓰지 않고, 실패 패턴을 분석한 후 도구 인터페이스를 작업에 맞게 조정했다.
2. 불필요한 보호 장치를 제거하라
5편에서 "점진적 작업을 강제하라"고 했다. 맞는 말이다 — 대부분의 경우에. 하지만 당신의 모델과 작업이 이미 충분히 안정적이라면, 과도한 체크포인팅이 오히려 생산성을 떨어뜨린다.
확인할 질문들:
- 강제 스프린트 분할이 필요한가? Opus 4.6은 2시간 이상 스프린트 구조 없이 일관성 있게 작업할 수 있다.
- 매 도구 호출마다 타입 체크가 필요한가? 간단한 수정에도 전체 타입 체크가 돌면 속도가 극적으로 떨어진다. 커밋 시점에만 체크하는 것이 더 효율적일 수 있다.
- 서브 에이전트가 진짜 필요한가? 작업이 단순하면 서브 에이전트 오버헤드가 직접 처리하는 것보다 비용이 클 수 있다.
Anthropic의 원칙을 거꾸로 적용하라: "하네스가 인코딩하는 가정이 낡았는지 정기적으로 재검토하라." 당신의 하네스도 마찬가지다. 3개월 전에 추가한 규칙이 지금도 필요한가?
3. 에이전트의 실패를 분류하라
모든 실패가 같은 실패가 아니다. 실패를 분류해야 올바른 하네스 조정이 가능하다.
| 실패 유형 | 원인 | 대응 |
|---|---|---|
| 모델 능력 부족 | 모델이 작업 자체를 처리할 수 없음 | 더 강한 모델로 전환, 또는 작업 분해 |
| 컨텍스트 부족 | 필요한 정보가 컨텍스트에 없음 | CLAUDE.md 보강, MCP 연결 |
| 도구 미스매치 | 도구 인터페이스가 작업에 맞지 않음 | 커스텀 도구/래퍼 추가 |
| 과잉 제약 | 하네스가 모델의 능력을 억제 | 규칙/훅 제거 또는 완화 |
네 번째 유형 — 과잉 제약 — 이 가장 발견하기 어렵다. 에이전트가 실패하면 "규칙을 더 추가해야 하나?"라고 생각하게 되지, "규칙이 너무 많은 건 아닌가?"라고는 잘 생각하지 않는다.
4. A/B 테스트를 하라
같은 작업을 다른 하네스 설정으로 실행하고 비교하라. 과학적으로 접근하지 않으면 "이 설정이 좋은 것 같다"는 감에 의존하게 된다.
테스트할 변수들:
- 컨텍스트 양: CLAUDE.md의 규칙을 절반으로 줄였을 때 결과가 나빠지는가?
- 도구 수: MCP 서버를 5개에서 3개로 줄였을 때 오히려 개선되는가?
- 훅 수: PostToolUse 훅을 전부 끄고 커밋 시점에만 검증하면 어떤가?
- 모델 선택: 서브 에이전트에 Sonnet 대신 Haiku를 넣으면 비용 대비 품질이 어떤가?
LangChain이 Terminal Bench에서 한 것이 정확히 이것이다. LangSmith 트레이스에서 실패 원인을 수집하고, 각 하네스 변수를 체계적으로 조정했다.
5. 모델 업데이트 시 하네스를 재점검하라
새 모델 버전이 나올 때마다 기존 하네스가 여전히 최적인지 확인하라. Anthropic이 Opus 4.5에서 4.6으로 전환할 때 스프린트 구조를 제거한 것처럼, 모델이 강해지면 기존 보조 장치가 족쇄가 된다.
체크리스트:
- 강제 스프린트 분할이 여전히 필요한가?
- 컴팩션 주기를 늘릴 수 있는가?
- 서브 에이전트 없이 단일 에이전트로 처리 가능한 작업이 있는가?
- 평가 에이전트를 단일 패스로 전환할 수 있는가?
- 기존에 추가한 규칙 중 모델이 이미 학습해서 불필요해진 것이 있는가?
기본 설정 너머의 풍경
이 인사이트의 더 넓은 함의를 생각해보자.
하네스가 경쟁 우위가 되는 이유
모델은 상향 평준화되고 있다. Claude가 앞서면 GPT가 따라오고, GPT가 앞서면 Gemini가 따라온다. 같은 모델을 쓰는 두 팀의 생산성 차이는 어디서 오는가?
하네스에서 온다.
그리고 기본 하네스가 최적이 아니라면, 커스터마이징한 팀이 기본 설정을 쓰는 팀보다 체계적으로 앞서게 된다. 이것은 일시적 우위가 아니라, 축적되는 자산이다. 하네스 조정의 노하우, 프로젝트에 특화된 도구 래퍼, 팀에 맞춘 피드백 루프 — 이것들은 모델 업그레이드로 한 번에 평준화되지 않는다.
"도구를 쓰는 법"이 아니라 "도구를 만드는 법"
5편에서 "기술 스택 선택 기준이 'AI 친화성'으로 바뀔 것"이라고 했다. 한 단계 더 나아가면, 에이전트를 위한 도구를 설계하는 능력 자체가 핵심 역량이 된다.
좋은 도구 인터페이스 하나가 모델의 점수를 61포인트 올리는 세상이다(Hashline 실험). "Claude Code 사용법"을 아는 것보다, "Claude Code의 기본 도구를 내 프로젝트에 맞게 재설계하는 법"을 아는 것이 더 가치 있다.
역설의 해소
3편에서 제기한 역설 — 모델이 자신의 하네스에 과적합된다 — 은 사실 역설이 아니라 기회다.
기본 하네스가 최적이 아니라는 것은, 커스터마이징할 여지가 있다는 뜻이다. 그리고 그 여지는 모델이 발전할수록 커진다. 모델의 능력이 올라갈수록, 기본 하네스의 보수적인 제약이 더 많은 잠재력을 묻어버리기 때문이다.
마무리: 네 편의 하네스 이야기
3편에서 6편까지, 하네스 엔지니어링을 네 겹으로 다뤘다.
- 3편: 하네스란 무엇인가 — 개념과 구성 요소
- 4편: Anthropic은 어떻게 설계했나 — 아키텍처와 구현
- 5편: 내 프로젝트에 어떻게 적용하나 — 7단계 실전 가이드
- 6편: 기본 설정을 의심하라 — 과적합의 함의와 최적화
가장 중요한 한 줄을 고르라면 이것이다.
하네스를 만드는 것에서 멈추지 마라. 만든 하네스를 의심하라.
에이전트가 기대만큼 작동하지 않을 때, 규칙을 더 추가하기 전에 기존 규칙이 족쇄가 아닌지 먼저 확인하라. 모델은 당신이 생각하는 것보다 더 많은 것을 할 수 있다. 다만 하네스가 허락하지 않고 있을 뿐일 수 있다.
1편에서 이야기한 것처럼, 변화의 주기는 한 주로 줄었다. 3개월 전에 최적이었던 하네스가 지금은 최적이 아닐 수 있다. 정기적으로 의심하고, 실험하고, 줄여라.
모델은 아마 괜찮다. 하네스가 너무 많은 것이 문제일 수 있다.
댓글
댓글 쓰기