프로덕션 AI 에이전트를 GPT-5.6으로 전환해 2.2배 빠르고 27% 저렴해진 과정

(ploy.ai)

1P by GN⁺ 6시간전 | ★ favorite | 댓글 1개

Ploy는 프로덕션 마케팅 웹사이트를 계획·구축·검증하는 에이전트를 Claude Opus 4.8에서 GPT-5.6 Sol로 전환하고 모든 워크스페이스의 기본 모델로 지정함
평가 하네스의 모델별 가정을 바로잡은 뒤 홈페이지 재구축 작업에서 평균 실행 시간이 8분에서 3분 42초로 줄었고, 비용은 $3.06에서 $2.22로 27% 낮아졌으며 시각 점수도 0.970으로 높아짐
GPT-5.6이 도구 호출의 선택적 매개변수 25개를 임의 값으로 모두 채우면서 파일 읽기의 52~64%가 빈 결과를 반환했으나, 선택 필드를 필수·nullable로 바꾸자 빈 읽기가 0%로 줄고 도구 호출도 약 30% 감소함
OpenAI와 Anthropic의 캐시 범위·처리량 구조 차이로 GPT-5.6이 처음에는 약 50% 비싸게 측정됐지만, 워크스페이스 단위 캐시 키와 계층별 breakpoint를 적용해 첫 호출 적중률을 0%에서 83.7%로 높이고 미캐시 입력 토큰을 28% 줄임
모델 교체의 비용과 성능은 모델 자체뿐 아니라 평가 예산, 도구 스키마, 캐시 구조, 추론 재생 방식에 좌우되므로 기존 모델에 맞춰진 프로바이더별 가정부터 찾아 수정해야 신뢰할 수 있는 비교와 안정적인 운영이 가능함

Claude Opus를 대체한 GPT-5.6 Sol

Ploy 에이전트는 프로덕션 마케팅 웹사이트의 페이지를 계획하고 코드베이스를 읽으며, 컴포넌트와 이미지를 생성하고 결과를 스크린샷으로 확인한 뒤 작업 완료 여부를 판단함
여러 달 동안 Claude Opus를 대체할 기준을 충족한 모델이 없었고, 기본 모델은 4개월 동안 Opus 4.7과 4.8 순서로 유지됨
GPT-5.6 Sol은 동일 작업을 대상으로 한 일대일 평가에서 처음으로 Opus를 앞서며 모든 Ploy 워크스페이스의 기본 모델이 됨
초기 평가에서도 완료된 빌드의 실행 시간은 절반 미만이었고 비용은 27% 낮았으며, 기존 모델과 같거나 높은 점수를 기록해 마이그레이션을 진행할 근거가 됨
Ploy는 Vercel AI SDK를 사용하지만, 모델 전환 과정에서 도구 인자 구성과 프롬프트 캐싱, 턴 간 추론 재생에 관한 프로바이더별 가정이 스택 전반에 남아 있음을 발견함
마이그레이션은 평가 하네스, 도구 스키마, 프롬프트 캐싱, 추론 재생 순으로 수정하며 진행됨

평가 수치를 믿기 전에 하네스부터 수정

평가 제품군은 프로덕션 에이전트를 고정 테스트 워크스페이스에서 실행하며, 홈페이지를 처음부터 구축하는 작업부터 복제 요청을 안전하게 실행할 수 있는지 판단하는 작업까지 수백 개 사례를 다룸
빌드 사례에서는 시각 판정기가 기준 디자인과 비교해 10개의 이진 검사를 수행함
- hero 영역이 화면 전체 폭을 채우는 사진 장면인지 검사함
- 주요 CTA가 pill 형태가 아닌 둥근 모서리의 직사각형인지 확인함
콘텐츠 검사와 도구 실행 경로 검사, 파일 단언도 함께 수행하며, 실패 시 도구 호출과 모델 텍스트를 포함한 전체 실행 추적을 검토함
기존 모델의 호출 방식에 맞춰진 제약
- 기존 도구 호출 예산은 Opus의 순차 호출 방식에 맞춰져 있었지만, GPT-5.6은 병렬 호출을 사용해 올바르게 문제를 해결한 사례에서도 예산을 초과함
- 평가 실행기는 Opus가 거의 사용하지 않던 일괄 파일 읽기를 지원하지 않았지만 GPT-5.6은 이를 자주 사용함
- 첫 실행에서 발생한 원시 실패의 약 3분의 1은 모델 동작이 아닌 하네스의 가정에서 비롯됐으며, 모델별로 고르게 분포하지도 않았음
- 도전 모델과 기존 모델의 실행 추적을 먼저 분류하지 않으면 새 모델이 기존 모델처럼 행동할수록 유리한 평가가 됨
암묵적인 점수 임계값
- minScore가 빠진 데이터셋은 아무 경고 없이 기본값 1.0을 물려받음
- 이 때문에 GPT-5.6은 hero 점수 0.98을 받고도 실패 처리됐고, Opus 역시 모든 개별 검사를 통과한 사례에서 실패로 판정됨
- 두 결과 모두 방어 가능한 디자인이었지만 모델이 아닌 암묵적 임계값 때문에 탈락함

