개요
LLM 코딩 성능에서 모델보다 하니스(harness)가 실질적 병목임을 보여주는 연구. Hashline이라는 새로운 코드 편집 포맷이 16개 모델 중 14개에서 기존 방식 대비 더 높은 정확도와 20~30% 토큰 절감을 달성. 단순한 포맷 변경만으로 모델 업그레이드 수준의 개선 가능.
- 출처: https://blog.can.ac/2026/02/12/the-harness-problem/
- 발표일: 2026-02-12
- 저자 프로젝트:
oh-my-pi(Pi 코딩 에이전트 포크, ~1,300 커밋) - 핵심 메시지: “모델은 해자(moat), 하니스는 다리(bridge)“
하니스(Harness)란?
LLM 모델 ←→ [하니스] ←→ 워크스페이스(코드)
↑
- 입력 토큰 관리
- 모델 출력 → 파일 변경 매핑
- 도구 호출 인터페이스 (read, edit, write 등)
- 컨텍스트 윈도우 활용 전략
대부분의 코딩 실패는 모델의 한계가 아니라 하니스의 구조적 한계에서 발생.
글의 framing 자체가 중요:
잘못된 질문:
"어떤 모델이 코딩을 가장 잘하나?"
더 중요한 질문:
"내 하니스가 모델 능력을 얼마나 가리고 있나?"즉, 하니스는 단순한 래퍼가 아니라:
- 첫 사용자 경험
- 입력 토큰 공급 방식
- 출력 → 워크스페이스 반영 인터페이스
를 모두 결정하는 실제 성능 병목 레이어입니다.
기존 편집 포맷의 한계
Codex apply_patch (OpenAI diff)
*** Update File: foo.py
@@ -10,3 +10,3 @@
- old line
+ new line- 문제: OpenAI 전용 포맷, 타 모델에서 실패율 높음
- 실패율 사례: Grok 4 → 50.7%, GLM-4.7 → 46.2%
- 핵심 문제: 모델이 기존 내용을 정확히 재현하며 엄격한 diff 문법까지 맞춰야 함
Claude Code str_replace
{
"old_string": "정확히 일치해야 하는 문자열",
"new_string": "교체할 문자열"
}- 문제: 공백·들여쓰기·줄바꿈 한 글자라도 다르면 실패
- 흔한 에러:
String to replace not found in file - GitHub에 다수 보고
- 본질: 기존 문자열을 완벽히 복사해야만 편집 가능
Cursor: 별도 70B 머지 모델
- 별도의 70B 모델로 변경사항 병합 처리
- 문제: 400줄 이하 파일은 전체 재작성(full rewrite)이 더 정확
- 머지 전용 모델 호출로 추가 비용·지연
왜 공통적으로 취약한가
기존 방식들은 대부분:
- 모델이 이미 본 내용을 다시 정확히 복사하거나
- 엄격한 diff/replace 문법에 맞춰 출력하거나
- 별도 병합 단계를 다시 통과해야 함
즉, 수정 대상을 가리키는 안정적 앵커(anchor) 가 없고, 모델의 기억력과 문자열 재현력에 과도하게 의존합니다.
Hashline 방식
원리
각 코드 줄에 2~3자 콘텐츠 해시를 부여해 모델이 수정 대상을 명확히 지정.
파일 표시:
1:a3| def hello():
2:f1| return "world"
3:b8|
4:c2| def main():
5:e7| print(hello())
모델 출력:
"replace line 2:f1 with: return 'hello world'"
핵심 가설:
모델이 의미 없는 짧은 해시 태그를 기억할 수 있다면, 적어도 무엇을 수정하려는지는 알고 있다고 볼 수 있다.
핵심 특징
- 파일 변경되어 해시 불일치 시 → 수정 거부 (손상 방지)
- 모델이 기존 내용을 재현할 필요 없음 → 공백/들여쓰기 오류 제거
- 줄 번호 + 해시 조합으로 모호성 제거
- diff 포맷 학습 부담 없이 자연스럽게 사용 가능
- 기존 내용을 길게 재현하지 않아도 돼서 공백/들여쓰기 오류 급감
벤치마크 결과
실험 설정
| 항목 | 내용 |
|---|---|
| 과제 수 | 180개 버그 수정 |
| 반복 | 3회 |
| 도구 | read, edit, write, etc. (4개) |
| 대상 모델 | 16개 |
| 테스트 코드 | React 코드베이스 무작위 파일 |
과제 생성 방식:
- React 코드베이스에서 무작위 파일 선택
- 기계적 변형을 버그로 주입
- operator swap
- boolean flip
- off-by-one
- optional chaining 제거
- identifier rename
- 이를 자연어 버그 설명으로 제시
- 에이전트 종료 후 포맷팅 포함 비교로 정답 채점
결과 요약
| 모델 | Patch | Hashline | 개선 |
|---|---|---|---|
| Grok Code Fast 1 | 6.7% | 68.3% | +61.6pp ⭐ |
| MiniMax | (낮음) | (2배+) | 두 배 이상 |
| Gemini 3 Flash | (기준) | +5.0pp | +5.0pp |
| Gemini (전체) | (기준) | 78.3% | +8% |
| Claude Sonnet 4.5 | (기준) | +1.6pp | +1.6pp |
핵심 발견
- Hashline은 14/16 모델에서 Patch보다 우수
- Patch는 거의 모든 모델에서 최악의 편집 포맷
- 평균 20~30% 토큰 절감
- 약한 모델일수록 개선 폭이 큼 (강한 모델은 어떤 포맷이든 잘함)
- Grok 4 Fast: 출력 토큰 61% 감소
- Gemini의 +8%는 일반 모델 업그레이드보다 큰 폭
요점:
모델이 과제를 이해 못 한 게 아니라
수정을 표현하는 방식에서 무너진 경우가 많다.편집 포맷 비교
| 포맷 | 방식 | 장점 | 단점 |
|---|---|---|---|
| Patch | diff 형식 | 표준적 | 모델 의존성 큼, 실패율 높음 |
| str_replace | 문자열 매칭 | 직관적 | 공백 한 글자도 매칭 실패 |
| Full Rewrite | 전체 재작성 | 안정적 | 토큰 낭비, 큰 파일 부적합 |
| Cursor Merge Model | 별도 모델 병합 | 큰 파일 가능 | 추가 비용·지연 |
| Hashline ⭐ | 줄별 해시 참조 | 정확·토큰 절감·안전 | 신규 포맷 (학습 필요) |
벤더 정책 & 오픈소스 생태계 이슈
연구 과정에서 드러난 폐쇄적 흐름:
Anthropic
- 오픈소스 코딩 에이전트 OpenCode의 Claude Code 접근 차단
- 명목상 이유: “비공개 API 역공학”
- 해석: “자체 하니스만 사용하라”는 신호
- Hashline으로 Gemini 3 Flash 성능 78.3% 달성한 벤치마크 직후 저자 계정 차단
- Gemini API 접근 막힘
저자의 비판
“하니스 최적화는 특정 모델이 아닌 모든 모델의 품질을 높이는 공공 연구다. 폐쇄적 접근은 생태계 발전을 저해한다.”
저자의 표현을 압축하면:
모델 = 해자
하니스 = 다리벤더는 자기 모델의 해자를 키우려 하지만, 오픈 하니스는 모든 모델을 더 잘 쓰게 만드는 공용 인프라라는 주장입니다.
시사점
1. 모델 선택보다 하니스 설계가 중요
- "어떤 모델이 코딩을 잘하나?"보다
- "내 하니스가 모델 능력을 제대로 끌어내고 있나?"
2. 약한 모델도 좋은 하니스로 강해질 수 있음
- Grok Code Fast 1: 6.7% → 68.3%
3. 토큰 비용 절감 효과
- 평균 20~30%, 일부 모델 60%+
4. 오픈소스 협업 필요성
- 단일 벤더의 폐쇄적 최적화보다
- 커뮤니티 공개 연구로 모든 모델 향상
더 직접적인 해석
- 모델 업그레이드 = 비싸고 벤더 종속적
- 하니스 업그레이드 = 즉시 적용 가능하고 모델 공통 혜택
즉, 실무에서는 종종 모델을 바꾸기 전에 하니스부터 바꾸는 편이 ROI가 더 높을 수 있습니다.
관련 연구
- JetBrains Diff-XYZ: 편집 포맷별 성능 차이 연구
- EDIT-Bench: 코드 편집 벤치마크
- oh-my-pi: 저자의 모델 독립 하니스 실험 환경