실행 토폴로지와 러너 아키텍처
브라우저 러너, 서비스 클라이언트, 증거 수집기, 판정기를 어떤 구조로 분리해야 하는지 설명합니다.
테스트 환경의 핵심은 러너 하나가 아니라 액추에이터, 관측기, 판정기의 조합입니다. Playwright는 강력한 브라우저 액추에이터지만, 그것만으로 좋은 테스트 환경이 되지는 않습니다.
테스트 환경 아키텍처의 기본 레이어
| 레이어 | 역할 | 예시 |
|---|---|---|
| actuator | 실제 상태를 바꾸거나 사용자 행동을 재현 | Playwright, API client, workflow trigger |
| environment controller | 데이터, clock, queue, sandbox를 준비 | seed tool, reset job, admin endpoint |
| evidence collector | trace, screenshot, logs, events, metrics 수집 | report pipeline, OTEL bridge, artifact store |
| judge / classifier | 실패 원인과 gate 의미 판정 | failure classifier, release policy engine |
| operator | 예외 승인과 인시던트 대응 | release manager, suite owner, on-call |
권장 디렉터리 구조
testops/
├── runners/
│ ├── browser/
│ ├── api/
│ └── workflow/
├── fixtures/
│ ├── auth/
│ ├── state/
│ └── sandbox/
├── contracts/
│ ├── ui/
│ ├── api/
│ └── events/
├── evidence/
│ ├── reporters/
│ ├── classifier/
│ └── retention-policy.md
└── runbooks/이 구조의 요지는 tool별 폴더가 아니라, 테스트 환경이 어떤 책임으로 나뉘는지가 눈에 보이게 만드는 데 있습니다.
브라우저 러너 예시: Playwright
브라우저 layer를 Playwright로 구현할 때는 다음 정도면 충분합니다.
import { defineConfig, devices } from '@playwright/test'
export default defineConfig({
testDir: './tests',
fullyParallel: false,
forbidOnly: !!process.env.CI,
retries: process.env.CI ? 1 : 0,
workers: process.env.CI ? 6 : undefined,
reporter: [
['list'],
['html', { open: 'never' }],
['json', { outputFile: 'test-results/results.json' }],
],
use: {
baseURL: process.env.E2E_BASE_URL,
trace: 'on-first-retry',
screenshot: 'only-on-failure',
video: 'retain-on-failure',
},
projects: [
{
name: 'chromium-smoke',
grep: /@smoke/,
use: { ...devices['Desktop Chrome'] },
},
{
name: 'chromium-critical',
grep: /@critical/,
use: { ...devices['Desktop Chrome'] },
},
],
})중요한 건 이 설정이 "Playwright 사용법"이 아니라 browser actuator가 evidence pipeline과 gate semantics에 맞게 동작하도록 맞춰져 있다는 점입니다.
matrix 원칙
| 축 | 기본 원칙 | 이유 |
|---|---|---|
| 브라우저 | gate는 1개, nightly에서 확장 | gate 신뢰도 우선 |
| device | critical 일부만 모바일 view 확대 | 비용과 triage 시간 절감 |
| locale | 법률/결제/권한처럼 민감한 흐름만 확대 | 조합 폭발 방지 |
| feature flag | canary / rehearsal 중심 | 상시 matrix 최소화 |
evidence 정책
| evidence | 기본 정책 | 목적 |
|---|---|---|
| trace | first retry 이상 | root cause 파악 |
| screenshot | failure only | 시각 상태 확인 |
| video | retain on failure | 동적 문제 파악 |
| console / network log | gate suite 중심 | JS/API 오류 분류 |
| event / job log | async flow 중심 | workflow completion 확인 |
evidence 과수집 주의
모든 실행에서 모든 artifact를 남기면 저장 비용만이 아니라 triage 속도도 느려집니다.
evidence는 실패를 분류하는 데 필요한 최소 세트를 기준으로 설계해야 합니다.
아키텍처 리뷰 체크리스트
- actuator와 judge가 섞여 있지 않은가?
- evidence만 보고도 실패를
product / data / infra / external로 분류할 수 있는가? - 공용 fixture가 제품 로직을 너무 많이 숨기고 있지 않은가?
- 브라우저, API, workflow probe가 같은 gate vocabulary를 쓰고 있는가?