App Store Connect

App Store Connect 는 개발자가 만든 앱을 Apple 의 앱 스토어에 내보내 줍니다. 앱을 올리고 심사를 신청하는 일을 웹 브라우저에서 합니다. 출시한 뒤에는 앱이 얼마나 팔렸는지도 여기서 봅니다.

상세

이 절은 App Store Connect 가 무엇을 맡는지부터 봅니다. 새 버전 하나가 올라가서 스토어에 나가기까지의 흐름을 따라갑니다. 이어서 출시 뒤에 보는 화면, 팀원에게 권한을 나누는 방법, 이 모든 일을 코드로 부르는 방법을 봅니다.

앱 스토어로 가는 창구

App Store Connect 는 Apple 이 운영하는 웹 서비스입니다. 따로 설치하지 않고 브라우저로 들어갑니다. iOS 가 도는 iPhone 앱이 주된 대상입니다. iPad, Mac, Apple Watch, Apple TV 앱도 같은 곳에서 다룹니다. 예전 이름은 iTunes Connect 였습니다.

앱 스토어에 앱을 올리는 길은 이 서비스를 거칩니다. 앱 스토어는 Apple 이 운영하는 앱 장터입니다. 올라가는 앱은 Apple 이 먼저 살펴봅니다.

그래서 개발자에게는 앱을 건네고, 살펴본 결과를 받고, 공개할 때를 정하는 곳이 필요합니다. App Store Connect 가 그 일을 맡습니다.

npm 과 견주면 차이가 보입니다. npm 은 자바스크립트 라이브러리를 올리고 받는 저장소입니다. npm 에는 명령 하나로 라이브러리를 올립니다. 올리는 즉시 누구나 받을 수 있습니다.

앱 스토어는 올린 것을 사람이 먼저 살펴봅니다. 공개 시점도 따로 정합니다. 올리는 일과 공개하는 일 사이에 단계가 여럿 끼어 있습니다. 그 단계가 전부 App Store Connect 안에 있습니다.

새 버전이 스토어에 가기까지

새 버전 하나는 몇 단계를 지나 스토어에 나갑니다. 단계마다 쓰는 도구와 절차가 따로 있어서, 그 이름부터 짚고 흐름을 봅니다.

이 이름들은 아래 순서로 이어집니다. 빌드를 올린 뒤 테스터가 먼저 써 봅니다. 그다음 스토어 등재정보를 채워 심사를 받습니다.

flowchart TD
    A["Xcode 에서 빌드를 올린다"] --> B["TestFlight 로 테스터가 써 본다"]
    B --> C["스토어 등재정보를 채워 심사를 신청한다"]
    C --> D{"앱 심사"}
    D -->|반려| E["고쳐서 다시 신청한다"]
    E --> D
    D -->|통과| F["출시 방식에 따라 스토어에 나간다"]

심사에서 반려되면 고쳐서 다시 신청합니다. 이 고리를 몇 번 돌 수도 있습니다. 각 단계는 뒤의 소절과 「맞물림」 절이 하나씩 풉니다.

앱 레코드

무엇을 올리기 전에 앱 레코드부터 만듭니다. 앱 레코드는 App Store Connect 안에서 앱 하나를 대표하는 항목입니다. 앱 이름과 기본 언어, 그리고 앱의 고유 이름을 적어 만듭니다.

그 고유 이름이 번들 ID(bundle identifier, 번들 식별자)입니다. 앱마다 겹치지 않습니다. com.example.shop 처럼 도메인을 뒤집어 씁니다. 자바 패키지 이름을 짓는 방식과 같습니다. 앱의 모든 버전과 설정이 이 이름으로 앱 레코드에 묶입니다.

앱 레코드 하나에 그 앱에 관한 것이 모두 모입니다.

이 표의 넷째 줄인 인앱 결제 상품은 아래 「출시 뒤에 보는 화면」 소절이 다시 다룹니다.

버전과 빌드

App Store Connect 는 버전과 빌드를 가릅니다. 버전은 사용자에게 보이는 번호입니다. 스토어에 「1.2.0」으로 뜨는 것이 버전입니다. 빌드는 소스 코드를 컴파일하고 서명해 만든 설치 파일 한 벌입니다. 빌드마다 빌드 번호가 붙습니다.