수정된 벤치마크 결과

하네스를 고친 뒤 브랜드 홈페이지를 기준 디자인에 맞춰 다시 구축하는 평가 제품군을 재실행함

완료된 빌드당 평균	Claude Opus 4.8 (`n=11`)	GPT-5.6 (`n=10`)
비용	$3.06	$2.22
실행 시간	8분 00초	3분 42초
입력 토큰	260만	170만
출력 토큰	33,000	17,100
시각 점수	0.936	0.970

GPT-5.6은 페이지를 2.2배 빠르게 완성했고 비용은 27% 낮았으며, 출력 토큰도 약 절반만 사용함
생성한 코드의 양도 더 적었음
- 한 쌍의 비교 사례에서 Opus는 대부분 사용되지 않는 색상 계열을 포함해 CSS 변수 174개와 17,957자의 globals.css를 생성함
- GPT-5.6은 CSS 변수 45개와 2,508자를 사용하면서도 비슷하거나 더 나은 렌더링 결과를 냄
디자인 품질과 일관성
- GPT-5.6은 깔끔하고 격자가 촘촘한 레이아웃에 강하지만, 강하게 유도하지 않으면 해당 스타일로 수렴하는 경향이 있음
- Opus 4.8용으로 설계된 기존 하네스에서는 기존 디자인 시스템을 무시한 채 깔끔하지만 평범한 결과물을 자주 생성함
- 디자인팀과 엔지니어링팀이 모델 유도 방식을 개선한 뒤에는 프로덕션에 필요한 브랜드 준수 기준을 충족함

도구 호출의 선택적 매개변수 처리

에이전트의 code 도구에는 최상위 매개변수 25개가 있으며, action만 필수이고 나머지는 선택 사항임
Claude는 사용하는 매개변수 2~3개만 전송하지만 GPT-5.6은 호출마다 25개를 모두 보내며, 사용하지 않는 필드도 offset: 0, timeout: 120000, siteId: "00000000-0000-0000-0000-000000000000" 같은 그럴듯한 값으로 채움
3일간 수집한 프로덕션 code(read) 실행 추적에서도 같은 패턴이 나타남

모델	호출 수	25개 속성을 모두 포함한 호출
`gpt-5.6`	6,635	6,635건, 100%
`claude-opus-4.8`	2,898	4건, 0.1%
`claude-sonnet-5`	1,933	0건

