TestFlight란? 첫 초대부터 설치 완료까지, 초보자를 위한 전체 가이드

확인 기준일: 2026년 9월 17일. 이 글은 iPhone과 iPad를 중심으로 설명합니다. Apple의 화면과 규정은 바뀔 수 있으므로, 본문에 링크된 공식 안내와 실제로 표시되는 화면을 기준으로 확인하세요.

앱을 만들었고 친구들에게 먼저 사용해 보라고 하고 싶지만, 아직 App Store에 정식으로 출시할 준비는 되지 않았습니다. 소스 코드를 그대로 보낼 수도 없고, 설치 파일을 보내더라도 상대방이 설치할 수 있다는 보장은 없습니다.

바로 이런 문제를 해결하는 도구가 TestFlight입니다.

흔히 말하는 “TF”는 대개 TestFlight의 줄임말입니다. Apple이 제공하는 테스트 배포 서비스로, 개발자가 베타 버전을 업로드하고 다른 사람을 초대해 설치하도록 한 뒤 피드백을 받아 개선된 버전을 다시 배포할 수 있습니다. 테스터가 설치하는 것은 스크린샷이나 웹 데모가 아니라, 기기에서 실제로 실행되는 앱입니다.[1][2]

먼저 다음 3가지를 기억하세요.

• 내부 테스트는 적절한 App Store Connect 권한이 있는 구성원을 대상으로 합니다.
• 외부 테스트는 친구, 고객, 커뮤니티 사용자에게 적합하며, 이들에게 개발자 관리 시스템의 권한을 줄 필요가 없습니다.
• 각 빌드는 업로드한 날부터 최대 90일 동안 테스트할 수 있습니다. 테스트 심사를 통과했다고 해서 정식 출시된 것은 아닙니다.[1][3]

다른 사람이 보낸 링크를 받았을 뿐이라면 9절 “테스터는 어떻게 설치하고, 업데이트하고, 피드백을 보내고, 테스트를 그만두나요?”부터 읽어도 됩니다. 자신의 앱을 다른 사람에게 배포하려면 처음부터 읽어 보세요.

1. TestFlight, App Store Connect, App Store는 각각 무엇인가요?

새 앱을 시범 운영 중인 가게라고 생각해 보세요. TestFlight는 사람들을 초대해 체험하게 하는 도구이고, App Store는 정식으로 문을 열고 영업하는 유통 경로입니다. 시범 운영에도 기한과 규칙이 있으며, 심사를 우회하는 뒷문은 아닙니다.

이름은 비슷해 보여도 하는 일은 서로 다릅니다.

표가 넓으면 좌우로 스크롤할 수 있습니다. 키보드 사용자는 표에 초점을 맞춘 뒤 방향키를 사용하세요.

App Store에서 다운로드하는 것은 TestFlight라는 도구이고, 그 도구를 통해 초대받은 테스트 앱을 설치하는 것입니다. 어떤 앱이 TestFlight에 있다고 해서 App Store에서도 검색된다는 뜻은 아닙니다.[1][3]

Apple은 이를 통해 “버전 배포—테스트 초대—문제 수집—버전 업데이트”를 하나로 연결합니다. 현재 TestFlight에서는 개발자가 테스터의 기기 식별자를 일일이 수집하거나, 테스터마다 별도의 설치 프로파일을 만들 필요가 없습니다.[2]

하지만 TestFlight가 앱을 대신 만들어 주거나 모든 기능이 올바르다고 보증하는 것은 아니며, 베타 버전을 자동으로 정식 버전으로 바꿔 주지도 않습니다. 테스트 심사를 거쳤더라도 앱에 결함이 없거나 데이터가 손실되지 않는다고 보장할 수는 없습니다. 잘 모르는 앱을 테스트할 때는 중요한 자료의 유일한 사본을 위험에 노출하지 마세요.

2. TestFlight의 역사: 처음부터 Apple이 만든 서비스는 아닙니다

역사를 알면 오래된 가이드에 나오는 이름, 인원수, 사용 방법이 왜 다른지 이해할 수 있습니다.

• 2011년 1월: 타사 서비스로 공개 출시. 당시 미출시 iPhone 앱을 테스트하려면 기기 식별자, 설치 파일, 프로파일을 처리한 뒤 컴퓨터의 iTunes로 동기화해야 하는 경우가 많았습니다. TestFlight는 무선 설치를 훨씬 편리하게 만들었습니다. 여기서 말하는 시점은 비공개 테스트에서 공개 서비스로 전환한 때이며, 회사의 법인 설립일은 아닙니다.[H1]
• 2012년 3월: Burstly에 인수되었다는 소식 발표. 이때도 TestFlight는 타사 제품이었습니다.[H2]
• 2014년 2월: Apple이 Burstly 인수. TestFlight도 모회사와 함께 Apple에 합류했습니다.[H3]
• 2014년 10월: Apple이 iTunes Connect를 통한 이메일 테스트 초대 기능 공개. iTunes Connect는 오늘날 App Store Connect의 전신이며, 당시에는 최대 1,000명을 초대할 수 있었습니다. 과거의 수치라는 점에 유의하세요.[H4]
• 2017년 7월: 초대 가능한 외부 테스터 수가 10,000명으로 확대.[H5]
• 2018년 9월: Apple이 공개 초대 링크 도입. 개발자는 이메일 주소를 먼저 일일이 수집하지 않고도 링크를 공유해 테스터를 모집할 수 있게 되었습니다.[H6]

현재는 iPhone, iPad, Mac, Apple Watch, Apple TV, Apple Vision Pro 등 여러 Apple 플랫폼을 지원합니다. 이 글에서 iPhone을 예로 든다고 해서 iPhone 앱만 테스트할 수 있다는 뜻도, Android 앱을 배포할 수 있다는 뜻도 아닙니다.[2][3]