한 버전에 빌드를 여러 개 올릴 수 있습니다. 1.2.0 을 준비하면서 버그를 고칠 때마다 빌드를 새로 올리는 식입니다. 심사에 낼 때는 그중 빌드 하나를 고릅니다.

Xcode 프로젝트 설정에서는 이 둘을 Version 과 Build 두 칸에 따로 적습니다. 빌드를 다시 올렸는데 받아 주지 않으면 대개 빌드 번호를 새로 매기지 않은 것입니다.

심사 신청

빌드를 골랐으면 스토어 등재정보를 채웁니다. 앱 설명, 화면 사진, 연령 등급, 앱이 모으는 개인정보의 종류가 여기 들어갑니다. 다 채우면 심사에 제출합니다.

앱 심사에서 Apple 은 자기 지침에 비춰 앱을 살펴봅니다. 앱이 광고와 다르게 동작하지 않는지, 금지한 기능을 쓰지 않는지를 봅니다. 반려되면 이유가 App Store Connect 의 메시지로 옵니다. 개발자는 거기에 답장하거나 앱을 고쳐 다시 제출합니다.

앱 안에서 파는 상품도 심사를 받습니다. 새 인앱 결제 상품은 앱과 함께 또는 따로 제출합니다.

출시 방식

심사를 통과한 버전을 언제 내보낼지는 신청할 때 미리 고릅니다.

수동 출시는 서버 배포와 맞춰야 할 때 씁니다. 새 버전이 서버의 새 기능을 부른다면, 서버를 먼저 배포하고 나서 출시 버튼을 누릅니다.

업데이트 버전에는 단계적 출시를 더 걸 수 있습니다. 새 버전이 한꺼번에 모든 사용자에게 가지 않습니다. 7일에 걸쳐 자동 업데이트를 켠 사용자 일부부터 받습니다.

문제가 보이면 도중에 멈출 수 있습니다. 반대로 괜찮으면 남은 사용자 모두에게 바로 넓힐 수도 있습니다.

출시 뒤에 보는 화면

앱이 나간 뒤에도 App Store Connect 를 계속 씁니다. 판매 기록과 사용자 반응이 모두 여기 모입니다.

유료 앱이나 인앱 결제로 돈을 받으려면 준비가 더 있습니다. 먼저 Apple 과 유료 앱 계약을 맺습니다. 세금 정보와 은행 계좌도 App Store Connect 에 넣어야 합니다. 이것이 빠지면 앱을 무료로만 낼 수 있습니다.

인앱 결제 상품도 이 화면들 옆에서 만듭니다. 한 번 쓰고 사라지는 아이템, 한 번 사면 계속 쓰는 기능, 주기마다 자동으로 결제되는 구독을 상품으로 등록하고 가격을 정합니다.

사용자와 역할

한 팀이 App Store Connect 를 함께 씁니다. 팀원은 저마다 계정으로 들어옵니다. 계정마다 역할이 붙습니다. 역할은 그 사람이 볼 수 있는 화면과 할 수 있는 일을 정합니다.

재무 보고서와 은행 정보는 재무를 맡은 역할에게 열립니다. 빌드와 TestFlight 는 개발을 맡은 역할에게 열립니다. 팀 전체를 책임지는 계정 소유자는 한 명입니다. 계약에 동의하는 일은 이 사람이 합니다.

역할로 권한을 나누는 방식은 AWS IAM 같은 클라우드 권한 관리와 같은 모양입니다. 사람에게 일에 필요한 만큼만 권한을 주는 최소 권한 원칙이 여기서도 통합니다.

App Store Connect API

화면에서 하는 일 상당수는 코드로도 부를 수 있습니다. 그 인터페이스가 App Store Connect API(Application Programming Interface, 프로그램이 부르는 인터페이스)입니다. 빌드를 올릴 때마다 사람이 브라우저를 여는 대신 CI(Continuous Integration, 지속적 통합) 서버가 이 API 를 부릅니다.

이 API 는 REST(Representational State Transfer) 방식입니다. 흔한 웹 API 처럼 주소마다 자원이 하나씩 있습니다. 앱 목록을 받는 요청은 이렇게 생겼습니다.

