App Store 스크린샷을 손으로 만든다고 가정하면, 그 계산은 꽤나 가혹합니다.

3가지 디바이스 크기, 6개 로케일, 5장의 스크린샷 프레임을 지원한다면 관리해야 할 스크린샷은 90장에 이릅니다. UI를 변경하거나, 오버레이 텍스트를 수정하거나, Apple이 새 iPhone을 출시했을 때 디바이스 프레임을 조정하면 그 90장을 전부 다시 만들어야 합니다. 그것도 손으로 말이죠.

대부분의 인디 개발자는 이 작업을 한 번 해보고 그 비용을 실감한 뒤, 정작 해야 할 만큼 자주 스크린샷을 업데이트하지 않게 됩니다. 이 결정이 방문이 일어날 때마다 제품 페이지의 전환율을 조용히 떨어뜨립니다.

스크린샷 자동화는 이 문제를 해결하지만, 도구의 선택지는 “정말 도입할 가치가 있는 것”부터 “절약하는 시간보다 손이 더 많이 가는 것”까지 폭넓게 존재합니다. 이 글에서는 스크린샷 자동화가 실제로 무엇을 의미하는지, 흔한 접근 방식, 그리고 수작업 방식을 넘어설 시점을 어떻게 판단하는지 다룹니다.

스크린샷 자동화란 무엇인가

App Store 스크린샷 자동화란 디바이스, 언어, 프레임의 모든 조합에 대해 손으로 작업하지 않고도 디바이스 스크린샷의 생성, 프레이밍, 업로드를 프로그램적으로 수행하는 워크플로를 말합니다.

실제로는 보통 다음 중 하나 이상을 의미합니다.

UI 테스트 기반 캡처. 자동화된 UI 테스트를 실행하여 앱의 특정 상태에서 스크린샷 캡처를 트리거합니다. 이 접근 방식의 구현으로 가장 널리 알려진 것이 fastlane의 snapshot 도구입니다.

디바이스 프레이밍. 원본 스크린샷을 디바이스 베젤 안에 배치하고 텍스트 오버레이를 프로그램적으로 추가합니다. 일반적으로 fastlane의 frameit이나 그에 준하는 도구를 사용합니다.

로컬라이즈된 텍스트 주입. 각 스크린샷의 오버레이 텍스트를 올바른 언어로 치환하여, 프랑스어 제품 페이지에는 프랑스어 캡션이, 일본어 페이지에는 일본어 캡션이 표시되도록 합니다.

일괄 업로드. 완성된 스크린샷을 ASC API를 통해 App Store Connect로 전송합니다. 많은 경우 CI/CD 파이프라인의 일부로 이루어집니다.

완전한 스크린샷 자동화 파이프라인은 이 네 단계를 모두 처리합니다. 대부분의 개발자는 한두 단계를 자동화하고 나머지는 손으로 처리합니다.

Fastlane 방식

Fastlane은 iOS 스크린샷 자동화 툴킷으로 가장 널리 알려져 있습니다. snapshot 도구는 시뮬레이터에서 UI 테스트를 실행하여 스크린샷을 캡처하고 결과물을 저장합니다. frameit 도구는 그 스크린샷을 받아 선택적으로 텍스트 오버레이를 붙여 디바이스 프레임 안에 배치합니다.

이미 배포에 fastlane을 사용하고 있는 개발자라면, 스크린샷 자동화를 추가하는 것은 기존 지식의 연장선에서 이뤄집니다. 설정은 Fastfile에 작성하고, 테스트는 시뮬레이터에서 실행되며, 결과물은 프레임이 입혀진 스크린샷 폴더가 됩니다.

실제로 마주치는 마찰 지점은 다음과 같습니다.

디바이스 프레임 업데이트가 하드웨어 출시를 따라가지 못한다. 새 iPhone 모델이 출시되면 frameit에 포함된 템플릿이 오래된 상태일 수 있어, 새 디바이스용으로 올바르게 프레이밍된 스크린샷을 생성하기 전에 수동 업데이트나 커뮤니티 패치가 필요할 수 있습니다.

로컬 머신 의존성. fastlane snapshot은 기본적으로 본인의 머신에서 실행됩니다. 90장의 스크린샷을 실행하는 데 최신 하드웨어에서도 30~40분이 걸릴 수 있으며, 그동안 컴퓨터가 점유됩니다.

로컬라이제이션 부담. 새 로케일을 추가하려면 snapshot이 로컬라이즈된 문자열을 받을 수 있도록 설정하고, 해당 로케일용 텍스트 파일을 업데이트하고, 모든 스크린샷을 재생성한 뒤 업로드해야 합니다. 파이프라인을 완전히 자동화하지 않았다면 각 단계가 수작업이 됩니다.

DevOps에 투입할 여력이 있는 팀에게는 이 문제들이 충분히 다룰 만합니다. 하지만 기능을 출시해야 하는 1인 개발자에게는 스크린샷 갱신을 미루는 이유가 되어버립니다.

자동화가 가치 있는 시점

스크린샷 자동화는 다음 중 어느 하나라도 해당될 때 가장 빠르게 투자를 회수합니다.

여러 로케일을 지원한다. 단 2개 언어만 되어도 스크린샷 수는 두 배가 됩니다. 로케일별 텍스트 주입을 처리해 주는 자동화가 있으면, 본래 40분이 걸릴 작업을 다른 일을 하는 동안 돌아가는 CI 작업으로 바꿀 수 있습니다.

UI를 자주 업데이트한다. 기능 릴리스마다 스크린샷의 시각적 상태가 바뀐다면, 릴리스 주기마다 손으로 다시 만드는 작업이 순식간에 쌓입니다. 자동화는 릴리스의 병목이 되지 않으면서 스크린샷을 최신 상태로 유지합니다.

