바비톡 QA팀이 모바일 앱 테스트 자동화는 갖춰져 있었지만, 빌드 완료 후 테스트 실행과 결과 확인에 매번 30분을 수동으로 쓰는 문제를 해결한 경험을 공유한 글이다. Bitrise → AWS Lambda → AWS Device Farm → Slack으로 이어지는 완전 자동화 파이프라인을 구축해 배포 전 검증 시간을 제거했다.
핵심 포인트- 파이프라인 4단계: Bitrise(빌드 관리) → AWS Lambda(테스트 트리거) → AWS Device Farm(실기기 테스트 실행) → Slack(결과 알림)
- 핵심 해결: 빌드 완료 이벤트 → Lambda 자동 호출 → Device Farm 테스트 개시 → 결과 Slack 전송 → 사람 개입 제로
- AWS Device Farm 선택 이유: 사내 실기기 유지보수 없이 Appium(Android: Robot Framework, iOS: pytest) 기반 실기기 테스트 가능
- 추적성 보장: Bitrise build number를 공통 키로 빌드 결과와 테스트 결과를 연결 — 어떤 빌드의 테스트인지 명확
- 결과: 배포 전 수동 검증 시간 약 30분 제거, QA 엔지니어가 반복 실행 대신 테스트 설계·품질 개선에 집중
- 설계 철학: 비용 최소화보다 운영 신뢰성과 개발자 효율을 우선 — 클라우드 실기기 인프라 선택
상세 정리- 기존 문제: UI 테스트 자동화 코드는 있으나 빌드마다 테스트 실행·결과 확인에 QA 엔지니어의 30분 수동 작업 필요
- Bitrise 역할: 앱 빌드 완료 시 AWS Lambda를 호출하는 워크플로우 단계 추가
- Lambda 역할: 빌드 완료 이벤트 수신 → Device Farm 테스트 런 생성 → 실행 명령 전달
- Device Farm 역할: Android(Robot Framework) / iOS(pytest) Appium 스크립트를 실제 클라우드 디바이스에서 실행
- 폴링 구조: Bitrise 스크립트가 Device Farm 테스트 완료 여부를 주기적으로 확인 → 완료 시 결과 수집
- Slack 알림: 테스트 통과/실패 결과를 팀 채널로 자동 전송, build number 포함으로 추적 가능
- 추적성 설계: 동일 build number를 Bitrise 빌드 로그와 Device Farm 테스트 결과에 공통 참조키로 사용
- 실기기 vs 에뮬레이터: Device Farm은 실제 물리 디바이스 풀 사용 → 에뮬레이터에서 재현 안 되는 버그 탐지 가능
- 비용 트레이드오프: 사내 디바이스 관리(구매·유지·교체) vs 클라우드 종량제 — 운영 안정성 우선으로 클라우드 선택
왜 읽나모바일 CI 파이프라인에서 테스트 자동화는 했지만 실행·확인 단계가 여전히 수동이라면, Lambda를 중간 트리거로 삼아 Device Farm과 Slack을 연결하는 이 구성이 30분 병목을 없애는 직접적인 참고가 된다.