주간 배포 병목을 해결하기 위한 스모크 테스트 개편
모바일 금융 플랫폼 토스는 매주 신규 앱 버전을 정기 배포하며, 이 과정에서 Android와 iOS 플랫폼별로 각각 5개에서 7개에 달하는 배포 후보(RC) 빌드가 생성됩니다. 빌드가 갱신될 때마다 회원가입, 로그인, 자산 확인, 송금 등 핵심 경로가 정상 작동하는지 확인하는 스모크 테스트를 거쳐야 하지만, 반복적인 수동 검증은 엔지니어링 리소스를 크게 소모하는 원인이 되었습니다.
토스 QA Platform 팀은 2024년 9월 기술 컨퍼런스 SLASH 24에서 초기 자동화 도구인 토스닥터 V1을 발표한 바 있습니다. 그러나 UI가 일부만 변경되어도 테스트 코드가 깨지고 실패 원인을 사람이 직접 추적해야 하는 유지보수 한계가 드러나면서, 4가지 핵심 구성 요소와 실행 환경을 전면 개편한 토스닥터 V2를 구축하게 되었습니다.
LLM과 Appium MCP를 결합한 BDD 기반 코드 자동 생성
토스닥터 V2의 첫 번째 변화는 테스트 코드 작성 방식의 전환입니다. 검증 담당자가 절차적인 클릭 및 입력 스크립트를 직접 작성하는 대신, Gherkin 문법(Given-When-Then) 기반의 한국어 시나리오(.feature)로 검증 목적만 기술하도록 변경했습니다.
이후 내부 명령(/codegen)을 실행하면 Model Context Protocol(MCP)로 연결된 Appium과 거대언어모델(LLM)이 실제 구동 중인 단말 화면 요소를 분석하여 테스트 실행 코드를 생성합니다. 이 과정에서 전체 UI 트리를 전송할 때 발생하는 과도한 토큰 비용을 제어하기 위해, 스크린샷 기반 단순 요소 탐색, 전체 XML 트리 분석, 엔지니어 질의로 이어지는 3단계 점진적 탐색 전략을 도입했습니다.
실시간 자가 치유와 검증 엄격성을 유지하는 안전장치
테스트 도중 예기치 못한 이벤트 팝업이나 외부 공유 툴팁이 화면을 가릴 경우, 기존 프레임워크는 요소를 찾지 못해 전체 테스트를 실패 처리하기 일쑤였습니다. 토스닥터 V2는 테스트 실패 직전 서버가 '스마트파인더'를 호출하여 방해 요소를 닫거나 우회한 뒤 작업을 재개하는 실시간 자가 치유(Self-Healing) 체계를 적용했습니다. 성공적으로 우회한 이력은 JSONL 형식으로 적재되어 재발 시 탐색 지연을 줄입니다.
주목할 부분은 자가 치유의 부작용을 방지하기 위한 권한 통제입니다. AI가 화면 요소를 유연하게 탐색하도록 두면 '엉뚱하게 유사한 버튼'을 클릭해 오류가 발생했음에도 통과로 처리되는 거짓 양성(False Positive) 위험이 커집니다. 토스는 검증(Then) 단계에서 유사 요소 매칭(similar-match)을 원천 차단하여, 가림막 제거 외에 검증 결과 자체를 왜곡하는 행위를 엄격히 방지했습니다. 이는 AI 자동화 프레임워크가 실무 환경에서 갖추어야 할 현실적인 안전 경계입니다.
원인 진단과 자동 복구 워크플로의 조건부 동작
테스트 실패가 발생하면 프레임워크는 에러 시점의 시나리오, 스텝 코드, 메시지와 함께 직전 실행 흐름을 담은 시퀀스 스크린샷을 사내 QA 플랫폼 '토션(Tossion)'으로 전송합니다. 이후 지능형 진단(/diagnosis)을 통해 원인 추정과 함께 자동 복구 가능 여부(recoverable: true/false)를 판정합니다.
복구 가능 판정이 내려지면 전체 실행을 멈추고 Appium MCP를 단말에 붙여 실제 요소를 확인한 후 코드를 수정하는 E-1~E-5 워크플로가 가동됩니다. 예를 들어 UI 요소 타입이 ImageView에서 TextView로 변경되어 실패한 경우, 로케이터를 자동 갱신하고 재검증을 거쳐 lessons.md 파일에 주의 사항을 기록하는 전 과정을 자동화했습니다.
확장 플랫폼 '토스체커'의 의의와 실무적 한계
토스는 토스닥터 V2에서 검증된 BDD 및 실기기 MCP 실행 구조를 회귀 테스트 전반으로 넓힌 '토스체커'로 발전시켰습니다. 토스 QA Platform 팀의 발표에 따르면, 기존에 테스터 3명이 이틀간 수행하던 배포 전 회귀 테스트를 대체하여 1,375개의 테스트 케이스를 3주 만에 자동화했습니다. 이는 반복 검증 인력을 시나리오 설계와 자동화 범위 결정 등 고차원 업무로 전환하는 구조적 토대를 마련한 것입니다.
그러나 기술적 관점에서 분명한 제약과 미확인 영역이 남아 있습니다. 첫째, 완전 자동 복구는 UI 로케이터 불일치 등 규격화된 오류에만 국한되며 비즈니스 로직 오류나 API 장애 같은 근본적인 결함은 사람이 직접 개입해야 합니다. 둘째, 발표된 회귀 테스트 자동화 성과는 사내 환경 기준의 자체 집계치로 검증 대상 도메인의 복잡도나 커버리지 산정 공식은 공개되지 않았습니다. 아울러 백엔드에 연동된 LLM 파운데이션 모델의 구체적 명칭과 토큰 비용 구조가 밝혀지지 않은 사내 전용 인프라라는 점에서, 타 개발 조직이 동일한 구조를 복제 도입하기에는 신중한 검토가 필요합니다.
출처
토스테크의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
쉼 없이 도는 테스트, 사람이 어디까지 돌봐야 할까요? - 토스닥터(Toss Doctor) (새 창)
