기본 설정을 의심하라 — AI 코딩이 느릴 때, 모델보다 먼저 버려야 할 것들

이 시리즈를 쓰면서 제일 이상했던 숫자가 하나 있었다.

 

Terminal Bench 2.0에서 Claude Opus 4.6이 Claude Code 안에서는 33위였는데, 다른 하네스에 올리면 5위권까지 올라간다는 얘기. 처음 봤을 때는 그냥 흥미로운 관찰 정도로 넘겼다. “벤치마크마다 다를 수도 있지”, “환경 차이겠지” 하고 지나가기 쉬운 숫자였다.

 

근데 이걸 계속 붙들고 있다 보니, 오히려 이 숫자가 시리즈 전체에서 제일 실전적인 힌트였다는 생각이 들었다.

 

보통 우리는 이렇게 생각한다.
좋은 모델이 있고, 좋은 하네스가 있고, 둘을 합치면 더 좋은 결과가 나온다고.

 

그런데 실제로는 꼭 그렇지 않다.

 

가끔은 모델이 문제가 아니라,
그 모델이 너무 익숙해진 기본 설정이 문제다.

 

심지어 더 노골적으로 말하면,
당신이 “안전하고 검증된 기본값”이라고 믿는 그 하네스가
지금은 에이전트 발목을 잡고 있을 수도 있다.

 

이건 꽤 불편한 이야기다.
왜냐하면 하네스를 만들기 시작한 사람은 대개 거기에 애착이 생기기 때문이다. 규칙을 추가했고, 훅을 달았고, 도구를 연결했고, 세션 관리도 넣었고, 서브 에이전트도 나눴다. 그렇게 공들여 만든 구조를 다시 의심하는 건 생각보다 어렵다.

 

근데 정말 봐야 할 순간이 온다.

 

“혹시 지금 느린 이유가, 하네스를 너무 잘 만들어놔서 그런 건 아닐까?”

 

모델은 종종 “작업”보다 “환경”에 적응한다

 

프론티어 코딩 모델은 그냥 코드만 많이 본 채로 끝나지 않는다.
자기들이 실제로 돌아갈 환경 안에서 후훈련된다.

 

Claude 계열은 Claude Code 류의 흐름에 익숙해지고, Codex 계열은 Codex 쪽 도구 사용 패턴에 익숙해진다. 이 말은 곧, 모델이 “문제를 푸는 법”만 배우는 게 아니라 “어떤 도구를 어떤 순서로 호출하고, 어떤 형식의 오류를 받고, 어떤 편집 인터페이스 안에서 일하는지”까지 같이 학습한다는 뜻이다.

 

여기서 문제가 생긴다.

 

모델이 파일을 수정하는 일반 능력을 배운 게 아니라,
특정 파일 편집 도구와 대화하는 방식을 배워버릴 수 있다.

 

모델이 검색을 잘하는 게 아니라,
자기 하네스 안의 검색 흐름에 익숙해진 것일 수도 있다.

 

이건 머신러닝에서 말하는 과적합이랑 되게 비슷하다. 훈련 데이터에는 너무 잘 맞는데, 조금만 환경이 달라지면 이상하게 굼떠지거나 엉뚱한 선택을 한다. 모델과 하네스 관계도 비슷한 식으로 꼬일 수 있다. 모델이 기본 하네스의 습관, 말투, 인터페이스, 순서, 에러 형식에 너무 익숙해지면, 다른 구성에서 보여줄 수 있는 잠재력이 묻힌다.

 

쉽게 말해,
모델이 똑똑하지 않은 게 아니라
너무 특정한 운전석에만 익숙해진 거다.

 

Codex가 파일을 편집한 게 아니라 apply_patch를 호출한 것이라면

 

이런 얘기가 공허하게 들릴 수도 있다.
근데 실제 사례를 보면 감이 확 온다.

 

