UX 개발 / 바이브코딩

Orca·Paseo·OmO로 이해하는 최신 바이브코딩: 병렬 에이전트 실전 가이드

Vibe CodingOrcaPaseoOmOAI AgentMulti-AgentAgent OrchestrationGit WorktreeOpenCode

바이브코딩의 관심사가 빠르게 바뀌고 있다. 처음에는 “어떤 모델이 코드를 더 잘 쓰는가”가 중요했다면, 이제는 여러 코딩 에이전트를 어떻게 격리하고, 역할을 나누고, 원격에서 지켜보고, 결과를 검증할 것인가가 더 중요한 문제가 됐다.

최근 주목받는 Orca, Paseo, OmO는 이 변화를 잘 보여 준다. 세 도구 모두 여러 AI 코딩 에이전트를 다루지만 같은 제품군은 아니다.

  • Orca는 사람이 여러 작업공간과 에이전트를 한 화면에서 운영하는 Agent Development Environment(ADE)다.
  • Paseo는 내 컴퓨터나 서버에서 에이전트를 실행하고 데스크톱·모바일·CLI로 제어하는 self-hosted control plane이다.
  • **OmO(Oh My OpenAgent)**는 OpenCode와 Codex 안에서 전문 agent, model routing, hook과 도구를 결합하는 agent harness다.

이 글은 2026년 8월 6일 기준 각 프로젝트의 공식 저장소와 문서를 확인해 작성했다. 이 분야는 릴리스 속도가 매우 빠르므로 설치 전에는 반드시 최신 공식 문서를 다시 확인해야 한다.

먼저 이름과 대상을 정확히 구분하자

Orca라는 이름의 AI 프로젝트는 여러 개다. 이 글에서 다루는 Orca는 stablyai/orca, 즉 onOrca.dev에서 배포하는 ADE다. DeepSeek 전용 terminal agent나 다른 orchestration framework를 뜻하지 않는다.

Paseo는 getpaseo/paseo와 paseo.sh를 기준으로 한다.

OmO는 code-yeongyu/oh-my-openagent를 뜻한다. 과거 이름과 package name에 oh-my-opencode가 남아 있어 검색 결과가 섞일 수 있지만, 현재 문서와 서비스 이름은 Oh My OpenAgent, 줄여서 OmO다.

세 도구는 서로 다른 층을 담당한다

도구제품의 층핵심 역할가장 잘 맞는 사용자
OrcaADE·시각적 작업환경여러 agent와 worktree를 한 화면에서 실행·비교·리뷰데스크톱에서 병렬 작업과 UI 검토가 많은 개발자
Paseodaemon·control plane내 장비의 agent를 원격·모바일·CLI·API로 실행하고 조정Mac mini, VPS, homelab을 계속 켜 두고 쓰는 사용자
OmOagent harness하나의 요청을 planner·researcher·coder·reviewer 역할과 모델로 라우팅OpenCode 또는 Codex 내부 작업 품질과 자동화를 높이고 싶은 사용자

쉽게 비유하면 Orca는 관제실, Paseo는 원격 운행 시스템, OmO는 팀의 역할·작업 규칙에 가깝다. 그래서 서로 완전히 대체하지도 않고, 무조건 세 개를 함께 설치할 필요도 없다.

최신 바이브코딩에서 달라진 다섯 가지

1. 한 채팅에서 여러 격리 작업공간으로

예전에는 한 agent가 한 폴더를 계속 수정했다. 이제는 작업마다 별도 Git branch와 worktree를 만들고 여러 agent가 동시에 일한다.

main repository
├── worktree: feature/login-ui    → UI agent
├── worktree: fix/payment-race   → debugging agent
└── worktree: review/api-change  → review agent

Orca는 이 구조를 UI의 중심에 둔다. 같은 prompt를 여러 agent에 보내 결과를 비교하거나, 작업별 worktree를 따로 열어 diff와 preview를 확인할 수 있다. Paseo 역시 새로운 agent를 worktree-isolated workspace에 실행할 수 있다.

중요한 점은 worktree가 보안 sandbox는 아니라는 것이다. 파일 checkout과 Git branch는 분리되지만, 같은 사용자 권한으로 실행한 프로세스는 환경변수, credentials, network, 다른 경로에 접근할 수 있다. 위험한 코드를 실행할 때는 container나 별도 VM 같은 실행 격리가 추가로 필요하다.

2. 한 모델에서 역할별 모델 라우팅으로

모든 작업에 가장 비싼 모델을 사용할 필요는 없다. 빠른 repository 탐색은 작은 모델, 구조 설계는 reasoning model, UI 분석은 vision-capable model, 최종 검토는 독립 reviewer에게 맡길 수 있다.

