좋아진 Claude가 편집 도구에서는 더 자주 미끄러진 이유

좋아진 Claude가 편집 도구에서는 더 자주 미끄러진 이유

AI 뉴스 썸네일

AI 코딩 도구를 만들 때 모델 성능만 보면 놓치는 지점이 있어요. 최신 모델이 더 똑똑해져도, 파일 편집 같은 도구 호출에서는 특정 실행 환경에 너무 익숙해져 다른 스키마를 더 자주 틀릴 수 있다는 관찰이 나왔어요. Armin Ronacher가 Pi의 편집 도구에서 본 Claude Opus 4.8과 Sonnet 5 사례가 그 문제를 꽤 선명하게 보여줘요. 1

핵심 요약

구분	핵심	왜 봐야 하나요
모델 동작	Claude Opus 4.8과 Sonnet 5가 Pi의 편집 도구에서 허용되지 않은 키를 붙였어요	모델이 좋아져도 도구 스키마 준수는 별도 문제라는 점을 보여줘요
실패 원인	편집 내용은 맞았지만 `requireUnique`, `oldText2`, `matchCase` 같은 가짜 필드가 섞였어요	에이전트 실패가 추론 품질이 아니라 호출 형식에서 생길 수 있어요
설계 포인트	느슨한 보정보다 엄격한 스키마 제약이나 좋은 오류 피드백이 필요해요	코딩 에이전트와 자체 도구를 만드는 팀에 바로 닿는 문제예요

1. 모델은 맞는 편집을 만들고도 도구 호출에서 실패했어요

Pi의 편집 도구는 한 번의 호출에서 여러 문자열 치환을 처리하기 위해 `edits[]` 배열을 써요. 문제는 최신 Claude 모델이 그 배열 안의 스키마에 없는 필드를 덧붙였다는 점이에요. 실제 `oldText`와 `newText` 값은 맞았는데, 객체 끝에 `requireUnique`, `oldText2`, `newText2`, `matchCase`, `in_file` 같은 키가 붙으면서 호출이 거부됐어요. 2

이 사례가 흥미로운 이유는 실패한 모델이 작은 모델이 아니기 때문이에요. 글에서는 Claude Opus 4.8과 Sonnet 5에서 문제가 보였고, 이전 Anthropic 모델에서는 같은 현상이 보이지 않았다고 설명해요. 단순히 모델이 약해서 JSON을 틀린 게 아니라, 더 최신 모델이 특정 도구 모양에서는 오히려 불안정해진 셈이에요. 2

재현 조건도 단순하지 않았어요. 새 대화에서 “이 파일을 고쳐 줘”라고 시키면 잘 드러나지 않았고, 모델이 파일을 읽고 문제를 진단한 뒤 여러 줄 편집을 구성하는 긴 작업 흐름에서 더 잘 나타났어요. 생각 과정 블록을 제거하면 실패율이 줄었다는 관찰도 있어요. 긴 문맥과 도구 호출 이력이 모델의 출력 습관을 바꿀 수 있다는 뜻이에요.

728x90

도구 호출은 결국 모델이 생성한 텍스트예요

LLM의 도구 호출은 마법 같은 별도 회로가 아니에요. 모델은 대화 기록과 사용할 수 있는 도구 목록을 보고, 특수 마커와 JSON 비슷한 형태의 호출 내용을 생성해요. 클라이언트나 API는 그 출력을 해석해서 실제 도구를 실행해요. 그래서 모델이 “대충 이 모양이 편집 도구 호출 같다고” 배운 패턴이 스키마보다 앞설 수 있어요.

문제는 샘플링이 자유로울 때 더 커져요. 스키마가 `oldText`와 `newText`만 허용해도, 모델이 다음 토큰으로 `, "requireUnique"`를 뽑으면 결과는 잘못된 호출이 돼요. 반대로 문법 제약이나 엄격한 구조화 출력이 적용되면, 애초에 허용되지 않은 키가 나오지 못하게 막을 수 있어요. 글에서도 Anthropic의 `strict` 도구 호출을 켰을 때 해당 실행에서는 문제가 사라졌다고 설명해요. 4

Claude Code식 편집 도구에 과하게 익숙해졌을 수 있어요

