iOS 27 Bundles와 Suites, 어떻게 선택할까? 2026 독립 개발자 가이드

iOS 27 Bundles와 Suites, 어떻게 선택할까? 2026 독립 개발자 가이드

구독 상품은 설계했지만, Bundles와 Suites 중 어느 쪽이 맞는지 판단하기 어렵습니다.

빠른 선택은 이렇습니다. 한 앱 안에서 여러 구독을 한 번에 제공하려면 Bundles를 먼저 검토하고, 같은 개발자의 여러 앱에서 구독 하나로 권한을 제공하려면 Suites를 먼저 검토합니다. 여러 개발자가 참여한다면 Apple의 신청 및 설정 자격부터 확인해야 합니다.

한 앱의 구독 선택지를 설계하는 독립 개발자는 Bundles가 현재 상품 구조에 맞는지 살펴보세요.
여러 앱을 운영하는 스튜디오는 앱 간 구독 권한 공유가 필요한지부터 판단하세요.
협업 구독을 준비하는 팀은 기술 구현에 앞서 신청 조건과 출시 경로를 확인하세요.

마지막 확인: 2026년 9월 24일. Apple의 공식 안내와 개발자 문서를 기준으로 정리했습니다. 실제 사용 가능 여부와 설정 범위는 계정 상태 및 Apple의 Bundles와 Suites 공식 요건에서 다시 확인해야 합니다.

구독을 묶는 방식은 상품 수보다 권한 범위로 고르세요

Apple은 2026년 9월 16일 Bundles와 Suites에 관한 안내를 공개했습니다. 공식 설명은 한 앱의 구독 조합, 같은 개발자의 여러 앱에 걸친 구독, 여러 개발자가 참여하는 경우를 구분합니다. 다만 기능 소개가 모든 계정에 설정 권한이 열렸다는 뜻은 아닙니다. 적용 범위와 신청 가능 여부는 Apple의 발표 및 계정 내 상태를 기준으로 판단해야 합니다.

개발 상황 구매자가 원하는 경험 우선 검토할 방향 먼저 확인할 점
앱 하나를 운영하며 구독 상품을 여러 개 제공 한 앱에서 여러 구독 선택지를 조합 Bundles 기존 상품과 결합 뒤의 권한이 겹치는지
같은 개발자의 앱이 여러 개 구독 하나로 여러 앱의 권한 이용 Suites 앱별 권한과 계정 연결 방식
서로 다른 개발자가 함께 구독 제공 여러 개발자의 상품을 함께 이용 Bundles 검토 신청 요건과 계정별 설정 가능 여부

iOS 27 Bundles와 Suites는 무엇이 다른가요? 핵심은 앱 간 권한 공유 여부입니다. Bundles는 여러 구독 상품의 조합을 검토할 때, Suites는 같은 개발자의 여러 앱에서 구독 경험을 공유하려 할 때 먼저 살펴보는 선택지입니다. 세부 조건은 Apple의 공식 구독 안내를 확인하세요.

상품을 묶을 수 있는지와 사용자가 실제로 어떤 기능에 접근하는지는 별개의 결정입니다. 구매 화면이 올바르게 표시되어도 앱의 권한 판단이 잘못되면 기대한 구독 경험이 되지 않습니다.

한 앱의 독립 개발자라면 기존 구독 구조부터 대조하세요

앱이 하나뿐이어도 Bundles를 검토할 수 있나요? 한 앱에서 여러 구독 상품을 조합하려는 경우라면 Bundles를 우선 검토할 수 있습니다. 반대로 목적이 여러 앱에 걸친 권한 공유라면, 앱이 하나인 상태에서 Suites를 먼저 선택할 이유가 분명한지 확인해야 합니다.

현재 상품 목록을 펼쳐 각 구독의 권한, 결제 주기, 대상 사용자를 적어 보세요. 다음으로 결합 상품을 샀을 때 중복 권한이 생기는지 확인합니다. 예를 들어 이미 같은 기능을 제공하는 상품을 함께 묶으면 사용자는 더 많은 비용을 내면서도 추가 가치를 느끼지 못할 수 있습니다.

