모바일 E2E 테스트, 실행과 운영 분리로 AI 분석 기반 마련

by DD
3시간 전
조회수 4

모바일 E2E 테스트 자동화 초기 목표는 단순 시나리오 실행 및 리포트 생성이었으나, 운영 과정에서 실패 원인 분석의 어려움이 병목으로 부상함

GitHub Actions는 테스트 실행 및 결과 전달에 집중하고, n8n은 알림, 기록, 분류 등 운영 규칙을 담당하며 실행과 운영의 책임 분리를 달성함

이 구조는 AI 기반 실패 분석(AI-based Failure Analysis)Self-Healing 워크플로 구축의 기반을 마련하여 운영 효율성을 증대시킴

GitHub Actions와 n8n의 책임 분리 전략

본문에서는 모바일 E2E 테스트 자동화에서 실행(Execution)운영(Operation)의 책임을 명확히 분리하는 아키텍처를 제시함. GitHub Actions는 테스트 실행, 환경 준비, 결과 리포트 생성 및 webhook 전송 등 재현 가능한 실행 환경 제공에 집중함. 반면, n8n은 webhook으로 전달받은 결과를 파싱하여 Slack 알림, Notion 기록, InfluxDB 적재, AI 기반 실패 분류 호출 등 변동성이 큰 운영 규칙 및 외부 시스템 연동을 담당함. 이러한 경계 설정은 각 시스템의 변경 비용을 최소화하고 안정적인 테스트 실행유연한 운영 규칙 관리를 가능하게 함.

테스트 실패 분석의 복잡성과 운영 자동화의 필요성

모바일 E2E 테스트 자동화 운영 시, 단순 실패 알림을 넘어 실패 원인(제품 결함, 테스트 코드 오류, 실행 환경 문제)을 판단하고 기록하는 과정이 복잡한 병목으로 작용함. GitHub Actions 내에서 이 모든 운영 로직을 처리하면 workflow가 비대해지고 변경 관리가 어려워짐. 따라서 n8n과 같은 워크플로 자동화 도구를 도입하여 Slack 알림 포맷 변경, Notion 기록 방식 수정, 실패 분류 기준 변경 등 잦은 운영 규칙 변경을 테스트 실행 환경과 분리하여 관리하는 것이 중요함. 이는 데이터의 누적과 분석을 통해 장기적인 테스트 안정성 확보에 기여함.

단일 출구(Single Exit Point) 설계의 중요성

테스트 결과 알림 및 후속 처리 과정에서 발생하는 혼란을 방지하기 위해, GitHub Actions의 결과 전송 스크립트를 유일한 출구로 설계함. 이 스크립트는 테스트 결과, 플랫폼 정보, 실행 시간, 리포트 URL, 인프라 오류 메시지 등 구조화된 payload를 생성하여 n8n으로 전송함. n8n은 이 payload를 기반으로 Slack, Notion, InfluxDB, AI 분류 시스템 등으로 데이터를 라우팅함. 이처럼 명확한 단일 출구를 통해 알림 경로 추적이 용이해지고, 문제 발생 시 책임 소재를 분명히 하여 디버깅 효율성을 높일 수 있음.

AI 기반 분석 및 Self-Healing을 위한 데이터 구조화

AI 기반 실패 분류 및 Self-Healing 워크플로를 성공적으로 구축하기 위해서는 구조화된 실패 데이터가 필수적임. 본 아키텍처는 GitHub Actions에서 생성된 테스트 결과 payload를 n8n에서 파싱하고, 이를 기반으로 실패 원인 분류, Slack 알림, Notion 기록 등을 수행함. 특히, 실패한 테스트 이름, 에러 메시지, 리포트 URL, 플랫폼 정보 등이 포함된 구조화된 데이터는 AI 모델이 실패 패턴을 학습하고 분류하는 데 핵심적인 역할을 함. 실행 환경과 운영 로직을 분리함으로써 AI 모델은 실행 안정성에 영향을 받지 않고 실패 분석 및 후속 조치 로직에 집중할 수 있음.

테스트 코드와 운영 정책의 분리 원칙

테스트 코드 자체는 실행 책임에만 집중하도록 설계되었으며, Slack 알림, Notion 기록, 실패 분류와 같은 운영 정책에 대한 지식은 배제함. 시나리오 파일은 테스트 흐름을 명확히 하고, 반복 동작은 공통 helper 함수로 분리하며, Page Object 패턴을 사용하여 selector만 관리함. 이는 테스트 코드 변경이 운영 정책 변경으로 이어지는 것을 방지하고, 각 계층의 독립적인 변경 및 유지보수를 가능하게 함. 불안정한 selector나 화면 흐름 변경 시에도 테스트 코드 내에서 무리하게 우회 로직을 추가하기보다, 운영 자동화 로직에서 처리하도록 하여 코드의 복잡성을 줄이고 원인 추적을 용이하게 함.

병목은 테스트 실행이 아니었다: Appium E2E 자동화에서 실행과 운영을 분리하기까지