My Real Multi-Agent Workflow in Orca: Smooth & Autonomous Collaboration

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Orca에서 Hermes와 Claude Code가 터미널로 소통하고 파일 소유권을 나누면, 계획 이후 구현·리뷰·수정을 적은 사용자 개입으로 이어가는 멀티에이전트 협업이 가능하다는 실전 사례다.

📌 핵심 요점

1. 협업의 연결점은 Orca CLI다. 두 에이전트가 서로의 터미널을 읽고 메시지를 보내며, 응답을 기다리는 방식으로 작업을 이어간다.
2. 발표자는 주요 에이전트를 두 개로 제한한다. Claude의 초기 계획·설계와 Hermes의 구현·이미지 생성·프로젝트 기억을 결합하고 서로 작업을 검토하게 한다.
3. 동시 작업의 전제는 명확한 소유권이다. 두 에이전트는 work split.md에 역할과 경로별 담당 범위를 합의해 같은 작업 트리에서 수정이 겹치지 않도록 했다.
4. 실제 시연에서는 Hermes가 리뷰 요청을 보내고, 잘못 선택한 터미널을 스스로 바로잡은 뒤 Claude의 리뷰 파일을 읽어 수정까지 진행했다.
5. 자율 협업이 곧 출시 완료를 뜻하지는 않는다. 인증된 프로필 API 구현을 보고했지만 실제 iPhone 환경의 Clerk 로그인 검증과 변경사항 확정은 남아 있었다.

🧩 배경과 문제 정의

발표자는 중단했던 iOS 학습 앱을 다시 만들면서 Orca 안의 Claude Code와 Hermes를 함께 사용한다. 앱은 AI와 에이전트를 배우는 듀오링고형 경험을 지향하며, 기존 교육 콘텐츠를 교육과정으로 재활용하려는 프로젝트다.

문제는 서로 다른 에이전트가 같은 프로젝트에서 작업할 때 사용자가 계속 메시지를 중계하거나 진행을 재촉해야 한다는 점이다. 발표자는 주요 에이전트를 두 개로 유지하고, Orca CLI를 통한 직접 소통과 경로별 작업 분담으로 이를 줄이려 한다. 영상은 설정 소개, 사전 계획 회고, 실제 리뷰 순환 시연, 남은 검증과 도구 선택으로 이어진다.

🕒 시간순 섹션별 상세정리

1. 두 에이전트가 함께 작업하는 실제 화면

• Orca의 Claude Code에 표시된 상세 지시와 리뷰 요청은 사용자가 직접 쓴 것이 아니라 옆 패널의 Hermes가 작성한 내용이라고 보여준다. [00:39]
• 서로 다른 환경과 모델을 사용하는 두 에이전트의 협업을 보여주며, 발표자가 경험한 구성 중 특히 매끄러웠다고 평가한다. [01:20]

2. 지식 자료 소개와 Orca CLI 준비

• Agent Wiki의 무료 자료와 유료 스킬 자료를 보여준다. 월 9.99달러와 가격 유지 조건은 영상 속 홍보 내용이다. [02:03]
• Orca 설정의 초기 설정 목록에서 CLI를 활성화하며, 이번 작업에는 브라우저 조작이 아닌 에이전트 조정 기능이 필요하다고 보여준다. [02:40]
• CLI로 터미널 내용을 읽고 메시지를 보낼 수 있는 것이 두 에이전트 간 소통의 기반이다. [02:54]

3. 두 에이전트로 제한하는 이유와 역할 구상

• 수십 개의 에이전트를 관리하는 구성보다 주요 에이전트 두 개를 함께 쓰는 단순한 운영을 선호한다. [03:21]
• Claude Code의 작업 능력에 Hermes의 프로젝트 기억과 스킬 축적을 결합하려 하며, Hermes에서 GPT-6 Astra를 사용한다고 드러낸다. [03:56]
• Claude가 초기 계획·설계를 맡고 Astra가 구현을 많이 수행한 뒤 상호 리뷰하는 방식을 소개하지만, 여전히 실험 중이라고 드러낸다. [04:18]

4. 오래된 iOS 학습 앱의 재구축