빈 파일 읽기가 발생한 원인
- 문제는 단순히 인자가 장황하다는 데 있지 않고, 파일 읽기 구현이 모델이 임의로 만든 값과 사용자가 의도한 값을 구별할 수 없다는 데 있었음
- 구현은 offset: 0을 실제 인자로 처리했고, GPT-5.6 파일 읽기의 52~64%가 빈 결과를 반환함
- 도구가 유효한 읽기와 빈 읽기 모두에 success: true를 반환해 모델은 빈 파일을 읽고 있다는 사실을 알 수 없었음
- 빈 결과를 보완하려고 호출을 더 많이 수행하면서 결과 품질까지 나빠짐
프롬프트와 strict 모드로 해결되지 않은 문제
- 도구 설명에 사용하지 않는 매개변수를 생략하라는 지시를 넣어도 25개가 모두 생성됨
- 각 속성에 OPTIONAL, omit if unused를 붙여도 동작은 달라지지 않음
- OpenAI의 strict 모드에서도 같은 결과가 나왔으며, 이를 도입하려면 모든 스키마에서 pattern, format, 배열 크기 검증을 제거해야 했음
- 이 동작은 모델이 함수 호출을 생성하는 방식에서 나오므로 프롬프트 대신 스키마를 변경함
프로바이더 경계의 스키마 변환
- OpenAI 계열 모델에는 모든 선택 속성을 anyOf: [T, null] 형태의 필수·nullable 속성으로 다시 작성함
- 모델은 사용하지 않는 매개변수를 명시적인 null로 채우고, 공유 도구 호출 경계에서 검증하기 전에 null을 제거함
- 도구 구현은 바꾸지 않고 모델용 스키마에서만 사용하지 않는 값을 표현할 수 있도록 함
```
// 변경 전: 25개 키가 모두 임의 값으로 채워짐
{ "action": "read", "file_paths": ["..."], "offset": 0, "timeout": 120000 }

// 변경 후: 실제 값 4개와 null 21개를 보내고, 도구 실행 전에 null을 제거함
{ "action": "read", "file_paths": ["..."], "offset": null, "timeout": null }
```
- 변경 후 빈 파일 읽기는 52%에서 0% 로 떨어짐
- 같은 작업에 필요한 도구 호출 수도 약 30% 줄어 빈 결과를 반복해서 읽는 동작이 사라짐

OpenAI 방식에 맞춘 프롬프트 캐싱

두 프로바이더 모두 프롬프트 캐싱을 제공하지만 구현 방식은 서로 다름
이 차이를 반영하기 전에는 GPT-5.6이 Opus보다 약 50% 비싸게 보였지만, 원인은 모델 가격이 아닌 캐시 구성이었음
Anthropic의 조직 단위 캐시
- 에이전트 프롬프트는 도구 스키마와 핵심 시스템 프롬프트로 구성된 약 29,000토큰의 정적 접두부로 시작하며 모든 대화에서 동일함
- Claude에서는 cache_control로 캐시 breakpoint를 표시하고 접두부를 조직 전체에서 공유함
- 어떤 워크스페이스의 대화든 하나의 공유 항목을 사용할 수 있고, 키별 처리량 제한도 없음
- 캐시 적중률은 92~96%임
GPT-5.6에서 달라진 캐시 동작
- 이전 GPT 모델은 암묵적으로 부분 접두부 일치를 캐시했지만, GPT-5.6은 부분 접두부 일치를 제거함
- 암묵적 캐시는 최신 메시지를 기준으로 전체 프롬프트 항목을 만들기 때문에, 동일한 29,000토큰 정적 접두부를 공유하는 새 대화도 첫 호출에서는 캐시 적중률이 0%임
- 이에 따라 대화마다 접두부 전체가 미캐시 요금으로 다시 청구됨
- 애플리케이션의 캐시 사용 여부와 관계없이 GPT-5.6은 모든 미캐시 프롬프트에 1.25배 캐시 쓰기 할증을 적용함
명시적 캐시 키의 제약
- 명시적 캐싱에는 prompt_cache_breakpoint와 필수 prompt_cache_key가 필요함
- 키도 캐시 정체성에 포함되므로 동일한 프롬프트라도 키가 다르면 적중하지 않음
- 각 키는 분당 약 15개 요청을 처리하는 캐시 노드에 매핑되며, 이를 넘으면 OpenAI가 독립적인 콜드 캐시를 가진 다른 노드로 트래픽을 분산함
- 따라서 어떤 단위로 키를 지정할지가 핵심 설계 결정이 됨
- 대화별 키: 새 대화가 공유 접두부를 적중하지 못해 첫 호출 적중률이 0%였음
- 전역 키 하나: 모든 요청이 한 노드로 해시되며, 프로덕션 트래픽이 15 rpm을 넘으면 콜드 노드로 넘침
- 워크스페이스별 키: 고객 워크스페이스의 모든 대화가 항목을 공유하면서도 키별 트래픽은 낮게 유지됨
워크스페이스 단위 계층형 캐시
- 실제 구성은 ws:{workspaceId} 형태의 워크스페이스 단위 키를 사용하고 시스템 프롬프트를 breakpoint 계층으로 나눔
- 항목 A는 도구와 정적 접두부를 담아 세션의 첫 호출 비용을 줄임
- 항목 B는 정적 접두부에 워크스페이스 컨텍스트를 더함
- 항목 C는 첫 턴부터 최신 메시지까지 이어지는 세션별 전체 프롬프트 체인임
- 워크스페이스 메모리가 바뀌면 항목 B는 빗나가지만 항목 A는 계속 적중해, 29,000토큰 전체가 아닌 변경된 컨텍스트 크기만 새로 씀
- 항목 C는 프롬프트가 엄격한 추가 전용 구조이므로 세션 안에서 OpenAI의 암묵적 전체 프롬프트 체인을 활용함
- OpenAI의 키 파티셔닝 때문에 정적 접두부를 워크스페이스 사이에서 공유할 수 없음
- 반면 Anthropic은 키 파티셔닝 없는 조직 단위 캐시를 사용해 접두부 공유가 가능함
- GPT-5.6에서는 각 워크스페이스가 유휴 시간 구간마다 29,000토큰을 한 번 콜드 쓰기하며, 비용은 약 $0.18임
- 이 비용은 범위가 제한돼 있고 예측 가능함
캐시 수정 결과
- 첫 호출 캐시 적중률은 약 0%에서 83.7% 로 상승함
- 전체 미캐시 입력 토큰은 28% 감소함
- GPT-5.6의 평가 제품군당 비용은 Opus보다 낮아졌으며, 초기 비용 격차 전체가 잘못된 캐시 구성에서 발생함
- 한 모델만 콜드 캐시로 시작한 상태에서 수행한 모델 간 비용 비교는 유효하지 않음

