Unity 6.3 LTS iOS 빌드: 2026년 윈도우에서 어떻게 패키징할까?

윈도우에서 Unity 프로젝트와 Xcode 프로젝트까지 만들었지만, 업로드할 아이피에이 파일이 나오지 않습니다.

가장 빠른 해결책은 작업을 두 단계로 나누는 것입니다. 윈도우에서는 Unity 프로젝트를 iOS용 Xcode 프로젝트로 내보내고, 원격 맥에서는 Xcode로 빌드·보관·코드 서명·테스트플라이트 업로드를 진행해야 합니다. 가끔 출시한다면 생성된 프로젝트를 임시 원격 맥으로 보내고, 자주 출시한다면 원격 맥에서 소스부터 다시 내보내는 편이 낫습니다.

윈도우에서 대부분의 Unity 개발을 끝내고 처음 iOS 버전을 준비하는 개인 개발자를 위한 글입니다.
테스트플라이트 빌드를 반복해서 만들지만 실제 맥을 구매하고 관리하고 싶지 않은 소규모 팀에도 적합합니다.
수동 내보내기를 재현 가능한 원격 빌드 작업으로 바꾸려는 프로젝트 유지 관리자도 대상입니다.

마지막 업데이트: 2026년 8월 29일. Unity 공식 버전 지원 및 iOS 빌드 문서, Xcode 배포 문서, 앱 스토어 커넥트 업로드 문서를 기준으로 내용을 확인했습니다.

Unity iOS 빌드는 한 번의 명령으로 완성되는 작업이 아닙니다. Unity는 iOS용 Xcode 프로젝트를 생성하고, 이후 Xcode가 해당 프로젝트를 실제 애플리케이션으로 빌드하는 구조를 설명합니다. 자세한 단계는 Unity의 iOS 빌드 과정 안내에서 확인할 수 있습니다.

이 구분을 놓치면 윈도우에서 성공한 결과를 최종 배포 파일로 오해하게 됩니다. 윈도우에서 확인할 수 있는 것은 게임 코드와 에셋, 그리고 생성된 Xcode 프로젝트입니다. 인증서 개인 키, 프로비저닝 프로파일, 보관 파일 생성과 업로드는 원격 맥의 Xcode 단계에 남습니다.

출시 빈도에 따라 다음처럼 결정합니다.

원격 맥을 처음 도입한다면 원격 맥의 Xcode 도구 체인 검수 방법을 먼저 확인하는 것이 좋습니다. 그래픽 화면이 필요한 첫 설정은 VNC로 처리하고, 반복 작업은 SSH와 스크립트로 분리하면 접근 권한과 재현성을 관리하기 쉽습니다.

Unity 6.3 LTS와 iOS 빌드 지원 모듈이 윈도우 개발 환경에 설치되어 있는지 확인합니다. Unity 6의 시스템 요구 사항과 지원 환경은 Unity 공식 시스템 요구 사항에서 확인할 수 있습니다. Unity 6.3의 정확한 릴리스 정보는 Unity 6000.3.0f1 릴리스 페이지를 기준으로 기록합니다.

원격 맥에서는 다음 항목을 문서로 남깁니다.

• Unity 편집기 버전과 설치된 iOS 빌드 지원 모듈
• 패키지 잠금 파일과 네이티브 플러그인 버전
• 설치된 Xcode 버전과 선택된 개발자 도구 경로
• 빌드 대상, 번들 아이디, 팀 아이디, 최소 운영체제 설정
• 서명에 사용할 인증서 유형과 프로비저닝 프로파일 이름

Xcode의 요구 조건은 고정된 규칙으로 보지 않아야 합니다. 앱 업로드 기준과 허용되는 Xcode 조합은 바뀔 수 있으므로, 출시 직전에 Apple의 앱 배포 준비 문서를 다시 확인합니다.

처음부터 정식 프로젝트를 사용하지 말고 빈 Unity 프로젝트로 검증합니다. 빈 프로젝트에서 iOS 내보내기가 되는지 확인한 뒤, 원격 맥에서 Xcode 프로젝트를 열고 명령 줄 빌드가 실행되는지 확인합니다. 이 단계가 실패하면 게임 플러그인이나 인증서 문제로 범위를 넓히지 말고 도구 경로부터 고칩니다.

생성된 Xcode 프로젝트를 전달하는 경우

