앱 스토어 스크린샷 자동화: 2026 fastlane snapshot 원격 맥 튜토리얼

스크린샷이 언어마다 잘리고 기기마다 순서가 달라져 다시 작업하고 있습니까?

페이지가 적고 변경도 드물면 수동 캡처가 빠릅니다. 여러 언어, 여러 기기, 잦은 업데이트가 겹치면 fastlane snapshot을 사용해 캡처 조건을 고정하는 편이 낫습니다. 원격 맥에서는 먼저 테스트 데이터와 시뮬레이터를 고정한 뒤 직렬 실행을 안정화하고, 그다음 병렬 실행과 업로드를 추가해야 합니다.

이 글은 다음 독자를 위한 안내입니다.

  • 여러 지역의 앱 스토어 이미지를 반복 제작하는 독립 개발자
  • 상시 맥은 없지만 Xcode UI Tests와 iOS 시뮬레이터를 실행해야 하는 Windows 또는 Linux 개발자
  • 스크린샷 생성을 배포 과정에 넣으려는 소규모 앱 팀

스크린샷 작업은 캡처, 이미지 장식, 업로드를 한 덩어리로 보면 안 됩니다. 실제로는 다음 네 작업이 분리됩니다.

  1. XCTest UI Tests로 앱 화면을 재현합니다.
  2. fastlane snapshot으로 원본 화면을 캡처합니다.
  3. frameit 같은 도구로 기기 프레임이나 홍보용 구성을 더합니다.
  4. App Store Connect에 언어별 자산을 업로드합니다.

페이지가 적고 한 언어만 사용하며 업데이트가 드물다면 수동 캡처가 합리적입니다. 반대로 같은 화면을 여러 언어와 기기 조합으로 반복해야 한다면 자동화의 가치가 커집니다. 판단 기준은 앱의 크기가 아니라 반복되는 조합의 수와 변경 빈도입니다.

작업 조건 수동 캡처 fastlane snapshot 판단 점수
한 언어, 한 기기, 일회성 작업 적합 설정 부담이 큼 수동 5점
여러 화면, 같은 기기, 잦은 수정 재작업 위험 적합 자동화 4점
여러 언어와 지역 형식 누락 확인이 어려움 조건 재현에 적합 자동화 5점
iPhone과 iPad의 다른 레이아웃 기기 전환이 반복됨 테스트 조합으로 분리 가능 자동화 4점
화면 상태가 네트워크에 의존 수동도 불안정 테스트 데이터 고정이 필수 조건부 3점

이 점수는 성능 측정값이 아니라 작업 방식 선택을 위한 편집 기준입니다. 한 번의 출시에서만 만들 이미지라면 자동화 설정 시간이 더 클 수 있습니다.

처음부터 다국어와 여러 시뮬레이터를 넣으면 오류 원인을 찾기 어렵습니다. 전용 UI Test Target을 만들고, 앱을 실행하는 공유 Scheme을 준비합니다. 테스트 대상의 Bundle ID, Scheme 이름, 테스트 계정은 아래처럼 명확한 자리표시자로 관리합니다.

  • <APP_BUNDLE_ID>
  • <APP_SCHEME>
  • <SCREENSHOT_TEST_TARGET>
  • <TEST_ACCOUNT>

XCTest에서는 접근성 식별자를 기준으로 버튼과 화면을 찾습니다. 화면의 위치나 표시 문자열만 이용하면 지역화 때 테스트가 깨질 수 있습니다. Apple의 XCUIElementQuery 문서처럼 요소를 안정적으로 조회할 수 있는 식별자를 사용해야 합니다.

테스트 데이터도 별도로 만듭니다. 운영 계정의 구매 내역이나 실제 서버 응답을 사용하면 로그인 상태와 화면 내용이 바뀝니다. 앱 시작 시 다음 상태를 선택할 수 있게 하면 반복성이 좋아집니다.

  • 로그인 완료 또는 로그아웃 상태
  • 구독 활성 또는 비활성 상태
  • 항목이 있는 화면 또는 빈 화면
  • 기능 플래그의 켜짐 또는 꺼짐
  • 네트워크 오류와 로딩 완료 상태

