--- title: "모델은 좋아졌는데 도구 호출은 더 나빠질 수 있다" published: 2026-07-04T20:16:22.000Z canonical: https://jeff.news/article/4680 --- # 모델은 좋아졌는데 도구 호출은 더 나빠질 수 있다 최신 Claude 계열 모델이 Pi의 파일 edit 도구를 호출할 때 스키마에 없는 필드를 invent해서 실패하는 현상을 분석한 글이다. 저자는 모델 성능이 좋아져도 특정 도구 생태계에 맞춘 post-training이 강해지면, 다른 harness의 도구 스키마에는 오히려 더 취약해질 수 있다고 본다. - 이상한 현상은 Pi의 edit tool에서 시작됨 - 최신 Claude 모델이 nested `edits[]` 배열 안에 스키마에 없는 필드를 자꾸 붙임 - 작은 모델이 아니라 Opus 4.8과 Sonnet 5에서 보였고, 이전 모델들에서는 재현되지 않았다는 점이 포인트임 - 더 짜증나는 건 `oldText`와 `newText` 자체는 byte-correct인 경우가 많았다는 것. 일을 못 한 게 아니라 호출 계약을 망친 셈임 - 실패 패턴은 꽤 구체적임 - Pi의 edit tool은 한 번에 여러 정확한 문자열 치환을 하려고 `edits` 배열을 받음 - 그런데 모델이 각 edit object 끝에 `type`, `id`, `kind`, `unique`, `requireUnique`, `matchCase`, `in_file`, `forceMatchCount`, `children`, `notes`, `cost` 같은 가짜 키를 붙임 - 어떤 경우에는 `oldText2`, `newText2`, `event.0.additionalProperties` 같은 황당한 필드도 나옴 - 이건 단순히 "모델이 JSON을 못 쓴다"는 얘기가 아님 - fresh single-turn prompt에서는 잘 재현되지 않았음 - 파일을 읽고, 문제를 진단하고, multi-line edit를 구성하는 agentic history에서 실패율이 올라감 - 특정 transcript에서는 Opus 4.8이 세션을 이어갈 때 약 20% 정도 실패했고, thinking block을 제거하면 실패율이 절반으로 줄었다고 함 - strict tool invocation을 켜면 저자의 실험에서는 문제가 사라짐 ```mermaid sequenceDiagram participant 모델 as Claude 모델 participant 하네스 as Pi 하네스 participant 검증기 as 스키마 검증기 participant 파일 as 파일 시스템 모델->>하네스: edit 도구 호출 생성 하네스->>검증기: edits 배열 인자 검증 검증기-->>하네스: 허용되지 않은 키 발견 하네스-->>모델: validation 실패 전달 모델->>하네스: 다시 호출 시도 하네스->>파일: strict 통과 시 편집 적용 ``` - 저자의 가설은 최신 모델이 특정 harness에 너무 잘 적응했다는 것임 - Claude Code의 edit tool은 Pi처럼 nested `edits[]` 구조가 아니라 `file_path`, `old_string`, `new_string`, `replace_all`에 가까운 flat 구조임 - Claude Code 클라이언트는 malformed tool use retry, parameter alias, type coercion, Unicode repair, unknown key filtering 같은 관대한 수리 로직을 갖고 있는 것으로 보임 - 이런 환경에서 강화학습이 이뤄지면, 살짝 틀린 tool call도 harness가 고쳐서 성공 처리하고 보상을 받을 수 있음 > [!WARNING] > 모델이 작업을 잘 이해해도 도구 호출 스키마를 정확히 지킨다는 보장은 없음. 특히 provider가 쓰는 hidden harness와 다른 구조의 도구를 붙이면 최신 모델일수록 이상한 prior와 싸울 수 있음 - nested schema가 특히 취약한 이유도 있음 - Anthropic tool call 포맷은 XML처럼 보이는 in-band signaling과 JSON serialization이 섞인 형태로 추정됨 - top-level string parameter는 비교적 단순하지만, 배열 안 객체에 multi-line file content가 escaped string으로 들어가면 sampling 난도가 확 올라감 - 특히 긴 `newText` 문자열을 닫은 직후 모델이 `}`를 낼지, `, "무언가"`를 낼지 결정하는 지점이 entropy가 높음 - strict mode와 grammar-aware decoding이 다시 중요해지는 흐름임 - schema상 허용되지 않는 키를 sampler가 애초에 못 내게 막으면 이 문제는 사라질 수 있음 - OpenAI의 harmony 포맷은 tool-call content type과 JSON constraint 경계를 transcript에 드러내는 방식이라 이런 전환이 비교적 명확함 - Anthropic도 strict mode에서는 서버 쪽에서 JSON schema 구조에 맞지 않는 key sampling을 막는 것으로 보인다고 저자는 추정함 - harness 만드는 팀에게 남는 교훈은 꽤 세다 - tool schema는 중립적인 계약이 아니라 모델의 post-training 분포 위에 놓인 입력임 - provider의 대표 제품이 사실상 모델의 기본 도구 사용 습관을 만든다면, 독자 harness는 그 습관과 가까운 schema를 쓰거나 strict decoding을 켜야 함 - "더 똑똑한 모델"이 "내 도구를 더 정확히 호출하는 모델"이라는 보장은 이제 더 약해졌음 --- ## 기술 맥락 - 이 글에서 중요한 기술 선택은 tool call을 모델의 자율 생성에 맡길지, 아니면 constrained decoding으로 강제할지예요. 전자는 유연하지만 모델이 학습된 관성대로 이상한 필드를 만들 수 있고, 후자는 schema 위반을 원천 차단하는 대신 sampling 제약이 생겨요. - 문제가 생긴 이유는 모델이 edit라는 작업의 의미는 이해했지만, Pi의 nested schema가 Claude Code식 flat edit schema와 달랐기 때문이에요. post-training에서 특정 도구 모양을 반복해서 성공 경험으로 배웠다면, 비슷하지만 다른 도구를 만났을 때 오히려 그 prior가 방해가 돼요. - harness 입장에서는 선택지가 두 개예요. Claude Code처럼 alias와 unknown key filtering을 넓게 받아주는 관대한 방식을 택할 수 있고, strict schema validation과 constrained decoding을 강하게 적용할 수도 있어요. 관대한 방식은 성공률은 높이지만 모델의 나쁜 습관을 숨기고, strict 방식은 실패를 빨리 드러내지만 도구 정의 복잡도 제한을 만날 수 있어요. - 에이전트 제품에서는 이게 파일 편집 안정성과 바로 연결돼요. 모델이 byte-correct patch를 만들었는데 schema 때문에 실패하면 사용자 경험이 나빠지고, 반대로 잘못된 필드를 조용히 무시하면 나중에 더 위험한 호출에서도 같은 관대함이 문제를 숨길 수 있거든요. ## 핵심 포인트 - Opus 4.8과 Sonnet 5가 nested edits 배열에 type, id, kind 같은 허구 필드를 붙여 tool call validation에 실패했다 - 실제 oldText와 newText 내용은 byte-correct인 경우가 많아, 문제는 작업 이해가 아니라 schema fidelity였다 - Claude Code처럼 관대한 harness에서 학습되면 잘못된 tool call도 보상받아 다른 도구 스키마에 약해질 수 있다 - strict tool invocation이나 constrained decoding이 이런 문제를 막는 현실적 방어선으로 보인다 ## 인사이트 에이전트 제품 만드는 팀이면 꽤 불편하게 읽어야 하는 글이다. 모델이 똑똑해지는 것과 내 도구 계약을 정확히 지키는 것은 다른 문제고, provider의 숨겨진 harness가 사실상 표준처럼 작동할 수 있다.