Codex 계열 모델을 다른 하네스에 올렸을 때, 별도의 apply_patch 도구를 굳이 다시 붙여줘야 했다는 얘기가 있다. 이게 왜 중요하냐면, 모델이 “파일 수정”이라는 추상 능력을 익힌 게 아니라 “apply_patch라는 특정 인터페이스를 쓰는 습관”에 맞춰져 있었다는 뜻이기 때문이다.

 

이 차이는 꽤 크다.

 

우리는 흔히 모델이 본질적인 능력을 가진다고 생각한다.
문서를 읽고, 구조를 이해하고, 파일을 편집하고, 테스트를 돌리는 능력 말이다.

 

그런데 실제로는 그 능력이 특정 인터페이스를 통해서만 잘 발휘되도록 길들여졌을 수 있다. 그러면 인터페이스가 바뀌는 순간, 모델은 갑자기 서툴러 보인다. 실력이 떨어진 게 아니라 손에 익은 공구가 사라진 셈이다.

 

이걸 보고 나면 “기본 도구를 그대로 쓰는 게 제일 안전하다”는 말도 다시 보이기 시작한다.
안전할 수는 있다.
근데 최적일지는 모른다.

 

인터페이스 하나 바꿨는데 성능이 10배 가까이 튄다면

 

이 시리즈 앞쪽에서 잠깐 언급했던 Hashline 실험도 사실 같은 이야기를 한다.

 

각 줄에 해시를 붙여서 모델이 줄 번호 대신 안정적으로 위치를 가리킬 수 있게 했더니, 어떤 모델은 성능이 6.7%에서 68.3%로 뛰었다. 이건 모델이 갑자기 천재가 됐다는 얘기가 아니다. 그냥 기존 파일 편집 인터페이스가 그 모델한테 너무 불리했던 거다. 손에 안 맞는 장갑을 끼고 일하다가, 장갑 하나 바꿨더니 갑자기 제대로 움직이기 시작한 셈이다.

 

이쯤 되면 질문이 바뀐다.

 

“이 모델이 좋은가?”가 아니라
“이 모델이 이 인터페이스에서 제 실력을 내고 있는가?”를 봐야 한다.

 

여기서 많은 팀이 한 번 놓친다.
성능이 안 나오면 모델을 바꿀 생각부터 한다.
더 비싼 모델, 더 최신 모델, 더 긴 컨텍스트 모델.

 

근데 가끔 진짜 답은 훨씬 싸다.

 

파일 편집 방식 하나 바꾸기.
검색 명령 하나 감싸기.
검증 타이밍 하나 늦추기.
쓸데없는 훅 하나 빼기.

 

그 정도로도 숨 막히던 에이전트가 갑자기 술술 움직일 때가 있다.

 

“33위”가 진짜 말하는 것

 

Claude Opus 4.6이 Claude Code 안에서 33위였다는 숫자를 그냥 “벤치마크 특이점” 정도로 치부하면, 여기서 제일 중요한 메시지를 놓친다.

 

그 숫자가 암시하는 건,
Opus 4.6이 별로라는 게 아니다.

 

오히려 반대다.
기본 하네스가 이 모델의 잠재력을 다 끌어내지 못하고 있을 가능성이다.

 

왜 이런 일이 생길까.
설명 가능한 가설은 몇 개 있다.

 

가장 먼저 떠오르는 건 하네스가 이전 세대 모델에 맞춰져 남아 있는 경우다. 예를 들어 예전 모델이 장기 작업에서 자주 흔들렸기 때문에 스프린트 분할을 넣고, 체크포인트를 강하게 걸고, 자주 요약하고, 자주 끊어주는 구조를 만들었다고 치자. 그 당시에는 그게 효과적이었을 수 있다. 그런데 모델이 좋아진 뒤에도 그 구조가 그대로 남아 있으면 어떻게 되나. 원래는 도와주려고 넣었던 장치가 이제는 오히려 브레이크가 된다.

 

