핵심 요약
- 속도와 비용 동시 개선: 평균 실행 시간 8분→3분 42초(약 2.2배 단축), 단위 작업 비용 3.06달러→2.22달러(27% 절감), 시각 점수 0.970을 달성함.
- 회귀의 정체: GPT-5.6은 도구 호출 시 선택적 매개변수 25개를 임의 값으로 채워 파일 읽기의 52~64%가 빈 결과를 반환하는 회귀를 발생시킴.
- 엔지니어링 해법: 선택 필드를 필수이면서 nullable로 강제하는 스키마 보정과 평가 하네스 모델별 가정 보정으로 빈 읽기 비율을 0%로 낮추고 도구 호출 횟수도 약 30% 줄임.
모델 전환은 모델만 바꾸는 일이 아니라 평가 하네스와 도구 스키마를 함께 재설계하는 엔지니어링 프로젝트임을 Ploy 사례가 보여준다.
프로덕션 환경에서 LLM 기반 에이전트를 운영해 본 개발자라면 한 번쯤 “이 모델이 다른 모델에서도 똑같이 작동할까”라는 질문을 던져 봤을 것이다. Ploy의 기술팀이 마케팅 웹사이트 구축 에이전트의 기본 모델을 Claude Opus 4.8에서 GPT-5.6 계열로 교체하면서 얻은 정량 결과와 회귀 해결 과정이 바로 그 질문에 대한 현실적인 답을 제공한다.
서론 – 프로덕션 AI 에이전트, 모델을 갈아끼우는 일은 왜 어려운가
대부분의 팀은 모델 성능을 벤치마크 점수로 판단하지만, 실제 프로덕션에서는 도구 호출 형식, 시스템 프롬프트 응답성, 비용 곡선이 함께 묶여 작동한다. 같은 점수를 내는 두 모델이 운영 환경에서는 완전히 다른 결과를 만드는 경우가 흔하며, 이는 모델이 학습 단계에서 습득한 암묵적 가정이 도구 스키마의 암묵적 가정과 충돌하기 때문이다.
왜 한 모델의 성능이 다른 모델에서 재현되지 않는가
에이전트 프레임워크는 보통 모델의 응답을 JSON으로 파싱하고, 파싱 실패 시 재시도 로직으로 대응한다. 그러나 모델이 선택적 필드를 임의 값으로 채우거나 빈 배열을 반환하면 재시도 로직이 이를 정상 경로로 오인할 수 있어, 회귀가 누적 비용과 사용자 응답 시간으로 표면화된다. Ploy 팀은 이 지점에서 단순 모델 교체가 아닌 통합 엔지니어링이 필요하다고 판단한 것으로 보인다.
이번 사례가 시사하는 모델 전환의 핵심 리스크
핵심 리스크는 세 가지로 요약된다. 첫째, 도구 호출 형식의 미세한 차이, 둘째, 평가 하네스에 내장된 모델별 가정, 셋째, 비용 구조의 변화다. 이 셋이 동시에 어긋나면 단일 지표 개선이 전체 시스템의 품질 저하로 이어질 수 있다.
사례 개요 – Ploy의 에이전트와 모델 전환 전후 비교
Ploy는 마케팅 웹사이트를 자동 구축하는 에이전트를 운영하며, 이 워크플로에는 콘텐츠 생성, 레이아웃 결정, 자산 호출, 검증 단계가 포함된다. 팀은 기본 모델을 Claude Opus 4.8에서 GPT-5.6으로 전환하면서 세 가지 지표를 동시에 측정했다.
대상 에이전트와 워크로드 정의
대상 에이전트는 사용자 입력을 받아 다단계 도구 호출을 통해 정적 웹사이트를 생성하며, 한 사이트 생성당 평균 50회 이상의 도구 호출이 발생한다. 각 호출은 파일 읽기, 코드 생성, 외부 자산 참조 등으로 구성되며, 호출 빈도와 응답 길이가 비용과 직결된다.
Claude Opus 4.8에서 GPT-5.6으로의 전환 과정
전환은 일회성 스왑이 아니라 단계적 A/B 평가로 진행되었다. 동일 입력에 대해 두 모델을 병렬 실행하고, 산출물과 메타데이터를 평가 하네스로 수집해 비교했다. 이 과정에서 도출된 회귀가 다음 단계의 엔지니어링 작업을 정의했다.
핵심 지표 비교 – 실행 시간, 비용, 시각 점수
전환 전후의 핵심 지표는 다음과 같다.
- 평균 실행 시간: 8분 → 3분 42초 (약 2.2배 단축)
- 단위 작업당 비용: 3.06달러 → 2.22달러 (27% 절감)
- 시각 점수: 0.970으로 개선
특히 주목할 점은 시각 점수의 개선인데, 단순히 속도와 비용만 좋아진 것이 아니라 결과 품질도 동반 상승했다는 사실이다. 이는 GPT-5.6의 응답 일관성과 지시문 준수율이 도구 호출 단계에서 더 효과적으로 작동했음을 시사한다.
회귀 분석 – GPT-5.6의 빈 결과 문제와 원인
모델 전환 초기 단계에서 가장 먼저 발견된 문제는 도구 호출의 신뢰성 저하였다. 전환 직후 파일 읽기 도구의 호출 결과 중 절반 이상이 빈 페이로드로 돌아왔고, 이로 인해 후속 단계가 잘못된 입력으로 분기되는 현상이 관찰되었다.
선택적 매개변수 25개를 임의 값으로 채우는 현상
조사 결과 GPT-5.6은 도구 호출 시 정의된 선택적 매개변수 25개를 임의의 값으로 채워 넣는 경향이 있었다. 즉, 모델이 “값이 없어도 되는 필드”를 “임의 값을 채워 넣어야 하는 필드”로 해석한 것이다. 이로 인해 호출 자체는 성공으로 기록되지만 결과가 의미를 잃는 회귀가 발생했다.
파일 읽기 52~64%가 빈 결과를 반환한 의미
이는 단순한 응답 정확도 저하가 아니라 에이전트의 컨텍스트 인식 자체가 깨졌음을 의미한다. 빈 결과를 받은 후속 단계는 다음 도구 호출을 잘못된 가설 위에서 설계하게 되며, 결과적으로 사용자 응답에 도달할 때까지의 도구 호출 체인이 비효율적으로 길어진다. 호출 횟수 증가는 곧 비용 증가와 직결되므로 이 회귀는 단순한 품질 문제가 아니라 경제성 문제이기도 했다.
해결책 – 평가 하네스 보정과 스키마 재설계
Ploy 팀은 이 회귀를 두 축에서 동시에 해결했다. 하나는 모델의 행동을 측정하는 평가 하네스의 보정이고, 다른 하나는 도구 자체의 스키마 재설계였다. 이 두 작업은 서로를 전제로 하며, 어느 한쪽만 수행하면 효과가 반감된다.
평가 하네스의 모델별 가정 바로잡기
기존 평가 하네스는 Claude Opus 4.8의 응답 패턴에 최적화되어 있었다. 즉, “모델이 이 필드를 비워 두면 정말로 값이 없는 것”이라는 암묵적 가정이 평가 로직 전반에 박혀 있었다. GPT-5.6의 응답 특성을 반영하도록 평가 로직을 수정해 모델별 가정에 의존하지 않는 중립적 평가 구조로 재편했다.
선택 필드를 필수이면서 nullable로 강제하는 스키마 보정
핵심 기술적 해법은 의외로 단순했다. 도구 스키마에서 선택 필드를 “값을 안 채워도 되는 필드”가 아니라 “반드시 명시하되 null을 허용하는 필드”로 재정의한 것이다. JSON Schema 관점에서 이는 "type": ["string", "null"] 형태이며, 모델 입장에서 보면 “값이 없으면 null을 명시해야 한다”는 명확한 규약이 된다. 이 보정만으로 파일 읽기의 빈 결과 비율이 0%로 떨어졌다.
도구 호출 약 30% 감소로 이어진 이유
스키마 보정이 호출 횟수를 줄인 이유는 누적 효과 때문이다. 첫 호출의 결과가 정확해지면 후속 단계가 잘못된 가정 위에서 재시도할 필요가 없어지며, 도구 체인 전체의 깊이가 줄어든다. Ploy 팀은 이 과정에서 도구 호출 횟수가 약 30% 감소했음을 측정했다.
오픈소스화 – 통찰을 라이브러리로 공개하다
Ploy는 이 과정에서 얻은 평가 보정 로직과 스키마 패턴을 자사 라이브러리 형태로 공개했다. 이는 단순한 사례 공유가 아니라 다른 에이전트 팀이 유사한 회귀를 진단하고 해결할 수 있는 재사용 가능한 도구를 제공한다는 점에서 의미가 크다.
공개된 라이브러리의 구성과 재사용 포인트
공개된 자산에는 모델 중립적 평가 러너, 스키마 보정 유틸리티, 도구 호출 패턴 분석기가 포함된 것으로 보인다. 특히 스키마 보정 유틸리티는 기존 JSON Schema를 입력으로 받아 선택 필드를 nullable 필수 형태로 자동 변환하는 기능을 제공해, 다른 팀이 최소한의 변경으로 동일한 효과를 얻을 수 있게 한다.
다른 에이전트 팀이 참고할 체크리스트
- 평가 하네스가 특정 모델의 응답 패턴에 종속되어 있지 않은지 점검
- 도구 스키마의 선택 필드가 모델에 따라 어떻게 해석되는지 실험으로 확인
- 파일 읽기, 검색, 외부 API 호출 등 입력 의존 도구의 빈 결과 비율을 별도 지표로 추적
- 모델 전환 시 호출 횟수, 비용, 응답 시간의 삼각 지표를 동시에 측정
- 스키마 보정 효과를 A/B 실험으로 정량 검증
결론 – 모델 전환을 운영 프로세스로 만드는 법
이번 사례는 모델 전환을 “벤치마크 점수 비교”로 단순화하는 접근의 한계를 명확히 드러낸다. 실제 프로덕션에서는 모델, 평가 하네스, 도구 스키마가 하나의 시스템으로 묶여 있기 때문에, 어느 하나를 바꾸면 다른 요소의 가정을 다시 검증해야 한다. Ploy의 접근은 모델을 교체한 뒤 회귀를 발견하고, 평가 하네스와 스키마를 동시에 보정해 더 나은 결과로 도약한 점에서 엔지니어링의 모범 사례라 할 수 있다.
평가, 스키마, 비용의 삼각 균형
운영 관점에서 가장 중요한 것은 세 지표를 동시에 보는 시각이다. 실행 시간이 줄어도 비용이 늘거나, 비용이 줄어도 품질이 떨어지면 의미 있는 전환이 아니다. Ploy 사례는 세 지표가 동시에 개선된 첫 사례라기보다, 회귀를 제거한 다음 비로소 세 지표가 함께 움직이기 시작했다는 점이 더 정확하다.
한국 개발팀이 즉시 적용할 수 있는 액션 아이템
한국 개발팀이 이 사례를 그대로 옮길 때 우선순위는 다음과 같다. 첫째, 현재 운영 중인 에이전트의 도구 스키마에서 선택 필드를 재분류한다. 둘째, 평가 하네스가 특정 모델 가정에 의존하는지 코드 리뷰를 수행한다. 셋째, 파일 읽기와 같은 입력 의존 도구의 빈 결과 비율을 별도 메트릭으로 모니터링한다. 이 세 가지를 2주 안에 점검하면 모델 전환 시 동일한 회귀를 사전에 차단할 수 있을 것으로 분석된다.
핵심 포인트
- 모델 전환은 모델 교체만으로 끝나지 않으며 평가 하네스와 도구 스키마 보정이 함께 필요하다.
- GPT-5.6의 선택적 매개변수 임의 채움 현상은 nullable 필수 스키마로 차단할 수 있다.
- 스키마 보정은 회귀 제거를 넘어 도구 호출 횟수 약 30% 감소라는 추가 효율을 만든다.
- Ploy가 공개한 라이브러리는 다른 에이전트 팀이 유사한 문제를 진단하고 해결하는 기준으로 활용할 수 있다.
참고 자료: GeekNews – Ploy 기술 블로그 큐레이션, MarkTechPost – 멀티 에이전트 시스템 사례