1. 핵심 주장 / 결론
AI 업계는 자꾸 "하나의 승자 모델"을 원하지만, 그건 착각이다. GPT-5.6 Soul이냐 Claude Fable 5냐를 **선택(OR)**하는 것 자체가 실수이며, 진짜 이기는 마인드셋은 **결합(AND)**이다 — compute를 고르지 말고 compute를 합쳐라.
저자(IndyDevDan)는 여러 모델을 벤치마크용으로 유지하긴 하지만, 실제 프론티어 엔지니어링 작업에서 중요한 건 통제되지 않은 "외로운 에이전트 한 마리"가 아니라 에이전트 팀이라고 강조한다. 이 패턴 자체는 새롭지 않다 — "architect-editor", "prompt chaining", "agent chaining"으로 불리다가 지금은 Devin/OpenRouter 등이 "model fusion"이라 부르고, 앞으로 또 다른 이름이 붙을 것이다. 이름이 뭐든, 이건 에이전틱 엔지니어링 툴박스에 반드시 넣어야 할 도구다.
2. 주요 논거 & 근거
- 바이브코딩이 아니라 하니스 엔지니어링: 저자는 PI 코딩 에이전트를 이용해 "퓨전 하니스(fusion harness)"라는 커스텀 도구를 직접 만들어 이 패턴을 실현한다. 즉 모델을 잘 쓰는 게 아니라, 모델들을 조율하는 하니스 자체를 엔지니어링하는 것이 핵심이다.
- 3개의 커맨드로 구성된 오케스트레이션:
/opinion— 여러 에이전트로부터 서로 다른 관점(perspective)을 동시에 받는다./fusion— 여러 에이전트의 최선의 결과를 결합/통합한다./auto validate— 작업을 시작하기 전에 검증 게이트를 먼저 만들어, 에이전틱 엔지니어링의 두 번째 제약(리뷰)을 해결한다.
- 컨텍스트 윈도우와 지능의 결합: 여러 모델을 "제대로" 쓴다는 건 각 모델의 지능과 컨텍스트 윈도우를 합치는 것이다. 단일 에이전트 응답도 괜찮고, 두 에이전트 응답은 더 좋고, 두 모델의 관점을 결합하면 더더욱 좋다.
- 합의(consensus)와 발산(divergence)이 곧 가치: 두 모델이 같은 답을 낸 부분은 신뢰도를 높여주고, 서로 다른 답을 낸 부분(상호 보완적이지 모순이 아닌 경우)은 퓨전 모델이 버리지 않고 함께 유지한다. 이게 정말 중요한 정보라고 강조한다.
- 검증을 실행 전에 배치:
/auto validate를 실행하면 빌더 에이전트가 작업을 시작하기 전에 검증자(validator) 에이전트가 먼저 검증 게이트(검증 스크립트, 실패 시 피드백 포함)를 작성한다. 빌더는 이 게이트 파일을 수정할 수 없도록 설계되어 있어, 작업이 끝나면 검증 스크립트가 자동으로 통과/실패를 판정하고, 실패하면 빌더에게 피드백을 주고 루프백한다. - 엔지니어링은 여전히 트레이드오프의 문제: 에이전트를 아무리 많이 써도 최종적으로는 사람이 결정을 내려야 한다. 최고의 결정을 내리려면 최고의 컴퓨트가 주는 관점과 정보가 필요하다.
- 소버린 AI(sovereign AI) 문제 제기: 우리는 계속 우리의 데이터를, 우리 회사의 지적재산을 Anthropic·OpenAI·Gemini 같은 빅랩에 프롬프트로 넘기고 있다. 로컬 컴퓨트를 소유해서 우리의 trace(작업 흔적)를 우리가 통제해야 한다는 논의가 점점 중요해질 것이라 지적하며, 다음 영상에서 "Anthropic과 OpenAI가 우리에게 돈을 받으면서 동시에 데이터를 훔치고 있는가"라는 주제를 다룰 예정이라 예고한다.
3. 세부 내용 & 사례 & 데이터
사례 1 — 간단한 워크숍 모델 비교 (Claude Sonnet 5 vs GPT-5.6 Terra)
- 프롬프트: "top 3 scikit-learn 모델, 사용 사례, 장단점을 opinion으로 나열하라"
- 결과: Terra는 4.5초, 9K 토큰 입력/300 토큰 출력, 비용 약 3센트로 완료. Sonnet 5는 그 두 배 시간, 입력 4K 토큰 더 많고 출력도 4K 토큰 더 많으며 비용은 약 1센트 더 들었다.
/fusion table.md로 결합한 결과, 두 모델 모두 "random forest, gradient boost, logistic regression"에 완전히 동의(consensus)했고, 일부 항목에서만 소소하게 다른 답을 냈는데 이는 모순이 아니라 상호 보완적이었다. 퓨전 모델은 둘 다 유지하고 버린 것이 없었다./auto validate로 "가장 작은 데이터셋으로 MVP 구현"을 지시하자, GPT-5.6 Terra(빌더)가 매우 빠르게 작업을 완료하는 동안 Claude Sonnet 5(검증자)는 검증 게이트 스크립트를 먼저 작성했다. 초기 체크에서는 파일이 없어 실패했지만, 빌더 작업이 끝난 후 재실행하니 전부 통과(pass)했다. Terra의 속도와 간결함이 인상적이었다고 평가.
사례 2 — 고난도 실전 문제 (SQLite에 100만 행 삽입)
- 문제 설정: 수천 명의 사용자 디바이스마다 있는 SQLite 데이터베이스에 100만 행 이상을 빠르고 메모리 효율적으로 삽입해야 하는 상황. (SQLite 데이터베이스는 전 세계에 1조 개 이상 존재한다는 통계 언급)
- 이번엔 최상위 모델(state-of-the-art) 사용: Claude Fable 5(X-high 모드)와 GPT-5.6 Soul(X-high 모드)을 아키텍트/빌더로 배정.
/opinion실행 결과: Fable 5는 약 90초 만에 완료하며 최고 300배 속도 향상을 제시. GPT-5.6 Soul은 8분이 걸렸고(Fable 대비 약 2배 비용), 250배~10,000배, 그리고 별도로 400배~2000배 속도 향상 구간을 제시했다./fusion으로 "속도와 RAM 두 축에서 대량 삽입 문제를 확정 짓는 벤치마크 스크립트를 함께 설계하라"고 지시(Astral UV 단일 파일 스크립트, 표준 라이브러리만 사용, 100만 행, 동일 스키마 생성, 피크 RAM 측정 등 세부 조건 명시).- 최종 퓨전 결과: 속도 우승 전략은 "set-based CTE"로 약 8,000배(원문 표현 기준 "a thousand x" 수준의 대폭 향상) 속도 향상을 달성했고, 메모리 우승 전략은 "WAL 튜닝 생성(wal tuned generation)"이었다. 최종적으로는 SQLite 네이티브 autocommit 대비 최대 560배 속도 향상을 보고했다.
- 합의/발산 분석: 두 모델 모두 독립적으로 "서브프로세스 단위 전략 격리", "결정론적 데이터셋" 등에 동의했지만, 빌더(GPT-5.6 Soul)의 해법은 더 단순하고 빨랐고, 아키텍트(Fable 5)의 3-컬럼 스키마와 "셔플된 두 번의 실행 중앙값을 단일 실행 순서로" 같은 아이디어는 더 단순했다. 결국 최종 결과는 양쪽에서 서로 다른 아이디어를 골라 조합한 것.
메타포: "10명의 존(John)이 팀에 있는 게 가치가 아니라, 존·샐리·팀처럼 서로 다른 사람이 있는 게 가치다" — 다양한 관점의 범위가 진짜 가치를 만든다는 비유.
추가로 언급된 다른 하니스 패턴들:
/debate— 라운드 수를 지정해 에이전트들이 아이디어/컨셉/아키텍처를 놓고 토론하게 함/parallel— opinion과 달리 두 에이전트를 동시에 실행만 시킴(응답만, edit/write 툴 없음)- coordinate류 패턴 — 에이전트들이 해법을 서로 논의한 뒤 실제로 빌드까지 하게 함
4. 실행 포인트 & 시사점
- 모델을 하나 고르지 말 것: 워크호스급(Claude Sonnet 5, GPT-5.6 Terra)부터 최상위급(Claude Fable 5, GPT-5.6 Soul)까지, 상황에 맞게 모델 조합을 바꿔 쓰되 "단일 모델·단일 제공사·단일 에이전틱 코딩 툴"에 고정되는 것 자체가 리스크라는 인식을 가질 것.
- 하니스를 직접 소유하라: "누가 당신의 에이전트 하니스를 소유하느냐가 곧 당신의 결과를 소유한다." Claude Code, Codex, Open Code처럼 커스터마이징이 제한된 툴에 갇히지 말고, 커스터마이즈·확장 가능한 툴(PI 코딩 에이전트 등)로 직접 나만의 퓨전 하니스를 만들 것을 권장. 툴이 곧 당신이 가능하다고 믿는 것의 한계를 정한다.
- 검증을 작업 앞에 배치하는 패턴을 도입하라: 매 프롬프트마다 작업이 시작되기도 전에 "이 작업이 끝났다는 걸 어떻게 증명할 것인가"를 검증 스크립트로 먼저 정의하면, 에이전틱 코딩의 두 가지 근본 제약(planning, reviewing) 중 리뷰 제약을 크게 완화할 수 있다.
- 에이전트 스택 사이의 divergence를 버리지 말고 활용하라: 여러 모델이 다르게 답한 지점이야말로 진짜 판단이 필요한 지점이라는 신호로 받아들이고, 상호 보완적인 답은 합쳐서 최종 결정에 반영할 것.
- 위임(delegation)과 퓨전(fusion)은 다르다: 단순히 서브 에이전트에게 작업을 던지는 것과, 두 에이전트가 팀으로서 서로의 결과를 검증·통합하는 것은 다른 차원의 워크플로우임을 구분해서 설계할 것.
- 소버린 AI 이슈를 염두에 둘 것: 회사의 프롬프트·워크플로우·IP를 지속적으로 빅랩에 넘기고 있다는 문제의식을 갖고, 로컬/자체 컴퓨트 확보 논의를 장기적으로 준비할 필요가 있다(저자는 다음 주 영상에서 이 주제를 심화할 예정).
- 참고: 저자가 지난 주 다룬 "loop engineering"에서 SDLC(software developer life cycle), ADW(AI developer workflows), software factory 개념으로의 전환을 다룬 영상과 이어지는 내용이므로, 퓨전 하니스는 ADW 안의 "단일 에이전트 노드" 하나로 이해하는 것이 맥락상 정확하다.
메타데이터
- 채널: IndyDevDan
- 영상 ID: AQl5Q-0l7FQ
- URL: https://www.youtube.com/watch?v=AQl5Q-0l7FQ
- 처리일: 2026-07-21