Claude와 Codex를 동시에 켜두면 누가 어느 파일을 고치는지 금방 헷갈린다. 창을 더 여는 일보다 작업을 나누고, 결과를 받아서, 변경 내용을 확인하는 일이 더 어려워진다. Orca 사용법을 익힐 때도 터미널 분할과 작업 조율을 구분해서 보는 편이 좋다.
코드팩토리의 영상은 Orca에서 여러 에이전트를 실행하고 브라우저·Git·원격 컴퓨터로 작업을 이어가는 흐름을 보여준다. 2026년 11월 5일 업로드된 영상과 11월 9일 확인한 공식 문서를 대조해, 따라 할 순서와 달라진 안내를 정리했다. 직접 Orca를 설치해 속도나 안정성을 재현한 벤치마크는 아니다.
Orca는 새 AI 모델이 아니라 코딩 에이전트의 작업환경이다
Orca 공식 소개는 제품을 여러 AI 코딩 에이전트를 나란히 운용하는 데스크톱 IDE로 설명한다. Claude Code나 Codex 같은 도구를 하나의 작업환경에서 다루고, Git 작업트리와 터미널·브라우저를 함께 관리하는 방식이다.
따라서 Orca를 설치했다고 Claude나 Codex의 계정·구독이 새로 생기지는 않는다. 사용할 에이전트의 설치와 인증은 별도로 확인해야 한다. 계정 전환과 사용량 표시도 해당 서비스의 할당량이나 이용 조건을 없애는 기능은 아니다.
영상에서 진행자는 무거운 작업을 할 때 Herdr가 자신에게 더 잘 맞았다고 설명한다. 이는 개인의 사용 경험이다. Orca가 항상 불안정하다거나, GUI가 있는 도구가 언제나 느리다는 비교 실험으로 읽을 필요는 없다.
시작 전에는 설치 위치와 실행 권한부터 확인한다
처음에는 에이전트를 많이 띄우기보다 아래 순서로 작업환경을 확인하자.
- 공식 설치 안내에서 운영체제에 맞는 Orca를 설치한다.
- 사용할 에이전트 CLI가 설치되어 있고, 그 컴퓨터에서 로그인되어 있는지 확인한다.
- 작업할 저장소를 열고 현재 브랜치와 변경 파일을 확인한다.
- 에이전트의 실행 권한과 실제 시작 인자를 검토한다.
- 작은 읽기 중심 작업으로 역할 배정과 결과 보고를 확인한다.
특히 네 번째를 건너뛰지 말자. 지원 에이전트 문서는 새 실행에 권한 확인을 우회하는 인자가 미리 채워질 수 있다고 안내한다. 처음부터 모든 명령을 자동 승인해도 안전하다고 가정해서는 안 된다.
설정의 Agents → Agent Permissions에서 Manual 모드를 검토하자. 기존 세션이나 직접 수정한 실행 인자는 전역 설정과 다를 수 있다. 모드를 바꿨다는 사실만 확인하지 말고 실제 실행 설정도 함께 봐야 한다.
Git 작업트리는 보안 샌드박스가 아니다. Git 공식 문서가 설명하는 작업트리는 같은 저장소에서 여러 작업 디렉터리를 운용하는 기능이다. 파일 변경을 나눌 수 있지만, 그것만으로 에이전트의 운영체제 접근 권한이 제한된다고 볼 수는 없다. Codex의 경우에도 샌드박스와 승인 정책은 별도로 확인할 항목이다.
터미널 여러 개와 오케스트레이션은 어떻게 다른가
여러 터미널을 열고 각각 프롬프트를 보내는 방법은 간단하다. 대신 누가 끝났는지, 어디서 막혔는지, 어느 결과를 다음 작업에 넘길지 사람이 직접 관리해야 한다.
Orca의 오케스트레이션은 그 조율을 구조화하는 기능이다. 영상의 Run·Task·Worker에 더해, 현재 문서의 Dispatch도 알아두면 상태를 읽기 쉽다.
- Run: 협업 기록과 조율자의 수신함을 묶는 지속성 있는 단위다. Run 자체가 워커를 자동 배치하는 스케줄러는 아니다.
- Task: 목표·의존 관계·상태를 가진 개별 작업이다.
- Worker: 배정된 작업을 수행하는 에이전트다.
- Dispatch: 어떤 터미널에서 그 작업을 수행하는지 식별하는 한 번의 실행 시도다.
같은 Task를 재시도할 수 있으므로 작업 ID와 실행 시도를 구분해야 한다. 현재 공식 문서는 워커의 완료·상태 보고에 Task와 Dispatch 식별자를 함께 사용하도록 안내한다. 오래된 실행의 보고를 새 시도의 완료로 착각하지 않기 위한 구분이다.
영상의 메뉴와 명령을 그대로 복사하지 않는다
11월 9일 확인한 오케스트레이션 문서는 과거의 orchestration run 계열 명령을 실제 동작하지 않는 구형 명령으로 안내한다. 현재 흐름은 run-create, task-create, worker-start 등을 사용한다.
문서에는 Experimental 활성화 안내와 함께 패널·스위치가 일시적으로 제공되지 않는다는 고지도 있다. 영상과 같은 버튼이 보이지 않는다면 먼저 설치 버전과 현재 스킬 안내를 확인하자.
다음은 실행 중인 Orca와 현재 오케스트레이션 스킬을 확인하는 공식 문서의 명령이다. macOS·Windows의 orca 이름을 기준으로 적었다. Linux 설치 문서는 CLI 이름을 orca-ide로 안내하므로 해당 환경에서는 명령 이름을 바꿔 확인해야 한다.
orca status --json
orca skills get orchestration --full
첫 명령은 실행 중인 Orca 런타임에 연결할 수 있어야 한다. 이 두 줄을 실행하는 것만으로 워커가 생성되거나 프로젝트 검토가 시작되는 것은 아니다.
첫 협업은 두 에이전트의 읽기 중심 검토로 시작해 본다
처음부터 두 에이전트가 같은 파일을 고치게 하면 변경 충돌부터 다뤄야 할 수 있다. 먼저 같은 프로젝트를 서로 다른 관점에서 검토시키고, 보고서를 받은 뒤 구현 담당을 정해보자.
다음은 영상의 역할 분담 방식을 바탕으로 재구성한 요청 예시다. Claude와 Codex의 능력을 고정적으로 나눈다는 뜻은 아니다. 모델별 역할과 실제 도구 권한은 자신의 환경에 맞춰 정하면 된다.
현재 설치된 Orca 오케스트레이션 스킬을 먼저 읽어라.
현재 열린 프로젝트에서 두 개의 검토 Task를 만들고 각각 워커에게 배정해라.
공통 제한:
- 코드와 설정 파일을 수정하지 않는다.
- 배포, 커밋, 외부 공유 설정 변경을 하지 않는다.
- 추가 실행이나 권한이 필요하면 먼저 보고한다.
Claude 워커:
- 화면 구성, 사용 흐름, 접근성 관점에서 문제를 찾는다.
Codex 워커:
- 입력 검증, 오류 처리, 테스트 누락 관점에서 문제를 찾는다.
각 워커는 파일 위치, 근거, 심각도, 확인하지 못한 사항을 보고한다.
조율자는 Task와 Dispatch를 구분해 두 워커의 보고를 받는다.
중복 의견과 충돌하는 의견을 나누고, 구현에 앞서 우선순위를 제시한다.
프롬프트에 ‘수정하지 말라’고 쓰는 것과 기술적으로 쓰기 권한을 제한하는 것은 다르다. 앞서 확인한 CLI 권한·샌드박스 설정도 함께 적용해야 한다.
두 보고서가 돌아왔다면 의견 수만 합치지 말자. 같은 문제를 다른 말로 썼는지, 실제 파일에서 확인되는지, 검토 범위 밖의 추측은 없는지 확인한다. 구현은 그다음이다.
브라우저 주석은 수정할 대상을 구체적으로 전달하는 도구다
영상에서는 웹페이지의 제목을 선택하고 변경 요청을 붙인다. ‘저 글자’라고 설명하는 대신, 실제 요소를 가리켜 에이전트에 전달하는 방식이다.
현재 Design Mode 문서는 요소의 DOM·CSS·크롭 이미지 등의 맥락을 활용할 수 있다고 설명한다. 소스맵이 제공되는 환경에서는 파일·줄 정보도 얻을 수 있다. 다만 전송 메뉴의 기본 요약과 전체 페이지 정보를 포함하는 옵션은 구분해야 한다.
이 기능을 쓸 때는 다음 순서로 확인해 보자.
- 작업 중인 페이지와 개발 서버가 정상적으로 열리는지 확인한다.
- 바꿀 요소를 선택하고 원하는 결과를 구체적으로 적는다.
- 올바른 에이전트·프로젝트로 요청을 보낸다.
- 수정된 파일과 화면을 각각 확인한다.
- 다른 화면 크기와 관련 동작도 확인한다.
주석을 보냈다고 코드 수정이 끝난 것은 아니다. 제목이 바뀌었더라도 저장 여부나 다른 기능의 정상 동작까지 증명되지는 않는다.
Git 변경 내용과 완료 기준을 마지막에 남긴다
Orca에서는 변경된 파일을 보고 코드의 특정 줄에 메모를 붙이는 작업도 할 수 있다. 영상의 해당 장면은 AI에게 지시한 뒤에도 사람이 변경 내용을 확인할 지점이 남는다는 것을 보여준다.
여러 에이전트가 코드를 수정한다면 작업트리와 수정 범위를 의도적으로 나누자. 터미널을 추가했다는 이유만으로 모든 워커가 서로 다른 작업 디렉터리에 있는 것은 아니다. 같은 파일을 동시에 바꿀 가능성이 있으면 분리 방식부터 정해야 한다.
최종 확인 담당도 지정해 두면 좋다. 아래 항목은 블로그의 운영 제안이다.
- 요청한 변경과 관계없는 파일이 섞이지 않았는가.
- 테스트를 실제로 실행했는가, 실행하지 못했다면 이유가 있는가.
- 브라우저에서 확인한 범위와 확인하지 못한 범위가 나뉘어 있는가.
- 다른 워커의 변경과 충돌하지 않는가.
- 병합·배포 전에 사람이 승인해야 할 사항이 남아 있지 않은가.
사이드바의 완료 표시나 워커의 ‘끝났다’는 보고는 확인의 출발점이다. 정확한 수정과 테스트 통과를 대신하는 증거로 쓰지는 말자.
원격 연결은 SSH 작업트리와 Remote Orca Server를 구분한다
영상 후반에는 다른 컴퓨터를 연결하는 방법이 나온다. 여기서는 원격 기능을 모두 ‘SSH 연결’ 하나로 묶지 않는 것이 중요하다.
공식 원격 서버 안내는 두 방식을 구분한다.
- SSH 작업트리: 내 컴퓨터의 Orca가 런타임을 소유하고, 다른 컴퓨터에서 선택한 작업트리·터미널을 실행하는 방식이다.
- Remote Orca Server: 다른 컴퓨터가 Orca 런타임과 세션을 소유하고, 내 컴퓨터는 그 서버의 화면과 작업에 연결하는 방식이다.
노트북을 덮어도 작업을 이어가려면 이 차이를 확인해야 한다. Remote Orca Server 방식에서는 서버가 켜져 있고 Orca 프로세스와 네트워크가 유지되어야 한다. 에이전트 CLI·저장소·인증 정보도 서버에 필요하다. 노트북에서 로그인했다고 서버 인증까지 자동으로 준비되는 것은 아니다.
공식 안내는 신뢰할 수 있는 LAN이나 Tailscale 같은 사설 경로를 권장한다. Orca 포트를 인터넷에 직접 공개하는 방식은 피하자. 페어링 링크는 런타임 접근 권한을 주므로 비밀번호처럼 다루고, 잘못 공유했다면 서버의 접근 권한을 철회해야 한다.
모바일과 계정 관리는 편의 기능의 범위를 확인한다
모바일 안내는 현재 동반 앱을 베타로 설명한다. 상태 확인, 짧은 응답, 변경 내용 확인 등을 휴대전화에서 이어갈 수 있지만 연결 대상 Orca 런타임이 필요하다. 휴대전화가 독립적으로 같은 개발 환경을 실행하는 것은 아니다.
진행자가 모바일 사용을 선호하지 않는다는 평가는 자신의 작업 방식에 따른 의견이다. 긴 코드를 검토할지, 상태만 볼지에 따라 필요한 기능은 달라진다. 데스크톱·서버·모바일 사이의 버전 호환성도 확인하자.
로컬에 프로젝트를 둔다고 모든 AI 처리가 로컬에서 끝나는 것도 아니다. 연결한 모델 공급자와 외부 서비스의 자료 처리 정책은 별도로 검토해야 한다. Orca 자체의 텔레메트리 안내도 공급자의 설명이며, 연결된 모든 도구에 대한 독립 보안감사를 뜻하지는 않는다.
에이전트 수를 늘리기 전에 보고 형식을 고정해 둔다
반복해서 사용하는 작업이라면 역할·허용 범위·보고 형식을 스킬이나 작업 지침에 남겨두자. 읽기 중심 검토인지, 수정까지 허용하는지, 무엇을 근거로 완료라고 판단할지부터 정하면 된다.
Orca를 처음 쓸 때의 목표를 많은 창을 여는 것으로 잡을 필요는 없다. 작은 작업 하나에서 역할 배정, 보고 수신, 변경 검토까지 이어지는지를 먼저 확인해 보자. 그 흐름이 잡힌 뒤에 병렬 구현과 원격 실행을 늘려도 늦지 않다.
함께 읽을 글
참고자료
- 코드팩토리, Orca로 LLM 오케스트레이션 액기스 모음
- Orca 공식 문서와 설치 안내
- Orca, 오케스트레이션 CLI와 워커 계약
- Orca, 지원 에이전트와 권한 기본값
- Orca, 원격 서버와 SSH 방식의 차이
- OpenAI, Codex 샌드박스와 승인 정책
캡처는 원본 영상의 기능 설명·비평을 위해 인용했다. 화면의 모델명·명령·메뉴는 촬영 당시 상태이며 현재 설치 환경과 다를 수 있다. 요청 예시는 영상의 흐름을 바탕으로 재구성한 것이며, 독립 실행 실험의 결과가 아니다.
FAQ
Orca를 설치하면 Claude나 Codex도 무료로 사용할 수 있나요?
Orca는 모델 자체가 아니라 에이전트를 다루는 작업환경이다. 사용할 에이전트의 설치·인증·구독이나 API 이용 조건은 별도로 확인해야 한다. 계정 전환 기능도 이용 한도를 없애지는 않는다.
에이전트를 여러 개 쓰면 작업이 무조건 빨라지나요?
그렇지는 않다. 서로 독립적인 검토에는 병렬 작업을 활용할 수 있지만, 같은 파일을 고치거나 앞 작업의 결과를 기다려야 한다면 충돌과 대기 시간이 생길 수 있다. 먼저 작업 범위와 결과 인계 방식을 정하자.
작업트리로 나누면 권한 우회 모드를 사용해도 안전한가요?
작업트리는 파일 변경을 분리하는 기능이지 운영체제 수준의 보안 경계가 아니다. 시작 인자와 실제 권한을 확인하고, CLI별 승인 정책·샌드박스 설정을 별도로 검토해야 한다.
노트북을 꺼도 원격 작업이 계속되나요?
연결 방식과 런타임 위치에 따라 다르다. Remote Orca Server가 작업을 소유하는 방식이라면 서버의 프로세스와 네트워크가 유지되어야 한다. SSH 작업트리와 같은 방식으로 단정하지 말고, 연결을 끊은 뒤에도 작업이 남는지 자신의 환경에서 확인하자.