Intelligence EXPLOSION: Harness Engineering with Pi Agent, Deepseek, and Gemini

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

지능 폭발 시대의 핵심은 Pi Agent 기반의 유연한 하네스에서 DeepSeek·Gemini 같은 모델을 함께 조합해 성능·속도·비용의 최적점을 찾는 것이다.

📌 핵심 요점

1. 화자는 짧은 기간에 여러 등급의 모델이 연이어 출시되고 가격 경쟁까지 격화된 상황을 지능 폭발로 규정하며, 특정 모델을 고르는 능력보다 변화에 적응하는 유연한 시스템이 중요하다고 주장한다.
2. Fusion Harness의 opinion 명령은 동일한 질문을 여러 모델에 병렬로 제시하고 결과·속도·비용을 나란히 비교해, 한 모델의 답에 의존하지 않고 복수 관점과 단위 결과의 비용을 확인하게 한다.
3. debate 명령은 모델들이 각자 입장을 낸 뒤 서로의 답을 공유하고 재검토하게 한다. DuckDB를 범용 서버처럼 써야 한다는 주장에 대해서는 세 모델 모두 기존 임베디드 분석 엔진 역할을 유지하면서 제한적으로 시험해야 한다는 방향에 수렴했다.
4. collaborate 명령은 여러 모델의 계획을 모은 뒤 강력한 모델을 architect로, 나머지를 builder로 배치하고 작업 소유자·의존성·위험·검증 절차를 지정해 실제 산출물을 공동 제작하게 한다.
5. 화자의 최종 주장은 combine compute, don’t select compute에 가깝다. 모델별 강점을 조합하는 하네스를 소유하고 이를 outloop agentic coding과 software factory로 확장해야 다음 단계의 엔지니어링 레버리지를 얻을 수 있다는 것이다.

🧩 배경과 문제 정의

• 화자는 짧은 기간에 경량·실무형·최상위 모델이 대거 등장하고 가격 인하 경쟁까지 벌어지는 상황을 지능 폭발로 정의한다.
• 엔지니어에게 주어진 문제는 단일 최강 모델을 찾는 것이 아니라 여러 모델을 함께 사용해 개별 모델보다 나은 결과를 얻고, 성능·속도·비용 변화에 유연하게 대응하는 것이다.
• 이를 위해 화자는 Pi coding agent를 확장한 Fusion Harness V2를 제시하고 opinion, debate, collaborate라는 세 가지 멀티모델 오케스트레이션 패턴을 시연한다.

🕒 시간순 섹션별 상세정리

1. 모델 출시 러시와 지능 폭발

• 화자는 수일 사이 여러 등급의 모델이 연속 출시되고 가격 경쟁이 격화됐다며 이를 intelligence explosion으로 규정한다. [00:48]
• 엔지니어가 풀어야 할 질문은 모델들을 함께 사용해 개별 성능을 넘어서는 방법과, 성능·속도·비용이 빠르게 변하는 시대에 적응하는 방법이다. [01:08]
• 기술 혁명기에는 가장 유연한 시스템이 이긴다는 원칙을 제시하고 Fusion Harness V2를 보여준다. [01:45]

2. 새 모델 스택과 실무형 컴퓨트

• 화자는 로컬 경량 모델부터 일상 업무용 A급 모델, 고성능 모델까지 자신의 모델 스택을 훑으며 엔지니어가 선택할 수 있는 컴퓨트가 넓어졌다고 보여준다. [03:09]
• DeepSeek V4 Flash·V4 Pro와 Gemini 3.7 Flash를 높은 가격 대비 성능을 지닌 실무형 모델로 평가하고, Gemini를 이번 출시군 중 가장 선호한다고 드러낸다. [03:47]
• 오픈 웨이트급 모델도 제공자를 통해 프런티어 모델보다 낮은 가격에 접근할 수 있어 활용 가능한 지능의 폭이 커졌다고 평가한다. [04:18]