윈도우에서 Unity의 iOS 빌드 대상을 선택하고 Xcode 프로젝트를 별도 출력 폴더에 생성합니다. 결과 폴더만 복사하지 말고, 라이브러리와 플러그인, 빌드 후처리로 생성된 설정 파일이 함께 포함되었는지 확인합니다.

압축과 전송 과정에서 심볼릭 링크가 일반 파일로 바뀌거나 일부 네이티브 라이브러리가 빠질 수 있습니다. 전송 뒤 원격 맥에서 프로젝트 구조를 확인하고, 원본과 파일 목록을 비교합니다. 생성 결과를 저장소에 넣는다면 대용량 캐시와 임시 파일을 분리해야 합니다.

이 방식은 출시가 드문 프로젝트에 적합합니다. 다만 Xcode 프로젝트를 윈도우와 원격 맥에서 동시에 수정하면 다음 내보내기 때 변경 사항이 사라질 수 있습니다. Unity 설정과 후처리 스크립트를 원본으로 삼고, 생성된 프로젝트는 결과물로 취급합니다.

원격 맥에서 소스부터 다시 내보내는 경우

지속적인 빌드라면 Unity 소스, 패키지 잠금 파일, 플러그인, 빌드 설정을 원격 맥으로 가져옵니다. 원격 맥에서 정해진 Unity 편집기를 호출해 Xcode 프로젝트를 생성하고, 이어서 Xcode 보관 작업을 실행하는 흐름을 스크립트로 고정합니다.

이 방식은 전송되는 결과물보다 재현 절차를 관리하기 쉽습니다. 대신 원격 맥에도 호환되는 Unity 편집기와 iOS 빌드 지원 모듈이 필요합니다. 네이티브 플러그인이나 PostProcessBuild 스크립트가 운영체제별 경로를 가정하고 있지 않은지도 확인합니다.

두 방식 모두 같은 생성 폴더를 수동으로 고치는 습관은 피해야 합니다. 수정이 필요하다면 Unity 설정, 플러그인 설정 또는 후처리 코드에 반영한 뒤 다시 생성합니다.

원격 맥으로 프로젝트를 옮긴 뒤 곧바로 인증서를 바꾸지 않습니다. 먼저 Xcode에서 프로젝트가 서명 없이 컴파일 가능한지 확인합니다. 컴파일이 실패하면 Unity 내보내기, CocoaPods, 네이티브 플러그인, 헤더 경로와 후처리 스크립트를 순서대로 조사합니다.

그 다음 아래 항목을 하나씩 확인합니다.

• 팀 설정이 올바른 개발자 계정에 연결되는지
• 번들 아이디가 앱 스토어 커넥트의 앱 기록과 일치하는지
• 권한 설정이 실제 기능과 일치하는지
• 인증서의 개인 키가 원격 맥에서 사용 가능한지
• 프로비저닝 프로파일이 현재 번들 아이디와 권한을 포함하는지
• 빌드 번호가 이전 업로드와 겹치지 않는지

개인 키와 비밀번호, 앱 스토어 커넥트용 API 키는 Unity 프로젝트나 저장소에 넣지 않습니다. 자동화할 때도 명령 줄에 평문으로 남기지 말고 원격 맥의 보안 저장 영역이나 비밀 변수로 주입합니다.

이후 Xcode에서 보관 작업을 실행합니다. Apple은 배포용 앱을 보관하고 검증한 뒤 배포하는 흐름을 안내하고 있으므로, Xcode의 테스트 및 배포 빌드 안내를 기준으로 결과를 확인합니다. 단계의 종료 조건은 “빌드가 성공했다”가 아니라, 배포 가능한 보관 결과가 생성되고 로그가 보존된 상태입니다.

보관 결과가 만들어졌다면 Xcode의 검증과 업로드를 실행합니다. Apple의 Xcode 테스트플라이트 및 정식 배포 안내는 이 구간에서 확인할 절차를 제공합니다.

성공 여부를 다음 네 상태로 나누어 기록합니다.

1. Unity가 Xcode 프로젝트를 생성했는가
2. Xcode가 보관 결과를 만들었는가
3. 코드 서명이 검증되었는가
4. 앱 스토어 커넥트 업로드와 서버 처리가 끝났는가

업로드가 끝났다고 곧바로 테스트플라이트에서 보이는 것은 아닙니다. 앱 기록, 번들 아이디, 버전 번호와 빌드 번호를 확인한 뒤 처리 상태를 기다려야 합니다. Apple의 빌드 업로드 문서와 빌드 업로드 상태 설명을 기준으로 전달 로그와 처리 상태를 구분합니다.