추론 재생을 자체 완결형으로 변경

GPT-5.6 Responses API는 기본적으로 이전 턴의 추론을 서버 측 항목 참조로 재생하며, 프로덕션 대화에서 간헐적으로 Item 'rs_...' not found 오류가 발생함
store: false를 설정하면 SDK가 암호화된 추론 콘텐츠를 요청하고, 서버 상태를 가리키는 포인터 대신 자체 완결형 blob을 재생함
애플리케이션이 보내는 바이트가 추가 전용 구조여도 서버 측 추론 상태가 유효 프롬프트를 바꿀 수 있음
평가 하네스와 도구 스키마, 프롬프트 캐시, 추론 재생을 모두 수정한 GPT-5.6 Sol은 Ploy의 프로덕션 기본 모델로 운영 중임

GN⁺ 6시간전 [-]

Hacker News 의견들

“그 정도 수치면 모델을 실제로 마이그레이션할 만하다” 같은 문구는 너무 우스꽝스럽다. 글을 쓰게 한 사람이 전형적인 LLM 문체만이라도 다듬었으면 좋았을 것 같다
콜론·쉼표·마침표로 짧은 구절을 이어 붙이는 방식도 형편없고 답답하다. 부분 접두사 일치 캐시가 GPT-5.6에서 사라졌다는 내용처럼 좋은 통찰은 있지만, 읽기 편한 글은 아니다
- 그래서 AGENTS.md나 CLAUDE.md 옆에 항상 WRITING.md를 둔다. 대부분은 모델에 무엇을 만들지만 알려주고, 어떻게 써야 하는지는 거의 알려주지 않지만 LLM은 명시적인 문체 지침을 놀라울 만큼 잘 따른다
  불필요한 콜론, 긴 대시, 강조처럼 위장한 문장 파편과 내가 자주 저지르는 문법 오류를 피하도록 규칙을 적고, 기술 문장이 명료하고 대화체이며 허세 없는 Brian Kernighan과 Rob Pike도 참고 대상으로 넣었다. 문서는 읽기 쉬울 뿐 아니라 읽고 싶게 만들어야 한다
  문서를 자주 생성한다면 에이전트가 WRITING.md를 참조하게 할 가치가 크다. 최신 모델로 교체하는 것보다 가독성이 훨씬 크게 좋아질 때가 많고, 모델을 바꿔도 문체를 일관되게 유지할 수 있다
