Cursor에서 시작한 작업을 Orca로, 외부 네트워크의 스마트폰으로 이어서 진행해 보기

선배 엔지니어에게 "여러 AI 코딩 에이전트를 사용할 거라면, Orca ADE가 편리하다"는 소개를 듣고 Orca에 대해 조사하게 되었습니다.

저는 평소 메인 개발 환경으로 Cursor를 사용하고 있습니다. Cursor는 코드를 읽고 AI와 상담하며 구현을 진행하는 환경으로서 충분히 편리합니다.

반면, Codex 등에게 여러 태스크를 동시에 요청하려고 하면 문제는 AI의 성능이 아니라 그 주변의 관리 영역으로 옮겨갑니다.

• 어떤 태스크를, 어느 브랜치에서 진행하고 있는지
• 어떤 에이전트가 실행 중이고, 어느 것이 확인 대기인지
• 생성된 차이점(diff)을 어디서 확인할지
• 여러 변경 사항을 어떻게 안전하게 통합할지

Orca는 이 관리 부분을 담당하는 ADE(Agent Development Environment)입니다.

본 기사에서는 공식 정보 확인에 더해, Cursor에서 시작한 작업을 Orca로 이어가고 외부 네트워크의 스마트폰에서 조작하는 것까지 시도했습니다.

Orca를 조사하기 전에는 AI 기능을 갖춘 새로운 IDE 중 하나라고 생각했습니다. 하지만 실제로는 Cursor와 직접적으로 경쟁한다기보다는 여러 에이전트를 구동하기 위한 '관제탑'에 가까운 도구입니다.

제가 사용하는 방식에 비추어 역할은 다음과 같이 나뉩니다.

AI에게 하나의 태스크만 요청한다면, Cursor나 터미널로 충분합니다.

하지만 두세 개를 동시에 요청하면, 사람 측에서는 태스크 분리, 진행 상황 확인, 리뷰, 통합 작업이 발생합니다. AI가 코드를 작성하는 시간을 단축시켜도, 사람이 관리에 지치면 전체 개발 속도는 올라가지 않습니다.

Orca의 기능을 개별적으로 보기보다는, 개발 흐름 속에서 '어떤 관리 작업을 줄일 수 있는가'로 생각하면 가치가 명확해집니다.

Orca에서는 태스크마다 실제 Git worktree와 브랜치를 생성합니다.

예를 들어, "검색 화면 개선"과 "API 테스트 추가"를 동시에 진행하는 경우, 각각이 다른 디렉토리에서 작업합니다. 한 에이전트의 변경 사항이 다른 작업 파일을 직접 덮어쓰지 않습니다.

통상적으로는 태스크마다 브랜치와 worktree를 준비하고, 대상 디렉토리에서 에이전트를 구동해야 합니다. Orca에서는 태스크 이름, 작업 원본, 사용할 에이전트를 지정하여 이 준비 과정을 일괄적으로 할 수 있습니다.

여기서 중요한 것은 'AI를 몇 개나 구동할 수 있는가'가 아니라, 병렬 실행하기 전에 변경 범위를 분리할 수 있다는 점입니다.

다만, 여러 브랜치가 같은 부분을 수정하면 최종 통합 시 충돌(conflict)이 발생합니다. worktree는 작업 중 덮어쓰기를 방지하는 것이며, 머지(merge) 시의 충돌까지 자동으로 없애주는 것은 아닙니다.

여러 터미널을 열어두면, '어떤 처리가 끝났는지'를 확인하기 위해 화면을 돌아다니기 쉽습니다.

Orca에서는 태스크 이름을 붙인 세션과 에이전트의 상태를 사이드바에서 확인할 수 있습니다.

검색 화면 개선

: 실행 중 -
API 테스트 추가

: 확인 대기 -
차이점 리뷰

: 완료

이렇게 배열해 놓으면, 사이드바 자체가 AI에게 요청한 태스크 목록이 됩니다. 기다리는 동안 다른 작업으로 옮겨가다가, 확인이 필요할 때 돌아오는 흐름을 만들 수 있습니다.

또한, Orca는 에이전트의 프로세스와 화면을 분리하여 관리합니다. 앱을 닫은 후에도 프로세스를 지속하고, 재시작 후에 세션으로 돌아갈 수 있어 장시간 처리를 화면에 붙어 지켜볼 필요가 없습니다.

AI로부터 완료 보고를 받았다고 해도, 그 변경 사항을 그대로 가져올 수 있는 것은 아닙니다. 구현 후에는 차이점 확인, 추가 수정, 테스트, 커밋(commit)이 필요합니다.

Orca에서는 worktree마다 다음 작업을 수행할 수 있습니다.

• 변경 차이점 확인
• 차이점에 대한 코멘트
• 코멘트를 기반으로 한 에이전트에게의 수정 요청
• 스테이징 및 커밋
• Issue나 Pull Request와의 연관성 부여

대상 코드를 채팅창에 다시 붙여넣고, "이 파일의 이 부분"이라고 설명하는 왕복 작업을 줄일 수 있다는 점이 실용적입니다.

프론트엔드의 경우, 내장 브라우저에서 구현을 확인할 수 있습니다. 화면상의 요소나 위치를 지정하여 수정을 요청할 수 있으므로, DOM 구조를 문장으로 설명하는 것보다 구체적인 피드백을 전달할 수 있습니다.

