안녕하세요, 엔도(@shoma_ai)입니다. 평소에는 중소기업을 대상으로 한 AI 도입 지원 및 시스템 개발을 하고 있습니다.

Orca / Tailscale이란

먼저, 이 기사에 등장하는 두 가지 도구에 대한 설명부터 시작하겠습니다.

두 도구 모두 알고 계신 분은 「세션을 그대로 이어가고 싶다」 부분으로 건너뛰어 주세요.

Orca

Orca는 AI 코딩 에이전트(AI coding agent)를 구동하기 위한 데스크톱 앱입니다. 터미널, 에디터, 에이전트와의 채팅이 하나의 화면에 모여 있어, Claude Code와 같은 CLI 에이전트를 여러 세션으로 나란히 배치하여 관리할 수 있습니다. 에디터라기보다는 「에이전트에게 일을 시키고, 진행 상황을 확인하며, 지시를 내리는 작업대」에 가깝습니다.

실제 데스크톱 버전 Orca의 화면.
왼쪽에는 터미널과 브라우저, 중앙에는 에디터와 에이전트의 세션,
오른쪽에는 파일 트리(프로젝트명은 모자이크 처리)

이 Orca에는 「Orca Mobile」이라는 스마트폰 앱이 있습니다. 데스크톱 버전이 표시하는 QR 코드를 스캔하여 페어링하면, PC에서 구동 중인 세션(터미널·에디터·에이전트와의 상호작용)에 스마트폰에서 그대로 접속할 수 있습니다.

단, 순수 구성 상태에서는 스마트폰과 PC가 동일한 LAN에 연결되어 있어야 합니다. 집의 Wi-Fi 환경 내에서는 문제없이 연결되지만, 외출하여 셀룰러 회선으로 전환되는 순간 연결이 끊깁니다.

Tailscale

Tailscale은 자신의 단말기끼리 가상적인 전용 네트워크(tailnet이라고 부릅니다)로 연결하는 서비스입니다. PC와 스마트폰 양쪽에 앱을 설치하고 동일한 계정으로 로그인하면, 각 단말기에 100.x.x.x 형태의 프라이빗 IP 주소가 할당되어, 외출 중인 셀룰러 회선에서도 마치 동일한 LAN에 있는 것처럼 집의 PC로 통신할 수 있습니다.

내부는 WireGuard라는 VPN 프로토콜을 사용하며, 통신은 단말기 간에 암호화되고 기본적으로는 서버를 중계하지 않고 단말기끼리 직접 연결됩니다. 개인 이용 시에는 무료입니다. 이 기사에서는 위의 「동일 LAN 제약」을 이 tailnet을 통해 극복합니다.

평소 작업은 거의 Orca 상에서 완결되므로, 외출 중에 PC를 들여다볼 수 없는 것은 꽤 곤란한 상황이 있었습니다. 특히 AI 에이전트에게 조사나 구현을 맡기고 외출했을 때, 진행 상황을 보고 싶거나 추가 지시를 내리고 싶은 상황입니다.

세션을 그대로 이어가고 싶다

제가 하고 싶었던 것은 단순한 「외부에서 PC를 들여다보는 것」이 아니라, 평소 PC에서 하던 세션을 그대로 이어받아 진행하는 것이었습니다. 다른 장소에서 작업을 다시 시작하는 것이 아니라, 진행 중인 에이전트와의 상호작용에 그대로 합류하는 것. 이 부분이 연결되지 않으면 외출하는 시점에서 작업이 한 번 끊겨 버립니다.

오진(1) docs를 맹신하여 「구조적으로 불가능」하다고 결론지음

처음에 Orca의 공식 docs를 읽었습니다. 페어링 설명 부분에 다음과 같이 적혀 있었습니다.

Closing the desktop app drops the connection — there is no cloud relay.

이를 보고 「클라우드 릴레이(cloud relay)가 없다 = LAN 외부에서의 접속은 구조적으로 불가능하다」라고 결론지었으나, 이는 잘못된 판단이었습니다.

실제로 Orca 앱 본체를 열어 내부 설정값을 확인해 보니, 다음과 같은 주석이 남아 있었습니다. app.asar 본체가 아니라, 그 옆의 app.asar.unpacked/out/shared/constants.js에 있습니다.

// Why: Anywhere (Relay + local) is the default; local-only is written only on explicit same-network choice.
mobilePairingConnectionMode: 'automatic',

