Orca... 대박인걸?
[https://goddaehee.tistory.com/623 참고하여 작성함]
최근 AI 코딩 도구를 사용하는 방식이 달라지고 있다.
과거에는 하나의 AI에게 코드를 요청하고 결과를 기다리는 방식이 일반적이었다. 하지만 이제는 Claude Code에는 설계를 맡기고, Codex에는 구현을 맡기고, 다른 에이전트에는 테스트와 코드 리뷰를 맡기는 식으로 여러 AI 에이전트를 동시에 활용하는 개발 방식이 등장하고 있다.
문제는 여러 에이전트가 동시에 작업을 실행할 때 다음과 같은 문제점들이 발생할 수 있다.
여러 에이전트가 같은 파일을 수정한다.
브랜치와 작업 디렉터리가 뒤섞인다.
어떤 에이전트가 아직 작업 중인지 확인하기 어렵다.
작업을 요청했지만 완료되었는지 알기 어렵다.
에이전트가 질문을 했는데 이를 놓칠 수 있다.
여러 결과 중 어떤 코드를 채택할지 사람이 직접 비교해야 한다.
Orca IDE는 이런 문제를 해결하기 위해 만들어진 AI 에이전트 중심 개발 환경입니다.
Orca는 공식적으로 자신을 여러 AI 코딩 에이전트를 병렬로 실행하기 위한 데스크톱 IDE로 설명합니다. 각각의 작업에는 독립적인 Git worktree, 에이전트 터미널, 브라우저 탭이 할당됩니다.
덕분에 Claude Code, Codex, OpenCode, Cursor CLI 등의 에이전트를 서로 다른 작업 공간에서 동시에 실행할 수 있습니다.
Orca IDE란?
Orca는 claude, codex와 같은 AI 코딩 툴이 아닙니다.
이미 사용하고 있는 CLI 기반 AI 에이전트를 한 곳에서 실행하고 관리하는 에이전트 개발 IDE라 볼 수 있습니다.
기존 IDE가 사람이 코드를 작성하기 좋은 환경을 제공한다면, Orca는 사람이 여러 AI 에이전트에게 작업을 분배하고 그 결과를 검토하기 좋은 환경을 제공합니다.
Orca에서 하나의 작업은 대략 다음 구조를 가집니다.
Repository
├── Worktree A
│ ├── Agent terminal: Claude Code
│ ├── Editor
│ ├── Browser
│ └── Git diff
│
├── Worktree B
│ ├── Agent terminal: Codex
│ ├── Editor
│ ├── Browser
│ └── Git diff
│
└── Worktree C
├── Agent terminal: OpenCode
├── Editor
├── Browser
└── Git diff
각 worktree는 독립된 브랜치와 파일 디렉터리를 가집니다. 따라서 여러 에이전트가 같은 저장소를 기반으로 작업하더라도 서로의 파일을 직접 덮어쓰지 않습니다.
Orca의 핵심은 Git Worktree!
일반적으로 하나의 Git 저장소에서 여러 작업을 동시에 처리하려면 다음과 같은 문제가 생깁니다.
git stash
git switch feature-a
작업
git switch feature-b
git stash pop
에이전트가 한두 개라면 어떻게든 관리할 수 있지만, 에이전트가 5개나 10개로 늘어나면 브랜치 전환과 stash 관리만으로는 감당하기 어려워집니다.
Orca는 작업마다 실제 git worktree를 만듭니다.
project/
project-feature-login/
project-payment-refactor/
project-performance-test/
각 worktree에는 다음 요소가 독립적으로 존재합니다.
브랜치
실제 파일 디렉터리
에이전트 터미널
편집기 탭
브라우저 탭
변경사항과 Diff
작업이 끝나면 해당 worktree에서 커밋하고 push한 뒤 Pull Request를 만들 수 있다. 필요 없는 실험용 worktree는 디렉터리와 브랜치를 함께 삭제할 수 있습니다.
이 구조는 AI 코딩에서 상당히 중요합니다. AI에게 강한 권한을 주더라도 작업 범위를 별도의 Git 작업 공간으로 분리한 뒤 확인 후 원본에 바로 반영할 수 있기 때문입니다.
Orca에서 에이전트는 어떻게 실행될까?
Orca에서 에이전트 세션은 다음과 같이 정의할 수 있습니다.
하나의 worktree 안에서 하나의 터미널을 통해 실행되는 하나의 CLI 에이전트
예를 들어 동일한 저장소를 기준으로 다음과 같이 구성할 수 있습니다.
login-api-worktree
└── Claude Code
login-test-worktree
└── Codex
login-review-worktree
└── OpenCode
Orca는 각 에이전트의 상태를 터미널 신호 등을 통해 감지합니다.
그냥 일반적으로 cmd창에 claude, codex를 호출하는 것 과 같습니다.
공식 문서 기준 상태 표시는 대략 다음 의미를 갖는다.
작업 중
사용자의 입력을 기다리는 중
유휴 상태
일반 셸 터미널
이 상태가 worktree 목록과 탭에 표시되므로, 사용자가 터미널을 하나씩 열어 보지 않아도 어떤 에이전트가 작업 중인지 확인할 수 있습니다.
하지만 Orca에 진짜 기능은 Orca /orchestration skill입니다!!
Orchestration이란?
Photo by 고영혁 on July 14, 2026. May be an image of text.
작업 공간을 여러 개 만드는 것 만으로 여러 에이전트가 자동으로 협업하는 것은 아닙니다.
누군가는 다음 작업을 해야 합니다.
전체 요구사항을 분석한다.
작업을 작은 단위로 나눈다.
어떤 에이전트가 어떤 작업을 맡을지 결정한다.
각 에이전트의 진행 상황을 확인한다.
완료된 결과를 모은다.
여러 결과를 비교하고 최종 결과를 정리한다.
이 역할을 담당하는 것이 Coordinator, 즉 코디네이터입니다.
Orca의 Orchestration은 하나의 에이전트가 코디네이터 역할을 맡아 여러 작업 에이전트를 지휘할 수 있도록 만드는 기능이다.
Orchestration을 실행한 에이전트가 코디네이터가 된다!!!
예를 들어 Claude Code에게 다음과 같이 요청한다고 가정해 봅니다.
수강 신청 시스템의 동시성 문제를 분석해줘.
Race Condition 재현 테스트,
DB 비관적 락 구현,
Redis 분산 락 구현,
성능 비교 작업을 각각 나누어 진행하고
마지막에 결과를 종합해줘.
/orchestration 스킬을 사용해줘
그리고 Claude Code가 다음 명령을 실행한다.
orca orchestration run \
--spec "수강 신청 시스템의 동시성 문제를 분석하고 여러 에이전트에게 작업을 나누어 수행한 뒤 결과를 종합한다." \
--max-concurrent 3 \
--worktree active \
--json
이 흐름에서는 Claude Code가 전체 작업을 관리하는 코디네이터 역할을 하게 됩니다.
정확히는 코디네이터 에이전트가 전체 목표를 이해하고, Orca가 제공하는 Coordinator Loop를 이용해 작업을 배분하고 추적합니다
전체 흐름은 다음과 같습니다.
사용자
│
│ 큰 요구사항 전달
▼
Coordinator Agent
│
├── 작업 분석
├── 작업 분할
├── 담당 에이전트 선택
├── 진행 상황 확인
└── 결과 종합
│
├──────────────┬──────────────┐
▼ ▼ ▼
Worker A Worker B Worker C
분석 담당 구현 담당 테스트 담당
│ │ │
└──────────────┴──────────────┘
│
│ 작업 결과 보고
▼
Coordinator Agent
│
▼
최종 결과 정리
│
▼
사용자
여기서 실제 코드를 구현하는 에이전트들을 Worker Agent라고 합니다.
Coordinator가 하는 일
Coordinator는 모든 코드를 직접 구현하는 에이전트가 아닙니다.
프로젝트 관리자나 개발 리더에 더 가까운 역할을 한다.
- 전체 요구사항을 분석한다
먼저 사용자가 요청한 작업을 이해합니다.
수강 신청 시스템에서
동시 요청이 들어와도
정원을 초과하면 안 된다.
Coordinator는 이 요구사항을 그대로 하나의 에이전트에게 넘기지 않고, 어떤 작업이 필요한지 분석합니다.
- 큰 작업을 작은 작업으로 나눈다
예를 들어 다음과 같이 작업을 나눌 수 있습니다.
Task 1. 현재 수강 신청 로직 분석
Task 2. Race Condition 재현 테스트 작성
Task 3. DB 비관적 락 구현
Task 4. Redis 분산 락 구현
Task 5. 부하 테스트 실행
Task 6. 결과 비교
이처럼 큰 작업을 여러 개의 작은 작업으로 분리해야 여러 에이전트가 동시에 작업할 수 있습니다.
- 작업을 Worker에게 분배한다
Coordinator는 각 작업을 처리할 에이전트를 선택합니다.
Codex Worker 1
→ Race Condition 테스트 작성
Codex Worker 2
→ DB 비관적 락 구현
Claude Code Worker
→ Redis 분산 락 구현
각 Worker는 독립적인 Git Worktree에서 작업합니다.
따라서 여러 에이전트가 동시에 작업해도 파일이 서로 뒤섞이지 않는다.
- 진행 상황을 확인한다
작업을 분배했다고 Coordinator의 역할이 끝나는 것은 아닙니다.
Coordinator는 각 Worker가 정상적으로 작업하고 있는지 확인합니다.
Worker 1 → 테스트 코드 작성 중
Worker 2 → 구현 완료
Worker 3 → Redis 연결 설정 문제 발생
오래 걸리는 작업은 Worker가 중간 상태를 보고할 수 있습니다.
예를 들어 다음과 같습니다.
현재 구현을 완료했고 부하 테스트를 실행하고 있습니다.
Worker가 스스로 결정하기 어려운 문제가 발생하면 Coordinator에게 질문할 수도 있다.
공통 서비스 코드를 수정할까요?
현재 구현 클래스 안에서만 처리할까요?
Coordinator는 질문에 답하거나, 중요한 결정이라면 사용자에게 다시 확인합니다.
- 작업 완료 여부를 확인한다
Worker는 작업이 끝나면 Coordinator에게 완료 사실을 보고합니다.
Race Condition 재현 테스트 작성 완료
DB 비관적 락 구현 완료
Redis 분산 락 구현 완료
단순히 “완료했습니다”라고만 전달하는 것이 아니라 다음과 같은 결과를 함께 전달할 수 있습니다.
수정한 파일
실행한 테스트
발견한 문제
남아 있는 작업
작성한 보고서 경로
Coordinator는 이를 바탕으로 각 작업이 실제로 완료되었는지 확인합니다.
- 여러 작업 결과를 종합한다
각 Worker의 작업이 모두 끝나면 Coordinator가 결과를 모읍니다.
예를 들어 DB 비관적 락과 Redis 분산 락의 결과를 다음처럼 비교할 수 있습니다.
데이터 정합성 보장 보장
구현 난이도 낮음 높음
추가 인프라 불필요 Redis 필요
장애 복구 비교적 단순 락 만료 설계 필요
분산 환경 DB 중심 여러 서버에서 활용 가능
Coordinator는 Worker가 만든 코드를 단순히 이어 붙이는 것이 아니라 다음 내용을 최종적으로 정리합니다.
어떤 작업을 수행했는가?
각 방법의 장단점은 무엇인가?
테스트 결과는 어떠한가?
어떤 방법을 적용하는 것이 적절한가?
추가로 확인할 위험은 무엇인가?
그리고 정리된 최종 결과를 사용자에게 전달합니다.
일반적인 AI 요청과 무엇이 다를까?
일반적인 AI 코딩 요청은 다음과 같습니다.
사용자
│
▼
AI Agent
│
├── 분석
├── 구현
└── 테스트
모든 작업이 한 에이전트에게 집중된다.
Orchestration을 사용하면 다음처럼 바뀐다.
사용자
│
▼
Coordinator Agent
│
├── Worker A → 분석
├── Worker B → 구현
├── Worker C → 테스트
└── Worker D → 리뷰
│
▼
결과 종합
작업이 독립적이라면 여러 Worker가 동시에 실행될 수 있으므로 전체 작업 시간을 줄일 수 있습니다.
또한 분석, 구현, 테스트, 리뷰를 서로 다른 에이전트가 수행하기 때문에 하나의 에이전트가 놓친 문제를 다른 에이전트가 발견할 가능성도 생깁니다.
모든 작업에 Orchestration이 필요한 것은 아니다
Orchestration은 여러 에이전트를 사용한다고 항상 좋은 것은 아닙니다.
다음과 같은 작은 작업은 하나의 에이전트에게 바로 요청하는 편이 낫습니다.
메서드 이름 변경
간단한 NullPointerException 수정
SQL 조건 하나 추가
테스트 한 개 수정
주석이나 문서 보완
이런 작업까지 여러 Task로 나누면 업무를 분배하고 결과를 합치는 비용이 실제 개발 비용보다 커질 수 있다.
반대로 다음과 같은 작업에는 Orchestration이 유용합니다.
신규 기능 전체 구현
대규모 리팩터링
여러 해결 방법 비교
동시성 문제 분석
성능 개선
마이그레이션
테스트와 코드 리뷰 병렬 수행
판단 기준은
작업을 서로 독립적인 두 개 이상의 단위로 나눌 수 있는가?
독립적인 작업이 여러 개라면 Orchestration의 장점을 활용할 수 있습니다.
마무리
그 이외에도 Orca Ide는 기존에 존재하던 IDE 처럼 git관리, 파일 미리보기(html, png, pdf 등), 파일 수정등이 가능합니다.
개인적으로 일주일 동안 사용해 봤는데 확실히 개발속도는 빨라졌습니다.
물론 작성되는 코드량이 2배 4배 늘어나니 작성된 코드를 직접 리뷰하는데 시간이 더 오래걸리는 문제도 있고 여러 Agent들을 호출하여 사용 하다보니
토큰 소모도 더 빨라졌습니다.
토큰이 넉넉하고 사람이 코드리뷰를 하지 않고 전적으로 AI에게 개발을 맡긴다는 가정하에서는 이만한 IDE도 없을 것 같습니다.
이글 작성하자마자 달아준 팀장님의 최고의 찬사