Orca의 가치는 코드 생성 속도 자체보다, 생성된 코드를 확인하고 다음 지시를 내리기까지의 거리를 좁히는 것에 있다고 생각합니다.

이번에 시도한 것은 Cursor의 Agent Window에서 진행하던 작업을 Orca로 옮겨서 그대로 이어가는 흐름입니다.

먼저, 평소대로 Cursor의 Agent Window에서 작업을 진행했습니다. 중간 브랜치에는 커밋된 변경 사항 외에도 미커밋(uncommitted) 변경 파일이 남아있는 상태였습니다.

다음으로 Orca에서 동일한 리포지토리와 브랜치를 열었습니다. Cursor 측에서 만든 변경 파일이나 Git 상태를 Orca에서 확인할 수 있었고, 그대로 작업을 계속할 수 있었습니다.

여기서 말하는 것은 'Cursor의 세션을 통째로 이전했다'는 의미는 아닙니다. 변경 파일과 리포지토리 상태는 인계되었지만, Cursor에서의 대화 기록이 Orca로 자동으로 넘어오는 것은 아니었습니다.

따라서 Orca 측에서는 다음 내용을 수동으로 다시 전달해야 했습니다.

• 어떤 목적의 작업이었는지
• 어느 정도까지 완료했는지
• 미커밋 변경 사항은 무엇인지
• 다음에 실행해 주었으면 하는 것

코드 상태는 인계할 수 있어도, 작업 의도까지 자동으로 인계되지는 않습니다. 이 차이점을 이해한 후, 작업 상황을 간결하게 정리하여 전달해야 합니다. 그럼에도 불구하고, 중간 변경 사항을 다시 만들지 않고 Orca로 옮길 수 있었기 때문에, 개발 환경을 전환하는 부담은 예상했던 것보다 작게 느껴졌습니다.

Orca에는 iOS 및 Android용 모바일 컴패니언(companion)이 있습니다. 이번에는 PC와는 다른 네트워크에서 연결하여 스마트폰으로 Orca 세션을 확인했습니다.

스마트폰에는 PC 측에서 열려 있던 프로젝트와 세션 목록이 표시되었습니다.

외부 네트워크에서 표시된 세션 목록입니다. 기기 이름, 프로젝트 이름, 브랜치 이름은 익명화 처리했습니다.

목록에서 대상 세션을 열면 실행 상황을 확인하고 추가 지시를 입력할 수 있었습니다.

이번 확인을 통해, 외출한 곳에서 진행 상황을 보고 짧은 추가 지시를 보내는 사용 방식이 현실적이라는 것을 알게 되었습니다. 세밀한 차분 리뷰(diff review)나 긴 지시문을 작성하는 것은 PC가 조작하기 더 편리하지만, 처리 완료를 기다리기 위해 계속 PC 앞에 있을 필요는 없습니다.

이번에는 Orca Relay를 사용했습니다. 하지만 모바일 앱만으로 에이전트가 작동하는 것은 아닙니다. 연결된 PC에서 Orca를 실행하고 절전(sleep)되지 않도록 유지해야 합니다.

Orca에는 주기적 태스크 자동화나, 스마트폰에서 세션을 확인할 수 있는 모바일 컴패니언도 있습니다.

유용한 기능이지만, 처음부터 모든 것을 사용하는 것보다 다음 순서로 도입하는 것이 효과를 판단하기에 더 쉬워 보입니다.

새로운 worktree에는 node_modules, 캐시, .env 등 Git으로 관리하지 않는 파일이 처음부터 갖춰져 있지는 않습니다.

Orca에는 공유 경로(shared path)나 .worktreeinclude 같은 메커니즘이 있지만, 무엇을 공유하고 무엇을 분리할지는 프로젝트마다 결정해야 합니다.

두 개의 에이전트를 구동하면, 확인할 차분도 두 개가 생깁니다. 태스크를 세밀하게 나누고 변경 범위와 완료 조건을 명확히 하지 않으면, 리뷰 부담 자체가 새로운 병목 지점(bottleneck)이 될 수 있습니다.

작은 수정 사항을 하나씩 요청하는 사용 방식이라면, Cursor나 일반 터미널만으로 충분할 때가 많습니다. Orca의 강점은 여러 작업을 동시에 진행하고, 그 상태와 결과물을 관리할 때 나타납니다.

Orca를 조사하면서 알게 된 것은, AI 코딩의 과제가 '어떻게 시키느냐'에서 '여러 업무를 어떻게 안전하게 처리하느냐'로 변화하고 있다는 것입니다.

저에게 Orca는 Cursor의 대체재가 아닙니다.

• Cursor로 코드를 이해하고 최종 판단을 내린다
• Codex에 독립적인 태스크를 요청한다
• Orca에서 작업 장소, 진행 상황, 차분을 관리한다

실제로 시도해 본 범위에서는, Cursor로 시작한 변경 사항을 Orca에서 확인하고, 작업 상황을 다시 전달하여 지속할 수 있었습니다. 게다가 PC와는 다른 네트워크의 스마트폰에서 세션을 열고 추가 지시까지 보낼 수 있었습니다.

반면, 대화 기록까지 자동으로 넘어오는 것은 아닙니다. 툴(tool)을 넘나들 때는 목적, 진행 정도, 남은 작업을 간결하게 정리하여 전달해야 합니다.

다음은 여러 worktree에서 Codex를 병렬 실행했을 경우의 준비 시간과, 생성된 차이점(diff)을 검토하는 데 걸리는 시간을 확인합니다.