Xcode 프로젝트를 VS Code에서 열었지만 서명, 시뮬레이터, 프로젝트 설정 단계에서 멈춥니다.
가장 빠른 해법은 VS Code를 원격 편집 창구로 사용하고, Xcode 27을 애플 플랫폼 도구 체인의 기준으로 남기는 이중 작업 흐름입니다.
이 글은 윈도우나 리눅스를 주 컴퓨터로 쓰면서 iOS 앱을 빌드하고 배포해야 하는 개발자를 위한 내용입니다. VS Code를 선호하는 Swift 개발자와, 원격 맥을 개발 환경과 상시 빌드 서버로 함께 쓰려는 소규모 팀에도 맞습니다.
마지막 업데이트: 2026년 8월 31일. Xcode 27 상태와 호환 범위는 애플의 Xcode 시스템 요구 사항, Remote SSH 기능은 VS Code 공식 원격 접속 문서를 기준으로 확인했습니다.
역할 경계
VS Code는 원격 파일 편집과 터미널 작업을 한곳에 모으는 데 적합합니다. 그러나 이것만으로 Xcode 프로젝트의 모든 설정, iOS 시뮬레이터 조작, 서명 진단과 배포 검증까지 대체한다고 판단하면 안 됩니다.
| 작업 영역 | VS Code와 Remote SSH | Xcode 27 또는 원격 그래픽 세션 | 판단 |
|---|---|---|---|
| Swift 소스 편집 | 원격 맥의 파일을 직접 열고 수정할 수 있습니다 | 필수 아님 | VS Code 중심 |
| Swift 패키지 작업 | Swift 확장과 명령줄 도구를 활용할 수 있습니다 | 패키지 설정 확인에 유리합니다 | 프로젝트 유형별 |
| Xcode 프로젝트와 작업 공간 설정 | 파일 편집은 가능하지만 전체 설정 화면을 그대로 제공하지 않습니다 | 프로젝트 설정과 구성 확인이 필요합니다 | Xcode 유지 |
| 빌드와 자동화 테스트 | 원격 터미널에서 xcodebuild를 호출할 수 있습니다 | 실패 원인과 결과를 그래픽으로 확인할 때 유리합니다 | 이중 사용 |
| 시뮬레이터 | 명령줄 제어는 가능하지만 화면 상호 작용은 제한됩니다 | 시뮬레이터 실행과 UI 검증에 필요합니다 | 원격 그래픽 세션 |
| 서명과 배포 | 명령 실행은 가능하지만 자격 증명 상태를 직접 보장하지 않습니다 | 키체인, 아카이브, 배포 검증을 담당합니다 | Xcode 유지 |
따라서 VS Code Xcode 27 대체라는 질문의 답은 “완전한 대체는 불가능하지만, 원격 개발의 주 편집 도구로는 충분히 쓸 수 있다”입니다. 이는 애플이나 마이크로소프트의 공식 대체 선언이 아니라, 각 도구가 제공하는 기능 범위를 바탕으로 한 운영 판단입니다.
원격 작업 공간
Remote SSH 연결과 단일 디렉터리
Remote SSH는 윈도우나 리눅스에서 Xcode를 실행하게 만드는 기능이 아닙니다. 지원되는 맥 호스트에 SSH로 연결하고, VS Code의 창과 확장을 원격 환경에 붙이는 방식입니다. 원격 확장 동작은 Remote SSH의 공식 지원 범위에서 확인해야 합니다.
소스는 로컬과 원격에 따로 복사하지 말고 원격 맥의 하나의 작업 디렉터리에 보관합니다. 다음 상태가 모두 맞아야 합니다.
- SSH 접속 계정이 저장소와 빌드 폴더를 읽고 쓸 수 있어야 합니다.
- 원격 VS Code 창에서 열어 둔 경로가 실제 빌드 경로와 같아야 합니다.
- 원격 터미널의 Git 상태가 기대한 브랜치와 커밋을 가리켜야 합니다.
- 언어 확장과 빌드 관련 확장은 로컬이 아니라 원격 창에 설치되어야 합니다.
- 파일 하나를 수정한 뒤 원격 터미널과 Xcode에서 즉시 같은 변경이 보여야 합니다.
이 검사를 통과하지 못하면 코드 문제처럼 보이는 오류가 실제로는 서로 다른 복사본에서 발생한 것일 수 있습니다.
Swift 지원의 실제 범위
Swift 확장은 문법 강조, 일부 코드 탐색과 패키지 기반 작업을 돕습니다. Swift 공식 문서도 VS Code에서 Swift를 시작하는 범위를 설명하지만, 이것을 완전한 Xcode 프로젝트 지원으로 해석해서는 안 됩니다.
Swift 패키지와 Xcode 프로젝트 또는 작업 공간은 운영 방식이 다릅니다. 코드 자동 완성이 정상이어도 다음 항목이 자동으로 검증되는 것은 아닙니다.
- 여러 구성과 대상 사이의 빌드 설정
- 프로젝트 파일에 저장된 서명 설정
- 연결된 프레임워크와 빌드 단계
- 공유 구성표와 배포용 아카이브 설정
- 시뮬레이터 화면에서 발생하는 UI 문제
그래서 VS Code에서 직접 열고 빌드할 수 있는지는 프로젝트 형식에 따라 달라집니다. Swift 패키지는 명령줄 중심으로 접근하기 쉽지만, 복잡한 Xcode 프로젝트와 작업 공간은 Xcode에서 설정을 확인하는 절차가 남습니다.
도구 체인 일치
원격 맥에 Xcode 27이 설치되어 있다는 사실만으로 충분하지 않습니다. 맥의 운영 체제 요구 사항과 Xcode 27의 지원 범위가 맞아야 합니다. 애플의 공식 요구 사항에는 Xcode 27 베타 6의 지원 운영 체제, SDK와 시뮬레이터 범위가 정리되어 있으므로 버전 변경 때마다 다시 확인해야 합니다.
먼저 활성 개발자 디렉터리를 확인합니다.
xcode-select -p
xcodebuild -version
xcodebuild -showsdks
xcode-select의 선택 경로, xcodebuild가 보고하는 버전, 실제 SDK 목록이 서로 다른 설치를 가리키면 VS Code에서 실행한 빌드와 Xcode에서 실행한 빌드가 달라질 수 있습니다. 명령줄 도구 선택은 애플의 개발자 디렉터리 설정 문서, 명령의 역할은 xcodebuild 도구 참조를 기준으로 점검합니다.
구성표와 의존성도 같은 원칙으로 고정합니다. 저장소의 프로젝트 파일, 작업 공간, 구성표, 패키지 잠금 파일을 확인한 뒤 실제 빌드 명령에 명시합니다. 프로젝트가 어떤 대상을 빌드하는지 모른 채 기본값에 의존하면 성공한 빌드가 다른 앱 대상을 가리킬 수 있습니다.
빌드와 테스트 피드백
명령줄 빌드의 분리
VS Code의 작업이나 원격 터미널에서 xcodebuild를 실행하면 편집 창을 떠나지 않고 빌드와 자동화 테스트를 시작할 수 있습니다. 결과는 사람이 읽는 로그와 기계가 읽을 수 있는 결과 번들로 나누어 보관하는 편이 좋습니다.
xcodebuild \
-workspace "<WORKSPACE_PATH>" \
-scheme "<SCHEME_NAME>" \
-sdk iphonesimulator \
-destination 'platform=iOS Simulator,name=<SIMULATOR_NAME>' \
clean test \
-resultBundlePath "<RESULT_BUNDLE_PATH>"
위 명령의 경로, 구성표, 시뮬레이터 이름은 실제 값을 넣지 말고 저장소 규칙에 맞춰 치환해야 합니다. 로그에는 <PROJECT_PATH>, <TEAM_ID>, <BUNDLE_ID>처럼 명확한 자리 표시자를 사용하면 자격 증명이나 내부 정보가 섞이는 일을 줄일 수 있습니다.
자동화 테스트가 통과했다면 결과 번들을 보관하고 실패한 테스트, 경고, 테스트 대상과 실행 환경을 기록합니다. 애플의 테스트 실행과 결과 해석 문서처럼 결과를 실행 단위로 확인해야 합니다. 터미널에 성공 문구가 나왔다는 사실만으로 시뮬레이터에서 화면이 정상이라고 결론 내리면 안 됩니다.
시뮬레이터와 그래픽 검증
윈도우에서 Remote SSH로 맥에 연결한 뒤에도 명령줄에서 시뮬레이터를 제어할 수 있습니다. simctl은 Xcode에 포함된 도구이므로 부팅, 설치, 로그 수집 같은 자동화에 활용할 수 있습니다. 다만 화면을 직접 누르고, 전환을 확인하고, SwiftUI 미리 보기를 조작하고, UI 디버거를 사용하는 작업은 원격 그래픽 세션이 필요합니다.
최소 검증은 다음 세 층으로 나눕니다.
- Debug 빌드가 지정한 대상과 SDK로 끝나는지 확인합니다.
- 자동화 테스트를 실행하고 결과 번들을 가져옵니다.
- 원격 Xcode 세션에서 시뮬레이터를 시작해 핵심 화면을 직접 확인합니다.
이 세 결과를 하나의 저장소와 하나의 도구 체인에서 얻어야 “개발 가능”이라는 판단을 배포 가능성과 혼동하지 않게 됩니다.
자격 증명과 복구
서명 정보의 위치
서명 인증서와 개인 키, 프로비저닝 프로파일, 업로드용 인증 정보는 빌드를 실행하는 원격 맥에서 관리해야 합니다. 윈도우나 리눅스의 VS Code에 개인 키를 복사하는 방식은 편리해 보여도 접근 범위를 넓힙니다.
서로 다른 권한을 분리해 기록합니다.
- 소스 저장소 권한
- SSH 접속 자격 증명
- 맥 키체인의 서명 신원
- 배포 프로파일
- 앱 배포 서비스 업로드 권한
배포용 서명 코드는 애플의 서명된 코드 생성 문서를 기준으로 확인합니다. 업로드 자동화에 API 키를 쓴다면 앱 배포 API 키 생성 문서의 권한 범위를 따로 검토합니다.
다음과 같이 신원을 노출하지 않는 방식으로 상태만 확인합니다.
security find-identity -v -p codesigning
xcodebuild -workspace "<WORKSPACE_PATH>" \
-scheme "<SCHEME_NAME>" \
-showBuildSettings | grep -E 'CODE_SIGN|PROVISIONING'
아카이브가 생성되었다고 바로 배포 준비가 끝난 것은 아닙니다. 올바른 팀, 번들 식별자, 서명 신원과 프로파일이 연결되었는지 확인하고, 배포 화면에서 검증을 완료해야 합니다.
단절 복구 기준
원격 맥을 상시 개발 환경이나 빌드 서버로 쓸 계획이라면 연결 성공보다 복구 시간을 먼저 봐야 합니다. 다음 순서로 실제 저장소를 검증합니다.
- SSH 연결을 끊었다가 같은 작업 디렉터리로 다시 연결합니다.
- 원격 그래픽 세션을 닫고 다시 열어 Xcode와 시뮬레이터 상태를 확인합니다.
- 맥을 재시작한 뒤 개발자 디렉터리와 SDK 선택을 다시 확인합니다.
- Xcode와 명령줄에서 같은 구성표를 선택해 빌드합니다.
- 결과 번들과 아카이브를 새 세션에서 다시 가져옵니다.
한 항목이라도 수동 복구 기록이 없으면 장기 운영보다 일회성 원격 편집에 가깝습니다. 특히 캐시, 키체인, 시뮬레이터 데이터와 아카이브 보관 위치를 분리해 기록해야 재시작 뒤 원인을 추적할 수 있습니다.
선택 기준표
아래 표에서 “항상”에 가까운 항목이 많으면 VS Code 단독 구성이 아니라 원격 맥과 원격 그래픽 세션을 함께 운영해야 합니다.
| 사용 조건 | 권장 방식 | VS Code의 위치 | Xcode의 위치 |
|---|---|---|---|
| 코드 수정과 패키지 확인이 중심 | 원격 편집 | 주 편집기 | 필요할 때 설정 확인 |
| 명령줄 빌드와 자동화 테스트가 중심 | 개발 이중 작업 흐름 | 작업과 로그 확인 | 실패 분석과 그래픽 검증 |
| 시뮬레이터 UI와 미리 보기 확인이 빈번 | 원격 맥 개발 환경 | 소스와 명령 실행 | 그래픽 세션의 핵심 도구 |
| 서명, 아카이브, 배포가 반복됨 | 상시 빌드 환경 | 자동화 진입점 | 서명 상태와 배포 검증 |
| 물리 기기 연결과 직접 디버깅이 필수 | 로컬 또는 전용 원격 구성 | 보조 편집기 | 기기 연결과 진단 담당 |
비용과 운영 부담
| 선택지 | 초기 부담 | 반복되는 비용 항목 | 맞는 경우 |
|---|---|---|---|
| 기존 윈도우·리눅스 + 원격 맥 | 맥 연결과 권한 구성 | 사용 기간, 원격 접속, 저장 공간 | 간헐적 개발과 테스트 |
| 맥을 직접 구매 | 하드웨어 확보와 초기 지출 | 전력, 유지 보수, 교체와 보안 관리 | 장기간 고정 부하 |
| 로컬 편집 + 원격 빌드 | 저장소와 자격 증명 분리 | 네트워크, 빌드 대기, 복구 관리 | 편집은 로컬, 배포는 원격 |
| 원격 맥 상시 운영 | 초기 작업 흐름 설계 | 보존할 캐시, 아카이브, 서명 상태 관리 | 지속 개발과 자동 빌드 |
구체적인 금액은 지역, 기간과 맥 구성에 따라 달라집니다. 따라서 공개 가격을 일반화하기보다 MACCOME의 맥 미니 원격 사용 방식을 확인하고, 자신의 빌드 빈도와 보관 요구를 대입해야 합니다.
최종 검증표
| 검증 항목 | 통과 조건 | 실패 시 결론 |
|---|---|---|
| 편집 | VS Code의 변경을 원격 터미널과 Xcode가 즉시 확인 | 원격 편집만 허용 |
| 도구 체인 | 개발자 디렉터리, SDK, 구성표가 동일 | 환경 재정렬 후 재검증 |
| 빌드 | 실제 저장소에서 Debug 빌드 성공 | 개발 이중 작업 흐름 보류 |
| 테스트 | 자동화 테스트와 결과 번트 보관 | 배포용으로 사용하지 않음 |
| 그래픽 | 시뮬레이터 핵심 화면과 미리 보기 확인 | 원격 Xcode 세션 필요 |
| 서명 | 올바른 팀과 프로파일로 아카이브 검증 | 자격 증명 재구성 |
| 복구 | 재접속과 재시작 뒤 같은 작업 재현 | 상시 서버로 채택하지 않음 |
이 검증 결과는 세 가지로 정리할 수 있습니다. 편집만 통과하면 “원격 편집”, 빌드·테스트·그래픽 검증까지 통과하면 “개발 이중 작업 흐름”, 아카이브와 복구까지 반복 가능하면 “상시 빌드 환경”입니다.
현실적인 선택
현재의 윈도우나 리눅스 중심 방식은 Xcode 그래픽 기능을 쓸 때마다 원격 데스크톱으로 전환해야 하고, 로컬·원격 저장소가 갈라지기 쉽습니다. 서명 키를 여러 컴퓨터에 복사할 위험도 있습니다. 반대로 VS Code와 원격 맥을 함께 쓰면 소스 편집은 가볍게 유지하면서, Xcode가 필요한 단계만 원격 세션으로 분리할 수 있습니다.
단일 저장소에서 빌드, 테스트와 실제 아카이브까지 확인한 뒤 사용 빈도를 판단하십시오. 가끔 검증하는 정도라면 짧은 기간의 원격 맥이 맞고, 지속 개발이나 자동 빌드가 목적이라면 도구 체인과 서명 상태를 유지할 수 있는 MACCOME 원격 맥이 더 안정적인 선택입니다. 사용 방식은 한국어 맥 원격 사용 안내에서 확인할 수 있습니다.