Pi Harness Better than Codex / Claude? (Fan Favourite)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Pi는 Codex·Claude Code보다 무조건 우월한 도구라기보다, 반복 작업에서 가벼운 실행 에이전트로 활용할 때 강점이 있다는 것이 이 대화의 결론이다.

📌 핵심 요점

1. 출연자는 Pi의 선택 이유로 가벼움, 높은 제어권, 커뮤니티 플러그인과 수정의 자유를 꼽는다.
2. 처음 만드는 웹사이트·게임 MVP처럼 일회성이고 요구사항이 덜 구체적인 작업에는 여전히 Codex나 Claude Code를 선호한다.
3. 반복 업무에서는 Codex·Claude Code가 전체 작업을 조율하고, 여러 Pi 에이전트가 나누어 실행하는 구성을 제안한다. Herder는 여러 창과 에이전트를 제어하는 별도 도구로 함께 사용한다.
4. 영상 편집을 자막, 애니메이션, 무음 제거, 배경음악 등으로 분리하면 병렬 처리가 가능하고, 단순 작업에는 저렴한 모델을 배정할 수 있다는 설명이다.
5. 반복 사용되는 Pi 에이전트에 용어와 작업 지식을 유지하려는 점이 핵심이다. 다만 가벼운 구성의 대가로 장시간 자율 실행이 부족하다고 느끼며, 커뮤니티 확장으로 기능을 보완한다고 말한다.

🧩 배경과 문제 정의

진행자는 주로 Codex와 Claude Code로 개발해 왔고, 게스트 Leo는 웹사이트 개발·자동화·AI 영상 편집에 Pi를 활용한다. 대화는 Pi가 기존 코딩 하네스보다 나은지 묻는 데서 시작해, 어떤 업무에 어떤 실행 구성이 적합한지로 초점을 옮긴다.

핵심 문제는 반복되는 대량 업무를 한 에이전트에 계속 맡길 때 생기는 시간과 컨텍스트 부담이다. 게스트는 기존 도구를 조율자로 유지하면서 여러 Pi 실행 에이전트를 연결하는 방식을 설명한다. 그가 말하는 구성은 일회성 서브에이전트 호출보다 업무별 에이전트와 지식을 재사용하는 데 무게가 있다.

🕒 시간순 섹션별 상세정리

1. Pi를 선택하는 이유와 일회성 작업의 기준

• Pi를 가볍고 제어하기 쉬우며, 커뮤니티 플러그인과 수정으로 유연하게 바꿀 수 있는 코딩 하네스로 보여준다. [00:36]
• 처음 만드는 웹사이트·게임 MVP에는 Codex·Claude Code 등을 선호한다. 덜 정교한 프롬프트로도 작업을 완수한다고 느끼기 때문이다. [01:59]
• 반복 실행할 업무라면 Pi 코딩 에이전트를 구성하는 방안을 고려한다고 구분한다. [02:12]

2. Herder와 여러 에이전트의 역할 분담

• 단순히 루프를 돌리는 이야기보다 하네스 설계와 여러 에이전트의 협업에 초점을 맞춘다. Herder의 여러 창에 각각 코딩 에이전트를 배치하는 방식을 보여준다. [03:18]
• Codex나 Claude Code를 조율자로 두고 나머지 에이전트가 실행을 맡는다. Herder는 계속 사용하며, 조율자가 다른 창을 제어하도록 돕는 도구라고 정리한다. [05:09]

3. 컨텍스트 부담을 나누려는 설계

• 여러 에이전트를 쓰는 이유로 컨텍스트 활용과 반복적인 압축을 줄이는 문제를 든다. 대화에서는 약 60% 사용 이후 성능이 나빠진다는 경험적 주장도 나온다. [05:58]
• 전체 조율은 기존 도구가 맡고 작은 실행 에이전트는 Pi로 구동하는 구성을 확인한다. 이런 복잡한 설정은 반복 업무일 때 의미가 있다고 강조한다. [06:21]

4. 영상 편집을 병렬 작업으로 전환

• 첫 영상은 Codex·Claude Code로 편집하고, 다음 영상부터 같은 작업이 반복되면 별도 하네스를 구성하는 예를 든다. [06:51]
• 자막, Remotion 그래픽, 무음 제거, 배경음악, 인트로·아웃트로를 나누어 동시에 처리하고, 자막 같은 작업에는 저렴한 모델을 쓸 수 있다고 보여준다. [07:51]
• 진행자는 기존 단일 에이전트 편집에 약 3~4시간이 걸린다고 드러낸다. 논의의 차이는 Codex가 같은 도구의 서브에이전트를 부르는 대신 여러 Pi 에이전트를 쓰는 데 있다고 정리한다. [08:45]

