2026년 7월 14일 · 4² AI 뉴스레터
AI 에이전트, GPT-5.6으로 업그레이드: 비용 절감
ploy.ai
파이랩 정리
AI 에이전트의 GPT-5.6으로의 업그레이드
오늘부터 Ploy의 에이전트는 OpenAI가 오늘 아침에 출시한 모델 패밀리의 주력 모델인 GPT-5.6 Sol을 사용합니다. 몇 달 동안, Claude Opus를 대체할 모델을 찾지 못했지만, GPT-5.6 Sol은 그 기준을 충족했습니다. 직접 비교 평가 후, 우리는 모든 Ploy 작업 공간에 기본 모델로 설정했습니다. Ploy의 에이전트는 마케팅 웹사이트를 구축하고 편집합니다. 페이지를 계획하고, 코드베이스를 읽고, 컴포넌트를 작성하며, 이미지를 생성하고, 작업의 스크린샷을 찍고, 완료 시점을 결정합니다. 우리는 모든 최신 릴리스를 이 작업 부하에 대해 테스트합니다. Opus가 기본 모델로 자리 잡은 4개월 동안(처음에는 Opus 4.7, 그 다음에는 4.8), 테스트한 어떤 모델도 이를 능가하지 못했습니다. GPT-5.6은 처음으로 이를 능가한 모델입니다. 첫 번째 평가 실행에서 여러 실패 모드가 드러났지만, 강력한 결과도 나왔습니다. 완료된 빌드는 벽시계 시간의 절반 이하로 줄었고, 비용은 27% 절감되었으며, 기존 모델과 동등하거나 그 이상의 점수를 기록했습니다. 이러한 결과는 마이그레이션 작업을 정당화했습니다.
평가 하니스 수정
우리는 Vercel의 AI SDK를 사용하지만, Claude Opus 4.8에서 GPT-5.6 Sol로 전환하면서 스택 전반에 걸쳐 제공자별 가정을 노출했습니다. 제공자들은 도구 인수 채우기, 프롬프트 캐싱, 턴 간의 추론 재생 방식에서 차이가 있습니다. 우리는 평가 하니스를 먼저 수정하고, 도구 스키마, 프롬프트 캐싱, 추론 재생을 순차적으로 수정했습니다.
Step 0: 하니스를 신뢰하기 전에 수정
우리의 평가 스위트는 프로덕션 에이전트를 고정 작업 공간에 대해 실행합니다. "홈페이지를 처음부터 구축하기"에서 "이 복제 요청이 실행하기에 안전한가"에 이르기까지 수백 가지 사례를 다룹니다. 빌드 사례의 경우, 시각적 심판이 참조 디자인에 대해 10개의 이진 검사를 실행합니다. 또한 콘텐츠 검사, 도구 경로 검사, 파일 주장을 실행합니다. 모든 실패를 도구 호출과 모델 텍스트를 포함한 전체 추적에 대해 분류합니다. 첫 번째 크로스 모델 실행에서 평가 하니스의 문제가 드러났습니다. 우리의 도구 호출 예산은 Opus의 순차 스타일에 맞춰져 있었습니다. GPT-5.6은 병렬 호출을 수행하여 올바르게 해결한 사례에서 예산을 초과했습니다. 우리의 평가 실행자는 또한 Opus가 거의 사용하지 않았던 배치 파일 읽기를 지원하지 않았으며, GPT-5.6은 자주 사용했습니다. 첫 번째 실행에서 발생한 원시 실패의 약 3분의 1은 모델 동작이 아닌 하니스 가정에서 비롯되었으며, 이러한 실패는 고르지 않게 분포되었습니다. 도전자를 기존 모델과 비교 평가할 때, 통과율을 신뢰하기 전에 추적을 분류하세요. 그렇지 않으면 평가가 새로운 모델을 기존 모델처럼 행동하도록 보상하게 됩니다.
벤치마크 결과
하니스를 수정한 후, 우리는 에이전트가 브랜드의 홈페이지를 참조 디자인에 맞춰 재구축하는 리디자인 스위트를 다시 실행했습니다. 평균 완료 빌드 결과는 다음과 같습니다:
-
Claude Opus 4.8 (n=11)
- 비용: $3.06
- 벽시계 시간: 8분 00초
- 입력 토큰: 2.60M
- 출력 토큰: 33.0K
- 시각적 점수: 0.936
-
GPT-5.6 (n=10)
- 비용: $2.22
- 벽시계 시간: 3분 42초
- 입력 토큰: 1.70M
- 출력 토큰: 17.1K
- 시각적 점수: 0.970
GPT-5.6은 페이지를 2.2배 더 빠르게 완료하고, 비용은 27% 절감했으며, 출력 토큰은 절반 정도 사용했습니다. 또한 코드도 덜 작성했습니다. 예를 들어, Opus는 17,957자 길이의 globals.css를 생성했으며, 174개의 CSS 변수를 포함했지만 대부분 사용되지 않았습니다. 반면, GPT-5.6은 2,508자와 45개의 변수를 사용하여 비교 가능한, 때로는 더 나은 렌더링 페이지를 생성했습니다.
디자인 품질과 일관성
GPT-5.6은 깔끔하고 그리드화된 레이아웃을 잘 처리하지만, 강력한 방향성이 없으면 그 스타일로 수렴하는 경향이 있습니다. Opus 4.8에 맞춰 설계된 이전 하니스에서는 기존 디자인 시스템을 무시하고 깔끔하지만 일반적인 출력을 생성했습니다. 여기서 우리가 한 변화는 별도의 게시물로 다룰 가치가 있습니다. 우리의 디자인 및 엔지니어링 팀은 GPT-5.6이 프로덕션에서 요구하는 브랜드 준수 기준을 충족할 때까지 방향성을 개선했습니다.
Step 1: 도구 호출 확인
우리 에이전트의 코드 도구는 25개의 최상위 매개변수를 가지고 있습니다. 그 중 하나인 action은 필수이며, 나머지는 선택 사항입니다. Claude는 사용하는 두세 개의 매개변수만 보내고 나머지는 생략합니다. GPT-5.6은 모든 호출에서 25개를 모두 보내며, 사용되지 않는 매개변수에 offset: 0, timeout: 120000, siteId: "00000000-0000-0000-0000-000000000000"와 같은 그럴듯한 값을 채웁니다. 우리는 이 패턴을 3일간의 프로덕션 코드(읽기) 추적에서 확인했습니다.
- 모델 호출
- GPT-5.6: 6,635 (100%)
- Claude Opus 4.8: 2,898 (0.1%)
- Claude Sonnet 5: 1,933 (0%)
장황함이 문제는 아니었습니다. 파일 읽기 구현은 발명된 값과 의도된 값을 구별할 수 없었습니다. offset: 0을 실제 인수로 처리하여 GPT-5.6의 파일 읽기의 52%에서 64%가 빈 상태로 반환되었습니다. 도구는 유효한 읽기와 빈 읽기에 대해 모두 success: true를 반환했기 때문에 모델은 빈 파일을 읽고 있다는 것을 알 수 없었습니다. 이는 더 많은 호출과 더 나쁜 결과로 이어졌습니다. 프롬프트로는 이 문제를 해결할 수 없었습니다. "사용되지 않는 매개변수를 생략하라"는 도구 설명 지시에도 불구하고 25개의 매개변수가 모두 생성되었습니다. OpenAI의 엄격한 모드를 사용해도 동일한 동작이 측정되었으며, 이를 채택하려면 모든 스키마에서 패턴, 형식, 배열 경계 유효성 검사를 제거해야 했습니다. 이 동작은 모델이 함수 호출을 생성하는 방식에서 비롯되므로 스키마를 변경했습니다. 작동하는 수정은 제공자 경계에서 스키마 변환이었습니다. OpenAI 계열 모델의 경우, 모든 선택적 속성을 필수이지만 null이 가능한 것으로 재작성합니다. 이는 사용되지 않는 매개변수에 대해 명시적인 값을 모델에 제공합니다. 그런 다음, 도구 실행 경계에서 유효성 검사 전에 null을 제거하여 도구 구현이 변경되지 않도록 합니다. 모델은 사용되지 않는 값을 나타내는 스키마를 보지만, 도구는 이전과 동일한 입력을 받습니다.
// Before: 25 keys, every one carrying an invented value
{
"action": "read",
"file_paths": [...],
"offset": 0,
"timeout": 120000,
...
}
// After: 25 keys, 4 real values, 21 explicit nulls (stripped before the tool runs)
{
"action": "read",
"file_paths": [...],
"offset": null,
"timeout": null,
...
}
변경 후, 빈 파일 읽기는 52%에서 0%로 줄었습니다. 에이전트는 또한 동일한 작업에 대해 약 30% 적은 도구 호출을 사용했습니다.
Step 2: 프롬프트 캐싱 재구축
두 제공자는 "프롬프트 캐싱"을 제공하지만 구현은 다릅니다. 차이를 고려하기 전에는 GPT-5.6이 Opus보다 약 50% 더 비싸 보였습니다. 우리의 캐시 구성 때문에 이러한 차이가 발생했습니다. 모델 가격은 문제가 없었습니다. 에이전트의 프롬프트는 약 29K 토큰의 정적 접두사(도구 스키마와 핵심 시스템 프롬프트 포함)로 시작하며, 모든 대화에 대해 동일합니다. Claude에서는 cache_control로 캐시 중단점을 표시하며, 접두사는 전체 조직에 걸쳐 캐시됩니다. 모든 작업 공간의 대화는 하나의 공유 항목을 사용할 수 있으며, 키당 처리량 예산이 없습니다. 캐시 적중률은 92%에서 96% 사이입니다.
GPT-5.6은 다른 OpenAI 캐싱 모델을 사용합니다. 이전 GPT 모델은 암시적 부분 접두사 일치를 캐시했습니다. GPT-5.6은 부분 접두사 일치를 제거하여, 암시적 캐싱이 이제 최신 메시지를 키로 하는 전체 프롬프트 항목을 생성합니다. 29K 정적 접두사를 공유하는 새로운 대화는 0%를 캐시했습니다. 각 대화는 전체 접두사를 캐시되지 않은 요금으로 다시 청구했습니다. GPT-5.6은 또한 애플리케이션이 캐싱을 사용하든 말든 모든 캐시되지 않은 프롬프트에 1.25배의 캐시 쓰기 할증을 적용합니다. 명시적 메커니즘은 prompt_cache_breakpoint 마커와 필수 prompt_cache_key를 사용합니다. 키는 캐시 정체성의 일부이므로, 다른 키를 가진 동일한 프롬프트는 캐시 적중을 생성하지 않습니다. 각 키는 약 15개의 요청을 처리할 수 있는 캐시 노드에 매핑되며, OpenAI는 독립적인 콜드 캐시를 가진 다른 노드로 트래픽을 분산합니다. 주요 설계 결정은 어떤 엔티티가 키의 범위를 지정해야 하는가입니다.
- 대화별 키: 새로운 대화는 공유 접두사에 적중하지 않습니다. 이 구성으로 첫 번째 호출 적중률은 0%였습니다.
- 전역 키: 모든 요청이 하나의 캐시 노드로 해시됩니다. 프로덕션 트래픽이 15 rpm 예산을 초과하고, 요청이 콜드 노드로 넘칩니다.
- 작업 공간별 키: 고객 작업 공간의 모든 대화가 항목을 공유하면서 키당 트래픽이 낮게 유지됩니다.
우리는 작업 공간 범위의 키를 제공하고, 시스템 프롬프트를 중단된 레이어로 분할하여 Anthropic에서 이미 사용한 구조를 반영합니다.
request ──► hash(prompt head + prompt_cache_key) ──► cache node (~15 req/min per key)
│ ┌──────────────────────────────────────────────────────┴───────────────┐
│ entries on the node, all namespaced by key ws:{workspaceId} │
│ │
│ [ tools + static prefix ]······················ A every session │
│ [ tools + static prefix + workspace context ]·· B same context │
│ [ ····················· + turn 1 + … + latest ] C this session │
└────────────────────────────────────────────────────────────────────────┘
Entry A는 세션의 첫 번째 호출 비용을 줄입니다. 작업 공간 메모리가 변경되면 요청이 Entry B에 적중하지 않지만 여전히 Entry A에 적중한 다음 새로운 Entry B를 작성합니다. 이는 전체 29K 접두사를 다시 청구하는 대신 컨텍스트 크기의 쓰기 한 번만 필요합니다. Entry C는 OpenAI의 암시적 전체 프롬프트 체인으로, 우리의 프롬프트가 엄격하게 추가만 가능하기 때문에 세션 내에서 작동합니다. OpenAI의 키 파티셔닝은 정적 접두사의 작업 공간 간 공유를 방지합니다. Anthropic은 키 파티셔닝 없이 조직 범위의 캐시를 사용하기 때문에 접두사를 공유할 수 있습니다. GPT-5.6에서는 모든 작업 공간이 유휴 창당 약 $0.18의 29K 콜드 쓰기 비용을 지불합니다. 비용은 제한적이고 예측 가능합니다. 변경 후, 첫 번째 호출 캐시 적중률은 약 0%에서 83.7%로 증가했으며, 전체 캐시되지 않은 입력 토큰은 28% 감소했고, GPT-5.6의 스위트당 비용은 Opus보다 낮아졌습니다. 캐시 잘못 구성은 우리가 측정한 전체 비용 차이를 설명했습니다. 모델 간 비용 비교는 하나의 모델이 콜드 캐시로 시작할 때 유용하지 않습니다.
Step 3: 추론 재생을 독립적으로 만듦
추론 재생은 프로덕션 대화에서 간헐적인 실패를 초래했습니다. GPT-5.6의 Responses API는 기본적으로 서버 측 항목 참조로 이전 턴 추론을 재생하며, 우리의 대화는 때때로 Item 'rs_...' not found 오류로 실패했습니다. store: false를 설정하면 SDK가 암호화된 추론 콘텐츠를 요청하고 서버 상태에 대한 포인터 대신 자체 포함된 블롭을 재생합니다. 또한 서버 측 추론 상태가 애플리케이션에서 보낸 바이트가 추가만 가능하더라도 효과적인 프롬프트를 변경할 수 있다는 것을 배웠습니다.
GPT-5.6 Sol의 프로덕션 실행
GPT-5.6은 오늘 출시되었으며 이미 Ploy에서 라이브로 사용되고 있습니다. ploy.ai에서 무료로 시작하여 웹사이트를 구축하고 4분 미만의 빌드가 어떤 모습인지 확인할 수 있습니다. Ploy는 웹사이트와 캠페인을 계획, 구축, 게시 및 최적화하는 AI 레이어입니다. 새벽 2시에 캐시 노드 팬 아웃을 디버깅하는 것이 재미있어 보인다면, 우리는 채용 중입니다.