3. 먼저 알아둘 5가지 용어: 베타 버전, 버전, 빌드, 그룹, 심사

베타 버전(Beta): 아직 검증하고 개선하는 단계의 앱 버전으로, 문제가 있을 수 있습니다.

버전(Version): 1.0, 1.1처럼 대외적으로 구분하는 한 차례의 버전을 나타냅니다.

빌드(Build): 특정 시점에 패키징한 앱 한 개를 뜻합니다. 예를 들어 1.0(12)는 버전 1.0, 빌드 번호 12라는 의미입니다. 문제를 고친 뒤 1.0(13)을 업로드할 수 있습니다. 대외적인 버전은 같지만 설치되는 내용은 달라진 것입니다.[7]

그룹(Group): 누가 어떤 빌드를 받을 수 있는지 결정합니다. “팀”과 “얼리 액세스”라는 그룹을 만들어 같거나 다른 빌드를 배정할 수 있습니다. 한 그룹에 여러 빌드를 넣을 수 있고, 하나의 일반 빌드를 여러 그룹에 배정할 수도 있습니다.[2][5][6]

테스트 심사(TestFlight App Review): 외부 테스트를 위한 Apple의 심사로, 정식 App Store 출시 심사와는 다릅니다.[1][6]

이 관계를 기억하면 헷갈리지 않습니다. 앱은 전체 프로젝트이고, 빌드는 그중 특정한 설치 내용 한 개이며, 그룹은 누가 사용해 볼 수 있는지를 결정합니다. 공개 초대 링크는 외부 그룹에 속하며, 특정 빌드 하나에 영구적으로 고정되는 것이 아닙니다.

4. 시작하기 전에 배포자와 테스터는 각각 무엇을 준비해야 하나요?

배포자가 준비할 것

1. 유효한 Apple Developer Program 멤버십. Apple의 현재 표준 가격은 연간 99달러이며, 지역별 가격이 다를 수 있고 일부 자격을 갖춘 기관은 비용 면제를 신청할 수 있습니다. TestFlight는 해당 멤버십 서비스에 포함되므로 테스터용 구독을 따로 구입하는 것이 아닙니다.[4]
2. 올바른 App Store Connect 앱 기록. 앱 식별자, 서명, 업로드 내용이 서로 일치해야 하며, 다른 앱의 설치 파일을 임의로 추가할 수는 없습니다.[7]
3. 충분하되 과도하지 않은 계정 권한. 계정 소유자, 관리자, 앱 관리자 또는 개발자 역할은 빌드를 업로드할 수 있습니다. 외부 테스트 관리에는 계정 소유자, 관리자 또는 앱 관리자 역할이 필요합니다. 업로드할 수 있다고 해서 외부 테스트의 모든 설정을 다룰 수 있는 것은 아닙니다.[6][7]
4. 테스트 정보. 앱 설명, 피드백 이메일 주소, 테스트할 내용을 포함합니다. 외부 심사에는 연락처와 심사 담당자가 실제로 로그인하거나 기능에 접근할 수 있는 방법도 필요합니다.[6][8]
5. 테스트 가능한 기기와 시간. 업로드에 성공했다고 해서 설치와 주요 기능을 모두 검증한 것은 아닙니다.

친구에게 자신의 Apple 암호를 보내지 마세요. 다른 사람에게 앱을 테스트하게 하려면 관리 계정을 공유하는 대신 초대를 보내야 합니다.

일반 테스터가 준비할 것

Apple 계정, 호환 기기, TestFlight, 유효한 초대만 있으면 됩니다. 유료 개발자 프로그램에 가입하거나 개발자 관리 시스템에 들어갈 필요는 없습니다.[1][3]

이 글의 확인 기준일 현재 Apple의 테스터 도움말에 나온 iPhone과 iPad의 요구 사항은 iOS 16, iPadOS 16 이상입니다. 다만 개별 앱은 더 최신 운영체제를 요구할 수 있으며, 공개 초대에서도 기기와 운영체제 버전으로 대상을 제한할 수 있습니다. TestFlight를 설치할 수 있다고 해서 그 안의 모든 앱을 설치할 수 있는 것은 아닙니다.[3][6]

직장이나 학교에서 제공하는 관리형 Apple 계정을 사용한다면 자격 조건을 특히 확인해야 합니다. Apple의 외부 테스트 도움말에는 이러한 계정으로 빌드를 테스트할 수 없다고 명시되어 있습니다. 내부 테스트 도움말에는 별도로, 예약된 도메인에서 생성한 관리형 계정은 테스트에 사용할 수 없다고 명시되어 있습니다. 이런 경우에는 해당 도움말과 조직 정책을 확인해야 하며, 초대 링크 오류로 생각하지 마세요.[5][6]

5. 내부 테스트와 외부 테스트는 정확히 어떻게 다른가요?

가장 중요한 차이는 관리 시스템에서의 신분과 권한입니다. 상대방과 얼마나 친한지, 초대를 이메일로 보냈는지로 나뉘는 것이 아닙니다.

표가 넓으면 좌우로 스크롤할 수 있습니다. 키보드 사용자는 표에 초점을 맞춘 뒤 방향키를 사용하세요.

내부 테스터가 될 수 있는 역할에는 계정 소유자(Account Holder), 관리자(Admin), 앱 관리자(App Manager), 개발자(Developer), 마케팅(Marketing)이 포함되며, 해당 앱에 대한 접근 권한도 있어야 합니다.[2][5]