- 특히 AI 회사라면 더 나쁘게 보인다. 모델을 충분히 사용하지 않아 특유의 문체를 모르거나, 그게 중요하다는 자각이 없거나, 전반적인 상황을 이해하지 못하거나, 독자를 존중하지 않는다는 뜻일 수밖에 없어 어느 쪽도 좋지 않다
- 읽는 방식이 잘못됐다. LLM에 자신의 문체 취향대로 읽고 요약하라고 하면 된다. 더 나아가 아무것도 직접 읽지 말고, 에이전트가 나중에 참고할 스킬 파일로 변환하게 하면 된다
- 글이 LLM으로 작성됐다고 의심되면 즉시 읽기를 멈추고 내가 쓰는 LLM 도구로 요약하거나 바꿔 쓰게 한다. 그러면 적어도 출력 문체는 어느 정도 통제할 수 있다
- 지금 쓰는 claude.md에서는 “load-bearing”이라는 표현을 금지했는데 Claude가 정말 싫어한다. 가끔 주석에서 “load-be…most specific” 같은 식으로 놀릴 정도로 이 표현을 지나치게 좋아한다
예전에 5.4-nano와 mini에서 돌리던 다양하고 작고 단순한 워크플로를 5.6으로 옮겼더니 전반적으로 글에서 말한 범위만큼 개선됐고, 일부 분류 작업은 품질도 좋아졌다
많은 회사에서 이런 모델 업그레이드는 사실상 코드 한 줄 변경이다. 핵심 워크플로에는 훌륭한 모델 라우터 아키텍처를 사용하지만, 단순 작업까지 그렇게 구성할 가치는 없으며 안정성 문제도 고려해야 한다
- 이 글의 핵심은 모델 업그레이드가 코드 한 줄 변경이 아니었다는 내용이다
- 어떤 SDK를 사용하는가? 아니면 자체 구현인가?
- Sol을 처음 사용한 목적은 우리 워크플로에서 5.6을 평가하는 것이었다. 이전에는 단순 모델의 품질이 부족해 모든 작업에 5.5를 썼고, 지금은 엉망인 원천 데이터에서 명시적·암묵적 구조화 데이터를 추출하기 위해 텍스트와 이미지를 함께 분석한다
  대체로 광고한 대로 작동한다. 현재 작업 대부분을 terra로 보내면서 비용이 절반으로 줄고 응답 시간도 50% 개선됐다. luna는 OpenCV 탐지 결과를 보완하는 용도로 쓰는데 기능은 매우 제한적이지만 빠르고 거의 공짜에 가깝다. Sol은 우리 작업에서 terra보다 조금만 나았다
  Sol ultra가 평가 자체도 훌륭히 수행했다. 합리적인 권고와 함께 직접 확인하고 비교해야 할 출력 목록, 원본·가공 데이터, 쿼리별 CPM을 담은 큰 자료를 만들어줬다. Pro 구독료 외에는 더 쓰지 않고 몇 시간 돌린 결과 비용 기준은 50% 낮아지고 처리량은 100% 늘었다
내 경험도 비슷하다. OpenRouter처럼 장애 조치를 내세우는 서비스는 샌드박스 테스트 외에는 거의 쓸모가 없다. 프로덕션 모델은 실제로 서로 교환 가능하지 않으며, 본격적인 에이전트 작업을 수행하는 실행 환경은 예상보다 훨씬 많은 모델별 특성에 의존한다
다른 모델이 오류 없이 작동하더라도 성능과 효율은 별개다. Claude 계열처럼 학습 과정에서 익숙해진 표현 방식에 맞춰 시스템 프롬프트를 조정해야 하는 모델이 있는가 하면, 다른 구분자에서 더 잘 작동하는 모델도 있다. 최적 성능이 중요하다면 실행 환경·프롬프트·모델을 하나의 시스템으로 봐야 하며, 부품처럼 자유롭게 교체할 수 있다고 생각하면 안 된다
- LLMOps의 일부로 도구 실행 경로 등을 제대로 검사하는 장애 조치 계획을 구축해야 한다. 그러면 충분히 좋은 모델을 저렴한 순서부터 비싼 순서로 배치해 원하는 장애 조치를 구현할 수 있다
  model -> {{prompts}, {tools descriptions}, ...} 형태의 대응표를 만드는 경우도 봤지만 너무 극단적이다. 어느 시점부터는 모델이 우리 프롬프트에 적응해야 하며, 그러지 못하는 모델은 장애 조치 후보에서 제외해 API 요청을 보내지 않으면 된다