첫 성공의 기준은 테스트가 통과했다는 표시 하나가 아닙니다. 캡처 파일이 생성됐는지, 파일명이 정해진 순서인지, HTML 요약에서 실패한 화면이 없는지를 함께 확인해야 합니다. Xcode의 테스트 결과와 로그, 첨부 파일을 확인하는 방법은 Apple의 테스트 결과 안내에서 확인할 수 있습니다.

주의: 원격 화면에서 앱이 보이는 것만 확인하면 안 됩니다. 세션이 끊겨도 테스트 프로세스는 계속 실행될 수 있으므로 로그와 결과 폴더를 별도로 회수하는 경로를 먼저 마련해야 합니다.

fastlane snapshot의 언어 설정은 화면에 표시되는 모든 내용을 자동으로 번역하지 않습니다. 언어 목록, 지역 형식, 앱 내부의 테스트 콘텐츠는 서로 다른 설정입니다.

예를 들어 한국어 화면을 선택했는데 숫자 형식은 다른 지역 기준으로 남거나, 긴 독일어 문장이 버튼 영역을 넘을 수 있습니다. 같은 캡처 지점에서 다음 항목을 비교해야 합니다.

  • 제목과 버튼이 잘리지 않았는지
  • 날짜, 통화, 소수점 표시가 지역에 맞는지
  • 로딩 표시가 남아 있지 않은지
  • 로그인 이름과 상품명이 테스트용 값인지
  • 구독 화면의 상태가 언어별로 동일한지
  • 오른쪽에서 왼쪽으로 읽는 지역을 지원한다면 레이아웃이 뒤집히는지

언어별 실행에서는 앱 시작 인자에 <LOCALE>, <REGION>, <DATA_PROFILE> 같은 값을 전달하는 방식이 관리하기 쉽습니다. 테스트 코드 안에 언어별 분기를 계속 추가하는 방식은 화면이 늘어날수록 유지보수 비용이 커집니다.

fastlane의 iOS 스크린샷 공식 안내는 시뮬레이터와 언어별 캡처 구성을 설명합니다. 실제 프로젝트에서는 공식 예시의 이름을 그대로 복사하기보다 팀의 Scheme과 기기 목록에 맞춰 분리해야 합니다.

모든 Simulator Runtime과 모든 기기를 무조건 실행하는 것은 좋은 자동화가 아닙니다. 먼저 현재 App Store Connect에서 요구하는 표시 대상과 앱이 지원하는 화면 구성을 확인합니다. Apple은 기기별 스크린샷 규격과 허용 형식을 공식 스크린샷 규격 문서에서 안내합니다.

예를 들어 Apple 문서에 기재된 6.9형 iPhone 세로 이미지 규격은 1320 × 2868 픽셀이고, 13형 iPad 세로 이미지 규격은 2064 × 2752 픽셀입니다. 이 값은 프로젝트의 실제 출력과 반드시 대조해야 합니다. 지원하지 않는 화면을 억지로 추가하면 실행 시간과 검수 범위만 늘어납니다.

기기 조합은 다음처럼 그룹으로 관리합니다.

  • 세로형 iPhone 기본 흐름
  • 가로형 iPhone 또는 게임 화면
  • iPad 전용 레이아웃
  • 로그인 화면과 빈 상태 화면
  • 기능 설명용 핵심 화면

App Store Connect가 자동으로 크기를 조정할 수 있는 경우와 특정 크기의 맞춤 이미지를 직접 제공해야 하는 경우도 구분해야 합니다. 업로드 전에는 파일의 픽셀 크기, 확장자, 방향, 투명 영역을 검사합니다. App Store Connect 업로드 안내는 표시 대상과 업로드 처리 상태를 확인하는 기준입니다.

원격 맥에서 스크린샷 자동화는 데스크톱 화면을 계속 지켜보는 작업이 아닙니다. 필요한 것은 Xcode, 해당 Simulator Runtime, 충분한 저장 공간, 로그인된 사용자 세션, 결과 파일을 꺼내는 방법입니다.

실행 순서는 다음이 안전합니다.

1. 실행 환경을 고정합니다

Xcode 버전, 설치된 Simulator Runtime, Scheme, 언어 목록을 기록합니다. 개발자의 로컬 환경과 원격 환경이 다르면 캡처 결과가 달라질 수 있습니다.

