프로덕션 AI 에이전트를 GPT-5.6으로 마이그레이션: 2.2배 빠르고 27% 저렴

TL;DR Highlight

마케팅 웹사이트를 자동 생성하는 프로덕션 AI 에이전트를 Claude Opus 4.8에서 GPT-5.6 Sol로 전환한 실전 경험담으로, 단순 모델 교체가 아니라 eval 하네스, 툴 스키마, 캐싱, 추론 리플레이까지 손봐야 했던 과정을 구체적인 수치와 함께 정리했다.

Who Should Read

LLM 기반 에이전트를 프로덕션에서 운영 중이고 Claude에서 GPT 계열로 전환을 고려 중인 백엔드/풀스택 개발자. 특히 멀티 스텝 툴 호출이 포함된 복잡한 파이프라인을 운영하는 팀에게 유용하다.

Core Mechanics

Ploy는 마케팅 웹사이트를 자동으로 기획, 코드 작성, 이미지 생성, 스크린샷 후 완료 여부까지 판단하는 복잡한 AI 에이전트를 운영 중인데, 4개월간 Claude Opus(4.7 → 4.8)가 기본 모델이었고 다른 어떤 모델도 이를 이기지 못했다.
GPT-5.6 Sol로 전환한 결과, 동일한 작업(홈페이지 리디자인) 기준으로 Claude Opus 4.8 대비 평균 빌드 시간이 8분 → 3분 42초로 2.2배 단축됐고, 비용은 $3.06 → $2.22로 27% 절감됐다.
출력 토큰 수도 Opus 33.0K → GPT-5.6 17.1K로 약 절반 수준이었는데, 이는 GPT-5.6이 훨씬 간결한 코드를 작성하기 때문이다. 실제로 globals.css 파일의 경우 Opus는 17,957자에 CSS 변수 174개를 썼지만 GPT-5.6은 2,508자에 45개로도 동등하거나 더 나은 결과물을 냈다.
시각적 품질 점수(visual score)도 Opus 0.936 → GPT-5.6 0.970으로 오히려 GPT-5.6이 더 높았다. 다만 GPT-5.6은 깔끔하고 현대적인 그리드 레이아웃으로 수렴하는 경향이 있어, 프롬프트로 방향을 잡아주지 않으면 결과물이 균일해 보이는 단점이 있다.
첫 번째 eval(평가) 실행에서 실패처럼 보인 케이스의 약 1/3은 모델 문제가 아니라 eval 하네스(평가 실행 환경) 자체가 Claude에 맞게 암묵적으로 튜닝되어 있었던 게 원인이었다. 예를 들어, 툴 호출 예산이 Opus의 순차 호출 스타일에 맞춰져 있어서, 병렬로 툴을 호출하는 GPT-5.6이 예산을 초과한 것처럼 잘못 기록됐다.
또 다른 하네스 문제로, 파일 일괄 읽기(batched file reads)를 eval 실행기가 지원하지 않았는데, Opus는 이 기능을 거의 쓰지 않아서 문제가 없었지만 GPT-5.6은 상시 사용해서 오류가 발생했다. 새 모델을 평가할 때는 트레이스를 직접 뜯어봐야 진짜 모델 실패와 하네스 실패를 구분할 수 있다.
캐싱 방식의 차이도 중요한 마이그레이션 포인트였다. 이전 GPT 모델들은 prefix의 일부만 맞아도 캐시가 히트됐는데, GPT-5.6은 partial-prefix 매칭을 없애버려서 명시적으로 캐시 구조를 재설계해야 했다.
추론 리플레이(reasoning replay, 모델이 이전 턴의 자체 추론을 다음 턴에 다시 참고하는 방식)도 제공자마다 동작이 달라서, Claude에서 당연하게 동작하던 것이 GPT-5.6에서는 별도 처리가 필요했다. Vercel AI SDK 같은 범용 SDK를 써도 내부적으로는 제공자 특화 동작에 의존하고 있다는 점을 인식해야 한다.

Evidence