주기는 임의로 설계하지 마세요. 상품 조합 뒤에 허용되는 구독 주기와 설정 조건은 Apple의 최신 요건에 대조해야 합니다. 가능 여부를 경험이나 기존 상품의 동작만으로 추정하면 안 됩니다. App Store Connect의 구독 설정 안내를 기준으로 상품별 조건을 확인하고, 계정에 해당 선택 항목이 실제로 나타나는지도 검토하세요.

여러 앱을 운영한다면 구독 상품보다 앱 간 권한을 먼저 설계하세요

같은 개발자가 앱을 여러 개 제공하더라도 모든 앱이 구독 하나를 공유해야 하는 것은 아닙니다. 앱별 기능과 구매 의도가 크게 다르면 상품을 나누는 편이 사용자에게 더 명확할 수 있습니다. 반대로 사용자가 앱 사이를 이동하며 같은 유료 기능을 이용해야 한다면 Suites를 검토할 이유가 생깁니다.

같은 개발자의 여러 앱에는 어떤 구독 조합이 적합한가요? 공통 구독이 필요한 이유가 분명하고, 앱별 권한을 일관되게 판정할 수 있을 때 Suites를 우선 살펴보세요. 앱마다 별도 권한과 구매 흐름이 필요하다면 기존 구독 구조를 유지하거나 Bundles와 비교해 보는 편이 낫습니다.

결정 전에 앱마다 권한을 표로 정리하세요. 구독 구매자에게 허용되는 기능, 로그인 계정과 거래를 연결하는 방식, 구독을 취소하거나 복원했을 때 바뀌는 접근 범위를 포함해야 합니다. Apple은 여러 앱에 구독을 제공하는 기술 안내를 공개하고 있지만, 특정 프로젝트의 권한 연결 구현까지 자동으로 보장하는 것은 아닙니다. 앱 간 접근 방법은 앱의 계정 구조와 실제 테스트 결과로 확인해야 합니다.

협업 개발자는 코드 작성 전에 신청 조건을 확인하세요

여러 개발자가 함께 제공하는 구독은 StoreKit 2 코드를 작성했다고 해서 곧바로 설정 자격이 생기는 구조가 아닙니다. Apple의 공식 안내에는 신청, 관련 계약, 제출 자료에 관한 조건이 포함되어 있습니다. 따라서 기술 검토와 별도로 각 참여자의 계정 및 자료가 요건을 충족하는지 확인해야 합니다.

다른 개발자와 Bundles를 구성하기 전에 무엇을 확인해야 하나요? 참여 개발자와 각자의 앱을 먼저 확정하세요. 그다음 공식 안내에서 신청 대상, 계약 상태, 요구 자료, App Store Connect에서의 설정 가능 여부를 대조하세요. 신청 절차와 실제 제공 가능 여부가 계정마다 다를 수 있으므로, 승인이나 메뉴 노출을 확인하기 전에는 출시 일정을 확정하지 않는 편이 안전합니다.

  • 각 참여자가 관련 개발자 계약을 완료했는지 확인합니다.
  • 참여할 앱과 구독 상품의 소유 관계를 정리합니다.
  • Apple이 요구하는 신청 정보와 자료를 공식 페이지에서 대조합니다.
  • App Store Connect에서 설정 항목이 실제로 제공되는지 확인합니다.
  • 자격 확인이 끝나기 전에는 협업 상품을 출시 확정 상태로 안내하지 않습니다.

StoreKit 2에서는 구매 화면과 권한 판정을 따로 검증하세요

StoreKit 2는 구독 거래를 다루는 도구이지만, 구매 화면이 표시되는 것만으로 앱의 접근 제어까지 검증되지는 않습니다. Apple은 StoreKit 2 개요와 Transaction 거래 문서를 제공합니다. 개발자는 거래의 검증 상태와 앱 내부의 권한 연결을 각각 확인해야 합니다.

구독 권한을 점검할 때는 현재 유효한 거래를 확인하는 흐름도 필요합니다. Apple의 Transaction.currentEntitlements 설명은 사용자의 현재 권한을 확인하는 API 동작을 안내합니다. 다음 코드는 검증된 거래를 별도로 분기하는 기본 형태입니다. 실제 상품 식별자와 앱별 권한 규칙은 프로젝트에 맞게 연결해야 합니다.

for await result in Transaction.currentEntitlements {
    guard case .verified(let transaction) = result else {
        continue
    }

    print("검증된 상품:", transaction.productID)
}

