# 15개 LLM의 코딩 성능을 개선했어요, 바뀐 것은 하니스뿐 > Clean Markdown view of GeekNews topic #26648. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26648](https://news.hada.io/topic?id=26648) - GeekNews Markdown: [https://news.hada.io/topic/26648.md](https://news.hada.io/topic/26648.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-13T09:51:31+09:00 - Updated: 2026-02-13T09:51:31+09:00 - Original source: [blog.can.ac](http://blog.can.ac/2026/02/12/the-harness-problem/) - Points: 35 - Comments: 3 ## Summary **코드 수정 성능의 핵심은 모델 자체보다 ‘하니스(harness)’에 있을 수 있음을 보여줍니다.** 16개 LLM을 동일 조건에서 테스트한 결과, 코드 수정 포맷을 **Hashline**으로 바꾸는 것만으로 평균 20~30%의 토큰을 절감했고, 대부분의 모델에서 정확도 개선이 관찰되었습니다. 특히 Grok Code Fast 1은 성공률이 6.7%에서 68.3%로 상승해, 단순한 하니스 교체만으로도 모델 교체에 준하는 수준의 효과를 보였습니다. 이번 연구는 코드 편집의 병목이 모델 내부 역량이 아니라 **입력·출력 인터페이스 설계에 있을 가능성**을 시사하며, 오픈소스 협업과 실험 문화의 중요성을 다시 부각합니다. ## Topic Body - 여러 LLM을 동일한 조건에서 테스트한 결과, **코드 수정 도구**만 바꿔도 성능이 크게 향상됨 - 기존의 **Patch·Replace 방식** 대신 각 코드 줄에 **해시 태그를 부여하는 ‘Hashline’ 포맷**을 적용해 수정 정확도를 높임 - Hashline은 16개 모델 중 14개에서 기존 방식보다 높은 정확도를 보였으며, **평균 20~30% 토큰 절감** 효과도 확인됨 - 특히 **Grok Code Fast 1** 모델은 성공률이 6.7%에서 68.3%로 급상승, 단순한 하니스 변경만으로 10배 개선됨 - 연구는 모델 자체보다 **‘하니스(harness)’가 실제 성능의 병목**임을 보여주며, 오픈소스 생태계의 협업 필요성을 강조함 --- ### 코드 편집 벤치마크 개요 - 실험은 **Patch, Replace, Hashline** 세 가지 편집 포맷을 비교하는 형태로 진행됨 - 16개 모델을 대상으로 동일한 코드 수정 과제를 수행 - 각 모델은 React 코드베이스에서 무작위로 선택된 파일의 버그를 수정하는 방식으로 테스트됨 - **Hashline 포맷**은 14개 모델에서 Patch보다 우수한 결과를 보였으며, 평균적으로 20~30%의 토큰을 절약함 - 가장 큰 개선은 **Grok Code Fast 1** 모델로, 성공률이 6.7%에서 68.3%로 상승 (+61.6pp) - Gemini 3 Flash는 5.0pp, Claude Sonnet 4.5는 1.6pp 향상 ### 하니스(harness) 문제 - 현재 논의는 주로 “어떤 모델이 코딩을 가장 잘하나”에 집중되어 있으나, 실제 병목은 **모델이 아닌 하니스**임 - 하니스는 입력 토큰을 관리하고, 모델 출력과 워크스페이스 변경을 연결하는 핵심 인터페이스 - 대부분의 실패는 모델이 아니라 하니스의 구조적 한계에서 발생 - 작성자는 오픈소스 코딩 에이전트 **Pi**를 포크한 개인 프로젝트 **oh-my-pi**를 통해 약 1,300개의 커밋을 수행하며 개선을 시도함 - 이 환경은 모델에 독립적이며, 하니스만 변수로 두고 실험 가능 ### 기존 편집 도구의 한계 - **Codex의 `apply_patch`** 방식은 OpenAI 전용 diff 포맷을 사용해 다른 모델에서는 실패율이 높음 - 예: Grok 4의 패치 실패율 50.7%, GLM-4.7은 46.2% - **Claude Code의 `str_replace`** 방식은 문자열을 완벽히 일치시켜야 하므로 공백이나 들여쓰기 차이로 오류 발생 - “String to replace not found in file” 오류가 GitHub에서 다수 보고됨 - **Cursor**는 별도의 70B 모델을 훈련시켜 병합을 처리하지만, 400줄 이하 파일에서는 전체 재작성(full rewrite)이 더 나은 결과를 냄 - JetBrains의 **Diff-XYZ**, **EDIT-Bench** 연구에서도 편집 포맷에 따라 성능이 크게 달라짐이 확인됨 ### Hashline 방식의 원리 - 각 코드 줄에 **2~3자 길이의 콘텐츠 해시**를 부여해 모델이 수정 대상을 명확히 지정할 수 있게 함 - 예시: `22:f1| return "world";` - 모델은 “replace line 2:f1”처럼 해시를 기준으로 수정 요청 - 파일이 변경되어 해시가 불일치하면 수정이 거부되어 손상 방지 - 이 방식은 모델이 기존 내용을 재현할 필요가 없어, 공백·들여쓰기 오류를 줄이고 안정적인 수정 가능 ### 벤치마크 결과 - 테스트는 180개의 버그 수정 과제, 3회 반복, 4개 도구(read, edit, write, etc.)로 구성 - 결과적으로 **Patch 포맷은 거의 모든 모델에서 최악**, **Hashline은 Replace와 동등하거나 우수** - 약한 모델일수록 개선 폭이 큼 - Grok 4 Fast는 출력 토큰이 61% 감소, MiniMax는 두 배 이상 향상 - **Gemini의 성공률 +8%** 는 일반적인 모델 업그레이드보다 큰 개선폭으로, 추가 학습 없이 달성됨 ### 벤더 정책과 오픈소스 생태계 - **Anthropic**은 오픈소스 코딩 에이전트 **OpenCode**의 Claude Code 접근을 차단함 - 이유는 “비공개 API 역공학”이지만, 결과적으로 “자체 하니스만 사용하라”는 신호로 해석됨 - **Google**은 작성자의 계정을 차단해 Gemini 접근을 막음 - Hashline 적용으로 Gemini 3 Flash 성능이 78.3%로 향상된 벤치마크 직후 발생 - 작성자는 이러한 조치가 **모델 개선 기회를 차단하는 역행적 행위**라고 지적 - 하니스 최적화는 특정 모델이 아닌 모든 모델의 품질을 높이는 공공 연구에 해당 - “모델은 해자, 하니스는 다리”라는 표현으로, 폐쇄적 접근이 생태계 발전을 저해한다고 강조 ### 결론 - 하니스 문제는 **측정 가능하고 실제 성능에 직접적 영향을 주는 요인**으로 확인됨 - 단순한 포맷 변경만으로도 모델 업그레이드에 준하는 개선 효과를 얻을 수 있음 - 향후 발전 방향은 **단일 기업의 폐쇄적 개선**이 아닌, **커뮤니티 기반의 공개 협력**이어야 함 - 모든 코드, 벤치마크, 실행 결과는 GitHub 저장소 **oh-my-pi**에서 공개됨 ## Comments ### Comment 51182 - Author: github88 - Created: 2026-02-15T06:56:15+09:00 - Points: 2 모델이 이상한데 왜 또 다시 프롬프트 엔지니어링.. ### Comment 54533 - Author: cosine20 - Created: 2026-04-03T10:27:17+09:00 - Points: 1 - Parent comment: 51182 - Depth: 1 하네스랑 프롬프트 엔지니어링은 전혀 다른 얘기입니다. ### Comment 51097 - Author: neo - Created: 2026-02-13T09:51:31+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46988596) - 이 글을 정말 흥미롭게 읽었음. 저자는 **정확히 핵심을 짚었다**고 생각함 지금 존재하는 모델조차도, 우리가 **에이전트 하니스(harness)** 를 어떻게 설계하느냐에 따라 훨씬 더 효율적으로 만들 수 있는 여지가 많음. 나는 “AI”를 단순히 LLM 자체로 보지 않고, LLM과 하니스가 피드백 루프로 연결된 **사이버네틱 시스템 전체**로 보는 게 맞다고 생각함. 모델과 하니스는 서로를 강화하며 함께 진화하는 구조이므로, 둘 다 동등하게 중요함. 이런 관점은 단순한 성능 향상뿐 아니라, 생성형 AI를 **신경-기호적(neurosymbolic)** 프로젝트로 재해석하게 해줌 - 내 생각엔 지금도 **GPT-4**로 충분히 많은 걸 만들 수 있음. 나는 실제로 2023년 버전의 GPT-4로 **코딩 에이전트**를 만들었음. 오래된 모델로 작업하면 단순함을 유지해야 해서 오히려 문제를 다르게 보게 됨. 예를 들어, Python에서는 `grep -r def .` 같은 단순한 **semantic compression**이 필수적임. Claude Code 같은 도구에 이런 간단한 훅을 추가하면 토큰 낭비 없이 코드 구조를 바로 파악할 수 있음 - 나는 **Peen**이라는 CLI를 만들고 있음. 로컬 Ollama 모델이 툴을 효율적으로 호출하도록 돕는 도구임. 단 몇 시간의 프롬프트 튜닝과 응답 처리 코드만으로도 작은 로컬 모델의 출력 품질이 놀랍게 개선됨 [GitHub 링크](https://github.com/codazoda/peen) - Claude Code와 OpenAI Codex의 하니스도 스스로 발전하고 있음. OpenAI는 GPT-5.3-Codex 초기 버전으로 자체 훈련 프로세스를 디버깅하고 배포를 관리했음. Claude Code는 하루에 20개 넘는 PR을 전부 **자체 코드 생성으로** 제출함 - 참고로, 내 글투가 “It’s not just X, it’s Y” 같은 구조를 자주 쓰지만, 이건 피곤해서 그런 거지 LLM이 쓴 게 아님 - SWE-bench 문서를 보면, 거의 임의적인 **컨텍스트 엔지니어링**을 사용함. 실제로 어떤 모델이 좋은 컨텍스트 엔지니어링에 민감한지조차 잘 모름. 하지만 분명히 **낮게 달린 열매(low hanging fruit)** 가 많다는 점에는 동의함 - 이 기술은 흥미롭지만 **과대평가된 느낌**이 있음. 작성자는 자신이 만든 단순한 find/replace 벤치마크에서 5% 개선을 보고, 마치 전체 성능이 14포인트 오른 것처럼 말함. 실제로는 전체 토큰 효율성에서 1% 미만의 개선일 가능성이 높음. 게다가 글의 **과장된 어조**와 ChatGPT 특유의 문체가 신뢰를 떨어뜨림 - “replace line 2:f1…” 같은 포맷이라면 실제 효율은 20%보다 훨씬 높을 수도 있을 것 같음 - 벤치마크에서는 토큰 사용량이 25~50% 줄었다고 하지만, 실제 사용 환경에서 그만큼 효과가 있을지는 의문임 - 이 글은 하니스 수준에서 얼마나 **개선 여지**가 큰지를 잘 보여줌. 에이전트들은 편집, 샌드박스, 툴 호출 간 데이터 전달 등에서 많은 토큰을 낭비함. **콘텐츠 기반 주소 지정 + 라인 넘버링**의 조합이 실용적이고 아름다움 - 가장 큰 낭비는 MCP를 모든 곳에 사용하는 것일 수 있음. 초기 개발은 쉬워지지만, 불필요하게 거대한 모델을 호출하게 되어 비효율적임 - ClaudeCode Superpowers 플러그인을 써봤는데, 기능은 좋지만 **비용이 많이 듦**. CC에서는 `/cost` 명령으로 세션당 비용을 확인할 수 있는데, 이런 지표로 플러그인 효율을 평가하는 게 좋음 - 반대로, 더 많은 토큰을 써서 복잡한 문제를 **작은 하위 문제로 분할**해 해결하는 접근도 가능함 - 하니스의 중요성은 대부분이 생각하는 것보다 훨씬 큼. 예를 들어, Opus의 CORE 벤치마크 점수가 자체 하니스에서 **Claude Code로 바꾸자 거의 두 배**가 되었음 [관련 링크](https://x.com/sayashk/status/1996334941832089732) - Pi 터미널 에이전트 제작자 Mario의 [블로그 글](https://mariozechner.at/posts/2025-11-30-pi-coding-agent/)에서도 TerminalBench 최고 점수가 **Terminus 2 하니스** 덕분이었다고 설명함 - 그래서 우리는 하니스를 자유롭게 교체하거나 직접 만들 수 있어야 함. 월 20달러 구독 때문에 특정 하니스에 묶이는 건 비합리적임 - 나는 **tilth**라는 도구를 만들어서 hash 기반 읽기/편집 방식을 구현했음. npm과 cargo에서 설치 가능하며, Claude Code나 Cursor 같은 에디터와 연동됨 [GitHub 링크](https://github.com/jahala/tilth) 목표는 LLM이 툴을 더 효율적으로 사용하고 토큰 낭비를 줄이는 것임 - 마크다운에도 적용하면 좋을 듯함. **섹션 단위 주소 지정**을 추가하면 버전 간 안정성이 높아짐 - grep과의 벤치마크 비교도 흥미로울 듯함 - 나는 비슷한 방법을 독립적으로 고안했지만, **추상화 의존성** 때문에 포기했음. 대신 **Damerau-Levenshtein 거리**를 사용해 편집 유사도를 계산하고, 일정 임계값 이상이면 수정이 통과되게 함. 이렇게 하면 모델이 교체할 소스 토큰을 명시적으로 출력하게 되어 정확도가 높아짐 [코드 예시](https://github.com/day50-dev/sidechat/blob/db9c8f9d834967442436c4ab4718be73ad321d23/sidechat/sc-tp.py#L72) 핵심은 오류 메시지가 구체적이어야 함 — “Content mismatch. Reread the file”처럼 **복구 지시를 포함한 에러 처리**가 중요함. 이 방식은 4B 모델에서도 잘 작동하며, 툴콜을 지원하지 않는 모델에는 **시스템 프롬프트 주입 해킹**으로 대응함 [관련 코드](https://github.com/day50-dev/sidechat/blob/db9c8f9d834967442436c4ab4718be73ad321d23/sidechat/sidechat#L365) - 예전 모델로도 꽤 정확한 결과를 얻을 수 있었음. 핵심은 모델을 **“올바르게 다루는 것”** 이었음. 이 글은 모델이 단순히 텍스트가 아니라 **소스 코드의 구조적 표현(AST)** 을 직접 다룰 수 있다면 더 큰 성과가 있을 것이라 시사함. 예를 들어 OpenRewrite는 코드의 타입, 포맷, 의존성 정보를 모두 포함한 **Lossless Semantic Tree**를 사용함. 이런 구조를 모델이 활용하면 불필요한 토큰 낭비 없이 매우 정확한 수정이 가능해짐. 결국 “Vim vs Emacs” 논쟁의 답이 “IntelliJ”인 이유와 같음 — 구조적 정보가 강력한 무기임. 만약 모델이 코드와 문서, 그리고 **구문/의미 트리**를 함께 학습한다면, 진정한 **신경-기호적 코딩 모델**이 될 것임 - 나는 Emacs의 gptel로 LLM을 실험하면서, LLM이 **Unix patch 도구로 코드 수정**을 잘 못한다는 걸 발견했음. 그래서 Emacs의 **tree-sitter**를 활용해 gptel용 툴을 직접 만들었음. `tree_sitter_list_nodes`, `tree_sitter_update_nodes` 같은 명령으로 AST 노드를 직접 수정하게 했더니 완벽하게 작동했음 - 흥미로운데, 그 코드를 공유할 수 있는지 궁금함 - Codex의 `apply_patch`는 사실 **제약된 샘플링 스키마**를 사용함. [관련 코드](https://github.com/openai/codex/blob/main/codex-rs/core/src/tools/handlers/tool_apply_patch.lark) 저자는 이를 모르고 단순 비교를 했기 때문에, 더 현실적인 벤치마크는 이 스키마를 활성화한 상태에서 해야 함 - 이 글의 인용구 중 특히 인상 깊었던 부분이 있음 “모델이 문제를 이해 못하는 게 아니라, **표현이 불안정한 것**이다. 착륙 장치 문제를 조종사 탓으로 돌리지 말라.” “모델은 해자(moat), 하니스는 다리(bridge)다.” “멋진 데모와 신뢰할 수 있는 도구의 차이는 마법이 아니라 **지루하지만 정교한 엔지니어링**이다.” - 정말 공감됨. 단순한 조언이 아니라, 저자의 사고방식을 생생히 그려낸 **기술적 예술 작품** 같음 - 내가 가장 좋아하는 문장은 “그건 위협이 아니다. **무료 R&D다**”임