Orca vs Paseo 통제 비교 — 같은 지시문 4라운드 실측 기록
코딩 에이전트 오케스트레이터 두 종을 동일 조건에서 4라운드 돌린 기록. 산출물은 전 라운드 동일했고 차이는 병렬 실행 관측성에서만 나타났다.
방구석컴퍼니
혼자 일하는 사람 · 작업 기록
이 문서가 다루는 범위
코딩 에이전트 오케스트레이터 도입을 앞두고 어느 쪽을 깔지 정해야 하는 분을 위한 정리다.
결론
Orca와 Paseo는 산출물로 구분되지 않는다. 동일 지시문·동일 입력 데이터로 4라운드를 돌린 결과, 세 과제 모두 두 도구의 출력 수치가 일치했다. 두 도구 모두 실행 주체가 같은 언어 모델이므로 이는 예측 가능한 결과다.
구분이 발생한 지점은 작업을 병렬로 세울 때의 관측성과 기본 권한 정책 두 가지다. 이 문서는 그 판정에 이른 절차와 원자료를 남긴다.
비교 대상의 정의
두 제품은 모두 Electron 데스크톱 애플리케이션이며, 카테고리는 코딩 에이전트 오케스트레이터다. 에이전트 자체를 구현하지 않고, 외부 에이전트(Claude Code·Codex 등)를 실행·격리·감시하는 계층을 제공한다.
| 항목 | Orca | Paseo |
|---|---|---|
| 검증 버전 | 1.4.180 | 0.3.1 |
| 진입 지점 | 터미널 세션 | 프롬프트 입력 필드 |
| 작업 격리 | worktree 생성 | 신규 워크스페이스 |
| 병렬 전용 뷰 | 워크스페이스 보드 | 없음 (목록) |
| 배포 채널 | 데스크톱 + 페어링 | 데스크톱 + 웹 + iOS/Android |
통제 방법
도구 비교에서 가장 흔한 오염원은 지시문 표류다. 한쪽을 먼저 돌리며 프롬프트를 다듬으면, 나중에 돌린 쪽이 정제된 지시문의 이득을 가져간다. 이를 막기 위해 다음을 고정했다.
- 지시문 동결 — 세 과제의 프롬프트를 실행 이전에 파일로 확정하고 이후 수정하지 않았다.
- 입력 데이터 결정론화 — 픽스처 생성 스크립트가 난수와 현재시각을 사용하지 않는다. 기준 시각을 상수(
BASE = 1786000000)로 고정해 파일 22개의 타임스탬프까지 재현 가능하게 만들었다. - 산출물 직접 실행 — 도구가 보고한 값을 신뢰하지 않고, 생성된 스크립트를 별도로 실행해 결과를 대조했다.
- 함정 사전 배치 — 인코딩 3종, 날짜 표기 3종, 파일 간 중복 결제 1건, 취소·환불 각 1건을 미리 심었다.
라운드 1~3 결과
| 과제 | 검증 지표 | Orca | Paseo |
|---|---|---|---|
| 다운로드 정리 | 이동 / 중복삭제 / 원본 | 20 / 2 / 22 무결 | 20 / 2 / 22 무결 |
| 명세서 통합 | 건수 / 합계 | 26건 / 385,970원 | 26건 / 385,970원 |
| 가격 수집 | 성공 / 차단 | 51.77 GBP / HTTP 403 | 51.77 GBP / HTTP 403 |
세부 분류도 일치했다. 식비 10건 213,670원, 교통 6건 36,400원, 쇼핑 7건 93,100원, 구독 3건 42,800원.
양쪽 모두 외부 패키지를 설치하지 않고 표준 라이브러리만으로 xlsx 파일을 직접 구성했으며, 지시문에 없던 대상 경로 옵션을 자발적으로 추가했다. 이 두 가지가 동시에 일치했다는 사실이 "같은 모델이 풀었다"는 해석을 뒷받침한다.
관측된 실행 편차
라운드 간 미세한 차이는 있었다. 한 회차에서 Orca 측 에이전트가 응답 헤더를 분해해 차단 주체를 CDN 계층(Akamai)으로 특정하고 참조 번호까지 인용했다. 다른 회차에서는 같은 에이전트가 자기가 작성한 차단 감지 로직의 오작동을 발견해 스스로 수정했다.
이는 도구 성능이 아니라 동일 모델의 회차 간 분산이다. 단발 관측을 제품 차이로 보고하면 오판이 된다.
라운드 4 — 병렬 실행
독립 과제 3건을 동시에 투입했다. 오케스트레이터의 존재 이유가 이 지점이므로, 비교의 무게는 여기에 있다.
| 관측 항목 | Orca | Paseo |
|---|---|---|
| 3개 생성 소요 | 4.7초 | 12.8초 |
| 최초 시도 | 3건 전부 디렉터리 신뢰 확인에서 정지 | 정지 없음 |
| 완료 | 해제 후 60초 이내 3건 | 43초 · 55초 · 64초 |
| 정지 지점 파악 | 목록에 확인 문구가 그대로 노출 | 상태는 running, 상세 진입 필요 |
Paseo 쪽 상태 표시가 running인 동안 실제로는 권한 대기 상태였다. inspect 명령을 통해서만 PendingPermissions가 드러난다. 상태 문자열과 실제 상태가 어긋나는 구간이 존재한다는 뜻이며, 작업 수가 늘수록 비용이 커지는 종류의 차이다.
이 수치를 속도로 해석하면 안 되는 이유
Paseo는 승인 절차를 생략하는 값을 초기 설정으로 두었고, Orca에서 실행한 Claude Code는 매 동작마다 승인을 요구하는 기본값으로 동작했다. 관측된 개입 횟수 차이는 제품 성능이 아니라 기본 권한 정책의 차이다. 양쪽 모두 설정으로 반전 가능하므로, 이 항목은 성능 지표가 아니라 취향 지표로 읽어야 한다.
선택 축
| 축 | Orca 우위 조건 | Paseo 우위 조건 |
|---|---|---|
| 권한 성향 | 파괴적 동작 전 확인을 원함 | 승인 클릭을 줄이고 싶음 |
| 조작 방식 | 터미널이 이미 손에 익음 | GUI 입력만으로 끝내고 싶음 |
| 동시 실행 규모 | 3개 이상을 상시 굴림 | 1~2개를 순차로 돌림 |
| 접근 환경 | 데스크톱 고정 | 외부·모바일 확인 필요 |
이 기록의 한계
- 표본이 작다. 라운드 4회, 과제 3종이다. 통계적 일반화가 아니라 재현 가능한 관측 기록으로 읽어야 한다.
- 모바일은 미검증이다. 스토어 배포 사실만 확인했을 뿐 실제로 돌려보지 않았다.
- 버전이 빠르게 움직인다. 1.4.180과 0.3.1 기준이며, 특히 Paseo는 0.x 대라 기본값 자체가 바뀔 수 있다.
- 환경 요인 1건을 배제했다. 초기 시도에서 Paseo가 모든 공급자를 오류로 표시했는데, 원인은 실행 셸의 PATH에
claude실행 파일이 없던 것이었다. 제품 결함이 아니므로 판정에서 제외했다.
초기 판정 중 하나를 철회한다
1차 촬영 시점에 나는 "Paseo는 CLI로 생성한 워크스페이스를 사이드바에 표시하지 않는다"고 기록했다. 재촬영에서 이 관측은 틀린 것으로 드러났다. 앱을 재시작하니 세 개가 정상적으로 표시됐다. 실행 중이던 앱의 목록이 갱신되지 않았을 뿐이며, 제품의 한계가 아니다.
같은 이유로 위 표의 항목들도 단발 관측이 아니라 재촬영으로 재확인된 것만 남겼다. 도구 비교에서 가장 흔한 오류는 한 번 본 것을 제품 속성으로 승격시키는 것이다.
재현 방법
지시문 3종과 픽스처 생성 스크립트, 라운드별 정답 기준을 공개해 두었다. 같은 입력으로 돌리면 위 표의 숫자가 그대로 재현된다. 다른 오케스트레이터를 넣어도 비교가 성립한다.
촬영본 전체는 다음 기록 영상에 담았다.