[번역] 하네스 수정만으로 15개 LLM의 코딩 능력을 향상시켰습니다

AI & ML-ops•2026.02.21

원문: http://blog.can.ac/2026/02/12/the-harness-problem/

Can Bölük - 2026-02-12

0x0: 잘못된 질문

현재의 논의는 거의 전적으로 어떤 모델이 코딩에 가장 뛰어난가에 집중되어 있습니다. GPT-5.3이냐 Opus냐, Gemini냐 아니면 이번 주에 새로 출시된 무엇이냐 하는 식입니다. 이러한 프레임은 모델을 유일하게 중요한 변수로 취급하기 때문에 점점 더 오해의 소지가 커지고 있습니다. 실제로는 훨씬 더 평범한 것이 병목 현상의 원인 중 하나이기 때문입니다. 바로 하네스(Harness)입니다.

하네스는 사용자의 첫인상을 결정짓는 곳(스크롤이 제멋대로인지, 아니면 버터처럼 부드러운지?)일 뿐만 아니라, 모든 입력 토큰의 소스이자 모델의 출력과 워크스페이스의 모든 변경 사항 사이를 잇는 인터페이스이기도 합니다.

우리는 Mario Zechner가 만든 훌륭한 오픈 소스 코딩 에이전트인 Pi를 포크한 "취미용 하네스" oh-my-pi를 관리하고 있습니다. 지금까지 약 1,300개의 커밋을 작성했으며, 주로 직접 사용하며 불편함을 느낄 때마다 조금씩 개선해 왔습니다. (~~혹은 "rg를 실행하는 게 왠지 찜찜하다"는 이유로 N-API를 통해 더 많은 Rust 코드를 심고 싶은 욕구가 생길 때마다요.~~)

왜 이런 수고를 하느냐고 물으실 수도 있습니다. Opus가 훌륭한 모델일지 모르지만, Claude Code는 오늘날까지도 서브 에이전트 출력에서 가공되지 않은 JSONL을 유출하여 수십만 개의 토큰을 낭비하고 있습니다. 우리는 "에라 모르겠다, 이제 서브 에이전트는 구조화된 데이터를 출력한다"라고 결정할 수 있습니다.

도구 스펙(Spec), 에러 메시지, 상태 관리 등 "모델이 무엇을 바꿔야 할지 아는 것"과 "문제가 해결되는 것" 사이의 모든 과정이 여기에 해당합니다. 실제 실패의 대부분은 바로 이 지점에서 발생합니다.

모델에 구애받지 않는 하네스는 모델 자체가 하나의 파라미터에 불과하기 때문에 훌륭한 테스트 베드가 됩니다. 진짜 변수는 우리가 상상할 수 없을 정도로 강력하게 제어할 수 있는 하네스입니다.

어쨌든, 어제 우리가 변경한 이 한 가지 변수에 대해 이야기해 보겠습니다.

0x1: 편집 도구!

우리가 무엇을 만들었는지 설명하기 전에, 현재 기술 수준(State of the art)을 이해할 필요가 있습니다.

Codex는 apply_patch를 사용합니다: 이는 기본적으로 OpenAI 스타일의 diff인 문자열을 입력으로 받습니다. 구조화된 스펙에 의존하는 대신, 하네스는 이 데이터 덩어리가 엄격한 규칙 세트를 따를 것으로 기대합니다. OpenAI 팀원들이 똑똑하다는 것은 의심의 여지가 없으므로, GPT의 Codex 변종 모델들의 경우 JSON 스키마나 필수 도구 호출과 같은 다른 제약 조건이 작동하는 방식과 유사하게, LLM 게이트웨이에서 이 구조에 맞도록 토큰 선택 프로세스가 편향되어 있을 것이라 확신합니다.

하지만 이를 전혀 모르는 다른 모델에 적용하면 어떻게 될까요? 패치 실패율이 치솟습니다. 우리의 벤치마크에서 Grok 4의 패치 실패율은 50.7%였고, GLM-4.7은 46.2%였습니다. 이 모델들이 나쁜 것이 아니라, 단지 그 언어를 구사하지 못할 뿐입니다.

Claude Code(및 대부분의 다른 도구)는 str_replace를 사용합니다: 정확한 기존 텍스트를 찾아 새 텍스트로 교체하는 방식입니다. 멘탈 모델(Mental model)은 매우 단순합니다. 하지만 모델은 공백과 들여쓰기를 포함하여 모든 문자를 완벽하게 재현해야 합니다. 일치하는 항목이 여러 개라면? 거부됩니다. "교체할 문자열을 파일에서 찾을 수 없음" 오류는 너무 흔해서 별도의 GitHub 이슈 메가스레드가 있을 정도입니다. 딱히 최적이라고 보기는 어렵습니다. Gemini도 기본적으로 동일한 방식을 사용하며 여기에 약간의 퍼지(fuzzy) 공백 매칭을 더한 정도입니다.