Ronacher가 제시한 강한 가설은 “학습된 실행 환경의 습관”이에요. Claude Code의 편집 도구는 Pi의 중첩 배열 구조와 달리 `file_path`, `old_string`, `new_string`, `replace_all`처럼 더 평평한 구조에 가까워요. Claude Code는 공개 구현이 아니지만, 관찰할 수 있는 동작 기준으로 잘못된 인자 별칭을 받아들이고, 타입을 보정하고, 알 수 없는 키를 걸러내는 식으로 꽤 관대하게 동작한다고 글은 설명해요. 2

모델이 그런 환경에서 많이 후 학습됐다면, 조금 틀린 도구 호출도 실행 환경이 알아서 고쳐 주고 작업은 성공했을 수 있어요. 그러면 모델로서는 “정확히 스키마를 지키기”보다 “대략 익숙한 도구 호출 모양을 내기”가 강화돼요. 같은 의미의 편집 도구를 다른 구조로 제공하는 Pi 같은 실행 환경에서는 그 습관이 비용으로 돌아와요. 3

이건 Claude만의 문제가 아닐 수도 있어요. 도구 호출에 의존하는 서비스라면 모델 제공자가 선호하는 실행 환경과 비슷한 모양을 쓸 때 더 안정적이고, 조금 다른 스키마를 쓰면 예상 밖 회귀를 겪을 수 있어요. 모델 성능표에는 잘 안 보이지만, 실제 제품에서는 “도구가 모델의 몸에 얼마나 잘 맞는가”가 성능 일부가 돼요.

엄격한 구조와 좋은 오류 메시지가 안전망이에요

해결책은 두 갈래예요. 하나는 생성 단계에서 스키마 밖 토큰을 못 뽑게 하는 방법이에요. Anthropic의 strict 모드나 OpenAI 쪽의 구조화 출력, grammar 기반 출력 제약이 이 방향에 가까워요. 복잡한 도구 정의에서는 제약이 까다롭고 품질 절충도 있을 수 있지만, 파일 편집처럼 실패 비용이 큰 도구에는 꽤 실용적인 안전장치예요. 4

다른 하나는 실행 환경이 실패를 잘 설명하는 방법이에요. Hacker News 댓글에서는 모델이 틀렸을 때 올바른 호출 방법을 오류 메시지에 넣으면 다음 시도에서 금방 고친다는 경험담도 나왔어요. 이 방식은 왕복 호출이 한 번 더 들 수 있지만, 자체 도구를 붙이는 개발팀에는 현실적인 절충안이에요. 도구가 “실패했어요”만 말하는 것보다 “이 키는 허용하지 않고, 필요한 키는 이 둘이에요”라고 답하는 편이 모델에게 훨씬 유용해요. 1

왜 중요한가요

AI 에이전트 제품의 품질은 모델 점수만으로 결정되지 않아요. 같은 모델이라도 어떤 도구 스키마를 주는지, 오류를 어떻게 돌려주는지, 잘못된 호출을 어디까지 보정하는지에 따라 완전히 다른 체감 성능이 나와요. 이번 사례는 “모델이 똑똑하면 알아서 맞출 것”이라는 가정을 조심해야 한다는 신호예요. 2

개발자 입장에서는 도구 설계를 모델 친화적으로 다시 봐야 해요. 중첩 배열 안에 긴 문자열을 넣는 구조가 꼭 필요하다면 strict 모드나 스키마 제약을 검토해 볼 만해요. 기존 구조를 유지해야 한다면 오류 메시지를 더 구체적으로 만들고, 불필요한 별칭이나 관대한 보정이 모델의 나쁜 습관을 키우지 않는지도 살펴봐야 해요.

플랫폼 종속 문제도 남아요. 모델이 특정 코딩 도구에서 잘 동작하도록 후 학습될수록, 다른 실행 환경은 그 도구의 암묵적 습관까지 따라가야 할 수 있어요. 오픈소스 에이전트나 사내 도구를 만드는 팀이라면 “표준 스키마를 주면 모델이 중립적으로 따를 것”이라고 기대하기보다, 실제 긴 작업 이력에서 반복 테스트해야 해요. 여기서 깨지는 지점이 제품 안정성을 좌우해요. 3

참고 자료

1. 더 나은 모델, 더 나빠진 도구 — GeekNews
2. Better Models: Worse Tools — Armin Ronacher
3. Pi issue 6278 — GitHub
4. Strict tool use — Anthropic Docs