grep

Retail Platform QA 자동화 여정

무신사

2026년 9월 3일

원문에서 보기 ↗

하루 걸리던 회귀 테스트를 30분으로 만든 이야기

무신사 Retail Platform QA팀이 Playwright와 Slack 봇, AI 기반 TC 생성기를 만들어 온 기록

들어가며

안녕하세요. 무신사 PBO(Platform Business Operation)에서 Retail Platform QA 엔지니어 고남석입니다.

Retail Platform팀은 편집샵과 무탠다드, 29CM 같은 오프라인 매장을 운영하는 플랫폼을 개발합니다. mPOS, Self-POS, PDP, MOSS까지 여러 서비스가 촘촘히 맞물려 돌아가는 구조입니다.

QA팀은 매주 정기 배포 를 합니다. 문제는 배포마다 반복되는 회귀 테스트였습니다. 새 프로젝트를 병행하면서 수동 회귀까지 감당하기에는 인원이 부족했고, 도메인은 계속 늘었습니다. 그때 정기 배포 회귀 테스트는 하루 꼬박 걸렸습니다.

이 글은 그 문제를 풀려고 만든 자동화 이야기입니다. UI 자동화에서 시작해 Slack 봇과 AI 기반 테스트케이스 생성기까지 만들었습니다. 커버리지가 다 찬 상태는 아니지만, 지금 자동화된 범위에서는 회귀 테스트가 30분에 끝납니다.

01. 전체구조

프로젝트는 크게 다섯 영역으로 구성됩니다. 테스트 실행 자동화(UI)만 만드는 것이 아니라 기획 → 설계 → 실행 → 리포트까지 하나의 파이프라인으로 잇는 것이 목표였습니다.

02. 왜 Playwright인가

UI 자동화 도구는 Selenium과 Cypress, Playwright를 놓고 비교한 끝에 Playwright와 TypeScript를 골랐습니다.

Selenium은 오래된 레거시가 많고 설정이 복잡합니다. Cypress는 JavaScript 생태계와 잘 맞지만 멀티 탭과 도메인 처리에 제약이 있습니다. Playwright를 고른 이유는 세 가지입니다.

① Auto-wait 요소가 나타날 때까지 자동으로 기다리기 때문에 sleep()이나 wait() 같은 수동 대기 코드가 거의 필요 없습니다. 매장 POS 특성상 결제 처리나 재고 조회 같은 API 응답이 느릴 수 있는데, Playwright는 이를 자연스럽게 처리합니다.

② 네트워크 인터셉트 API 요청을 가로채서 원하는 응답으로 교체할 수 있어 특정 엣지케이스(재고 없음, 결제 실패 등)를 외부 서버 세팅 없이 재현할 수 있습니다.

③ Trace Viewer 테스트가 실패하면 각 스텝의 스크린샷과 DOM 상태, 네트워크 로그를 타임라인으로 재생할 수 있어 원인 분석이 빠릅니다.

03. E2E 테스트 설계

Page Object Model로 유지보수 비용 낮추기

테스트 코드에서 가장 큰 문제는 UI가 바뀔 때마다 테스트가 깨지는 것입니다. 이를 해결하기 위해 Page Object Model(POM) 패턴을 적용했습니다.

핵심 아이디어는 UI 조작 로직을 테스트 로직에서 분리하는 것입니다. 버튼 클릭·입력·요소 탐색 같은 UI 조작은 Page 클래스가 담당하고, 테스트 코드는 "무엇을 검증하는가"에만 집중합니다.

이 구조 덕분에 UI 변경이 생겨도 해당 Page 클래스 하나만 수정하면 됩니다. 테스트 코드는 건드릴 필요가 없습니다.

스모크 vs 회귀 분리 전략과 현재 커버리지

모든 테스트를 매번 돌리면 너무 느립니다. 목적에 따라 스모크와 회귀를 분리했습니다.

