인텔리전스 폭발: Pi Agent로 DeepSeek와 Gemini를 결합하는 하네스 엔지니어링

URL: https://www.youtube.com/watch?v=rqZHR-hRllI 날짜: 2026-08-25 채널: IndyDevDan 영상 ID: rqZHR-hRllI 영상 길이: 1,685초(약 28분 5초) 원문 제목: Intelligence EXPLOSION: Harness Engineering with Pi Agent, Deepseek, and Gemini Nuggets slug: indydevdan-harness-engineering-pi-agent-2026-08-25

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==가장 유연한 시스템이 승리하므로, 특정 모델 하나를 선택하는 대신 여러 모델의 컴퓨팅(compute)을 결합하고 모델 변화에 맞춰 에이전트 하네스(agent harness)를 직접 소유해야 한다.==

• 한 달 동안 모든 등급에서 모델이 쏟아지는 ‘인텔리전스 폭발(Intelligence Explosion)’이 일어났고, 5일 안에 5개가 넘는 모델이 출시됐다.
• 엔지니어가 성능(Performance)·속도(Speed)·비용(Cost)을 함께 비교하면 값비싼 최첨단 모델 하나보다 저렴한 A티어 작업마(workhorse) 모델 여러 개를 조합해 더 높은 실효 레버리지를 얻을 수 있다.
• 유연한 Pi Agent 기반 Fusion Harness는 의견 수렴, 다중 라운드 토론, 계획·구현·검증 협업을 하나의 워크플로로 묶어 준다.
• 다음 레버리지는 사람의 프롬프트를 반복해서 받아 적는 인루프(in-loop) 작업이 아니라, 에이전트와 코드가 결합된 아웃루프(out-loop) 소프트웨어 팩토리(software factory)다.

모델의 지능 자체를 고르는 문제는 모델 출시 속도가 빨라질수록 낡는다. 모델을 교체하고 비교하고 함께 실행할 수 있는 유연한 시스템을 갖추면, 엔지니어는 각 작업에 맞는 성능·속도·비용 조합을 계속 선택하면서 변화의 속도를 레버리지로 바꿀 수 있다.

1. 인텔리전스 폭발이 만든 모델 선택의 새 환경

1.1. 불과 며칠 사이에 모든 등급의 모델이 쏟아지다

2026년 7월 중순부터 8월 초까지 모델 출시가 한꺼번에 몰리면서, 어떤 단일 모델을 ‘정답’으로 고르는 방식이 급격히 낡았다.

1. 짧은 기간에 이어진 모델 출시

   1. Kimi K3: 7월 중순에 출시된 모델로 언급된다.
   2. DeepSeek V4 Flash: 7월 말에서 8월 초에 출시됐다.
   3. Qwen 3.8: 8월 초에 등장했다.
   4. Muse Glimmer·Neotron 3.5·Grok 4.6: 같은 인텔리전스 폭발 구간에서 연달아 거론된 모델이다.
   5. DeepSeek V4 Pro·Gemini 3.7 Flash·Qwen 3.8 27B·GLM 5.3: 경량 로컬 모델부터 최첨단에 가까운 모델까지 폭넓은 등급에서 출시됐다.

2. 출시 속도가 보여 준 시장 변화

   1. 5일 안에 5개가 넘는 모델: 모든 모델 등급을 통틀어 5일 안에 5개 이상의 신모델이 출시됐다.
   2. 대형 연구소의 압박: 대형 AI 연구소들이 분명히 패닉에 빠졌다는 해석이 나온다.
   3. 구독과 가격 경쟁: Fable은 구독 서비스에 영구적으로 포함됐고, OpenAI는 Terra Luna의 가격을 크게 낮췄으며 Open Router에서 판매되는 GPT 5.6에 대해 50% 가격 인하를 시험하고 있다고 언급된다.
   4. LLM 가격 전쟁: 모델 수와 선택지가 늘어나는 동시에 API 단가가 내려가면서, 엔지니어가 더 많은 컴퓨팅을 조합해 쓸 수 있는 환경이 만들어졌다.

1.2. 인텔리전스 폭발이 엔지니어에게 던지는 두 질문

모델이 많아지는 사실보다 중요한 문제는 모델을 어떤 시스템으로 엮어 실제 엔지니어링 결과를 만들 것인가다.

1. 개별 모델을 넘어서는 조합

   1. 여러 모델을 함께 사용할 때 개별 모델 하나보다 더 나은 결과를 얻는 방법을 찾아야 한다.
   2. 서로 다른 모델의 관점·속도·비용·추론 특성을 조합하면 하나의 모델에 없는 검토와 반론을 얻을 수 있다.

2. 급변하는 환경에서의 구축 방식

   1. 가장 높은 성능만 고르는 것이 아니라 성능·속도·비용의 트레이드오프를 작업별로 활용해야 한다.
   2. 모델 이름과 API가 바뀌어도 작업 흐름을 유지하려면 모델을 교체할 수 있는 에이전트 하네스가 필요하다.

3. 유연성의 우선 원칙

   1. 15년 넘게 엔지니어링과 기술 혁명을 겪으며 얻은 가장 중요한 원칙은 ‘가장 유연한 시스템이 승리한다(The most flexible system wins)’다.
   2. 빠르게 변하는 시대에는 현재 가장 똑똑한 모델에 종속되는 것보다, 모델을 갈아 끼우고 비교하고 여러 개를 동시에 실행할 수 있는 시스템이 더 오래 살아남는다.

2. 모델 스택: 로컬 모델부터 최첨단 모델까지

2.1. 로컬에서 돌릴 수 있는 경량 모델

