Fastlane으로 앱 등록하기 — 문자 2FA까지 기존 Mac 환경에서 처리한 기록

2026-09-29 · 문의노트 iOS 배포 과정

“앱을 올린다는데, 왜 브라우저 화면에서는 아무 일도 안 보이지?”

이번 작업은 화면을 누르는 대신 명령어로 진행했다. Fastlane으로 Apple 계정에 로그인하고 앱을 등록한 뒤, Apple 업로드 도구로 파일을 보냈다. 중간에 필요한 문자 인증은 계정 소유자가 이미 사용하는 Mac의 수신 경로에서 처리했다. 이 글은 그때의 방법과 확인 기준을 정리한 기록이다.

Fastlane은 무엇인가

앱을 만들고 배포할 때 반복하는 일을 명령어로 묶어 주는 도구다. 택배에 비유하면 앱 파일은 물건이고, Fastlane은 접수와 발송 준비를 도와주는 작업 도우미다. 최종 심사와 배포 상태는 Apple 쪽에서 결정한다.

웹브라우저에서는 사람이 버튼을 눌러 앱 정보를 등록한다. Fastlane의 produce는 필요한 정보를 받아 App Store Connect와 Apple Developer Portal에 앱을 등록할 수 있다. Fastlane produce 공식 문서

Fastlane으로 로그인했다고 브라우저에도 로그인되는 것은 아니다. 브라우저와 명령줄 도구는 각자의 세션을 사용한다. 작업을 설명할 때도 어느 컴퓨터에서 어떤 도구로 실행하는지 먼저 알려야 한다.

이번에 연결한 경로

앱 서명 환경이 있는 Mac에서 로그인·등록·업로드를 실행했다. 인증문자는 다른 Mac의 메시지 앱에 동기화돼 들어왔다.

배포용 Mac: Fastlane으로 Apple 로그인 요청
                         ↓
문자 수신 Mac: 방금 요청한 Apple 인증문자 확인
                         ↓
비공개 프로세스 연결로 코드 전달 → 로그인 완료
                         ↓
앱 등록 → 서명된 IPA 업로드 → Apple 처리 상태 확인

두 컴퓨터는 이미 승인된 연결을 사용했다. 같은 Mac이 두 역할을 맡아도 된다. 필요한 전제는 본인 계정의 기존 자격증명, 신뢰할 수 있는 전화번호, 해당 문자가 실제로 수신되는 경로, 그리고 그 경로를 읽을 권한이다. 모든 Mac에서 문자 읽기가 자동으로 가능한 것은 아니다.

이번 경로에서는 다른 작업이 쓰고 있던 아이폰을 조작할 필요가 없었다. 다만 앱이 실제 폰에 설치되고 기록을 저장하는지 확인하는 단계는 별도로 남는다.

API 키와 Apple 계정 로그인을 나눴다

Fastlane 공식 문서는 지원되는 작업에 App Store Connect API 키를 권장한다. 지원하지 않는 작업에는 Apple 계정과 2FA가 필요할 수 있다. 인증 방식 공식 문서

이번 환경에서는 API로 새 앱 레코드를 만드는 요청이 403으로 거절됐다. 그래서 앱 등록은 기존 Apple 계정으로 Fastlane에 로그인해 처리했다. 업로드와 후속 상태 조회에는 기존 API 키를 사용했다. 이때 관측한 403을 모든 계정·모든 API 작업에 적용되는 제한으로 일반화하지는 않는다.

역할은 다음처럼 나뉘었다.

단계	이번에 사용한 방법	확인한 결과
Apple 로그인	Fastlane + 문자 2FA	인증 후 다음 작업 진행
새 앱 등록	Fastlane `produce`	API로 등록된 앱 재조회
서명된 IPA 업로드	Apple `altool` + API 키	업로드 성공 응답
빌드 처리 확인	App Store Connect API	`VALID`
테스터 연결·베타 심사	App Store Connect API	그룹 연결 및 심사 대기

문자 인증에서 중요했던 네 가지

1. 문자가 실제로 도착하는 컴퓨터를 찾는다