5. 반복 사용할 에이전트에 용어와 기억 유지

• 게스트는 사라지는 서브에이전트보다 기억과 업무별 스킬을 유지하는 실행 에이전트를 선호한다고 드러낸다. [08:56]
• 광둥어와 영어가 섞인 영상에서 도구 이름이 잘못 전사되는 사례를 들며, 에이전트가 교정할 키워드 목록을 기억할 필요가 있다고 보여준다. [09:35]
• 진행자는 이를 전날 사용한 에이전트를 다시 연결해 기존 작업 지식을 활용하는 방식으로 이해한다. 구체적인 기억 저장 구현은 다루지 않는다. [10:01]

6. 가벼움의 대가와 조율자의 필요성

• Pi가 가볍고 빠르다는 평가와 함께, 오래 자율적으로 작업을 이어가는 성향은 부족하다는 경험을 드러낸다. 그래서 직접 코딩하기보다 Codex·Claude Code가 Pi를 제어하도록 한다. [11:09]
• 많은 업무를 처리할 때 강한 조율자가 작은 작업용 에이전트를 활용해 효율과 컨텍스트 사용을 개선하려는 구성이라고 요약한다. [12:25]

7. 커뮤니티 확장과 후속 논의

• pi.dev의 패키지를 소개하며, Pi 자체에 없는 루프 등의 동작을 커뮤니티 플러그인으로 추가하고 하네스를 맞춤 구성할 수 있다고 보여준다. [13:03]
• 구체적인 확장 기능은 후속 영상에서 다룰 수 있다고 예고하고, 시청자에게 해결하고 싶은 업무와 워크플로를 공유해 달라고 요청한다. [13:39]
• 진행자는 자신도 Pi 워크플로를 도입하기 시작했다고 말하며 대화를 마친다. [14:01]

🧾 결론

• 도구 선택의 기준은 단순한 우열보다 작업의 반복성, 필요한 제어 수준, 초기 설정 부담이다.
• 제안된 구조는 전체 맥락을 이해하는 조율자와 좁은 업무를 맡는 여러 실행 에이전트의 결합이다.
• 처음 한 번은 기존 도구로 작업 방식을 만들고, 같은 작업이 반복될 때 Pi 기반 분업을 검토하는 접근이다.

📈 투자·시사 포인트

• 출연자가 강조하는 가치는 모델 선택뿐 아니라 작업 분해, 에이전트 연결, 확장 기능을 포함한 실행 환경 설계에 있다.
• 반복 업무의 생산성을 판단할 때는 처리 시간과 토큰 사용량뿐 아니라 설정·조율·결과 검수에 드는 비용도 함께 비교필요가 있다.
• 커뮤니티 패키지와 작업별 기억을 재사용하는 구조가 도구 선택 요인으로 제시된다. 다만 이 대화에는 특정 기업의 투자 가치나 시장 우위를 판단할 정량 자료가 없다.

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

• 컨텍스트 사용량이 약 60%를 넘으면 성능이 나빠진다는 발언은 출연자의 주장이다. 영상에는 적용 모델, 측정 방법, 비교 실험이 제시되지 않는다.
• Pi가 더 빠르고 토큰을 덜 사용한다는 설명에는 동일 작업·동일 모델 기준의 수치가 없다. 한 시간에 영상 여섯 개를 만든다는 언급도 검증된 처리량으로 제시되지 않는다.
• Pi 에이전트가 기억을 유지하는 구체적인 저장 방식과 재접속 절차는 설명되지 않는다. 기존 서브에이전트에는 장기 기억과 전용 스킬이 없다는 설명 역시 사용 환경에 따라 확인해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 업무를 처음 수행하는 작업과 반복 수행하는 작업으로 나누고, Pi 구성을 검토할 반복 업무 하나를 고른다.
• 기존 Codex·Claude Code 작업에서 자막, 그래픽, 무음 제거처럼 독립적으로 맡길 수 있는 단계를 정리한다.
• 조율자 하나와 Pi 실행 에이전트 소수로 시험하고, 처리 시간·토큰 비용·수정 횟수·설정 시간을 기록한다.
• 자막에 반복 등장하는 고유명사와 교정 규칙을 목록으로 만들고, 다음 작업에서도 유지되는지 확인한다.

❓ 열린 질문

• 반복 작업을 몇 번 수행해야 초기 설정과 운영 부담을 상쇄할 수 있을까?
• 같은 모델과 같은 입력을 사용할 때 Pi 기반 분업은 기존 도구의 서브에이전트 구성보다 얼마나 효율적인가?
• 여러 에이전트의 결과를 합칠 때 충돌과 품질 차이는 어떻게 검수하며, 업무별 기억은 어떤 방식으로 갱신하는가?