GPT-5.6으로 갈아탔더니 2.2배 빠르고 27% 쌌다 — 단, 하네스를 같이 고쳐야 그 숫자가 나온다

모델을 비교하는 흔한 방법은 두 가지다. 벤치마크 점수를 보거나, 100만 토큰당 단가를 보거나. 그런데 프로덕션에서 에이전트를 돌리는 입장에서 둘 다 반쪽이다. 점수는 내 워크로드가 아니고 단가는 모델마다 태우는 토큰 양이 다르다는 걸 숨긴다.

그래서 Ploy가 이달 초에 공개한 마이그레이션 실측기가 귀하다. 마케팅 웹사이트를 통째로 만들어 주는 프로덕션 에이전트를 Claude Opus 4.8에서 GPT-5.6으로 옮기면서 지나간 구덩이와 최종 회계를 숫자로 다 적어놨다. 이 에이전트는 페이지를 계획하고 코드베이스를 읽고 컴포넌트를 쓰고 이미지를 만들고, 마지막엔 자기 결과물을 스크린샷으로 검사해 완료를 스스로 판단한다.

요약 먼저. 4개월간 자사 프로덕션 eval에서 어떤 프런티어 모델도 Opus를 못 이겼는데, GPT-5.6이 처음으로 넘었다. 완료당 비용 27% 절감, 벽시계 시간 2.2배 단축, 품질 점수는 오히려 위였다. 다만 첫 실행의 점수에도 하네스 호환성 실패가 섞여 있었고, 이를 분리해야 모델 비교가 공정해졌다.

반전: 네 eval은 현직 모델에 맞춰 휘어 있다

GPT-5.6을 기존 파이프라인에 그대로 꽂은 첫 실행은 최종적으로 강한 결과를 냈지만 여러 실패 유형도 드러냈다. 실패 트레이스를 뜯어 보니, 원시 실패의 약 3분의 1이 모델 행동이 아니라 하네스의 가정 탓이었다.

대표적인 게 도구 호출 예산이다. Opus는 도구를 순차적으로 부르는 편이라 파이프라인의 호출 한도가 그 리듬에 맞춰져 있었다. GPT-5.6은 병렬로 여러 개를 한꺼번에 부른다. 같은 일을 하는데 한도를 초과해 실패 판정을 받은 것이다. 모델이 못한 게 아니라 심판이 구형 룰북을 들고 있었다.

이게 이 글에서 제일 값진 교훈이라고 생각한다. 몇 달간 한 모델로 운영하면 프롬프트, 도구 스키마, 호출 예산, 평가 기준이 전부 그 모델의 버릇에 맞춰 조금씩 휘어 간다. 의도한 적 없어도 그렇게 된다. 그 상태에서 새 모델을 꽂고 점수를 재면, 현직 모델의 홈그라운드에서 원정 경기를 시키는 셈이다. Ploy의 표현을 빌리면, pass rate를 믿기 전에 트레이스부터 분류하라(triage the traces before trusting the pass rate).

#35에서 하네스는 모델을 갈아타도 남는 자산이라고 썼다. 맞는 말인데, 이 사례는 그 뒷면을 보여준다. 자산에는 관성이 있다. 리포지토리에 쌓인 하네스는 현직 모델의 모양대로 굳고 그 관성이 새 모델의 실력을 가린다.

하네스에서 고친 세 가지

하네스를 새 모델에 맞게 고치는 작업은 크게 세 건이었다. 셋 다 프롬프트가 아니라 구조를 고쳤다는 게 공통점이다.

1) 도구 스키마 — 프롬프트로 못 고치면 스키마로 고친다. 파일 읽기 도구에 필수 파라미터 1개와 선택 파라미터 24개가 있었는데, Opus는 필요한 2~3개만 채워 보낸 반면 GPT-5.6은 6,635번의 호출 전부에서 25개를 다 채웠다. 쓸 값이 없으면 지어내서라도. 그렇게 지어낸 offset 값 때문에 파일 읽기의 52%가 빈 결과를 돌려받았다. “선택 파라미터는 비워두라”는 프롬프트 지시는 안 먹혔고 해결은 스키마 변경이었다. 선택 파라미터를 전부 필수이되 null 허용으로 바꾸자 모델이 지어내는 대신 명시적으로 null을 보냈다. 빈 파일 읽기 52% → 0%, 전체 도구 호출도 약 30% 줄었다. #29에서 다룬 “도구 설계가 곧 에이전트 품질”이라는 명제의 생생한 재연이다.

2) 캐시 — 콜드 캐시로 비용을 비교하지 마라. Anthropic 캐시는 부분 프리픽스 일치를 지원해서 대충 써도 적중했는데, OpenAI 쪽은 정확한 매칭에 캐시 쓰기 보증금(1.25배)까지 있다. 그대로 옮기니 새 대화의 첫 호출 캐시 적중률이 0%였다. 워크스페이스 단위 캐시 키와 계층적 breakpoint(도구+정적 프리픽스 → 워크스페이스 컨텍스트 → 세션 턴)를 다시 설계하고서야 첫 호출 적중률 83.7%, 미캐시 입력 토큰 28% 감소가 나왔다. 캐시 전략이 벤더마다 다르다는 건 곧, 캐시를 새 벤더 구조에 맞추기 전의 비용 비교가 신형에게 불리하게 왜곡될 수 있다는 뜻이다.

