iPhone Duo 스크린샷 요구 사항이 공개됐습니다, 2026년 기업 CI는 어떻게 준비해야 할까요?

앱별 스크린샷은 흩어져 있고, 제출 직전마다 담당자가 누락 여부를 확인하나요?

이번 주에는 앱·언어별 소재와 생성 책임자를 목록화하고, iPhone Duo 스크린샷을 제출 전 검사에 추가하세요. 요구 사항만으로 CI 플랫폼이나 맥 노드를 바꿀 필요는 없습니다. Apple은 해당 규격의 적용 시점을 2027년 4월부터로 안내했으므로, 현재 요건과 앞으로의 준비 항목을 구분해야 합니다 (Apple 공지).

기업 iOS 배포 책임자: 제품 페이지 소재와 버전 제출을 함께 조정해야 하는 분
CI 플랫폼 책임자: 자동 검사와 배포 증거를 연결하려는 분
여러 앱을 관리하는 IT 책임자: 소재 관리가 기존 배포 절차에 미치는 영향을 검토하는 분

발표 시점과 현재 적용 범위

Apple의 공지는 iPhone Duo 스크린샷 요구 사항과 적용 시점을 알립니다. 2026년 10월 13일 기준, 이를 이미 시행 중인 제출 차단 조건으로 취급하지 말고 2027년 4월 적용을 준비하는 일정으로 관리하세요. 적용 대상과 공지 내용은 App Store Connect 출시 노트와 원문 공지를 다시 확인해야 합니다.

여기서 말하는 것은 제품 페이지에 제출하는 스크린샷 소재입니다. 기기 호환성 시험이나 새 기기에서의 동작 검증과는 다른 작업입니다. 제품 페이지 소재가 준비됐다고 앱의 기기별 호환성이 검증되는 것은 아니며, 반대로 호환성 테스트를 통과했다고 스크린샷 제출 요건이 충족되는 것도 아닙니다. 두 결과를 같은 CI 상태로 합치지 말고 별도 증거로 보관하세요.

Xcode 27.1은 스크린샷 요건 자체와 구별해야 합니다. Apple의 Xcode 27.1 출시 노트는 개발 도구 관련 정보를 확인하는 자료이지, 모든 팀에 해당 버전으로 전환하라는 제출 요구가 아닙니다.

준비 단계: 앱·언어별 소재 현황

기존 스크린샷이 어느 앱, 언어, 제품 페이지에 연결되는지부터 기록하세요. 파일만 모으는 방식으로는 최신 버전인지, 실제 제출에 쓸 수 있는지 구분하기 어렵습니다. 아래 항목을 한 행에 하나의 앱과 언어 조합으로 정리하면 담당자와 누락 지점을 찾기 쉽습니다.

공식 요구 범위와 팀의 선제 준비 계획은 별도 필드로 두세요. 예를 들어 아직 적용 전인 요구를 내부 검사 대상으로 삼을 수는 있지만, 이를 현재 Apple 제출의 필수 조건이라고 문서에 적으면 안 됩니다. App Store Connect 스크린샷 규격을 기준으로 앱별 확인 항목을 정리하고, 변경이 있으면 확인 날짜와 담당자도 남기세요.

제작 전 확인: 규격과 화면의 정확성

App Store Connect 스크린샷 규격은 어디서 확인하나요?

Apple의 규격 안내에서 대상 기기, 허용 크기와 방향, 파일 형식 등 현재 표시된 조건을 확인하세요. 규격은 바뀔 수 있으므로 오래된 내부 위키나 과거 제출 파일을 기준으로 고정하지 않는 편이 안전합니다. Apple의 스크린샷 규격 안내를 소재 검토 시점마다 참조하도록 체크리스트에 연결하세요.

화면이 앱의 실제 경험을 정확히 나타내는지도 검토해야 합니다. 실제 앱 화면과 편집된 홍보 디자인을 구분하고, 언어별 문구나 화면 구성이 앱 버전과 맞는지 사람이 확인하세요. Apple의 스크린샷 심사 지침은 제출 이미지가 앱 경험을 정확하게 보여야 한다는 기준을 확인할 때 참고할 수 있습니다. 규격에 맞는 파일이라고 해서 내용 검토까지 통과한 것은 아닙니다.

시뮬레이터에서 만든 이미지가 모든 제출 조건을 자동으로 충족한다고 가정하지 마세요. 생성 도구와 후처리 방식은 팀 환경에서 확인하고, 최종 이미지는 공식 규격과 심사 지침을 각각 대조하세요.

소재 생성과 CI 검사 연결

소재를 누가 만들고 승인하는지 먼저 정하세요. 제품 팀이 화면을 준비하고 QA가 내용과 언어를 검토한 뒤, 배포 담당자가 제출용 파일과 기록을 묶는 식으로 책임을 나누면 누락 원인을 추적하기 쉽습니다. 역할은 조직 구조에 맞게 조정하되, 한 파일의 생성자·검토자·최종 승인 상태를 기록하세요.

