출시는 개발의 끝이 아니다
앱을 완성했다는 말은 코드가 더 이상 필요 없다는 뜻이 아니다. 사용자가 앱을 설치하고, 첫 화면을 열고, 핵심 기능을 문제없이 사용할 수 있어야 비로소 개발의 결과가 전달된다. 그래서 iOS 개발의 마지막 단계는 단순히 App Store에 올리는 일이 아니라 식별, 서명, 테스트, 심사, 출시 후 개선까지 포함한다.
이 장에서는 완성한 앱을 App Store에 등록하고, TestFlight로 검증하고, 심사를 통과한 뒤 운영하는 흐름을 정리한다. 처음에는 낯선 용어가 많지만 구조는 단순하다. Apple은 "이 앱이 누구의 앱인지", "어떤 권한으로 실행되는지", "사용자에게 안전한지", "설명한 기능이 실제로 동작하는지"를 확인한다.
AI 생성 이미지
앱의 신원을 정하는 Bundle Identifier
iOS 앱은 이름만으로 구분되지 않는다. 같은 이름의 앱은 여러 개 있을 수 있지만, Bundle Identifier는 앱을 고유하게 구분한다. 예를 들어 com.example.dailymemo 같은 형식이다.
Bundle Identifier는 여러 곳에 연결된다.
Xcode 프로젝트의 Signing & Capabilities 설정
Apple Developer 계정의 App ID
App Store Connect에 등록한 앱
Provisioning Profile
앱 업데이트 식별
한 번 App Store에 등록한 앱은 같은 Bundle Identifier를 유지해야 업데이트할 수 있다. 앱 이름이나 아이콘은 바꿀 수 있지만, Bundle Identifier는 앱의 내부 신분증에 가깝다. 따라서 연습용 프로젝트라면 가볍게 정해도 되지만, 실제 출시 앱이라면 회사 도메인이나 개인 도메인을 바탕으로 신중하게 정하는 것이 좋다.
Signing과 Provisioning Profile 이해하기
iPhone은 아무 앱이나 실행하지 않는다. 앱이 신뢰할 수 있는 개발자에게서 만들어졌고, 실행 권한이 있는지 확인한다. 이때 등장하는 개념이 Signing Certificate와 Provisioning Profile이다.
Signing Certificate는 앱에 붙는 디지털 서명이다. 쉽게 말해 "이 앱은 이 개발자 계정에서 만든 앱입니다"라고 증명하는 도장이다.
Provisioning Profile은 앱, 인증서, 실행 대상, 권한을 연결하는 허가서다. 개발 중에는 특정 기기에서 실행할 수 있도록 하고, 배포 단계에서는 App Store 배포가 가능하도록 연결한다.
초보자는 보통 Xcode의 Automatically manage signing을 켜고 진행한다. 그러면 Xcode가 필요한 인증서와 프로파일을 자동으로 관리해 준다. 문제가 생겼을 때는 다음 항목을 먼저 확인한다.
Xcode의 Team이 올바른 Apple Developer 계정인지
Bundle Identifier가 App Store Connect에 등록한 앱과 같은지
필요한 Capability가 Xcode와 Apple Developer 계정 양쪽에 설정되어 있는지
개발용 빌드와 배포용 빌드를 혼동하지 않았는지
서명 문제는 오류 메시지가 길고 복잡해 보인다. 하지만 대부분은 "앱 ID, 계정, 인증서, 권한 중 하나가 서로 맞지 않는 상황"이다.
업로드 전 개발 환경 기준 확인하기
App Store에 앱을 올릴 때는 현재 Apple이 요구하는 빌드 기준을 확인해야 한다. 2026년 5월 기준으로 Apple은 App Store Connect에 업로드하는 앱이 최신 SDK 기준을 충족하도록 요구하고 있으며, 2026년 4월 28일부터 iOS와 iPadOS 앱은 iOS 및 iPadOS 26 SDK 이상으로 빌드되어야 한다고 안내하고 있다1.
따라서 배포 직전에는 다음을 확인한다.
Xcode가 최신 배포 기준을 만족하는지
앱의 Deployment Target이 의도한 최소 지원 버전인지
사용 중인 라이브러리가 최신 Xcode에서 정상 빌드되는지
실제 기기에서 최신 iOS로 테스트했는지
여기서 SDK와 Deployment Target은 다르다. SDK는 앱을 빌드할 때 사용하는 개발 도구의 기준이고, Deployment Target은 앱이 실행될 수 있는 최소 iOS 버전이다. 예를 들어 최신 SDK로 빌드하더라도, 앱은 더 낮은 iOS 버전을 지원하도록 설정할 수 있다. 단, 사용하는 API가 해당 버전에서 동작하는지는 별도로 확인해야 한다.
Release Archive 만들기
App Store 제출용 빌드는 평소 시뮬레이터에서 실행하던 Debug 빌드와 다르다. 배포용으로 최적화된 Release Archive를 만들어야 한다.
일반적인 흐름은 다음과 같다.
Xcode에서 실행 대상을 실제 기기 또는 Any iOS Device로 선택한다.
상단 메뉴에서 Product > Archive를 실행한다.
Organizer 창에서 생성된 Archive를 확인한다.
Validate App으로 기본 검사를 진행한다.
Distribute App을 선택해 App Store Connect로 업로드한다.
Archive 전에 반드시 Version과 Build 번호를 확인한다. Version은 사용자에게 보이는 앱 버전이다. 예를 들어 1.0.0이다. Build는 내부 빌드 번호다. 같은 Version이라도 App Store Connect에 다시 업로드하려면 Build 번호는 증가해야 한다.
배포 직전에는 Debug 전용 코드도 점검한다. 테스트 서버 주소, 임시 버튼, 개발자용 로그 화면, 샘플 데이터, placeholder 문구가 남아 있으면 심사에서 문제가 될 수 있다. 특히 로그인, 결제, 서버 연동이 있는 앱은 실제 운영 환경에서 동작해야 한다.
TestFlight로 실제 사용 흐름 검증하기
앱을 바로 심사에 제출하기 전에 TestFlight를 사용해 테스트하는 것이 좋다. TestFlight는 App Store 출시 전 빌드를 내부 또는 외부 테스터에게 배포하는 Apple의 베타 테스트 도구다.
내부 테스트는 팀 구성원에게 빠르게 배포할 때 유용하다. 외부 테스트는 실제 사용자와 비슷한 환경에서 더 넓게 검증할 때 사용한다. 외부 테스터에게 배포하는 경우에는 Apple의 간단한 베타 앱 검토를 거칠 수 있다.
TestFlight에서 확인해야 할 항목은 명확하다.
첫 실행 화면이 정상적으로 표시되는가
회원가입과 로그인이 실패 없이 진행되는가
네트워크가 느리거나 끊겼을 때 앱이 멈추지 않는가
핵심 기능을 반복 사용해도 크래시가 없는가
다크 모드, 작은 화면, 큰 화면에서 UI가 깨지지 않는가
앱 삭제 후 재설치했을 때 데이터 흐름이 의도와 맞는가
권한 요청 문구가 사용자가 이해할 수 있게 작성되어 있는가
TestFlight는 단순히 "설치가 되는지" 확인하는 도구가 아니다. 심사 전에 실제 기기에서 앱의 약점을 찾는 마지막 안전망이다.
App Store Connect에 준비할 정보
App Store Connect는 앱의 등록, 빌드 관리, 심사 제출, 출시 후 지표 확인을 담당하는 웹 서비스다. 앱을 제출하려면 제품 페이지에 필요한 정보를 채워야 한다. Apple은 앱 이름, 아이콘, 설명, 스크린샷, 앱 미리보기, 키워드, 개인정보 처리 항목 등을 준비하라고 안내한다1.
기본적으로 다음 항목을 점검한다.
앱 이름과 부제
앱 설명과 홍보 문구
카테고리
가격과 배포 국가
앱 아이콘
iPhone 및 iPad용 스크린샷
키워드
지원 URL
개인정보 처리방침 URL
연령 등급
앱 개인정보 항목
심사용 연락처
심사용 테스트 계정
특별 설정이나 심사 안내 메모
스크린샷은 예쁘기만 해서는 부족하다. 사용자가 앱으로 무엇을 할 수 있는지 보여 주어야 한다. 단순한 시작 화면, 로고 화면, 로그인 화면만 올리면 앱의 가치를 설명하기 어렵다.
개인정보 항목도 가볍게 보면 안 된다. 앱이 직접 수집하는 데이터뿐 아니라 광고 SDK, 분석 SDK, 로그인 SDK 같은 제3자 코드가 수집하는 데이터도 확인해야 한다. Apple은 앱에 통합한 제3자 파트너의 개인정보 처리 방식까지 App Store Connect에 입력해야 한다고 안내한다1.
심사에서 자주 문제가 되는 부분
App Review Guidelines는 크게 Safety, Performance, Business, Design, Legal 영역으로 구성되어 있다2. 초보 개발자가 가장 자주 부딪히는 부분은 Performance의 "앱 완성도"와 Metadata의 "설명 정확성"이다.
심사에 제출하는 앱은 완성된 상태여야 한다. 베타 버전, 데모 버전, 임시 콘텐츠가 남아 있는 앱은 App Store가 아니라 TestFlight에서 테스트해야 한다. placeholder 텍스트, 빈 웹사이트, 숨겨진 기능, 문서화되지 않은 기능도 거절 사유가 될 수 있다2.
특히 다음 항목은 제출 전에 반드시 확인한다.
앱이 실행 직후 크래시 나지 않는가
모든 링크가 실제로 열리는가
로그인 기능이 있다면 심사자가 사용할 수 있는 계정을 제공했는가
서버가 심사 기간 동안 접근 가능한가
앱 설명과 실제 기능이 일치하는가
스크린샷이 실제 앱 화면을 보여 주는가
결제 기능이 있다면 어떤 항목이 유료인지 명확한가
개인정보 처리방침이 실제 데이터 수집 방식과 일치하는가
권한 요청 이유가 Info.plist 문구에 명확히 적혀 있는가
앱이 사용자 생성 콘텐츠를 다룬다면 신고, 차단, 부적절한 콘텐츠 필터링 같은 안전 장치가 필요하다. 의료, 금융, 도박, VPN, 아동 대상 앱처럼 규제가 강한 분야는 추가 문서나 자격 증명이 필요할 수 있다.
심사용 계정과 Review Notes 작성하기
심사자는 앱을 실제로 사용해 본다. 그래서 로그인 뒤에 핵심 기능이 있다면 테스트 계정을 제공해야 한다. Apple은 특정 설정, 계정 정보, 특별 지침이 필요한 경우 App Store Connect의 App Review Information에 제공하라고 안내한다3.
Review Notes에는 다음처럼 심사자가 막히지 않도록 필요한 정보를 적는다.
테스트 계정 아이디와 비밀번호
관리자 권한이 필요한 경우 사용 방법
특정 기능에 도달하는 경로
테스트용 결제나 샘플 데이터 사용 방법
외부 하드웨어나 특수 환경이 필요한 경우 설명
심사 중 서버 접근이 가능한 시간이나 조건
설명은 짧아도 된다. 하지만 심사자가 기능을 찾지 못해 "동작하지 않는다"고 판단하지 않도록 해야 한다. 앱 안에서 바로 보이지 않는 기능이 있다면 반드시 Review Notes에 적는다.
거절되었을 때 대응하기
앱이 한 번에 승인되지 않는 일은 흔하다. 거절 자체보다 중요한 것은 사유를 정확히 읽고 대응하는 것이다.
심사를 통과하지 못하면 App Store Connect에서 어떤 가이드라인을 충족하지 못했는지 확인할 수 있다. Apple은 App Review와의 커뮤니케이션을 통해 문제를 해결한 뒤 다시 제출할 수 있다고 안내한다3. 실무에서는 App Review 페이지나 Resolution Center에서 메시지를 확인하고 답변한다.
대응 방식은 크게 두 가지다.
첫째, 앱을 수정해야 하는 경우다. 크래시, 로그인 불가, 잘못된 권한 문구, 누락된 개인정보 처리방침처럼 실제 문제가 있다면 코드를 수정하고 새 Build 번호로 Archive를 다시 업로드한다. 그런 다음 수정한 빌드를 선택해 재심사를 요청한다.
둘째, 설명이 부족한 경우다. 심사자가 기능을 찾지 못했거나, 특정 동작의 의도를 오해했을 수 있다. 이때는 Review Notes나 답변 메시지에 기능 접근 경로, 테스트 계정, 정책 준수 근거를 명확히 적는다. 감정적으로 대응하기보다 "어떤 항목을 어떻게 수정했는지" 또는 "왜 이 기능이 가이드라인을 충족하는지"를 짧고 구체적으로 설명하는 편이 좋다.
출시 후 바로 봐야 할 것들
승인 후 앱을 출시하면 이제 사용자의 실제 환경이 시작된다. 개발 중에는 발견하지 못한 문제가 나타날 수 있다. 특정 기기, 특정 iOS 버전, 느린 네트워크, 오래된 계정 데이터에서만 발생하는 버그도 있다.
출시 직후에는 다음을 모니터링한다.
크래시 리포트
App Store 리뷰와 별점
사용자 문의 메일
서버 오류와 트래픽
로그인 실패율
결제 실패나 복원 문제
첫 실행 후 이탈 지점
TestFlight 후속 빌드 피드백
문제가 심각하면 기능 추가보다 안정화 패치를 먼저 배포한다. 예를 들어 앱 실행 크래시, 로그인 불가, 데이터 손실, 결제 오류는 최우선이다. 반대로 버튼 색상 변경이나 작은 문구 개선은 다음 정기 업데이트로 묶어도 된다.
업데이트를 낼 때는 Version과 Build 번호를 올리고, 변경 사항을 명확히 기록한다. 사용자가 읽는 릴리스 노트에는 "버그 수정"만 반복하기보다 "로그인 실패 문제를 수정했습니다", "메모 목록 스크롤 성능을 개선했습니다"처럼 이해 가능한 문장을 쓰는 것이 좋다.
Apple 업데이트를 계속 확인하기
출시 후 운영에서는 Apple 생태계의 변화도 따라가야 한다. Xcode, iOS, TestFlight, App Store Connect는 계속 업데이트된다. Apple Developer Releases 페이지에는 Xcode, iOS, TestFlight, App Store Connect 관련 업데이트가 날짜별로 올라온다4.
이 정보는 유지보수에 중요하다. 새 Xcode에서 빌드 오류가 생길 수 있고, 새 iOS에서 UI 동작이 달라질 수 있으며, App Store Connect의 제출 요구 사항이 바뀔 수도 있다. 특히 다음 업데이트를 준비할 때는 공식 릴리스 정보를 확인하는 습관이 필요하다.
운영 중인 앱은 "한 번 올리고 끝나는 파일"이 아니다. 사용자의 기기와 운영체제, Apple의 정책, 서버 환경, 개인정보 요구 사항이 계속 변한다. 좋은 앱은 이 변화에 맞춰 작게, 자주, 안전하게 개선된다.
출시 전 최종 체크리스트
마지막으로 제출 전에 다음 목록을 한 번씩 확인하자.
Bundle Identifier가 App Store Connect 앱과 일치한다.
최신 Xcode와 최소 SDK 요구 사항을 확인했다.
Release Archive를 만들고 Validate를 통과했다.
Version과 Build 번호가 올바르다.
TestFlight에서 실제 기기 테스트를 완료했다.
로그인 테스트 계정을 준비했다.
앱 설명, 스크린샷, 키워드, 카테고리를 작성했다.
개인정보 처리방침과 앱 개인정보 항목을 확인했다.
지원 URL과 연락처가 유효하다.
placeholder 콘텐츠와 개발용 코드를 제거했다.
서버, 링크, 권한 요청, 핵심 기능이 모두 동작한다.
Review Notes에 필요한 설명을 적었다.
앱 출시는 목표 지점이면서 동시에 출발점이다. 처음 출시한 버전이 완벽할 필요는 없다. 하지만 사용자가 핵심 기능을 안정적으로 사용할 수 있어야 한다. 작게 출시하고, 정확히 관찰하고, 빠르게 고치는 과정이 iOS 앱을 실제 제품으로 성장시킨다.
참고
1Submit your apps and games today
2App Review Guidelines - Apple Developer
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.