배포용 Mac에 문자가 없다고 해서 사용자에게 바로 코드를 물어볼 필요는 없었다. 기존 수신 환경을 확인하니 다른 Mac에 문자가 도착해 있었다. 로그인 실행 위치와 문자 수신 위치를 따로 확인한 것이 해결의 시작이었다.

2. 방금 요청한 인증문자만 사용한다

로그인을 시작한 시각을 기억하고 그 이후에 도착한 수신 문자만 읽었다. Apple 인증 문구와 코드 형식을 확인하고, 이전 문자나 발신 문자는 제외했다. 여러 개의 서로 다른 코드가 잡히면 어느 것이 맞는지 추측하지 않고 중단했다.

이 확인은 기존의 신뢰할 수 있는 문자 수신 경로를 전제로 한다. 본문에 ‘Apple’이라는 단어가 있다는 사실만으로 발신자의 신원이 증명되는 것은 아니다.

3. 메시지의 저장 형태를 확인한다

실제 Mac 메시지 기록에서는 일반 텍스트 필드가 비어 있고 attributedBody라는 별도 필드에 내용이 들어 있었다. 같은 코드가 그 안에 반복되기도 했다. 이번 형식에서는 반복된 동일 코드를 하나로 취급해 읽을 수 있었다.

이 저장 형식은 macOS 버전이나 메시지에 따라 달라질 수 있다. 이번에 확인한 읽기 방식을 모든 메시지의 범용 해석기로 취급하면 안 된다. 데이터베이스는 읽기 전용으로 열었다.

4. 코드와 세션은 출력하지 않는다

코드는 부모·자식 프로세스 사이에서 메모리로만 전달했다. 문자 본문, 비밀번호, 인증번호, 세션 문자열은 대화·로그·임시 평문 파일에 남기지 않았다. Fastlane 원시 출력에도 계정 정보가 들어갈 수 있어, 재사용 래퍼는 필요한 진행 상태만 출력하도록 했다.

인증 실패 때 같은 요청을 계속 반복하지 않고 멈추도록 했으며, 성공한 기존 세션은 보존했다.

로그인 전에 막혔던 service key 문제

설치된 Fastlane이 사용하는 구 설정 주소에서 404가 발생했다. 이때는 암호나 인증번호를 다시 입력해도 원인이 해결되지 않았다. 관련 Fastlane 상류 수정 PR을 확인하고, 로그인 초기화에 필요한 service key를 얻는 호환 처리를 해당 작업 프로세스에만 적용했다.

이번 호환 처리에서는 쿠키 없는 새 연결과 리다이렉트를 따라가지 않는 HEAD 요청을 사용했다. 기존 로그인 세션에 영향을 주지 않는지 확인하는 것이 중요했다. Ruby의 URL 쿼리 해석 방식 차이도 수정했다. 이 service key는 업로드에 쓰는 개인 App Store Connect API 키와 다른 값이다.

또 하나의 멈춤 지점은 개발팀 선택이었다. 계정에 팀이 여러 개 있으면 인증이 끝난 뒤에도 선택 입력을 기다릴 수 있다. 기존에 확인한 대상 팀을 명시하고 정상 세션을 재사용해 앱 등록을 마쳤다.

어디까지 됐는지 끝에서 다시 확인한다

글을 작성한 시점의 문의노트는 다음 상태였다.

새 앱 등록을 API 재조회로 확인했다.
IPA 업로드 후 빌드가 VALID가 된 것을 확인했다.
내부·외부 테스터 그룹에 빌드와 테스터가 연결된 것을 확인했다.
외부 TestFlight 심사는 WAITING_FOR_REVIEW였다.
실제 고객 폰 설치와 설치 후 로컬 저장은 아직 확인하지 않았다.

문자 코드 입력, 로그인 성공, 업로드 성공, 심사 승인, 실제 설치는 각각 확인할 단계다. 앞 단계의 성공을 뒤 단계의 완료로 바꾸어 보고하지 않는 것이 이 자동화의 마지막 기준이다.

다음 작업에서도 먼저 기존 인증·수신 환경을 확인하고, 필요한 도구를 연결한 뒤, 사용자가 받는 결과까지 단계별로 검증한다.