개념
에뮬레이터(Emulator)와 시뮬레이터(Simulator)
컴퓨터 안에서 모바일 기기를 소프트웨어로 흉내 낸 것이다(Android는 에뮬레이터, iOS는 시뮬레이터라 부른다). 모듈 14(레슨 3)에서 배운 Docker 컨테이너와 비슷하게, 실제 하드웨어 없이도 빠르게 환경을 만들고 없앨 수 있다는 장점이 있다.
실기기와 에뮬레이터의 차이
모듈 7(레슨 3)에서 배운 환경 패리티 개념이 여기서 가장 극명하게 드러난다.
| 에뮬레이터/시뮬레이터 | 실기기 | |
|---|---|---|
| 속도·비용 | 빠르고 저렴, 대량으로 병렬 실행 쉬움 | 느리고 관리 비용이 큼 |
| 하드웨어 센서 | 카메라·GPS·지문인식 등을 흉내만 냄 | 진짜 하드웨어 동작 확인 가능 |
| 성능 특성 | 컴퓨터 성능에 좌우되어 실제와 다를 수 있음 | 실제 배터리 소모·발열·성능(레슨 4) 그대로 |
| 인터럽트 상황 | 전화·알림 등을 재현하기 어려움 | 실제 전화·알림 등을 그대로 테스트 가능(레슨 1) |
| 네트워크 환경 | 대부분 안정적인 네트워크로 고정 | 실제 이동 중 전파 약화, 네트워크 전환 등을 겪을 수 있음 |
에뮬레이터가 적합한 경우
- 빠른 반복 개발 중 확인(레슨 2~4를 배우는 학습 단계 포함)
- 모듈 13(레슨 8)에서 배운 대규모 화면 크기·OS 버전 조합의 1차 스크리닝(넓게, 빠르게 훑어보기)
- CI 파이프라인(모듈 14)에서 매 커밋마다 도는 자동화 테스트 — 실기기를 매번 쓰기엔 비용·속도 부담이 크다
실기기가 반드시 필요한 경우
- 카메라·지문인식·NFC 같은 실제 하드웨어 센서를 검증할 때
- 레슨 4에서 배운 배터리 소모·발열 같은, 에뮬레이터로는 정확히 재현 안 되는 성능 특성을 확인할 때
- 레슨 1에서 배운 인터럽트 시나리오(실제 전화, 실제 알림)를 검증할 때
- 최종 릴리스 전, 사용자가 실제로 쓸 환경과 최대한 가까운 조건에서 마지막 확인을 할 때
균형 잡힌 전략
모듈 11(레슨 5)에서 배운 전략 수립 원칙처럼, "에뮬레이터만" 또는 "실기기만"이 정답이 아니다.
개발·CI 단계: 에뮬레이터/시뮬레이터로 빠르게 반복
릴리스 전 핵심 검증: 실제 사용자가 많이 쓰는 기종의 실기기로 최종 확인이건 모듈 13(레슨 8)에서 배운 "핵심 흐름은 폭넓게, 일반 기능은 좁게"라는 커버리지 깊이 조절 원칙과 정확히 같은 논리다.
클라우드 실기기 팜
자체적으로 수십 종의 실기기를 다 갖추기는 비현실적이다. 모듈 13(레슨 8)에서 언급한 클라우드 디바이스 팜(BrowserStack, AWS Device Farm 등)을 통해, 필요할 때만 다양한 실기기를 원격으로 빌려 쓰는 방식이 실무에서 널리 쓰인다 — 모듈 11(레슨 3)의 ROI 관점에서, 자체 기기 구매·관리보다 합리적인 경우가 많다.
이 모듈을 종합하며
이 마지막 레슨은 모듈 17 전체를 하나로 묶는다 — 앱 생명주기와 인터럽트(레슨 1), 플랫폼별 관습(레슨 2), OS 업데이트 대응(레슨 3), 성능·크래시 모니터링(레슨 4)에서 배운 검증 항목들 중 상당수는 에뮬레이터로는 정확히 재현되지 않는다. 그래서 이 모듈의 마지막 판단은 "우리가 지금까지 배운 모바일 고유의 리스크를, 어느 단계에서 실기기로 반드시 확인할 것인가"로 귀결된다.
실무에서 왜 필요한가
"에뮬레이터에서는 통과했는데 실제 매장에서 써보니 카메라 인식이 느려서 못 쓰겠다는 항의가 왔다"는 사고는, 하드웨어 의존적인 기능을 에뮬레이터로만 검증했을 때 흔히 생긴다. 반대로 모든 테스트를 실기기로만 하려 하면 CI 속도(모듈 14)가 감당 안 될 만큼 느려진다. 언제 무엇을 쓸지 판단하는 QA는 두 세계의 장점을 모두 취할 수 있다.