GET https://api.appstoreconnect.apple.com/v1/apps
Authorization: Bearer <서명한 토큰>

요청 머리에 실은 토큰이 이 요청을 누가 보냈는지 증명합니다. 토큰은 JWT(JSON Web Token)입니다. JWT 는 서명이 붙은 짧은 문자열입니다. 받는 쪽은 서명을 보고 위조가 아닌지 확인합니다.

토큰에 서명하려면 App Store Connect 에서 API 키를 만듭니다. API 키를 만들면 그 키의 개인 키 파일을 한 번만 내려받을 수 있습니다. CI 서버는 이 개인 키로 짧게 쓰고 버릴 토큰에 서명해 요청마다 싣습니다.

개인 키를 손에 넣은 사람은 이 팀의 앱을 건드릴 수 있습니다. 그래서 개인 키 파일은 비밀번호처럼 비밀 저장소에 둡니다.

fastlane 같은 배포 자동화 도구가 이 API 를 감싸서 씁니다. 빌드 올리기, 테스터 추가, 심사 제출을 명령 한 줄로 부릅니다.

언제 거치고 언제 안 거치나

앱 스토어나 TestFlight 로 나가는 빌드는 모두 App Store Connect 를 지납니다. iPhone 앱을 일반 사용자에게 내는 팀이면 피할 수 없습니다. 개발 중인 앱을 개발자 자기 기기에 직접 까는 일은 이 서비스를 거치지 않습니다.

Android 앱은 이 서비스를 쓰지 않습니다. Google Play 에서 같은 일을 하는 서비스는 Google Play Console입니다. 하는 일이 거의 같습니다.

맞물림

App Store Connect 는 혼자 돌지 않습니다. 앞에는 Xcode 와 Apple 개발자 사이트가 붙습니다. 개발자 사이트는 앱의 신원을 등록하는 Apple 의 또 다른 웹 화면입니다. 뒤에는 TestFlight 앱과 앱 스토어가 붙습니다. 이 절은 그 넷이 App Store Connect 와 무엇을 주고받는지 봅니다.

flowchart TD
    D["Apple 개발자 사이트"] -->|번들 ID 와 인증서| A["App Store Connect"]
    X["Xcode"] -->|서명한 빌드| A
    A -->|테스트할 빌드| T["TestFlight 앱"]
    A -->|심사를 통과한 버전| S["앱 스토어"]

Apple 개발자 사이트가 번들 ID 와 인증서를 쥔다

앱을 스토어에 내려면 개발자 사이트부터 씁니다. 번들 ID 와 인증서처럼 앱의 신원을 만드는 일이 여기 모여 있습니다. 이 사이트를 쓰려면 Apple 의 유료 개발자 프로그램에 먼저 가입합니다.

개발자 사이트에서는 번들 ID 를 등록하고 배포용 인증서를 만듭니다. 인증서는 이 팀이 누구인지를 Apple 이 보증해 주는 전자 문서입니다. 이 인증서가 있어야 빌드가 이 팀이 만든 것임을 밝힐 수 있습니다.

Xcode 는 이 인증서로 빌드에 코드 서명을 합니다. 코드 서명은 누가 만들었고 그 뒤로 바뀌지 않았다는 것을 증명하는 서명입니다.

App Store Connect 는 앱 레코드를 만들 때 개발자 사이트에 등록된 번들 ID 가운데 하나를 고릅니다. 올라온 빌드는 번들 ID 가 이 레코드와 같아야 받아 줍니다. 빌드의 서명도 이 팀의 배포용 인증서로 한 것이어야 합니다.

신원은 되돌리기 어렵습니다. 빌드를 한 번 올린 앱 레코드는 번들 ID 를 바꾸지 못합니다. 인증서에는 기한이 있습니다. 만료되면 새로 만들고 서명을 다시 해야 합니다.

Xcode 가 빌드를 올린다

Xcode 에서 앱을 배포용으로 묶는 일을 아카이브라고 합니다. 아카이브를 만들고 App Store Connect 로 배포를 고르면 Xcode 가 서명해서 올립니다. CI 서버에서는 Xcode 의 명령줄 도구로 빌드합니다. 올리는 일은 Apple 의 업로드 도구 Transporter 나 App Store Connect API 가 합니다.