• 과거 시작했던 학습 앱을 AI와 에이전트 분야의 듀오링고형 앱으로 재구축하고, 보유한 교육 자료를 교육과정에 활용하려 한다. [05:01]
• 기존 학습 방식과 경제 시스템은 유지하면서 그래픽을 새로 만들 계획이다. Windows에서 개발·테스트하고 최종 배포에는 Mac을 사용할 예정이라고 보여준다. [05:30]
• Claude가 기존 상태와 전체 계획을 검토한 뒤 Hermes도 코드와 Claude의 작업을 읽고 계획을 평가하도록 참여시킨다. [05:58]

5. 실행 전에 소유권과 수락 기준 합의

• Hermes에 구현과 시각 자산 생성을 맡기고 Claude의 계획을 검증하게 한다. 초기 수정 의견은 사용자가 Claude에게 전달했다. [06:12]
• Hermes는 먼저 파일 소유권과 수락 기준을 합의하자고 제안한다. 기존 앱을 보존하고 대체 구현을 별도 위치에 두며 같은 모듈의 동시 수정을 피한다. [06:38]
• 이후 Hermes가 Claude의 터미널에 직접 분담안을 보내며 협업 절차를 시작한다. [07:01]

6. 작업 분담 문서와 공유 작업 트리

• Claude의 호스팅·API 관련 검토와 Hermes의 클라이언트 구현·통합 테스트·오프라인 큐·계정 격리·시각 자산 작업 등으로 역할을 나눈다. [07:16]
• 별도 비공개 채널이 아니라 터미널의 실제 응답과 Orca CLI 읽기·쓰기로 소통하며, 합의 결과를 work split.md에 남긴다. [07:39]
• 같은 작업 트리에 있으므로 경로별 독점 소유권을 정한다. 이미지 생성 기능이 있는 Hermes가 시각 자산을 맡는다. [08:13]

7. 적은 개입으로 이어진 계획 검토

• 사용자 답변을 반영해 단계별 범위와 열린 질문을 정리했으며, 발표자는 초기 계획 과정에서 개입할 일이 많지 않았다고 드러낸다. [08:37]
• 기존 코드와 계획을 검토하는 동안 두 에이전트가 다섯∼여섯 차례 의견을 주고받았고, 진행을 재촉할 필요가 없었다고 보여준다. [09:11]
• 매끄러운 진행의 원인이 CLI 설계인지 모델 특성인지는 모른다고 인정한 뒤 인증·데이터베이스 통합 작업의 실시간 시연으로 넘어간다. [10:07]

8. 더 복잡한 조정 기능과 단순한 운영 선택

• 실행 단위, 작업, 워커, 메시지, 의사결정 관문과 작업 그래프를 이용하는 더 정교한 조정 방식도 있지만 이번 용도에는 과하다고 본다. [10:46]
• 주요 에이전트는 두 개로 유지하되 필요하면 하위 에이전트를 쓰게 하는 방식을 선호한다. 현재 프로젝트에는 작업 트리 하나를 사용한다. [11:19]
• 여러 작업 트리는 큰 팀에는 유용할 수 있으나 개인적으로 추적하기 어렵다고 드러낸다. 이어 Hermes가 구현한 API 부분의 리뷰를 Claude에게 요청한다. [11:50]

9. 리뷰 요청과 터미널 오류의 자체 복구

• Hermes는 처음에 잘못된 터미널을 지정했지만 목록을 다시 읽어 사용자의 수정 지시 없이 올바른 대상으로 메시지를 보냈다. [12:13]
• 리뷰 요청은 차단 요소만 회신해 달라는 형태였으며, Claude가 구현 내용을 읽기 시작한다. [12:57]
• Hermes는 Orca의 터미널 대기로 응답을 확인하고 Claude가 작성한 profile review.md를 읽는다. [13:49]

10. 리뷰 반영과 도구별 운영상의 차이

• Hermes가 리뷰 파일을 읽고 필요한 수정을 진행한다. 보고된 결과는 병합 차단 요소 없이 수정할 의견이 일부 남은 상태다. [14:04]
• 발표자는 리뷰 확인을 따로 지시하지 않아도 진행되는 점을 높이 평가하지만, Orca의 장점이 어디서 비롯되는지는 확신하지 못한다. [14:42]
• 장기 프로젝트에는 Orca, 개별 작업에는 Herder를 고려한다. Orca 재시작 때 Hermes 세션이 자동 복원되지 않았던 경험을 비교 근거로 든다. [15:49]

11. 프로젝트 기억·스킬과 구독 활용