친구 한 명을 이메일로 비공개 초대하더라도, 보통은 외부 테스트를 선택해야 합니다. 외부라는 말이 공개라는 뜻은 아닙니다. 공개 링크를 켜지 않고 몇 명만 초대해도 됩니다.

심사 절차를 하나 줄이겠다는 이유로 일반 테스터에게 관리자 권한을 주지 마세요. 그것은 단순히 설치를 허용하는 스위치가 아니라 실제 관리 권한입니다.

놓치기 쉬운 제한이 하나 더 있습니다. 개인 개발자 계정에는 App Store Connect 사용자를 최대 50명까지 추가할 수 있습니다. 따라서 TestFlight의 “내부 테스터 100명”이라는 상한이 모든 개인 계정에서 관리 구성원 100명을 추가로 만들 수 있다는 뜻은 아닙니다.[9]

6. 빌드는 어떻게 추가하나요? “업로드”와 “테스트 그룹에 추가”를 구분하세요

실제로는 서로 다른 2가지 작업입니다.

• 빌드 업로드: 이미 패키징한 앱을 개발 또는 빌드 도구에서 Apple로 전달하는 작업입니다.
• 그룹에 빌드 추가: 업로드되어 사용 가능한 빌드 중 하나를 골라 해당 그룹에 배포하는 작업입니다.

App Store Connect 테스트 그룹의 “빌드 추가(Add Builds)”는 소스 코드를 끌어다 놓으면 자동으로 앱이 만들어지는 기능도, 로컬 파일을 업로드하는 버튼도 아닙니다.[5][6][7]

처음 배포하는데 관리 시스템에 아직 앱이 없다면?

계정 소유자, 관리자 또는 앱 관리자 역할로 앱(Apps) → “+” → 신규 앱(New App)에 들어갑니다. 플랫폼을 선택하고 앱 이름, 기본 언어, 앱 식별자(Bundle ID), 관리용 SKU 등 필수 정보를 입력한 다음, 구성원의 접근 범위를 설정하고 생성합니다. 앱 식별자는 프로젝트와 일치해야 합니다. 어떤 식별자를 써야 하는지 아직 모르겠다면 먼저 패키징 담당자에게 확인하고, 다른 앱의 식별자를 임의로 선택하지 마세요.

생성할 수 없다면 계정 소유자가 최신 계약에 동의했는지 확인하세요. 앱 기록을 만드는 것은 관리할 공간을 마련하는 것일 뿐, 업로드나 출시가 완료된 것은 아닙니다.[15]

Xcode로 업로드하는 기본 절차

이미 iOS 프로젝트가 있다면 다음 순서로 진행할 수 있습니다.

1. 앱 식별자와 서명 팀이 App Store Connect의 앱 기록과 일치하는지 확인합니다.
2. 이번 업로드에 중복되지 않는 빌드 번호를 설정합니다. 예를 들어 1.0(12)에서 1.0(13)으로 올립니다.
3. 실제 기기 배포용 대상을 선택하고 Product → Archive를 눌러 아카이브를 생성합니다. 시뮬레이터용 버전을 업로드하는 것이 아닙니다.
4. Window → Organizer → Archives에서 아카이브를 선택하고 Distribute App을 누릅니다. 일반적인 TestFlight 배포와 이후 정식 출시를 위해서는 TestFlight & App Store를 선택합니다. 사용자화된 절차에서는 App Store Connect 배포에 해당합니다. 화면 안내에 따라 서명과 업로드를 완료합니다.[16]
5. 업로드 후 App Store Connect → 앱(Apps) → 내 앱 → TestFlight에서 확인합니다.
6. Apple의 처리를 기다립니다. 수출 규정 준수에 관한 질문이 나오면 앱이 실제로 사용하는 암호화를 기준으로 정확하게 답해야 합니다. 진행하기 위해 무조건 “암호화를 사용하지 않음”을 선택해서는 안 됩니다.
7. 처리가 완료되어 빌드를 사용할 수 있게 되면 내부 또는 외부 테스트 그룹에 추가합니다.

Xcode Cloud, Transporter 등의 도구로도 업로드할 수 있습니다. 도구가 다르다고 해서 Apple의 처리, 규정 준수, 그룹 설정, 외부 심사 절차를 생략할 수 있는 것은 아닙니다.[7] 업로드 도구와 SDK의 최소 요구 사항은 바뀔 수 있으므로 작업할 때 Apple의 현재 업로드 요구 사항을 확인하세요. 빌드에 사용한 SDK 버전과 앱을 설치할 수 있는 최소 운영체제 버전은 다릅니다.[18]

“내부 테스트 전용” 옵션에 주의하세요

TestFlight Internal Only는 업로드 방식에 따라 생기는 제한입니다. 이러한 빌드는 내부 그룹에만 추가할 수 있으며, 외부 테스트나 정식 사용자 대상 출시에 사용할 수 없습니다. 나중에 외부 테스트나 정식 출시가 필요하다면 적절한 방식으로 새 빌드를 업로드해야 하며, 기존 빌드의 그룹만 바꾸는 것으로는 해결되지 않습니다.[5][6]

반대로 일반 빌드를 먼저 내부 그룹에 추가했다고 해서 자동으로 “내부 테스트 전용” 빌드가 되는 것은 아닙니다. “지금은 내부 구성원이 사용해 본다”는 것과 “이 업로드는 내부용으로만 제한되어 있다”는 것을 혼동하지 마세요.

AirBuild에서 앱을 개발하고 있다면

AirBuild의 도움을 받아 배포 가능한 빌드 준비, 서명, 업로드, 테스트 그룹 및 초대 설정을 진행할 수 있습니다. 먼저 “TestFlight로 배포”하려는 것인지, 대상이 팀 구성원인지 외부 친구인지 명확하게 알려 주세요. 그런 다음 권한이 있는 Apple 개발자 팀을 연결하거나 확인하고, 테스트 설명, 피드백 이메일, 심사 연락처, 공개 링크 사용 여부를 확인합니다.