예상 출력 예시는 다음과 같습니다. 실제 상품 식별자는 앱에서 설정한 값으로 달라집니다.

검증된 상품: com.example.subscription

이 출력만으로 구독 권한이 올바르다고 판단하면 안 됩니다. 상품 식별자를 앱 기능에 연결하는 규칙, 거래 취소나 만료 시 처리, 다른 앱에서의 접근 여부도 함께 검증해야 합니다. 복원 구매와 테스트 방법은 Apple의 개발 단계별 구독 테스트 안내 및 TestFlight 구독 테스트 설명을 확인하세요.

출시 전에는 자격·빌드·구매 검증을 각각 통과시키세요

상품 설정이 가능하다는 결과, Xcode에서 빌드가 통과했다는 결과, 구매 흐름을 시험할 수 있다는 결과는 서로 다른 검증입니다. 하나가 성공해도 나머지가 자동으로 확인되는 것은 아닙니다.

  1. 상품 구조를 고정합니다. 각 구독의 권한, 주기, 대상 앱을 정리하고 중복 권한을 확인합니다.
  2. 설정 자격을 확인합니다. Apple 공식 요건과 개발자 계정의 실제 설정 항목을 대조합니다.
  3. 앱의 거래 처리를 점검합니다. StoreKit 2의 검증된 거래와 상품 식별자가 앱 권한으로 연결되는지 확인합니다.
  4. 앱 간 접근을 시험합니다. Suites를 고려한다면 로그인 상태, 구매 앱과 이용 앱의 조합, 복원 뒤의 결과를 따로 검증합니다.
  5. 실제 빌드와 TestFlight 흐름을 확인합니다. Xcode 빌드, 테스트용 구독 구매, 복원, 만료 또는 권한 회수 처리를 점검합니다.
  6. 출시 직전에 다시 대조합니다. 신청 상태, 상품 설정, 빌드에 포함된 상품 식별자, 검수 대상 버전을 각각 확인합니다.

선택은 다음 조건으로 좁힐 수 있습니다.

  • 앱 하나에서 여러 구독 상품을 결합하려면 Bundles를 먼저 검토합니다. 결합 뒤 권한이 불명확하면 기존 상품 구성을 유지하고 권한부터 다시 설계합니다.
  • 같은 개발자의 여러 앱에서 구독 하나를 공유하려면 Suites를 먼저 검토합니다. 앱 간 권한 판정을 검증할 수 없다면 공유를 서두르지 않습니다.
  • 여러 개발자가 참여한다면 Bundles의 신청 조건과 계정별 설정 가능 여부가 확인된 뒤에 구현 범위와 일정을 확정합니다. 확인되지 않았다면 독립 상품으로 출시할 수 있는 대안을 준비합니다.

검증할 Mac 환경이 필요하다면 구매 방식도 비교하세요

구독 설계를 확정한 뒤에는 Xcode 빌드와 TestFlight 검증을 반복할 수 있는 환경이 필요합니다. 기존 컴퓨터만 쓰면 macOS 전용 빌드 작업을 수행할 수 없고, 개인 Mac에 작업을 몰아주면 저장 공간과 상시 빌드 운영을 함께 책임져야 합니다. 별도 Mac을 구매하면 초기 하드웨어 비용과 유지 관리가 필요하며, 일반적인 클라우드 빌드 환경은 관리자 권한이나 장시간 유지되는 작업 환경이 필요한 프로젝트에 맞지 않을 수 있습니다.

장기간 동일한 장비를 계속 사용하는 팀이라면 직접 구매가 더 적합할 수 있습니다. 반면 출시 전 테스트나 특정 개발 단계에만 Mac이 필요하다면 SFTPMAC의 원격 Mac을 검토해 비용과 필요한 사용 기간을 비교할 수 있습니다. 맥 미니 대여 가격 안내에서 조건을 살펴보고, 서울 지역 환경이 필요하다면 서울 맥 미니 대여 정보도 확인하세요. Bundles와 Suites의 선택은 앱 수와 권한 구조로 먼저 결정하고, 실제 출시 검증에 필요한 기간과 작업 환경에 맞춰 Mac 이용 방식을 정하는 것이 합리적입니다.

추가 읽기