AI 도구 호출 스키마 회귀: Claude Opus 4.8, Sonnet 5의 pi edit 장애와 에이전트 신뢰 지표 재설정

2026년 7월 초, 멀티모달 AI 서비스 pi의 edit 도구를 운용하는 과정에서 도구 호출이 거부되는 사례가 포착됐다. 거부된 호출은 새 세대 모델인 Claude Opus 4.8과 Sonnet 5에서 발생했으며, 그 원인은 edits[] 배열 내부에 스키마에 규정되지 않은 임의의 필드가 덧붙은 것으로 지목됐다. 이 사건은 단순한 일회성 버그라기보다는, 모델이 커질수록 도구 스키마 준수가 오히려 불안정해질 수 있다는 가설을 다시 한번 실측으로 끌어올린 사례다.

사건 개요: pi의 edit 도구 장애와 Opus 4.8, Sonnet 5의 edits[] 위반

관찰의 출발점은 pi 프로젝트의 edit 도구다. 이 도구는 텍스트를 부분 수정하기 위한 호출 규약을 갖고 있으며, 모델은 edits 배열 안에 수정 단위들을 담아 응답하도록 설계되어 있다. 그런데 Opus 4.8과 Sonnet 5가 생성한 호출에는 기존 스키마에는 존재하지 않는 보조 필드들이 edits[] 원소 안으로 함께 끼어들어 들어왔다. 런타임 검증기는 이를 허용 목록에 없는 속성으로 판단해 호출을 거부했고, 결과적으로 도구 자체가 실행되지 않았다.

에러의 구체적 형태와 거부 경로

에러 메시지는 편집 단위 한 개가 가진 페이로드의 형태에서 발생했다. edits[]의 한 원소에 통상적인 텍스트 수정 정보 외에 학습 데이터에서 자주 등장한 것으로 추정되는 보강용 속성들이 부착된 것이다. 검증기는 스키마의 additionalProperties 정책과 비교해 이를 위반으로 분류했고, 호출이 도구 런타임으로 넘어가기 전에 차단됐다. 거부 경로가 호출 단계에 있다는 점에서, 이 문제는 모델 출력 생성 자체의 실패라기보다는 스키마 정합성 검증 단계에서의 실패로 해석된다.

영향 받은 모델과 비교 대상 구형 LLM

관찰에서 비교 대상으로 언급된 모델군은 직전 세대 라인의 Claude 모델들이다. 동일 pi edit 도구 환경에서 호출 빈도와 거부율을 비교한 결과, 신형 두 모델에서만 edits[] 내부 필드 추가가 눈에 띄게 관측됐다. 표면적으로는 같은 도구, 같은 스키마를 공유하면서도 모델 교체만으로 안정성이 떨어진 것이다. 이는 모델 카드 상의 일반 벤치마크 점수만으로는 예측하기 어려운 종류의 회귀로, 도구 호출 충실도가 별도의 품질 차원으로 분리돼야 함을 보여준다.

도구 호출 기술의 작동 원리와 스키마의 역할

LLM 기반 에이전트가 외부 도구를 호출하는 방식은 크게 두 가지 산출물로 분해된다. 하나는 호출을 시작하겠다는 의도를 표시하는 특수 마커이며, 다른 하나는 그 안에 담기는 JSON 형태의 페이로드다. 런타임은 마커를 인식해 페이로드를 추출하고, 추출된 객체를 사전에 등록된 스키마와 비교한다. 스키마는 곧 호출 규약이며, 도구의 입력 계약서 역할을 한다.

특수 마커와 JSON 페이로드의 내부 구조

호출 마커는 코드블록과 유사한 구분자를 사용해 모델 출력 안에 박혀 있다. 그 안에 들어가는 본문은 사실상 JSON 객체이며, edits[]처럼 배열을 값으로 갖는 중첩 구조가 흔히 사용된다. 배열의 각 원소는 작업 단위를 표현하며, 텍스트 수정, 이미지 영역, 함수 인자 같은 정보가 키와 값의 쌍으로 정리된다. 스키마는 이 트리 구조 전체에 대해 키 이름, 자료형, 필수 여부, 허용 패턴을 명시한다.

스키마 미준수 시 런타임에서 발생하는 시스템 동작

런타임은 대체로 두 단계로 검증을 수행한다. 첫 단계는 JSON 자체의 파싱 가능성 검사이며, 두 번째 단계는 추출된 객체를 스키마와 대조하는 구조 검사다. 두 번째 단계에서 additionalProperties: false 같은 정책이 걸린 필드를 모델이 임의로 추가하면 즉시 거부 사유가 발생한다. 거부 사유는 에이전트 루프에 다시 입력되며, 모델은 자기 수정 후 재호출을 시도하게 된다. 이 자기 수정 시도조차 실패할 경우 도구 사용 자체가 중단되고, 에이전트 작업 전체가 실패로 귀결된다.