빌드가 보이지 않을 때 인증서를 무작정 교체하거나 같은 파일을 반복 업로드하지 않습니다. 처리 중인지, 거부되었는지, 전달 로그에 오류가 있는지부터 확인해야 합니다. 같은 빌드 번호를 다시 올리는 방식은 문제를 해결하지 못할 수 있습니다.

첫 성공 뒤에는 모든 단계를 하나의 긴 스크립트로 합치지 않습니다. Unity 내보내기, Xcode 보관, 서명, 업로드를 독립 단계로 나누고 각 단계의 입력과 결과를 저장합니다.

다음 점검을 수행합니다.

• 소스 변경만 발생한 경우 이전 패키지와 캐시를 사용해 재실행
• 네이티브 플러그인 변경 뒤에는 Xcode 프로젝트를 새로 생성
• 인증서를 사용할 수 없는 상황에서 빌드가 안전하게 중단되는지 확인
• 보관 결과와 로그의 보존 위치, 삭제 시점을 분리
• 업로드 실패 뒤 보관 단계부터 반복하지 않아도 되는지 확인
• 윈도우와 원격 맥의 Unity 및 패키지 잠금 상태가 같은지 확인

처음에는 실제 프로젝트의 작은 변경 하나로 검증합니다. 이후 플러그인 변경과 인증 정보 만료 상황을 각각 시험합니다. 이 세 가지 실패를 구분하지 못하면 자동화가 되어도 장애 원인을 찾기 어렵습니다.

Unity iOS 코드 서명 실패 점검 안내를 참고해 서명 문제를 별도 절차로 관리하고, 업로드 뒤 상태가 멈추면 앱 스토어 커넥트 업로드 상태 점검 흐름으로 확인합니다.

한 달에 한두 번처럼 출시가 드문 경우에는 매번 생성된 Xcode 프로젝트를 전달하는 임시 환경이 관리 부담이 적습니다. 반대로 매주 테스트플라이트 빌드를 만들거나 여러 개발자가 같은 파이프라인을 사용한다면, 원격 맥에 Unity와 Xcode 기준선을 고정하는 편이 재작업을 줄입니다.

다만 장기간 무거운 빌드를 계속 수행하거나 물리 장치 연결이 꼭 필요하다면 실제 장비를 직접 보유하는 편이 적합할 수 있습니다. 원격 환경은 네트워크 지연, 화면 공유 권한, 인증 정보 관리라는 추가 변수를 갖습니다. 반대로 별도 맥을 구매하면 초기 하드웨어 비용, 운영체제 업데이트, 저장 공간 관리, 24시간 전원 유지 부담을 직접 감당해야 합니다.

윈도우 쪽 개발이 끝났고 최종 단계에만 맥이 필요하다면 JEXCLOUD의 원격 맥 환경을 실제 프로젝트로 먼저 검증하는 방식이 합리적입니다. 생성, 보관, 업로드가 모두 성공한 뒤에만 임시 사용을 상시 사용으로 늘릴지 결정합니다.

FAQ는 위 메타데이터에 정리한 네 가지 질문을 기준으로 제공합니다. 핵심은 윈도우의 Unity 개발과 원격 맥의 Xcode 배포를 하나의 작업으로 오해하지 않는 것입니다.

윈도우와 원격 맥을 함께 쓰는 구성은 iOS 빌드 자체를 없애는 방법이 아닙니다. Unity 내보내기, Xcode 컴파일, 보관, 서명, 업로드와 서버 처리를 각각 확인하는 방법입니다.

현재 윈도우만 사용하는 방식은 최종 Xcode 단계가 없고, 생성 프로젝트를 수동 전송할 때 라이브러리 누락과 환경 차이가 생기며, 출시 때마다 인증서와 프로파일을 다시 점검해야 한다는 단점이 있습니다. 반면 JEXCLOUD의 원격 맥을 임시 또는 상시 환경으로 사용하면 필요한 시점에 실제 맥 기반 Xcode 작업 공간을 확보하고, 반복 빌드 절차를 같은 환경에서 유지할 수 있습니다. 먼저 실제 프로젝트 하나로 전체 경로를 검증한 뒤, 출시 빈도에 맞춰 이용 기간을 정하는 것이 안전합니다.