일기 slecs

테스트 기기 13대로 정리한 CI/CD 최적화

목차

안드로이드 가상 디바이스(AVD) 28개에서 필요한 것만 골라 13개로 축소했다. 데일리 테스트 러너의 효율성을 높이기 위한 정리 작업이었는데, 의외로 이 과정에서 배운 게 많았다.

문제: 증식한 테스트 환경들

처음에는 다양한 기기 환경을 커버하기 위해 여러 AVD를 추가했다. 기기 화면 크기, 안드로이드 버전, 메모리, 해상도 등을 조합하면서 언제 사이 28개나 되어 있었다. 하지만 실제로는 대부분의 테스트가 특정 API 레벨이나 화면 크기 조합에서만 의미 있었고, 나머지는 단순히 "혹시 모르니" 추가했던 것들이었다.

더 큰 문제는 CI 시간이었다. 데이터를 안 보고도 느낌으로 알 수 있었다. 28개 기기에서 모두 테스트를 돌린다는 건 (병렬화를 한다고 해도) 가장 느린 기기가 전체 시간을 결정하는 병목이 되었다. 매일 수십 분의 테스트 시간이 쌓였다.

정리의 기준

기기 분류 선정 기준 유지 제거
API 레벨 민간 앱 최소/최대 지원 범위 O -
화면 크기 모바일/태블릿 대표 사이즈 O -
해상도 성능 영향 테스트 1~2개 중복
특수 옵션 실제 사용 사례 선별 미사용

결국 제거 대상 11개는 대부분 다음과 같았다:
- pt17~28 범위에서 중간 버전들: 테스트 커버리지 측면에서 최소/최대 버전만 의미
- 해상도 중복: 같은 화면 크기인데 해상도만 다른 기기들
- 실제 사용 없는 특수 조합: "혹시 나올 수도" 했던 나머지들

최종적으로 13개 리스트는 이렇게 구성되었다:
- 안드로이드 API: 22, 24, 28, 30, 33, 35 등 주요 버전만 선별
- 화면 크기: 4인치 스마트폰부터 10인치 태블릿 범위
- 성능 테스트: 저사양/고사양 대표 1~2개씩

실행 측면의 영향

# 변경 전: 데일리런 평균 시간
28개 기기 × 평균 3분/기기 =  84분 (병렬화 후에도 30~40분)

# 변경 후: 예상되는 시간
13개 기기 × 평균 3분/기기 =  39분 (병렬화  15~20분)

단순히 시간만이 아니다. 기기 수를 줄이면:
- CI 큐 단축: 동시 실행 리소스 줄어들어 빠른 피드백
- 유지보수 간결: 새 버전 추가/제거 시 13개만 검토
- 디버깅 효율: 실패한 테스트 원인을 좁은 범위에서 추적 가능
- 자원 절감: 에뮬레이터 인스턴스 생성/해제 오버헤드 감소

회고: 최적화는 명확한 기준에서

이 작업을 하면서 느낀 건 "더 많은 게 항상 좋지 않다"는 것이다. 테스트 범위도 마찬가지다. 우리는 종종 불확실성 때문에 과도하게 안전한 쪽을 선택한다. "혹시 모르니 이 버전도, 저 기기도" 하다 보면 배보다 배꼽이 더 커진다.

좋은 테스트 환경은 필요충분 조건을 만족하는 것이다. 모든 가능성을 다 커버하는 게 아니라, 실제 사용자 환경과 위험성 높은 엣지 케이스를 대표할 수 있는 최소 집합을 찾는 게 목표다.

이건 테스트 기기 정리뿐 아니라 모니터링, 로그 레벨, 기능 플래그 정리 같은 다른 인프라 작업에도 같은 원리가 적용된다. 팀 내에서 이 기준을 명확히 하고 주기적으로 정리하는 습관이 쌓이면, 개발 속도도 올라가고 운영도 한결 편해진다.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.