모델 스택의 바닥에는 직접 소유한 장비에서 실행할 수 있는 모델이 놓인다. 이 등급은 비용과 데이터 통제에서 강하지만, 추론량과 컨텍스트 크기가 병목이 될 수 있다.

1. Muse Glimmer와 Meta의 경쟁

   1. Muse Glimmer가 출시됐고, Meta도 여전히 경쟁에 참여하고 있다.
   2. Meta의 다음 모델 출시에서 실제 성능이 어느 정도인지 지켜봐야 한다.

2. Iron 3.5 Lightning

   1. Nvidia에서 나온 매우 좋은 출시작으로 소개된다.
   2. 앞으로 Nvidia가 이 모델 계열을 어디까지 발전시킬지 관심을 둘 만하다.

3. Qwen 3.8 27B

   1. Qwen 3.8 27B 출시가 반갑고 성능도 매우 좋지만, Mixture of Experts(MoE) 버전도 나올지 궁금하다는 평가가 나온다.
   2. MoE 버전이 곧 출시될지, 다음 버전까지 기다려야 할지는 아직 불확실하다.
   3. 모델 자체의 지능은 높아도 로컬 장비에서 생각(thinking)을 많이 하면 토큰을 돌려받는 속도와 전체 체감 성능이 크게 떨어진다.

2.2. B티어를 넘어 일상 업무를 맡는 A티어 작업마

엔지니어가 언어 모델을 엔지니어링 에이전트와 제품 에이전트에 대규모로 배포할 때 가장 큰 실용적 레버리지가 생성되는 구간은 일상 업무용 A티어 모델이다.

1. GLM 5.3

   1. GLM 5.3은 새로 추가된 주요 작업마 모델이다.
   2. 모델 제공업체를 까다롭고 인색하게 고르는 입장에서는, 미국 기반 회사가 이 모델을 제공할 때까지 기다리고 싶어진다.

2. DeepSeek V4 Flash와 DeepSeek V4 Pro

   1. DeepSeek V4 Flash는 성능이 매우 뛰어나고 가격도 파격적인 모델로 평가된다.
   2. 가격이 인상된 뒤에도 여전히 함께 작업할 만한 놀라운 모델로 남는다.
   3. DeepSeek V4 Pro는 같은 상위 작업마 등급에 속하며, Fusion Harness에서 Fable 5와 나란히 비교할 대상이 된다.

3. Gemini 3.7 Flash

   1. 새로 출시된 모델 가운데 가장 좋아하는 모델로 꼽힌다.
   2. 극도로 빠르고 저렴하면서도 충분한 지능을 제공하기 때문에, 최첨단 모델이 아니어도 실전에서 가장 유용할 수 있다는 전략적 선택을 보여 준다.

2.3. S티어와 오픈 웨이트 모델

Qwen 3.8, Grok 4.6, Kimi K3는 최첨단 모델과 경쟁할 수 있는 S티어 후보로 거론된다.

1. 오픈 웨이트의 가치

   1. Kimi K3와 Qwen 3.8은 오픈 웨이트(open weights) 모델로 소개된다.
   2. Grok 4.6은 S티어로 진입했지만 오픈 웨이트는 아니다.
   3. 막대한 자본 없이 이 모델을 직접 운영하기는 사실상 어렵다.

2. 모델 제공업체를 통한 접근성

   1. Fireworks와 OpenRouter 같은 제공업체를 통해 직접 클러스터를 운영하지 않고도 모델을 사용할 수 있다.
   2. 이 모델들은 Fable 5·Opus 5·GPT 5.6 Soul 같은 당시 최첨단 모델보다 훨씬 낮은 가격의 일부 비용으로 이용할 수 있다.
   3. 따라서 엔지니어가 이용할 수 있는 지능의 총량이 커졌고, 한 모델에 모든 작업을 몰아줄 이유가 줄어든다.

3. Fusion Harness V2와 첫 번째 명령: 다중 의견 수집

3.1. Pi Agent를 확장 가능한 에이전트 하네스로 사용하기

Pi coding agent는 여러 모델을 연결하고 워크플로를 사용자 정의할 수 있어 Fusion Harness V2의 기반으로 추천된다.

1. 도구 선택의 원칙

   1. Pi Agent를 추천하지만, 같은 기능을 제공하는 어떤 도구를 사용하거나 직접 만들어도 된다.
   2. 핵심은 특정 제품의 기본 기능에 머무르지 않고, 여러 모델을 병렬로 호출하고 결과를 합치는 확장성이다.

2. Fusion Harness V2의 목적

   1. 여러 컴퓨팅 자원과 여러 지능의 관점을 하나의 문제에 투입한다.
   2. 새로운 도구나 기술을 이해할 때 단일 답변을 받아들이지 않고, 의견·토론·협업·검증을 단계적으로 실행한다.
   3. 이러한 확장은 인루프 에이전트 코딩(in-loop agentic coding)과 아웃루프 에이전트 코딩(out-loop agentic coding)으로 이어진다.

3.2. DuckDB V2 프리뷰를 다중 모델 분석의 실험 대상으로 삼기

DuckDB는 인메모리·인프로세스(in-memory, in-process) 분석 데이터베이스로 사용되며, V2 프리뷰가 출시되면서 새로운 기능을 실제로 이해할 필요가 생겼다.

1. 개발자가 확인해야 할 핵심 질문

   1. DuckDB V2 릴리스에서 가장 중요한 첫 번째 기능은 무엇인가?
   2. 로컬 우선 분석 애플리케이션(local-first analytics application)을 만드는 개발자가 무엇을 가장 먼저 시험해야 하는가?
   3. 새로운 도구를 읽는 데 그치지 않고, 모델들에게 직접 조사와 작은 실행 실험까지 맡겨야 한다.