OmO는 이 방식을 제품의 핵심으로 삼는다. main orchestrator인 Sisyphus, planner인 Prometheus, executor인 Atlas, architecture consultant인 Oracle, documentation search를 맡는 Librarian 등 전문 역할을 두고, quick, deep, visual-engineering, ultrabrain 같은 category를 적합한 model과 연결한다.

장점은 사용자가 매번 model name을 고르지 않아도 된다는 것이다. 단점은 routing 규칙이 복잡해지고, 잘못 구성하면 작은 작업에도 여러 agent가 움직여 비용과 시간이 늘어난다는 점이다.

3. 터미널 세션에서 daemon과 원격 제어로

Paseo는 coding agent 자체가 아니라 agent CLI를 실행하고 관리하는 local daemon이다. Claude Code, Codex, OpenCode 같은 기존 도구와 로그인 상태를 그대로 사용하고, desktop·mobile·web·CLI client가 daemon에 연결한다.

덕분에 책상에서 작업을 시작하고 이동 중 휴대폰으로 상태를 확인하거나, 집의 Mac mini에서 agent를 실행한 뒤 다른 장소에서 follow-up을 보낼 수 있다. schedule과 API를 이용하면 정기적인 테스트·리뷰·문서 업데이트도 자동화할 수 있다.

4. 코드 생성에서 검증 loop로

새로운 도구들의 공통점은 “코드를 많이 생성한다”보다 “작업이 끝났는지 반복해서 확인한다”에 있다.

Plan → Implement → Test → Review → Fix → Re-test → Deliver

Paseo의 /paseo-loop, OmO의 ultrawork와 /start-work, Orca의 diff annotation과 preview는 형태는 다르지만 같은 방향을 가진다. 성공 조건을 먼저 정하고, 구현자와 reviewer를 분리하며, test나 observable result가 나올 때까지 반복한다.

5. 사람이 agent를 쓰는 것에서 agent가 agent를 운영하는 것으로

Orca와 Paseo는 CLI·MCP·skills를 통해 agent가 새로운 worktree나 subagent를 만들 수 있게 한다. OmO는 harness 내부에서 역할별 agent에게 작업을 위임한다.

이제 prompt는 “버튼을 만들어 줘”에서 다음처럼 변한다.

목표: 결제 실패 후 재시도 UX를 구현한다.

Planner:
- 현재 결제 상태 흐름과 실패 종류를 조사한다.
- 범위와 acceptance criteria를 작성한다.

Implementer:
- 별도 worktree에서 최소 변경으로 구현한다.

Reviewer:
- 결제 중복 요청, 접근성, 모바일 레이아웃을 독립 검토한다.

Verifier:
- focused test, typecheck, build를 실행한다.
- 실패하면 implementer에게 근거와 함께 돌려보낸다.

프롬프트 하나의 문장보다 역할, 파일 범위, 입력·출력 계약, 종료 조건이 중요해진 것이다.

Orca 활용법: 병렬 결과를 눈으로 비교하고 싶을 때

Orca는 Claude Code, Codex, OpenCode 등 terminal에서 실행되는 여러 agent를 worktree 단위로 한곳에 모은다. embedded terminal, file editor, diff review, browser preview, Design Mode, SSH worktree, mobile companion을 제공한다.

설치

공식 download page에서 운영체제별 앱을 받거나 macOS에서는 Homebrew를 사용할 수 있다.

brew install --cask stablyai/orca/orca

설치 후에도 Claude Code나 Codex 같은 실제 coding agent는 각자 설치하고 인증해야 한다. Orca가 model subscription을 대신 제공하는 것은 아니다.

가장 효과적인 첫 workflow

처음부터 다섯 agent를 동시에 실행하지 말고 같은 기준으로 두 개만 비교한다.

  1. 깨끗한 main에서 feature/search-empty-state 작업을 만든다.
  2. 첫 worktree에는 Claude Code, 두 번째에는 Codex를 실행한다.
  3. 두 agent에 같은 목표, 수정 가능 파일, acceptance criteria를 준다.
  4. 각 worktree의 preview와 diff를 비교한다.
  5. 더 나은 결과 하나를 선택하고, 다른 결과의 좋은 아이디어만 review comment로 전달한다.
  6. 선택한 branch에서 test와 build를 다시 실행한 뒤 merge한다.
목표: 검색 결과가 없을 때 empty state를 추가한다.

수정 가능 범위:
- src/components/SearchResults.tsx
- src/styles/search.css