지금까지 41개 파일, 234개 테스트 케이스를 자동화했습니다. mPOS가 가장 복잡한 도메인이라 결제 수단별(카드, 현금, 간편PAY)과 회원 유형별로 시나리오를 나눠 뒀습니다.

Okta 인증: 로그인 세션을 워커 단위로 공유

mPOS는 Okta 인증이 필요합니다. 그냥 구현하면 테스트마다 로그인을 반복하고 전체 실행 시간이 늘어납니다.

Playwright는 테스트를 워커 단위로 병렬 실행합니다. worker-scoped fixture로 워커 하나당 로그인을 한 번만 하고, 그 세션을 그 워커의 모든 테스트가 나눠 쓰게 했습니다.

04. Slack 리포트: 테스트 결과를 채널로

테스트가 끝날 때마다 GitHub Actions 로그에 들어가 결과를 확인하기는 번거롭습니다. slack-reporter.ts가 결과를 Slack 스레드로 보냅니다.

테스트 suite가 시작되면 채널에 메시지를 하나 올리고, 이후 업데이트는 전부 그 메시지의 스레드에 답니다. 각 테스트가 끝날 때마다 통과와 실패 여부가 스레드에 쌓이고, 실패한 경우에는 어느 스텝에서 멈췄는지도 함께 올라갑니다. 전체가 끝나면 통과와 실패 수, 소요 시간을 요약해 붙입니다.

이 구조 덕분에 QA 엔지니어가 자리를 비워도 팀 전체가 테스트 상태를 실시간으로 확인할 수 있습니다.

05. @doomto: Slack 봇으로 테스트 트리거

CI/CD 접근 권한이 없는 팀원도 테스트를 실행할 수 있어야 했습니다. PM과 디자이너, 개발자를 위해 Slack 봇 @doomto를 만들었습니다.

Socket Mode를 선택한 이유

Slack 봇은 두 가지 방식으로 만듭니다. Slack이 이벤트를 HTTP로 보내주는 Webhook, 봇이 먼저 WebSocket 연결을 여는 Socket Mode입니다. Webhook은 외부에서 접근 가능한 서버와 공인 IP가 필요합니다. Socket Mode는 봇이 Slack 서버에 먼저 연결하기 때문에 별도 서버 없이 GitHub Actions 위에서 바로 돌릴 수 있습니다.

봇 안정성 유지

Socket Mode 연결은 장시간 유지하면 끊길 수 있습니다. GitHub Actions 워크플로우를 6시간마다 자동 재시작하도록 설정해 봇이 항상 살아있게 유지합니다.

또 하나 신경 쓴 부분은 중복 응답 방지입니다. 로컬에서 개발할 때 봇을 띄우면 CI의 봇과 동시에 실행되어 하나의 명령에 응답이 두 번 오는 문제가 있었습니다. 실행 환경(로컬 vs CI)을 구분하는 식별자를 붙여 이 문제를 해결했습니다.

07. TC 생성기: 마인드맵에서 테스트케이스까지

테스트케이스 문서 작성은 반복이지만 빠뜨리면 안 되는 일입니다. TC 생성기는 기획 산출물을 넣으면 AI가 테스트케이스 초안을 써 주는 웹 앱입니다. 케이스를 바로 나열하지 않고 마인드맵을 그린 뒤 검토, 케이스 생성, 커버리지 분석 순으로 갑니다.

생성 프로세스

  1. 마인드맵으로 전체 구조 파악 --- 케이스를 바로 생성하지 않고, 먼저 마인드맵을 그립니다. 입력된 기획 문서를 분석해 테스트해야 할 기능 영역·시나리오 분기·엣지케이스 항목을 트리 구조로 시각화합니다. 방향이 잘못된 것을 여기서 잡아내면 수십 개의 케이스를 다시 만드는 낭비를 막을 수 있습니다.
  2. 마인드맵 검토 및 수정 --- 누락된 시나리오를 추가하거나 불필요한 항목을 제거합니다. QA 엔지니어의 판단이 개입되는 가장 중요한 단계입니다.
  3. 테스트케이스 생성 --- 검토를 통과한 마인드맵을 기반으로 테스트케이스를 생성합니다. 마인드맵의 각 항목이 구체적인 케이스로 변환됩니다.
  4. 커버리지 분석 및 케이스 수정 --- 생성된 케이스에 대한 커버리지 결과가 함께 제공됩니다. 어떤 시나리오가 커버됐고 어떤 부분이 부족한지 확인할 수 있으며, 부족한 부분에 대해 케이스를 추가하거나 수정할 수 있습니다.

