2026년, 모델이 아니라 하네스가 AI 코딩 결과를 가른다

결론부터 말씀드리면, 같은 AI 모델이라도 어떤 도구가 그 모델을 운전하느냐에 따라 결과물의 품질이 갈립니다. OpenAI의 GPT-5.6 "Sol" 모델을 자사 도구인 Codex가 아니라 Anthropic의 Claude Code(코드 작업을 도와주는 명령줄 도구)에서 돌렸더니 결과가 눈에 띄게 좋아졌거든요. 가중치도 같고 모델도 같은데 결과가 달라진 겁니다.

이 실험을 공개한 사람은 개발자 Theo Browne(t3.gg, T3 Chat 창업자)입니다. 2026년 7월 11일 트윗으로 "gpt-5.6-sol이 Codex보다 Claude Code에서 확연히 낫다"고 알렸고, 게임 개발자 Paul Bettner도 거의 동시에 같은 결과를 확인했어요. 커뮤니티는 이 현상을 설명하는 단어로 하나를 지목했습니다. 바로 "하네스"입니다.

하네스란 무엇인가요

하네스(harness): 모델 자체를 뺀 나머지 전부 — 도구를 호출하는 방식, 서브에이전트를 조율하는 로직, 시스템 프롬프트, 외부 통합.

모델을 자동차 엔진이라고 하면, 하네스는 그 엔진을 감싼 차체와 운전석입니다. 같은 엔진을 얹어도 변속기가 거칠고 계기판이 산만하면 주행 경험이 나빠지죠. AI 모델도 마찬가지입니다. 도구를 어떻게 부르는지, 서브에이전트(하나의 큰 작업을 쪼개 처리하는 보조 AI)를 어떻게 통제하는지, 시스템 프롬프트(모델에게 매번 딸려가는 기본 지시문)로 무엇을 주입하는지가 최종 결과를 만듭니다.

Theo는 Claude Code v2.1.207에서 gpt-5.6-sol을 high effort로 돌리면서 "Codex 코드베이스의 서브에이전트 V1과 V2 차이를 비개발자도 이해하게 HTML로 정리하라"는 작업을 워크플로우로 시연했습니다. 같은 모델을 다른 껍데기에 넣었을 때 무엇이 달라지는지 직접 보여준 셈이죠.

Codex의 발목을 잡는 건 모델이 아니라 시스템 프롬프트다

Theo가 처음 던진 질문은 "Claude Code는 왜 프론트엔드를 더 잘 만들까"였습니다. 그래서 Claude Code의 시스템 프롬프트를 뒤졌는데, 의외였어요. 'frontend'라는 단어가 딱 세 번, 그것도 "UI를 바꾸면 개발 서버를 띄우고 브라우저에서 확인하라"는 검증 지침으로만 나왔습니다. 디자인 지침은 사실상 없었죠.

문제는 반대편에 있었습니다. 유출된 Codex 시스템 프롬프트에는 프론트엔드 디자인 '헌법'이라 부를 만한 분량이 통째로 들어 있었거든요.

카드는 8px 이하 모서리 (기존 디자인 시스템이 요구하지 않는 한)
자간(글자 사이 간격)은 0, 음수 금지
보라·베이지·슬레이트·에스프레소 같은 색 팔레트로 제한, "CSS 색을 스캔한 뒤 이 테마로 읽히면 수정하라"
SaaS·CRM 도구는 조용하고 실용적으로
lucide 아이콘 라이브러리를 쓰고 직접 그린 SVG는 금지
랜딩 페이지 대신 실제 사용 화면부터
30초마다 진행 상황 보고

이 규칙들이 문제인 이유는, CLI·데이터베이스·백엔드·라이브러리 작업에까지 매번 딸려온다는 데 있습니다. Theo가 세어 보니 'cards'는 프롬프트에 6번, 'card'는 12번, 심지어 'goblins(고블린)'는 2번 나왔어요. Claude Code 시스템 프롬프트가 'frontend'를 말한 횟수보다 많았습니다.

