클라우드 Mac에서 원격 개발 워크플로 구축하기: VS Code Remote-SSH와 JetBrains Gateway 튜닝

새벽 두 시, 집에서 노트북으로 대여한 클라우드 Mac mini에 접속해 낮에 끝내지 못한 빌드를 이어가려 한다. VS Code에 "원격 확장 설치 중"이라는 진행률 표시줄이 뜨고, 무려 40초간 계속 돌아간다—확장 프로그램 목록은 어제와 완전히 똑같은데도 또다시 설치되고 있는 것이다. 이런 "매번 처음 만나는 것 같은" 경험은 많은 사람이 에디터를 처음 클라우드 Mac으로 옮길 때 밟는 첫 번째 함정이며, 그 뒤로는 네트워크 흔들림으로 인한 세션 끊김, 그래픽 디버깅이 안 되는 문제 등이 기다리고 있다. 이 글에서는 이런 문제들을 한 번에 정리한다.

에디터를 클라우드 Mac으로 옮기는 이유, 로컬 개발로는 안 되는가

가끔 로그인해서 xcodebuild를 한 번 돌리는 정도라면 SSH로 바로 들어가 명령어를 치는 것으로 충분하다. 하지만 클라우드 Mac mini에서 장기적으로 코드를 작성하고, 디버깅하고, 테스트를 돌린다면, 맨 터미널 + vim만으로는 로컬 IDE의 경험보다 효율이 명확히 떨어진다—시맨틱 점프도 없고, 브레이크포인트 디버깅도 없고, 클립보드 동기화도 별도 설정이 필요하다. 더 합리적인 방법은 Mac mini가 연산과 컴파일만 담당하게 하고, 에디터 화면은 로컬에 남긴 채 원격 프로토콜로 둘을 연결하는 것이다. 이것이 바로 '클라우드 Mac'이라는 서비스의 진정한 사용법이기도 하다. 이 머신은 독점적으로 쓸 수 있는 물리 리소스이며, 데이터센터에 놓여 있는 자신의 컴퓨터로 다뤄야 할 대상이지, 한 번 쓰고 버리는 임시 컨테이너가 아니다.

VS Code Remote-SSH로 클라우드 Mac 연결하기

VS Code Remote-SSH의 원리는 간단하다. 로컬에서는 가벼운 클라이언트만 실행되고, 실제 언어 서버, 터미널, 파일 시스템은 모두 원격 Mac에 있다. 처음 연결할 때 vscode-server 바이너리와 확장 호스트가 원격의 ~/.vscode-server 디렉터리에 설치되고, 이후 연결은 이 환경을 재사용한다.

SSH 설정과 연결 다중화

기본적으로는 연결할 때마다 매번 완전한 TCP + SSH 핸드셰이크를 새로 수행해야 하는데, 태평양을 건너 아시아태평양이나 미국 서부 노드에 접속할 경우 이 지연이 바로 "파일을 열 때 잠깐 기다려야 하는" 형태로 나타난다. ControlMaster로 연결을 다중화하면 핸드셰이크 오버헤드의 대부분을 줄일 수 있다.

# ~/.ssh/config
Host omac-jp
    HostName <해당 노드의 IP>
    User devuser
    Port 22
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 10m
    ServerAliveInterval 30
    ServerAliveCountMax 3

ControlPersist 10m은 메인 연결이 끊기고 창을 닫아도 다중화 채널을 10분간 유지한다는 뜻이다. 이 기간 동안 새로 여는 터미널 탭이나 VS Code 재연결은 모두 이 기존 채널을 통하게 되어, 암호화 재협상에 걸리는 시간을 아낄 수 있다. ServerAliveInterval은 일부 통신사 NAT가 유휴 상태의 연결을 몰래 끊어버리는 문제에 대응하기 위한 것이다.

확장 프로그램 캐시와 인덱싱 가속화

앞서 언급한 "매번 확장 프로그램이 재설치되는" 문제는 대부분 VS Code 자체의 문제가 아니라, 매번 접속하는 원격 호스트가 바뀌었기 때문인 경우가 많다—예를 들어 콘솔에서 시스템을 재설치했거나 다른 인스턴스로 바꾼 경우다. 같은 머신을 고정해서 계속 사용한다면, ~/.vscode-server 안의 확장 프로그램, 언어 서버 캐시, TypeScript/Swift 인덱스가 계속 유지되며, 두 번째 연결부터는 "즉시 열리는" 경험을 하게 될 것이다.

프로젝트 규모가 큰 경우(예: 여러 target을 포함한 Xcode 프로젝트), 원격에서 미리 전체 인덱싱을 한 번 돌린 뒤 연결을 끊어 캐시를 미리 데워두는 방법도 있다.

cd ~/Projects/MyApp
xcodebuild -project MyApp.xcodeproj -scheme MyApp -showBuildSettings > /dev/null

이 단계는 실행 파일을 만들어내지는 않지만, Xcode의 인덱스 데이터베이스를 먼저 구축해 두어, 이후 에디터에서 정의로 이동할 때 현장에서 다시 만들 필요가 없게 해준다.

