프로덕션 AI 에이전트를 GPT-5.6으로 전환해 2.2배 빠르고 27% 저렴해진 과정

• Ploy는 프로덕션 마케팅 웹사이트를 계획·구축·검증하는 에이전트를 Claude Opus 4.8에서 GPT-5.6 Sol로 전환하고 모든 워크스페이스의 기본 모델로 지정함
• 평가 하네스의 모델별 가정을 바로잡은 뒤 홈페이지 재구축 작업에서 평균 실행 시간이 8분에서 3분 42초로 줄었고, 비용은 $3.06에서 $2.22로 27% 낮아졌으며 시각 점수도 0.970으로 높아짐
• GPT-5.6이 도구 호출의 선택적 매개변수 25개를 임의 값으로 모두 채우면서 파일 읽기의 52~64%가 빈 결과를 반환했으나, 선택 필드를 필수·nullable로 바꾸자 빈 읽기가 0%로 줄고 도구 호출도 약 30% 감소함
• OpenAI와 Anthropic의 캐시 범위·처리량 구조 차이로 GPT-5.6이 처음에는 약 50% 비싸게 측정됐지만, 워크스페이스 단위 캐시 키와 계층별 breakpoint를 적용해 첫 호출 적중률을 0%에서 83.7%로 높이고 미캐시 입력 토큰을 28% 줄임
• 모델 교체의 비용과 성능은 모델 자체뿐 아니라 평가 예산, 도구 스키마, 캐시 구조, 추론 재생 방식에 좌우되므로 기존 모델에 맞춰진 프로바이더별 가정부터 찾아 수정해야 신뢰할 수 있는 비교와 안정적인 운영이 가능함

Claude Opus를 대체한 GPT-5.6 Sol

• Ploy 에이전트는 프로덕션 마케팅 웹사이트의 페이지를 계획하고 코드베이스를 읽으며, 컴포넌트와 이미지를 생성하고 결과를 스크린샷으로 확인한 뒤 작업 완료 여부를 판단함
• 여러 달 동안 Claude Opus를 대체할 기준을 충족한 모델이 없었고, 기본 모델은 4개월 동안 Opus 4.7과 4.8 순서로 유지됨
• GPT-5.6 Sol은 동일 작업을 대상으로 한 일대일 평가에서 처음으로 Opus를 앞서며 모든 Ploy 워크스페이스의 기본 모델이 됨
• 초기 평가에서도 완료된 빌드의 실행 시간은 절반 미만이었고 비용은 27% 낮았으며, 기존 모델과 같거나 높은 점수를 기록해 마이그레이션을 진행할 근거가 됨
• Ploy는 Vercel AI SDK를 사용하지만, 모델 전환 과정에서 도구 인자 구성과 프롬프트 캐싱, 턴 간 추론 재생에 관한 프로바이더별 가정이 스택 전반에 남아 있음을 발견함
• 마이그레이션은 평가 하네스, 도구 스키마, 프롬프트 캐싱, 추론 재생 순으로 수정하며 진행됨

평가 수치를 믿기 전에 하네스부터 수정

• 평가 제품군은 프로덕션 에이전트를 고정 테스트 워크스페이스에서 실행하며, 홈페이지를 처음부터 구축하는 작업부터 복제 요청을 안전하게 실행할 수 있는지 판단하는 작업까지 수백 개 사례를 다룸
• 빌드 사례에서는 시각 판정기가 기준 디자인과 비교해 10개의 이진 검사를 수행함
  • hero 영역이 화면 전체 폭을 채우는 사진 장면인지 검사함
  • 주요 CTA가 pill 형태가 아닌 둥근 모서리의 직사각형인지 확인함
• 콘텐츠 검사와 도구 실행 경로 검사, 파일 단언도 함께 수행하며, 실패 시 도구 호출과 모델 텍스트를 포함한 전체 실행 추적을 검토함

• 기존 모델의 호출 방식에 맞춰진 제약

  • 기존 도구 호출 예산은 Opus의 순차 호출 방식에 맞춰져 있었지만, GPT-5.6은 병렬 호출을 사용해 올바르게 문제를 해결한 사례에서도 예산을 초과함
  • 평가 실행기는 Opus가 거의 사용하지 않던 일괄 파일 읽기를 지원하지 않았지만 GPT-5.6은 이를 자주 사용함
  • 첫 실행에서 발생한 원시 실패의 약 3분의 1은 모델 동작이 아닌 하네스의 가정에서 비롯됐으며, 모델별로 고르게 분포하지도 않았음
  • 도전 모델과 기존 모델의 실행 추적을 먼저 분류하지 않으면 새 모델이 기존 모델처럼 행동할수록 유리한 평가가 됨

• 암묵적인 점수 임계값

  • minScore가 빠진 데이터셋은 아무 경고 없이 기본값 1.0을 물려받음
  • 이 때문에 GPT-5.6은 hero 점수 0.98을 받고도 실패 처리됐고, Opus 역시 모든 개별 검사를 통과한 사례에서 실패로 판정됨
  • 두 결과 모두 방어 가능한 디자인이었지만 모델이 아닌 암묵적 임계값 때문에 탈락함