• Orca에는 장기 프로젝트 하나를 두고 Herder에는 영상 제작·연구·아이디어 구상 같은 작은 세션을 유지하려 한다. 단독 Hermes 작업에는 데스크톱 앱을 선호한다. [17:02]
• 프로젝트에서 개발한 iOS Expo 상태 검토 스킬을 예로 들며, 작업 경험을 재사용할 수 있다는 점을 Hermes의 장점으로 보여준다. [17:21]
• 모델 간 성능 차이가 줄었다는 개인 평가와 함께, 두 구독을 병행해 한쪽 사용 한도만 소진하지 않으려는 목적을 드러낸다. [18:18]

12. 구현 결과, 남은 검증과 마무리

• 인증된 프로필 API 부분의 구현과 확인 사항을 보고하지만, 실제 iPhone 토큰을 사용하는 Clerk 로그인 검증이 남았고 변경사항도 아직 확정되지 않은 상태라고 보여준다. [18:41]
• 계획 이후에는 Hermes를 주된 대화 창구로 삼는다. 발표자는 이번 인증 API와 Clerk 설정 과정에서 두 에이전트가 추가 사용자 입력 없이 소통하고 검토했다고 평가한다. [19:53]
• 앱 개발의 흥미로운 부분을 후속 영상으로 다룰 가능성을 언급하고, 시청자의 Orca 멀티에이전트 운영 경험을 요청하며 끝낸다. [20:39]

🧾 결론

• 이 사례의 핵심은 에이전트 수보다 통신 방식, 작업 경계, 리뷰 절차를 먼저 정한 데 있다.
• 사용자는 초기 비전과 선호를 제공하고, 에이전트는 합의된 계획 안에서 구현과 검토를 반복했다. 자율성은 이러한 준비 이후의 실행에서 관찰됐다.
• 발표자는 장기 프로젝트에는 Orca, 일상적인 개별 세션에는 Herder를 병행할 계획이다. Orca의 협업 경험과 세션 복원 문제를 함께 고려한 선택이다.

📈 투자·시사 포인트

• 개발 도구를 평가할 때 모델 성능뿐 아니라 에이전트 간 전달·대기·검토를 얼마나 안정적으로 연결하는지 살펴볼 필요가 있다.
• 프로젝트 기억과 재사용 가능한 스킬은 장기 작업에서 도구를 선택하는 요인으로 제시된다. 다만 생산성 향상의 크기는 측정되지 않았다.
• 두 구독의 사용 한도를 분산하는 운영 방식이 소개되지만, 총비용 절감이나 투자수익률을 입증하는 비용 자료는 없다.
• 세션 복원과 작업 추적 같은 운영 기능도 도구 선택에 영향을 준다. 영상만으로 특정 기업의 실적이나 투자 매력까지 판단할 근거는 부족하다.

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

• 발표자도 협업이 매끄러운 이유가 Orca CLI 설계인지 모델 조합인지 구분하지 못한다. 단일 프로젝트의 경험이며 도구 간 통제 비교는 없다.
• 자막에 등장하는 Fable 5.1, GPT-6 Astra 등의 명칭과 성능 평가는 발표자의 설명이다. 정확한 제품 표기와 객관적인 성능 우위는 이 자료만으로 확인할 수 없다.
• 최종 보고 시점에도 실제 iPhone 토큰을 사용하는 Clerk 로그인 확인이 남았다. API 구현 보고를 실제 기기에서의 전체 인증 흐름 검증으로 확대 해석하면 안 된다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Orca 설정에서 CLI의 에이전트 조정 기능을 활성화하고, 터미널 읽기·메시지 전송·응답 대기가 동작하는지 확인한다.
• 주요 에이전트 두 개로 시작해 초기 계획, 구현, 시각 자산, 상호 리뷰의 담당을 정한다.
• 공유 작업 트리를 사용한다면 경로별 소유권과 수락 기준을 작업 분담 문서에 기록한다.
• 구현 → 리뷰 요청 → 리뷰 파일 확인 → 수정의 흐름을 작은 작업에서 재현하고 사용자 개입이 필요한 지점을 기록한다.

❓ 열린 질문

• 동일한 모델 조합을 다른 작업 공간에서 사용해도 같은 수준의 자율 협업이 재현될까?
• 공유 파일이나 의존성이 늘어날 때 경로별 소유권만으로 충돌을 충분히 방지할 수 있을까?
• 두 에이전트의 상호 리뷰가 단일 에이전트 대비 결함, 소요 시간, 사용 비용을 얼마나 바꿀까?