Orca에서 삽질히고 Paseo로 갈아탄 비개발자의 멀티에이전트 첫 세팅기
새벽의 거위 · Orca 멀티에이전트 시스템 · · 좋아요 0 · 답글 0
연재 Orca 멀티에이전트 시스템 6/12편
📝 요약
Claude Code 하나로 코딩하던 비개발자가 Orca와 Paseo를 직접 설치해 보면서, 기존 개인 재무 프로젝트에 Codex 구현 + Claude/Codex 독립 리뷰 구조를 붙이는 중입니다. Orca에서는 구형 WSL 인식 문제로 Windows에 repo를 다시 clone하는 시행착오가 있었는데, Paseo는 같은 WSL을 바로 인식해서 현재 CP6 UI 작업용 Git worktree까지 분리했습니다.
아직 완성보다 “환경 정리” 단계에 가깝습니다
현재까지 완료된 것은:
항목
상태
Orca 설치
완료
Orca에서 Codex review 테스트
완료
Orca의 WSL 제약 확인
완료
Windows repo clone
해봄
Paseo 설치
완료
WSL project 인식
완료
Claude Code / Codex provider 인식
완료
CP6 전용 Git worktree
완료
CP6 Architect 실행
다음 단계
Codex Implementer
예정
독립 Reviewer 연결
예정
복붙 자동화
이번 달 목표
그래서 아직 “Paseo가 Orca보다 좋다”라고 결론 내리지는 않으려고 합니다.
다만 제 오래된 Windows/WSL 환경에서는 Paseo가 기존 WSL repo를 잡는 과정이 훨씬 수월했습니다.
과정 중 가장 크게 배운 점
첫 번째는 오케스트레이션보다 환경 통일이 먼저라는 점입니다.
저처럼 기존 프로젝트가 WSL에 있는데 새로운 도구 때문에 Windows clone을 별도로 만들기 시작하면:
어느 repo가 canonical인가?
어느 branch가 최신인가?
어느 agent가 어느 worktree에서 작업했나?를 관리하는 비용이 금방 생깁니다.
그래서 지금은:
canonical
/home/yj/projects/personal-capital
feature worktree
/home/yj/projects/personal-capital-cp6-ui처럼 Git 자체를 기준으로 분리하고, Paseo는 그 위에서 agent를 실행하는 방식으로 정리했습니다.
두 번째는 멀티에이전트를 에이전트 수로 생각하지 않는 것입니다.
처음에는 4~5개 역할을 만들어야 멀티에이전트 같다고 생각했는데, 실제로 제가 원하는 건:
설계자 1
구현자 1
리뷰어 1이면 충분했습니다.
세 번째는 Reviewer를 구현자와 분리하는 것이 가장 먼저 체감할 수 있는 효과라는 점입니다.
기획 agent 5개를 띄우는 것보다, 지금 제가 하는 일에서는:
“구현한 모델이 아닌 다른 모델이 diff를 읽고 confirmed defect만 뽑아 준다”
는 구조가 훨씬 실용적으로 느껴졌습니다.
시행착오
이번 설치 과정에서는 꽤 여러 번 잘못된 길로 갔습니다.
Orca에서는
구형 WSL 연결이 잘 안 됨
Windows repo를 별도로 clone
Orca 전용 worktree(
zoanthid)가 생김원본 WSL repo와 작업 위치가 갈라짐
Paseo에서는
WSL repo는 바로 인식
하지만 기본 Terminal은 Windows CMD
/home/...경로가 안 먹음WSL에는
paseoCLI가 없음Ubuntu가 추천한 동명
paseo패키지를 설치할 뻔함Windows Paseo CLI를 WSL에서 호출하는 방법을 따로 확인
Paseo CLI가 WSL UNC repo를 Git repository로 판별하지 못함
결국
git worktree add로 직접 feature worktree 생성
이라는 과정을 거쳤습니다.
지금 생각하면 Git worktree를 먼저 이해하고 시작했으면 꽤 많이 줄일 수 있었던 삽질이었습니다.
나만의 꿀팁
저처럼 개발자가 아니고 기존 repo가 WSL에 있다면, 새 orchestration 도구를 설치할 때 가장 먼저 아래부터 확인하는 게 좋을 것 같습니다.
pwd
git branch --show-current
git status --short
git worktree list화면에 agent가 여러 개 떠 있다고 안심하지 말고, 각 agent가 어느 working directory와 branch를 보고 있는지 먼저 확인하는 것입니다.
그리고 AI에게 바로:
Implement CP6.라고 하지 않고,
Do not modify files yet.
Inspect the repository and tell me what CP6 actually means.부터 시키는 것도 효과가 좋았습니다.
제가 checkpoint 이름을 잘못 기억하고 있어도 repo를 source of truth로 다시 잡을 수 있기 때문입니다.
도움이 필요한 부분
아직 궁금한 점은 Paseo에서 이 구조를 얼마나 자연스럽게 자동화할 수 있느냐입니다.
최종적으로 원하는 흐름은:
Architect
↓
Codex Implementer
↓
Independent Reviewer
↓
confirmed defect만 Implementer에게 반환
↓
재테스트입니다.
각 단계에서 제가 결과를 복붙하지 않아도 되는 수준까지 가는 것이 목표입니다.
그리고 Orca와 Paseo를 둘 다 조금 더 사용한 뒤에는 단순한 “어느 UI가 예쁘다”가 아니라:
기존 WSL 프로젝트 연결
worktree 관리
다른 provider 혼용
구현 → 리뷰 handoff
context 관리
모델별 비용 배분
기준으로 비교해 보고 싶습니다.
앞으로의 계획
이번 한 달 동안 목표는 거창하지 않습니다.
1. Codex review를 루틴으로 만들어 보기
모든 코드를 여러 모델에게 검토시키기보다 중요한 checkpoint마다:
Implementer → Independent Reviewer패턴을 적용해 볼 생각입니다.
2. 복붙 노가다 줄이기
지금까지는 Claude Code, ChatGPT, Codex 사이에서 직접 전달하던 내용을 Paseo orchestration으로 어느 정도 없앨 수 있는지 확인해 보려고 합니다.
3. 한 달 뒤에는 “도구 설치 후기”가 아니라 실제 생산성 차이를 비교하기
최종적으로는:
“Orca/Paseo를 설치했다”
가 아니라
“기존에는 리뷰 handoff에 사람이 N번 개입했는데, 지금은 어디까지 자동화됐다”
를 결과로 남기는 것이 목표입니다.
잘 되면 이후에는 지금 진행하는 개인 자산관리 프로젝트에도 같은 구조를 적용해 보고 싶습니다.
태그: #멀티에이전트