안녕하세요, QA Engineer 변유진입니다. 라포랩스에 합류한 지 이제 곧 1년이 되어가는 시점에, 라포랩스 QA Chapter가 어떻게 하루 30회의 배포 속도를 감당하는 품질 시스템을 만들었는지 공유하려 합니다.
1. E2E 자동화, 왜 다시 설계해야 했을까?
라포랩스는 하루 평균 10회, 많게는 30회까지 서비스를 배포합니다.
이 빠른 속도에서 품질을 어떻게 지켜낼 수 있을까요?
단순히 테스트를 자동화하는 수준을 넘어서, 서비스 전체 품질을 지키는 시스템이 필요했습니다. 그걸 만들기 위해 QA팀은 E2E 테스트 구조를 전면 리팩토링했습니다.
이 글에서는 Playwright + Python 기반 테스트 자동화 구조를 리팩토링하고, CI/CD, AI 리포팅, 대시보드까지 유기적으로 통합해 매일 30회 배포에도 흔들리지 않는 품질 시스템을 만든 과정을 소개합니다.
2. 기존 QA 자동화 구조의 한계
처음에는 모바일 웹 중심으로 빠르게 자동화를 구축했습니다. 하지만 서비스가 성장하면서 구조적 한계가 드러났습니다.
문제는 명확했습니다:
서비스별로 중복된 테스트 로직과 인증 코드
UI나 API 변경 시 각 프로젝트를 따로 수정해야 하는 비효율
배포 파이프라인과 테스트 자동화가 분리된 구조
결국 테스트는 오히려 관리 리스크가 되었고, 빠른 배포 주기를 따라가지 못하는 병목이 되었습니다.
3. 하나의 프로젝트로 모든 서비스를 테스트하기까지
우리가 세운 목표는 단순합니다:
“하나의 테스트 프로젝트로 모든 서비스를 커버한다.”
이를 위해 전체 디렉토리 구조부터 리팩토링을 시작했습니다.
/api: 인증 및 API 로직 공통 모듈화/services: 각 서비스에 동일한 구조 적용 (tests/actions/scenarios)/shared: 로깅, 예외 처리, 설정 등 모든 공통 요소 중앙 관리
결과적으로 변화에 강하고 유지보수가 쉬운 구조를 완성했습니다.
/api
├─ admin_api/
├─ seller_api/
├─ user_service_api/
└─ authorization/
/services
├─ queenit_web/
├─ queenit_app/
├─ 8dogam_web/
├─ admin_seller/
├─ ...
/shared
├─ base/
├─ logger/
├─ exceptions/
└─ config/4. 리팩토링의 핵심 포인트
1) 통합 인증 시스템
다양한 인증 방식을 authentication.py로 통합해, 토큰 만료 시 자동 갱신되도록 구성했습니다.
이제 테스트 코드에선 인증을 신경 쓰지 않아도 됩니다.
# common_api/authentication.py
class AuthenticationAPI:
def get_keycloak_access_token(self, server="stg"): ...
def get_app_token_sms(self, is_prod=False): ...
def get_seller_access_token(self, is_prod=False): ...2) Locator 중앙 관리
UI를 변경할 때 테스트 전체를 수정하지 않도록, 모든 locator를 하나의 파일에서 관리합니다. 텍스트나 DOM이 바뀌어도 단 한 파일만 수정하면 모든 테스트에 반영됩니다.
class Locators:
PHONE_LOGIN_BUTTON = 'button:has-text("휴대폰 인증으로 시작")'
PRODUCT_DETAIL_BUY_BUTTON = 'button:has-text("구매하기")'
PAYMENT_SUBMIT_BUTTON = 'button:has-text("결제하기")'3) Scenario - Action - API 레이어 분리
각 레이어의 역할을 명확히 분리해, 협업 효율을 극대화했습니다.
레이어 | 역할 |
|---|---|
scenarios/ | 무엇을 테스트할지 – 비즈니스 로직 중심 |
actions/ | 어떻게 조작할지 – UI 인터랙션 |
common_api/ | 데이터를 어떻게 가져올지 – API 통신 및 응답 |
4) 에러 분류 시스템
실패 유형을 아래 다섯 가지로 자동 분류합니다. 각 오류에는 trace-id, locator, API 경로 등을 함께 기록해, 디버깅과 개선에 바로 활용 가능한 로그로 구성했습니다.
Frontend (Locator 오류 등)
Backend (API 오류 등)
Network (지연, 연결 실패 등)
System (예외 처리 실패 등)
Validation (응답값 검증 실패)
5. 배포마다 자동으로 실행되는 테스트 시스템
배포가 매일 수십 번이면 테스트도 그만큼 빠르게, 자주, 정확히 돌아야 합니다.
그래서 배포 파이프라인에 자동화를 완전히 통합시켰습니다.
파이프라인 흐름
ArgoCD 배포 완료
↓
Grafana Alert 발생
↓
GitHub Actions Workflow 트리거
↓
E2E 테스트 실행
↓
Slack 결과 전송이제 배포할 때마다 자동으로 테스트가 실행되고, 결과는 슬랙에서 바로 확인됩니다.
6. 모두가 실행하고 해석하는 전사 품질 대시보드
하루에도 수십 번씩 배포가 이뤄지는 지금, 품질은 이제 QA팀만의 일이 아닙니다.
그래서 테스트 시스템을 모두가 직접 실행하고 해석할 수 있는 도구로 확장했습니다.
📊 테스트 현황은 한눈에 보고, 누구나 결과를 해석합니다.
대시보드는 단순 결과 로그가 아닙니다. 최근 성공률, 실패 시나리오, 실행 이력, 에러 분류까지 필요한 정보를 한 화면에서 확인할 수 있습니다.
🚀 버튼 한 번으로 누구나 실행할 수 있습니다.
더 이상 QA에게 테스트 실행을 요청하지 않아도 됩니다.
대시보드에서 본인이 직접 원하는 환경(dev, stg, prod)과 시나리오를 선택해 버튼 한 번으로 테스트를 실행할 수 있습니다. PO는 주문 시나리오를, 개발자는 적립금 정책을, 각자 필요한 테스트를 직접 돌리고 결과를 즉시 확인합니다.
🧠 실패 원인도 AI가 분석합니다.
테스트 결과는 Claude 기반 AI 리포터가 분석합니다.
단순히 “실패”가 아니라:
어떤 유형의 문제였는지 (Frontend / Backend / Network 등)
어떤 locator / API에서 문제가 발생했는지
반복되는 패턴인지
AI가 자동으로 분류하고, 결과는 HTML 리포트로 저장되어 대시보드에서 바로 확인할 수 있습니다. node-cache로 2주간 캐싱하여, 빠른 확인과 함께 AI 호출 비용도 절감하고 있죠.
7. 리팩토링 이후의 변화
배포와 테스트 자동화를 연동하여, 하루 수십 회 테스트가 가능합니다.
테스트 성공률 95% 이상을 유지합니다.
환불 계좌 입력 오류, 적립금 미적립 등의 장애를 사전 탐지해 선제 대응합니다.
자동화는 이제 단순 반복 검증이 아니라, 실시간으로 품질을 증명하는 시스템이 되었습니다.
8. 함께할 분을 기다립니다
이렇게 테스트 자동화 구조를 전면적으로 설계하고, AI 분석 시스템을 도입하고, 전사 차원에서의 대시보드를 만들 수 있었던 이유는 무엇일까요?
바로 주도적으로 변화를 만들어갈 수 있는 환경이기 때문입니다. “이렇게 하면 좋겠다” 는 생각이 들 때, 직접 설계하고 구현할 수 있습니다. 아직도 손댈 수 있는 영역은 많고, 실험해볼 수 있는 기술적 여지도 넓습니다. QA 엔지니어의 플레이그라운드가 열려 있는 환경이죠. 그래서 다음과 같은 분들과 함께하고 싶습니다:
프로덕트 전체 맥락을 이해하고 품질 구조를 설계하고 싶은 분
자동화와 AI로 품질 문제를 근본적으로 해결하고 싶은 분
문제를 정의하고, 빠르게 실험하고, 직접 답을 찾아가는 분
테스트를 효율화하는 팀을 넘어, 서비스 품질을 스스로 증명하는 구조를 만드는 팀. 라포랩스 QA Chapter에서 함께할 팀원을 기다리고 있습니다.