최신 LLM, 왜 특정 도구 호출서 오히려 성능이 떨어질까?
최신 Claude 모델(Opus 4.8, Sonnet 5)이 이전 모델보다 특정 도구 스키마 호출 오류를 더 자주 발생시킴
이는 LLM의 강화 학습(Reinforcement Learning) 방식이 특정 환경(Claude Code)에 과도하게 최적화된 결과일 수 있다는 가설이 제기됨
모델이 잘못된 스키마를 허용하는 환경에 학습되면, 다른 환경의 도구 스키마 적용에 어려움을 겪을 수 있음
엄격한 스키마 검증(Strict Schema Validation) 모드 활성화 시 문제가 해결될 수 있으나, 이는 모델의 전반적인 성능에 영향을 줄 수 있음
최신 LLM의 도구 호출 스키마 불일치 현상
최신 Claude 모델(Opus 4.8, Sonnet 5)에서 이전 모델보다 특정 도구 스키마(Pi의 edit tool) 호출 오류가 증가하는 현상이 관찰되었습니다. 모델이 올바른 편집 내용을 생성하더라도, 스키마에 정의되지 않은 추가적인 키(Invented Keys)를 포함하여 도구 호출이 거부되는 사례가 보고되었습니다. 이는 최신 SOTA(State-of-the-Art) 모델이 특정 작업에서는 오히려 이전 모델보다 성능이 저하될 수 있음을 시사합니다.
강화 학습(RL)과 훈련 환경의 영향
이러한 현상의 주요 원인으로 강화 학습(Reinforcement Learning) 과정에서 특정 환경(예: Claude Code)에 과도하게 최적화된 결과일 가능성이 제기됩니다. 모델이 허용적인 스키마(Forgiving Schema)를 가진 환경에서 보상을 받으며 학습하면, 다른 엄격한 스키마를 가진 환경에서는 오히려 부정확한 출력을 생성할 수 있습니다. 특히 Claude Code 자체의 도구 스키마가 Pi의 복잡한 중첩 구조와 다르다는 점이 지적됩니다.
도구 호출(Tool Calling)의 내부 메커니즘
LLM의 도구 호출은 마법이 아니라, 모델이 텍스트 기반 신호(Text-based Signaling)를 통해 특정 도구를 호출하도록 훈련된 결과입니다. 모델은 시스템 프롬프트와 사용 가능한 도구 목록을 기반으로 특수 마커 토큰이 포함된 프롬프트를 받아, 이를 해석하여 도구를 호출합니다. 이 과정에서 JSON 직렬화(JSON Serialization)와 같은 기술이 사용되지만, 모델이 학습된 관례(Learned Convention)에 따라 예상치 못한 필드를 추가할 수 있습니다.
스키마 불일치 문제 해결 방안 및 트레이드오프
이 문제를 해결하기 위해 엄격 모드(Strict Mode)와 같은 강력한 스키마 검증(Stronger Guarantees) 메커니즘이 제시되었습니다. 이 모드는 JSON 스키마에 허용되지 않는 키 생성을 서버 측에서 거부합니다. 하지만 이러한 엄격한 제약은 모델의 전반적인 성능(Overall Performance)이나 창의성(Creativity)에 영향을 줄 수 있다는 트레이드오프(Trade-off)가 존재합니다. 또한, 특정 제공업체의 숨겨진 인코딩 방식에 대한 의존성 문제도 제기됩니다.
벤더 종속성(Vendor Lock-in) 가능성
일부 커뮤니티에서는 이러한 현상이 벤더 종속성(Vendor Lock-in) 전략의 일환일 수 있다는 추측도 나옵니다. 특정 제공업체의 독점적인 훈련 환경(Proprietary Training Environment)에 모델이 최적화되면, 다른 환경과의 호환성이 떨어지게 됩니다. 이는 결국 사용자가 특정 생태계에 종속되도록 유도할 수 있으며, 개방형 표준과 상호 운용성에 대한 우려를 낳습니다.