Anthropic 쪽 자료를 읽을 때 재미있었던 부분도 바로 이거였다.
모델이 좋아지니까 이전에 필요했던 보조 장치를 줄일 수 있었다는 점. 스프린트 분해를 없애고, 평가도 단일 패스로 줄이고, 복잡도는 낮췄는데 성능은 유지됐다. 이건 하네스가 늘 정답이 아니라는 뜻이다. 정확히 말하면, 하네스는 특정 모델의 약점에 붙여놓은 임시 외골격일 수 있다. 모델이 바뀌면 외골격도 다시 봐야 한다.

 

두 번째는 기본 도구가 너무 범용적이라는 문제다.
Claude Code든 뭐든 기본 도구는 대체로 어디서나 돌아가게 설계된다. 그건 장점이다. 하지만 “당신의 저장소”에 딱 맞게 설계된 건 아니다. 범용성은 넓지만, 프로젝트 특화 작업에서는 늘 약간 둔하다. 검색도 그렇고, 테스트 실행도 그렇고, 빌드 확인도 그렇다. 다 되긴 되는데, 빠르고 정확하게 되느냐는 또 다른 문제다.

 

세 번째는 컨텍스트 자체가 너무 일반적이라는 점이다. 기본 하네스는 전역 규칙 파일을 읽고, 도구 설명을 넣고, 이전 대화를 유지한다. 근데 지금 당신 작업에 정말 필요한 게 그건 아닐 수 있다. 지금 필요한 건 특정 디렉토리의 의존 방향일 수도 있고, 영향받는 테스트만 빠르게 돌리는 명령일 수도 있고, 최근에 바뀐 API 응답 형식일 수도 있다. 기본 하네스는 그걸 모른다. 모르는 게 당연하다. 그래서 결국 팀이 따로 손을 대야 한다.

 

하네스를 더하는 일보다, 빼는 일이 더 어려울 때가 있다

 

실무에서 진짜 어려운 건 규칙을 추가하는 일이 아니다.
규칙을 없애는 일이다.

 

에이전트가 한번 망가진 걸 보면, 사람은 자연스럽게 가드레일을 더 친다. 이 규칙도 넣고, 저 훅도 추가하고, 여긴 승인도 걸고, 저긴 서브 에이전트도 붙인다. 그 순간에는 대개 합리적이다. 문제는 이런 구조가 쌓이기만 하고 잘 안 사라진다는 점이다.

 

그러다 어느 순간부터 에이전트가 묘하게 느려진다.

 

간단한 수정인데도 훅이 너무 많이 돈다.
작은 변경인데도 전체 타입 체크가 계속 돈다.
서브 에이전트 호출 오버헤드가 실제 조사 시간보다 길어진다.
세션이 너무 자주 끊겨서 맥락이 오히려 잘린다.
쓸모없는 규칙까지 다 읽느라 정작 중요한 판단이 흐려진다.

 

여기서 자주 하는 실수가 있다.
결과가 안 좋으면 “규칙이 부족한가?”라고 생각한다.
근데 실제 원인이 “규칙이 너무 많은가?”인 경우도 꽤 있다.

 

이건 발견하기가 어렵다.
왜냐하면 과잉 제약은 겉으로 보면 안전장치처럼 보이기 때문이다.

 

브레이크를 밟고 있는데 차가 안 나간다고 해서,
보통은 엔진 문제를 먼저 의심하지 브레이크를 의심하진 않는다.
하네스도 비슷하다.

 

기본 도구는 그대로 두지 말고, 프로젝트용 손잡이를 만들어야 한다

 

그래서 실전에서는 기본 도구를 무조건 그대로 믿지 않는 편이 낫다.
내 프로젝트에서 자주 하는 작업에 맞는 래퍼를 하나씩 만드는 게 생각보다 효과가 크다.

 

예를 들어 컴포넌트 찾을 때마다 일반 검색 도구를 쓰는 대신, 프로젝트 구조에 맞춘 find-component 스크립트를 만든다. 테스트도 무조건 전체 테스트를 돌리지 말고 변경 파일 기준으로 영향 범위만 보는 test:affected 같은 걸 둔다. 빌드 확인도 무거운 전체 빌드 대신 우선 타입 체크만 빠르게 보는 식으로 나눌 수 있다.

 