2. 한 기기만 실행합니다

단일 언어와 단일 기기로 테스트합니다. 앱 시작, 로그인, 화면 이동, 캡처, 종료가 모두 끝나는지 확인합니다.

3. 결과 폴더를 보존합니다

원본 이미지, HTML 요약, 표준 출력 로그, 오류 로그를 작업 번호와 함께 저장합니다. 화면만 저장하고 로그를 버리면 실패한 단계가 사라집니다.

4. 언어를 하나씩 늘립니다

언어를 추가할 때마다 같은 화면 지점의 내용과 파일 이름을 확인합니다. 특정 언어만 실패한다면 테스트 데이터나 지역 형식부터 비교합니다.

5. 기기를 조합합니다

iPhone 기본 흐름이 안정된 뒤 iPad와 가로 화면을 추가합니다. 기기별 레이아웃 분기를 테스트 코드에 명시합니다.

6. 병렬 실행을 제한적으로 시도합니다

여러 시뮬레이터를 동시에 실행하면 CPU, 메모리, 그래픽 자원, 디스크 입출력이 겹칩니다. 실패가 생기면 병렬 수를 다시 줄이고, 실패한 기기만 단독으로 재실행합니다. snapshot의 기기, 언어, 출력 관련 설정은 공식 action 문서를 기준으로 확인합니다.

7. 연결이 끊겨도 회복되게 만듭니다

SSH 세션이나 원격 데스크톱이 끊겨도 작업이 종료되지 않도록 별도의 터미널 세션이나 CI 실행기를 사용합니다. 완료 후에는 결과 폴더를 내려받고, 실패한 조합만 다시 실행합니다.

원격 맥을 장기간 켜둘 필요가 있는지 판단할 때는 맥 미니 렌탈 요금과 이용 조건도 함께 비교할 수 있습니다. 단발성 출시라면 필요한 기간만 확보하고, 매주 이미지가 갱신되는 앱이라면 상시 실행 환경을 검토하는 방식이 맞습니다.

다국어 캡처가 같은 화면을 보장하지 않을 때

언어만 바꾸고 지역과 테스트 데이터까지 바꾸지 않으면 캡처마다 내용이 달라집니다. 실행 인자와 테스트 계정 상태를 하나의 설정 파일에서 관리하고, 같은 화면 식별자를 사용해야 합니다.

맥 없이 대량 캡처해야 할 때

원격 맥은 Xcode와 시뮬레이터를 실행할 실제 macOS 환경으로 사용할 수 있습니다. 다만 원격 접속 자체가 자동화를 대신하지는 않습니다. 테스트 실행, 로그 보관, 파일 회수, 실패한 조합의 재실행 명령까지 스크립트로 준비해야 합니다.

병렬 실행이 불안정할 때

처음부터 여러 대를 동시에 실행하지 않습니다. 단일 기기의 성공 결과를 기준선으로 삼은 뒤 하나씩 추가합니다. 특정 조합만 반복 실패하면 병렬 수보다 해당 기기의 Runtime, 레이아웃, 테스트 데이터 초기화를 먼저 점검합니다.

원본 캡처가 정확하다고 해서 스토어 등록이 끝난 것은 아닙니다. frameit은 원본 화면을 기기 프레임이나 홍보 이미지 형태로 구성하는 단계입니다. 관련 설정은 fastlane frameit 공식 문서를 따릅니다.

업로드 전에는 다음 순서로 검수합니다.

  • 언어별 폴더가 올바른 지역에 연결됐는지 확인합니다.
  • 화면의 표시 대상과 실제 기기 조합을 대조합니다.
  • 파일명 순서가 스토어에서 의도한 순서인지 확인합니다.
  • 잘린 글자, 빈 화면, 로딩 화면, 테스트 계정 정보가 없는지 봅니다.
  • 대표 언어와 가장 긴 문장이 있는 언어를 사람 눈으로 다시 확인합니다.
  • 업로드 뒤 처리 상태와 오류 메시지를 확인합니다.
  • 설정 파일과 생성 결과를 함께 보관해 같은 결과를 다시 만들 수 있게 합니다.