성공 조건:
- 결과가 0개일 때만 empty state가 보인다.
- 키보드와 screen reader에서 의미가 전달된다.
- 320px 화면에서 가로 overflow가 없다.
- 기존 search tests와 build가 통과한다.

금지:
- API와 routing 변경
- 공통 button component 리팩터링
- 새 package 설치

UI 작업에서는 Orca의 Design Mode로 실제 browser element를 선택해 HTML, CSS, screenshot context를 agent에게 전달할 수 있다. 다만 자동 생성된 수정안을 바로 commit하지 말고 diff annotation으로 불필요한 변경을 되돌려 보내는 과정이 핵심이다.

Orca가 잘 맞지 않는 경우

  • GUI보다 headless server와 automation이 중요한 경우
  • 하나의 agent만 쓰며 병렬 branch가 거의 없는 경우
  • Git을 사용하지 않는 단순 prototype
  • worktree를 보안 sandbox로 오해하고 untrusted code를 실행하려는 경우

Orca의 packaged build는 anonymous usage telemetry를 사용하지만 공식 privacy 설정, DO_NOT_TRACK=1, ORCA_TELEMETRY_DISABLED=1로 끌 수 있다. 문서상 prompt, file contents, terminal output은 전송하지 않지만 조직 정책에 맞는지 직접 검토해야 한다.

Paseo 활용법: 내 장비의 agent를 어디서나 운영하고 싶을 때

Paseo는 local daemon이 기존 agent CLI를 subprocess로 실행하고, 여러 client가 그 daemon을 제어하는 구조다. agent는 내 laptop, Mac mini, server, Docker에서 실행되고 mobile과 desktop은 상태를 보고 명령을 전달한다.

설치

Desktop app이 가장 간단하다. headless machine이나 CLI 중심 환경에서는 다음처럼 설치한다.

npm install -g @getpaseo/cli
paseo

먼저 Claude Code, Codex, OpenCode 중 최소 하나가 해당 장비에서 정상 실행되고 인증되어 있어야 한다.

worktree에 agent 실행하기

paseo run \
  --provider codex \
  --new-workspace worktree \
  --worktree-mode branch-off \
  --new-branch feature/profile-form \
  --base main \
  "Implement the profile form using the acceptance criteria in issue 142. Run focused tests and build."

실행 후에는 다음 명령으로 관리한다.

paseo ls
paseo attach <agent-id>
paseo send <agent-id> "Also verify keyboard navigation."
paseo logs <agent-id> --tail 20
paseo wait <agent-id> --timeout 300

--background를 쓰면 agent를 계속 실행한 채 ID만 받을 수 있다. --output-schema로 결과를 JSON schema에 맞추면 CI나 automation에서 reviewer verdict를 파싱하기 쉬워진다.

orchestration skills 활용하기

Paseo의 공식 skills를 추가하면 agent가 다른 provider의 agent를 만들고 관리하는 방법을 배운다.

npx skills add getpaseo/paseo

주요 흐름은 다음과 같다.

  • /paseo-handoff: Claude로 계획하고 Codex로 구현하는 식의 handoff
  • /paseo-loop: acceptance criteria와 verifier를 기준으로 반복
  • /paseo-advisor: 구현 권한 없이 두 번째 의견 받기
  • /paseo-committee: 서로 다른 두 agent가 원인과 계획 검토

처음에는 /paseo-advisor처럼 read-only에 가까운 활용부터 시작하고, 자동 구현·merge·schedule은 충분한 검증 뒤에 추가하는 편이 안전하다.

원격 연결 보안

Paseo daemon은 기본적으로 127.0.0.1:6767에 bind된다. 공식 문서는 mobile 연결에 end-to-end encrypted relay를 권장한다. 직접 연결한다면 Tailscale 같은 VPN과 password를 함께 사용한다.

paseo daemon set-password

다음은 피해야 한다.

0.0.0.0:6767에 password 없이 공개
pairing QR 또는 offer URL을 공개 채널에 공유
Docker에 홈 디렉터리 전체와 모든 credentials를 mount
원격 agent에게 무제한 shell 권한을 준 채 unattended schedule 실행

Paseo는 provider API key를 직접 관리하지 않지만, agent process는 현재 사용자 context와 기존 credentials로 실행된다. daemon 보안과 agent 권한은 별개로 관리해야 한다.

OmO 활용법: 하나의 agent를 역할 기반 팀으로 바꾸고 싶을 때

OmO는 OpenCode를 중심으로 동작하는 multi-model agent orchestration harness이며, Codex용 Light edition도 제공한다. current docs 기준으로 planner, orchestrator, architecture reviewer, repository explorer, documentation researcher 등 11개 built-in agent와 LSP·AST 도구, hooks, skills, MCP integration을 묶는다.