수정된 벤치마크 결과

• 하네스를 고친 뒤 브랜드 홈페이지를 기준 디자인에 맞춰 다시 구축하는 평가 제품군을 재실행함

• GPT-5.6은 페이지를 2.2배 빠르게 완성했고 비용은 27% 낮았으며, 출력 토큰도 약 절반만 사용함
• 생성한 코드의 양도 더 적었음
  • 한 쌍의 비교 사례에서 Opus는 대부분 사용되지 않는 색상 계열을 포함해 CSS 변수 174개와 17,957자의 globals.css를 생성함
  • GPT-5.6은 CSS 변수 45개와 2,508자를 사용하면서도 비슷하거나 더 나은 렌더링 결과를 냄

• 디자인 품질과 일관성

  • GPT-5.6은 깔끔하고 격자가 촘촘한 레이아웃에 강하지만, 강하게 유도하지 않으면 해당 스타일로 수렴하는 경향이 있음
  • Opus 4.8용으로 설계된 기존 하네스에서는 기존 디자인 시스템을 무시한 채 깔끔하지만 평범한 결과물을 자주 생성함
  • 디자인팀과 엔지니어링팀이 모델 유도 방식을 개선한 뒤에는 프로덕션에 필요한 브랜드 준수 기준을 충족함

도구 호출의 선택적 매개변수 처리

• 에이전트의 code 도구에는 최상위 매개변수 25개가 있으며, action만 필수이고 나머지는 선택 사항임
• Claude는 사용하는 매개변수 2~3개만 전송하지만 GPT-5.6은 호출마다 25개를 모두 보내며, 사용하지 않는 필드도 offset: 0, timeout: 120000, siteId: "00000000-0000-0000-0000-000000000000" 같은 그럴듯한 값으로 채움
• 3일간 수집한 프로덕션 code(read) 실행 추적에서도 같은 패턴이 나타남

• 빈 파일 읽기가 발생한 원인

  • 문제는 단순히 인자가 장황하다는 데 있지 않고, 파일 읽기 구현이 모델이 임의로 만든 값과 사용자가 의도한 값을 구별할 수 없다는 데 있었음
  • 구현은 offset: 0을 실제 인자로 처리했고, GPT-5.6 파일 읽기의 52~64%가 빈 결과를 반환함
  • 도구가 유효한 읽기와 빈 읽기 모두에 success: true를 반환해 모델은 빈 파일을 읽고 있다는 사실을 알 수 없었음
  • 빈 결과를 보완하려고 호출을 더 많이 수행하면서 결과 품질까지 나빠짐

• 프롬프트와 strict 모드로 해결되지 않은 문제

  • 도구 설명에 사용하지 않는 매개변수를 생략하라는 지시를 넣어도 25개가 모두 생성됨
  • 각 속성에 OPTIONAL, omit if unused를 붙여도 동작은 달라지지 않음
  • OpenAI의 strict 모드에서도 같은 결과가 나왔으며, 이를 도입하려면 모든 스키마에서 pattern, format, 배열 크기 검증을 제거해야 했음
  • 이 동작은 모델이 함수 호출을 생성하는 방식에서 나오므로 프롬프트 대신 스키마를 변경함

• 프로바이더 경계의 스키마 변환

  • OpenAI 계열 모델에는 모든 선택 속성을 anyOf: [T, null] 형태의 필수·nullable 속성으로 다시 작성함
  • 모델은 사용하지 않는 매개변수를 명시적인 null로 채우고, 공유 도구 호출 경계에서 검증하기 전에 null을 제거함
  • 도구 구현은 바꾸지 않고 모델용 스키마에서만 사용하지 않는 값을 표현할 수 있도록 함
  // 변경 전: 25개 키가 모두 임의 값으로 채워짐 { "action": "read", "file_paths": ["..."], "offset": 0, "timeout": 120000 } // 변경 후: 실제 값 4개와 null 21개를 보내고, 도구 실행 전에 null을 제거함 { "action": "read", "file_paths": ["..."], "offset": null, "timeout": null }
  • 변경 후 빈 파일 읽기는 52%에서 0% 로 떨어짐
  • 같은 작업에 필요한 도구 호출 수도 약 30% 줄어 빈 결과를 반복해서 읽는 동작이 사라짐

OpenAI 방식에 맞춘 프롬프트 캐싱

• 두 프로바이더 모두 프롬프트 캐싱을 제공하지만 구현 방식은 서로 다름
• 이 차이를 반영하기 전에는 GPT-5.6이 Opus보다 약 50% 비싸게 보였지만, 원인은 모델 가격이 아닌 캐시 구성이었음