Apple의 처리, 외부 심사, 인원 및 유효 기간 규칙은 그대로 적용됩니다. 작업 결과를 전달받을 때는 정확한 버전과 빌드 번호, 어느 그룹에서 사용 가능한지, 외부 심사가 아직 대기 중인지 구분해야 합니다. AirBuild가 절차를 돕는다고 해서 Apple 심사를 우회할 수 있는 것은 아니며, 시뮬레이터 검증만으로 실제 기기의 모든 동작을 확인했다는 뜻도 아닙니다.

위 내용은 AirBuild의 작업 방식에 대한 설명이며, Apple이 특정 도구 사용을 강제한다는 뜻은 아닙니다. Mac에 로컬 Xcode가 없더라도, 다른 사람과 협업해 배포하려면 패키징의 모든 세부 사항을 반드시 배워야 한다는 뜻도 아닙니다.

7. 내부 테스터는 어떻게 추가하나요? 초대가 2번이라는 점에 주의하세요

대상: 자신과 앱 관리 시스템에 실제로 접근해야 하는 협업 구성원입니다.

첫 번째: 상대방을 권한이 있는 관리 사용자로 추가하기

계정 소유자(Account Holder), 관리자(Admin) 또는 앱 관리자(App Manager) 역할로 사용자를 추가합니다.

1. 사용자 및 액세스(Users and Access) → 사용자(People)로 들어갑니다.
2. “+”를 누르고 이름과 이메일을 입력합니다.
3. 적절한 역할을 부여합니다. 역할에 따라 앱 범위를 제한할 수 있다면 필요한 앱의 권한만 부여하세요. 기본적으로 관리자 권한을 주지 마세요. 관리자, 재무 역할의 사용자, 그리고 보고서나 인증서 등 추가 리소스에 대한 접근 권한을 받은 사용자는 개별 앱 단위로 접근을 제한할 수 없으므로 권한을 선택하기 전에 범위를 잘 확인해야 합니다.[9]
4. 초대를 보내고 상대방이 수락해 관리 접근 자격을 활성화하도록 합니다.

Apple의 현재 안내에 따르면 이러한 관리 사용자 초대는 3일 후 만료되며, 만료되면 다시 보낼 수 있습니다. 이것은 나중에 보내는 TestFlight 초대와 다르고, 빌드의 90일 기한과도 다릅니다.[9]

상대방이 이미 적격 역할과 해당 앱의 접근 권한을 갖고 있다면 이 단계는 건너뛰어도 됩니다.

두 번째: 내부 테스트 그룹에 사람과 빌드 추가하기

1. 앱 → 내 앱 → TestFlight로 들어갑니다.
2. 내부 테스트(Internal Testing) 옆의 “+”를 눌러 “팀” 등의 새 그룹을 만듭니다.
3. 그룹을 열고 테스터 초대(Invite Testers) 또는 테스터 목록 옆의 “+”를 선택합니다.
4. 조건에 맞는 관리 구성원을 선택해 그룹에 추가합니다.
5. 빌드 추가(Add Builds)를 누르고 처리가 완료되어 테스트할 수 있는 빌드를 선택합니다.
6. 테스트할 내용(What to Test)을 작성하고 추가합니다.
7. 상대방이 기기에 TestFlight를 설치하고 테스트 초대를 수락한 뒤 앱을 설치하도록 합니다.[5]

“명단에 사람이 있다”는 것만으로 끝난 것이 아닙니다. 사용 가능한 빌드가 있어야 하고, 상대방도 실제로 초대를 수락하고 설치해야 합니다.

초대할 사람이 보이지 않나요? 먼저 관리 사용자 초대를 수락했는지, 역할 요건을 충족하는지, 이 앱에 대한 접근 권한이 있는지 확인하세요. 곧바로 앱을 다시 업로드하지 마세요.

일부 내부 그룹은 자동 배포를 켤 수 있지만, 모든 경로에서 생성된 빌드가 모든 그룹에 자동으로 추가된다고 가정해서는 안 됩니다. Apple의 현재 도움말은 Xcode Cloud에서 생성한 빌드를 App Store Connect에서 그룹에 수동으로 추가해야 한다고 별도로 안내합니다.[5]

8. 외부 테스터는 어떻게 추가하나요?

대상: 친구, 고객, 초기 사용자, 커뮤니티 테스터입니다. 처음 앱을 다른 사람에게 공유할 때는 보통 이 방식이 더 적합합니다.

먼저 빌드를 받을 외부 그룹 준비하기

계정 소유자, 관리자 또는 앱 관리자 역할로 진행합니다.

1. 내부 그룹이 없다면 먼저 하나 만듭니다. Apple의 현재 외부 테스트 가이드는 “먼저 내부 그룹 생성”을 사전 조건으로 명시합니다. 정식 출시를 먼저 해야 한다거나, 외부 테스터가 먼저 내부 구성원이 되어야 한다는 뜻은 아닙니다.[6]
2. 앱 → 내 앱 → TestFlight로 들어갑니다.
3. 테스트 정보(Test Information)에 베타 버전 설명과 피드백 이메일을 입력하고, 심사에 필요한 연락처를 모두 작성합니다. 로그인이 필요하다면 유효한 심사용 접근 방법과 사용 안내를 제공하고 관련 서버가 사용 가능한지 확인합니다. 실제 사용자의 개인 정보를 데모 자료로 쓰지 마세요.[6][8][14]
4. 외부 테스트(External Testing) 옆의 “+”를 눌러 “얼리 액세스” 등의 새 그룹을 만듭니다.
5. 그룹에 들어가 빌드 추가를 누르고 플랫폼, 버전, 구체적인 빌드를 선택합니다.
6. 테스트할 내용을 작성합니다. “아무거나 해 보세요”보다는 “기록을 하나 만들고 앱을 종료했다가 다시 열어 기록이 남아 있는지 확인해 주세요”처럼 씁니다.
7. 필요에 따라 테스터에게 자동으로 알림(Automatically notify testers)을 선택합니다.
8. 화면 상태에 따라 심사 제출 또는 테스트 시작을 선택하고, 필요한 심사가 모두 완료될 때까지 기다립니다.
9. 이메일, 공개 링크 또는 두 방식을 함께 사용해 테스터를 초대합니다.[6]