JetBrains Gateway의 적용 범위와 한계

팀에서 (Kotlin/Go로 작성된 API 같은) 백엔드 서비스도 같은 클라우드 Mac에 배포하고 있다면, JetBrains Gateway도 하나의 선택지가 된다. 로컬에는 가벼운 클라이언트를 설치하고, 원격에서는 완전한 IDE 백엔드(IntelliJ IDEA, GoLand 등)를 실행하며, 렌더링 결과를 자체 프로토콜로 로컬에 전달한다. 순수 웹 IDE보다 로컬 머신에 가까운 경험을 제공한다.

Gateway의 경계는 명확하다. 대응하는 JetBrains IDE가 있는 언어 생태계에 서비스를 제공하는 것이며, Xcode 프로젝트, Interface Builder, Swift Playground 같은 애플 생태계 전용 도구는 다루지 않는다.

즉, 클라우드 Mac에서 순수 iOS/macOS 개발을 한다면 주력 도구 체인은 여전히 VS Code Remote-SSH(코드 작성, 스크립트 실행, 로그 확인)와 터미널의 xcodebuild 조합이며, Gateway는 팀에서 "같은 Mac으로 겸사겸사 백엔드 서비스도 돌리는" 상황에 더 적합하다.

tmux로 세션 유지하며 네트워크 흔들림에 대응하기

어떤 원격 편집 방식을 쓰든, 하위 연결이 SSH인 이상 끊김 위험은 항상 존재한다—출장 중 Wi-Fi를 전환하거나 집 라우터가 재시작되면 연결이 순간적으로 끊길 수 있다. 이때 마침 40분짜리 빌드를 돌리고 있었다면, 연결이 끊기는 순간 빌드 프로세스가 강제 종료되어 그동안의 작업이 모두 헛수고가 된다.

해법은 시간이 오래 걸리는 모든 작업을 tmux 세션 안에서 실행하는 것이며, SSH 세션에 직접 매달아두지 않는 것이다.

ssh omac-jp
tmux new -s build
xcodebuild -workspace MyApp.xcworkspace -scheme MyApp \
  -destination 'generic/platform=iOS' build 2>&1 | tee build.log

연결이 끊긴 후 다시 접속해서 tmux attach -t build를 실행하면 방금 전 터미널 출력을 그대로 이어받을 수 있고, 빌드 프로세스는 전혀 영향을 받지 않는다. 이 습관은 빌드에만 유용한 것이 아니라, 오래 걸리는 모델 파인튜닝, 로그 모니터링, fastlane 패키징 스크립트도 모두 tmux 안에 넣어 돌려야 한다.

그래픽 디버깅은 어떻게: VNC/화면 공유의 트레이드오프

명령줄로 대부분의 상황을 해결할 수 있지만, 일부 작업은 그래픽 인터페이스를 피할 수 없다. Instruments로 메모리 타임라인을 보거나, Interface Builder에서 제약 조건을 조정하거나, 단순히 실제 렌더링에서 UI가 어떻게 보이는지 확인하고 싶은 경우 등이다. 이때는 화면 공유(VNC)로 전환해야 하는데, 경험이 명령줄과는 완전히 다르다—지연에 더 민감하므로, 해상도를 실제 필요한 범위로 낮추는 것을 권장한다(4K가 아니라 예를 들어 1440×900). 색상 깊이도 "수천 색" 단계로 조정하면 리전을 넘나드는 접속 시 부드러움이 눈에 띄게 개선된다. 일상적인 개발에서는 SSH + 에디터를 기본으로 하고, 그래픽 인터페이스는 필요할 때만 임시로 켜야 하며, VNC를 상시 켜두어 대역폭을 계속 점유하게 하지 않는 것이 좋다.

체크리스트와 함정 기록

이 워크플로를 실제로 적용하기 전에 아래 항목들을 점검해보자.

• SSH config에 ControlMaster/ControlPersist를 설정해 중복 핸드셰이크로 인한 지연을 줄인다;
• 같은 인스턴스를 고정해서 계속 사용하고, 시스템을 자주 재설치하지 않는다. 그렇지 않으면 확장 프로그램 캐시와 인덱스가 반복적으로 다시 구축된다;
• 몇 분 이상 걸리는 모든 작업은 tmux 안에 넣고, 맨 SSH 세션에 직접 매달아두지 않는다;
• Xcode 관련 작업에서는 Gateway의 경계를 명확히 인식하고, 그래픽 기반 애플 도구 체인을 대체할 수 있다고 기대하지 않는다;
• 그래픽 디버깅은 필요할 때만 VNC를 켜고, 해상도와 색상 깊이를 낮춰 부드러움을 우선시한다;
• 실제로 선택할 수 있는 기종과 노드는 콘솔에서 현재 선택 가능한 구성을 기준으로 하고, 이를 바탕으로 대역폭과 지연 예상치를 계획한다.

자주 묻는 질문