3. Opinion 명령으로 동일 질문 병렬 비교

• Fusion Harness에서 Fable 5, Gemini 3.7 Flash, DeepSeek V4 Pro에 DuckDB V2의 가장 중요한 기능을 묻고 세 답을 병렬로 생성한다. [05:37]
• 비교 기준은 작업 성능, 응답 속도, 비용이며 모델 alias를 사용해 모델들이 서로의 정체를 알지 못하게 한다. [06:28]
• 세 모델의 관점과 간단한 실험안을 함께 보고, 한 모델이 아니라 n개 모델을 사용하되 결과 한 단위를 얻는 비용까지 측정해야 한다고 강조한다. [07:43]

4. Debate 명령과 다회전 반론

• DuckDB를 서버처럼 사용할 수 있다는 발표를 두고, 임베디드 분석 엔진인지 다중 인스턴스용 서버인지 세 모델에게 토론시킨다. [08:32]
• 첫 라운드에서 세 모델은 모두 범용 멀티테넌트 서버를 기본값으로 삼지 말고 기존 임베디드 역할을 유지하거나 제한적으로 시험해야 한다는 쪽에 선다. [09:22]
• 각 모델의 답을 다른 모델들에게 공유한 뒤 재검토시키지만 입장은 바뀌지 않았고, 최종적으로 세 모델 모두 해당 주장을 기각한다. [11:18]

5. 비용 격차와 전략적 의사결정

• 화자는 고가 프런티어 모델과 A급 실무형 모델의 성능이 이번 과제에서는 비슷했지만 비용 차이는 컸다고 설명하며, 단순 토큰 가격보다 effective agent hour per token cost를 중시한다. [12:03]
• 긴 컨텍스트에서 가격이 달라질 수 있고 모델마다 장단점이 있으므로, 여러 컴퓨트를 조합하는 모델 스택이 필요하다고 주장한다. [13:17]
• debate는 기술 학습뿐 아니라 장기간 영향을 주는 전략적 의사결정에서 반론과 복수 관점을 확보하는 데 특히 가치가 있다고 드러낸다. [14:04]

6. Collaborate 명령과 공동 계획 수립

• 세 모델에게 DuckDB V2의 주요 기능 세 가지를 Astral UV 단일 파일 스크립트로 구현하라고 지시해 협업 워크플로를 시작한다. [14:39]
• 모든 모델이 각각 계획을 제출하고, 두 builder와 한 architect로 역할을 나누며 가장 강력한 모델을 architect에 배치하라고 권한다. [15:36]
• 계획에는 작업별 의존성, 담당자, 충돌과 안전 우려, 위험 분석, 공통 참조점이 포함되며 시스템 프롬프트가 구조를 안내한다. [16:57]

7. Architect 중심의 작업 배분과 실행

• architect는 여러 계획을 통합해 작업 목록, 소유자, 실행 방식과 의존성을 지정하고 에이전트들은 완료될 때까지 체크리스트를 수행한다. [17:34]
• 세 모델뿐 아니라 다섯 모델 구성으로도 확장할 수 있으며, 핵심은 컴퓨트를 하나만 고르는 것이 아니라 작업에 맞게 조합하는 데 있다고 보여준다. [18:06]
• 화자는 inloop와 outloop 작업에서 각 토큰의 속도·가치·비용을 계속 비교해야 한다고 강조한다. [18:23]

8. 모델별 비용·속도와 벤치마크의 한계

• 시연 실행 비용으로 Fable은 65센트, Gemini는 7센트, DeepSeek은 5센트가 제시되며 Gemini는 속도·비용·지능의 균형이 뛰어난 모델로 평가된다. [19:04]
• DeepSeek은 깊게 사고해 느릴 수 있고 로컬 Qwen 계열은 높은 평가 점수에도 컨텍스트와 생성 속도가 실제 사용의 제약이 될 수 있다고 드러낸다. [20:12]
• 벤치마크를 절대적 진실로 보지 말고 자신의 사용 사례에 모델을 배치해 직접 비교해야 한다고 결론짓는다. [20:45]