- OpenRouter는 다른 모델로 장애 조치하지 않고, 같은 모델을 제공하는 다른 공급자로 전환한다
깊이 있는 인프라 통찰이 가득한 글 아래에서 댓글 절반이 억지스러운 문체만 비판하는 건 아이러니하다. Claude가 문장을 다듬는 데 도움을 줬더라도, API 예산을 30% 절감하고 빈 파일 읽기를 고치는 즉시 활용 가능한 청사진이 담겼다면 그게 더 중요하지 않은가
- AI와 관련된 것은 무엇이든 싫어해 꼬투리를 잡는 사람도 있겠지만, 정말로 그 문체를 견딜 수 없어서 거기에만 집착하는 사람도 있을 것이다
  개인적으로 문체를 투덜대는 건 우스워 보인다. 내가 문법과 철자에 약해서 그런지 전달 방식보다 개념, 사실, 논증 같은 핵심 내용에 집중한다. 문법과 철자는 나무일 뿐이고 숲이 요점이다
  내 글에 오류가 많지 않은 건 받아쓰기와 직접 만든 단축키 덕분이다. 선택한 텍스트를 로컬 LLM으로 교정한 뒤 교체해 주는데, 이 두 도구만큼 삶의 질과 글쓰기 품질을 높여준 것은 없다
“오늘부터 Ploy 에이전트는 오늘 아침 공개된 GPT-5.6 Sol을 사용한다”니, 겨우 반나절 시험한 결과로 전환한 것인가? 회사를 십 대들이 운영하는 건가?
- 실제로 직원 구성은 Staff와 Senior Staff급에 더 가깝다. YC 관계를 통해 GPT-5.6 미리보기 모델을 약 일주일간 시험하면서 피드백을 제공했다
  평가 작업은 GitHub CI에서 실행되며, ploy.ai가 전문으로 하는 웹 디자인·마케팅 작업 115개 이상의 평가 세트를 약 15분 만에 모두 돌릴 수 있다. PostHog 기능 플래그로 모델을 켠 뒤에는 실패를 적극적으로 감시했다
  인터넷의 1% 이상을 지원하는 Webflow를 운영했던 지식을 Ploy에 최대한 옮겨, 더 많은 인터넷을 지원하려 한다
- 이런 글을 쓸 수 있도록 평가하라고 사전 접근 권한을 어느 정도 받았을 가능성이 충분하다
- 이제는 평가와 벤치마크를 만들고 최신 모델에서 실행하기가 꽤 쉽다. LLM은 교체하기 쉬우므로 좋은 평가 세트가 매우 유용하고, 때로는 개선 폭이 너무 명확해 평가조차 필요 없다
- 새 모델을 비교할 프로덕션 기반 데이터셋을 갖고 있을 것으로 예상한다
Ploy 에이전트가 실제 마케팅 웹사이트를 만들고 수정하며 계획 수립, 코드베이스 읽기, 컴포넌트 작성, 이미지 생성, 자체 결과 촬영과 완료 판단까지 한다지만, 엄밀한 테스트를 하지 않았더라도 Fable이 Opus보다 마케팅 사이트 제작을 훨씬 잘할 것으로 예상한다. 프레젠테이션 자료 제작에서는 확실히 훨씬 낫다
- 디자인에서는 GPT-5.6이 Fable보다 훨씬 낫다
- 4.7은 지시를 지나치게 문자 그대로 따르는 경향이 있어 원문의 결과도 충분히 그럴듯하다
OpenAI 계열 모델에만 선택 속성을 모두 필수이면서 anyOf: [T, null]로 null을 허용하도록 바꾼다는 해결책은 뭔가 잘못된 냄새가 난다. 변형된 형태의 MCP만 써봤지만, TypeScript 타입 정의가 에이전트에서 추론 백엔드로 보내는 JSON Schema에 왜 영향을 주는지 분명하지 않다
MCP 명세에는 선택적 매개변수를 나타내는 필드가 명시적으로 있으므로 TypeScript 계층과 실제로 전송되는 도구 설명 사이 어딘가에 버그가 있는 듯하다. 추론 백엔드가 “유효한 도구 응답 생성”에서 “선택적 매개변수가 없는 JSON Schema에 맞춘 유효한 응답 생성”으로 바뀌었을 수도 있지만, 실제 요청을 보지 않고는 판단할 수 없다
- 이는 스키마 생성이나 TypeScript 버그가 아니라 OpenAI 함수 호출의 내부 동작이다. 도구 사용을 위해 미세 조정된 가중치는 가능한 한 완전한 데이터 구조를 출력하려 한다. 모델이 시스템 프롬프트 문맥에서 매개변수 이름을 보면 required 배열에 없어도 값을 채우려 한다
- Fable·Opus·5.6을 포함한 최신 최전선 모델은 도구 호출에서 꽤 느슨하며 스키마를 정확히 따르지 않을 때가 많다. Pi의 편집·치환 도구 호출에서 Claude 모델이 존재하지 않는 속성을 만들어내는 예는 https://lucumr.pocoo.org/about/에서 볼 수 있다
  원인 일부는 제약 디코딩을 사용하면 지능이 저하되는 현상과 관련 있어 보인다. 스키마 유효성은 보장되지만 능력이 크게 떨어지므로 분류, 요약, 프롬프트 개선에는 괜찮아도 에이전트 반복 실행에서는 주의해야 한다
  Claude Code 같은 실행 환경은 전처리, 복구, 정리 등을 많이 수행하지만 보통 드러나지 않는다. 완벽한 정확성을 가정하고 강제하기보다 실행 환경을 더 느슨하게 만들어 모델별 특성에 맞추는 편이 실전에서는 더 쉽고 낫다. 모델도 한두 달마다 바뀐다. 이것이 분위기로 만드는 응용 AI다