올라간 빌드는 바로 보이지 않습니다. App Store Connect 가 빌드를 받아 처리하는 동안 기다려야 목록에 뜹니다. 그 뒤에야 테스터에게 보내거나 심사에 낼 수 있습니다. 같은 빌드 번호는 다시 올리지 못합니다. 그래서 올릴 때마다 빌드 번호를 1 늘리는 일이 빌드 스크립트에 들어갑니다.

App Store Connect 가 TestFlight 앱에 빌드를 보낸다

처리가 끝난 빌드는 TestFlight 로 나눠 줄 수 있습니다. 테스터는 자기 iPhone 에 TestFlight 앱을 깝니다. 그 앱으로 테스트할 빌드를 받습니다. 보내는 쪽은 App Store Connect 입니다. 받는 쪽은 TestFlight 앱입니다.

테스터는 두 무리로 갈립니다. 내부 테스터는 App Store Connect 에 계정이 있는 팀원입니다. 빌드가 처리되면 바로 받습니다.

외부 테스터는 이메일이나 공개 링크로 초대한 바깥 사람입니다. 외부 테스터에게 보내는 빌드는 Apple 의 베타 심사를 먼저 거칩니다. 베타 심사는 바깥 사람에게 나눠 줘도 되는지 Apple 이 살펴보는 일입니다. 스토어에 내기 전의 앱 심사와는 따로 받습니다.

테스터가 TestFlight 앱에서 남긴 의견과 화면 사진은 App Store Connect 로 돌아옵니다. 앱이 죽었을 때의 기록도 함께 모입니다. TestFlight 빌드에도 기한이 있습니다. 일정 기간이 지나면 테스터 기기에서 더 실행되지 않습니다.

App Store Connect 가 앱 스토어에 버전을 내보낸다

심사를 통과한 버전은 고른 출시 방식에 따라 앱 스토어에 나갑니다. 스토어 화면에 뜨는 설명과 화면 사진은 App Store Connect 에 적은 스토어 등재정보입니다. 사용자가 스토어에서 내려받는 앱은 개발자가 심사에 낸 바로 그 빌드입니다.

스토어 화면을 고치는 일도 버전에 묶입니다. 앱 설명 대부분은 새 버전을 낼 때만 고칠 수 있습니다. 고친 설명은 새 버전과 함께 심사를 받습니다. 언제든 바꿀 수 있는 짧은 홍보 문구 칸은 따로 있습니다. 급한 안내는 거기에 적습니다.

Android 쪽도 얼개가 같습니다. Android 개발 도구 Android Studio 가 빌드를 만듭니다. Google Play Console 이 그 빌드를 받아 테스터에게 먼저 나눠 줍니다. 그다음 스토어로 내보냅니다.

관련 항목

App Store Connect 가 속하는 상위 분류

앱 스토어 · 모바일 개발 · 배포 · 릴리스 관리 · 서비스형 소프트웨어

App Store Connect 로 앱이 나가는 운영체제

iOS · iPadOS · macOS · watchOS · tvOS · visionOS

App Store Connect 와 맞물리는 Apple 도구

Apple · Xcode · TestFlight · Transporter · Apple Developer Program · SwiftUI

App Store Connect 에 올리기 전에 거치는 서명 단계

코드 서명 · 번들 ID · 인증서 · 프로비저닝 프로파일 · 개발자 계정 · 개인 키

App Store Connect 가 관리하는 출시 단계

빌드 · 베타 테스트 · 앱 심사 · 단계적 출시 · 자동 업데이트 · 시맨틱 버저닝

App Store Connect 에서 파는 상품과 정산 항목

인앱 결제 · 구독 · 프로모션 코드 · 스토어 등재정보 · 앱 분석

App Store Connect 계정에 적용되는 접근 규칙

역할 기반 접근 제어 · 최소 권한 원칙 · API 키 · 2단계 인증

App Store Connect 를 자동화하는 인터페이스와 도구

App Store Connect API · REST API · JWT · fastlane · 지속적 통합 · 지속적 배포

App Store Connect 에 대응하는 다른 플랫폼의 배포 창구

Google Play Console · Firebase App Distribution · Microsoft Partner Center · Steamworks · npm