하루 만에 15개 LLM의 코딩 성능을 개선했다 — 바꾼 건 Harness뿐

Improving 15 LLMs at Coding in One Afternoon. Only the Harness Changed

Feb 12, 2026•kachapopopow•View Original

TL;DR Highlight

LLM 코딩 에이전트의 성능 병목은 모델이 아니라 edit tool 같은 harness(도구 인터페이스)에 있으며, edit 포맷 하나만 바꿔도 15개 모델에서 5~14점 향상과 토큰 20% 절감이 가능하다는 실증 분석.

Who Should Read

LLM 기반 코딩 에이전트를 만들거나, Claude Code·Cursor·Codex 같은 AI 코딩 도구의 한계를 느끼고 있는 개발자. 자체 에이전트 harness를 개선하고 싶은 사람.

Core Mechanics

현재 AI 코딩 도구 논의는 '어떤 모델이 최고냐'에 집중되지만, 실제 실패의 대부분은 모델이 아니라 harness(모델과 코드 사이의 인터페이스)에서 발생한다. 모델은 뭘 바꿔야 하는지 알지만, 그걸 표현하는 도구가 엉망이면 실패한다.
기존 edit 방식들은 각각 치명적 문제가 있다. Codex의 apply_patch는 OpenAI 전용 diff 포맷이라 다른 모델(Grok 4: 50.7%, GLM-4.7: 46.2%)에서 패치 실패율이 극심하고, Claude Code의 str_replace는 공백·들여쓰기까지 완벽히 재현해야 해서 'String to replace not found' 에러가 GitHub 이슈 메가스레드가 될 정도로 흔하다.
Cursor는 이 문제가 너무 어려워서 아예 별도의 70B 파인튜닝 모델을 edit 전용으로 훈련시켰다. 그런데도 400줄 이하 파일은 전체 재작성이 diff보다 낫다고 자사 블로그에서 인정했다.
Aider 벤치마크에서 edit 포맷만 바꿨더니 GPT-4 Turbo 성능이 26%→59%로 뛰었다. 반면 GPT-3.5는 같은 포맷에서 19%밖에 못 냈는데, 유효한 diff를 생성하는 능력 자체가 부족해서다. 포맷이 모델만큼 중요하다는 직접적 증거.
저자가 제안하는 'Hashline' 방식은 파일을 읽을 때 각 줄에 해시 태그를 붙여 반환하는 것이다. 모델이 수정할 줄을 해시로 안정적으로 식별할 수 있어서, 내용을 완벽히 재현할 필요 없이 '어떤 줄을 바꿀지' 정확히 지정할 수 있다.
이 해시 기반 edit 포맷 하나만 바꿨더니 15개 모델에서 5~14점 성능 향상, 출력 토큰 약 20% 절감이 나왔다. 모델 자체는 전혀 안 건드렸다.
JetBrains의 Diff-XYZ 벤치마크도 '모든 모델과 유스케이스에서 지배적인 단일 edit 포맷은 없다'고 확인했고, EDIT-Bench에서는 현실적 편집 태스크에서 pass@1 60% 넘는 모델이 단 하나뿐이었다.
저자는 oh-my-pi라는 오픈소스 코딩 에이전트를 1,300+ 커밋 유지하며, 모델을 파라미터로 두고 harness를 실험하는 테스트베드로 사용 중이다. Claude Code가 서브에이전트 출력에서 raw JSONL을 누출해 수십만 토큰을 낭비하는 문제도 직접 해결했다고 한다.

Evidence

