언어

Hashline vs Replace: 편집 형식이 중요할까?

작성일 · 수정일

기계 번역 원문.

내용

Can Bölük의 하네스 문제에서는 코딩 에이전트에서 hashline 방식의 편집(4#WB처럼 줄 번호를 기준점으로 삼는 방식)이 기존 replace 모드 편집(old_string/new_string 매칭)보다 성능이 좋다는 결과를 보여주었다. 나는 직접 하네스(tau)를 만드는 실험을 하고 있었고, 이 결과를 검증하고 내 하네스의 기본 편집 전략으로 hashline을 고려해야 할지 알아보고 싶었다. 그래서 여러 언어와 모델에 걸쳐 직접 시험해 보려고 edit-bench를 만들었다.

실험 설정

edit-bench는 기존 코드베이스를 바탕으로 변이 기반 테스트를 생성한다. 스크립트에 디렉터리를 지정하면 명령문 삭제, 불리언 값 반전, 인수 교환 등의 변이를 생성한다.

  • 언어: Python(hive에서 가져옴), TypeScript(oh-my-pi에서 가져옴), Rust(irradiate에서 가져옴)
  • 모델: gpt-4.1-mini, google/gemini-3-flash-preview, qwen/qwen3.5-397b-a17b
  • 편집 모드: replace(old_string/new_string) vs hashline(줄 번호를 기준점으로 사용)
  • 언어별 작업 20개, 단일 시도, 원샷 실행
  • 최근에는 tau에 퍼지 매칭도 추가했는데(단계적 공백 제거: trim_end → trim_both → unicode normalization), 이것이 도움이 되는지도 알아보고 싶었다

결과

Replace 모드:

모델 Python TypeScript Rust
gemini-3-flash 95% 80% 95%
qwen3.5-397b 90% 85% 85%
gpt-4.1-mini 65% 75% 45%

Hashline 모드(이전 실행 결과):

모델 Python TypeScript Rust
gemini-3-flash 70% 85% 90%
qwen3.5-397b 85% 85% 90%
gpt-4.1-mini 50% 70% 55%

Hashline은 Python에서는 성능을 눈에 띄게 떨어뜨리고, TypeScript와 Rust에서는 대체로 큰 영향을 주지 않는 듯하다. 이런 언어 의존성은 흥미롭다 — Python에서는 공백이 문법적 의미를 갖기 때문에 줄 번호를 기준점으로 삼는 편집에서 오류가 더 쉽게 발생할 수 있다.

퍼지 매칭이 도움이 될까?

그렇지 않은 듯하다.

tau의 단계적 공백 제거 기반 퍼지 매칭이 replace 모드 실행 중 실제로 작동하는지 확인하려고 트레이스 수집 기능을 추가했다. 성공한 편집 114건과 실패한 편집 20건(모델 3개 × 언어 3개) 전체에서 퍼지 매칭이 작동한 횟수는 0회였다.

실패한 편집 20건 중:

  • 1건은 줄 끝에 공백이 있었다(이론상 수정 가능)
  • 약 8건은 old_string에 줄 번호가 포함되어 있었다(모델 버그)
  • 약 11건은 완전히 지어낸 내용을 담고 있었다

모델이 old_string을 정확히 재현할 때는 공백도 정확히 재현한다. 틀릴 때는 아주 크게 틀린다 — 공백을 단계적으로 제거해도 도움이 되지 않는다.

(트레이스 분석 상세 내용)

시사점

  1. Hashline과 replace 중 어느 쪽도 확실한 우위에 있지는 않다. 효과는 언어와 모델에 따라 달라진다. Python에서는 hashline의 성능이 떨어지고, TypeScript에서는 차이가 없으며, Rust에서는 우열을 가리기 어렵다.

  2. Can의 결과를 일반화하기는 어렵다. react-edit-benchmark는 JavaScript만 대상으로 하며, 검증 피드백에 LSP를 사용한다. 우리 실험 환경(LSP 미사용, 여러 언어)에서는 다른 양상이 나타난다. 특히 LSP 피드백 루프가 교란 요인으로 작용할 가능성이 크다. 모델에 타입 오류를 알려주고 이를 바탕으로 재시도하게 하면 성능이 상당히 높아지며, 이 효과는 편집 형식과 상호작용한다.

  3. 현재 모델에서는 퍼지 매칭으로 해결할 문제가 없다. LLM은 소스 텍스트를 정확히 재현하거나 완전히 다른 내용을 지어낸다. 퍼지 매칭이 겨냥하는 것은 공백이 조금 어긋나는 경우인데, 실제로는 이런 일이 거의 발생하지 않는다.

  4. 현재의 하네스에서 현세대 모델을 사용할 때는 편집 형식이 병목이 아니다. 모델 간 격차(gemini-3-flash는 90% 이상, gpt-4.1-mini는 55~65%)가 편집 형식 간 격차보다 훨씬 크다. 편집 형식을 고민하기 전에 모델 선택과 프롬프트 엔지니어링에 투자하자.

의례적으로 덧붙이는 주의 사항: 표본 수가 작고 통계적으로 엄밀하지 않으니, 그 점을 감안해서 받아들이길 바란다.

전체 데이터: nwyin/edit-bench, 이슈 #13 및 #14.