처음 통과하면 그다음부터는 심사가 필요 없나요?

아닙니다.

외부 테스트에 처음 제출하는 빌드는 전체 심사가 필요합니다. 같은 버전의 후속 빌드는 전체 심사가 필요 없을 수도 있지만, 이후 영구적으로 심사가 면제된다고 약속할 수는 없습니다. Apple은 중요한 베타 버전 업데이트도 배포 전에 테스트 심사에 제출하도록 요구합니다.[6][14]

심사에 걸리는 시간은 일정하지 않습니다. “업로드하고 몇 분이면 반드시 설치할 수 있다”거나 “24시간 안에 반드시 통과한다”고 약속하지 마세요.

빌드를 추가할 때 자동 알림을 선택하지 않았다면, 승인 후 테스터에게 알림(Notify Testers)을 실행해야 합니다. TestFlight 왼쪽의 빌드(Builds) 아래에서 플랫폼과 버전을 선택한 뒤, 해당 빌드의 상태 표시줄에 있는 알림 항목을 누릅니다. 승인됨, 배포됨, 상대방이 설치함은 서로 다른 3가지 상태입니다.[6]

방법 1: 이메일로 초대하기

외부 그룹을 열고 테스터(Testers) 옆의 “+”를 누릅니다. 새 테스터의 이메일을 입력하거나, 기존 테스터를 선택하거나, 명단을 가져올 수 있습니다.[6]

상대방이 받는 것은 테스트 초대이며, 이로 인해 App Store Connect의 관리 권한을 얻는 것은 아닙니다.

방법 2: 공개 링크를 만들어 공유하기

외부 그룹의 테스터 페이지를 열고 공개 링크 생성(Create Public Link)을 선택합니다.

1. 모든 사람에게 공개(Open to Anyone) 또는 조건으로 필터링(Filter by Criteria)을 선택합니다.
2. 필요에 따라 링크를 통한 모집 인원 상한을 설정합니다. 1–10,000명으로 설정할 수 있지만, 이 앱의 전체 외부 테스터 수 상한도 적용됩니다.
3. 필터링을 선택했다면 대상 기기와 운영체제 버전 조건을 설정합니다.
4. 확인한 뒤 실제 생성된 링크를 복사해 친구에게 보내거나 커뮤니티, 이메일, 웹사이트에 공유합니다.[6]

링크는 보통 https://testflight.apple.com/join/…로 시작합니다. Apple이 생성한 실제 링크를 복사해야 합니다. 뒤의 코드를 임의로 만들거나 App Store Connect 관리 페이지 주소를 설치 링크로 사용하지 마세요.

QR 코드에 같은 링크를 담을 수도 있지만, 별도의 배포 방식이 되는 것도 아니고 심사를 우회하는 것도 아닙니다.

링크를 공유하기 전에 확인할 4가지

• 대상 외부 그룹에 공유하려는 빌드가 있는지 확인합니다.
• 필요한 심사를 통과했고 배포도 시작되었는지 확인합니다.
• 빌드가 만료되지 않았고 대상 기기와 호환되는지 확인합니다.
• 링크가 활성화되어 있고 남은 자리가 있으며, 필터 조건이 대상 사용자를 제외하지 않는지 확인합니다.[3][6]

링크가 열린다고 해서 새 버전을 반드시 설치할 수 있는 것은 아닙니다. 이전 빌드가 여전히 사용 가능하더라도 최신 빌드가 그 그룹에 배포되었다는 뜻은 아닙니다.

공개 링크는 계속 전달될 수 있으며, 비밀 명단이 아닙니다. 특정한 몇 명만 초대하고 싶다면 이메일 초대를 우선 사용하고, 앱 자체의 계정 권한에서도 접근을 적절히 통제하세요.

공개 링크로 참여한 사람의 이름과 이메일은 기본적으로 TestFlight 테스터 명단에 표시되지 않지만, 설치 날짜, 사용 세션, 충돌 등의 정보는 볼 수 있습니다. 상대방이 직접 피드백을 제출할 때 이메일을 제공할 수도 있습니다. Apple이나 앱 자체의 로그인 시스템에 대해서도 완전히 익명이라는 뜻은 아닙니다.[3][6]

이후 빌드를 업데이트할 때는 보통 같은 외부 그룹의 링크를 계속 사용할 수 있으므로 매번 모든 사람을 다시 모집할 필요가 없습니다. 관리(Manage)에서 필터 조건, 인원 제한을 변경하거나 링크를 비활성화할 수도 있습니다. 링크 비활성화는 신규 참여 경로를 닫는 것이지, 기존 설치를 삭제하거나 앱 계정을 탈퇴시키거나 서버 데이터를 비우는 것이 아닙니다.[6]

9. 테스터는 어떻게 설치하고, 업데이트하고, 피드백을 보내고, 테스트를 그만두나요?