한 댓글은 이 글의 성과가 과장됐다고 지적했다. 5% 개선은 저자가 직접 만든 find-and-replace 벤치마크 기준이지 상위 레벨 벤치마크가 아니며, 실제 일상 사용에서 editing이 전체 토큰의 1/3 미만이라 전체 효율 개선은 1% 미만일 수 있다고 계산했다. Google이 API 접근을 차단한 걸 '천재를 억누르려는 것'처럼 묘사하는 과대망상적 톤도 비판받았다.
Codex가 실제로 constrained sampling용 스키마를 사용한다는 반론이 있었다(GitHub 소스 링크 제공). 저자가 이를 모르고 벤치마크했기 때문에, apply_patch 테스트에서 constrained sampling을 활성화했어야 공정하다는 지적. 실제로 Codex 모델 두 개만 저자의 새 포맷에서 성능이 떨어졌다.
OpenRewrite의 Lossless Semantic Tree(LST) 개념을 언급하며, 텍스트가 아닌 AST/시맨틱 트리 위에서 모델이 직접 작업하면 포맷팅 같은 부수적 토큰 낭비를 없앨 수 있다는 의견이 있었다. Emacs에서 tree-sitter 기반으로 노드 해시를 사용한 edit 도구를 직접 구현해 성공했다는 경험담도 공유됐다.
Damerau-Levenshtein 거리(편집 거리)를 써서 유사도가 임계값 이상이면 edit을 통과시키는 fuzzy matching 방식을 쓰고 있다는 개발자가 있었다. 정확한 매칭을 요구하면 절대 안 되고, 에러 메시지에 'Content mismatch. Reread the file' 같은 구체적 해결 액션을 넣는 게 핵심이라고 했다. 4B 소형 모델에서도 작동한다고.
CORE 벤치마크에서 Opus 점수가 자체 harness에서 Claude Code로 바꿨을 때 거의 2배가 됐다는 사례가 공유되며, harness가 얼마나 중요한지 추가 증거로 제시됐다.

How to Apply

자체 코딩 에이전트를 만들고 있다면, 파일 읽기 결과에 줄별 해시를 붙여 반환하고 edit 시 해시로 대상 줄을 지정하는 방식을 도입해보라. 저자의 oh-my-pi(github.com/can1357/oh-my-pi)나 tilth(npx tilth → tilth install claude-code --edit)를 참고하면 바로 테스트 가능하다.
str_replace 기반 edit에서 실패율이 높다면, 정확한 문자열 매칭 대신 Damerau-Levenshtein 같은 fuzzy matching을 임계값과 함께 적용하고, 실패 시 'Content mismatch. Reread the file'처럼 모델이 자동 복구할 수 있는 구체적 에러 메시지를 반환하도록 수정하라.
Claude Code나 Cursor를 쓰면서 edit 실패가 잦다면, tilth를 설치해서(cargo install tilth 또는 npx tilth) 해시 기반 edit 모드를 활성화해볼 수 있다. tilth install claude-code --edit로 바로 적용 가능.
에이전트의 서브에이전트 출력이 raw 텍스트로 흘러 토큰을 낭비하고 있다면, 구조화된 데이터(JSON 등)로 반환하도록 변경하라. 모델 성능을 안 건드리고도 비용과 정확도를 동시에 개선할 수 있다.

Code Example

snippet

# tilth 설치 및 Claude Code에 해시 기반 edit 적용
cargo install tilth   # 또는 npx tilth
tilth install claude-code --edit

Terminology

HarnessLLM과 실제 코드 사이를 연결하는 도구 계층. 모델의 출력을 받아서 파일 편집, 명령 실행 등으로 변환하는 '중간 다리' 역할. Claude Code, Cursor 같은 코딩 에이전트의 뼈대.

str_replace파일에서 정확히 일치하는 문자열을 찾아 새 문자열로 바꾸는 편집 방식. 공백 하나라도 틀리면 실패해서 LLM이 자주 헤맨다.

apply_patchOpenAI Codex가 사용하는 diff 기반 편집 포맷. Unix patch와 비슷하지만 OpenAI 전용 규칙이 있어서 다른 모델은 이 포맷을 제대로 생성하지 못한다.

Constrained Sampling모델이 토큰을 생성할 때 특정 포맷(JSON, diff 등)에 맞는 토큰만 선택하도록 강제하는 기법. 출력이 항상 유효한 구조를 가지게 된다.

Hashline이 글에서 제안하는 방식. 파일의 각 줄에 해시 태그를 붙여서 모델이 수정 대상 줄을 해시로 정확히 지정할 수 있게 하는 것. 내용을 통째로 재현할 필요가 없어진다.

LST (Lossless Semantic Tree)소스 코드의 포맷팅, 타입, 의존성 정보까지 모두 보존한 트리 구조. 텍스트 기반보다 훨씬 정확한 코드 변환이 가능하다.