GPT-5.6 전환으로 2.2배 빨라지고 비용은 27% 절감한 AI 에이전트 운영 사례 분석

AI 모델 교체, 성능만 비교하면 충분할까?

AI 에이전트를 운영하는 기업이라면 새로운 모델이 출시될 때마다 "정말 바꿀 만한 가치가 있을까?"라는 고민을 하게 됩니다. 일반적으로는 모델의 성능과 비용만 비교하지만, 실제 프로덕션 환경에서는 평가 방식, 도구 호출 구조, 캐시 전략, 추론 처리 방식까지 함께 고려해야 합니다.

이번 사례에서는 AI 에이전트 플랫폼 Ploy가 프로덕션 마케팅 웹사이트를 생성하는 에이전트의 기본 모델을 Claude Opus 4.8에서 GPT-5.6 Sol로 전환한 과정을 소개합니다. 단순히 모델만 변경한 것이 아니라 평가 환경과 운영 구조를 함께 개선하면서 실행 속도는 2.2배 향상되고 비용은 27% 절감하는 결과를 얻었습니다.

이번 글에서는 모델 전환 과정에서 어떤 문제가 발견되었으며, 이를 어떻게 해결했는지 단계별로 살펴보겠습니다.

반응형

---

Ploy의 AI 에이전트는 어떤 작업을 수행할까?

Ploy의 AI 에이전트는 단순한 코드 생성기가 아닙니다. 하나의 프로덕션 웹사이트를 구축하기 위해 여러 단계를 자동으로 수행합니다.

주요 작업은 다음과 같습니다.

• 웹사이트 페이지 기획
• 프로젝트 코드베이스 분석
• 컴포넌트 및 이미지 생성
• 생성 결과 스크린샷 확인
• 작업 완료 여부 자동 판단

그동안 여러 모델을 평가했지만 Claude Opus를 대체할 수준의 모델은 없었습니다. 그러나 GPT-5.6 Sol이 동일한 작업을 대상으로 한 평가에서 처음으로 Claude Opus를 앞서면서 모든 워크스페이스의 기본 모델로 채택되었습니다.

모델 전환은 다음 순서로 진행되었습니다.

• 평가 하네스 수정
• 도구 스키마 개선
• 프롬프트 캐싱 구조 변경
• 추론 재생 방식 개선

즉, 모델만 교체한 것이 아니라 운영 환경 전체를 GPT-5.6에 맞게 최적화한 것입니다.

---

먼저 수정한 것은 모델이 아닌 평가 하네스

흥미로운 점은 처음부터 GPT-5.6의 성능이 낮았던 것이 아니라는 점입니다.

평가 과정에서 확인해 보니 상당수 실패 사례가 모델 때문이 아니라 평가 시스템의 기존 가정 때문이었습니다.

예를 들어 기존 평가 환경은 Claude Opus의 동작 방식에 맞춰져 있었습니다.

기존 평가 환경의 문제

• 순차적인 도구 호출을 기준으로 예산이 설정됨
• GPT-5.6의 병렬 호출이 정상 동작해도 예산 초과로 실패 처리
• GPT-5.6이 자주 사용하는 일괄 파일 읽기를 지원하지 않음
• 일부 데이터셋은 minScore가 없어 기본값 1.0이 자동 적용

그 결과 실제로는 충분히 우수한 결과를 생성했음에도 실패로 판정되는 사례가 발생했습니다.

대표적으로 Hero 영역 점수가 0.98임에도 평가 기준이 암묵적으로 1.0이 적용되어 실패 처리되었습니다.

이는 모델 성능 문제가 아니라 평가 기준 자체의 문제였습니다.

---

평가 환경 수정 후 성능 비교

평가 하네스를 수정한 후 동일한 홈페이지 구축 작업을 다시 수행한 결과는 다음과 같습니다.

항목	Claude Opus 4.8	GPT-5.6 Sol
평균 비용	$3.06	$2.22
평균 실행 시간	8분	3분 42초
입력 토큰	260만	170만
출력 토큰	33,000	17,100
시각 점수	0.936	0.970

결과를 보면 GPT-5.6은

• 실행 속도 2.2배 향상
• 비용 27% 절감
• 출력 토큰 약 절반 사용
• 시각 품질 향상

이라는 성과를 보였습니다.

또한 생성되는 코드도 훨씬 간결했습니다.

예를 들어 비교 사례에서는

Claude Opus는

• CSS 변수 174개
• globals.css 17,957자

를 생성한 반면,

GPT-5.6은

• CSS 변수 45개
• globals.css 2,508자

만으로도 비슷하거나 더 나은 렌더링 결과를 만들었습니다.

---

GPT-5.6에서 발견된 도구 호출 문제

모델 교체 과정에서 가장 큰 문제 중 하나는 도구(Function Calling) 호출 방식이었습니다.

Ploy의 code 도구는

• action만 필수
• 나머지 25개 매개변수는 선택 사항

으로 설계되어 있었습니다.

Claude는 필요한 2~3개의 매개변수만 전달했습니다.

반면 GPT-5.6은 호출할 때마다 선택 필드까지 모두 채웠습니다.

예를 들어 사용하지 않는 값도

• offset: 0
• timeout: 120000
• siteId: "00000000-0000-0000-0000-000000000000"

처럼 실제 값처럼 전달했습니다.

