왜 굳이 WebdriverIO? Appium Device Farm에서 Appium 그대로 돌려봤습니다

크몽 QA팀이 Appium Device Farm을 도입하면서 WebdriverIO로 전환하지 않고 기존 Appium 코드베이스를 그대로 사용한 결정과 최소 설정 방법을 다룬다. 기존 테스트 자산을 유지하면서 Device Farm의 대시보드, 미러링, 실행 이력 관리 혜택을 취하는 실용적 접근이다.

핵심 포인트

크몽 QA팀은 Appium 기반 테스트를 이미 대규모로 구축한 자산이 있어 WebdriverIO 전환 비용 없이 Device Farm을 연동했다.
Device Farm 연동에 필요한 설정은 핵심 2가지뿐이다: 드라이버 capabilities에 빌드명/세션명 추가, 테스트 종료 시 결과 명시적 저장.
연동 후 자동화 결과가 체계적으로 누적되고 대시보드에서 누구나 테스트 현황을 파악할 수 있게 됐다.
원격 미러링 기능으로 물리 디바이스 없이도 원격 근무 환경에서 테스트 진행을 실시간 확인할 수 있다.
Device Farm이 WebdriverIO를 기본으로 권장하더라도 Appium 직접 연동이 충분히 가능하다는 것을 검증했다.

상세 정리

배경: 이전 글에서 소개한 Appium Device Farm을 도입 후, 기존 Appium 테스트 코드를 어떻게 연결할지 결정해야 했다.
WebdriverIO 미전환 이유: 크몽 QA팀이 Appium 기반으로 수많은 테스트를 이미 구축해왔기 때문에 전환 비용과 학습 부담이 불필요했다.
설정 1 — 드라이버 옵션 추가: 빌드명과 세션명을 드라이버 capabilities에 추가해 Device Farm이 각 실행을 식별하고 기록할 수 있게 한다.
설정 2 — 결과 저장: 테스트 종료 시 성공/실패 결과를 Device Farm에 명시적으로 전송해야 이력에 기록된다. 이 두 가지가 전부다.
데이터 가시성 확보: 설정 후 실행마다 Device Farm에 데이터가 누적되고, 대시보드에서 디바이스별 테스트 현황 확인이 가능해진다.
디바이스 미러링: 원격 미러링 기능으로 물리 디바이스가 없는 환경에서도 테스트 실행 화면을 실시간으로 볼 수 있다.
팀 변화 1: 자동화 테스트 결과가 체계적으로 저장되기 시작해 히스토리 추적이 가능해졌다.
팀 변화 2: 직관적 대시보드 덕분에 QA 팀원 외에도 테스트 현황을 누구나 파악할 수 있게 됐다.
팀 변화 3: 원격 근무 환경에서도 원격 미러링으로 테스트 효율이 유지된다.