테스트 자동화 Framework 3.0 전환기
안녕하세요. MUSINSA Automation QE팀 정다정입니다.
저희는 앱 빌드나 웹 프론트엔드(FE) 배포가 끝날 때마다 실기기에서 BVT(Build Verification Test, 새 빌드의 핵심 기능이 정상 동작하는지 확인하는 테스트)를 자동으로 수행합니다. 결과는 Slack과 TMS(Test Management System, 테스트 케이스와 결과를 관리하는 도구)로 전달합니다. 이 글에서 ‘런(run)’은 이 BVT를 한 번 실행하는 단위를 뜻합니다.
운영하다 보니 두 가지가 눈에 걸리기 시작했습니다. 어떤 기기는 배정된 시나리오를 일찍 끝내고 놀고 있는데, BVT 전체 수행은 배정된 작업을 가장 늦게 끝내는 기기가 끝날 때까지 이어졌습니다. 시나리오가 늘수록 이 기다림도 길어졌습니다. 또 기기 한 대를 추가하려면 기기 전용 스크립트 파일을 새로 작성해야 했고, 그 과정에서 설정이 어긋나는 실수가 종종 생겼습니다.
“빠른 기기가 왜 기다려야 하지?”
“기기 하나 추가하는 게 왜 이렇게 번거롭지?”자동화 Framework 3.0은 이 두 질문에서 출발했습니다.
29CM 자동화 프레임워크가 걸어온 길 — 1.0과 2.0
3.0으로 전환하기까지, 29CM의 자동화 프레임워크는 1.0과 2.0을 거쳤습니다.
Framework 1.0 — 한 대의 Mac이 모든 역할을 맡던 구조
초기에는 Mac 한 대(Mac Mini로 시작해 이후 Mac Studio로 교체)가 자동화에 필요한 역할을 모두 맡았습니다.
테스트 데이터 제공: 실행할 시나리오와 계정 정보 제공 (Flask API 서버)
기기 관리: 실기기 연결과 상태 관리 (STF)
실행 시작: 빌드·배포 완료 시 테스트 트리거 (Jenkins)
실기기 테스트 실행
결과 저장·알림 (Slack 봇)
작고 빠르게 시작하기에는 좋은 구조였습니다. 하지만 연결된 기기가 늘자, 테스트 실행 부하가 같은 머신에서 돌던 서버 역할까지 느리게 만들었습니다. 기기를 더 붙일수록 전체가 불안정해져 마음 놓고 확장하기 어려웠습니다.
Framework 2.0 — 서버 역할은 EC2로, Mac은 테스트 실행만
1.0의 한계를 보완하기 위해 2.0에서는 실행과 데이터 관리를 분리했습니다. 데이터를 제공하고 결과를 저장·알리는 역할은 EC2로 옮기고, Mac에는 실기기 연결과 테스트 실행만 남겼습니다.
Amazon EC2: API 서버(테스트 자동화 데이터), PostgreSQL(결과 DB 저장), Grafana(결과 조회 및 시각화), Slack 봇 서버
Mac Studio 2대: Android 담당 / iOS 담당으로 분리, 각각 실기기 4대씩 연결
Jenkins: 앱 빌드·웹 프론트엔드(FE) 배포 완료 시 자동화 머신에 실행 명령
실행 흐름은 다음과 같습니다.
Android·iOS 빌드 또는 FE 배포 완료 → Jenkins 트리거
Jenkins가 Mac Studio에 실행 명령 → Run 스크립트 시작
각 기기가 EC2에서 자기에게 배정된 시나리오 목록과 계정 정보를 받고, Appium으로 앱에 연결
배정된 목록을 정해진 순서대로 실행. 이 목록은 실행 도중 다른 기기로 넘어가지 않습니다. 실패 시 스크린샷·로그 자동 캡처
DB 저장, TMS 결과 전송, Slack 스레드 실시간 업데이트. 실패가 발생하면 스크린샷·로그를 Claude로 분석해 Slack에 전달
완료 이모지 추가, TMS 플랜 Close
이 구조는 지금도 안정적으로 운영되고 있습니다. 하지만 시나리오와 기기가 늘면서 처음에 말씀드린 두 가지 한계가 뚜렷해졌습니다.
Framework 2.0을 운영하며 마주한 한계
첫번째 한계. 배정된 작업을 가장 늦게 끝내는 기기가 전체 시간을 정한다.
Framework 2.0에서 각 기기의 완료 시점은 기기 성능뿐 아니라, 배정된 시나리오의 개수와 실행 시
빠른 기기가 왜 기다려야 하지?
생성 일시
2026/10/19 23:01
최종 편집 일시
2026/10/19 23:01
태그
무신사
파일과 미디어