3) 추론 재생 — 상태를 서버에 맡기지 마라. GPT-5.6의 Responses API는 이전 턴의 추론을 재생하는데, 서버 저장 참조 방식이 프로덕션에서 간헐적으로 깨졌다(“Item not found”). store: false로 바꿔 암호화된 추론 컨텐츠를 요청에 직접 실어 보내는 자기완결 방식으로 해결했다.

신형은 ‘덜’ 생각하고도 이긴다

공사가 끝난 뒤의 최종 숫자다. 표본은 완료된 빌드 기준 Opus 11건, GPT-5.6 10건으로 작다.

이 표에서 제일 눈여겨볼 줄은 비용이 아니라 출력 토큰이다. GPT-5.6은 Opus의 절반만 말하고도 품질 점수가 더 높다. 생성한 코드도 같은 방향이다. Opus가 만든 globals.css는 17,957자에 CSS 변수 174개였는데, GPT-5.6은 2,508자에 45개로 같은 페이지를 만들었다.

이 워크로드에서 확인된 바는 이렇다. 새 모델이 더 적은 출력 토큰으로도 더 높은 점수를 냈고, 완료당 비용과 시간도 함께 줄었다. #31에서 본 Sol의 벤치 수치도 비슷한 방향이었다. 다만 다른 워크로드에서도 같은지는 각 조직의 평가로 확인해야 한다.

물론 공짜는 아니다. 위의 세 공사가 이 숫자의 전제 조건이다. 콜드 캐시에 구형 스키마로 잰 GPT-5.6은 이 표의 모델이 아니다.

실전: 모델을 비교하기 전 점검 4가지

이 사례에서 이식할 수 있는 체크리스트는 네 줄이다.

1) pass rate 전에 트레이스를 분류하라. 새 모델의 실패를 모델 실패와 하네스 실패로 갈라 세어 보라. Ploy는 3분의 1이 하네스였다. 이 분류 없이 나온 “새 모델 별로던데”는 측정이 아니라 홈 어드밴티지다.

2) 도구 스키마를 새 모델의 버릇에 맞춰라. 병렬 호출 성향, 파라미터 채우기 방식은 모델마다 다르고 프롬프트로 잘 안 고쳐진다. 선택 파라미터가 많은 도구는 필수+null 허용 패턴을 검토하라.

3) 캐시를 벤더 구조에 맞게 재설계한 뒤에 비용을 재라. 프리픽스 매칭 방식, 쓰기 비용, 키 스코프가 다 다르다. 캐시를 고치기 전의 비용 비교는 무효다.

4) 단가뿐 아니라 완료당 비용으로 회계하라. 토큰 단가표만으로는 모델별 토큰 소비량과 성공률 차이를 담지 못한다. 내 워크로드 기준 “성공한 작업 하나에 얼마·몇 분”을 함께 보는 편이 더 공정하다.

그리고 이 점검에는 전제가 하나 있다. #32의 eval 파이프라인이 없으면 애초에 비교 자체를 못 한다. Ploy가 “4개월간 아무도 Opus를 못 이겼다”고 말할 수 있는 건 도전자가 올 때마다 돌리는 프로덕션 eval이 있었기 때문이다.

사람들이 진짜 원한 것

이 글이 HN에서 화제가 된 이유를 생각해 보면, 밑에 깔린 수요는 “GPT가 Claude를 이겼다”는 승부가 아니다. 갈아탈 자유다. 프런티어 모델이 몇 달 간격으로 순위를 뒤집는 시대에, 조직이 정말 두려워하는 건 나쁜 모델이 아니라 좋은 모델이 나왔는데 못 옮기는 상황이다.

그리고 이 사례가 보여주듯, 이제 락인은 가격표나 API 호환성에 있지 않다. 락인은 하네스 가정 속에 산다. 현직 모델의 버릇에 맞춰 휘어 간 도구 스키마, 캐시 구조, 호출 예산, 평가 기준이 조용히 쌓여서 전환 비용이 된다. Ploy는 그 비용을 치르고 27%와 2.2배를 가져갔다.

#35의 마지막 질문이 “저 점수는 모델이 낸 것인가, 하네스가 받쳐준 것인가”였다. 이 글은 그 질문을 뒤집은 실사판이다 — 저 낮은 점수는 모델이 못한 것인가, 하네스가 발목 잡은 것인가. 두 질문에 답할 수 있는 조직만이 모델이 바뀌는 속도를 이득으로 바꾼다. 등급 선택의 기초는 #31을, 하네스 일반론은 #35를 보라.

참고: Migrating a production AI agent to GPT-5.6 (Ploy, Lorenzo Gentile, 2026-07-09), GPT-5.6 가격·프롬프트 캐싱 (OpenAI), HN 토론. 수치는 Ploy가 공개한 완료 빌드 Opus 11건·GPT-5.6 10건의 자사 프로덕션 eval 기준이다. 단일 회사·단일 워크로드 실측이므로 일반화할 수 없다.