AI 모델 교체가 코드 한 줄로 끝나지 않는 이유

AI 모델 교체가 코드 한 줄로 끝나지 않는 이유

AI 뉴스 썸네일

Ploy가 웹사이트 제작 AI 에이전트의 기본 모델을 Claude Opus 4.8에서 GPT-5.6 Sol로 바꿨어요. 같은 홈페이지 재구축 작업에서 평균 실행 시간은 8분에서 3분 42초로 줄었고, 평균 비용도 3.06달러에서 2.22달러로 낮아졌어요. 다만 이 수치는 모델 이름만 바꿔 얻은 결과가 아니에요. 평가 기준과 도구 스키마, 입력 캐시, 턴 간 추론 전달 방식을 새 모델에 맞게 손본 뒤 나온 값이에요. 1

핵심 요약

구분	확인된 변화	운영할 때 볼 점
속도와 비용	평균 8분에서 3분 42초, 3.06달러에서 2.22달러로 개선됐어요	완료된 빌드가 Opus 11건, GPT-5.6 10건이라 작업 특성과 표본을 함께 봐야 해요
도구 호출	선택 필드를 필수·nullable로 바꾸자 빈 파일 읽기가 0%로 줄었어요	같은 JSON 스키마도 모델마다 채우는 방식이 달라요
입력 캐시	첫 호출 적중률이 0%에서 83.7%로 올랐어요	제공사마다 캐시 범위와 키별 처리량 구조가 달라요
결과 품질	시각 점수가 0.936에서 0.970으로 올랐어요	GPT-5.6은 별도 유도가 약하면 깔끔하지만 평범한 디자인으로 모이는 경향이 있었어요

1. GPT-5.6 전환에서 성능보다 먼저 고친 것

Ploy의 AI 에이전트는 마케팅 웹사이트를 계획하고 코드베이스를 읽은 뒤 컴포넌트와 이미지를 만들어요. 완성된 화면을 직접 촬영해 결과도 확인해요. 회사는 이 작업을 기준으로 새 모델을 비교했는데, 첫 결과의 약 3분의 1은 모델 문제가 아니라 기존 Claude의 동작 방식에 맞춰진 평가 환경에서 생겼어요. GPT-5.6은 파일을 병렬로 읽거나 여러 파일을 한 번에 요청했지만, 기존 호출 예산과 실행기는 이런 방식을 제대로 반영하지 못했어요. 점수 기준이 빠진 사례에 1.0이 자동 적용돼 시각 점수 0.98을 받은 결과가 실패로 처리되기도 했어요. 2

평가 조건을 바로잡은 뒤에는 차이가 뚜렷했어요. GPT-5.6은 완료된 빌드당 평균 3분 42초가 걸렸고 Opus 4.8은 8분이 걸렸어요. 입력 토큰은 260만 개에서 170만 개로, 출력 토큰은 3만 3,000개에서 1만 7,100개로 줄었어요. 한 비교 사례에서는 Opus가 CSS 변수 174개와 17,957자짜리 전역 CSS를 만든 반면 GPT-5.6은 변수 45개와 2,508자로 비슷하거나 더 나은 화면을 만들었어요. 다만 비교한 완료 빌드는 각각 11건과 10건이에요. 모든 종류의 AI 작업에서 같은 격차가 난다고 일반화하기에는 표본과 작업 범위가 좁아요.

728x90

가장 큰 운영 문제는 선택 매개변수에서 나왔어요. Ploy의 코드 도구는 25개 속성 중 `action`만 필수였어요. Claude는 필요한 값 2~3개만 보냈지만 GPT-5.6은 사용하지 않는 속성에도 `offset: 0`이나 임의의 식별자를 채웠어요. 이 값들이 실제 요청으로 처리되면서 파일 읽기의 52~64%가 빈 결과를 반환했어요. 도구는 빈 결과에도 성공 상태를 돌려줬고, 모델은 같은 파일을 되풀이해 읽었어요.

설명 문구를 더 붙이거나 strict 모드를 켜는 방식으로는 해결되지 않았어요. Ploy는 OpenAI 계열 모델에 전달하는 선택 속성을 모두 필수로 만들되 `null`을 허용했어요. 실행 직전에 `null`만 제거하자 빈 파일 읽기가 0%로 내려갔고, 같은 작업의 도구 호출 수도 약 30% 줄었어요. 모델이 스키마를 어떻게 해석하는지 관찰하고, 사용하지 않는 값을 안전하게 표현할 방법을 제공한 셈이에요.

비용 비교도 캐시 구성을 고친 뒤 뒤집혔어요. 기존 설정에서는 GPT-5.6이 Opus보다 약 50% 비싸게 측정됐어요. Ploy는 워크스페이스별 캐시 키와 계층형 중단점을 적용했어요. 그 결과 첫 호출 캐시 적중률은 0%에서 83.7%로 올랐고, 캐시되지 않은 입력 토큰은 28% 줄었어요. Anthropic은 조직 단위로 정적 접두부를 공유할 수 있지만 OpenAI 방식은 키 파티셔닝과 키별 처리량을 고려해야 했어요. 같은 입력을 보내도 제공사의 캐시 구조가 다르면 비용표만으로 실제 지출을 비교하기 어려워요.

왜 중요한가요

프로덕션 AI 에이전트에서 모델 교체 범위는 API의 모델명보다 넓어요. 새 모델이 병렬 호출을 선호하는지, 선택 속성을 어떤 값으로 채우는지, 입력 캐시가 어느 범위에서 재사용되는지까지 실행 환경에 영향을 줘요. 기존 모델에 맞춘 호출 횟수와 점수 기준을 그대로 두면 새 모델의 정상 동작을 실패로 오해할 수 있어요. 반대로 한쪽만 따뜻한 캐시를 쓰는 비교에서는 비용 차이를 모델 가격 차이로 잘못 읽을 수 있어요. 2

도입 순서도 구체적으로 잡을 수 있어요. 먼저 두 모델의 전체 실행 기록을 비교해 평가 실패와 실행기 실패를 나눠야 해요. 다음으로 선택 매개변수, 빈 결과, 재시도 횟수를 모델별로 집계해요. 비용은 첫 요청과 이후 요청을 나눠 캐시 적중률과 함께 봐야 해요. 마지막에는 기능 플래그로 일부 작업부터 전환하고, 실패율과 브랜드 준수 같은 제품 품질을 실제 트래픽에서 확인하는 편이 안전해요.

Ploy의 수치만 보고 GPT-5.6이 모든 작업에서 더 낫다고 결론 내리기는 어려워요. 이번 사례가 보여주는 실용적인 교훈은 따로 있어요. 모델을 바꿀 때는 모델과 도구 계약, 평가 기준, 캐시 정책을 한 묶음으로 점검해야 해요. 그래야 속도와 비용 개선이 실제 모델 차이인지, 주변 설정을 고친 효과인지 구분할 수 있어요.

참고 자료

1. 프로덕션 AI 에이전트를 GPT-5.6으로 전환해 2.2배 빠르고 27% 저렴해진 과정 — GeekNews
2. Migrating a production AI agent to GPT-5.6 — Ploy