• Anthropic의 조직 단위 캐시

  • 에이전트 프롬프트는 도구 스키마와 핵심 시스템 프롬프트로 구성된 약 29,000토큰의 정적 접두부로 시작하며 모든 대화에서 동일함
  • Claude에서는 cache_control로 캐시 breakpoint를 표시하고 접두부를 조직 전체에서 공유함
  • 어떤 워크스페이스의 대화든 하나의 공유 항목을 사용할 수 있고, 키별 처리량 제한도 없음
  • 캐시 적중률은 92~96%임

• GPT-5.6에서 달라진 캐시 동작

  • 이전 GPT 모델은 암묵적으로 부분 접두부 일치를 캐시했지만, GPT-5.6은 부분 접두부 일치를 제거함
  • 암묵적 캐시는 최신 메시지를 기준으로 전체 프롬프트 항목을 만들기 때문에, 동일한 29,000토큰 정적 접두부를 공유하는 새 대화도 첫 호출에서는 캐시 적중률이 0%임
  • 이에 따라 대화마다 접두부 전체가 미캐시 요금으로 다시 청구됨
  • 애플리케이션의 캐시 사용 여부와 관계없이 GPT-5.6은 모든 미캐시 프롬프트에 1.25배 캐시 쓰기 할증을 적용함

• 명시적 캐시 키의 제약

  • 명시적 캐싱에는 prompt_cache_breakpoint와 필수 prompt_cache_key가 필요함
  • 키도 캐시 정체성에 포함되므로 동일한 프롬프트라도 키가 다르면 적중하지 않음
  • 각 키는 분당 약 15개 요청을 처리하는 캐시 노드에 매핑되며, 이를 넘으면 OpenAI가 독립적인 콜드 캐시를 가진 다른 노드로 트래픽을 분산함
  • 따라서 어떤 단위로 키를 지정할지가 핵심 설계 결정이 됨
  • 대화별 키: 새 대화가 공유 접두부를 적중하지 못해 첫 호출 적중률이 0%였음
  • 전역 키 하나: 모든 요청이 한 노드로 해시되며, 프로덕션 트래픽이 15 rpm을 넘으면 콜드 노드로 넘침
  • 워크스페이스별 키: 고객 워크스페이스의 모든 대화가 항목을 공유하면서도 키별 트래픽은 낮게 유지됨

• 워크스페이스 단위 계층형 캐시

  • 실제 구성은 ws:{workspaceId} 형태의 워크스페이스 단위 키를 사용하고 시스템 프롬프트를 breakpoint 계층으로 나눔
  • 항목 A는 도구와 정적 접두부를 담아 세션의 첫 호출 비용을 줄임
  • 항목 B는 정적 접두부에 워크스페이스 컨텍스트를 더함
  • 항목 C는 첫 턴부터 최신 메시지까지 이어지는 세션별 전체 프롬프트 체인임
  • 워크스페이스 메모리가 바뀌면 항목 B는 빗나가지만 항목 A는 계속 적중해, 29,000토큰 전체가 아닌 변경된 컨텍스트 크기만 새로 씀
  • 항목 C는 프롬프트가 엄격한 추가 전용 구조이므로 세션 안에서 OpenAI의 암묵적 전체 프롬프트 체인을 활용함
  • OpenAI의 키 파티셔닝 때문에 정적 접두부를 워크스페이스 사이에서 공유할 수 없음
  • 반면 Anthropic은 키 파티셔닝 없는 조직 단위 캐시를 사용해 접두부 공유가 가능함
  • GPT-5.6에서는 각 워크스페이스가 유휴 시간 구간마다 29,000토큰을 한 번 콜드 쓰기하며, 비용은 약 $0.18임
  • 이 비용은 범위가 제한돼 있고 예측 가능함

• 캐시 수정 결과

  • 첫 호출 캐시 적중률은 약 0%에서 83.7% 로 상승함
  • 전체 미캐시 입력 토큰은 28% 감소함
  • GPT-5.6의 평가 제품군당 비용은 Opus보다 낮아졌으며, 초기 비용 격차 전체가 잘못된 캐시 구성에서 발생함
  • 한 모델만 콜드 캐시로 시작한 상태에서 수행한 모델 간 비용 비교는 유효하지 않음

추론 재생을 자체 완결형으로 변경

• GPT-5.6 Responses API는 기본적으로 이전 턴의 추론을 서버 측 항목 참조로 재생하며, 프로덕션 대화에서 간헐적으로 Item 'rs_...' not found 오류가 발생함
• store: false를 설정하면 SDK가 암호화된 추론 콘텐츠를 요청하고, 서버 상태를 가리키는 포인터 대신 자체 완결형 blob을 재생함
• 애플리케이션이 보내는 바이트가 추가 전용 구조여도 서버 측 추론 상태가 유효 프롬프트를 바꿀 수 있음
• 평가 하네스와 도구 스키마, 프롬프트 캐시, 추론 재생을 모두 수정한 GPT-5.6 Sol은 Ploy의 프로덕션 기본 모델로 운영 중임