이 때문에 파일 읽기 기능은 이를 정상 입력으로 인식했고, 실제 파일 대신 빈 결과를 반환하는 문제가 발생했습니다.

프로덕션 로그에서는 GPT-5.6의 파일 읽기 중 52~64%가 빈 결과를 반환했습니다.

더 큰 문제는 도구가 빈 결과에도 success: true를 반환해 모델이 실패를 인식하지 못했다는 점입니다.

결국 동일한 파일을 반복해서 읽으면서 도구 호출 횟수까지 증가하게 되었습니다.

---

선택 매개변수를 nullable 구조로 변경

이 문제는 프롬프트 수정으로 해결되지 않았습니다.

다음과 같은 방법도 효과가 없었습니다.

• OPTIONAL 표시
• omit if unused 설명 추가
• strict 모드 적용

결국 Ploy는 도구 스키마 자체를 변경했습니다.

기존에는 선택 속성을 그대로 두었지만,

GPT-5.6용 스키마에서는 모든 선택 속성을

• 필수(required)
• nullable(anyOf: [T, null])

형태로 변경했습니다.

즉,

기존에는

offset: 0
timeout: 120000

처럼 임의 값이 전달되었다면,

변경 후에는

offset: null
timeout: null

이 전달되고, 실제 도구 실행 전에 null 값을 제거하도록 구성했습니다.

그 결과

• 빈 파일 읽기 52% → 0%
• 도구 호출 약 30% 감소

라는 개선 효과를 얻었습니다.

---

OpenAI에 맞춘 프롬프트 캐싱 전략

비용 문제 역시 모델 자체 때문이 아니었습니다.

초기에는 GPT-5.6이 Claude보다 약 50% 비싼 것으로 측정되었습니다.

하지만 원인을 분석해 보니 캐시 전략이 달랐습니다.

Claude는

• 조직 단위 캐시
• 약 29,000토큰의 정적 프롬프트 공유
• 캐시 적중률 92~96%

를 사용했습니다.

반면 GPT-5.6은

• 부분 접두부 캐시 제거
• 새 대화의 첫 호출 캐시 적중률 0%
• 동일한 정적 프롬프트를 매번 다시 계산

하는 구조였습니다.

---

워크스페이스 단위 캐시 구조 적용

이를 해결하기 위해 Ploy는 캐시 키를

ws:{workspaceId}

형태의 워크스페이스 단위로 변경했습니다.

또한 시스템 프롬프트를 계층적으로 분리하여

• 정적 접두부
• 워크스페이스 정보
• 세션 정보

를 각각 독립적으로 캐시하도록 구성했습니다.

그 결과

• 첫 호출 캐시 적중률 0% → 83.7%
• 미캐시 입력 토큰 28% 감소
• GPT-5.6 전체 비용이 Claude보다 낮아짐

이라는 결과를 얻었습니다.

즉, 초기 비용 차이는 모델이 아니라 캐시 구성 때문이었습니다.

---

추론 재생 방식도 함께 변경

Responses API 사용 과정에서는 간헐적으로

Item 'rs_...' not found

오류가 발생했습니다.

원인은 이전 추론을 서버 측 참조 방식으로 재사용했기 때문입니다.

이를 해결하기 위해

store: false

를 적용하여 서버 참조 대신 암호화된 자체 완결형 추론 데이터를 사용하도록 변경했습니다.

이렇게 변경하면서 서버 상태에 의존하지 않는 안정적인 추론 재생이 가능해졌습니다.

---

이번 사례가 주는 의미

이번 사례는 AI 모델을 교체할 때 단순히 벤치마크 점수만 비교해서는 안 된다는 점을 잘 보여줍니다.

실제 운영 환경에서는 다음 요소들이 모두 성능에 영향을 미칩니다.

• 평가 하네스의 기준
• 도구(Function Calling) 스키마
• 프롬프트 캐시 구조
• 추론 재생 방식
• 프로바이더별 API 특성

특히 기존 모델에 맞춰 설계된 운영 환경에서는 새로운 모델의 장점이 제대로 드러나지 않을 수 있습니다.

따라서 모델을 비교하기 전에 먼저 운영 환경이 특정 모델의 동작 방식에 맞춰져 있지는 않은지 점검하는 과정이 필요합니다.

---

728x90

Ploy의 GPT-5.6 Sol 전환 사례는 단순한 AI 모델 교체 사례가 아닙니다. 평가 방식과 도구 스키마, 캐시 전략, 추론 처리 구조까지 함께 개선하면서 프로덕션 환경에 최적화한 사례라고 볼 수 있습니다.

최종적으로 GPT-5.6은 홈페이지 생성 작업에서 실행 속도를 2.2배 높이고 비용을 27% 절감했으며, 시각적 품질까지 향상시키는 결과를 보여주었습니다.

이번 사례는 앞으로 AI 에이전트를 운영하거나 모델을 교체하려는 조직에게 중요한 시사점을 제공합니다. 새로운 모델의 성능을 정확하게 평가하려면 모델 자체뿐 아니라 기존 운영 환경의 가정과 구조를 함께 검토해야 한다는 점이 가장 큰 교훈이라고 할 수 있습니다.

300x250

https://ploy.ai/blog/migrating-a-production-ai-agent-to-gpt-5-6

Migrating a production AI agent to GPT-5.6 | Ploy