파일 원본, 언어, 대상 앱 버전, 검토 결과, 제출용 사본의 위치도 함께 보관하세요. 스크립트나 Xcode 기반 도구를 쓰더라도 자동으로 모든 화면을 만들고 승인할 수 있다고 전제하지 마세요. 팀이 이미 쓰는 환경에서 같은 입력으로 결과가 재현되는지 시험한 다음 자동화 범위를 넓히세요.

CI에는 기계적으로 판별할 수 있는 항목부터 넣으세요. 대상 앱과 언어별 파일 존재 여부, 파일을 읽을 수 있는지, 확인 시점의 규격 조건과 맞는지를 점검하고 결과를 빌드 버전과 연결합니다. 다만 이미지 내용의 정확성, 실제 앱 화면과의 일치, 제품 페이지에서의 표시 상태는 담당자의 검토 대상으로 남겨야 합니다. 자동 검사가 통과해도 Apple이 소재를 승인했다는 뜻은 아닙니다.

기업 iOS CI에서 소재 누락은 어떻게 검사하나요?

검사 대상을 앱·언어 조합으로 정의하고, 각 조합에 필요한 파일과 검토 상태를 CI가 확인하도록 구성하세요. 한 항목이라도 빠지면 어떤 앱과 언어에서 어떤 파일이 누락됐는지 보고하게 하면 수정 요청이 구체적입니다. 파일 검증 결과와 사람의 내용 검토는 별도 상태로 남겨야 합니다.

판단은 다음 조건으로 나눌 수 있습니다.

• 파일 존재, 읽기 가능 여부, 규격상 검사 가능한 속성을 반복 검증할 수 있다면 CI에 자동 검사를 추가하세요.
• 이미지의 실제 내용, 앱 경험과의 일치, 언어 표현을 확인해야 한다면 사람의 승인을 배포 조건으로 두세요.
• 팀이 사용하는 도구에서 재현 가능한 결과를 만들지 못한다면 자동 생성을 강제하지 말고, 수동 생성과 제출 전 검토를 유지하세요.
• 자동 검사는 통과했지만 App Store Connect에서 미리 보지 않은 상태라면 업로드 완료로 간주하지 마세요.

제출 전 시범 운영과 최종 확인

여러 앱으로 한꺼번에 확대하기 전에 한 앱과 언어 조합을 골라 전체 흐름을 시험하세요. 소재 준비, 규격 검사, 사람의 검토, 업로드, 제품 페이지 미리 보기까지 진행하고 각 단계의 담당자와 결과를 기록합니다. 실패 유형에 따라 누락 파일 알림, 재생성, 승인 대기 같은 복구 절차를 정한 뒤 다른 앱으로 확장하세요.

업로드 절차는 Apple의 스크린샷 업로드 안내를 따라 확인하세요. 제출 전 점검을 통과한 시점과 App Store Connect에서 업로드 및 페이지 표시를 확인한 시점은 따로 기록해야 합니다. 이 차이가 있어야 팀 내부 자동화 성공을 Apple의 최종 수락으로 오해하지 않습니다.

iPhone Duo 요구 사항이 기존 앱 제출 흐름을 바꾸나요?

소재 목록화와 제출 전 검사 항목은 추가할 수 있지만, 이 요구만으로 앱 빌드, 서명, 업로드를 담당하는 CI 플랫폼을 교체해야 하는 것은 아닙니다. 기존 파이프라인에 검사 단계를 덧붙일 수 있는지 먼저 확인하고, 병목이 확인된 뒤에야 도구나 노드 변경을 검토하세요.

기존 맥 환경에서 필요한 빌드와 검증 작업을 수행할 수 있다면 우선 그대로 활용하세요. 별도 macOS 환경이 필요한 이유가 소재 생성이 아니라 격리, 동시 작업, 운영 정책 같은 다른 요구인지도 분리해 판단해야 합니다. 독립된 원격 맥 환경의 이용 조건과 신청 절차를 검토해야 한다면 VMSPIN 원격 맥 이용 안내에서 기본 정보를 확인하고, 이어 VMSPIN의 맥 환경 요금 안내를 참고해 현재 파이프라인의 운영 요건과 맞는지 평가할 수 있습니다.

구매한 맥은 장기 상시 부하와 물리 인터페이스가 필요한 경우 더 적합할 수 있습니다. 반면 기존 방식은 장비 관리, 용량 조정의 경직성, 별도 환경 구성 부담이 남을 수 있습니다. 이런 조건이 실제 운영의 제약이라면, 스크린샷 검증이나 iOS 배포 작업을 위한 임시 macOS 환경으로 원격 맥 대여를 검토하세요. 요구 사항만을 이유로 기존 CI나 맥 노드를 교체하지 말고, 확인된 운영상 필요를 기준으로 선택하세요.