AI 코딩 에이전트에게 작업을 맡기는 방식의 좋은 점은 사람이 자리를 지킬 필요가 없다는 것입니다. 그런데 실제로 자리를 비우면 곧바로 다음 문제가 생깁니다. 에이전트가 질문을 던진 채 멈춰 있으면, 돌아올 때까지 작업 전체가 서 있게 됩니다. 결국 노트북 앞을 떠나지 못하는 역설이 생깁니다.
Orca는 이 문제를 모바일 컴패니언 앱으로 풀어 온 ADE(Agent Development Environment, 에이전트 개발 환경)입니다. 다만 지금까지의 모바일 앱에는 두 가지 벽이 있었습니다. 데스크톱과 같은 네트워크에 있어야 연결되고, 폰 화면에서 터미널을 그대로 미러링해서 봐야 했다는 점입니다. 2026년 7월 기준 이 두 가지가 모두 허물어지고 있습니다. 다른 네트워크에서도 연결되는 Relay와, 터미널 대신 네이티브 채팅으로 에이전트와 대화하는 Chat UI가 도입되면서입니다.
이 글에서는 두 기능이 각각 무엇을 해결하는지, 그리고 합쳐졌을 때 모바일 에이전트 운영이 실제로 어떻게 달라지는지 살펴봅니다. Orca 자체가 처음이라면 지난 글 「Orca란? 여러 AI 코딩 에이전트를 한곳에서 운영하는 ADE」를 먼저 읽어 보시길 권합니다.
모바일 컴패니언은 원래 무엇을 해 줬나요?
Orca 모바일 앱(iOS·Android)은 데스크톱 Orca와 페어링해서 쓰는 리모컨형 앱입니다. 실행 중인 worktree와 에이전트 상태를 목록으로 보고, 에이전트가 작업을 마치거나 입력을 기다리면 푸시 알림을 받고, 터미널 내용을 확인한 뒤 후속 프롬프트를 보낼 수 있습니다. 파일 트리 탐색, diff 확인과 커밋, 사진 첨부, 음성 입력까지 지원하니 “확인하고 지시하는” 용도로는 이미 쓸 만했습니다.
문제는 연결 방식이었습니다. 페어링이 로컬 네트워크 기반이라 데스크톱과 폰이 같은 Wi-Fi에 있거나, Tailscale 같은 VPN(Virtual Private Network, 가상 사설망)으로 같은 네트워크처럼 묶여 있어야 했습니다. 집 안 소파에서는 잘 되지만 정작 모바일 앱이 가장 필요한 순간인 “밖에 나갔을 때”는 VPN을 직접 구성하지 않는 한 연결할 방법이 없었습니다.
Relay: 다른 네트워크에서도 데스크톱과 이어집니다
Relay는 이 연결 문제를 푸는 기능입니다. 폰과 데스크톱이 서로 다른 네트워크에 있을 때, Orca 개발사 Stably AI가 운영하는 중계 서버를 거쳐 연결을 이어 줍니다. 카페의 Wi-Fi든 이동 중의 LTE든, 데스크톱이 켜져 있고 인터넷에 연결되어 있으면 폰에서 세션에 접속할 수 있습니다.
구조를 그려 보면 이렇습니다.
설계에서 눈여겨볼 부분이 세 가지 있습니다.
첫째, 기존 로컬 페어링이 기본 경로로 유지됩니다. 같은 네트워크에 있으면 이전처럼 계정 없이 직접 연결하고, Relay는 직접 연결이 불가능할 때를 위한 추가 경로입니다. Relay를 쓰려면 데스크톱 쪽에서 Orca 계정으로 로그인해야 하지만, 폰은 로그인하지 않습니다. 중계 자체는 무료입니다.
둘째, 종단 간 암호화(E2EE, End-to-End Encryption)를 전제로 설계됐습니다. 폰과 데스크톱이 암호화 키를 서로 확인한 뒤 통신하므로, 중간의 중계 서버는 트래픽을 전달할 뿐 터미널 내용이나 코드를 들여다볼 수 없는 구조입니다. 도입 PR의 보안 감사 항목에 페어링 검증, 재전송 공격 방지, 토큰 범위 제한 같은 내용이 상세히 기록되어 있어, 원격 연결 기능을 회사 코드에 써도 되는지 검토할 때 참고할 수 있습니다.
셋째, 연결을 시작하는 쪽이 데스크톱입니다. 데스크톱이 중계 서버로 바깥 방향 연결을 먼저 열어 두는 방식이라, 공유기 뒤에 있는 집 데스크톱에 포트포워딩이나 방화벽 설정을 할 필요가 없습니다. 로컬 머신뿐 아니라 WSL(Windows Subsystem for Linux)이나 SSH로 붙인 원격 worktree 환경에서도 같은 방식으로 동작합니다.
Chat UI: 터미널을 폰에 욱여넣지 않습니다
연결이 됐다면 다음 문제는 화면입니다. 기존 모바일 앱은 데스크톱 터미널 화면을 폰에 그대로 미러링했습니다. 어떤 화면이었는지 보면 이해가 빠릅니다.
읽을 수는 있습니다. 하지만 TUI(Text-based User Interface, 터미널 텍스트 기반 인터페이스)는 애초에 넓은 모니터와 키보드를 전제로 설계된 화면입니다. 폰에서는 글씨가 작고 긴 출력을 스크롤로 따라가야 하고, 에이전트가 던진 선택지에 답하려면 화살표 키를 흉내 낸 버튼을 눌러야 합니다. 잠깐 상태를 확인하는 데는 충분해도 “폰에서 에이전트와 일한다”고 부르기는 어려운 경험이었습니다.
Chat UI는 이 지점을 다시 설계했습니다. 터미널 화면을 픽셀 단위로 옮기는 대신, 에이전트가 남기는 대화 기록(transcript)을 읽어 메신저처럼 네이티브 채팅 화면으로 다시 그려 줍니다. 베타 초기에는 native chat이라는 이름이었다가 지금의 Chat UI로 정리됐습니다. 달라지는 부분은 이렇습니다.
- 에이전트의 답변이 채팅 말풍선으로 스트리밍되고, 도구 호출·실행 로그 같은 중간 과정은 접힌 상태로 정리됩니다.
- 에이전트가 선택지를 물으면(예: Claude Code의 AskUserQuestion) 터미널 메뉴 대신 탭으로 넘기며 답하는 카드가 뜹니다. 권한 승인 요청도 카드로 표시됩니다.
- 입력창에서 메시지를 보내면 데스크톱의 에이전트 터미널에 그대로 전달됩니다. 이미지를 첨부하거나 모델과 추론 강도를 바꾸는 것도 채팅 화면 안에서 가능합니다. 스킬을 골라 실행하는 피커는 데스크톱 Chat UI에 먼저 들어왔고, 모바일 반입이 진행 중입니다.
- 탭 하나로 원래 터미널 화면과 채팅 화면을 오갈 수 있어, 세부 로그를 봐야 할 때는 언제든 터미널로 돌아갈 수 있습니다.
재미있는 점은 Chat UI가 모바일 전용이 아니라는 것입니다. 같은 채팅 화면이 데스크톱과 웹 클라이언트에도 함께 들어와서, 어디서 보든 에이전트와의 대화가 같은 모습으로 이어집니다. Claude Code와 Codex처럼 대화 기록 형식이 파악된 에이전트부터 지원하며 현재 TestFlight와 Android APK 채널에서 베타로 쓸 수 있습니다.
두 기능을 합치면 워크플로가 이렇게 바뀝니다
Relay와 Chat UI는 따로 보면 각각 “연결 개선”과 “화면 개선”이지만, 합치면 하나의 이야기가 됩니다. 퇴근길 시나리오로 그려 보겠습니다.
- 퇴근 전, 리팩터링 두 건과 버그 수정 한 건을 각각의 worktree에서 에이전트에게 맡겨 둡니다.
- 지하철에서 푸시 알림이 옵니다. 버그 수정 에이전트가 “테스트를 수정해도 되는지” 묻고 멈춰 있습니다.
- 폰을 열면 Relay가 데스크톱 세션에 연결하고, Chat UI에 질문 카드가 떠 있습니다. 선택지를 눌러 답하면 에이전트가 다시 움직입니다.
- 도착 전에 리팩터링 하나가 끝났다는 알림이 옵니다. diff를 훑어보고, 마음에 걸리는 부분에 후속 프롬프트를 보냅니다.
- 집에 도착하면 세 작업 모두 검토 가능한 상태가 되어 있고, 데스크톱에서 최종 리뷰와 커밋만 하면 됩니다.
에이전트가 멈춰서 기다리는 시간이 “사람이 자리로 돌아올 때까지”에서 “사람이 폰을 꺼낼 때까지”로 줄어드는 것, 이것이 두 기능이 함께 만드는 변화입니다.
써보기 전에 알아두면 좋은 것들
- 모바일 앱은 여전히 컴패니언입니다. 세션은 데스크톱(또는 데스크톱이 관리하는 원격 머신)에서 돌아가므로, 데스크톱 앱이 꺼지면 연결도 끊깁니다. 폰 단독으로 에이전트를 돌리는 클라우드 서비스가 아닙니다.
- Relay는 데스크톱 로그인이 필요합니다. 계정 없이 쓰고 싶다면 기존처럼 같은 네트워크에서 직접 페어링하거나 Tailscale 같은 VPN을 직접 구성하는 방법이 그대로 남아 있습니다.
- 두 기능 모두 단계적 롤아웃 중입니다. Chat UI는 TestFlight(iOS)·APK(Android) 채널에 먼저 들어오는 베타이고 Relay도 최근 릴리스에 순차 반영되는 단계라 공식 모바일 문서에는 아직 로컬 페어링 기준 설명이 남아 있습니다. 릴리스 노트를 보면 메시지 전달 상태 표시나 대화 순서 정렬, Relay 재연결 같은 부분을 활발히 다듬는 중이라, 세부 동작은 버전에 따라 달라질 수 있습니다.
- 에이전트 호환은 확인이 필요합니다. Chat UI는 에이전트의 대화 기록을 해석해서 그리는 방식이라, 터미널 미러링과 달리 에이전트별 지원 수준에 차이가 있을 수 있습니다.
마무리
Orca의 모바일 앱은 그동안 “있으면 편한 보조 화면”에 가까웠습니다. Relay가 장소의 제약을 걷어내고 Chat UI가 화면의 제약을 걷어내면서, 이제는 “에이전트 운영의 절반을 폰으로 옮길 수 있는 도구”에 가까워졌습니다. 여러 에이전트를 병렬로 돌리는 작업 방식일수록 사람의 응답 지연이 전체 처리량을 좌우하는데 그 지연을 줄이는 가장 현실적인 방법이 주머니 속 폰이라는 점에서 방향이 잘 잡힌 업데이트라고 봅니다.
병렬 에이전트 운영 자체가 궁금하다면 지난 글 「Orca란? 여러 AI 코딩 에이전트를 한곳에서 운영하는 ADE」와 「AI 에이전트 병렬 터미널 6종 비교」도 함께 읽어 보세요.