Cursor는 별도의 신경망을 훈련시켰습니다: 편집 초안을 가져와 파일에 올바르게 병합하는 작업만을 수행하는 파인튜닝된 70B 모델입니다. 하네스 문제는 너무나 어려워서 가장 자본력이 풍부한 AI 기업 중 하나가 또 다른 모델을 투입하기로 결정했을 정도입니다. 심지어 그들은 자신들의 블로그 포스트에서 "400라인 미만의 파일에서는 파일을 통째로 다시 쓰는 것이 aider 스타일의 diff보다 성능이 뛰어나다"고 언급하기도 했습니다.

Aider의 자체 벤치마크에 따르면 포맷 선택만으로 GPT-4 Turbo의 점수가 26%에서 59%로 요동쳤지만, GPT-3.5는 동일한 포맷에서 유효한 diff를 안정적으로 생성하지 못해 19%에 그쳤습니다. 포맷은 모델만큼이나 중요합니다.

JetBrains의 Diff-XYZ 벤치마크는 이를 체계적으로 확인해 주었습니다. 모든 모델과 사용 사례를 아우르는 단일 편집 포맷은 존재하지 않습니다. EDIT-Bench는 실제 편집 작업에서 단 하나의 모델만이 60% 이상의 pass@1을 달성했다는 사실을 발견했습니다.

보시다시피, "어떻게 변경 사항을 적용할 것인가"라는 단순한 문제에 대해 진정한 합의가 이루어진 "최선의 해결책"은 없습니다. 우리의 생각은 이렇습니다. 이러한 도구 중 어느 것도 모델이 변경하려는 라인에 대해 엄청난 양의 컨텍스트를 낭비하거나 완벽한 기억력에 의존하지 않고도 안정적이고 검증 가능한 식별자를 제공하지 못합니다. 이들은 모두 모델이 이미 본 내용을 다시 재현하는 방식에 의존합니다. 모델이 이를 수행하지 못할 때(실제로 자주 못 합니다), 사용자는 모델을 탓합니다.

0x2: Hashline!

이제 잠시만 주목해 주세요. 모델이 파일을 읽거나 무언가를 검색할 때, 모든 라인에 2~3글자의 콘텐츠 해시가 태그로 붙어 돌아온다면 어떨까요?

11:a3|function hello() {
22:f1|  return "world";
33:0e|}

모델이 편집할 때는 이 태그들을 참조합니다. "라인 2:f1을 교체하고, 1:a3부터 3:0e까지의 범위를 교체하고, 3:0e 뒤에 삽입해." 마지막 읽기 이후 파일이 변경되었다면 해시가 (낙관적으로) 일치하지 않을 것이고, 데이터가 손상되기 전에 편집이 거부됩니다.

모델이 의사 난수(pseudo-random) 태그를 기억해낼 수 있다면, 자신이 무엇을 편집하고 있는지 알고 있을 가능성이 큽니다. 그러면 모델은 자신의 변경 사항을 표현하기 위한 신뢰할 수 있는 "앵커(anchor)"를 증명하기 위해 이전 콘텐츠나 공백을 재현할 필요가 없습니다.

0x3: 벤치마크

우리의 주된 관심사는 실제 성능이었기 때문에, 테스트 데이터(fixtures)는 다음과 같이 생성되었습니다.

React 코드베이스에서 무작위 파일을 가져옵니다.

역연산이 가능한 편집을 통해 버그로 위장한 변이(mutation)를 도입합니다 (예: 연산자 교체, 불리언 반전, off-by-one 에러, 옵셔널 체이닝 제거, 식별자 이름 변경 등).

문제에 대한 설명을 평이한 영어로 생성합니다.

평균적인 작업 설명은 다음과 같습니다.

# `useCommitFilteringAndNavigation.js`의 버그를 수정하세요.
가드 절(조기 반환)이 제거되었습니다.
문제는 `useCommitFilteringAndNavigation` 함수에 있습니다.
누락된 가드 절(조기 반환이 포함된 if 문)을 복구하세요.

당연히 모델이 반드시 원래 파일과 똑같은 방식이 아닌 고유한 해결책을 제시할 수도 있으므로 100%의 성공률을 기대하지는 않지만, 버그들이 기계적이기 때문에 대부분의 경우 해결책은 우리가 가한 변이를 되돌리는 것입니다.

작업당 3회 실행, 실행당 180개 작업을 수행했습니다. 매번 새로운 에이전트 세션을 시작하고 네 가지 도구(read, edit, write)를 제공했습니다. 임시 워크스페이스를 제공하고 프롬프트를 전달한 뒤, 에이전트가 멈추면 포맷팅 전후의 원본 파일과 비교했습니다.