9. 소유해야 할 것은 에이전트 하네스

• 세 패턴을 multi-agent orchestration으로 정리하고, 기존 코딩 제품도 유용하지만 타인의 하네스에 갇히면 모델 변화에 맞춘 사용자 정의가 제한된다고 지적한다. [21:13]
• 자율적으로 행동하는 기술을 활용하려는 엔지니어에게는 교체 가능하고 확장 가능한 agent harness가 핵심 소유 대상이라고 주장한다. [21:48]
• 실험과 시장 이해를 위해 먼저 하네스를 소유하고, 그다음에는 더 어려운 과제인 모델 소유로 나아가야 한다고 제안한다. [22:13]

10. 통합 검증과 추천 모델

• builder가 데모 실행 경로를 추가하고 architect가 최종 통합과 검증을 맡아, 여러 컴퓨트가 서로의 작업을 확인하는 구조를 완성한다. [22:48]
• 화자는 저렴하고 빠른 Gemini 3.7 Flash와 호스팅·미세조정이 가능한 오픈 웨이트 선택지로 DeepSeek V4 Pro를 추천한다. [23:05]
• 고난도 agentic engineering의 오케스트레이션에는 여전히 Fable 5를 쓰되, 여러 Pi agent 변형으로 복수 모델 관점을 활용한다고 보여준다. [24:05]

11. 완성된 협업 결과와 설정 구조

• API 비용을 실제로 지불하는 실험이 차별화된 수익을 위한 투자라고 주장하고, API 사용 시 IP 보호와 ZDR의 이점이 있다고 드러낸다. [24:30]
• architect가 협업 종료와 산출물 목록을 보고하며, 생성된 DuckDB 데모와 설정을 코드베이스에서 확인한다. [24:42]
• 설정은 모델명, thinking 옵션, 추가 시스템 프롬프트 중심으로 단순하게 유지됐지만 데모 자체는 영상에서 실행하지 않는다. [25:25]

12. 컴퓨트를 선택하지 말고 결합하라

• 핵심 원칙을 특정 모델 간 대결이 아니라 함께 사용하는 것으로 정리하며 combine compute, don’t select compute라는 문구를 강조한다. [25:41]
• auto validate와 fusion 등 추가 명령이 있으며, 유연한 Pi coding agent는 여러 의견·계획·구현을 생성하고 결합하거나 최선안을 선택할 수 있다고 보여준다. [26:16]

13. 하네스 엔지니어링에서 소프트웨어 팩토리로

• 범용 도구를 그대로 쓰는 단계를 넘어 에이전트 주변에 특화된 장치를 설계하는 harness engineering이 필요하다고 드러낸다. [26:27]
• 다음 단계는 에이전트와 코드를 결합해 각각을 단독으로 쓸 때보다 높은 성과를 내는 software factory라고 정의한다. [26:43]
• 사람이 터미널에서 매번 에이전트를 감독하는 대신, 사람 없이도 작업하는 outloop agentic coding으로 이동해야 한다고 주장한다. [26:56]

14. Outloop 전환과 책임

• prompt·context·harness engineering을 이해했다면 여러 소프트웨어 개발 수명주기 변형을 만들고 관리하는 software factory에 집중해야 한다고 제안한다. [27:14]
• 모델과 기술은 이미 준비됐으므로 도구를 탓하기보다 사용자가 통제권과 결과에 대한 책임을 가져야 한다고 촉구한다. [27:35]

15. 지속될 지능 폭발과 마무리

• 앞으로도 지능 폭발이 반복될 것으로 보고, 채널에서 모델을 계속 추적해 시청자의 의사결정과 agentic engineering을 지원하겠다고 드러낸다. [27:47]
• 지능 폭발이 제공하는 기회를 활용하되 집중력을 유지하고 계속 구축하라는 메시지로 영상을 마친다. [28:02]

