테스트 프레임워크 교체만으로 15개 LLM의 코딩 성능을 단시간에 개선한 사례

코딩 AI의 성능 병목이 모델 자체보다 '하네스(Harness)'와 '편집 도구'의 설계에 있음을 지적하며, 편집 툴의 스키마 개선만으로 Grok 4(실패율 50.7%)와 GLM-4.7(실패율 46.2%)을 포함한 15개 LLM의 코딩 효율을 극대화한 사례입니다.

AI 요약

최근 AI 코딩 분야에서는 GPT-5.3이나 Claude Opus 등 모델 성능 비교에만 집중하고 있으나, 실제 병목 현상은 모델의 출력을 워크스페이스에 반영하는 '하네스(Harness)'에서 발생하고 있습니다. 개발자 @_can1357은 오픈소스 코딩 에이전트인 Pi를 포크한 'oh-my-pi'를 1,300회 이상의 커밋을 통해 개선하며, 단순한 모델 교체보다 편집 도구(Edit Tool)의 논리 구조를 바꾸는 것이 더 효과적임을 입증했습니다. 기존 OpenAI의 apply_patch 방식은 타사 모델에서 높은 실패율을 보였고, Claude Code의 str_replace 방식은 공백 하나만 틀려도 에러가 발생하는 한계가 있었습니다. 이를 해결하기 위해 하네스 단에서 구조화된 데이터 처리를 최적화함으로써 다양한 LLM들이 가진 잠재력을 단시간에 끌어올릴 수 있었습니다.

핵심 인사이트

  • 하네스의 중요성: 모델은 단순한 파라미터일 뿐이며, 사용자 인터페이스와 토큰 입력 및 출력의 접점인 '하네스'가 실제 코딩 에이전트의 성패를 좌우합니다.
  • 기존 방식의 높은 실패율: 특정 모델에 최적화되지 않은 상태에서 apply_patch 도구를 사용할 경우, Grok 4는 50.7%, GLM-4.7은 46.2%의 높은 패치 실패율을 기록했습니다.
  • 도구 설계의 차이: Claude Code의 str_replace는 정확한 문자열 일치를 요구하여 'String to replace not found' 오류가 빈번하며, Cursor는 편집만을 위해 별도의 70B 미세조정 모델을 사용합니다.

주요 디테일

  • oh-my-pi 프로젝트: Mario Zechner의 Pi를 기반으로 한 홉 하네스 프로젝트로, 작성자가 약 1,300개의 커밋을 통해 Rust 기반 N-API 등을 활용하여 성능을 개선했습니다.
  • Claude Code의 비효율성: 현재 Claude Code는 서브 에이전트 출력에서 가공되지 않은 JSONL을 유출하여 수십만 개의 토큰을 낭비하는 문제를 안고 있습니다.
  • OpenAI의 apply_patch: OpenAI는 모델 게이트웨이 수준에서 토큰 선택 프로세스를 편향시켜 자사 모델(Codex)이 고유의 diff 구조를 잘 따르도록 설계했으나, 이는 타 모델과의 호환성을 저해합니다.
  • 편집 도구의 한계: 문자열을 단순히 찾는 방식은 들여쓰기나 공백 하나에도 민감하게 반응하여 모델이 완벽한 출력을 내놓아도 편집에 실패하는 경우가 많습니다.
  • 모델 불가지론적 접근: 하네스 구조를 개선하면 모델의 종류와 관계없이 구조화된 데이터를 정확히 처리하고 오류 메시지와 상태 관리를 효율적으로 수행할 수 있습니다.

향후 전망

  • 에이전트 경쟁의 변화: 향후 코딩 AI 경쟁은 '누가 더 똑똑한 모델을 쓰느냐'에서 '누가 더 견고하고 유연한 하네스를 구축하느냐'의 싸움으로 이동할 것입니다.
  • 범용 코딩 툴의 발전: 특정 모델에 종속되지 않고 다양한 LLM을 수용할 수 있는 고성능 편집 스키마와 하네스 기술이 오픈소스 커뮤니티를 중심으로 발전할 것으로 예상됩니다.
Share

이것도 읽어보세요

댓글

이 소식에 대한 의견을 자유롭게 남겨주세요.

댓글 (0)

불러오는 중...