16개 모델, 3개 편집 도구를 테스트한 결과는 명확했습니다. 패치(Patch)는 거의 모든 모델에서 최악의 포맷이었고, Hashline은 대부분의 모델에서 Replace와 대등하거나 그 이상의 성능을 보였으며, 성능이 낮은 모델일수록 가장 큰 이득을 보았습니다. Grok Code Fast 1은 6.7%에서 68.3%로 10배 향상되었습니다. 패치가 너무나 처참하게 실패하고 있었기 때문에 모델의 실제 코딩 능력이 기계적인 편집 실패 뒤에 거의 완전히 숨겨져 있었기 때문입니다. MiniMax는 두 배 이상 향상되었습니다. Grok 4 Fast의 출력 토큰은 재시도 루프에 토큰을 낭비하는 것을 멈추면서 61% 감소했습니다.

0x4: 그래서 어쩌라고요?

Gemini의 성공률이 8% 향상된 것은 대부분의 모델 업그레이드가 제공하는 것보다 더 큰 성과이며, 훈련 컴퓨팅 비용은 전혀 들지 않았습니다. 약간의 실험(과 벤치마킹에 쓴 약 300달러)만 들었을 뿐입니다.

종종 모델은 작업을 이해하는 데 서툰 것이 아닙니다. 자신을 표현하는 데 서툰 것입니다. 여러분은 착륙 장치 문제 때문에 조종사를 비난하고 있는 셈입니다.

0x5: 벤더들에 대한 짧은 생각

최근 Anthropic은 엄청난 인기를 끌고 있는 오픈 소스 코딩 에이전트인 OpenCode가 Claude Code 구독을 통해 Claude에 접속하는 것을 차단했습니다.

"OpenCode가 비공개 API를 리버스 엔지니어링했다"는 Anthropic의 입장은 그 자체로는 타당합니다. 그들의 인프라이고, 그들의 규칙이니까요. 하지만 이 조치가 시사하는 바를 보십시오.

하네스를 직접 만들지 마세요. 우리 것을 쓰세요.

Anthropic뿐만이 아닙니다. 이 기사를 쓰는 동안 Google은 우리의 계정을 Gemini에서 완전히 차단했습니다.

속도 제한(Rate-limit)도 아니고, 경고도 없었습니다. 비활성화되었습니다. 벤치마크를 실행했다는 이유만으로요. Gemini 3 Flash가 그들의 최선의 시도보다 5.0pp 더 높은 78.3%를 기록했다는 것을 보여준 바로 그 벤치마크 말입니다. 정확히 무엇 때문인지조차 모릅니다.

이것이 왜 시대착오적인지 말씀드리겠습니다. 우리는 방금 다른 편집 포맷이 그들 자신의 모델 성능을 5~14포인트 향상시키는 동시에 출력 토큰을 약 20% 절감한다는 것을 보여주었습니다. 이것은 위협이 아닙니다. 무료 R&D입니다.

어떤 벤더도 경쟁사 모델을 위해 하네스 최적화를 해주지 않을 것입니다. Anthropic은 Grok을 위해 튜닝하지 않을 것이고, xAI는 Gemini를 위해 튜닝하지 않을 것입니다. OpenAI는 Claude를 위해 튜닝하지 않을 것입니다. 하지만 오픈 소스 하네스는 모든 모델을 위해 튜닝합니다. 기여자들은 서로 다른 모델을 사용하고 자신이 직접 겪은 실패를 수정하기 때문입니다.

모델은 해자(Moat)이고, 하네스는 다리(Bridge)입니다. 다리를 불태우는 것은 건너오려는 사람을 줄어들게 할 뿐입니다. 하네스를 이미 해결된 문제라거나 심지어 중요하지 않은 것으로 취급하는 것은 매우 근시안적인 태도입니다.

우리는 게임 보안 분야 출신입니다. 치터(Cheater)들은 생태계에 엄청난 파괴력을 가집니다. 물론 그들은 차단당하고, 쫓겨나고, 고소당하지만, 잘 알려진 비밀은 결국 보안 팀이 "멋지네요! 어떻게 뚫었는지 보여줄래요?"라고 묻고 그들이 방어 팀에 합류하게 된다는 것입니다.

누군가 당신의 API를 건드리고 그 도구를 사용하여 상당한 추종자를 모으는 데 성공했을 때 올바른 반응은 "더 자세히 알려달라"는 것이어야지, "수천 명을 일괄 차단할 테니 복구하고 싶으면 DM으로 빌어라"가 되어서는 안 됩니다.

하네스 문제는 실재하며 측정 가능하고, 현재 가장 큰 레버리지를 일으킬 수 있는 혁신의 장입니다. "멋진 데모"와 "신뢰할 수 있는 도구" 사이의 간극은 모델의 마법이 아닙니다. 도구의 경계에서 이루어지는 세심하고 다소 지루한 경험적 엔지니어링입니다.

하네스 문제는 해결될 것입니다. 문제는 그것이 한 회사에 의해 폐쇄적으로 특정 모델만을 위해 해결될 것인가, 아니면 커뮤니티에 의해 공개적으로 모든 모델을 위해 해결될 것인가 하는 점입니다.

벤치마크 결과가 이를 증명합니다.

모든 코드, 벤치마크 및 실행별 보고서: oh-my-pi