2026년 7월 4일 - Link Blog

더 나은 모델: 더 나쁜 도구 (Better Models: Worse Tools). Armin은 Pi를 해킹하던 중 마주친 기묘한 문제에 대해 보고합니다:

요약하자면, 최신 Claude 모델들이 중첩된 edits[] 배열 내에서 때때로 존재하지 않는 임의의 필드를 추가하여 Pi의 편집 도구 (edit tool)를 호출한다는 것입니다. 그리고 이것은 Haiku나 작은 모델의 문제가 아닙니다. 바로 Opus 4.8에서 발생합니다. 편집 자체는 대개 정확하지만, 모델이 가공의 키 (keys)를 만들어내기 때문에 인자 (arguments)가 스키마 (schema)와 일치하지 않으며, 이로 인해 Pi는 도구 호출 (tool call)을 거부하고 다시 시도할 것을 요청합니다. 모델이 때때로 잘못된 형식의 도구 호출을 생성한다는 점(특히 작은 모델들의 경우)만 본다면 이것 자체는 그리 놀라운 일이 아닙니다. 저를 놀라게 한 점은, Opus 4.8과 Sonnet 5 모두에서 이 현상이 나타나지만 이전 모델들에서는 나타나지 않는다는 점에서, 최신 Anthropic 모델들로 갈수록 이 문제가 악화되고 있다는 사실입니다. 즉, 이 제품군의 SOTA (State-of-the-Art) 모델들이 이전 모델들보다 이 특정 도구 스키마 (tool schema)를 다루는 데 더 서툴다는 것입니다.

Armin은 이것이 최근의 Anthropic 모델들이 Claude Code에 내장된 편집 도구들을 더 잘 사용하도록 특별히 훈련되었기 때문(아마도 강화학습 (Reinforcement Learning)을 통해)이라고 이론을 세웁니다. 이로 인해 Pi와 같은 다른 코딩 하네스 (coding harnesses)들은 자신들의 커스텀 편집 도구들이 잘못 사용될 가능성이 더 높아지는 불행한 결과를 초래하게 됩니다.

Claude의 편집 도구는 검색 및 교체 (search and replace) 방식을 사용합니다. 반면 OpenAI의 Codex는 대신 apply_patch 메커니즘을 사용하며, OpenAI는 과거에 자신들의 모델이 해당 도구를 효과적으로 사용하도록 어떻게 훈련되는지에 대해 언급한 바 있습니다.

이것이 Pi와 같은 제3자 코딩 하네스 (third-party coding harnesses)들이 사용자가 선택한 기반 모델에 대해 가장 성능이 좋은 도구를 사용할 수 있도록 여러 개의 편집 도구를 구현해야 함을 의미할까요?