기본값은 「Anywhere (Relay + local)」이며, local-only는 동일 네트워크를 명시적으로 선택했을 때만 작성됩니다. docs의 한 문장에서 읽어낸 「LAN 외부는 불가능하다」는 전제는 실제와 달랐습니다. docs가 거짓말을 한 것이 아니라, 릴레이가 없는 것과 LAN 외부에서 연결되지 않는 것은 별개의 문제였을 뿐입니다.

오진(2) 「Mac이 자동으로 슬립 모드에 들어간 것이 아닌가」

다음으로 의심한 것은, Mac 측이 자동으로 슬립 모드(sleep mode)에 들어가서 접속할 수 없었던 것이 아닌가 하는 가설이었습니다. 노트북을 덮고 외출하는 운용 방식이기에 가장 먼저 떠오르는 의구심입니다.

pmset -g log

그리고 슬립 (Sleep) 이력을 살펴보니, 기록되어 있는 것은 Clamshell Sleep (덮개를 닫음으로써 발생하는 슬립)와, 몇 분에서 십수 분 내에 복귀하는 Maintenance Sleep뿐이었습니다. 로그는 다음과 같은 형식으로 남아 있습니다.

2026-07-24 19:10:14 +0900 Sleep Entering Sleep state due to 'Clamshell Sleep':TCPKeepAlive=active Using Batt (Charge:98%) 2943 secs
2026-07-24 22:45:06 +0900 Sleep Entering Sleep state due to 'Clamshell Sleep':TCPKeepAlive=active Using Batt (Charge:66%) 312 secs

행 끝의 secs가 해당 슬립이 지속된 시간입니다. 수중에 있는 로그를 집계해 보니 가장 길어도 Maintenance Sleep인 79분이었으며, 연결되지 않았던 시간대를 통째로 설명할 수 있을 만한 장시간의 시스템 슬립은 없었습니다.

이 가설도 틀렸습니다. 화면이 어두워져 있었던 것은 displaysleep (디스플레이만 끄는 설정)이었으며, 시스템 전체의 슬립과는 별개의 것이었습니다. "화면이 어둡다 = 잠들어 있다"라고 해석하면 오진하게 됩니다. 이 부분은 저 자신도 구분(isolation)이 미흡했던 점입니다.

덮개를 닫아도 구동을 유지할 수 있는 Capsomnia

외출 중에도 본체를 깨워둔 상태로 유지하려면, 덮개를 닫아도 슬립하지 않도록 하는 설정이 필요합니다. 제가 사용하고 있는 것은 Capsomnia라는 도구로, Caps Lock 키에 pmset -a disablesleep 1을 할당하여 누르는 것만으로 슬립 무효화를 전환할 수 있습니다.

확인은 다음 명령어로 합니다.

pmset -g | grep SleepDisabled

Caps Lock으로 슬립 무효화를 ON으로 설정하면, 이 부분이 1이 됩니다.

해결책: Tailscale

앞서 언급한 mobilePairingConnectionMode: 'automatic'에서 알 수 있듯이, Orca는 애초에 동일 LAN 이외에서의 접속을 상정하고 만들어졌습니다. 다만 "멋대로 릴레이(Relay)에 연결되는" 동작은 피하고, 자신의 네트워크 안에서만 완결시키고 싶었습니다. 여기서 서두에 언급했던 Tailscale이 등장합니다.

사실 Orca의 설정에도 정확히 그를 위한 항목이 있었습니다.

설정 → 모바일의 "연결 방법"을 열면, "LAN" 설명에 **"스마트폰이 이 Wi-Fi 또는 Tailscale에 연결되어 있어야 합니다"**라고 Tailscale의 이름이 처음부터 적혀 있습니다. 편법이나 회피책이 아니라, 공식적으로 준비된 접속 경로였습니다.

연결 방법 선택 화면. "이 컴퓨터의 주소"에서 tailnet의 IP(모자이크 처리된 부분)를 선택하고, "QR 코드 생성"을 눌러 재페어링(re-pairing)한다.

참고로 현재 버전에서는 이 선택지 옆에 "Orca Relay" (베타, 로그인 필요)라는 클라우드 릴레이도 추가되어 있습니다. docs의 "there is no cloud relay"는 과거의 이야기가 되어가고 있지만, 로그인 없이 자신의 네트워크 내에서만 완결되는 것은 LAN + Tailscale 측입니다.

절차

• PC와 스마트폰 모두를 동일한 tailnet에 참여시킨다
• Orca 설정 → 모바일의 "이 컴퓨터의 주소"에서 Tailscale의 100.x 주소를 선택한다
• QR 코드를 재발행한다
• Orca Mobile 앱에서 재발행한 QR을 스캔한다

결과: 릴레이를 사용하지 않고 tailnet 직결

