Developer Device Platform의 모바일 테스트 경로 설계

1. ‘왜 모바일 CI는 기기가 늘어도 느릴까?’ DDP가 바꾸는 실행 단위

2026년 8월 10일 Google Cloud는 Developer Device Platform(DDP)을 발표했고, 8월 12일부터 공개 프리뷰로 제공하고 있다. 공식 릴리스 노트 기준 DDP는 Android 개발자를 위한 엔터프라이즈 규모의 클라우드 네이티브 기기 팜으로, Device Catalog, Device Run, 로그 조회, Device Streaming API와 에이전트 기반 기기 연결을 포함한다. 이는 정식 출시가 아니다. 프리뷰 기능은 제한된 지원과 변경 가능성을 전제로 하며, Google은 현재 CLI 중심 Android 제공 이후 콘솔 통합과 iOS 지원을 계획하고 있다고 명시한다.

이 사건이 중요한 이유는 모바일 테스트가 더 이상 ‘기기 몇 대를 빌릴 것인가’라는 조달 문제에만 머물지 않기 때문이다. 물리 기기는 카메라·GPU·폴더블 화면·제조사 이미지처럼 실제 하드웨어에서만 드러나는 결함을 검증한다. 반면 에뮬레이터는 넓은 API 수준과 화면 조합을 빠르게 훑는 데 유리하다. 기존에는 이 두 실행 환경과 결과가 별도 도구·별도 대기열로 흩어지기 쉬웠다. DDP는 원격 물리 Android 기기와 고동시성 가상 에뮬레이터에 온디맨드로 접근하고, 스트리밍·CI 실행을 같은 플랫폼에 두려는 선택이다.

Google Cloud는 Device Streaming으로 원격 물리 기기 또는 에뮬레이터를 직접 조작하고, Device Run으로 CI/CD에서 수백 기기에 병렬 실행할 수 있다고 설명한다. 또한 에이전트가 다단계 사용자 흐름, 시각적 결함, 기기 성능을 확인하도록 하는 방향을 제시한다. 그러나 에이전트가 기기를 조작할 수 있다는 사실만으로 테스트 전략이 완성되는 것은 아니다. 다음 질문은 어떤 테스트를 어디에 보내고, 실패했을 때 얼마나 다시 실행할 것인가다.

2. ‘모든 테스트를 실기기에 보내면 안전할까?’ 기기 행렬을 위험으로 분할하는 법

모바일 테스트 매트릭스는 넓을수록 좋은 것이 아니다. 모든 PR에서 모든 물리 기기·모든 OS·모든 화면 비율을 실행하면 신뢰도는 잠시 높아 보이지만, 큐 대기·비용·피드백 지연이 개발 흐름을 압박한다. 반대로 에뮬레이터만 쓰면 빠르지만 실제 드라이버, 성능 제약, 제조사 특성에서 발생하는 오류를 놓칠 수 있다. 따라서 테스트를 기능 이름이 아니라 실패의 성격으로 나누는 편이 낫다.

[변경 감지]
   ├─ UI 레이아웃·API 호환성 → 에뮬레이터 샤드: 넓은 조합, 빠른 피드백
   ├─ 카메라·GPU·폴더블·성능 → 물리 기기 샤드: 실제 하드웨어 검증
   ├─ 핵심 구매·로그인 경로 → 고정 기준 기기: 배포 차단 신호
   └─ 에이전트 탐색 → 후보 결함·시각 이상 탐지 → 결정적 테스트로 재검증

이 구조에서 에이전트의 산출물은 배포 승인 자체가 아니라 조사 후보여야 한다. 에이전트가 화면 이상을 발견하거나 다단계 흐름을 통과했다 해도, 재현 가능한 입력·기기 프로필·관측 로그가 없으면 CI의 결정 신호가 될 수 없다. 특히 프리뷰 단계에서는 API와 지원 범위가 변할 수 있으므로, 기존의 결정적 테스트와 롤백 경로를 유지한 채 작은 매트릭스부터 붙이는 것이 안전하다.

기기 선택도 정적 목록이 아니라 제품 위험에 맞춰야 한다. 폴더블 UI가 핵심이 아닌 앱이라면 폴더블 기기 전체를 모든 실행에 넣을 이유가 없다. 반대로 카메라, 오프라인 동기화, 고주사율 렌더링이 핵심이라면 그 특성을 대표하는 물리 기기를 배포 차단 집합에 둬야 한다. 문제는 기기 다양성 자체가 아니라, 고객 약속과 기기 특성 사이의 연결을 잃는 순간 시작된다. 이제 이 분할을 CI의 재시도와 비용 제어로 연결해 보자.

3. ‘전체 재실행이 왜 결함을 더 늦게 찾을까?’ 샤드 실패만 격리하는 재시도 경로

▲ 샤딩의 목적은 병렬 수를 늘리는 데 있지 않다. 실패를 해당 기기·입력·로그와 함께 좁혀 전체 재실행을 피하는 데 있다.