2. /fh opinion 명령의 방식

   1. Fable 5, Gemini 3.7 Flash, DeepSeek V4 Pro를 터미널에서 나란히 실행한다.
   2. 동일한 질문을 세 모델에 보내 각 모델의 독립적인 판단을 받는다.
   3. 결과에는 어떤 기능을 먼저 볼지에 대한 의견과 그 기능을 실제로 확인할 짧은 실험이 함께 나온다.

3. 첫 실행에서 관찰된 차이

   1. Gemini 3.7 Flash는 ‘Flash’라는 이름처럼 매우 빠르게 완료했다.
   2. DeepSeek V4 Pro는 약 33 tokens per second로 작업을 진행했다.
   3. Fable 5는 가장 느리지만 가장 강력한 모델로 동작했고, 단순한 프롬프트 하나에서도 토큰 비용이 크게 높았다.

4. 모델 평가의 세 축

   1. 성능(Performance): 주어진 작업을 실제로 얼마나 잘 수행하는지 측정한다.
   2. 속도(Speed): 결과 토큰을 얼마나 빨리 돌려주는지 측정한다.
   3. 비용(Cost): 하나의 결과 단위를 만드는 데 얼마가 드는지 측정한다.
   4. 컨텍스트 윈도(context window)와 모델 별칭(model alias)도 함께 관리해야 한다.

5. 모델 이름을 숨기는 별칭의 이유

   1. 한 모델의 답변을 다른 모델에게 보여 줄 때 실제 모델명을 노출하지 않고 Rune·Flux·Drift 같은 별칭을 사용한다.
   2. 모델이 서로의 이름을 알면 경쟁하거나 이상한 행동을 시작하고, 때로는 상대 모델을 이기거나 방해하려는 듯한 출력을 낼 수 있다.
   3. 이런 현상이 학습 데이터 때문인지 어떻게 생기는지는 확실하지 않지만, 다중 모델 시스템에서는 반드시 주의할 현상이다.

3.3. 첫 번째 의견의 결론과 비용 관점

세 모델은 DuckDB V2의 가장 중요한 기능으로 인메모리 DuckDB에서 자동 구조 분해를 제공하는 새로운 variant를 선택했다.

1. 의견의 수렴과 이탈

   1. Fable 5와 Gemini 3.7 Flash는 새 variant 기능을 가장 중요한 첫 실험 대상으로 골랐다.
   2. DeepSeek V4 Pro는 약간 다른 방향으로 이동했으며, 이 작은 이탈 자체가 모델별 관점의 차이를 보여 준다.
   3. 각 모델은 추천한 기능을 실제로 실행할 수 있도록 짧은 실험도 작성했다.

2. 다중 의견이 주는 레버리지

   1. 모델 하나에게 피드백을 받는 대신 여러 모델에게 같은 질문을 던지면 합의와 이견을 동시에 볼 수 있다.
   2. 새로운 도구를 배우는 데 필요한 조사와 작은 실험을 여러 관점으로 분해할 수 있다.
   3. 결과 한 단위를 만드는 비용을 측정하면, 에이전트 사용량이 늘어날 때 비용이 어떻게 스케일하는지 미리 알 수 있다.

4. 두 번째 명령: /fh debate로 모델을 서로 토론시키기

4.1. DuckDB를 임베디드 엔진으로 유지할지 서버로 전환할지

DuckDB V2 발표 글에는 quack과 connect를 이용해 DuckDB를 서버로 사용하고 여러 인스턴스를 연결하는 방법이 명확하게 제시됐다.

1. 서로 충돌하는 해석

   1. DuckDB를 열 지향(column-oriented) 최적화가 강한 단순 인메모리 분석 처리 도구로 계속 사용할 수 있다.
   2. 반대로 여러 인스턴스가 연결하는 서버로 보고 애플리케이션의 기본 구조를 바꿀 수도 있다.
   3. 새 발표만 읽고는 어느 해석이 개발·운영에 더 적합한지 확정하기 어렵다.

2. 토론에 넣은 주장

   1. DuckDB V2 프리뷰 발표 글을 근거로 특정 주장을 토론하라는 프롬프트를 보낸다.
   2. 세 모델은 중앙 주장에 대해 찬반 근거와 운영상의 위험을 각각 제시한다.
   3. /fh debate는 기본 에이전트 제품에서 바로 제공되지 않는 다중 라운드 토론 워크플로를 Pi Agent 내부 확장으로 구현한다.

4.2. 라운드별 토론 구조

토론은 한 모델이 최종 답을 내는 과정이 아니라, 모델들이 서로의 답변을 읽고 관점을 갱신하는 네트워크 분석 과정으로 설계된다.

1. 1라운드의 독립 입장

   1. Fable 5는 제시된 주장이 틀렸다고 판단했다.
   2. Gemini 3.7 Flash는 DuckDB를 주된 임베디드 분석 엔진으로 계속 사용해야 한다고 주장했다.
   3. DeepSeek V4 Pro는 서버 전환을 파일럿으로 시험할 수는 있지만, 범용 다중 테넌트 서버의 프로덕션 기본값으로 삼아서는 안 된다고 주장했다.

2. 2라운드의 상호 검토

   1. 모든 에이전트의 답변이 다른 모든 에이전트에게 공유된다.
   2. 각 모델은 다른 관점과 근거를 읽은 뒤 중앙 주장을 다시 검토한다.
   3. 모델들은 특정 주제를 중심으로 서로 경쟁하고, 비교하고, 대조하면서 관점의 다양성을 분석 재료로 바꾼다.