재페어링 후에는 tailnet 주소를 경유하여 외출지에서도 연결되게 되었습니다. 정말로 릴레이를 거치지 않았는지는 PC 측에서 소켓(socket)을 확인하면 알 수 있습니다.

$ netstat -an | grep 6768
tcp4 0 0 100.120.x.x.6768 100.126.x.x.49657 ESTABLISHED

6768이 Orca의 대기(listening) 포트이며, 연결된 상대는 iPhone의 tailnet IP입니다. 어딘가의 릴레이 서버 주소가 아니라, 단말기끼리 직접 연결되어 있습니다. Orca 측의 설정 파일(~/Library/Application Support/Orca/profiles/local-default/orca-data.json

）에도 릴레이(relay)에 대한 속박을 나타내는 relayBinding과 같은 키는 적혀 있지 않습니다.

참고로 mobilePairingConnectionMode는 나중에 다시 확인했을 때 기본값인 automatic 상태였습니다. 동일 네트워크를 명시적으로 선택했을 때만 local-only가 적힌다는 앞서 언급한 설명대로 동작하므로, tailnet 운영 시에는 이 부분을 건드릴 필요가 없습니다.

주의해야 할 점 3가지

Tailscale을 경유한 연결로 전환한 후, 실제로 겪었던 함정이 3가지 있었습니다.

① iPhone 측의 Tailscale을 OFF로 하면 집 Wi-Fi 환경에서도 연결되지 않음

QR 코드가 광고하는 주소가 tailnet의 IP로 되어 있기 때문에, iPhone 측의 Tailscale이 OFF 상태라면 같은 Wi-Fi 안에 있더라도 접속할 수 없습니다. Tailscale은 항상 ON 상태로 운영하는 것을 전제로 합니다.

② 키(Key)의 유효 기간 만료로 예고 없이 연결이 끊김

Tailscale의 키는 기본적으로 약 180일 후에 만료됩니다. 방치해 두면 어느 날 갑자기 연결이 되지 않는 사고가 발생합니다. 관리 콘솔에서 「Disable key expiry」를 설정해 두어야 합니다.

확인은 tailscale status --json을 실행하여 Self의 키 목록을 보는 방법이 있습니다. 유효 기간이 남아 있는 단말기에서는 KeyExpiry라는 키에 만료 예정 일시가 들어가지만, 무효화한 단말기에서는 이 키 자체가 사라집니다. 제 단말기에서 실제로 확인을 마쳤습니다.

③ brew의 cask 설치가 TTY 에러로 중단됨

brew install --cask tailscale을 실행하면, pkg 설치 프로그램이 sudo 권한을 요구하는 단계에서 TTY 에러가 발생하며 멈췄습니다. brew의 cask는 대화형(interactive) 설치 프로그램을 상정하지 않기 때문입니다. 다운로드된 pkg 파일을 open 명령어로 GUI 설치 프로그램으로서 실행하면 해결됩니다.

open "$(brew --cache --cask tailscale)"

추가: 1대 구성에는 허점이 있었다

여기까지로 「외부에서 내 PC에 연결되는」 상태가 되었습니다.

하지만 잠시 사용해 보니 발견된 허점이 있습니다.

연결 대상이 PC 그 자체이므로, 그 PC를 가지고 나가면 연결 대상 자체가 사라집니다.

외출 중 카페 Wi-Fi에 연결된 노트북에, 마찬가지로 외출 중인 iPhone으로 연결하는 것은 의미가 거의 없습니다. 이 구성이 효과를 발휘하는 것은 「PC는 집에 두고 몸만 나갈 때」뿐입니다.

그런데 제 경우에는 PC를 가지고 나가는 날도 있습니다.

그래서 사용하지 않던 두 번째 Mac을 상시 가동되는 거치형 허브(hub)로 만들고, 그것도 tailnet과 Orca에 추가했습니다. 공식 docs에는 다음과 같이 적혀 있습니다.

Mobile lists worktrees from every host you're connected to (local desktops and remote Orca servers) in a single view, so switching between them doesn't need a device change.

적혀 있는 대로, 모바일 측에는 가지고 나가는 본체(아래 스크린샷의 「메인」)와 거치형(「서브」)이 한 화면에 나열되며, 둘 다 Connected · Direct · Tailscale로 표시됩니다. iPhone의 Wi-Fi를 끄고 셀룰러만 사용하더라도 거치형 측은 Connected 상태를 유지했습니다. 가지고 나간 본체가 통신 불능 지역에 있더라도, 집에 있는 한 대가 살아 있다면 작업을 계속할 수 있습니다.

Orca Mobile의 홈 화면 (Wi-Fi 연결 시 촬영). 두 대의 Mac이 한 화면에 나열되어 있으며, 둘 다 「Connected · Direct · Tailscale」로 표시됨. 여기서 각 호스트의 worktree로 들어갈 수 있음

거치형 측에 「무엇을 둘 것인가」를 간과했다

처음에는 거치형 측에 리포지토리(repository)를 하나만 두었습니다. 호스트로서 연결되는 것만으로 만족하고 있었지만, 접근할 수 있는 것은 해당 기기에 있는 것뿐입니다. 본체를 가지고 나가는 순간, 나머지 전부에는 손을 댈 수 없습니다.

허브로서 의미를 갖게 하려면, 밖에서 만질 만한 것들을 미리 가져다 놓아야 했습니다. 최근에 작업하던 7개의 리포지토리를 git clone 하여 ~/dev 전체 용량은 163MB였습니다. node_modules

를 포함하지 않으므로, 배치하는 비용이 선택하는 비용보다 저렴하다는 판단입니다.

이 clone 과정에서 한 가지 난관이 있었습니다. remote가 https 형식인 리포지토리는 SSH를 통한 비대화형 셸(non-interactive shell)에서 clone할 수 없습니다. 인증 정보를 Keychain에서 가져오지 못해 멈추기 때문입니다.

$ git clone https://github.com/<owner>/<repo>.git /tmp/test
Cloning into '/tmp/test'...
failed to get: -25308
...

SSH 형식의 URL로 다시 clone하면 통과됩니다. 개인 PC에서 평소 사용할 때는 https 상태로도 문제가 없었기에, 옮기는 단계에 이르러서야 처음으로 깨달았습니다.

허브를 계속 유지하기 위한 조건

데스크톱에 고정해 두면, "꺼진 상태로 방치되어 알아차리지 못하는 것"이 새로운 실패 모드가 됩니다.

정리해 보니 다음과 같았습니다.

첫 번째 줄의 LaunchAgent 내용은 이것뿐입니다. StartInterval에 300을 넣어 5분마다 실행하고 있습니다.

pgrep -f '/Applications/Orca.app/Contents/MacOS/Orca' >/dev/null 2>&1 \\
|| /usr/bin/open -a /Applications/Orca.app

복구시키는 메커니즘과는 별개로, 꺼졌다는 사실을 알아차리는 메커니즘도 필요합니다.

이것은 휴대하는 쪽에서 15분마다 tailnet의 도달 가능성과 포트 6768의 응답을 확인하여, 응답이 없으면 채팅으로 알림을 보냅니다. 복구와 감지를 동일한 기기에 맡기면, 그 기기 자체가 꺼졌을 때 둘 다 멈추기 때문입니다.

마지막 줄만은 자동화할 수 없습니다. FileVault를 끄면 자동 로그인으로 무인 복구가 가능하지만, 상시 가동하며 tailnet에 노출되어 있고 SSH도 열려 있는 기기의 암호화를 해제하는 결정이 됩니다. 여기서는 암호화를 해제하지 않고, 위의 알림을 통해 인지한 뒤 귀가하여 수정하는 것으로 타협했습니다.

brew install --cask orca로는 설치되지 않음

덤으로 주의할 함정: 두 번째 기기에 Orca를 설치할 때, 순순히 brew install --cask orca를 입력하면 다른 소프트웨어가 설치됩니다. 이 cask 이름은 Plotly의 차트 이미지 생성 도구(plotly/orca)에 할당되어 있어, 에디터인 Orca와는 무관합니다. 공식 사이트에서 설치해야 합니다.

요약

Orca Mobile의 "동일 LAN 제한"은 공식 docs의 기술만 보면 회피 불가능해 보이지만, 구현 코멘트와 Orca 자체의 Mobile 설정을 살펴보면 Tailscale을 통한 연결은 처음부터 마련된 경로였습니다.

돌아온 부분은 두 곳입니다. docs의 한 문장을 읽고 "구조적으로 불가능"하다고 단정한 점과, 화면이 어두운 것을 보고 슬립을 의심했던 점입니다.

둘 다 직접 확인할 수 있는 것(구현된 상수 파일, pmset -g log의 실제 출력)을 보기 전에 결론을 내렸었습니다.

연결이 가능해진 이후에 중요해진 것은, 경로의 문제보다 배치 장소의 문제였습니다.

연결 대상은 PC 그 자체이므로, "어떤 PC를 휴대하고 어떤 PC를 남겨둘 것인가"와 "남겨두는 쪽에 무엇을 넣어둘 것인가"에 따라 사용 편의성이 결정됩니다.

Discussion