OpenAI 모델은 "시키면 그대로 한다"는 특성이 강합니다. 그래서 이 규칙들이 모든 출력을 획일적인 결과물로 밀어붙이죠. Codex가 유독 30초 타이머를 자주 거는 것, 빈 화면 안내(empty state)를 잘 못 만드는 것, 기획 단계인데 무작정 코딩부터 시작하는 것이 전부 이 시스템 프롬프트에서 나왔습니다.

이건 설정으로 끌 수 있는 게 아니라 Codex 시스템 프롬프트 그 자체입니다. 모든 모델 호출에 따라붙어 토큰(AI가 처리하는 글자 단위, 비용과 직결)을 태우고 출력을 나쁘게 만들어 온 거죠. 실제로 openai/codex 저장소에는 관련 이슈가 여럿 올라와 있습니다. "과도한 프론트엔드 지침에 산만해지지 않게 하라"(#19720), "시스템 프롬프트가 너무 크다"(#19212), "Codex는 자체 디자인 시스템과 더 강한 UI 훈련이 필요하다"(#20878). Theo는 자신이 문제를 지적한 뒤 OpenAI가 해당 조항 일부를 실제로 제거했다고 말합니다. 다만 유출 저장소에는 GPT-5.5 버전에 8px 카드 지침이 여전히 남아 있어, 제거 범위는 버전과 모델마다 다릅니다.

Claude Code Dynamic Workflows — 조율은 코드가, 판단은 모델이

사실 Theo가 이 실험을 시작한 진짜 동기는 UI가 아니라 Claude Code의 워크플로우(Dynamic Workflows)였습니다.

Dynamic Workflow는 여러 서브에이전트를 조율하는 하나의 JavaScript 파일입니다. 내가 무엇을 하고 싶은지 설명하면 Claude가 그 스크립트를 직접 짜고, 런타임이 백그라운드에서 실행하는 동안 내 세션은 계속 응답하죠. 원칙은 간단합니다. "제어 흐름(control flow)은 코드에, 판단(judgment)은 모델에." 워크플로우는 독주자가 아니라 악보에 가깝습니다.

토큰 효율의 핵심은 조율 로직이 어디에 사느냐입니다. 일반 모드에서는 Claude가 직접 지휘자 역할을 하기 때문에, 매 판단의 중간 산출물이 컨텍스트 창(모델이 한 번에 기억하는 대화 공간)에 계속 쌓입니다. 반면 워크플로우에서는 생성된 JavaScript가 지휘자가 되고, 중간 결과는 컨텍스트 창이 아니라 스크립트 변수에 담기죠. 컨텍스트 창에는 중간 과정이 아니라 최종 검증된 답만 남습니다.

이게 이른바 "서브에이전트 세금"을 없앱니다. 서브에이전트를 지휘자를 거쳐 돌리면, 5개만 돼도 필요한 것보다 3~~4배, 10개면 8~~10배의 토큰을 낭비하거든요. 조율을 코드로 옮기면 복잡한 워크플로우에서 토큰이 60~90% 줄고, 조율 자체는 코드라서 모델 토큰을 0으로 씁니다. Theo의 표현으로는 "출력 품질은 같거나 더 좋은데 토큰은 1/4밖에 안 쓴다"였습니다.

주요 기본 함수는 세 가지입니다. agent()는 에이전트 하나를 실행하며 정해진 형식(schema)으로 출력을 검증하고, parallel()은 여러 개를 동시에 돌린 뒤 결과를 모으며, pipeline()은 단계별로 결과를 흘려보냅니다(기본값). 동시 16개, 한 실행당 최대 1000개 에이전트까지 가능하지만 실무에서는 보통 20~100개를 씁니다.

주의할 점도 있어요. 판단하는 에이전트를 많이 띄우니 전체 토큰은 오히려 비쌉니다. 그래서 넓은 탐색, 독립적인 교차 검증, 한 컨텍스트에 안 담기는 규모가 필요할 때만 쓰는 게 정석입니다. 실행 전에 dry-run(실제 발행 없이 규모만 미리 계산)으로 견적을 내는 게 비용 통제의 왕도고요.

Codex와 Claude Code, 서브에이전트를 다루는 방식이 다르다

두 도구가 서브에이전트를 대하는 태도 자체가 다릅니다.

Codex의 서브에이전트 V2는 컨텍스트 창을 통째로 복사하고, 서브에이전트가 또 자기 밑에 서브에이전트를 만들며 메시지를 주고받습니다. 단순해야 할 위계를 복잡하게 만들어서 아직 기본 비활성 상태예요. 자유의지를 가진 조수들이 알아서 튀어나오는 셈이죠.

Claude Code는 반대입니다. 모델이 앞단에서 단계별 프롬프트와 서브에이전트를 코드로 미리 명시한 뒤 실행합니다. 미리 짜인 각본대로 움직이는 거죠. 코드는 위에서 아래로 흐르고 끝이 있으니, 토큰이 폭주할 여지를 구조적으로 막습니다.

Theo는 다른 하네스도 검토했습니다. OpenCode·Pi·OhMyPy의 시스템 프롬프트는 Codex보다 덜 나쁘지만, 그가 가장 원하는 서브에이전트 조율 문제를 풀지 못했어요. OhMyPy는 설치할 때 150페이지짜리 변경 이력을 터미널에 통째로 뿌려 스크롤백을 날렸고, Pi는 훌륭하지만 조율 도구를 직접 다 만들어야 했으며, OpenCode는 하드코딩된 서브에이전트가 아쉬웠습니다. 그의 결론은 "복잡한 실무 작업에서 서브에이전트를 조율하는 최고의 구현은 단연 Claude Code의 워크플로우이고, 근접한 대안이 없다"였습니다.

균형점 — 위험과 대안도 함께 봐야 한다

여기서 멈추면 반쪽짜리 결론이 됩니다. 세 가지 균형점을 같이 봐야 해요.

첫째, 붙이는 방식에 리스크가 있습니다. 가장 많이 공유된 방법은 비공식 프록시(CLIProxyAPI)를 깔고 셸 alias로 GPT-5.6 Sol을 Claude Code에 붙이는 겁니다. 환경변수가 셸 단위라, 기본 claude는 Fable/Sonnet/Opus로, 별칭 세션은 GPT-5.6 Sol로 분리되죠. 그런데 이 방식은 계정 정지(밴)와 이용약관(ToS) 회색지대 위험이 있습니다. OpenAI가 Claude Code 안에서 Codex를 부르는 공식 플러그인을 낸 이유이기도 해요(/codex:review, /codex:adversarial-review, /codex:rescue, Codex CLI 0.144.0 이상). 참고로 CLIProxyAPI로는 Grok이나 Opus 4.5 같은 다른 구독도 Claude Code에 붙일 수 있습니다.

둘째, 벤치마크가 얽혀 있어 깨끗한 비교가 아닙니다. Artificial Analysis 코딩 에이전트 지수에서는 Sol이 Codex 안에서 1위, Claude Fable이 Claude Code 안에서 근소한 2위였어요. 모델과 하네스가 섞여 있어서 "같은 모델의 순수 비교"라고 보기 어렵습니다.

셋째, 재현되지 않은 사례도 있습니다. 4개 작업을 돌린 한 독립 소규모 테스트는 코딩 작업에서 하네스 우위를 재현하지 못했어요. Theo 본인도 Codex가 더 빠르다고 평가한 적이 있고, GPT-5.5 on Codex가 한때 그의 데일리 드라이버였습니다. 속도와 출력 품질은 다른 축이라는 거죠.

정리하면 "하네스가 중요하다"는 방향에는 커뮤니티가 크게 공감하지만, "어느 하네스가 항상 이긴다"는 단정은 경계하는 분위기입니다.

실무 함의 — 무엇을 챙겨야 하나

Theo의 메시지를 한 줄로 옮기면 이렇습니다. "새 세대 모델의 성능을 최대로 끌어내려면, 하네스가 무엇을 잘하고 무엇을 못하는지 이해해야 한다."

1인 기업 자동화나 AI 도구를 실무에 쓰는 입장에서 얻을 교훈은 두 가지입니다.

첫째, 시스템 프롬프트에 픽셀 단위 규칙을 잔뜩 넣어 모델을 '보수적 기본값'에 가두면 오히려 획일적인 결과물이 나옵니다. 규칙이 많다고 품질이 오르지 않아요. 도메인마다 필요한 지침이 다른데, 프론트엔드 규칙을 백엔드 작업에까지 딸려 보내면 모델이 산만해집니다.

둘째, 조율을 코드로 옮기고 판단만 모델에 맡기면 토큰은 줄고 품질은 올라갑니다. 여러 AI를 조율하는 자동화를 설계할 때, 지휘를 사람이나 모델이 매번 하는 대신 코드(워크플로우)로 고정하면 비용과 안정성이 동시에 좋아지는 거죠.

모델 선택은 여전히 중요합니다. 다만 모델 선택만큼, 때로는 그 이상으로 그 모델을 감싸는 하네스의 설계가 결과를 가릅니다. 새 모델이 나올 때마다 벤치마크 점수만 보지 말고, 그 모델을 어떤 도구로 돌릴지도 함께 따져봐야 하는 이유입니다.

자주 묻는 질문 (FAQ)

Q: 하네스가 정확히 뭔가요?

하네스는 AI 모델 자체를 뺀 나머지 전부를 가리킵니다. 모델이 도구를 어떻게 호출하는지, 서브에이전트를 어떻게 조율하는지, 시스템 프롬프트로 무엇을 주입하는지, 어떤 외부 시스템과 통합되는지가 모두 하네스예요. 같은 모델도 하네스가 다르면 결과가 달라집니다.

Q: GPT-5.6 Sol을 Claude Code에서 돌리면 항상 결과가 더 좋나요?

항상은 아닙니다. Theo Browne과 Paul Bettner는 복잡한 실무 작업에서 하네스 우위를 확인했지만, 4개 작업을 돌린 한 독립 소규모 테스트에서는 재현되지 않았어요. 벤치마크도 모델과 하네스가 섞여 있어 깨끗한 비교가 아니고, 속도 면에서는 Codex가 더 빠르다는 평가도 있습니다. "하네스가 중요하다"는 방향은 맞지만 "항상 이긴다"는 단정은 이릅니다.

Q: 비공식 프록시로 붙이는 방식이 안전한가요?

리스크가 있습니다. CLIProxyAPI 같은 비공식 프록시와 셸 alias로 붙이는 방식은 계정 정지와 이용약관 회색지대 위험이 있어요. 안전하게 두 도구를 섞고 싶다면 OpenAI가 낸 공식 플러그인(Claude Code 안에서 Codex를 호출하는 /codex:rescue 등, Codex CLI 0.144.0 이상)을 쓰는 편이 낫습니다.

Q: Dynamic Workflows가 토큰을 왜 절약하나요?

조율 로직이 어디에 사는지가 핵심입니다. 일반 모드에서는 모델이 직접 지휘하느라 중간 산출물이 컨텍스트 창에 계속 쌓이지만, 워크플로우에서는 생성된 JavaScript가 지휘를 맡아 중간 결과를 스크립트 변수에 담습니다. 컨텍스트 창에는 최종 검증된 답만 남죠. 그래서 복잡한 작업에서 토큰이 60~90% 줄고, 조율 자체는 코드라 모델 토큰을 0으로 씁니다.

2026년, 모델이 아니라 하네스가 AI 코딩 결과를 가른다