▲

15개 LLM의 코딩 성능을 개선했어요, 바뀐 것은 하니스뿐

 (blog.can.ac)
14P by GN⁺ 6시간전 | ★ favorite | 댓글 1개
  • 여러 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에서 공개됨
▲
GN⁺ 6시간전  [-]
Hacker News 의견들

  • 이 글을 정말 흥미롭게 읽었음. 저자는 정확히 핵심을 짚었다고 생각함
    지금 존재하는 모델조차도, 우리가 에이전트 하니스(harness) 를 어떻게 설계하느냐에 따라 훨씬 더 효율적으로 만들 수 있는 여지가 많음.
    나는 “AI”를 단순히 LLM 자체로 보지 않고, LLM과 하니스가 피드백 루프로 연결된 사이버네틱 시스템 전체로 보는 게 맞다고 생각함.
    모델과 하니스는 서로를 강화하며 함께 진화하는 구조이므로, 둘 다 동등하게 중요함.
    이런 관점은 단순한 성능 향상뿐 아니라, 생성형 AI를 신경-기호적(neurosymbolic) 프로젝트로 재해석하게 해줌

    • 내 생각엔 지금도 GPT-4로 충분히 많은 걸 만들 수 있음.
      나는 실제로 2023년 버전의 GPT-4로 코딩 에이전트를 만들었음.
      오래된 모델로 작업하면 단순함을 유지해야 해서 오히려 문제를 다르게 보게 됨.
      예를 들어, Python에서는 grep -r def . 같은 단순한 semantic compression이 필수적임.
      Claude Code 같은 도구에 이런 간단한 훅을 추가하면 토큰 낭비 없이 코드 구조를 바로 파악할 수 있음
    • 나는 Peen이라는 CLI를 만들고 있음. 로컬 Ollama 모델이 툴을 효율적으로 호출하도록 돕는 도구임.
      단 몇 시간의 프롬프트 튜닝과 응답 처리 코드만으로도 작은 로컬 모델의 출력 품질이 놀랍게 개선됨
      GitHub 링크
    • 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로 바꾸자 거의 두 배가 되었음
    관련 링크

    • Pi 터미널 에이전트 제작자 Mario의 블로그 글에서도
      TerminalBench 최고 점수가 Terminus 2 하니스 덕분이었다고 설명함
    • 그래서 우리는 하니스를 자유롭게 교체하거나 직접 만들 수 있어야 함.
      월 20달러 구독 때문에 특정 하니스에 묶이는 건 비합리적임

  • 나는 tilth라는 도구를 만들어서 hash 기반 읽기/편집 방식을 구현했음.
    npm과 cargo에서 설치 가능하며, Claude Code나 Cursor 같은 에디터와 연동됨
    GitHub 링크
    목표는 LLM이 툴을 더 효율적으로 사용하고 토큰 낭비를 줄이는 것임

    • 마크다운에도 적용하면 좋을 듯함. 섹션 단위 주소 지정을 추가하면 버전 간 안정성이 높아짐
    • grep과의 벤치마크 비교도 흥미로울 듯함

  • 나는 비슷한 방법을 독립적으로 고안했지만, 추상화 의존성 때문에 포기했음.
    대신 Damerau-Levenshtein 거리를 사용해 편집 유사도를 계산하고, 일정 임계값 이상이면 수정이 통과되게 함.
    이렇게 하면 모델이 교체할 소스 토큰을 명시적으로 출력하게 되어 정확도가 높아짐
    코드 예시
    핵심은 오류 메시지가 구체적이어야 함 — “Content mismatch. Reread the file”처럼 복구 지시를 포함한 에러 처리가 중요함.
    이 방식은 4B 모델에서도 잘 작동하며, 툴콜을 지원하지 않는 모델에는 시스템 프롬프트 주입 해킹으로 대응함
    관련 코드

  • 예전 모델로도 꽤 정확한 결과를 얻을 수 있었음.
    핵심은 모델을 “올바르게 다루는 것” 이었음.
    이 글은 모델이 단순히 텍스트가 아니라 소스 코드의 구조적 표현(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는 사실 제약된 샘플링 스키마를 사용함.
    관련 코드
    저자는 이를 모르고 단순 비교를 했기 때문에, 더 현실적인 벤치마크는 이 스키마를 활성화한 상태에서 해야 함

  • 이 글의 인용구 중 특히 인상 깊었던 부분이 있음
    “모델이 문제를 이해 못하는 게 아니라, 표현이 불안정한 것이다. 착륙 장치 문제를 조종사 탓으로 돌리지 말라.”
    “모델은 해자(moat), 하니스는 다리(bridge)다.”
    “멋진 데모와 신뢰할 수 있는 도구의 차이는 마법이 아니라 지루하지만 정교한 엔지니어링이다.”

    • 정말 공감됨. 단순한 조언이 아니라, 저자의 사고방식을 생생히 그려낸 기술적 예술 작품 같음
    • 내가 가장 좋아하는 문장은 “그건 위협이 아니다. 무료 R&D다”임
답변달기