내가 추구하는 배포 후 E2E 테스트 모니터링 전략
들어가며
에이슬립의 다양한 프로덕트 중 앱노트랙(Apnotrack)은 안정성과 신뢰성이 가장 중요한 서비스입니다. 백엔드 API 변경이나 프론트엔드 업데이트가 사용자 경험에 영향을 미치지 않도록 배포 후 즉시 E2E 테스트를 통해 전수검사를 수행하는 모니터링 전략을 구축했습니다. 이 글에서는 에이슬립이 어떻게 3가지 트리거 방식을 통해 E2E 테스트 실행을 자동화하고 배포 후 장애를 조기에 감지하는 시스템을 구축했는지 공유합니다.
배포 후 장애를 어떻게 빠르게 감지할 것인가?
지난 10년간 소프트웨어 품질 분야에서의 커리어를 돌이 켜봤을 때 수동 및 자동 테스트 전략에서 배포 전/후 크게 3가지 관점에서 문제가 발생했습니다.
첫 번째 문제는 수동 테스트의 한계입니다. 배포 후 QA/개발자가 프로덕션 환경에서 주요 기능을 하나씩 클릭하며 확인하는 방식은 한계가 있었습니다.
시간이 오래 걸립니다. 전체 플로우를 확인하려면 최소 30분 이상이 필요했습니다.
누락되는 케이스가 발생합니다. "이건 괜찮겠지" 하며 넘어간 부분에서 문제가 생깁니다.
야간 배포 시 즉시 확인이 어렵습니다. 피곤한 상태에서 모든 케이스를 체크하기 어렵습니다.
사람의 실수가 발생합니다. "체크했다고 생각했는데..." 같은 상황이 반복되었습니다.
두 번째 문제는 인력과 시간이 제한적인 환경에서의 정기 테스트의 지연입니다. 처음에는 "하루에 한 번만 자동으로 테스트를 돌리면 되지 않나?"라는 생각으로 매일 새벽에 테스트를 실행하도록 설정했습니다. 하지만 이 방식도 문제가 있었습니다.
배포가 오후에 이루어졌다면 다음날 새벽까지 기다려야 문제를 발견할 수 있었습니다.
이미 사용자에게 영향이 발생한 후에야 알림을 받게 됩니다.
문제 발견 시점이 늦어 롤백 결정이 지연되고 사용자 불만이 증가합니다.
세 번째 문제는 장애 대응의 지연입니다. 가장 큰 문제는 문제를 발견하는 시점이 너무 늦다는 것이었습니다. 배포 후 수시간이 지나서야 문제를 알게 되면
롤백 결정이 지연됩니다.
이미 많은 사용자가 영향을 받았을 수 있습니다.
의료기기 앱이라는 특성상 서비스 신뢰도에 직접적인 영향을 미칩니다.
이런 문제들을 해결하기 위해 지나온 경험을 토대로 다음과 같은 목표를 세웠습니다.
배포 직후 즉시 자동으로 E2E 테스트 실행
문제 발견 시 5분 이내 알림
수동 개입 100% 제거하여 실행과 결과 보고까지 모든 과정 100% 자동화
배포 후 즉시 테스트 방안 검토
배포 직후 자동으로 테스트를 실행하려면 백엔드 배포 파이프라인과 E2E 테스트 파이프라인을 연결해야 했고 백엔드와 QA에서 개발 중인 E2E 테스트가 다른 저장소에 있다는 점에서 현재 코드베이스를 크게 건드리지 않는 선에서 복잡도를 최소화하는 방식인 GitHub API repository_dispatch 이벤트로 진행하게 되었습니다. repository_dispatch 이벤트를 사용하면 이벤트를 사용하면 다른 저장소에서도 워크플로우를 트리거할 수 있습니다.
다른 저장소에서도 트리거 가능
GitHub API를 통한 표준 방식
client_payload로 배포 정보 전달 가능
인증이 간단함 (GitHub Token 사용)
3가지 트리거 방식
에이슬립은 3가지 트리거 방식을 통해 다양한 시나리오에서 E2E 테스트를 자동화했습니다. 각 방식은 서로 다른 목적을 가지고 있으며 함께 사용할 때 효과적입니다.
1. 수동 실행 (workflow_dispatch)
workflow_dispatch 방식은 GitHub Actions UI에서 Run workflow 버튼으로 즉시 실행 가능하고 개발자 또는 QA가 원하는 시점에 유연하게 테스트 가능하며 주로 아래와 같은 상황에서 활용합니다.
긴급 버그 재현 테스트
배포 전 수동 검증
특정 브랜치/커밋 테스트
2. 정기 스케줄링 (schedule)
실제로 모니터링 시스템을 구축하고 운영하다 보면 배포와 무관하게 발생하는 문제들이 있었습니다.
데이터베이스 성능 저하
외부 API 장애
인프라 문제
장기간 누적된 버그
이런 문제들은 배포와 무관하게 발생하지만 사용자에게는 동일한 영향을 미칩니다. 따라서 배포와 무관하게 정기적으로 시스템 상태를 확인하는 것이 필요했습니다. 따라서 3시간 간격의 정기 스케줄링을 통한 하루 7~8회 지속적인 모니터링을 진행하고 있습니다. 문제 발생 시 최대 3시간 이내 감지 가능하며 매일마다 프로덕트의 안정성이 보장되고 있다는 것을 확인할 수 있기에 1인 QA 환경에서 업무를 수행하는 상황에서 큰 안정감을 느끼게 되었습니다.
하루 종일 지속적인 모니터링
배포와 무관하게 정기적으로 시스템 상태 확인
장기간 누적된 문제도 감지 가능
서버 부하 분산으로 안정적인 실행
3. 백엔드 배포 트리거 (repository_dispatch)
현재 제가 가장 중요하게 생각한 트리거 방식입니다. 백엔드 배포 직후 즉시 테스트를 자동으로 실행하여 문제를 조기에 발견하는 것이 목표였고 repository_dispatch를 통해 목표를 달성하게 되었습니다.
배포 직후 즉시 검증 (수동 개입 불필요)
배포 정보가 Slack에 자동 포함되어 추적 용이
문제 발견 시 빠른 롤백 결정 가능
배포 실패 시 불필요한 테스트 실행 방지
마무리하며
안정성과 신뢰성이 중요한 에이슬립에서 이러한 자동화된 모니터링 전략은 필수적입니다. 특히 repository_dispatch를 통한 배포 후 자동 테스트는 수동 개입 없이 5분 이내로 장애 발견 여부를 감지하고 150개 이상의 전수검사를 통해 배포의 안정성을 보장하는 핵심 모니터링 전략입니다. 1인 QA로서 완벽한 시스템을 구축하고 운영하기엔 힘들 수 있겠지만 각 분야에서 노력해 주시는 동료분들 덕분에 지속적인 개선을 통해 속도와 품질을 모두 지켜내면서 견고한 시스템을 구축해 나갈 예정입니다.
