Theo(t3.gg)가 GPT-5.6(코드네임 "Soul") 모델을 OpenAI의 공식 CLI인 Codex가 아니라 Claude Code 안에서 돌려본 경험을 공유하는 영상. 결론부터 말하면 모델 자체보다 "하니스(harness, 실행 환경)"가 실사용 품질을 좌우한다는 것이며, 그 근거로 Codex의 공식 시스템 프롬프트를 직접 파헤쳐 문제점을 낱낱이 공개한다.
계층 1 — 핵심 주장/결론
- GPT-5.6(Soul)을 Codex CLI가 아니라 Claude Code 안에서 실행하면 결과물이 훨씬 좋다. 같은 모델인데도 하니스만 바꿨을 뿐인데 품질 차이가 크다.
- Codex의 공식 시스템 프롬프트가 심각하게 나쁘게 작성되어 있다. 특히 프론트엔드 디자인 지침이 과도하게 구체적이고 강압적이며, 30초마다 업데이트를 보내라는 지침 때문에 Codex가 이상하게 30초 타이머에 집착하는 현상이 생겼다.
- Claude Code의 "워크플로우"(sub-agent를 코드로 정의하는 기능)가 현존하는 서브에이전트 오케스트레이션 구현 중 최고다. Codex의 Ultra 모드보다 토큰 효율이 약 4배 좋고 결과물 품질도 동등하거나 더 낫다.
- Claude Code의 시스템 프롬프트는 Codex보다 훨씬 절제되어 있고 실용적으로 쓰여 있다. 분량은 상당하지만 불필요한 강제 규칙이 적다.
- Theo 본인은 완전히 Codex를 버리라는 게 아니라, "실험 삼아 해봤는데 예상보다 훨씬 좋았다"는 태도로 공유하는 것이며, Codex 데스크톱 앱 자체는 여전히 입문자에게 좋은 시작점이라고 인정한다.
계층 2 — 주요 논점/근거/사례
Codex 서브에이전트 구조의 문제
- Codex 서브에이전트는 V1(안정적, 단순: 최상위 에이전트가 서브에이전트를 한 단계 아래로 스폰하고 결과를 받는 구조)과 V2(수동 활성화 필요, 컨텍스트 윈도우 전체를 복사하고 서브에이전트가 또 자신의 서브에이전트를 만드는 계층 구조)로 나뉜다.
- V2는 단순한 계층 구조를 과도하게 복잡하게 만들고, 통신을 위한 도구가 잔뜩 필요해지며 결과가 다소 혼란스럽다. 그래서 여전히 기본값이 꺼져 있음.
Claude Code 워크플로우의 우위
- Claude Code의 워크플로우는 모델이 사전에 단계별(stage)로 다른 프롬프트, 다른 서브에이전트를 지정하는 하나의 JavaScript 파일을 top-to-bottom으로 실행하는 방식.
- 코드로 정의되기 때문에 "실제로 끝난다"는 게 핵심 장점 — Ultra 모드는 끝없이 돌아가는 경향이 있는 반면 워크플로우는 종료 조건이 명확함.
- 같은 작업 기준으로 토큰 사용량이 워크플로우가 Ultra 대비 약 1/4 수준.
- OpenAI는 Codex 안에서 코드 실행 자체를 자신들이 구현해두고 모델이 그걸 올바르게 "호출"해야 하는 구조인 반면, Claude Code는 모델 스스로 워크플로우/서브에이전트용 코드를 직접 작성하게 함 — 이 차이가 품질 차이로 이어진다고 봄.
디자인 품질 차이의 원인 추적
- 동일한 5.6 Soul 모델로 만든 웹페이지를 비교했을 때, Claude Code에서 만든 것이 Codex에서 만든 것보다 눈에 띄게 낫다.
- Theo는 Claude Code 시스템 프롬프트에 프론트엔드 관련 특별 지침이 있을 거라 가정하고 전체 프롬프트를 읽었지만, "front-end"라는 단어는 단 3번, 그마저도 실질적 디자인 가이드는 없었음(주로 "UI 변경 시 개발서버 켜서 브라우저로 확인하라"는 검증 지침).
- 반대로 Codex의 공식 시스템 프롬프트를 파헤친 결과, 프론트엔드 전용 "디자인 헌법"에 가까운 방대한 규칙 뭉치를 발견. 예: 카드 모서리는 8px 라운드 이하로 고정, 아이콘은 반드시 Lucide 아이콘 라이브러리 사용, 색상 팔레트(보라/파랑 그라데이션, 베이지, 슬레이트 등) 사용 제한, 히어로 섹션 구성 방식 강제, "인앱 텍스트로 기능/단축키를 설명하지 말라"는 규칙 등.
- 이 규칙들 때문에 Codex가 만드는 페이지들이 다 비슷비슷하게 획일적으로 나온다는 게 Theo의 진단.
- Theo가 OpenAI의 프론트엔드 담당 지인에게 이 문제를 항의(crash out)해서, 해당 프론트엔드 지침이 실제로 삭제/수정됨. (영상에서는 "잘렸다"고 언급하며 캐시된 버전을 별도로 찾아 예전 지침 내용을 그대로 인용해서 보여줌)
30초 타이머 미스터리 해결
- 많은 Codex 유저들이 경험한 "왜 자꾸 30초 타이머를 거는가"라는 의문의 원인이 시스템 프롬프트의 "You provide user updates frequently every 30 seconds." 지침이었음을 확인.
Autonomy/지속성 지침 문제
- Codex 프롬프트의 "continue until solved", "사용자가 명시적으로 계획만 원한다고 하지 않는 이상 바로 코드 변경을 실행하라"는 지침이, Codex가 계획 단계에서도 성급하게 코드를 짜기 시작하는 원인으로 지목됨.
GPT-5.6 Soul 자체의 평가
- Theo가 Claude Code 안의 5.6 Soul, Fable 5, 그리고 Codex 안의 5.6 Soul 모두에게 Codex 시스템 프롬프트를 평가시킴.
- Claude Code의 5.6 Soul 평가: "특정 Codex 런타임 전용으로는 7/10, 범용 코딩 에이전트 프롬프트로는 4/10, 5.6 같은 최신 모델의 portable 프롬프트로는 3/10." 프론트엔드 섹션이 프롬프트 전체의 약 1/4을 차지하며 CLI/DB/라이브러리 작업에도 불필요하게 적용된다고 지적.
- Codex 안의 5.6 Soul도 자체 평가에서 4/10을 주며 문제점을 조목조목 비판.
Claude Code 시스템 프롬프트의 장점
- "실행 위험도(reversibility, blast radius)를 신중히 고려하라", "되돌리기 어렵거나 공유 시스템에 영향을 주는 작업은 사용자에게 먼저 확인하라" 같은 안전 지침이 잘 갖춰져 있음.
- 톤/스타일 지침(이모지 남용 금지, 짧고 간결한 응답, 파일경로:줄번호 형식 참조 등)도 실용적.
- "기본적으로 코드에 주석을 달지 마라. WHY가 명확하지 않을 때만 달아라" 같은 코드 작성 원칙도 합리적으로 평가.
실사용 중 발견한 단점(gotcha)
- GPT-5.6이 Claude Code 안에서 가끔 컨텍스트를 살짝 놓치는 느낌이 있었음(다만 이건 시스템 프롬프트의 사소한 문제일 수 있다고 추측).
- 같은 이름의 파일을 여러 에이전트가 동시에 만들려 할 때 처리 방식에 약간의 혼선이 있었으나, 결국 스킬 지침(HTML 호스팅)은 정상적으로 따름 — Theo 본인이 초반에 오판했다가 정정.
- 마크다운 번호 매기기 포맷팅에서 가끔 어색한 반복(1, 1, 2, 2, 3, 3...) 현상 발견.
- 5.6 모델은 Fable과 달리 작업 도중 실시간으로 토큰 사용량을 보여주지 않고, 작업이 끝난 후에야 보여줌.
다른 하니스는 왜 대안이 안 되는가
- OpenCode, Pi, Amp My Pi 등은 시스템 프롬프트는 Codex보다 나을 수 있지만, Theo가 가장 중요하게 여기는 서브에이전트 오케스트레이션(워크플로우) 기능이 없음.
- "Amp My Pi"는 설치 시 150페이지짜리 체인지로그를 터미널에 그대로 쏟아내서 스크롤백을 통째로 날려버리는 등 UX가 나빴다고 혹평.
- Pi는 좋지만 워크플로우/오케스트레이션 도구를 직접 다 만들어야 함.
- OpenCode는 하드코딩된 서브에이전트가 있지만 품질이 별로였고, 워크플로우 기능 자체가 없음.
계층 3 — 구체적 발언/인용/데이터 포인트
- "The output quality's the same if not better from workflows, and the token usage is like a fourth as much."
- Codex 구 프론트엔드 지침 인용: "Cards are kept at 8-pixel border radius or less unless the existing design system requires otherwise." / "You use Lucid icons inside buttons whenever one exists instead of manually drawn SVG icons."
- "The word cards is on this page six times. The word card is 12."
- 30초 타이머의 근원이 된 문구: "You provide user updates frequently every 30 seconds."
- 5.6 Soul(Claude Code)의 Codex 프롬프트 자체평가: "Seven out of 10 is a prompt for one tightly controlled Codex runtime, four out of 10 is a general coding agent prompt, and three out of 10 is a portable prompt for modern models like 5.6."
- OpenAI 측 응답(전달받은 내용): "We're unlikely to change the current system prompt for 5.5 because it was used during training, but I'll pass your feedback along to the team."
- Matt Schumer 사건 언급: Codex Ultra를 돌리다 유저 홈 폴더 전체가 삭제된 사고가 있었다고 인용.
- Claude Code 시스템 프롬프트 인용: "Default to writing no comments. Only add one when the why is non-obvious." / "Carefully consider the reversibility and blast radius of actions."
- Codex의 autonomy 지침 인용: "Unless the user explicitly asks for a plan... you assume they want you to make the change... do not stop at a proposal, implement the fix."
- "Have you ever wondered why Codex never does good empty states? It's the system prompt." (인앱 설명 텍스트 금지 규칙 때문)
- "It mentions goblins twice. The Codex system prompt mentions goblins more than the Claude code one mentions front end and UI." (풍자적 비교)
계층 4 — 실행 시사점/액션 아이템
- Codex 구독이 있다면 CLI Proxy API를 통해 Claude Code 안에서 GPT-5.6(Soul) 모델을 실행해보고 결과물 품질을 직접 비교해볼 것. 같은 모델이라도 하니스 차이로 결과가 달라질 수 있음.
- 복잡한 멀티 에이전트 작업(코드베이스 분석, PR 리뷰, 병렬 리서치 등)은 Ultra 모드처럼 모델이 알아서 서브에이전트를 스폰하게 두기보다, 워크플로우(JS 파일로 단계·모델·서브에이전트를 명시적으로 정의)로 구성하는 게 토큰 효율과 결과 품질 모두에 유리.
- 시스템 프롬프트/스킬/AGENTS.md는 AI가 대신 작성하게 하지 말고 직접 손으로 작성할 것. Codex 사례처럼 과도하게 구체적인 규칙이 쌓이면 오히려 결과를 획일화·저하시킬 수 있음.
- Claude Code에서 특정 모델(예: Soul, Terra, Fable)을 이름으로 지칭해 오케스트레이션시키고 싶다면, 그 이름-모델 매핑을 AGENTS.md나 시스템 프롬프트에 명시적으로 정의해둘 것 — 그래야 모호한 지시에도 올바르게 라우팅됨.
- CLI Proxy API로 Grok Build(트위터 프리미엄 구독 활용), Opus 4.5 등 다른 제공처의 구독도 Claude Code 안에 연결해 활용 가능 — 특정 구독을 이미 갖고 있다면 확인해볼 가치가 있음.
- Codex를 계속 쓰는 사람이라면, 프론트엔드 결과물이 획일적이거나 과하게 규칙적으로 나오는 이유가 하드코딩된 시스템 프롬프트 규칙 때문일 수 있음을 인지하고, 필요시 원하는 스타일을 명시적으로 강하게 지정하는 프롬프트로 우회할 것.
- 서브에이전트/워크플로우 오케스트레이션이 핵심 요구사항이라면, 시스템 프롬프트 품질만 보고 하니스를 고르지 말고 오케스트레이션 기능 유무를 우선 기준으로 삼을 것 (OpenCode/Pi류는 이 부분이 약함).