왜 더 나은 모델이 도구 호출에서 더 나빠지는가

모델이 교체될수록 일반 추론 능력은 향상되지만, 도구 호출 정확도는 같은 비율로 올라가지 않는 것으로 보인다. 이는 두 능력 사이의 학습 신호가 다르기 때문일 가능성이 높다. 추론 능력은 광범위한 텍스트 코퍼스에서 자기회귀적으로 학습되지만, 스키마 준수 능력은 상대적으로 좁은 합성 데이터와 보상 신호 위에서 미세 조정되기 때문이다.

학습 데이터와 강화학습 최적화 방향 가설

한 가지 가설은, 신형 모델의 강화학습 단계가 도구 호출보다 자유 형식 응답의 품질을 더 강하게 보상하도록 조정됐다는 것이다. 그 결과 모델은 응답을 풍부하게 만들려는 경향이 커지고, 도구 페이로드에 본문 컨텍스트를 덧붙이려는 습관이 강화된다. edits[] 같은 배열 원소에 메모나 설명을 필드 형태로 끼워 넣는 행동은 이러한 경향의 부산물로 해석될 여지가 있다. 다만 이 해석은 외부에서 직접 학습 로그를 본 것이 아니므로 가설 수준에 머문다.

도구 스키마 회귀가 발생하는 조건과 트리거

회귀는 보통 네 가지 조건이 겹칠 때 드러난다. 첫째, 스키마가 additionalProperties: false로 엄격히 잠겨 있을 때, 둘째, 모델이 스키마보다 풍부한 출력을 선호하도록 학습됐을 때, 셋째, 컨텍스트가 길어 모델이 일부 키를 누락한 상태로 메우려 할 때, 넷째, 도구 호출 자기 수정 재시도 횟수에 한계가 걸려 있을 때다. pi의 edit 사례는 이 네 조건이 동시에 성립했을 가능성이 높으며, 이 점이 회귀를 가시화한 것으로 추측된다.

에이전트 시대의 신뢰 지표 재설정

에이전트가 복잡한 작업을 자동화하는 비중이 늘어날수록, 신뢰 지표는 정확도와 지연 시간 외에 도구 호출의 결정성까지 포함해야 한다. 모델 카드에 적힌 일반 벤치마크 점수는 그 자체로 의미를 잃지는 않지만, 도구 사용 시나리오에 그대로 대입해선 곤란하다. 새로운 평가는 도구별 스키마를 따로 정의하고, 허용 키 외 항목 출현 비율을 별도로 측정하는 방향으로 설계돼야 한다.

벤치마크 점수와 도구 호출 성공률 사이의 괴리

벤치마크 점수가 높은 모델이 도구 호출에서 더 자주 실패한다는 관찰은 일견 모순처럼 보이지만, 두 지표가 측정하는 대상이 다르기 때문에 모순이 아니다. 전자는 자유 형식 응답의 품질을, 후자는 제약된 형식 준수 능력을 본다. 도구 호출은 응답의 내용보다 형식의 정합성이 우선인 작업이므로, 두 점수를 분리해 트래킹할 필요가 있다. 다음 표는 두 지표의 차이를 요약한다.

개발자가 현장에서 채택해야 할 스키마 검증 절차

현업에서는 도구 스키마 회귀를 조기에 발견하기 위한 검증 절차가 사실상 필수다. 첫째, 도구 호출 페이로드를 별도의 회귀 테스트로 매일 실행해 모델 교체 시 변경을 추적한다. 둘째, additionalProperties: true로 임시 완화한 뒤 허용되지 않은 키의 빈도를 측정해 모델의 행동을 관찰한다. 셋째, 도구 호출 자기 수정 루프를 더 두텁게 설계해 한 번의 거부에도 작업이 끊기지 않도록 한다. 넷째, 모델 업그레이드 전후의 호출 거부율을 별도 대시보드에 남긴다. 이러한 절차는 모델 회귀가 발생할 때 원인을 분리하고, 다운그레이드나 프롬프트 수정 같은 대응을 빠르게 결정하는 기반이 된다.

정리하면, pi의 edit 도구에서 일어난 edits[] 위반은 단순 버그 리포트 이상의 의미를 갖는다. 이 사건은 모델의 인지 능력과 도구 호출 능력은 별개의 차원이며, 새로운 모델이 항상 옛 모델의 도구 사용 행동을 계승하지는 않는다는 점을 실측으로 보여준다. 에이전트 시스템을 안정적으로 운영하기 위해서는 모델 카드의 벤치마크 외에 스키마 준수율이라는 별도의 신뢰 지표를 함께 관리해야 할 시점이다.

참고: GeekNews 원문, pi 프로젝트 페이지