🧾 결론

• 모델 출시 속도가 빨라질수록 하나의 최강 모델에 고정된 도구보다 모델을 쉽게 교체·비교·조합할 수 있는 하네스가 유리하다.
• 최고가 모델을 모든 단계에 투입하기보다 고난도 통합과 판단에는 강력한 architect를, 조사·초안·구현에는 빠르고 저렴한 builder를 배치하는 구조가 합리적이다.
• 벤치마크 순위만으로 모델을 선택해서는 안 되며, 실제 업무에서 성능·응답 속도·비용과 산출물 검증 결과를 함께 측정해야 한다.
• 멀티모델 활용의 목적은 답변 수를 늘리는 것이 아니라 독립 의견, 반론, 계획 통합, 작업 분담, 최종 검증을 하나의 반복 가능한 시스템으로 만드는 데 있다.

📈 투자·시사 포인트

• 모델 가격 전쟁과 경쟁력 있는 A급 모델의 증가는 추론 비용을 낮추고, 여러 모델을 동시에 사용하는 오케스트레이션의 경제성을 높일 수 있다.
• 지속 가능한 차별화 지점은 개별 모델 접근권보다 모델 라우팅·평가·협업·검증을 담당하는 하네스와 소프트웨어 팩토리로 이동할 가능성이 있다.
• 빠르고 저렴한 모델이 대부분의 작업에서 충분한 품질을 제공한다면, 프런티어 모델의 가치는 모든 호출이 아니라 architect·최종 판단·고난도 통합 같은 제한된 단계에 집중될 수 있다.
• 모델 제공자나 단일 코딩 제품에 강하게 종속된 조직은 가격·정책·성능 변화에 대응하기 어렵지만, 교체 가능한 모델 스택을 가진 조직은 같은 변화를 비용 절감과 생산성 향상의 기회로 활용할 수 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• 영상에서 언급한 모델명·출시 시점·가격·벤치마크 수치는 별도의 원문이나 공식 가격표로 검증되지 않았으며, 일부 명칭은 전사 과정에서 부정확하게 표기됐을 가능성이 있다.
• Gemini 3.7 Flash와 DeepSeek V4 Pro가 프런티어 모델보다 약 10배 저렴하다는 평가는 영상 속 특정 실행 결과에 기반하므로, 프롬프트 길이·출력량·캐시·제공자 가격에 따라 달라질 수 있다.
• 모델명을 숨기지 않으면 모델들이 경쟁하거나 방해한다는 설명은 화자의 반복 관찰이지만, 통제 실험이나 원인 분석이 제시되지는 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 동일한 실제 업무 하나를 선정해 단일 모델, 3개 모델 병렬 opinion, 다회전 debate의 품질·지연시간·비용을 각각 기록한다.
• 모델명 대신 중립적인 alias를 사용한 블라인드 비교와 모델명을 공개한 비교를 모두 실행해 행동 차이가 재현되는지 확인한다.
• 가장 강력한 모델을 architect와 최종 검증에만 배치하고, 저비용 모델을 조사·계획·구현 builder로 배치하는 비용 제한 실험을 설계한다.
• 생성된 코드에는 실행 테스트, 충돌 검사, 의존성 확인, 결과물 검증을 필수 단계로 넣어 다중 에이전트의 상호 확증 오류를 줄인다.

❓ 열린 질문

• 여러 모델이 같은 결론에 수렴했을 때 그것이 독립적인 교차 검증인지, 유사한 학습 데이터와 추론 습관에서 나온 집단 오류인지 어떻게 구분할 수 있을까?
• architect에 가장 비싼 모델을 쓰는 것이 언제 비용 대비 효과적이며, 어느 수준부터 저비용 모델과 규칙 기반 검증으로 대체할 수 있을까?
• effective agent hour per token cost를 실제 조직에서 측정하려면 산출물 품질, 재작업, 검토 시간과 운영 비용을 어떤 방식으로 결합해야 할까?