Apple Developer 릴리스 목록에는 iOS 27과 Xcode 27이 공개된 버전으로 올라와 있습니다(공식 릴리스 상태 확인). 이 환경에서 iOS 27 기업 앱 배포 방식을 정한다면, 대부분의 조직은 Apple Business의 Custom Apps를 먼저 검토하세요. TestFlight는 테스트용이며, 넓은 사용자층에는 공개 또는 비공개 App Store 배포가 맞습니다. Apple Developer Enterprise Program은 일반 채널이 실제 요구를 충족하지 못하고 자격 조건도 맞을 때만 검토해야 합니다.

기업 IT 책임자: 내부 앱이나 직원용 도구의 배포 경로를 정해야 하는 경우에 적합합니다. iOS 출시 책임자: 사용자 범위, App Store Connect 설정, 서명 및 출시 흐름을 맞춰야 하는 경우에 적합합니다. 플랫폼 엔지니어링 책임자: Xcode 27 빌드와 실제 배포 단계의 책임 경계를 확인하려는 경우에 적합합니다.

먼저 사용자와 전달 범위를 고정합니다

채널 선택의 기준은 앱이 누구에게 전달되어야 하는지입니다. “직원용”이라고 부르는 것만으로 기업 내부 배포가 자동으로 정답이 되지는 않습니다. 지정된 고객 조직에 전달하는 앱과 자사 직원에게만 제공하는 앱은 배포 대상이 다릅니다.