초대를 받았다면 테스트에 사용할 iPhone 또는 iPad에서 다음과 같이 진행합니다.

1. App Store에서 Apple 공식 TestFlight를 설치합니다.
2. 초대 이메일 또는 공개 링크를 엽니다.
3. 화면 안내에 따라 TestFlight로 이동해 수락(Accept)을 선택한 다음 설치(Install)를 누릅니다.
4. 테스트할 내용을 읽고 사용을 시작합니다.
5. 새 빌드가 나오면 TestFlight에서 업데이트합니다. 자동 업데이트를 켤 수도 있습니다. 기존 테스터에게는 바로 업데이트(Update) 또는 열기(Open)가 표시될 수 있습니다.[3]

일반적인 외부 테스트에는 개발자의 암호나 관리 역할이 필요 없고, 전용 샌드박스 계정을 먼저 만들 필요도 없습니다.

휴대폰에 정식 버전이 이미 있으면 앱이 2개 설치되나요?

보통은 아닙니다. 같은 앱의 TestFlight 베타 버전은 기기에 설치된 App Store 버전을 대체합니다.[3]

따라서 중요한 데이터는 먼저 백업하거나 내보내세요. 베타 버전이 데이터 형식을 바꿀 수 있으며, 새 버전에서 작성한 데이터를 이전 버전에서 읽지 못할 수도 있습니다. 버전을 전환해도 데이터가 온전히 유지된다고 보장되는 것은 아닙니다.

개발자가 다른 유효한 빌드를 계속 제공하고 있다면 이전 빌드(Previous Builds)에서 선택할 수 있습니다. 모든 과거 버전을 영구 보관하는 다운로드 저장소는 아닙니다.[3]

개발자가 이해하기 쉽게 피드백하려면?

TestFlight에서 해당 앱을 열고 베타 피드백 보내기(Send Beta Feedback)를 누릅니다. 지원되는 운영체제에서는 테스트 앱에서 스크린샷을 찍은 뒤 피드백을 보낼 수도 있습니다. 충돌 후에는 추가 정보를 공유하라는 안내가 나올 수 있습니다.[3]

“안 돼요”보다 도움이 되는 작성 예시는 다음과 같습니다.

제가 사용하는 기기는 [기기 모델], 운영체제는 [운영체제 버전]이며, 앱은 [버전 및 빌드 번호]입니다. 설정을 열어 언어를 바꾼 다음 홈 화면으로 돌아갔습니다. 홈 화면의 글자도 함께 바뀔 것으로 예상했지만 실제로는 이전 언어가 그대로 표시됩니다. 2번 반복해 보았고 모두 같은 문제가 발생했습니다. 스크린샷을 첨부합니다.

암호, 결제 정보, 다른 사람의 개인 정보가 스크린샷에 그대로 들어가지 않게 하세요. TestFlight로 제출한 피드백은 Apple에도 제공됩니다. 앱 자체의 피드백 창구는 별도의 경로입니다.[3]

더 이상 테스트하고 싶지 않다면?

TestFlight에서 해당 앱의 정보 페이지로 들어가 테스트 중단(Stop Testing)을 선택합니다. 정식 버전이 이미 있다면 App Store에서 다시 다운로드하거나 구입할 수 있습니다. 베타 버전만 있고 아직 정식 출시되지 않은 앱이라면 돌아갈 정식 버전이 없을 수도 있습니다.[3]

테스트를 중단한다고 해서 앱에 가입한 계정이 삭제되는 것은 아닙니다. 계정과 클라우드 데이터는 앱 자체의 규칙에 따라 처리해야 합니다.

10. TestFlight에서 결제하면 실제로 돈이 청구되나요?

TestFlight로 설치한 앱에서 Apple의 앱 내 구입으로 진행하는 테스트 거래는 샌드박스를 사용하므로 실제 요금이 청구되지 않습니다. StoreKit을 통한 구독 테스트도 포함됩니다.[3][10]

“샌드박스”는 구입 과정을 연습하는 환경이라고 생각하면 됩니다. 앱은 상품 정보를 읽고, 테스트 구입을 시작하고, 구입을 복원하고, 거래 알림을 처리할 수 있지만 이로 인해 실제 판매 수익이 발생하지는 않습니다.[10]

가장 오해하기 쉬운 부분은 샌드박스가 적용되는 범위입니다.

요금이 청구되지 않는다고 해서 정식 버전을 평생 무료로 쓸 수 있는 것은 아닙니다

Apple은 테스트 중의 앱 내 구입이 App Store 정식 버전의 구입 내역으로 이전되지 않는다고 명시합니다. 테스터에게 “지금 한 번 누르면 정식 출시 후에도 평생 회원 혜택을 받는다”고 약속하지 마세요.[3]

개발자가 별도로 앱 계정 혜택을 제공하기로 결정했다면 그것은 자체적인 사업 운영 방침이지, TestFlight가 자동으로 제공하는 규칙이 아닙니다.

테스트 구독의 시간도 실제 청구 주기와 다릅니다

자동 갱신 구독에 대한 Apple의 현재 TestFlight 테스터 안내는 다음과 같습니다. 원래 구독 기간의 길이에 관계없이 테스트 중에는 매일 갱신되며, 1주일 동안 최대 6회 갱신됩니다. 샌드박스 계정을 사용하는 고급 제어 기능에서는 갱신 속도를 조정할 수도 있습니다. 다른 샌드박스 상황에 적용되는 “5분”, “12회” 등의 값을 일반적인 TestFlight 테스트에 그대로 적용하지 마세요.[3][10]

이러한 가속 규칙은 갱신과 만료를 테스트하기 위한 것이며, 정식 사용자의 청구 주기로 받아들여서는 안 됩니다.