이게 왜 좋냐면, 모델이 애매한 범용 도구를 가지고 헤매는 시간을 줄여준다. 작업의 손잡이가 분명해진다. “어디서 찾아야 하지?” 대신 “이 명령 쓰면 된다”가 된다. LangChain이 벤치마크에서 큰 폭으로 점프한 배경에도 이런 종류의 하네스 조정이 있었다는 얘기가 나오는 이유가 여기 있다. 모델을 갈아끼운 게 아니라, 실패 패턴을 보고 인터페이스를 손봤다.

 

이건 사소해 보이는데 효과는 꽤 거칠다.
좋은 래퍼 하나가 프롬프트 열 줄보다 세다.

 

보호 장치도 정기적으로 뜯어봐야 한다

 

5편에서는 점진적 작업 강제, 세션 분리, 체크포인팅 같은 걸 꽤 강하게 추천했다. 그건 여전히 맞다. 특히 처음 붙일 때는 그렇다. 근데 거기서 멈추면 안 된다. 모델이 좋아지고, 저장소 규칙이 안정되고, 도구 인터페이스가 손에 맞기 시작하면 예전에 필요했던 보호 장치가 이제는 오버헤드가 되기도 한다.

 

예를 들면 이런 질문을 정기적으로 던져볼 수 있다.

 

정말 아직도 강제 스프린트 분할이 필요한가.
모든 도구 호출 뒤 타입 체크를 돌려야 하나.
서브 에이전트를 꼭 거쳐야만 하는 작업인가.
이 검증을 커밋 시점으로 미뤄도 되지 않나.
3개월 전에 넣은 규칙이 지금도 자주 잡히는가.

 

이런 질문이 없으면 하네스는 점점 두꺼워진다.
그리고 두꺼워질수록, 원래 막으려던 실패보다
새로운 느려짐을 더 많이 만든다.

 

실패도 종류를 나눠서 봐야 한다

 

에이전트가 못했다고 해서 다 같은 실패는 아니다.
이걸 한 덩어리로 보면 처방이 계속 어긋난다.

 

어떤 실패는 정말 모델 능력 한계다.
그건 더 강한 모델을 쓰거나 작업을 더 잘게 나눠야 한다.

 

어떤 실패는 컨텍스트 부족이다.
필요한 규칙이나 시스템 정보가 없으니 틀리는 거다. 그건 문서 보강이나 연결 확장이 맞다.

 

어떤 실패는 도구 미스매치다.
도구가 있긴 한데 손에 안 맞는다. 이건 래퍼나 커스텀 인터페이스가 답이다.

 

그리고 제일 찾기 어려운 실패가 하나 있다.
과잉 제약이다.

 

모델은 할 수 있는데,
하네스가 허락을 너무 늦게 하거나,
중간에 너무 많이 끊거나,
쓸데없는 검사로 기동력을 죽이고 있는 경우다.

 

이 실패는 겉으로 보면 모델이 답답해 보인다.
그래서 자꾸 모델을 탓하게 된다.
근데 실제로는 모델이 아니라 하네스가 너무 무거운 거다.

 

그래서 한 번쯤은 A/B 테스트를 해보는 편이 낫다.
규칙 절반으로 줄이기, MCP 몇 개 빼기, 훅 일부 끄기, 서브 에이전트 빼기. 감으로 “이게 더 안전해 보여”라고 가는 것보다 같은 작업을 다른 설정으로 돌려보는 게 훨씬 빨리 답을 준다. 생각보다 “덜 넣었더니 더 잘됨”이 자주 나온다.

 

모델이 업데이트되면 하네스도 같이 업데이트돼야 한다

 

이건 사실 제일 중요한 운영 원칙일 수 있다.

 

새 모델이 나오면 보통 사람들은 프롬프트를 조금 수정하고 끝낸다.
근데 더 봐야 하는 건 하네스다.

 