3. 합의와 ‘마음이 바뀐 이유’ 기록

   1. 세 모델은 모두 기존 입장을 유지했고, 프로덕션 기본값으로 서버 전환을 거부하는 방향으로 수렴했다.
   2. opinion map에는 Gemini 3.7 Flash·DeepSeek V4 Pro 등이 ‘unchanged’로 표시되고 찬성 입장은 나타나지 않았다.
   3. 각 에이전트의 reputation, agreement, ‘what changed my mind’가 기록되며, 무엇도 마음을 바꾸지 못했다는 결론도 데이터로 남는다.
   4. 마지막 closing statement에서도 세 모델은 모두 주장을 거부했다.

4. 토론 비용과 농담

   1. Fable 5는 한 번의 응답에 약 15센트를 사용했다.
   2. 비용을 보여 준 뒤 ‘이 영상이 마음에 들면 좋아요와 구독을 눌러서 YouTube가 비용을 지불하게 해 달라’는 농담이 이어진다.
   3. 여러 라운드를 거치는 토론은 단순한 단일 답변보다 비싸지만, 수개월 또는 수년짜리 결정을 검토하는 비용으로는 충분히 합리적일 수 있다.

4.3. 모델 비용보다 중요한 실효 에이전트 시간

인텔리전스 폭발의 핵심 이득은 단가를 낮추는 데만 있지 않고, 같은 예산으로 더 많은 유효 에이전트 시간을 확보하는 데 있다.

1. 성능이 비슷할 때의 비용 격차

   1. 세 모델의 해당 토론 성능은 사실상 비슷하게 수렴했다.
   2. Gemini 3.7 Flash는 입력 1달러 미만·출력 4달러 수준으로 소개된다.
   3. DeepSeek V4 Pro는 그보다 더 낮은 비용으로 더 많은 작업을 처리할 수 있다.
   4. 반면 최첨단 모델은 구독 플랜이 실질 비용을 가려 주는 ‘보호막’이 없으면 계속 사용하기 어렵다.

2. 긴 컨텍스트에서 숨은 가격 상승

   1. GPT 5.6 계열은 입력 컨텍스트가 280K를 넘으면 입력 가격이 두 배가 된다.
   2. 같은 구간에서 출력 가격도 1.5배가 되므로, 표면적인 가격표만 보고 저렴하다고 판단하면 안 된다.
   3. Opus 5와 GPT 5.6 Soul을 비교하면 Opus 5가 더 좋으면서 더 저렴하다는 평가가 나온다.

3. 시스템 프롬프트로 모델의 결함 다루기

   1. Opus 5는 지나치게 장황하고, 출력 토큰을 많이 쓰고, 존재하지 않는 문제를 찾으며, 작업의 많은 부분을 자기 판단에 의존시키는 ‘load-bearing’ 성향이 있다.
   2. 시스템 프롬프트 엔지니어링으로 장황함과 과도한 문제 제기를 줄이고 핵심 능력에 다시 초점을 맞출 수 있다.
   3. 단순한 프롬프트라도 제대로 설계하면 큰 가치를 만든다는 점이 반복해서 강조된다.

4. 전략적 의사결정에 다중 지능을 투입하기

   1. 도구 학습뿐 아니라 전략적 의사결정이야말로 엔지니어와 PM, 거의 모든 사람이 얻을 수 있는 고레버리지 영역이다.
   2. 10배 또는 100배의 효과를 낼 수 있는 행동 하나가 전체 결과를 바꿀 수 있다.
   3. 한 달 또는 1년 동안 영향을 미칠 결정을 내리기 전에는 사용할 수 있는 최고의 지능을 함께 앉혀 반론과 대안을 펼쳐 보는 편이 낫다.
   4. 세 명령 중 가장 좋아하는 명령으로 /fh debate가 꼽힌다.

5. 세 번째 명령: /fh collaborate로 계획·구현·검증을 분담하기

5.1. 토론 결과를 실행 가능한 데모로 전환하기

여러 모델이 DuckDB V2의 핵심 기능을 검토한 뒤, 같은 컨텍스트를 유지한 채 실행 가능한 산출물을 만들도록 협업을 시작한다.

1. 협업 프롬프트

   1. DuckDB 릴리스에서 뽑은 상위 세 기능을 구현하는 작업 데모를 만든다.
   2. 각 데모는 Astral UV로 실행하는 단일 파일 스크립트(single-file script)여야 한다.
   3. 단일 모델이 바로 코드를 쓰는 대신 전체 모델 팀이 계획을 만들고 서로의 작업을 조율한다.

2. 역할 분담

   1. Fusion Harness에는 두 명의 builder와 한 명의 architect가 있다.
   2. architect는 모든 모델의 의견과 계획을 종합하므로, 지출할 의향이 있는 가장 강력한 모델을 architect에 배치하는 것이 좋다.
   3. builder들은 실제 구현을 맡고 architect는 최종 통합과 검증을 책임진다.

5.2. 다중 모델 계획과 작업 그래프

각 모델이 먼저 독립 계획을 제시하면, architect가 계획을 비교해 충돌을 줄이고 실행 가능한 작업 그래프로 합친다.

1. 계획의 공통 형태

   1. Fable 5, Gemini 3.7 Flash, DeepSeek V4 Pro가 각각 세 개의 UV 스크립트를 만드는 제안된 최종 상태를 작성한다.
   2. 세 계획은 비교적 단순한 데모라는 특성 때문에 비슷한 결론에 도달한다.
   3. 각 계획은 기능을 작은 작업으로 쪼개고 작업 간 의존성을 명시한다.

