Apple의 ActivityKit 푸시 문서는 시작 요청에서 event, timestamp, content-state를 확인하도록 안내합니다. ActivityKit 푸시 시작 및 갱신 문서에 명시된 이 3가지 핵심 데이터만 보아도, 단일 기기에서 카드가 한 번 나타난 사실만으로는 출시를 승인할 수 없습니다. iOS 27 Live Activities 검수는 빌드 환경, 토큰 수명, APNs 요청, 연속 갱신, 제한 조건, 단계적 출시를 시간순으로 모두 통과해야 합니다.
마지막 업데이트: 2026년 9월 18일. 내용은 Xcode 27 출시 기록, iOS 27 출시 기록, Apple의 ActivityKit 및 APNs 문서를 기준으로 확인했습니다.
이 글을 읽어야 하는 팀
Live Activities 푸시 연결을 관리하는 iOS 개발자는 클라이언트 토큰과 수명 주기를 보완할 수 있습니다. 버전 출시를 승인하는 기술 책임자는 수정 완료와 출시 허용 기준을 분리할 수 있습니다. 테스트와 운영 팀은 Xcode 27과 iOS 27 실기기를 격리한 회귀 환경을 만들 수 있습니다.
검수 기준과 증거의 분리
이번 검수에서 가장 먼저 분리해야 할 것은 APNs가 요청을 받았는지, 기기에 전달했는지, 앱과 잠금 화면이 상태를 그렸는지입니다. 서버가 요청을 제출했다는 로그만 있으면 첫 번째 단계의 증거일 뿐입니다. APNs 응답의 상태와 apns-id, 대상 토큰, 요청 시각을 함께 저장해야 다음 단계와 연결할 수 있습니다. APNs 응답의 의미와 오류 처리는 Apple의 APNs 응답 문서에서 확인합니다.
반대로 카드가 보이지 않는 원인을 곧바로 iOS 27 시스템 오류로 단정해서는 안 됩니다. 개발자 포럼이나 질의응답 사이트의 사례는 재현할 고장 신호로 활용하되, 공식 출시 기록에 없는 고정 새로 고침 예산이나 특정 실패율을 사실처럼 기록하지 않습니다. Apple이 고정된 예산 수치를 공개하지 않았다면 팀의 검수표에도 임의의 임계값을 넣지 않는 편이 안전합니다.
빌드 환경과 서명 확인
Xcode 18은 iOS 27 SDK 검수용 기준이 아닙니다. iOS 27 SDK를 지원하는 Xcode 27로 검수 빌드를 다시 만들고, 다음 정보를 빌드 기록에 남깁니다. Xcode 27 출시 기록과 프로젝트의 실제 아카이브 설정을 함께 대조합니다.
- SDK와 Xcode 27의 정확한 빌드 정보
- 배포용 Bundle ID와 앱의 환경 구분
- 서명 인증서와 프로비저닝 프로필
- Live Activities와 Push Notifications 권한
- 최종 아카이브에 포함된 Entitlements
- 개발용과 운영용 APNs 환경의 구분
로컬 디버그 실행에서만 권한이 보이고 최종 아카이브에서 빠지는 경우가 있습니다. 따라서 소스 프로젝트의 설정 화면이 아니라 보관된 앱의 서명과 권한을 확인해야 합니다. 이 단계의 통과 조건은 “Xcode 27로 만든 배포 대상 앱이 올바른 Bundle ID와 권한을 가지고 있다”입니다. 실패하면 토큰 단계로 넘어가지 않고 아카이브부터 다시 만듭니다.
시작 토큰과 갱신 토큰의 수명
Push-to-Start 토큰과 활동이 시작된 뒤의 갱신 토큰은 같은 값으로 취급하면 안 됩니다. Apple은 Push-to-Start 토큰을 별도 흐름으로 설명하고 있으며, Push-to-Start 토큰 문서에서 해당 토큰의 관찰 방식을 확인할 수 있습니다.
Push-to-Start 요청은 성공했지만 잠금 화면에 표시되지 않을 때 무엇을 확인해야 합니까?
먼저 시작 토큰이 실제로 서버에 도착했는지 확인합니다. 그 다음 서버가 해당 토큰에 연결된 운영 환경과 사용자 식별자를 정확히 선택했는지 봅니다. APNs 응답의 성공 여부만으로 화면 표시를 판정하지 않습니다. 시작 요청의 Payload 구조, 앱의 속성 타입, 기기에서의 활동 생성 여부를 별도로 확인해야 합니다.
ActivityKit 갱신 토큰이 바뀐 뒤 서버는 무엇을 검증해야 합니까?
클라이언트는 비동기 ActivityKit 시퀀스에서 새 갱신 토큰을 관찰하고 서버에 업로드해야 합니다. 서버는 다음 값을 한 묶음으로 저장합니다.
- 사용자와 기기 식별자
- Push-to-Start 토큰 또는 활동 갱신 토큰의 종류
- 현재 토큰과 이전 토큰의 교체 시각
- 개발 환경 또는 운영 환경
- 토큰에 연결된 활동 식별자
- 업로드 성공과 APNs 제출 결과
핵심은 토큰이 출력됐는지가 아닙니다. 최신 토큰이 서버 저장소에서 활성 상태인지, 이전 토큰으로 계속 전송하지 않는지, 새 토큰을 받은 뒤 실제 요청이 그 값으로 나가는지가 통과 조건입니다. 이전 토큰을 즉시 삭제하기보다 교체 이력을 보존하면 전환 중의 실패를 추적하기 쉽습니다.
APNs 요청과 최소 Payload
ActivityKit 푸시를 검수할 때는 요청 헤더와 본문을 한 줄의 서버 로그로 묶습니다. APNs 요청 문서에 따라 Live Activities용 푸시 유형과 토픽을 확인하고, 응답의 apns-id를 대상 토큰과 연결합니다.
시작 이벤트의 최소 구조는 다음처럼 공식 필드 중심으로 검수합니다. 실제 속성과 상태 이름은 앱의 ActivityAttributes 정의와 일치해야 합니다.
{
"aps": {
"timestamp": "<유닉스 시간>",
"event": "start",
"attributes-type": "<활동 속성 타입>",
"attributes": {
"<속성 이름>": "<속성 값>"
},
"content-state": {
"<상태 이름>": "<상태 값>"
},
"alert": {
"title": "<알림 제목>",
"body": "<알림 내용>"
}
}
}
업데이트와 종료는 시작과 같은 이벤트로 처리하지 않습니다. event의 의미, content-state의 디코딩 가능 여부, 종료 상태의 표현을 각각 기록합니다. timestamp가 서버 기준으로 정상 생성됐는지도 확인합니다. APNs 우선순위는 요청 성격에 맞춰 Apple의 APNs 규칙을 적용하며, 문서에 정의된 값인 5와 10을 임의로 섞지 않습니다. 즉시 표시가 필요한 알림과 전력 절약형 전달을 같은 기준으로 처리하지 않습니다.
이 단계의 통과 조건은 네 가지입니다.
- 요청 헤더의 푸시 유형과 토픽이 앱 식별자와 맞습니다.
- 시작 Payload에 필요한 속성과 알림 구조가 있습니다.
content-state가 앱의 Codable 구조로 해석됩니다.- 서버 응답 상태와
apns-id가 토큰별로 저장됩니다.
APNs가 요청을 수락했는데도 기기에서 늦게 보이는 경우가 있습니다. 이는 APNs 수락, 기기 전달, 화면 렌더링을 하나의 성공으로 합칠 수 없다는 뜻입니다.
시간순 연속 갱신 시험
수정 후에는 한 번 시작하는 시험보다 상태 변화를 이어 붙인 시험이 중요합니다. Live Activities 표시와 수명 주기 문서를 기준으로 다음 순서를 고정합니다.
- 활동 시작
- 일반 상태 갱신
- 중요한 상태 갱신
- 만료 상태 전환
- 종료 이벤트 전송
- 잠금 화면과 다이내믹 아일랜드의 최종 상태 확인
각 이벤트에는 서버 요청 기록, APNs 응답, 기기 수신 관찰 결과, 사용자에게 보인 값이 있어야 합니다. 순서가 뒤집힌 요청이 도착했을 때 오래된 상태가 최신 상태를 덮어쓰지 않는지도 확인합니다. 네트워크가 약해진 뒤 연결이 회복되는 상황에서는 마지막으로 유효한 상태에서 다시 이어지는지 봅니다.
제한 조건과 회귀 범위
Live Activities 수정 후 필요한 시험 항목은 정상 흐름만으로 끝나지 않습니다. 잠금 상태, 백그라운드 전환, 약한 네트워크, 기기 재시작, 사용자가 빈번한 갱신을 제한한 경우를 각각 분리합니다. 이때 측정할 값은 임의의 성공률이나 지연 시간이 아니라 다음과 같은 사건의 순서입니다.
- 서버가 어느 토큰으로 요청했는지
- APNs가 어떤 응답과 식별자를 반환했는지
- 기기에서 활동이 유지되었는지
- Payload 해석 오류가 있었는지
- 화면에 최종적으로 어떤 상태가 표시되었는지
iOS 27 실기기에서는 정상인데 운영 환경에서 갱신되지 않으면 어떻게 합니까?
개발 환경과 운영 환경의 토큰, 인증 키, 토픽, 서명된 Bundle ID를 먼저 비교합니다. 운영 로그에 요청이 없으면 서버 라우팅이나 토큰 저장 문제를 의심합니다. APNs 응답은 성공이지만 화면이 바뀌지 않으면 기기 전달 지연, Payload 해석, 앱 상태 매핑을 차례로 분리합니다. 개발 환경에서만 통과했다는 이유로 운영 서버 전체를 재시작하거나 앱을 즉시 되돌리지는 않습니다.
단계적 출시와 방출 점수
아래 표는 기능별 점수가 아니라 증거의 완성도를 평가하는 내부 방출 도구입니다. 각 항목의 점수가 높아도 핵심 증거가 하나라도 없으면 전체 출시를 승인하지 않습니다.
| 검수 영역 | 반드시 남길 증거 | 방출 판단 |
|---|---|---|
| 빌드와 서명 | Xcode 27, SDK, Bundle ID, 권한, 아카이브 정보 | 운영 서명과 일치할 때 통과 |
| 토큰 수명 | 시작 토큰, 갱신 토큰, 교체 기록, 서버 수신 기록 | 최신 토큰으로 전송될 때 통과 |
| APNs 요청 | 헤더, Payload, 대상 토큰, 응답 상태, apns-id |
요청과 응답을 서로 연결할 때 통과 |
| 화면 결과 | 시작부터 종료까지의 실기기 기록 | 최신 유효 상태가 보일 때 통과 |
| 제한 조건 | 잠금, 백그라운드, 약한 네트워크, 재시작 결과 | 복구 결과가 설명될 때 통과 |
| 단계적 출시 | 버전·시스템·기기별 로그와 실패 사례 | 실패 범위를 좁혀 추적할 때 통과 |
권장 점수는 빌드 1점, 토큰 2점, APNs 2점, 화면 2점, 제한 조건 2점, 단계적 출시 1점으로 기록할 수 있습니다. 다만 이 점수는 Apple의 공식 기준이 아니라 팀 내부 운영 도구입니다. 토큰과 화면 증거가 빠진 상태에서 총점만 맞추어 출시하는 방식은 허용하지 않습니다.
출시 전 실행 목록
다음 목록은 테스트 담당자가 그대로 실행할 수 있는 최종 검수표입니다.
- [ ] Xcode 27과 iOS 27 SDK 정보를 기록했습니다.
- [ ] 최종 아카이브의 Bundle ID와 Entitlements를 확인했습니다.
- [ ] 개발 환경과 운영 환경의 토큰을 분리했습니다.
- [ ] Push-to-Start 토큰이 서버에 도착하는 것을 확인했습니다.
- [ ] 활동 시작 뒤 갱신 토큰이 서버에서 교체되는 것을 확인했습니다.
- [ ] 이전 토큰으로 재전송되지 않는지 확인했습니다.
- [ ] Live Activities 푸시 유형과 토픽을 기록했습니다.
- [ ]
timestamp,event,content-state, 속성, 알림 구조를 대조했습니다. - [ ] 모든 APNs 응답에 대상 토큰과
apns-id를 연결했습니다. - [ ] 시작, 일반 갱신, 중요 갱신, 만료, 종료를 순서대로 실행했습니다.
- [ ] 잠금 화면과 다이내믹 아일랜드의 최종 상태를 기록했습니다.
- [ ] 백그라운드, 약한 네트워크, 재시작 조건을 시험했습니다.
- [ ] APNs 수락과 실제 화면 표시를 별도 결과로 저장했습니다.
- [ ] 버전·시스템·기기별 실패 범위를 확인한 뒤 단계적 출시를 승인했습니다.
이 목록에서 하나라도 서버 기록과 실기기 결과를 연결하지 못하면 “수정 완료”로만 표시하고 “전체 출시 가능”으로 표시하지 않습니다. 특히 단일 기기에서 한 번 보인 화면은 초벌 확인에는 쓸 수 있지만 최종 승인 근거가 될 수 없습니다.
임시 Mac 환경을 선택할 때의 기준
Xcode 27 회귀를 진행하면서 기존 Xcode가 설치된 장비와 새 SDK를 같은 환경에 무리하게 섞으면, 어떤 도구 체인으로 아카이브했는지 추적하기 어려워집니다. 오래된 프로젝트를 유지하면서 iOS 27 실기기 검수를 병렬로 해야 한다면 다중 Xcode 환경 분리와 전환 가이드처럼 환경을 분리하는 접근이 먼저입니다.
현재 팀이 로컬 Mac 한 대에 의존한다면 대기 시간이 비용으로 바뀝니다. 동시에 여러 버전의 앱을 검수해야 하는 팀은 JexMac 요금과 이용 방식에서 도구 체인 유지, 원격 접속 방식, 필요한 테스트 기간을 비교할 수 있습니다. 다만 실기기 연결이나 지속적인 대규모 부하가 핵심인 팀에는 원격 Mac 임대가 항상 최선은 아닙니다. 물리 장비가 반드시 필요한 회귀라면 자체 장비를 유지하고, 빌드·로그 확인·병렬 검수처럼 격리 가능한 작업만 원격 환경으로 나누는 편이 합리적입니다.
한 대의 로컬 Mac만 사용하면 Xcode 버전 교체 때 기존 빌드 재현성이 흔들리고, 운영 서명 환경과 테스트 환경이 섞이며, 여러 담당자가 같은 실기기 순서를 기다려야 하는 문제가 생깁니다. 반면 JexMac의 Mac 임대 환경은 필요한 기간에 별도 도구 체인을 확보하고, 팀의 검수 기록과 접근 방식을 사전에 맞출 수 있는 선택지입니다. 따라서 이번처럼 Xcode 27 회귀를 단기간에 병렬화해야 하지만 새 장비를 바로 구매할 이유가 부족한 경우에 먼저 비교할 가치가 있습니다. 최종 선택은 JexMac 도움말에서 접근 방식과 운영 조건을 확인한 뒤, 실기기 필요 여부와 테스트 기간을 기준으로 결정해야 합니다.
출시 전 검수를 위한 전용 원격 맥을 준비하세요
JexMac의 가상화 없는 전용 원격 맥에서 빌드와 반복 검증을 안정적으로 진행할 수 있습니다.