예전 모델이 자주 실수해서 넣었던 강한 보조 장치가, 지금 모델에서는 이미 불필요할 수 있다. 심지어 방해가 될 수도 있다. Anthropic이 모델 버전이 바뀌면서 스프린트 구조를 줄였던 것처럼, 팀 하네스도 모델 업데이트마다 다시 점검해야 한다.

 

강제 분할이 여전히 필요한지,
컴팩션을 덜 자주 해도 되는지,
평가 루프를 단순화할 수 있는지,
규칙 몇 개를 없애도 성능이 유지되는지.

 

이걸 안 하면 어떤 일이 생기냐면,
모델은 진화하는데 하네스는 과거에 묶인다.

 

결국 더 강한 모델 위에
더 낡은 족쇄를 채우는 꼴이 된다.

 

경쟁 우위는 모델보다 하네스 조정에서 오래 남는다

 

모델은 점점 비슷해진다.
누가 잠깐 앞서면 몇 달 안에 다른 쪽이 따라온다.
성능 격차는 있더라도, 그 우위가 영원하지는 않다.

 

근데 하네스는 다르다.
그건 팀이 자기 저장소에 맞춰 만든 축적물이다.

 

프로젝트 구조에 맞춘 검색 명령,
테스트 범위를 줄이는 래퍼,
실패 패턴에 맞춘 피드백 루프,
보안 경계,
과한 규칙을 걷어낸 경험.

 

이건 모델 버전 올린다고 한 번에 따라잡히지 않는다.
그래서 같은 모델을 써도 팀마다 생산성이 크게 갈린다.

 

재미있는 건, 이쯤 되면 중요한 역량도 조금 바뀐다는 점이다.
예전에는 “이 도구를 잘 쓰는 법”이 중요했다면,
이제는 “이 도구를 우리 일에 맞게 다시 만드는 법”이 더 중요해진다.

 

Claude Code 사용법보다
Claude Code 위에 우리 프로젝트용 손잡이를 설계하는 능력 쪽이 더 오래간다.

 

결국 이 역설은 기회다

 

3편에서 잠깐 언급했던 역설,
즉 모델이 자기 하네스에 과적합된다는 얘기는
듣기에는 문제처럼 보인다.

 

근데 실무적으로 보면 오히려 기회다.

 

기본 하네스가 최적이 아니라는 건,
건드릴 여지가 있다는 뜻이다.

 

그리고 모델이 좋아질수록 그 여지는 더 커진다.
모델이 원래 할 수 있는 일이 많아질수록,
기본 하네스의 보수적인 안전장치가 더 큰 병목이 되기 쉽기 때문이다.

 

그러니까 하네스 엔지니어링의 마지막 단계는
하네스를 만드는 일이 아니라
하네스를 의심하는 일이다.

 

규칙을 더 넣기 전에,
지금 있는 규칙이 이미 너무 많지 않은지 보는 것.
도구를 더 연결하기 전에,
지금 연결된 도구가 실제로 일을 빠르게 하는지 보는 것.
서브 에이전트를 더 나누기 전에,
그 분리가 정말 도움이 되는지 보는 것.

 

이걸 안 하면, 잘 만든 하네스가 오히려 가장 비싼 병목이 된다.

 

이 시리즈를 여기까지 끌고 오면서 남은 한 줄이 있다면 아마 이거다.

 

하네스를 만드는 것에서 멈추지 마라.
잘 돌아가는 것처럼 보여도, 그 하네스를 계속 의심하라.

 

에이전트가 기대만큼 작동하지 않을 때
무조건 규칙을 더 추가하는 쪽으로 가지 말고,
먼저 지금의 기본 설정이 모델 능력을 눌러버리고 있지는 않은지 봐야 한다.

 

모델은 생각보다 괜찮을 수 있다.
정말 문제인 건, 당신이 너무 성실하게 쌓아올린 하네스일지도 모른다.