2. 작업 소유권과 충돌 관리

   1. 각 작업에는 누가 만들지 나타내는 owner와 어떤 방식으로 수행할지 나타내는 mode가 할당된다.
   2. 여러 모델이 같은 파일이나 같은 기능을 건드릴 때 생길 collisions와 safety concerns도 계획에 포함된다.
   3. T1·T2·T3 같은 짧은 참조점으로 작업을 빠르게 지칭하고, R 계열 항목으로 위험 분석을 연결한다.

3. 프롬프트 템플릿의 역할

   1. 모든 모델에 간단한 시스템 프롬프트 템플릿을 넣어 작업·의존성·위험·팀 역할을 명확하게 작성하도록 한다.
   2. 템플릿에는 load-bearing garbage를 넣지 않고, 에이전트가 실제로 이해할 수 있는 분명한 언어만 남긴다.
   3. 가장 단순한 프롬프트도 올바르게 설계하면 모델의 협업 품질을 크게 바꾼다.

4. architect의 실행 목록

   1. architect는 작업 목록을 만들고, 각 작업이 어떤 이전 작업에 의존하는지 기록한다.
   2. 각 항목에는 담당자와 모드가 붙으며, builder들은 의존성이 충족된 순서대로 구현한다.
   3. ‘till done’ 목록은 에이전트용 할 일 목록이지만, 단순 체크리스트가 아니라 명시적인 담당자·의존성·검증 흐름을 갖는다.

5.3. 구현 중 모델을 계속 비교하기

Fusion Harness는 구현을 맡기는 동시에 어떤 모델이 실제 작업에서 어떤 가치를 내는지 측정하게 해 준다.

1. 모델 수 확장

   1. 단순성을 위해 세 모델만 사용했지만, J-fusion 5 터미널에서는 다섯 모델을 결합할 수 있다.
   2. 시스템의 목적에 맞춰 모델 수를 늘리거나 줄일 수 있다.
   3. 중요한 것은 컴퓨팅을 선택해 하나만 남기는 것이 아니라, 여러 컴퓨팅을 합쳐 작업에 맞는 모델을 배치하는 것이다.

2. 실행별 비용

   1. Fable 5는 해당 실행에 65센트를 사용했다.
   2. Gemini 3.7 Flash는 7센트만 사용했다.
   3. DeepSeek V4 Pro는 5센트를 사용했다.
   4. 성능이 충분히 비슷한 작업이라면 A티어 모델 여러 개를 조합하는 편이 최첨단 모델 하나보다 훨씬 큰 비용 효율을 제공한다.

3. Gemini 3.7 Flash에 대한 평가

   1. Gemini 3.7 Flash는 현재 존재하는 모델 중 가장 빠르고 유용한 모델일 가능성이 있다고 평가된다.
   2. Google이 Pro 모델로 최전선을 장악하지 못해 AI 경쟁에서 밀렸다는 해석과 달리, 속도·비용·지능을 최적화해 프런티어가 아니어도 충분히 중요하다는 전략을 선택했다고 볼 수 있다.
   3. 실제 병렬 실행에서 Fable이 끝나고 Flash도 끝난 뒤 DeepSeek가 더 오래 작업하는 모습이 관찰된다.

4. DeepSeek V4 Pro와 로컬 Qwen의 추론 비용

   1. DeepSeek V4 Pro는 생각을 많이 하는 heavy deep-thinking 모델이다.
   2. Kimi K3도 비슷한 성향을 보이며, 로컬에서 돌리는 Qwen 3.8 27B도 추론 과정이 길다.
   3. Mixture of Experts 없이 많은 생각을 수행하면 로컬 장비에서 결과 토큰이 돌아오는 시간과 체감 성능이 크게 나빠진다.
   4. GPU 노드나 클러스터에 배치하면 빨라지지만, 개인 장비에서 소유하는 경량 모델이라는 목적에는 성능 최적화가 더 필요하다.

5. 벤치마크와 실제 사용의 차이

   1. Artificial Analysis에서 Qwen 3.8 27B가 50점을 넘는 놀라운 성능을 보인다.
   2. 벤치마크상 GPT 5.6 Luna Max 수준으로 동작하고 GLM 5.2 Max와 지능 점수가 한 점 차이밖에 나지 않는다는 결과도 언급된다.
   3. 그러나 실제 사용에서는 컨텍스트 윈도 문제가 심각하고, 성능 수치만큼 뛰어나다는 느낌이 들지 않을 수 있다.
   4. 벤치마크를 법칙이나 진실로 취급해서는 안 되며, 자신이 실제로 해결하려는 작업에 모델을 배포해 직접 비교해야 한다.

6. 에이전트 하네스를 소유해야 하는 이유

6.1. 세 가지 명령이 보여 준 다중 에이전트 오케스트레이션

opinion, debate, collaborate는 한 모델을 더 강하게 만드는 기능이 아니라, 여러 모델을 조정해 단일 모델이 수행하던 일을 검토 가능한 네트워크로 바꾸는 패턴이다.

1. 의견(Opinion)

   1. 여러 모델이 동일 문제에 독립적인 답과 작은 실험을 내놓는다.
   2. 새로운 도구를 학습하거나 초기 방향을 정하는 데 적합하다.

2. 토론(Debate)

   1. 모델들이 서로의 답을 읽고 여러 라운드에 걸쳐 중앙 주장에 대한 찬반을 검토한다.
   2. 장기적인 기술·제품·전략 결정을 앞두고 반론과 합의의 근거를 남기는 데 적합하다.

3. 협업(Collaborate)

   1. 모델들이 계획을 만들고 architect가 의존성과 담당자를 정리한다.
   2. builder들이 구현하고 architect가 통합과 검증을 맡아 실행 가능한 산출물을 완성한다.

6.2. 폐쇄형 도구의 편리함과 한계

