(2/4) Orca 첫 3-에이전트 세션 — add→worktree→agent→split→diff→ship
🐳 Orca — 병렬 AI 에이전트 오케스트레이션 4부작 — Claude Code·Codex 같은 코딩 에이전트를 여러 개 동시에 굴리고, 각자 격리된 git worktree 에서 경쟁시킨 뒤 제일 나은 결과만 골라 합치는 데스크톱 도구 Orca 를 실전 워크플로우 중심으로 정리했어요. 먼저 Orca 가 뭐고 왜 필요한지 전체 그림을 잡고(1편), add→worktree→agent→split→diff→ship 첫 3-에이전트 세션을 손에 익히고(2편), diff 리뷰·Design Mode·브라우저로 결과를 검수하고(3편), 원격(SSH·VPS)·모바일·CLI 로 스웜을 확장하는 것(4편)까지 이어집니다. 전체 4편.
- Orca 란 무엇인가 — 병렬 에이전트 ADE 의 전체 그림
- 첫 3-에이전트 세션 — add→worktree→agent→split→diff→ship ← 지금 글
- 결과 검수 — diff 리뷰·Design Mode·브라우저
- 스웜 확장 — 원격(SSH·VPS)·모바일·CLI 자동화
Summary
1편에서 Orca 가 “내 구독으로, 아무 CLI 에이전트를, 격리된 worktree 에서 여러 개 굴리는 관제탑”이라는 걸 잡았어요. 이번 편은 말을 멈추고 진짜 첫 세션을 열어봅니다.
Orca 의 전체 흐름은 딱 여섯 단어로 요약돼요.
add → worktree → agent → split → diff → ship
저장소를 붙이고(add), 과제별로 작업 공간을 가르고(worktree), 각 공간에 에이전트를 앉히고(agent), 화면을 쪼개 동시에 지켜보고(split), 끝나면 결과를 비교해서(diff), 제일 나은 걸 내보낸다(ship). 이번엔 이걸 같은 과제를 세 에이전트에게 동시에 시키는 “레이싱” 형태로 처음부터 끝까지 밟아볼게요. 공식 문서가 “이 문서에서 가장 중요한 한 페이지”라고 부르는 그 세션이에요.
💡 이 글에서 다루는 것
- 여섯 단어 흐름을 한 장으로 — add→worktree→agent→split→diff→ship
- 저장소 붙이고 과제 만들기 (진짜 worktree 가 생기는 순간)
- 같은 문제를 세 에이전트에게 던지는 “레이싱” 세팅
- 분할 화면(split)으로 셋을 동시에 관찰하는 법
- diff 를 나란히 놓고 줄 단위로 골라 담아 합치기
- 승자만 남기고 나머지 브랜치 깔끔하게 정리
1. 여섯 단어 흐름을 한 장으로
먼저 전체 지도를 눈에 넣고 시작할게요. Orca 로 하는 거의 모든 일이 이 여섯 단계 안에 들어와요.
| 단계 | 하는 일 | 누가 |
|---|---|---|
| add | 로컬 저장소를 Orca 에 붙임 |
사람 (한 번) |
| worktree | 과제별 작업 폴더·브랜치 생성 |
버튼 클릭 |
| agent | 그 폴더에서 에이전트 실행 |
콤보박스 선택 |
| split | 화면 쪼개 동시에 관찰 |
탭 드래그 |
| diff | 결과를 나란히 비교 |
사람 (검수) |
| ship | 승자를 커밋· 푸시, 나머지 정리 |
버튼 클릭 |
사람이 머리를 쓰는 건 사실상 맨 앞(뭘 시킬지)과 맨 뒤(누구 걸 고를지) 두 곳이에요. 가운데의 폴더·브랜치·창 관리는 전부 Orca 가 흡수해요. 1편에서 “손으로 하면 귀찮은 1·3·5·6·7번”이라고 했던 게 바로 이 가운데 단계들이에요.
2. add — 저장소 붙이기
Orca 를 처음 켜면 빈 화면이에요. 여기서 “Add Repo” 를 눌러 내 로컬 코드 체크아웃(이미 git clone 해둔 폴더)을 가리켜요. 그러면 Orca 가 그 폴더의 git 상태를 읽어서 기준 브랜치(base branch) 를 잡아요. 보통 main 이나 develop 이겠죠.
여기서 중요한 감각 하나. Orca 는 이 저장소를 어디 클라우드로 올리거나 복제해서 가두지 않아요. 그냥 내 디스크에 있는 그 폴더를 그대로 봐요. 그래서 Orca 를 나중에 지워도 코드는 원래 자리에 그대로 있어요.
💡 처음엔 작고 익숙한 저장소로 시작하는 걸 추천해요. 첫 세션의 목적은 “결과물”이 아니라 “흐름을 몸에 붙이는 것”이라서, 빌드가 빠르고 구조가 눈에 익은 저장소일수록 add→ship 한 바퀴를 빠르게 돌 수 있어요.
3. worktree — 과제 만들기 (한 번에 세 개)
이제 본론이에요. 화면의 ”+” 버튼을 누르면 런처가 뜨고, 여기서 과제 이름을 적어요. 예를 들어 “로그인 폼 검증 버그” 같은 거요. 확인을 누르는 순간 Orca 가 하는 일이 이거예요.
- Orca 가 관리하는 디렉터리 아래에 진짜 git worktree 를 하나 만든다
- 거기에 새 브랜치를 체크아웃한다
- 그 폴더를 탭으로 열어준다
즉 “+” 한 번 = git worktree add 한 번이에요. 손으로 치던 명령이 버튼이 된 거죠.
우리는 레이싱을 할 거니까, 이걸 세 번 반복해요. 같은 과제를 세 갈래로 갈라두는 거예요.
| worktree | 브랜치(예) | 여기 앉힐 에이전트 |
|---|---|---|
| 과제 A | login-fix-a | Claude Code |
| 과제 B | login-fix-b | Codex |
| 과제 C | login-fix-c | Cursor CLI |
세 폴더는 서로 완전히 격리돼 있어서, A 에서 에이전트가 파일을 아무리 헤집어도 B·C 는 멀쩡해요. 1편에서 말한 “서로 안 밟는 모래상자”가 이렇게 세 개 생긴 거예요.
4. agent — 각 worktree 에 에이전트 앉히기
각 worktree 탭에는 터미널이 딸려 있어요. 여기서 콤보박스로 에이전트를 골라요. Claude Code, Codex, Cursor CLI, OpenCode 등등. 고르면 Orca 가 그 worktree 폴더를 작업 디렉터리로, 내 구독 자격증명을 붙여서 에이전트를 띄워줘요. (1편의 BYO 가 여기서 작동해요 — 내가 이미 로그인해 둔 구독을 그대로 씀.)
이제 세 터미널에 똑같은 프롬프트를 던져요.
로그인 폼에서 이메일 형식이 틀려도 "가입 완료"로 넘어가는 버그가 있어요.
원인을 찾아서 고치고, 회귀 테스트도 하나 추가해줘.
같은 문제를 셋에게 동시에 던지는 이 순간이 Orca 의 핵심이에요. 셋이 각자 다른 접근으로 파고들기 시작하고, 우리는 그걸 경주 지켜보듯 볼 수 있어요.
⚠️ 여기서 1편의 경고가 현실이 돼요. 지금 우리는 같은 요금제 사용량을 3배로 태우고 있어요. 어려운 문제일수록 이 레이싱이 값어치를 하지만, 사소한 오타 수정에까지 3-에이전트를 붙이는 건 연료 낭비예요. “이건 접근이 갈릴 만한 문제인가?” 를 기준으로 레이싱을 켤지 정하세요.
5. split — 셋을 동시에 지켜보기
에이전트 셋이 일하는 동안, 한 번에 하나씩만 보면 답답하겠죠. Orca 는 탭을 화면 가장자리로 드래그하면 화면이 쪼개져요(split). 오른쪽 끝으로 끌면 좌우 분할, 아래쪽 끝으로 끌면 상하 분할. 무한히 쪼갤 수 있어서 세 에이전트를 나란히 띄워 놓고 동시에 관찰할 수 있어요.
터미널 자체도 꽤 신경 써서 만들었어요. WebGL 로 렌더링하는 빠른 터미널이라 로그가 폭포처럼 쏟아져도 안 버벅대고, 스크롤백(과거 출력)이 앱을 재시작해도 남아 있어요. 밤새 돌려놓고 다음 날 다시 켜도 어젯밤 로그가 그대로 있는 거죠.
이 단계에서 사람이 할 일은 딱 관찰이에요. 누가 헛다리를 짚는지, 누가 테스트를 진짜 돌려보는지, 누가 엉뚱한 파일을 건드리는지. 이 관찰이 뒤의 diff 단계에서 “누구 걸 고를까”의 밑감이 돼요.
6. diff — 나란히 놓고 줄 단위로 골라 담기
셋 다 “다 했어요”를 뱉으면, 이제 사람의 진짜 일이 시작돼요. 각 worktree 의 diff 뷰를 열면 그 에이전트가 뭘 바꿨는지 한눈에 보여요.
여기서 Orca 의 진가가 나오는데, 꼭 한 명의 결과를 통째로 고를 필요가 없어요. 세 개의 diff 를 나란히 놓고 줄(hunk) 단위로 골라 담을 수 있어요. 예를 들면 이런 식이죠.
- 버그 원인을 제일 정확히 짚은 건 A(Claude Code) 의 수정 → 이 hunk 채택
- 테스트를 제일 꼼꼼하게 짠 건 B(Codex) → 이 테스트 파일은 B 걸로
- C 는 이번엔 헛다리 → 통째로 버림
세 결과의 좋은 부분만 조합해서 하나의 최종본을 만드는 거예요. diff 의 특정 줄에 코멘트를 달아 그 에이전트에게 되돌려 “여기 이렇게 고쳐줘”라고 시킬 수도 있는데, 이 리뷰 왕복은 3편에서 제대로 다뤄요.
💡 여기서 마음가짐이 중요해요. 레이싱의 목적은 “1등 뽑기”가 아니라 “세 개를 재료 삼아 더 나은 하나를 조립하기” 예요. 그래서 C 가 꼴찌여도 C 의 어떤 한 줄이 제일 나을 수 있어요. 승자를 미리 정하지 말고, diff 를 다 훑고 나서 조립하는 습관을 들이세요.
7. ship — 승자만 남기고 정리
최종본이 마음에 들면, Orca 안에서 바로 커밋·푸시해요. 터미널로 나갈 필요 없이 diff 뷰에서 커밋 메시지를 쓰고 push 까지 눌러요. GitHub 연동이 되어 있으면 그대로 PR 로 이어갈 수도 있고요.
그리고 마지막 정리. 채택 안 된 worktree(B 를 통째로 쓰지 않았다면 B·C 브랜치)는 버튼으로 삭제해요. 손으로 하던 git worktree remove + git branch -D 가 클릭 한 번이 된 거예요. 이 정리가 쉬워서, 병렬을 부담 없이 켰다 껐다 할 수 있어요.
한 바퀴를 표로 되짚으면 이래요.
| 단계 | 방금 한 일 |
|---|---|
| add | 로그인 저장소 붙임 |
| worktree | A·B·C 세 갈래 생성 |
| agent | Claude·Codex·Cursor 같은 프롬프트로 실행 |
| split | 셋을 나란히 관찰 |
| diff | 좋은 hunk 만 골라 최종본 조립 |
| ship | 커밋·푸시, B·C 정리 |
8. 정리 — 첫 세션이 남기는 감각
첫 세션 한 바퀴를 돌고 나면 이런 감각이 남아요.
- 병렬은 생각보다 안 귀찮다. 창·폴더·브랜치 관리가 사라지니까, “하나 더 시켜볼까?”의 심리적 비용이 확 낮아져요.
- 사람의 자리가 앞뒤로 옮겨간다. 가운데(타이핑)를 에이전트가 채우고, 사람은 “뭘 시킬까(앞)”와 “누구 걸 조립할까(뒤)”에 집중하게 돼요.
- 레이싱은 공짜가 아니다. 사용량 3배를 감안하고, 접근이 갈릴 만한 문제에만 켜는 게 실전 감각이에요.
다음 3편에서는 이 흐름의 “diff” 단계를 깊게 팝니다. 줄에 코멘트를 달아 에이전트에게 되돌리는 리뷰 왕복, 그리고 UI 버그를 코드가 아니라 화면을 클릭해서 잡는 Design Mode 까지 — 사람이 검수자로서 개입하는 자리를 제대로 볼게요.
📚 참고 링크
- Orca 첫 세션 가이드 — https://www.onorca.dev/docs
- Orca GitHub (Stably AI, MIT) — https://github.com/stablyai/orca