다양한 입력 소스와 AI 모델 이중화

기획 문서는 여러 곳에 흩어져 있습니다. 현재 다음 소스를 모두 지원합니다.

Claude는 복잡한 Retail Platform 도메인 로직 해석에 강합니다. 결제 정책과 재고 처리, 프로모션 적용 규칙처럼 맥락 이해가 필요한 곳에 씁니다. Google Gemini는 패턴이 반복되는 단순한 케이스를 빠르게 만듭니다. 두 모델을 병렬로 돌려 생성 속도를 높입니다.

도메인 지식을 파일로 관리

AI가 Retail Platform 도메인을 이해하려면 도메인 지식이 프롬프트에 들어가야 합니다. 코드에 하드코딩하면 고칠 때마다 코드를 건드려야 해서, 도메인 지식은 별도 파일로 뺐습니다.

도메인이나 TC 작성 규칙이 바뀌어도 파일만 고치면 다음 생성부터 반영됩니다. 새로 온 QA 엔지니어가 이 파일을 읽고 도메인을 파악하는 효과도 있었습니다.

앞으로의 계획

지금은 Retail Platform 도메인만 다룹니다. PBO 전체 도메인으로 넓혀 다른 서비스에도 같은 기능을 제공할 계획입니다.

08. 테스트 플랜 자동 생성

PRD URL을 입력하면 Claude Sonnet이 QA 테스트 설계서 와 테스트 플랜을 자동으로 생성해주는 기능입니다.

PRD URL을 넣으면 Claude Sonnet이 QA 테스트 설계서와 테스트 플랜을 만듭니다. 규칙 파일 18개로 출력 품질을 잡습니다. 규칙이 파일로 분리돼 있어 품질을 손볼 때 규칙만 고치면 됩니다.

09. CI/CD: 자동 실행 파이프라인

모든 테스트는 self-hosted runner에서 실행됩니다. 테스트 결과는 Playwright HTML 리포트로 아티팩트에 14일간 보관되어 나중에도 실패 시점을 재현할 수 있습니다.

10. 지금까지의 성과

회귀 테스트 시간: 하루 → 30분

정기 배포 전 회귀 테스트는 예전에 하루 꼬박 걸렸습니다. QA 엔지니어 한 명이 mPOS와 PDP, Self-POS의 결제와 환불, 회원 조회 등 수백 개 시나리오를 손으로 클릭했습니다. 지금은 자동화된 범위 기준으로 30분이면 끝납니다.

커버리지는 아직 다 차지 않았습니다. MOSS는 스모크 단계이고, 각 서비스의 엣지케이스도 계속 추가하는 중입니다.

테스트 플랜과 테스트케이스: 문서화 시간 대폭 단축

E2E 자동화 이전에도 리소스를 갉아먹는 일이 있었습니다. 테스트 플랜 작성과 테스트케이스 문서화입니다.

새 기능이 나올 때마다 PRD를 읽고 테스트 관점을 정리하고 케이스를 하나씩 쓰는 데는 경험 많은 QA 엔지니어도 몇 시간이 걸립니다. 놓친 케이스가 있으면 처음부터 다시 검토해야 합니다.

테스트 플랜 자동 생성은 PRD URL 하나로 설계서와 플랜 초안을 만듭니다. TC 생성기는 마인드맵으로 전체 구조를 먼저 보여주고 검토를 거쳐 케이스까지 만듭니다. QA 엔지니어가 할 일은 결과를 리뷰하고 고치는 쪽으로 바뀌었습니다. 작성에 쓰던 시간을 리뷰에 쓰니 같은 시간에 더 많은 프로젝트를 봅니다.