<
배포 선택지실제 사용자와 발견 방식우선 검토 상황적합도
TestFlight초대된 테스터가 시험판을 사용합니다기능 확인, 피드백 수집, 출시 전 검증테스트에 높음
Apple Business Custom AppsApp Store Connect에서 지정한 조직이 비공개 앱을 받습니다특정 기업 또는 자사 조직에 정식 앱 제공조직 배포에 높음
기업 내부 배포자사 조직의 직원에게 앱을 제공합니다다른 일반 배포 선택지로 요구를 충족하기 어려운 경우제한 조건에서 검토
공개 App StoreApp Store에서 넓은 사용자층이 앱을 찾을 수 있습니다일반 고객에게 공개 제공대중 배포에 높음
비공개 App Store 배포공개 검색 대신 직접 링크로 앱을 찾습니다링크를 아는 사용자에게 배포하려는 경우제한적 도달에 적합
적합도는 공식 등급이 아니라 사용자 범위와 전달 방식에 따른 선택 기준입니다. Apple은 TestFlight, 지정 조직 대상 Custom Apps, 공개·비공개 배포를 서로 다른 방식으로 안내합니다([App Store Connect의 배포 방식 설명](https://developer.apple.com/help/app-store-connect/manage-your-apps-availability/set-distribution-methods)).

TestFlight를 정식 앱 전달 경로로 계속 써도 될까요?

TestFlight는 베타 빌드를 시험하고 의견을 받는 경로입니다. Apple 안내에 따르면 내부 테스터는 최대 100명, 외부 테스터는 최대 10,000명까지 초대할 수 있습니다(TestFlight 개요와 테스터 한도). 이 수용 한도를 정식 배포 권한이나 영구적인 직원 배포 방식으로 해석하면 안 됩니다.

출시 담당자는 빌드가 누구에게 공개되는지, 테스트용 빌드가 어떤 방식으로 관리되는지, 이번 단계의 목적이 검증인지 실제 운영인지 확인하세요. 테스트가 끝난 뒤에도 같은 링크와 초대 구조를 계속 사용하는 설계라면 정식 배포 요구를 충족하는지 다시 판단해야 합니다. TestFlight에서 테스트할 수 있다는 사실이 공개·비공개 App Store 또는 조직 배포 절차를 대신하지는 않습니다.

Apple Business Custom Apps와 기업 내부 배포는 어떻게 다를까요?

Custom Apps는 App Store Connect에서 지정한 조직을 대상으로 비공개 앱을 제공하는 방식입니다. 구매 조직은 Apple Business를 통해 앱을 관리하고, 배포 담당자는 MDM 또는 사용 가능한 코드 전달 방식과 설치 절차를 맞출 수 있습니다. Apple의 기업용 Custom Apps 배포 안내를 기준으로 구매 주체, 관리 방식, 대상 조직을 함께 확인하세요.

기업 내부 배포는 자사 직원에게 앱을 전달해야 하는 특별한 경우를 위한 선택지입니다. 이를 심사 회피 수단이나 외부 고객에게 앱을 배포하는 범용 통로로 취급하면 안 됩니다. 일반적인 지정 조직 배포가 요구를 충족한다면 Custom Apps를 먼저 검토하고, 다른 방식이 불가능한 이유가 명확할 때만 기업 프로그램의 자격과 현행 조건을 Apple Developer 공식 안내에서 확인하세요. 자격과 조직 검증 절차는 신청 시점의 규칙을 기준으로 판단해야 합니다.

주의: “사내에서 쓰는 앱”과 “우리 회사 직원만 설치할 수 있는 앱”은 같은 뜻이 아닙니다. 앱을 받는 조직이 고객사라면, 자사 직원 전용 배포를 선택하기 전에 고객 조직을 지정할 수 있는 Custom Apps 경로부터 확인하세요.

지정 고객에게 제공하는 앱은 어떤 경로가 맞을까요?

고객사나 업무 협력 조직에만 제공할 앱이라면, 우선 Custom Apps를 평가하세요. 고객 조직이 실제 배포 대상이고 앱 제공자가 App Store Connect에서 해당 조직을 지정해야 하는지 확인합니다. 이어서 고객의 구매 담당 조직, 앱을 제공하는 개발 조직, 설치를 관리하는 조직이 서로 일치하는지 점검하세요. 세 역할이 다르면 구매와 MDM 등록, 설치 지원의 책임을 계약 및 운영 절차에서 분명히 해야 합니다.

고객이 특정 조직으로 지정되지 않고 더 넓은 사용자가 접근해야 한다면 공개 App Store가 더 자연스러울 수 있습니다. 앱을 검색 결과에 노출하지 않고 링크로만 찾게 하려는 경우에는 비공개 배포를 따로 검토하세요. Apple은 비공개 앱을 공개 검색에 노출하지 않는 링크 기반 배포로 설명하지만, 링크를 가진 사람의 이용 범위와 실제 접근 통제는 같은 개념이 아닙니다(비공개 App Store 배포 설명). 따라서 민감한 고객 데이터의 접근 권한을 배포 방식만으로 해결하려 하지 마세요.

iOS 27 기업 앱 배포 방식과 CI 검수 항목을 연결합니다

채널을 정한 뒤에는 빌드 성공 여부와 배포 완료 여부를 분리하세요. Xcode 27에서 아카이브가 만들어졌더라도, 목표 조직에 전달되었는지, 지정한 배포 설정이 적용되었는지, 설치 관리 주체가 실제로 설치를 확인했는지는 별도 검증이 필요합니다. Xcode의 베타 테스트와 앱 출시 배포 문서를 기준으로 빌드 목적과 전달 경로를 맞추세요.

다음 순서로 파이프라인에 검수 단계를 추가합니다.

  1. 대상 사용자 범위를 기록합니다. 자사 직원, 지정 고객 조직, 링크로 접근할 사용자, 공개 고객 중 하나로 구분하고 승인된 범위를 저장합니다.
  2. 빌드 목적을 고정합니다. TestFlight 검증용인지, Custom Apps용인지, 공개 또는 비공개 App Store 출시용인지 빌드 작업에 표시합니다.
  3. 서명 주체와 자격 증명을 확인합니다. 해당 앱을 제공하는 조직의 서명 권한이 사용되는지 확인하고, 자동화 작업에 필요한 권한만 부여합니다.
  4. App Store Connect 설정을 대조합니다. 선택한 배포 방식과 대상 조직 또는 공개 범위가 일치하는지 제출 전에 확인합니다.
  5. 실제 전달을 검증합니다. 테스트 조직이나 내부 검수 계정에서 설치 경로를 실행하고, 전달 완료와 설치 결과를 출시 증거로 남깁니다.
  6. 출시 승인 조건을 분리합니다. 빌드 통과만으로 출시하지 말고, 배포 설정·검토 상태·대상 조직 확인이 모두 끝난 뒤 출시 단계로 이동합니다.
자동화에서 자주 놓치는 부분은 “아카이브 생성 성공”을 “사용자에게 전달 완료”로 기록하는 것입니다. 출시 게이트에는 빌드 결과뿐 아니라 선택한 채널, 대상 조직, 제출 또는 검토 상태, 실제 전달 확인이 포함되어야 합니다. Apple이 채널 설정이나 기업 프로그램 조건을 바꾸면 해당 설정과 파이프라인 검증 항목도 함께 다시 확인하세요. 현재 버전 상태는 [Apple Developer 릴리스 안내](https://developer.apple.com/news/releases/?id=05262026b)에서 확인할 수 있습니다.

기존 실행 환경과 원격 Mac을 비교합니다

이미 다른 운영체제의 빌드 서버만 사용하고 있다면, macOS 앱을 빌드하고 서명하는 작업을 실제로 수행할 환경이 있는지 먼저 점검하세요. 기존 서버를 그대로 유지하면 새 환경 관리 부담은 적지만, Mac 기반 빌드 작업을 처리하지 못하는 구간이 남을 수 있습니다. 반대로 Mac을 직접 구매하면 장비와 계정, 업데이트, 장애 대응을 조직이 맡아야 합니다. 원격 Mac 임대는 필요 기간에 맞춰 Mac 빌드 환경을 검토할 수 있지만, 서명 권한 관리와 복구 절차를 대신 설계해 주는 것은 아닙니다.

따라서 장기간 상시 가동되는 중량 작업이나 물리 장비 연결이 필수인 경우에는 직접 보유가 더 적합할 수 있습니다. 출시 일정에 맞춘 빌드 노드나 검증 환경이 필요하고, 장비 구매·관리 부담을 줄이고 싶다면 MACGPU의 원격 Mac 환경을 실제 서명 권한과 복구 요구에 대조해 보세요. 지역별 옵션을 확인하려면 서울 Mac 환경 안내도 참고할 수 있습니다.

분배 채널을 먼저 확정하고, 해당 채널을 대상으로 CI에서 실제 전달까지 검증하는 것이 핵심입니다. TestFlight는 검증에, Custom Apps는 지정 조직 배포에, 기업 내부 배포는 다른 선택지가 맞지 않는 제한된 경우에 사용하세요. 출시 노드가 필요하다면 MACGPU 원격 Mac이 서명 권한, 빌드 실행, 장애 후 복구 요구를 충족하는지 확인한 뒤 평가하세요.