GPT-5.6 전환, 모델보다 평가 하네스가 먼저다

2.2배 빠르고 27% 저렴했다는 숫자

Ploy의 마이그레이션 회고는 GPT-5.6 Sol 전환을 단순한 성능 자랑으로 쓰지 않았다. Ploy의 에이전트는 마케팅 웹사이트를 계획하고, 코드베이스를 읽고, 컴포넌트를 만들고, 이미지를 생성하고, 스크린샷으로 자기 결과를 확인한다. 회사는 Claude Opus 4.8을 기본 모델로 쓰다가 GPT-5.6을 head-to-head로 평가했고, 완료된 빌드 기준 비용이 3.06달러에서 2.22달러로 낮아지고 wall-clock time이 8분에서 3분 42초로 줄었다고 밝혔다.

숫자만 보면 모델 교체의 성공담이다. 하지만 더 중요한 교훈은 GPT-5.6 가격과 캐시 정책, GLM-5.2 가격 충격, Apollo AI ROI 경고에서 다룬 흐름과 같다. AI 에이전트의 ROI는 모델 단가가 아니라 eval, tool schema, cache design, reasoning replay가 합쳐진 시스템 성능이다.

평가 하네스는 중립적이지 않다

Ploy가 먼저 고친 것은 모델 프롬프트가 아니라 평가 하네스였다. 기존 suite는 Claude Opus의 순차적 tool-call 스타일에 맞춰져 있었고, GPT-5.6이 병렬 호출을 많이 쓰자 "성공 중인 케이스"를 실패처럼 기록했다. 또 일부 데이터셋은 minScore 기본값 문제 때문에 0.98점을 받은 결과를 실패로 처리했다. Ploy는 첫 cross-model run의 raw failure 중 약 3분의 1이 모델 문제가 아니라 하네스 가정에서 왔다고 설명한다.

이 지점은 한국 기업에 특히 중요하다. 많은 팀이 기존 Copilot, Claude, Gemini 기준으로 만든 내부 benchmark를 그대로 새 모델에 적용한다. 그러나 model family가 바뀌면 도구 호출 방식, optional parameter 처리, 캐시 정책, 출력 길이, reasoning state 재현 방식이 달라진다. 현실의 디테일, AI 에이전트 평가의 맹점이 지적한 것처럼, 에이전트 평가는 정답률보다 trace triage가 중요하다.

도구 계약은 모델마다 다르다

가장 실무적인 부분은 optional parameter 문제다. Ploy의 code tool에는 25개 top-level parameter가 있고 그중 하나만 required였다. Claude는 필요한 23개만 보냈지만 GPT-5.6은 매번 25개를 모두 채웠다. Ploy는 3일간 production trace에서 GPT-5.6의 관련 호출 6,635건이 모두 25개 property를 포함했다고 밝혔다. 문제는 verbose함이 아니라 invented value가 실제 의도처럼 보인다는 점이다. 그 결과 파일 read 호출의 5264%가 비어 돌아왔다고 한다.

Ploy의 해결책은 OpenAI-family 모델에 한해 optional property를 required but nullable로 바꿔 모델이 "쓰지 않음"을 null로 표현하게 하는 schema transform이었다. OpenAI function calling 문서, Vercel AI SDK, OpenAI prompt caching guide, Anthropic prompt caching guide를 함께 보면 이 문제는 한 회사의 특수 사례가 아니다. provider abstraction은 편하지만 provider behavior까지 지워주지는 않는다.

캐시는 가격표가 아니라 아키텍처다

Ploy는 GPT-5.6 전환 초기에는 비용이 Opus보다 50% 비싸 보였지만, 원인은 모델 가격이 아니라 캐시 설정이었다고 말한다. 약 2만 9,000토큰의 static prefix를 어떻게 공유하느냐가 비용을 갈랐다. OpenAI의 GPT-5.6 계열에서는 prompt_cache_key와 breakpoint 설계가 중요해졌고, Ploy는 workspace-scoped key를 선택해 첫 호출 cache hit를 0%에서 83.7%로 끌어올렸다고 설명한다. 총 uncached input token도 28% 줄었다.

한국 SaaS와 SI 조직은 이 대목을 그대로 가져와야 한다. 고객사별 workspace, 부서별 정책, 프로젝트별 memory가 섞이는 구조에서는 캐시 키를 전역으로 둘 수도, 대화별로 잘게 쪼갤 수도 없다. 너무 넓으면 hot key가 되고, 너무 좁으면 첫 호출이 항상 비싸다. 따라서 모델 도입 문서에는 가격표뿐 아니라 cache scope, cache invalidation, tenant isolation 정책이 들어가야 한다.

자주 묻는 질문

Q1: GPT-5.6이 Claude Opus보다 항상 낫다는 뜻인가요?

A: 아니다. Ploy의 업무와 평가 suite에서는 유리했다는 사례다. 다른 도메인에서는 Claude, Gemini, 오픈 모델이 더 나을 수 있다.

Q2: 모델 교체 전 가장 먼저 할 일은 무엇인가요?

A: 기존 평가 실패를 trace 단위로 분류해야 한다. 새 모델이 못한 것인지, 평가 하네스가 기존 모델의 습관을 강요한 것인지 구분해야 한다.

Q3: optional parameter 문제는 프롬프트로 해결되나요?

A: Ploy 사례에서는 아니었다. 도구 설명을 바꿔도 행동이 유지됐고, schema transform이 효과를 냈다.

Q4: 캐시 설정은 왜 제품 전략인가요?

A: 고객, workspace, 세션 단위로 비용과 지연시간이 달라지기 때문이다. 잘못된 cache key는 모델 가격 비교 자체를 왜곡한다.

Q5: 한국 기업에는 어떤 시사점이 있나요?

A: 모델 전환을 구매팀 프로젝트로 두면 안 된다. 평가, 플랫폼, 보안, 제품팀이 함께 tool contract와 trace 관측 체계를 설계해야 한다.