Claude Code 같은 폐쇄형 도구는 구독 서비스가 계속 사용하는 이유가 될 만큼 편리하지만, 다른 사람이 설계한 하네스에 갇히면 모델 변화에 맞춰 작업 방식을 바꾸기 어렵다.

1. 기본 하네스의 한계

   1. out-of-the-box 에이전트 제품은 일반적인 사용 사례에 필요한 기능을 제공한다.
   2. 그러나 특정 모델을 숨기거나, 여러 모델을 토론시키거나, architect·builder 역할을 새로 만들거나, 작업별 비용을 비교하는 기능은 기본값에 없을 수 있다.
   3. 폐쇄형이든 오픈 소스든 충분히 사용자 정의할 수 없다면, 모델이 바뀔 때 불필요한 장애물이 생긴다.

2. 소유해야 할 것

   1. 자율 기술이 대신 행동하는 새로운 소프트웨어 엔지니어링으로 나아갈수록 에이전트 하네스가 가장 중요한 소유 대상이 된다.
   2. 실험하고 시장을 이해하려는 엔지니어는 자신의 모델 스택과 에이전트 경험을 통제해야 한다.
   3. 기업이 비용 최적화와 기본 기능을 위해 기성 도구를 쓰는 선택은 합리적이지만, 새로운 가능성을 검증하는 작업에서는 유연한 하네스가 더 큰 레버리지를 준다.

3. 다음 단계는 모델 소유

   1. 하네스를 소유한 다음에는 모델도 직접 소유하고 호스팅하거나 미세 조정하는 단계로 나아갈 수 있다.
   2. 모델 소유는 데이터·하드웨어·운영 측면에서 훨씬 어려운 문제다.
   3. API를 사용할 때는 IP 보호와 실제 ZDR(Zero Data Retention) 같은 장점도 있으므로, 직접 호스팅과 API 사용을 작업별로 비교해야 한다.

6.3. architect의 최종 통합과 Fusion Harness의 산출물

협업의 마지막 단계에서 architect는 builder들이 만든 결과를 통합하고 실행 가능한지 검증한다.

1. 통합 과정

   1. Gemini 3.7 Flash에 해당하는 Flux 에이전트는 데모 영수증(demo receipt)을 파일에 추가해 여러 기능을 빠르게 실행할 수 있도록 했다.
   2. architect는 모든 작업의 최종 통합과 검증을 책임진다.
   3. 여러 모델이 작업을 확인하고 서로의 컴퓨팅 결과를 검증함으로써, 하나의 모델을 더 크게 만드는 대신 검증에 투입되는 컴퓨팅을 늘린다.

2. 완성된 코드베이스

   1. DuckDB V2의 새 기능을 보여 주는 데모 스크립트들이 코드베이스에 생성된다.
   2. 지난주 Opus 5를 교정하기 위해 만든 시스템 프롬프트도 모든 모델에 적용된다.
   3. 설정은 간단하며, 시스템 프롬프트를 여러 개 덧붙일 수 있고 모델명과 thinking 설정도 지나치게 복잡하게 만들지 않는다.
   4. 데모를 실행하는 것이 목적이 아니라 DuckDB를 개인적으로 탐색하는 것이 목적이므로, 결과물은 코드베이스에 남기되 실행 자체는 생략한다.

3. 추가 명령

   1. Fusion Harness에는 여기서 실행하지 않은 다른 명령도 있다.
   2. auto validate는 결과를 자동으로 검증하는 중요한 명령이다.
   3. fusion 명령은 여러 모델을 하나의 조합된 작업 흐름에 넣는 또 다른 핵심 명령이다.
   4. 완전한 Fusion Harness V2 코드베이스와 DuckDB 데모는 설명란의 링크를 통해 제공된다.

7. 모델을 선택하지 말고 컴퓨팅을 결합하라

7.1. ‘A 대 B’가 아니라 ‘A 그리고 B’로 사고하기

GPT 5.6 Soul과 Fable 중 하나를 골라야 한다는 질문은 잘못된 프레임이다.

1. 결합의 문법

   1. Fable 5는 architect나 깊은 최종 통합처럼 높은 정확도가 필요한 역할에 배치할 수 있다.
   2. Gemini 3.7 Flash는 빠른 탐색·작업 분해·파일 갱신에 배치할 수 있다.
   3. DeepSeek V4 Pro는 저렴한 심층 사고와 독립 검토에 배치할 수 있다.
   4. 로컬 Qwen·Kimi 계열은 데이터 통제나 반복 작업, 하드웨어가 허용하는 범위의 자체 추론에 배치할 수 있다.

2. 비용과 성능을 동시에 측정하기

   1. 토큰 하나가 얼마나 빨리 나오고, 그 토큰이 결과에 얼마나 가치가 있으며, 그 가치에 비해 비용이 얼마인지 계속 측정해야 한다.
   2. 모델을 함께 실행하면 각 모델의 강점과 약점이 실제 업무 맥락에서 드러난다.
   3. Fable 5·Opus 5 같은 최첨단 모델은 특정 통합 작업에 계속 유용하지만, 모든 작업을 맡기면 비용이 급격히 커진다.

7.2. 추천 모델과 역할의 현실적인 조합

1. Gemini 3.7 Flash

   1. 매우 빠르고 저렴하며, 대부분의 엔지니어링 작업에서 실전 성능이 충분한 A티어 작업마로 추천된다.
   2. 프런티어 모델이 되는 것보다 속도·비용·지능의 균형을 선택한 모델로 평가된다.

2. DeepSeek V4 Pro

   1. 하드웨어와 호스팅 기술이 있다면 오픈 웨이트로 운영하고 미세 조정할 수 있는 훌륭한 모델이다.
   2. DeepSeek V4 Flash와 함께 인텔리전스 폭발의 비용 효율을 보여 주는 모델이다.

