모델은 좋아졌는데 도구 호출은 더 나빠질 수 있다

• 이상한 현상은 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을 켜면 저자의 실험에서는 문제가 사라짐

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가 고쳐서 성공 처리하고 보상을 받을 수 있음

• 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 때문에 실패하면 사용자 경험이 나빠지고, 반대로 잘못된 필드를 조용히 무시하면 나중에 더 위험한 호출에서도 같은 관대함이 문제를 숨길 수 있거든요.