제품 페이지 전환율을 테스트하고 있다. App Store Connect에서 Product Page Optimization 테스트를 실행하려면 처리(treatment) 변형을 위한 두 번째 스크린샷 세트가 필요합니다. 그 세트를 자동화로 만드는 것이 대안을 손으로 만들어 업로드하는 것보다 훨씬 빠릅니다.

2가지를 초과하는 디바이스 크기를 지원한다. iPhone 15 시리즈, iPhone 16 시리즈, iPad — 각각 고유한 스크린샷 요구 사항을 가집니다. 3~5가지 디바이스 포맷을 손으로 관리하는 것은 확장성이 없습니다.

대부분의 인디 개발자에게 분기점은 대략 로케일 2개, 디바이스 타깃 2개 정도에 있습니다. 그 아래라면 수작업 워크플로도 충분히 정당화됩니다. 그 위라면 자동화가 설정에 드는 비용보다 더 많은 시간을 절약해 줍니다.

현대적인 스크린샷 파이프라인의 모습

1인 인디 개발자를 위한 완전한 자동화 파이프라인은 다음과 같이 동작합니다.

  1. 특정 앱 상태에 도달하여 각 상태마다 스크린샷 함수를 호출하는 UI 테스트
  2. 그 테스트들을 모든 대상 디바이스 시뮬레이터에 대해 실행하는 CI 트리거(브랜치 푸시, 릴리스 태그, 또는 수동 실행을 계기로 작동)
  3. 디바이스 오버레이를 적용하고 로케일별로 올바른 로컬라이즈된 텍스트를 주입하는 프레이밍 단계
  4. 완성된 스크린샷을 ASC API를 통해 App Store Connect로 전송하는 업로드 단계

더 단순한 로컬 fastlane 구성과의 결정적인 차이는, CI 트리거 덕분에 파이프라인이 본인의 머신이 아니라 클라우드에서 실행된다는 점입니다. 코드를 푸시하면 스크린샷이 생성됩니다. 결과물을 검토하고, 문제없어 보이면 승인한 뒤, 다음 작업으로 넘어가면 됩니다.

Marteso는 이 모델을 중심으로 만들어졌습니다. 저장소를 연결해 두면 푸시를 계기로 스크린샷 파이프라인을 자동으로 트리거할 수 있습니다. 프레이밍과 로컬라이제이션 단계는 여러분의 노트북이 아니라 Marteso의 인프라에서 실행됩니다. 결과물은 App Store Connect에 도달하기 전에 대시보드에 표시되어 검토할 수 있습니다.

목표는 이 과정에서 개발자의 판단을 없애는 것이 아닙니다. 40분짜리 로컬 실행을 없애서, 그 시간을 출력을 기다리는 데가 아니라 출력을 검토하는 데 쓸 수 있도록 하는 것입니다.

오래된 스크린샷이 낳는 숨은 비용

제품 페이지 데이터에서 일관되게 나타나는 패턴이 있습니다. 스크린샷 파이프라인을 자동화한 개발자는 손으로 작업하는 개발자보다 스크린샷을 더 자주 업데이트한다는 것입니다. 이 자체는 놀라운 일이 아닙니다. 놀라운 것은 전환율 차이의 크기입니다.

스크린샷이 오래되면 보통 다음과 같은 문제 중 하나 이상을 안고 있습니다.

  • 스크린샷에 보이는 UI 요소가 현재 앱과 일치하지 않아, 사용자가 설치한 뒤 다른 것을 보게 될 때 인지적 마찰이 생긴다
  • 오버레이 텍스트가 이후 작업으로 대체된 기능이나 가치 제안을 가리킨다
  • 영어가 아닌 로케일이 업데이트를 미룬 탓에 영어 텍스트를 표시한다

이들 각각은 작은 전환율 저해 요인입니다. 합쳐지면, 실제 앱의 품질에 비해 제품 페이지가 줄곧 제 실력을 발휘하지 못하는 상태를 만들어 냅니다.

해법은 더 나은 스크린샷 전략이 아닙니다. 업데이트 과정의 마찰을 줄여, 평소 개발의 부산물로서 스크린샷이 최신 상태로 유지되도록 하는 것입니다.

간단한 점검

지금 스크린샷을 손으로 관리하고 있다면, 다음 질문들을 짚어 보세요.

  1. 관리하는 스크린샷은 총 몇 장입니까(디바이스 수 × 로케일 수 × 프레임 수)?
  2. 마지막으로 업데이트한 것이 언제입니까?
  3. 그 이후로 UI가 스크린샷에 보이는 형태로 바뀌었습니까?
  4. 현재 영어 텍스트를 표시하고 있는 로컬라이제이션이 있습니까?

질문 3 또는 4의 답이 “예”라면, 제품 페이지 전환율을 은밀히 떨어뜨리고 있는 스크린샷 부채를 안고 있는 것입니다. 영어가 아닌 시장의 사용자가 영어 텍스트를 마주치며 겪는 마찰은 App Store Connect 어디에도 드러나지 않고 오직 전환율 데이터에만 나타납니다.

스크린샷 자동화는 화려한 인프라가 아닙니다. 그것은 ASO 작업의 다른 모든 것을 실제로 의미 있게 만들어 주는, 눈에 띄지 않는 배관과 같은 일입니다.

Marteso는 iOS 스크린샷의 생성, 프레이밍, 로컬라이제이션을 CI에 연결된 단일 파이프라인으로 자동화합니다. app.marteso.com에서 시작하세요.