실험 설계와 도구별 채택률
이번 실험은 Opus 4.8, Sonnet 4.6, Haiku 4.5 모델을 대상으로 Python과 TypeScript 저장소에서 코드 위치 찾기, 호출자 탐색, 편집 작업을 수행하며 진행됐다. 비교 대상은 텍스트 일치 기반의 `grep`과 참조·정의·문서 심벌을 이용하는 의미 기반 탐색 도구인 LSP(Language Server Protocol)다.
단순한 코드 위치 찾기 작업에서 모델들의 LSP 호출 비중은 매우 낮았다. Opus 4.8은 0%, Sonnet 4.6은 4%, Haiku 4.5는 6%만이 LSP를 선택했다. 특히 LSP를 먼저 사용하도록 강제한 실험군에서는 작업 성공률이 100%에서 89%로 하락하는 결과가 나타났다. 다중 파일 이름 변경 작업에서도 Opus 4.8의 LSP 호출 비중은 3%에 그쳤다.
반면 모든 호출자를 찾는 참조 완전성 작업에서는 LSP 채택률이 각각 45%, 50%, 57%로 상승했다. 정밀도 측면에서 LSP는 1.00을 기록하며 거짓 일치를 효과적으로 제거했으나, grep의 정밀도는 0.76에 머물렀다. 다만 재현율은 두 방식 모두 약 0.66으로 비슷해, LSP가 실제 호출을 더 많이 찾아내지는 못했다.
검색 정밀도와 출력 형식의 상관관계
저장소의 특성에 따라 LSP의 효용은 다르게 나타났다. TypeScript 저장소인 remeda에서는 grep의 정밀도가 1.00이었으며, LSP를 사용해도 F1 스코어 개선 없이 토큰 사용량만 16% 증가했다. 반면 hono 저장소에서는 grep 정밀도가 0.51로 낮았고, LSP 사용 시 F1이 0.246 상승하며 토큰 사용량은 12% 감소했다. Python 저장소인 requests에서는 LSP 사용 시 F1이 0.072 상승했으나 토큰 사용량은 19% 늘어났다.
도구의 성능 차이는 검색 알고리즘뿐 아니라 출력 형식에서도 발생했다. 초기 LSP 도구는 파일 경로, 행, 열 정보만 반환해 모델이 코드를 확인하려면 파일을 추가로 읽어야 했다. 반면 grep은 `src/auth.ts:42: return validateToken(token)`처럼 일치한 코드 줄을 즉시 반환한다.
이러한 맥락 차이를 해결하기 위해 LSP 응답에 소스 텍스트를 추가하자 성능이 개선됐다. Opus 4.8과 pyright 인덱스를 사용한 실험에서, 위치만 반환한 LSP는 첫 시도 성공률 0.67, 후속 읽기 15.2회를 기록했다. 하지만 코드 맥락을 함께 반환하도록 수정하자 성공률은 0.83으로 높아졌고, 후속 읽기는 3.2회로 급감했으며 토큰 사용량도 4,131개에서 3,336개로 줄었다.
텍스트 검색이 여전히 유효한 이유는 포괄성 때문이다. LSP의 `find_references`는 실제 코드 참조만 반환하지만, 이름 변경 작업에는 주석, 문서 문자열, 설정 파일 내의 텍스트 수정이 함께 필요하다. grep은 이러한 비코드 영역까지 모두 찾아낼 수 있어 리팩터링 작업에 더 적합한 특성을 보인다.
하네스 설계와 에이전트 성능의 관계
에이전트의 실효 성능은 '모델 × 하네스(Harness)'의 관계로 정의된다. 하네스는 모델 주변의 실행 환경으로, 문맥 지시어, 도구 입력 스키마, 결과 및 오류 형식, 루프 구조를 포함한다. 동일한 모델이라도 하네스 구성에 따라 도구 선택과 행동 정책이 달라진다.
모델이 LSP보다 grep을 선호하는 현상은 학습 분포의 영향일 가능성이 크다. `read`, `grep`, `edit`, `bash`를 반복 사용하는 궤적으로 사후 학습을 거친 모델은 해당 인터페이스에 의존하는 행동 정책을 학습한다. 프롬프트로 새 도구를 소개하더라도, 모델이 익숙한 도구와 결과 형식의 패턴을 우선시하는 경향이 있다.
따라서 새로운 도구를 도입할 때는 단순히 정밀도가 높은 도구를 제공하는 것에 그치지 않고, 실제 호출 여부와 다음 판단에 필요한 맥락이 충분히 제공되는지를 전체 실행 흐름 안에서 평가해야 한다. 개발자는 `path:line:content`와 같이 모델이 즉각적으로 해석할 수 있는 출력 형식을 설계하고, 의미 기반 검색과 텍스트 검색을 상호 보완적인 대체 경로로 유지하며 하네스를 구성해야 한다.