자동 업로드는 마지막에 넣어야 합니다. 캡처 오류가 남아 있는 상태에서 업로드까지 자동화하면 잘못된 이미지가 여러 지역에 동시에 퍼질 수 있습니다.

한두 화면을 한 번만 만들 때는 수동 캡처가 빠릅니다. 반면 지역화 버전, 기기 레이아웃, 화면 상태가 반복되면 fastlane snapshot이 재현성을 제공합니다. 원격 맥은 특히 상시 맥을 따로 두기 어려운 개발자가 이 반복 작업을 배치로 실행할 때 유용합니다.

현재 사용하는 Windows 또는 Linux 방식은 Xcode와 iOS Simulator를 직접 실행할 수 없고, 별도 환경을 조합하면 접속 지연과 파일 회수 과정이 추가됩니다. 로컬 맥을 새로 구매하면 초기 하드웨어 비용과 저장 공간 관리 부담이 생깁니다. 클라우드 기반 빌드만 사용하면 화면 상태를 직접 확인하거나 테스트 흐름을 세밀하게 조정하기 어려운 경우도 있습니다.

따라서 작은 일회성 작업에는 수동 캡처를 유지하고, 반복되는 다국어·다기기 작업에는 원격 맥을 별도 실행 환경으로 두는 편이 현실적입니다. 필요한 기간만 macOS 환경을 확보하려면 NOVAKVM의 원격 맥 환경을 확인한 뒤, 먼저 단일 기기 기준선과 결과 회수 절차를 검증하는 것이 좋습니다.

자주 묻는 질문

fastlane snapshot으로 여러 언어의 앱 스토어 이미지를 만들려면 무엇을 고정해야 하나요?

언어 목록만 지정해서는 충분하지 않습니다. 각 언어의 지역 형식, 로그인 상태, 구독 상태, 테스트 데이터, 화면 이동 순서를 함께 고정해야 합니다. 전용 UI 테스트 대상과 공유 Scheme을 만든 뒤 snapshot 설정에 언어와 기기를 연결하면 같은 화면 지점에서 반복 캡처할 수 있습니다.

맥이 없어도 iOS 앱 스크린샷을 여러 장 자동으로 만들 수 있나요?

가능합니다. 다만 실행 환경에는 Xcode, 필요한 Simulator Runtime, iOS 시뮬레이터가 있어야 합니다. 원격 맥에 접속해 XCTest UI Tests와 fastlane snapshot을 실행하는 방식입니다. 처음부터 여러 기기를 동시에 돌리지 말고 단일 기기에서 파일 생성과 테스트 결과를 먼저 확인해야 실패 원인을 좁힐 수 있습니다.

fastlane snapshot에서 로그인 상태와 테스트 데이터를 어떻게 일정하게 유지하나요?

실제 사용자의 계정이나 운영 데이터에 의존하지 않는 별도 테스트 계정을 사용합니다. 앱 시작 인자로 로그인 상태, 구독 상태, 빈 데이터 여부, 기능 플래그를 전달하고 테스트 시작 전에 앱 데이터를 초기화합니다. 네트워크 응답이 바뀌면 이미지도 달라지므로 고정된 로컬 응답이나 통제된 테스트 환경이 적합합니다.

원격 맥에서 iOS 시뮬레이터를 여러 대 동시에 실행하면 왜 자주 실패하나요?

여러 시뮬레이터가 같은 시간에 CPU, 메모리, 저장 공간, 그래픽 자원과 사용자 세션을 함께 사용하기 때문입니다. 원격 화면 연결이 끊기면 실패한 것처럼 보일 수도 있습니다. 먼저 직렬 실행으로 기준선을 만들고, 로그와 결과 파일을 회수한 뒤 실제 자원 여유가 확인될 때만 병렬 수를 늘리는 편이 안전합니다.

앱 출시용 스크린샷 작업을 원격 맥으로 간편하게 시작해 보세요

NOVAKVM의 원격 맥에서 패스트레인 스냅샷을 실행하고 반복적인 스크린샷 작업을 안정적으로 자동화할 수 있습니다.

언어별 화면과 다양한 기기 설정을 관리하면서 앱 출시용 이미지를 효율적으로 준비할 수 있습니다.

가격 보기 →