테스트 포트폴리오 운영 모델
어떤 시나리오를 browser, API, workflow, canary probe로 나누고 어느 tier를 게이트에 올릴지 정하는 운영 표준
핵심 요약
- 테스트 운영의 핵심은 E2E를 얼마나 쓰느냐가 아니라 어떤 질문에 어떤 probe가 답하게 할지 설계하는 일입니다.
- browser·API/contract·workflow·canary·exploratory 포트폴리오로 나눠 모든 리스크를 browser E2E로 풀지 않습니다.
- tier는 실행 빈도가 아니라 의사결정 권한으로 보고 smoke·critical·full·exploratory로 나눕니다.
- 매출/권한/데이터 무결성, 수동검증 난이도 등 4개 중 2개 이상이면 critical 이상을 검토합니다.
- ownership은 QA가 전담하지 않고 인프라·도메인·환경·게이트·agent repair로 나눠 소유합니다.
에이전틱 시대의 테스트 운영은 "E2E를 얼마나 많이 쓰는가"가 아니라 어떤 질문에 어떤 probe가 대신 답하게 할지를 설계하는 일입니다.
테스트 포트폴리오를 먼저 설계한다
좋은 테스트 환경은 하나의 거대한 suite가 아니라 비용과 신뢰도가 제각각인 probe들의 포트폴리오로 짜입니다.
| probe 종류 | 주로 답하는 질문 | 대표 액추에이터 | gate 비중 |
|---|---|---|---|
| browser journey | 사용자가 실제로 핵심 흐름을 끝낼 수 있는가 | Playwright, Cypress, browser agent | 높음 |
| API / contract | 서비스 경계와 상태 전이가 유지되는가 | API runner, contract test | 높음 |
| workflow / async | queue, job, webhook 이후 최종 상태가 맞는가 | workflow harness, replay runner | 중간 |
| canary / prod-safe | 실제 배포 환경에서 이상 신호가 없는가 | synthetic probe, safe browser smoke | 높음 |
| exploratory / learning | 새로운 리스크를 어디서 볼 수 있는가 | ad-hoc script, agent exploration | 낮음 |
여기서 중요한 건 모든 리스크를 browser E2E로 풀려 들지 않는 태도입니다. browser는 강력한 액추에이터지만 느리고 비싸며 원인을 분리하기도 어렵습니다.
tier는 실행 빈도가 아니라 의사결정 권한으로 본다
| tier | 목적 | 예시 | 실행 시점 | 허용 시간 |
|---|---|---|---|---|
smoke | 변경이 시스템을 즉시 망가뜨리지 않았는지 확인 | 로그인, 핵심 대시보드, health probe | 모든 PR, 배포 직전 | 5분 이내 |
critical | 매출·권한·데이터 무결성 보호 | 가입, 결제, 저장, 권한 | main, release candidate | 10~20분 |
full | 넓은 회귀 탐지 | 관리 기능, edge case, locale/device 확장 | nightly, 주간 회귀 | 30~90분 |
exploratory | 학습과 새 리스크 발굴 | 신규 기능, 임시 실험 경로 | 수동, 임시 pipeline | gate 미연결 |
tier 원칙
full을 늘린다고 release 신뢰도가 비례해서 올라가지는 않습니다.
배포를 멈출 테스트는 좁고 빠르고 실패의 의미가 분명해야 합니다.
어떤 시나리오를 높은 tier로 올릴까
아래 4개 중 2개 이상이면 critical 이상을 검토할 만합니다.
- 브라우저 수준 상호작용이나 서비스 간 경계가 핵심이다
- 매출, 활성, 권한, 데이터 무결성과 직접 연결된다
- 장애가 났을 때 인간이 수동 검증하기 어렵거나 늦다
- 제품팀이 "이건 배포 전에 반드시 알고 싶다"고 합의했다
반대로 아래는 높은 tier보다 다른 레이어가 보통 더 적합합니다.
- 순수 계산 로직
- 조합 폭이 큰 정책 테이블
- 브라우저 없이도 충분히 검증 가능한 API 상태 전이
- 디자인 세부 조정처럼 릴리즈 blocker가 아닌 변경
ownership은 QA 전담이 아니라 분산 소유여야 한다
| 영역 | 1차 owner | 2차 owner | 책임 |
|---|---|---|---|
| 공용 실행 인프라 | QA Platform / DevEx | SRE | runners, artifacts, CI, evidence schema |
| 도메인 시나리오 | 제품팀 | QA/SDET | 기대 결과, 핵심 흐름 유지 |
| 환경·데이터 통제 | 플랫폼 / SRE | 제품팀 | seed, reset, sandbox, secret |
| 게이트 정책 | Release Manager + QA Platform | 테크리드 | blocker, 예외 승인, release hold |
| agent repair loop | AI Platform / DevEx | QA Platform | targeted rerun, safe scope, audit trail |
실행 매트릭스
| 이벤트 | 실행 probe | 목적 | 실패 시 기본 조치 |
|---|---|---|---|
| PR | smoke subset | merge 전 빠른 회귀 탐지 | merge block |
| main merge | smoke + critical 일부 | trunk 안정성 확인 | triage 후 main red 유지 |
| nightly | full + cross-browser + workflow | 누적 회귀와 drift 탐지 | ticket 발행, 다음 영업일 triage |
| release candidate | critical 전체 + release probes | 배포 승인 판단 | release hold |
| canary / post-deploy | production-safe probes | 실제 환경 이상 감지 | rollout stop / rollback 검토 |
| agent-repair | 실패 관련 subset만 재실행 | 원인 축소와 패치 검증 | human gate 전 증거 수집 |
서비스 onboarding 최소 기준
- 핵심 사용자 여정 3~5개 정의
smoke와critical태그 또는 동등 tier 분리- 테스트 계정, seed, reset 방식 문서화
- 실패 알림 채널과 owner 등록
- 어떤 failure가 release blocker인지 합의
운영 모델 결정 질문
- 지금 gate를 막을 가치가 있는 시나리오는 정확히 몇 개인가?
- browser probe가 아니어도 더 빠르게 답할 수 있는 질문이 섞여 있지 않은가?
- 각 tier에 실제 owner와 예외 승인자가 존재하는가?
- 팀이 실패를 "테스트 문제"가 아니라 "릴리즈 신호"로 다루고 있는가?