Apple의 구입 경로만 자동으로 샌드박스에 들어갑니다. 앱 전체가 아닙니다

TestFlight 앱도 여전히 다음과 같은 일을 할 수 있습니다.

• 운영 서버에 연결해 실제 기록을 변경할 수 있습니다.
• 실제 이메일이나 메시지를 보낼 수 있습니다.
• 실제 계정이나 데이터를 삭제할 수 있습니다.
• 실제로 결제를 받는 웹페이지를 열 수 있습니다.
• Apple의 앱 내 구입이 아닌 결제 수단을 사용할 수 있습니다.

웹 결제, Apple Pay, StoreKit 앱 내 구입은 서로 다릅니다. TestFlight로 받은 앱이라고 해서 웹 결제나 실제 업무 처리에서 진짜 돈이 들지 않는다고 생각해서는 안 됩니다. 개발자는 테스트 데이터, 서버, 다른 결제 환경을 별도로 설정해야 합니다.[10]; 앱 시스템의 적용 범위 설명

모든 테스터가 샌드박스 계정을 만들어야 하나요?

아닙니다. 일반적인 TestFlight 설치와 구입 테스트에는 평소 사용하는 Apple 계정을 쓸 수 있습니다.[10]

구입 내역 초기화나 고급 테스트 설정 조정 등의 제어가 필요할 때만 개발자가 Apple 문서에 따라 Sandbox Apple Account를 설정하면 됩니다. 고급 절차에는 “미디어 및 구입 항목”에서 로그아웃하는 단계가 포함될 수 있으며, 기기에서 구입한 콘텐츠에 접근하는 데 영향을 줄 수 있습니다. 이것은 일반 테스터가 설치 전에 반드시 해야 하는 일이 아니며, 함부로 기기 전체의 iCloud에서 로그아웃하도록 해서도 안 됩니다. Apple은 전용 테스트 기기를 사용하는 방안을 고려하도록 권장합니다.[10]

구입에 성공했다고 나오지만 앱 기능이 잠금 해제되지 않는다면 개발자에게 피드백해야 합니다. 상품 설정, 거래 검증, 이용 권한 부여, 구입 복원, 갱신 처리 모두 올바르게 구현되어야 합니다. 샌드박스 구입 성공은 정식 결제, 수익 입금, 모든 구독 로직이 올바르다는 증거가 아닙니다.

11. TestFlight에는 어떤 제한이 있나요?

표가 넓으면 좌우로 스크롤할 수 있습니다. 키보드 사용자는 표에 초점을 맞춘 뒤 방향키를 사용하세요.

90일이 지나면 초대를 다시 보내도 되나요?

다시 보내도 해결되지 않습니다. 기한은 특정 테스터가 아니라 빌드에 적용됩니다. 늦게 참여한 사람에게 새로운 90일이 주어지는 것이 아닙니다. 만료된 베타 버전은 더 이상 열 수 없으며, 개발자가 유효한 새 빌드를 제공해야 합니다.[3]

테스트가 끊기지 않게 하려면 이전 빌드가 만료되기 전에 새 빌드를 업로드하고 배포한 뒤 업데이트를 안내해야 합니다. 새 빌드에는 별도의 기한이 있으며, 이전 빌드의 수명을 연장하지는 않습니다.

TestFlight로 장기간 앱이나 참여권을 판매해도 되나요?

정식 출시를 우회하는 판매 경로로 생각하지 마세요.

Apple의 심사 지침 2.2는 테스트 앱도 심사 규칙을 준수하고 공개 출시를 목적으로 해야 한다고 요구합니다. 또한 크라우드펀딩 보상을 포함해, 어떤 형태로든 대가를 받고 TestFlight 테스트 배포를 제공하는 것을 금지합니다. 쉽게 말해 “돈을 내고 그룹에 가입해야 베타 버전을 받을 수 있다”는 방식을 정상적인 TestFlight 배포 방안으로 삼아서는 안 됩니다.[14]

12. 자주 묻는 질문: 왜 다른 사람이 설치하지 못하나요?

표가 넓으면 좌우로 스크롤할 수 있습니다. 키보드 사용자는 표에 초점을 맞춘 뒤 방향키를 사용하세요.

위 내용은 확인할 방향을 제시하는 것이며, 오류 문구 하나만 보고 근본 원인을 확정할 수 있다는 뜻은 아닙니다.[3][5][6][11]

특히 주의하세요. 관리 화면의 녹색 “테스트 중(Testing)”도 내부 그룹에서만 사용 중이라는 뜻일 수 있습니다. 외부 사용자가 설치할 수 있는지 판단하려면 대상 외부 그룹, 구체적인 빌드, 해당 그룹에서의 사용 가능 상태를 반드시 확인해야 합니다.[11]

“제출 준비 완료(Ready to Submit)”, “심사 대기 중(Waiting for Review)”, “베타 심사 중(In Beta Review)”, “테스트 준비 완료(Ready to Test)”도 모두 다른 단계입니다. 특히 테스트 준비 완료 상태라도 테스터를 추가하거나 수동 알림을 완료해야 할 수 있습니다.[11]

13. 개발자는 어디에서 피드백을 보고, 어떻게 다음 버전을 배포하나요?

앱 → 내 앱 → TestFlight → 피드백(Feedback)으로 들어가면 스크린샷(Screenshots)과 충돌(Crashes)을 볼 수 있으며, 버전이나 기기 등의 조건으로 필터링할 수 있습니다. 앱 내에서 피드백을 제출할 수 있는지는 그룹 설정의 영향도 받습니다.[12]

재현할 수 있는 문제부터 처리한 다음 다음 회차를 진행하세요.