Opus와 Sol로 사이트 하나를 만들 때 실제 비용이 각각 얼마나 드는지 대략적인 금액을 알고 싶다
워크플로를 Reasonix로 옮기고 DeepSeek에서 캐시 적중을 활용하니, 보조금을 받지 않는 미국 공급자를 써도 요청 비용이 사실상 공짜에 가까워졌다
- 어떤 설정을 쓰는지, 그리고 Pi와 비교하면 어떤가?
모든 Ploy 워크스페이스에 GPT-5.6 Sol을 기본으로 쓰기보다 실제 도구를 다루는 작업 일부에는 Luna를 고려할 만하다. 놀랄 만큼 유능하고 빠르다
Sol은 사람과 대화하고 에이전트 호출을 조율하는 데 뛰어나지만 모든 작업에 쓰기에는 너무 비싸다. Sol 한 번 가격으로 Luna를 다섯 번 실행할 수 있으며, 통계적으로 표본 하나가 다섯 개로 늘어나는 차이는 상당히 크다
- Luna 실행의 각 단계가 90% 확률로 맞는다면 다섯 단계가 모두 맞을 확률은 0.9^5 = 0.59, 즉 59% 다. Sol 한 번의 정확도가 95%쯤일 수도 있다. 실제 수치는 달라지겠지만 마지막에 Sol로 검증하는 편이 더 저렴할 수 있다
- 하위 에이전트는 서로 격리돼 있다는 문제가 늘 생긴다. 문맥을 작게 유지하고 집중하게 해준다는 장점이 있지만, 맡은 일을 계속하려면 각자 다시 조사해야 해서 캐시되지 않은 토큰을 소모하곤 한다
  어떤 작업에 에이전트를 얼마나 많이 쓰는지에 따라 비용은 더 들면서 결과는 오히려 나빠질 수도 있다

답변달기

프로덕션 AI 에이전트를 GPT-5.6으로 전환해 2.2배 빠르고 27% 저렴해진 과정

Claude Opus를 대체한 GPT-5.6 Sol

평가 수치를 믿기 전에 하네스부터 수정

기존 모델의 호출 방식에 맞춰진 제약

암묵적인 점수 임계값

수정된 벤치마크 결과

디자인 품질과 일관성

도구 호출의 선택적 매개변수 처리

빈 파일 읽기가 발생한 원인

프롬프트와 strict 모드로 해결되지 않은 문제

프로바이더 경계의 스키마 변환

OpenAI 방식에 맞춘 프롬프트 캐싱

Anthropic의 조직 단위 캐시

GPT-5.6에서 달라진 캐시 동작

명시적 캐시 키의 제약

워크스페이스 단위 계층형 캐시

캐시 수정 결과

추론 재생을 자체 완결형으로 변경

함께 보면 좋은 글 β

댓글과 토론

Hacker News 의견들