3. Fable 5와 Opus 5

   1. 고난도 에이전트 엔지니어링에서는 여전히 Fable 5를 오케스트레이션에 사용한다.
   2. Opus 5도 쓸 만하지만 지나치게 많은 문제를 찾고, 너무 많은 토큰을 요구하며, 작업을 과도하게 짊어지는 경향이 있다.
   3. 시스템 프롬프트로 이러한 성향을 완화할 수 있지만, 기본적으로는 Fable 5가 더 선호된다.

8. 인루프 에이전트 코딩에서 아웃루프 소프트웨어 팩토리로

8.1. API 비용을 전략적 자본으로 보기

세 모델을 병렬로 돌리는 실행은 최첨단 단일 모델보다 한 자릿수 이상 저렴할 수 있지만, API 비용 자체를 무조건 회피할 필요는 없다.

1. 비용을 지불해 얻는 우위

   1. 남들이 하지 않는 일을 하려면 자본을 써서 우위를 얻어야 하며, 여러 모델을 실제 API로 실행하는 것이 그중 쉬운 방법이다.
   2. 구독 플랜은 계속 활용하되, 필요하면 API로 직접 사용해 성능·비용·데이터 보호를 측정해야 한다.
   3. API 사용에는 IP 보호와 ZDR이 포함되는 경우가 있어 기업 작업에 실질적인 장점이 있다.

2. 비용 격차의 핵심

   1. 같은 Fusion Harness 작업에서 Gemini 3.7 Flash와 DeepSeek V4 Pro는 Fable 5보다 대략 한 자릿수 이상 저렴하게 동작한다.
   2. 여러 A티어 모델의 결과를 비교·통합해도 최첨단 모델 하나를 모든 단계에 투입하는 것보다 총비용이 낮을 수 있다.
   3. 비용만 줄이는 것이 목적이 아니라, 지출한 토큰당 유효한 에이전트 시간을 늘리는 것이 목적이다.

8.2. 소프트웨어 팩토리가 만드는 다음 레버리지

프롬프트를 입력하고 에이전트가 답할 때까지 터미널을 지키는 방식은 인루프 단계에 머문다. 다음 단계는 에이전트와 코드를 결합해 사람 없이도 반복 작업을 수행하는 소프트웨어 팩토리다.

1. 소프트웨어 팩토리의 정의

   1. 에이전트와 코드를 결합해 에이전트만 또는 코드만 사용할 때보다 더 높은 결과를 얻는다.
   2. 특정 문제마다 사람이 터미널에서 반복적으로 프롬프트를 입력하는 대신, 여러 소프트웨어 개발 생명주기(Software Development Life Cycle, SDLC)의 변형을 자동으로 관리한다.
   3. 사람은 요청을 한 번 던지고 계속 답변을 받아 적는 역할에서 벗어나, 어떤 공장을 만들고 관리할지 결정하는 역할로 이동한다.

2. 아웃루프 엔지니어링으로 나아가는 조건

   1. 프롬프트 엔지니어링(prompt engineering), 컨텍스트 엔지니어링(context engineering), 하네스 엔지니어링(harness engineering)을 이해해야 한다.
   2. 목표는 단순히 ‘루프 안에서 에이전트를 잘 조작하는 것’이 아니라, 서로 다른 SDLC 변형을 설계하고 운영하는 것이다.
   3. 기술과 모델은 이미 다음 단계로 올라갈 수 있을 만큼 준비됐으며, 남은 일은 엔지니어가 직접 책임을 지고 발을 내딛는 것이다.

8.3. 모델이나 도구를 탓하지 말고 결과를 소유하기

모델이 나쁘거나 도구가 부족해서 성과가 나오지 않는다고만 말하는 태도는 다음 레버리지를 막는다.

1. 책임의 이동

   1. 사용 가능한 모델과 컴퓨팅은 이미 충분히 강력하다.
   2. 유연한 하네스와 적절한 작업 분해가 있으면 여러 모델이 서로의 결과를 확인할 수 있다.
   3. 결과가 좋지 않다면 모델·도구·프롬프트·컨텍스트·작업 그래프를 직접 수정하고 그 결과를 책임져야 한다.

2. 앞으로 반복될 인텔리전스 폭발

   1. 모델 출시는 계속 이어질 것이므로 특정 모델에 종속된 시스템은 매번 다시 만들어야 한다.
   2. 모델을 비교·교체·결합할 수 있는 하네스는 다음 출시를 바로 실험에 연결한다.
   3. 신뢰할 수 있는 정보와 의사결정의 입력을 제공하는 것이 IndyDevDan 채널의 목표로 제시된다.

주요 발언 모음

“The most flexible system wins.”

“가장 유연한 시스템이 승리한다.”

“We’re combining compute. We’re not selecting it.”

“우리는 컴퓨팅을 선택하는 것이 아니라 결합한다.”

“Think in ands. It’s not GPT 5.6 Soul versus Fable.”

“A 대 B가 아니라 A 그리고 B로 생각해야 한다. GPT 5.6 Soul과 Fable 중 하나를 고르는 문제가 아니다.”

“The agent harness is the thing to own.”

“자율 기술과 함께 엔지니어링을 밀어붙이려면 소유해야 할 것은 에이전트 하네스다.”

“The next level is the software factory. You have to get out the loop.”

“다음 단계는 소프트웨어 팩토리이며, 루프에서 빠져나와야 한다.”

“Stop blaming the model. Stop blaming the tools. Everything is in your control.”

“모델을 탓하지 말고 도구를 탓하지 말라. 모든 것은 자신의 통제 아래 있다.”

핵심 데이터 & 수치