글 자체가 LLM이 작성한 것처럼 느껴진다는 지적이 있었다. 'Numbers like that buy a model a real migration effort' 같은 문구나 콜론/쉼표/마침표로 짧게 끊어 쓰는 스타일이 LLM 특유의 문체라는 댓글이 달렸고, 그럼에도 실용적인 인사이트는 담겨 있다는 의견도 함께 있었다.
Sol 대신 Luna(더 저렴한 GPT-5.6 하위 티어로 추정)를 툴 호출 부분에 활용하는 게 낫다는 의견이 있었다. Sol은 사람과의 대화나 에이전트 오케스트레이션에 적합하고, 실제 툴 작업에는 Luna가 더 효율적이며 Sol 1회 비용으로 Luna를 5회 실행할 수 있어 샘플 수를 늘리는 효과가 있다는 주장이었다.
Deepseek 기반의 Reasonix를 캐시 히트와 함께 사용하면 미국 프로바이더 기준으로도 요청 비용이 거의 0에 가깝다는 경험담이 공유됐다. 이는 GPT-5.6이 비용 면에서 최선이 아닐 수 있다는 시각을 제공한다.
마케팅 웹사이트 빌드에 Fable(별도 모델로 추정)이 Opus보다 훨씬 뛰어날 것 같다는 의견이 있었는데, 해당 댓글 작성자는 리고러스한 테스트 없이 직관으로 말하는 것임을 인정했다.
실제 사용자 입장에서는 GPT-5.6의 결과물보다 Claude Opus의 결과물을 더 선호한다는 댓글도 있었다. 기술적 지표(속도, 비용, 시각 점수)가 좋더라도 실제 마케팅 효과나 컨버전율은 다를 수 있다는 점에서 시사하는 바가 있다.

How to Apply

Claude에서 GPT 계열로 모델을 전환하기 전에, 기존 eval 하네스가 현재 모델의 행동 패턴(순차 툴 호출 vs 병렬 툴 호출, 파일 일괄 읽기 등)에 맞춰 암묵적으로 최적화되어 있지 않은지 먼저 점검해야 한다. 새 모델의 실패 케이스를 트레이스 레벨에서 직접 뜯어보면 하네스 문제와 모델 문제를 구분할 수 있다.
GPT-5.6으로 전환할 때 캐싱 전략을 반드시 재검토해야 한다. 이전 GPT 모델과 달리 partial-prefix 캐시 매칭이 없어졌기 때문에, 캐시 히트율을 유지하려면 프롬프트 구조와 캐시 키 설계를 명시적으로 다시 짜야 한다.
멀티 스텝 에이전트를 운영 중이라면 Sol(플래그십)을 모든 스텝에 쓰지 않고, 사람 응답 및 오케스트레이션은 Sol, 실제 툴 실행 작업은 Luna처럼 저렴한 하위 티어를 조합하는 방식으로 비용을 추가로 절감할 수 있다.
GPT-5.6의 결과물이 깔끔하고 모던한 스타일로 수렴하는 경향이 있으므로, 디자인 다양성이 중요한 서비스라면 시스템 프롬프트나 유저 프롬프트에 원하는 디자인 방향성을 명시적으로 기술해서 결과물이 균일해지지 않도록 스티어링해야 한다.

Terminology

eval harness모델 성능을 자동으로 평가하는 테스트 실행 환경. 쉽게 말해 모델용 QA 자동화 프레임워크로, 입력을 넣고 출력을 채점하는 과정을 자동화한 것이다.

wall-clock time사람이 시계로 재는 실제 경과 시간. CPU 연산 시간이나 토큰 수와 달리, 사용자가 실제로 기다리는 시간을 의미한다.

prompt cache같은 프롬프트 앞부분(prefix)이 반복될 때 다시 계산하지 않고 저장된 결과를 재활용하는 기능. API 비용과 응답 속도를 크게 줄일 수 있다.

reasoning replay멀티 턴 대화에서 모델이 이전 턴에 수행한 추론 과정을 다음 턴에 다시 참고하게 하는 방식. 에이전트가 긴 작업을 이어서 수행할 때 컨텍스트 일관성을 유지하는 데 쓰인다.

visual judge모델이 생성한 UI/디자인 결과물을 또 다른 모델이 사전에 정의된 기준(yes/no 질문)으로 평가하는 자동화 채점 방식.

tool schemaAI 에이전트가 호출할 수 있는 외부 도구(함수)의 입력/출력 형식을 정의한 명세. 모델이 올바른 인자를 넣어 도구를 호출하려면 이 스키마를 정확히 이해해야 한다.

Related Resources

원문: Migrating a production AI agent to GPT-5.6