I Improved 15 LLMs at Coding in One Afternoon. Only the Harness Changed.
TL;DR
보안 연구자 Can Boluk는 LLM의 코드 편집 인터페이스(하네스)만 개선하여 16개 모델의 성능을 극적으로 향상시켰다. "Hashline"이라는 새로운 편집 도구는 각 코드 줄에 2~3자리 해시를 부여해 정확한 문자열 재현 없이 줄 참조를 가능하게 했다. 그 결과 Grok Code Fast 1 모델은 6.7%에서 68.3%로 성능이 급증했고, 평균 출력 토큰은 20% 감소했다. 모델 자체는 전혀 변경하지 않고 도구 인터페이스만 바꾼 성과다.
Key Takeaways
- 하네스(Harness) 설계가 모델 성능의 병목: 어떤 모델이 가장 우수한가보다 모델과 코드베이스 간 인터페이스가 실제 성능을 좌우한다. Claude나 OpenAI의 기본 도구는 특정 모델에 최적화되어 있어 다른 모델에선 실패율이 50% 이상 발생한다.
- 줄 해시 기반 참조의 혁신: Hashline은 정확한 문자열 매칭 대신 2~3자리 해시로 코드 줄을 식별해, 모델이 긴 문자열을 재현할 필요를 없앴다. 이는 토큰 효율성과 편집 정확도를 동시에 개선한다.
- 모델 비의존적 최적화: 동일한 하네스 개선이 GPT-4o, Claude Sonnet, Gemini 등 15개 이상의 모델에서 일관되게 성능 향상을 보였다. 이는 프롬프트 엔지니어링보다 도구 인터페이스 설계가 더 범용적인 개선 방법임을 시사한다.
- 실무 적용 가능성: 기존 str_replace나 apply_patch 도구의 한계(긴 인덴트 처리, 특수문자 이스케이핑 등)를 인지하고, 간단한 해시 기반 인터페이스로 대체하면 즉각적인 성능 개선이 가능하다.
- 토큰 경제성: 출력 토큰 20% 감소는 비용 절감뿐 아니라 응답 속도 개선으로 이어지며, 이는 프로덕션 환경에서 직접적인 사용자 경험 향상으로 연결된다.
상세 내용
하네스 문제: 간과된 병목 지점
AI 코딩 어시스턴트 논의는 대부분 "어떤 모델이 최고인가"에 집중한다. GPT-5.3 vs Opus, Gemini vs 이번 주 출시된 신모델. 하지만 Can Boluk는 이 프레임이 근본적으로 오해를 유발한다고 지적한다. 실제 병목은 훨씬 평범한 곳에 있다: 하네스(harness).
하네스는 단순한 UI가 아니다. 모든 입력 토큰의 소스이자, 모델의 출력과 실제 코드베이스 변경 사이의 인터페이스다. Claude Code는 여전히 서브에이전트 출력에서 원시 JSONL을 유출하며 수십만 토큰을 낭비한다. 도구 스키마, 에러 메시지, 상태 관리 등 "모델이 무엇을 바꿀지 안다"와 "문제가 실제로 해결된다" 사이의 모든 것이 하네스 영역이며, 실무에서 대부분의 실패가 발생하는 지점이다.
Boluk는 오픈소스 코딩 에이전트 Pi의 포크인 oh-my-pi를 유지보수하며 1,300개 이상의 커밋을 작성했다. 모델 비의존적 설계 덕분에 모델은 단순한 파라미터가 되고, 진짜 변수는 하네스가 된다. 바로 여기서 "상상 이상의 제어권"을 행사할 수 있다.
기존 편집 도구의 한계
현재 주류 편집 도구는 두 가지다:
1. OpenAI Codex의 apply_patch OpenAI 특화 diff 형식의 문자열 블롭을 입력받는다. 구조화된 스키마가 아닌 엄격한 규칙을 따르는 텍스트다. OpenAI 게이트웨이에서 토큰 선택 프로세스가 이 구조에 맞게 편향되어 있을 것으로 추정되지만, 다른 모델에 적용하면 패치 실패율이 급증한다. Grok 4는 50.7%, GLM-4.7은 46.2%의 실패율을 기록했다. 모델이 나쁜 게 아니라 "언어를 모르는" 것이다.
2. Claude Code의 str_replace 대부분의 도구가 채택한 방식이다. "이 정확한 문자열을 찾아서 저것으로 교체해라." 간단하지만 치명적인 문제들이 있다:
- 인덴테이션 지옥: 긴 인덴트를 포함한 문자열을 정확히 재현해야 함
- 특수문자 이스케이핑: JSON/XML 컨텍스트에서 따옴표, 개행 등을 올바르게 이스케이프해야 함
- 토큰 낭비: 변경하려는 줄 전체를 두 번(원본과 교체본) 재현해야 함
- 미묘한 불일치: 공백 하나 차이로 전체 편집이 실패
이런 도구들은 특정 모델(GPT 계열, Claude 계열)에 최적화되어 있어, 다른 모델은 구조적으로 불리한 위치에 놓인다.
Hashline: 해시 기반 줄 참조
Boluk의 해결책은 우아하게 단순하다. 파일의 각 줄에 2~3자리 해시를 부여한다:
1:a3|function hello() {
2:f1| return "world";
3:0e|}
모델이 편집을 요청할 때는 이렇게 말한다:
"2:f1 줄을 다음으로 교체: return 'universe';"
정확한 문자열 재현이 필요 없다. 해시가 줄을 고유하게 식별하므로, 모델은 짧은 참조만으로 위치를 지정할 수 있다. 이는:
- 토큰 효율성: 긴 문자열 재현 불필요
- 오류 감소: 인덴트나 이스케이핑 실수 원천 차단
- 범용성: 모델 특화 편향 없이 모든 LLM이 동일하게 사용 가능
벤치마크 결과: 극적인 성능 향상
결과는 놀라웠다:
- Grok Code Fast 1: 6.7% → 68.3% (10배 이상 향상)
- 전체 모델 평균 출력 토큰: 약 20% 감소
- 16개 모델 전반에 걸친 일관된 개선
중요한 점은 모델 가중치를 전혀 건드리지 않았다는 것이다. 파인튜닝도, 프롬프트 대수술도 없었다. 순전히 편집 도구 하나만 바꿨다.
이는 현재 LLM 코딩 성능 논의가 얼마나 잘못된 지점에 집중하고 있는지 보여준다. "어떤 모델이 최고인가"보다 "어떤 인터페이스로 모델을 활용하는가"가 실제 성능을 좌우한다.
실무적 시사점
1. 하네스 설계는 모델 선택만큼 중요하다 프로덕션 코딩 어시스턴트를 구축한다면, 모델 API 선택에 쏟는 시간만큼 도구 인터페이스 설계에 투자해야 한다. 기존 도구(str_replace, apply_patch)의 한계를 이해하고, 당신의 유즈케이스에 맞는 인터페이스를 설계하라.
2. 모델 비의존적 최적화의 가치 Hashline의 개선은 GPT, Claude, Gemini, Grok 등 다양한 모델군에 걸쳐 작동했다. 특정 모델에 종속된 최적화보다 범용적인 인터페이스 개선이 장기적으로 더 큰 가치를 제공한다. 모델은 계속 바뀌지만, 좋은 하네스는 남는다.
3. 토큰 경제성과 사용자 경험 20% 토큰 감소는 단순 비용 절감이 아니다. 응답 속도가 빨라지고, 컨텍스트 윈도우를 더 효율적으로 사용할 수 있으며, 사용자는 더 빠른 피드백을 받는다. 토큰 레벨의 최적화가 직접적인 UX 개선으로 이어진다.
4. 오픈소스와 실험의 중요성 Boluk의 발견은 상업적 제품(Claude Code, Cursor 등)이 놓친 지점이다. 모델 비의존적인 오픈소스 하네스에서 자유롭게 실험할 수 있었기에 가능했다. AI 인프라 스택에서 오픈소스 레이어의 가치를 재확인하는 사례다.
더 넓은 맥락: Harness Engineering의 부상
Hashline 실험은 새로운 엔지니어링 디시플린의 필요성을 보여준다: Harness Engineering. 프롬프트 엔지니어링이 모델에게 "무엇을 요청할지"를 다룬다면, 하네스 엔지니어링은 "어떻게 상호작용할지"를 설계한다.
좋은 하네스는:
- 모델의 출력을 실행 가능한 액션으로 신뢰성 있게 변환한다
- 토큰 효율성을 극대화한다
- 다양한 모델에 걸쳐 작동한다
- 에러 핸들링과 상태 관리를 우아하게 처리한다
이는 단순한 UI/UX 문제가 아니다. 분산 시스템 설계, API 설계, 컴파일러 인터페이스 설계와 맥을 같이하는 시스템 엔지니어링 문제다.
결론: 도구가 모델만큼 중요하다
Can Boluk의 실험은 명확한 메시지를 전달한다: 당신의 AI 시스템 성능은 가장 약한 고리, 즉 하네스에 의해 결정된다. 최신 최고 모델을 사용하더라도, 형편없는 편집 인터페이스는 그 잠재력을 절반도 끌어내지 못한다.
실무 AI 엔지니어로서 우리는 모델 선택뿐 아니라 인터페이스 설계에 진지하게 투자해야 한다. Hashline은 하나의 예시일 뿐이다. 당신의 도메인, 당신의 워크플로우에는 또 다른 "해시라인"이 기다리고 있을 수 있다. 모델 벤치마크를 쫓는 대신, 하네스를 해킹하라.