누구나 테스트를 실행할 수 있게

@doomto 덕분에 QA 엔지니어가 없는 시간에도 개발자와 PM이 Slack에서 테스트를 돌립니다. 배포 병목이 QA 한 명에서 팀 전체로 분산됐습니다.

11. AI를 어떻게 활용하느냐가 핵심이다

"AI로 무엇을 자동화하느냐"보다 "AI를 어떻게 활용하느냐"가 더 중요하다.

개발자의 AI 활용법을 QA에 이식하다

개발자들이 AI를 활용하는 방식을 생각해보면, 단순히 코드를 대신 짜달라고 시키지 않습니다. 요구사항을 주고 초안을 만들게 한 뒤, 그 결과를 리뷰하고 수정 방향을 잡습니다. 코드리뷰를 AI에게 먼저 맡기고 사람이 최종 판단을 내립니다. AI는 생산성을 높이는 도구이지, 판단을 대체하는 도구가 아닙니다.

Retail Platform QA팀은 같은 철학을 QA 워크플로우에 적용했습니다.

QA 엔지니어의 역할이 "케이스를 처음부터 쓰는 사람"에서 "AI가 만든 결과를 판단하고 방향을 잡는 사람"으로 바뀝니다. 전문성이 줄어드는 것이 아니라, 전문성을 더 가치 있는 곳에 쓰게 됩니다.

AI가 시나리오를 스스로 확장하다

한 단계 더 나아가, 테스트케이스가 작성되면 AI가 해당 케이스를 분석해서 누락된 시나리오를 자동으로 추가 하는 기능을 구현하고 있습니다. AI가 "이 케이스에서 다루지 않은 경계 조건이 있다"고 판단하면 시나리오를 새로 제안하고, QA 엔지니어가 승인하면 해당 시나리오가 회귀 테스트에 자동으로 반영됩니다.

사람이 놓치기 쉬운 엣지케이스를 AI가 잡아내고, 그 케이스가 다음 배포부터 자동으로 검증되는 구조입니다. 회귀 테스트의 커버리지가 인력 투입 없이 점진적으로 넓어지는 효과가 있습니다.

테스트 불안정성 (Flakiness)

UI 테스트는 본질적으로 불안정합니다. 네트워크 지연, 렌더링 타이밍, 외부 API 응답 속도에 따라 같은 코드가 어떤 날은 통과하고 어떤 날은 실패할 수 있습니다. Playwright의 auto-wait와 retry 설정으로 어느 정도 해소했지만, 완벽히 없애기는 어렵습니다. 실패 알림이 왔을 때 재현 여부를 먼저 확인하는 문화를 팀에 심는 것도 중요한 작업이었습니다.

Slack 봇 안정성

Socket Mode 연결이 끊기면 봇이 명령에 응답하지 않습니다. 6시간 주기 재시작으로 해결했지만, 재시작 직전에 명령이 오면 유실될 수 있는 구조적 한계가 있습니다. 이 부분은 추후 개선 포인트로 남아 있습니다.

마치며

"하루 걸리던 것을 30분으로"는 단순한 수치 이상의 의미가 있습니다. QA 엔지니어가 반복 클릭에서 벗어나 더 중요한 탐색적 테스트와 품질 개선에 시간을 쓸 수 있게 됐다는 뜻입니다.

아직 갈 길이 남아 있습니다. 커버리지는 계속 확대 중이고, TC 생성기는 Retail Platform을 넘어 PBO 전체 도메인으로 확장할 예정입니다. QA Hub는 QA의 모든 프로세스를 하나의 플랫폼으로 통합하는 방향으로 성장하고 있습니다.

완성된 시스템을 소개하는 것이 아니라, 함께 만들어가는 과정을 공유하고 싶었습니다. 비슷한 고민을 하고 계신 분들에게 조금이나마 참고가 됐으면 합니다.