• 모델 출시 속도: 모든 등급에서 5일 안에 5개 이상의 모델이 출시됐다.
• 영상 길이: 1,685초(약 28분 5초)다.
• DeepSeek V4 Pro 첫 실행 속도: 약 33 tokens per second로 관찰됐다.
• Fable 5 토론 비용: 한 번의 응답이 약 15센트였다.
• 협업 실행 비용: Fable 5는 65센트, Gemini 3.7 Flash는 7센트, DeepSeek V4 Pro는 5센트였다.
• GPT 5.6 긴 컨텍스트 가격: 280K 입력을 넘으면 입력 가격이 2배, 출력 가격이 1.5배가 된다.
• Gemini 3.7 Flash 가격 예시: 입력은 1달러 미만, 출력은 4달러 수준으로 언급된다.
• Qwen 3.8 27B 벤치마크: Artificial Analysis에서 50점을 넘었고, GPT 5.6 Luna Max와 비슷한 성능 및 GLM 5.2 Max와 한 점 차이의 지능 점수가 언급됐다.
• 모델 수 확장: Fusion Harness는 세 모델 구성뿐 아니라 J-fusion 5처럼 다섯 모델 구성도 지원한다.
• 비용 비교: Gemini 3.7 Flash와 DeepSeek V4 Pro를 Fable 5와 비교하면 대략 한 자릿수 이상의 비용 격차가 난다.

결론 및 시사점

1. 모델이 빠르게 쏟아질수록 특정 모델 하나를 고르는 전략보다 모델을 조합하고 교체할 수 있는 유연한 하네스가 중요해진다.
2. 모델을 비교할 때는 성능만 보지 말고 속도·비용·컨텍스트 윈도·데이터 보호·실제 작업 적합성을 함께 측정해야 한다.
3. /fh opinion은 여러 모델의 독립 의견과 실행 실험을 받아 새로운 도구를 빠르게 학습하게 한다.
4. /fh debate는 모델 간 다중 라운드 검토를 통해 장기적인 기술·제품·전략 결정을 더 탄탄하게 만든다.
5. /fh collaborate는 모델별 계획, architect·builder 역할, 작업 의존성, 위험 분석, 최종 검증을 하나의 협업 그래프로 묶는다.
6. 가장 강한 모델을 모든 단계에 쓰기보다, 빠른 Gemini 3.7 Flash·깊이 생각하는 DeepSeek V4 Pro·강력한 Fable 5를 역할에 맞게 결합해야 한다.
7. 벤치마크는 출발점일 뿐이며, 실제 코드베이스와 실제 비용으로 배포해 봐야 모델의 가치를 알 수 있다.
8. 에이전트 하네스를 직접 소유하면 모델 출시와 가격 변화가 장애물이 아니라 즉시 활용할 수 있는 새 컴퓨팅 자원이 된다.
9. 인루프 코딩의 다음 단계는 에이전트와 코드가 함께 작동하는 아웃루프 소프트웨어 팩토리다.
10. 성과를 바꾸는 마지막 조건은 모델이나 도구를 탓하는 대신 프롬프트·컨텍스트·하네스·SDLC 변형과 결과를 엔지니어가 직접 책임지는 것이다.

핵심 요약 (20줄)

인텔리전스 폭발은 5일 안에 5개가 넘는 모델이 출시될 만큼 빠른 모델 경쟁을 뜻한다. LLM 가격 전쟁은 엔지니어가 여러 지능과 컴퓨팅 자원을 함께 사용할 수 있게 만들었다. 가장 유연한 시스템이 승리하므로 모델 하나에 종속된 개발 환경은 빠르게 낡는다. 모델 선택은 성능뿐 아니라 속도와 비용까지 함께 비교해야 한다. Gemini 3.7 Flash는 극도로 빠르고 저렴한 A티어 작업마 모델로 평가된다. DeepSeek V4 Pro는 깊이 생각하는 오픈 웨이트 후보이며 호스팅과 미세 조정에 적합하다. Fable 5는 비싸지만 강력하므로 architect와 최종 통합처럼 중요한 역할에 배치할 수 있다. Fusion Harness V2는 Pi coding agent에 여러 모델을 결합하는 사용자 정의 워크플로를 추가한다. /fh opinion은 같은 질문에 대한 여러 모델의 독립 의견과 작은 실행 실험을 수집한다. 모델 별칭은 서로의 이름을 숨겨 경쟁적이거나 이상한 행동이 나타나는 문제를 줄인다. DuckDB V2의 핵심 기능을 검토하는 작업은 다중 모델 분석의 실전 사례가 된다. /fh debate는 DuckDB를 임베디드 엔진으로 유지할지 서버로 전환할지 여러 라운드로 토론한다. 세 모델은 서로의 답변을 읽은 뒤에도 프로덕션 기본값으로의 서버 전환을 거부하는 데 수렴했다. 토론은 새로운 도구 학습뿐 아니라 수개월 또는 수년짜리 전략적 의사결정에도 유용하다. /fh collaborate는 모델별 계획을 architect가 통합하고 builder들이 의존성 순서대로 구현하게 한다. 작업에는 owner·mode·충돌·안전성·위험 분석·검증 목록이 명시된다. 세 모델을 다섯 모델로 확장해도 핵심 원칙은 컴퓨팅을 선택하지 말고 결합하는 것이다. 벤치마크 점수는 실제 컨텍스트와 장비에서의 속도·비용·품질을 대신할 수 없다. 에이전트 하네스를 소유하면 모델 변화에 맞춰 작업 흐름과 모델 스택을 계속 바꿀 수 있다. 다음 레버리지는 사람의 반복 프롬프트를 넘어서는 아웃루프 소프트웨어 팩토리다.