설치 전에 먼저 알아둘 점

공식 문서는 설치 prompt를 agent에게 전달하는 방법을 우선 안내하지만, remote instruction을 그대로 실행시키기 전에 원문을 직접 읽는 편이 안전하다. 수동 설치 entry point는 다음과 같다.

bunx oh-my-openagent install

설치 과정에서 OpenCode, Codex 또는 둘 다를 선택하고 연결된 provider subscription을 묻는다. 설치 후에는 doctor로 실제 model resolution과 도구 상태를 확인한다.

bunx oh-my-openagent doctor --verbose

Codex 전용 Light edition에서 자동 full-permission 설정을 원하지 않는다면 명시적으로 끈다.

npx lazycodex-ai install --no-tui --no-codex-autonomous

공식 installer는 선택에 따라 Codex에 approval_policy = "never", sandbox_mode = "danger-full-access", network_access = "enabled"를 설정할 수 있다. 이는 편리함이 아니라 실질적인 권한 확대다. 격리된 disposable environment가 아니라면 먼저 --no-codex-autonomous로 시작하는 것을 권한다.

작업 난이도별 사용법

간단한 수정은 평소처럼 요청한다.

Fix the typo in the empty-state message. Do not change other files.

범위가 복잡하지만 agent에게 탐색을 맡기고 싶을 때는 prompt에 ulw 또는 ultrawork를 포함한다.

ulw
Investigate the intermittent checkout failure, reproduce it, implement the smallest fix,
run relevant tests, and report remaining risks. Do not change payment provider configuration.

정확한 의사결정 기록이 필요한 작업은 Prometheus planning과 Atlas execution을 나눈다.

@plan "Migrate the account settings page without changing the public API"

질문에 답해 plan이 확정되면 다음을 실행한다.

/start-work

이 방식은 multi-day project, 큰 refactoring, production-critical change에 적합하다. 반대로 한 줄 수정에 ultrawork를 사용하면 research와 delegation이 과도해질 수 있다.

OmO의 라이선스와 빠른 변화

확인 시점의 package는 SUL-1.0을 선언하고 있으며 repository의 Sustainable Use License는 internal business, personal, non-commercial use와 무료 비상업적 배포를 중심으로 허용 조건을 설명한다. MIT나 Apache-2.0과 동일한 permissive license가 아니므로 재배포, 유료 서비스 포함, 상용 제품 bundling을 고려한다면 원문을 검토해야 한다.

또한 package name, product name, install path가 최근 여러 번 바뀌었다. 오래된 글의 oh-my-opencode 명령과 최신 oh-my-openagent 명령을 섞어 설치하지 말고, doctor가 보고하는 실제 loaded version과 config를 기준으로 문제를 해결한다.

어떤 도구를 선택해야 할까

원하는 결과먼저 선택할 도구이유
같은 기능을 여러 agent에 맡겨 결과 비교Orcaworktree, terminal, preview, diff review가 한 화면에 있음
UI를 browser에서 보며 agent에게 정확히 수정 요청Orcaembedded Chromium과 Design Mode 중심 workflow
집이나 회사 장비의 agent를 휴대폰에서 제어Paseodaemon-client 구조와 mobile·relay 지원
headless server에서 agent job을 script와 schedule로 운영PaseoCLI, API, output schema, schedule이 핵심 기능
OpenCode 안에서 planner·coder·reviewer 역할 자동화OmO전문 agent와 category-based model routing 제공
작은 저장소에서 가끔 한 agent만 사용기존 Claude Code·Codexorchestration layer가 오히려 복잡성을 늘릴 수 있음

가장 좋은 선택은 기능이 가장 많은 도구가 아니라, 지금의 병목을 하나만 해결하는 도구다.

함께 사용할 때의 권장 구조

세 도구는 조합할 수 있지만 처음부터 모두 겹치면 “누가 worktree를 만들었는지, 누가 subagent를 종료해야 하는지, 어느 layer가 완료를 판단하는지”가 불분명해진다.

Human
└── 하나의 outer control layer
    ├── Orca: visual worktree supervision
    └── 또는 Paseo: remote daemon orchestration
        └── coding agent runtime
            ├── Claude Code / Codex
            └── OpenCode + OmO harness

권장 원칙은 다음과 같다.

  1. Orca와 Paseo 중 outer control layer는 하나만 먼저 선택한다.
  2. OmO를 안쪽에 넣을 때는 outer layer와 internal Team Mode가 동시에 무제한 spawn하지 않도록 concurrency를 제한한다.
  3. 한 작업의 branch와 worktree owner를 하나로 정한다.
  4. merge 권한은 기본적으로 사람에게 남긴다.
  5. reviewer는 implementer와 다른 session 또는 model을 사용한다.