Google Cloud는 DDP의 Device Run이 다수의 기기에 병렬 실행하고, 스마트 샤딩과 자동 재시도로 실패한 샤드를 다시 처리할 수 있다고 설명한다. 이 기능은 특히 긴 기기 매트릭스에서 전체 파이프라인을 다시 돌리는 비용을 줄일 가능성이 있다. 하지만 자동 재시도가 처음 실패를 지워서는 안 된다. 재시도 전 결과와 재시도 뒤 결과가 섞이면 네트워크 흔들림, 비결정적 UI 대기, 기기 상태 오염, 실제 회귀 결함을 구별할 근거가 사라진다.

DDP의 분당 과금 모델도 경로 설계를 요구한다. 물리 기기와 에뮬레이터의 요금이 다르고 프리뷰 상태에서는 제품·지원 범위가 바뀔 수 있으므로, 단순히 병렬도를 최대로 올리는 방식은 비용을 예측하기 어렵게 만든다. 테스트 집합마다 ‘실기기가 필요한가’, ‘매 PR인가 야간인가’, ‘실패 시 한 번만 재시도할 것인가’를 명시해야 한다. 성능 개선율을 보편 수치로 약속할 수는 없지만, 각 팀은 큐 대기, 실행 시간, 실패 샤드 비율, 재현 성공률, 분당 테스트 비용을 같은 릴리스 단위에서 비교할 수 있다.

그렇다면 자동 재시도를 크게 잡아 불안정함을 흡수하면 되지 않을까? 그렇지 않다. 다음 절의 안티패턴은 편리한 재시도가 어떻게 실패 신호를 숨기고, 에이전트의 탐색 결과가 어떻게 승인 신호로 오용되는지를 다룬다.

4. ‘자동 재시도가 초록색을 만들면 안전한가?’ 프리뷰 도입의 세 가지 안티패턴

첫째, 재시도 통과를 테스트 통과와 같게 취급하는 일이다. 재시도는 불안정한 샤드를 격리하기 위한 도구이지, 실패 원인을 없애는 도구가 아니다. 첫 실패와 재시도 결과를 별도 지표로 남기고, 같은 기기·테스트 묶음에서 반복되는 재시도는 격리·수정 대상으로 승격해야 한다.

둘째, 물리 기기 검증을 모든 테스트에 강제하는 일이다. 실제 기기는 귀중한 신호를 주지만, 모든 회귀 테스트에 같은 비용을 쓰면 개발 피드백이 늦어진다. 하드웨어 의존 위험이 높은 경로만 물리 기준 집합에 두고, 넓은 조합 탐색은 에뮬레이터로 분리해야 한다.

셋째, 프리뷰 기능을 기존 배포 차단 규칙보다 앞세우는 일이다. 현재 DDP는 공개 프리뷰이며 Android 중심 CLI 제공 단계다. 기능이 유용해도 핵심 배포 경로는 기존 테스트와 함께 이중으로 검증하고, API 변경·할당량·기기 가용성 문제가 생겼을 때 되돌아갈 실행 경로를 문서화해야 한다.

5. ‘다음 스프린트에는 어디서 시작할까?’ DDP 공개 프리뷰 도입 3단계

프리뷰의 비용과 가용성도 도입 판단에 넣어야 한다. 테스트가 길어지는 이유가 코드 회귀인지, 기기 예약 대기인지, 특정 제조사 프로필의 가용성인지 분리해 기록하지 않으면 팀은 플랫폼 자체의 병목을 제품 결함으로 오해할 수 있다. 반대로 예약 대기와 실행 시간을 분리하면, 야간 확장 실행으로 옮길 집합과 PR 단계에 남길 집합을 근거 있게 나눌 수 있다. 이 구분은 DDP가 정식 출시로 바뀌거나 지원 범위가 넓어진 뒤에도 그대로 남는 운영 자산이다.

도입 초기에 가장 피해야 할 것은 기존 테스트 자산을 한꺼번에 옮기는 일이다. 한 경로에서 장애 재현과 비용 관측이 가능한지 먼저 확인하고, 기준선이 확보된 뒤에만 기기 집합과 병렬도를 확장해야 한다. 실패를 설명하지 못하는 초록색 결과는 품질 지표가 아니며, 다음 변경의 근거도 될 수 없다.

DDP가 제시하는 변화는 테스트를 더 많이 실행한다는 선언이 아니다. 실제 기기, 가상 기기, 에이전트의 역할을 분리하고 실패한 샤드만 다시 돌릴 수 있게 CI의 경계를 바꾸는 일이다. 공개 프리뷰의 제약을 인정한 채 작은 집합에서 기기·비용·재시도 증거를 모으면, 모바일 품질은 기기 수가 아니라 재현 가능한 실행 경로로 관리할 수 있다.

모바일 테스트의 신뢰는 모든 기기를 매번 돌렸다는 사실이 아니라, 실패가 어느 기기에서 왜 발생했고 어떤 경로로 다시 검증됐는지 설명할 수 있을 때 생긴다.

공식 참고 자료

• Google Cloud: Introducing the Developer Device Platform
• Google Cloud: Developer Device Platform release notes

참고 자료 (References)

• Android Developers - Testing Fundamentals on Android
• Apple Developer - Testing Your Apps with XCTest