1. 문제를 수정하고 새 빌드 번호로 패키징해 업로드합니다.
2. 처리를 기다리고 필요한 규정 준수 절차를 완료합니다.
3. 새 빌드를 대상 그룹에 추가하고 필요한 외부 심사를 완료합니다.
4. 테스트할 내용을 업데이트하고 설정에 따라 테스터에게 알립니다.
5. 대상 그룹의 사람들에게 실제로 설치한 버전과 빌드를 확인하고 원래 문제를 다시 테스트해 달라고 요청합니다.

업로드 기록, 그룹 명단, 심사 승인 모두 중요하지만, 마지막에는 반드시 대상 사용자가 실제로 대상 빌드를 설치했는지 확인해야 합니다.

내부 테스트 스크린샷 하나만으로 모든 외부 사용자도 설치할 수 있다고 증명할 수는 없습니다. 시뮬레이터에서 실행된다는 사실도 실제 기기의 설치 결과를 대신하지 못합니다.

14. 테스트를 끝내거나 정식 출시하려면 어떻게 하나요?

먼저 무엇을 중단하려는지 구분하세요.

• 신규 사용자 모집 중단: 외부 그룹의 공개 초대 링크를 비활성화합니다.
• 누가 어떤 빌드를 받을 수 있는지 조정: 테스터, 그룹, 빌드 배정을 관리합니다.
• 특정 빌드의 신규 설치 중단: 빌드 상세 화면에서 빌드 만료(Expire Build)를 선택합니다. 모든 휴대폰의 앱을 원격으로 삭제하거나 클라우드 계정을 지우는 것으로 이해해서는 안 됩니다.[6][13]
• 정식 출시: App Store 정식 버전에 필요한 자료를 준비하고 적격 빌드를 선택한 뒤, 별도로 정식 심사에 제출합니다.[1][2]

일반 TestFlight 업로드를 통해 이미 올린 적격 빌드는 정식 심사에도 선택할 수 있습니다. 출시하려는 이유만으로 반드시 다시 패키징해야 하는 것은 아닙니다. 다만 실제 코드가 바뀌었다면 새 빌드를 업로드해야 하며, “내부 테스트 전용” 업로드도 정식 출시에는 사용할 수 없습니다.[2][5]

TestFlight 심사를 통과해도 App Store에 자동으로 출시되지는 않습니다. 반대로 정식 버전을 출시해도 아직 유효한 베타 버전이 자동으로 종료되지는 않습니다. 테스트 종료와 사용자 전환을 각각 계획해야 합니다.[1]

15. 첫 테스터에게 보낼 안내문은 이렇게 써 보세요

[앱 이름]의 초기 버전을 테스트해 주실 수 있을까요?

먼저 App Store에서 Apple 공식 TestFlight를 설치한 다음, iPhone에서 [실제 초대 링크]를 열어 초대를 수락하고 설치해 주세요.

이번에 중점적으로 테스트해 주셨으면 하는 내용은 [구체적인 작업 1~2개]입니다. 지원 기기와 운영체제는 [실제 요구 사항]입니다.

베타 버전이라 문제가 있을 수 있으니 중요한 자료는 먼저 백업해 주세요. 이상이 생기면 TestFlight의 “베타 피드백 보내기”에서 어떤 작업을 했는지, 무엇을 예상했는지, 실제로 어떤 일이 일어났는지 알려 주세요. 스크린샷과 버전 번호도 함께 보내 주시면 좋습니다.

대괄호 부분을 실제 정보로 바꾸세요. 대상 외부 그룹의 빌드가 실제로 설치 가능한지 확인한 뒤 보내야 합니다. 아직 심사를 기다리는 링크를 먼저 단체로 보내면서 사용 가능하다고 안내하지 마세요.

배포 전, 마지막으로 확인할 10가지

• □ 계정 권한에 맞춰 내부 또는 외부 테스트를 선택했고, 편의를 위해 과도한 권한을 부여하지 않았다.
• □ 대상 빌드의 처리가 완료되었고, 해결되지 않은 배포 장애 요인이 없다.
• □ 대상 그룹에 해당 빌드가 실제로 포함되어 있다.
• □ 필요한 외부 심사를 통과했고, 필요한 알림도 보냈다.
• □ 초대 방식을 확인했다. 이메일 초대는 올바른 사람에게 보냈으며, 공개 링크를 사용한다면 활성화되어 있고 남은 자리가 있다. 대상 기기와 운영체제가 요구 사항을 충족한다.
• □ 테스트 설명, 피드백 이메일, 테스트할 내용이 정확하고 유용하다.
• □ 테스터가 베타 버전임을 알고 있으며, 정식 버전을 대체할 수 있다는 점도 알고 있다.
• □ 샌드박스 구입과 실제 서버, 웹 결제, 현실에서 이루어지는 작업을 구분했다.
• □ 빌드의 만료 시점을 확인하고 후속 업데이트를 계획했다.
• □ 대상 사용자 중 누군가가 초대 웹페이지를 열어 보기만 한 것이 아니라, 대상 빌드를 실제로 설치했다고 확인했다.

처음 앱을 배포할 때 진짜 도착점은 “업로드 완료”가 아닙니다. 올바른 사람이 올바른 버전을 설치하고, 무엇을 테스트해야 하는지, 문제를 어떻게 알려야 하는지까지 아는 상태가 되어야 합니다.

출처 및 더 읽어 볼 자료

아래 자료는 2026년 9월 17일에 확인했습니다. 역사적 사건은 당시 보도나 해당 연도의 Apple 발표를 사용했으며, 현재 규칙은 주로 Apple 공식 도움말을 기준으로 했습니다. 사용 화면은 언어와 버전에 따라 달라질 수 있습니다.