예를 들어 UI 중심 팀은 Orca worktree 하나 안에서 OmO의 planning·review 기능만 사용하고, OmO Team Mode는 끈 상태로 시작할 수 있다. 원격 automation이 중심이라면 Paseo가 worktree와 agent lifecycle을 관리하고, OpenCode+OmO는 해당 workspace 안의 implementation 품질을 담당하게 할 수 있다.

실패를 줄이는 실전 운영 규칙

1. 병렬 수보다 독립성을 먼저 확인한다

두 작업이 같은 shared config, schema, lockfile, global CSS를 수정하면 worktree를 나눠도 merge conflict와 logic conflict가 생긴다. 병렬화할 작업은 수정 파일과 의존성이 겹치지 않아야 한다.

2. 모든 agent에 같은 acceptance criteria를 준다

비교 실험에서 agent마다 다른 prompt를 쓰면 model 차이가 아니라 요구사항 차이를 비교하게 된다. 목표, 금지 범위, test command를 동일하게 유지한다.

3. reviewer에게 쓰기 권한을 주지 않는다

reviewer의 목적은 문제를 찾는 것이다. 가능하면 read-only mode를 사용하고, 결과를 implementer에게 근거와 함께 전달한다.

4. 자동 완료 조건을 명령으로 만든다

완료 조건:
- npm run test -- checkout 통과
- npm run typecheck 통과
- npm run build 통과
- 변경 파일이 승인된 범위 안에 있음
- reviewer의 blocking issue가 0개임

“잘 동작함”보다 exit code와 diff 범위처럼 machine-checkable한 조건이 좋다.

5. 비용과 rate limit을 관찰한다

agent를 네 개 실행하면 속도가 네 배가 되는 것이 아니라 token 사용량, API 호출, duplicate research가 함께 늘어난다. 먼저 두 개로 시작하고, 역할별로 fast·cheap model과 high-reasoning model을 구분한다.

6. 최종 merge 전 사람의 이해를 확인한다

다음 질문에 답할 수 없다면 merge를 미룬다.

  • 왜 이 파일들이 바뀌었는가?
  • 핵심 로직을 한 문단으로 설명할 수 있는가?
  • 어떤 test가 어떤 위험을 검증하는가?
  • 문제가 생기면 어느 commit을 되돌려야 하는가?
  • secret, migration, external service에 어떤 영향이 있는가?

30분 도입 계획

처음 시험한다면 다음 범위면 충분하다.

  1. production secret이 없는 작은 repository를 고른다.
  2. 현재 test와 build가 통과하는지 baseline을 기록한다.
  3. Orca, Paseo, OmO 중 현재 문제에 맞는 하나만 설치한다.
  4. 두 파일 이하의 독립적인 작업을 고른다.
  5. agent 수를 최대 두 개로 제한한다.
  6. 수정 가능 파일, 금지 사항, acceptance criteria를 prompt에 넣는다.
  7. diff, test, build 결과를 사람이 확인한다.
  8. 소요 시간, token·subscription 사용량, 무관한 변경 수를 기록한다.

첫 실험의 목표는 “더 빨리 만들기”가 아니라 어디에서 통제가 필요하고 어떤 자동화가 실제로 도움이 되는지 알아내는 것이다.

최종 체크리스트

  • 이 글의 Orca가 stablyai/orca임을 확인했다.
  • Orca는 ADE, Paseo는 daemon control plane, OmO는 agent harness라는 차이를 이해했다.
  • worktree와 security sandbox를 구분했다.
  • outer orchestration layer를 하나만 선택했다.
  • agent별 branch, 파일 범위, 종료 조건을 정했다.
  • 원격 daemon에 password, encrypted relay 또는 VPN을 적용했다.
  • OmO 설치 시 autonomous full-permission 설정 여부를 직접 결정했다.
  • OmO의 current license와 redistribution 조건을 검토했다.
  • reviewer와 implementer를 분리했다.
  • test·build·diff review 후에만 merge한다.

Orca, Paseo, OmO가 보여 주는 최신 바이브코딩의 방향은 분명하다. 앞으로의 경쟁력은 prompt를 멋지게 쓰는 능력만으로 결정되지 않는다. 여러 agent가 충돌하지 않게 작업공간을 설계하고, 역할과 모델을 적절히 라우팅하며, 사람이 검증 가능한 상태로 결과를 돌려받는 운영 능력이 더 중요해지고 있다.

참고 자료

Related