사용자 수용 테스트 (UAT)
계획 수립, 실행, 이해관계자 승인 및 출시 결정(go/no-go) 게이트를 포괄하는 종단 간 UAT 프레임워크입니다. UAT는 프로덕션 배포 전 마지막 품질 관문입니다. 그에 걸맞게 대우하십시오. 승인 기준에 대한 명시적인 이해관계자 승인 없이는 어떤 기능도 출시될 수 없습니다.
사전 처리 (자동 컨텍스트)
시작하기 전에 프로젝트 컨텍스트를 자동으로 수집합니다:
- 프로젝트 루트 또는 상위 디렉토리에
PORTFOLIO.md가 있으면 읽어서 제품/팀 컨텍스트를 파악합니다. - 실행:
cat package.json 2>/dev/null || cat build.gradle.kts 2>/dev/null || cat Podfile 2>/dev/null를 통해 스택을 감지합니다. - 실행:
git log --oneline -5 2>/dev/null를 통해 최근 변경 사항을 확인합니다. - 실행:
ls src/ app/ lib/ functions/ 2>/dev/null를 통해 프로젝트 구조를 파악합니다. - 이 컨텍스트를 사용하여 모든 출력을 실제 프로젝트에 맞게 조정합니다.
1단계: UAT 필요성 분류
계획을 수립하기 전에 UAT 유형을 결정합니다. 유형에 따라 범위, 깊이, 이해관계자 참여 및 일정이 결정됩니다.
| UAT 유형 | 트리거 | 범위 | 일반 소요 기간 |
|---|---|---|---|
| 신규 기능 UAT | 기능 개발 완료, 스테이징에 병합됨 | PRD/스토리의 모든 승인 기준, 전체 정상 경로 + 예외 케이스 | 2-5 영업일 |
| 회귀 UAT | 주요 리팩터링, 의존성 업그레이드 또는 플랫폼 마이그레이션 | 주요 사용자 여정 재확인, 동작 회귀 없음 | 1-3 영업일 |
| 릴리스 후보 UAT | 릴리스 브랜치 생성, 모든 기능 통합됨 | 전체 릴리스 범위 — 모든 기능, 통합 지점 및 교차 플랫폼 동작 | 3-5 영업일 |
| 핫픽스 검증 | 프로덕션 버그 수정, 패치가 스테이징에 배포됨 | 좁은 범위 — 수정 사항 확인, 인접 흐름에 대한 부작용 없음 확인 | 2-4 시간 |
UAT 유형이 명확하지 않으면 진행하기 전에 질문하십시오. 핫픽스 검증과 릴리스 후보 UAT는 근본적으로 다른 계획이 필요합니다.
자동 컨텍스트 수집
UAT 계획을 생성하기 전에:
- 기존 테스트 스펙, PRD 파일, 승인 기준 문서를 검색합니다.
- 발견된 스펙을 읽어 테스트 가능한 요구 사항을 추출합니다.
- 테스트 중인 기능을 제어하는 기능 플래그를 grep으로 검색합니다.
산출물 생성 (필수)
Write를 사용하여 다음을 생성합니다:
- UAT 계획:
docs/uat/uat-plan.md— 테스트 계획 출력 스타일 사용 - 테스트 케이스:
docs/uat/test-cases.md— 단계 및 예상 결과가 포함된 상세 테스트 케이스 - 승인 양식:
docs/uat/sign-off.md— 이해관계자 승인 템플릿 - 버그 분류 템플릿:
docs/uat/bug-triage.md— 심각도 분류 가이드
2단계: 컨텍스트 수집
UAT 계획을 작성하기 전에 모든 입력을 수집합니다. 컨텍스트가 누락되면 불완전한 계획이 생성됩니다.
| 입력 | 필수 | 출처 | 비고 |
|---|---|---|---|
| 기능 이름/릴리스 버전 | 예 | PM/기술 리드 | 추적을 위한 짧은 식별자 |
| 승인 기준 | 예 | PRD, 사용자 스토리, Jira/Linear 티켓 | 가능한 경우 /sdlc 스킬 출력 사용 |
| 이해관계자 목록 | 예 | PM/제품 소유자 | 누가 테스트하고, 누가 승인하며, 누가 거부권을 가지는지 |
| 대상 환경 | 예 | 엔지니어링 | 스테이징 URL, 빌드 번호, 기능 플래그 |
| 플랫폼 | 예 | 엔지니어링 | Android, iOS, Web 또는 조합 |
| 규정 준수 요구 사항 | 선택 사항 | 법무/보안 | 테스트 데이터에 대한 HIPAA, SOC 2, PCI-DSS, GDPR 제약 조건 |
| 알려진 위험 또는 제한 사항 | 선택 사항 | 엔지니어링 | 기술 부채, 알려진 문제, 불완전한 통합 |
| 이전 UAT 결과 | 선택 사항 | QA/PM | 회귀 비교 기준 |
| 릴리스 마감일 | 예 | PM | 확정일 vs. 유동적 — go/no-go 압력 결정 |
승인 기준이 존재하지 않으면 중단하고 먼저 /sdlc 스킬을 사용하여 생성하십시오. 승인 기준이 없는 UAT는 의견 기반 테스트일 뿐이며 아무것도 증명하지 못합니다.
3단계: UAT 계획 생성
3.1 승인 기준 추출
모든 출처에서 승인 기준을 추출하여 테스트 가능한 명령문으로 정규화합니다.
형식: [전제 조건]이(가) 주어졌을 때, [동작]을(를) 수행하면, [예상 결과]가 나와야 한다.
출처 우선순위:
1. PRD 승인 기준 (권위 있음)
2. 사용자 스토리 승인 기준 (상세)
3. 디자인 스펙 / 프로토타입 (시각적 및 상호 작용 동작)
4. API 계약 (응답 형태, 오류 코드)
5. 코드 리뷰 또는 /feature-audit 중 식별된 예외 케이스
모든 승인 기준은 하나 이상의 테스트 시나리오가 됩니다. 기준을 수동으로 테스트할 수 없으면 플래그를 지정하고 자동화된 검증 방법을 지정합니다.
3.2 테스트 시나리오 매트릭스
전체 시나리오 매트릭스를 구축합니다. 모든 시나리오에는 정확히 하나의 예상 결과가 있습니다.
| ID | 카테고리 | 시나리오 | 전제 조건 | 단계 | 예상 결과 | 플랫폼 | 우선순위 |
|---|---|---|---|---|---|---|---|
| UAT-001 | 정상 경로 | [기본 성공 흐름] | [설정 상태] | [1. 2. 3.] | [예상 결과] | 전체 | P0 |
| UAT-002 | 정상 경로 | [보조 성공 흐름] | [설정 상태] | [1. 2. 3.] | [예상 결과] | 전체 | P0 |
| UAT-003 | 예외 케이스 | [경계 조건] | [설정 상태] | [1. 2. 3.] | [예상 결과] | 전체 | P1 |
| UAT-004 | 오류 상태 | [잘못된 입력 / 실패] | [설정 상태] | [1. 2. 3.] | [오류 처리] | 전체 | P1 |
| UAT-005 | 교차 플랫폼 | [플랫폼별 동작] | [설정 상태] | [1. 2. 3.] | [플랫폼별 기대치] | 특정 | P1 |
| UAT-006 | 접근성 | [스크린 리더 / 키보드 탐색] | [AT 활성화] | [1. 2. 3.] | [접근 가능한 결과] | 전체 | P1 |
| UAT-007 | 성능 | [로드 시간 / 응답성] | [표준 조건] | [1. 2. 3.] | [예산 이내] | 전체 | P2 |
| UAT-008 | 오프라인/저하 | [연결 없음 / 신호 불량] | [비행기 모드 / 제한] | [1. 2. 3.] | [정상적인 처리] | 모바일 | P1 |
우선순위 정의:
- P0 — 핵심 기능. 실패하면 기능이 작동하지 않습니다. 릴리스를 차단합니다.
- P1 — 중요한 동작. 실패하면 기능은 작동하지만 심각한 격차가 있습니다. 릴리스 전에 반드시 수정해야 합니다.
- P2 — 있으면 좋은 확인 사항. 실패하면 알려진 문제로 문서화하여 출시할 수 있습니다.
3.3 환경 체크리스트
UAT를 시작하기 전에 테스트 환경을 확인합니다. 환경이 손상되면 이해관계자의 시간을 낭비하고 신뢰를 떨어뜨립니다.
UAT 전 환경 체크리스트
[ ] 올바른 빌드/버전으로 스테이징 환경 배포됨
[ ] 빌드 버전 문서화됨: _______________
[ ] UAT 범위에 대한 기능 플래그 활성화:
[ ] 플래그: _____________ = 켜짐/꺼짐
[ ] 플래그: _____________ = 켜짐/꺼짐
[ ] 테스트 데이터 시드됨 (계정, 콘텐츠, 트랜잭션)
[ ] 필요한 역할/권한으로 테스트 계정 생성됨
(계정 프로비저닝은 /test-accounts 스킬 참조)
[ ] 테스트/샌드박스 모드의 타사 통합:
[ ] Stripe: 테스트 API 키로 테스트 모드
[ ] 결제 처리기: 샌드박스 환경
[ ] 이메일/SMS: 가로채기 또는 테스트 수신자 사용
[ ] 분석: dev/staging 속성 (프로덕션 아님)
[ ] 백엔드/API가 스테이징을 가리킴 (프로덕션 아님)
[ ] 데이터베이스에 대표적인 데이터 볼륨 시드됨
[ ] 푸시 알림이 스테이징에 맞게 구성됨
[ ] 딥 링크 / 유니버설 링크가 스테이징 도메인에 맞게 구성됨
[ ] 스테이징에서 SSL 인증서 유효함
[ ] 모든 테스터에 대해 VPN/네트워크 액세스 구성됨
3.4 이해관계자 역할 테이블
누가 무엇을 하는지 정의합니다. 역할이 모호하면 적용 범위에 구멍이 생깁니다.
| 역할 | 담당자 | 책임 | 승인 권한 |
|---|---|---|---|
| UAT 리드 | [이름] | UAT 계획 소유, 세션 조정, 버그 분류, 보고서 생성 | 최종 go/no-go 권장 |
| 제품 소유자 | [이름] | 승인 기준 충족 여부 검증, 비즈니스 로직 시나리오 테스트 | 예 — 비즈니스 승인 |
| 디자인 리드 | [이름] | 시각적 충실도, 상호 작용 패턴, 브랜드 일관성 검증 | 예 — 디자인 승인 |
| 엔지니어링 리드 | [이름] | 버그 조사, 환경 수정, 기술적 제약 설명 가능 | 예 — 기술 승인 |
| QA 테스터 | [이름] | 테스트 시나리오를 체계적으로 실행, 증거와 함께 결과 문서화 | 아니요 — UAT 리드에게 보고 |
| 도메인 전문가 | [이름] | 도메인별 워크플로우 테스트 (금융, 의료, 법률) | 예 — 도메인 승인 |
| 접근성 테스터 | [이름] | 스크린 리더 통과, 키보드 탐색, WCAG AA 확인 | 자문 — UAT 리드에게 에스컬레이션 |
최소 승인 요건: 제품 소울자 + 엔지니어링 리드. 다른 모든 승인은 권장되지만 범위에 따라 다릅니다.
4단계: UAT 실행 프레임워크
자세한 내용은 reference/details.md (섹션 "4단계: UAT 실행 프레임워크")를 참조하십시오.
5단계: 승인 및 Go/No-Go 게이트
5.1 Go/No-Go 결정 매트릭스
go/no-go 결정은 의견이 아닌 데이터에 기반합니다. 각 기준을 점수화하고 가중치가 적용된 결과를 계산합니다.
GO / NO-GO 결정 매트릭스
기능/릴리스: _______________
날짜: _______________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌──────────────────────────────────┬────────┬────────┬───────┬───────┐
│ 기준 │ 가중치 │ 상태 │ 점수 │ 비고 │
├──────────────────────────────────┼────────┼────────┼───────┼───────┤
│ 모든 P0 시나리오 통과 │ 30% │ GO/NOGO│ X/30 │ │
│ 모든 P1 시나리오 통과 │ 25% │ GO/NOGO│ X/25 │ │
│ 열려 있는 P0 버그 없음 │ 20% │ GO/NOGO│ X/20 │ │
│ 열려 있는 P1 버그 없음 (또는 위험 수락됨) │ 10% │ GO/NOGO│ X/10 │ │
│ 접근성 통과 (WCAG AA) │ 5% │ GO/NOGO│ X/5 │ │
│ 예산 이내 성능 │ 5% │ GO/NOGO│ X/5 │ │
│ 교차 플랫폼 동등성 확인됨 │ 5% │ GO/NOGO│ X/5 │ │
├──────────────────────────────────┼────────┼────────┼───────┼───────┤
│ 합계 │ 100% │ │ X/100 │ │
└──────────────────────────────────┴────────┴────────┴───────┴───────┘
결정 임계값:
GO >= 90/100 모든 P0 기준이 GO여야 함.
CONDITIONAL 70-89/100 문서화된 조건 및 해결 일정과 함께 출시.
NO-GO < 70/100 출시하지 마십시오. 수정하고 재테스트하십시오.
하드 블로커 (점수와 관계없이 자동 NO-GO):
- 열려 있는 P0 버그
- 데이터 손실 또는 손상 시나리오
- 보안 취약점 (인증 우회, 데이터 노출)
- 중요 사용자 여정 충돌
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.2 승인 템플릿
이해관계자 승인
기능/릴리스: _______________
빌드/버전: _______________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌──────────────────┬──────────────┬──────────┬────────────┬─────────┐
│ 이해관계자 │ 역할 │ 결정 │ 조건 │ 날짜 │
├──────────────────┼──────────────┼──────────┼────────────┼─────────┤
│ [이름] │ 제품 소유자 │ GO/NOGO │ [있는 경우] │ [날짜] │
│ [이름] │ 엔지니어링 리드│ GO/NOGO │ [있는 경우] │ [날짜] │
│ [이름] │ 디자인 리드 │ GO/NOGO │ [있는 경우] │ [날짜] │
│ [이름] │ 도메인 전문가 │ GO/NOGO │ [있는 경우] │ [날짜] │
│ [이름] │ UAT 리드 │ GO/NOGO │ [있는 경우] │ [날짜] │
└──────────────────┴──────────────┴──────────┴────────────┴─────────┘
조건부 승인은 "GO, 단 다음 사항이 [날짜]까지 해결되어야 함:"을 의미합니다.
1. [조건]
2. [조건]
이해관계자가 NO-GO에 서명하면 해당 이해관계자의 우려 사항이 해결될 때까지 릴리스가 차단됩니다.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.3 롤백 계획
모든 릴리스는 go/no-go 결정 전에 롤백 계획이 문서화되어야 합니다. 롤백 계획이 없으면 자동 NO-GO입니다.
롤백 계획
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
트리거: [롤백을 트리거하는 조건 — 예: 충돌률 > 2%, 프로덕션에서 P0 버그]
소유자: [롤백을 시작하는 사람]
단계:
1. [기능 플래그 비활성화 / 배포 롤백]
2. [롤백 성공 확인]
3. [이해관계자에게 알림]
4. [롤백 후 30분간 모니터링]
데이터: [필요한 데이터 마이그레이션 롤백이 있습니까? Firestore 문서 버전 관리?]
커뮤니케이션: [필요한 경우 사용자에게 전달할 사람 — 지원팀, 상태 페이지]
사후 분석: [롤백 후 48시간 이내에 일정 수립]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.4 릴리스 노트 초안
UAT 결과에서 릴리스 노트를 생성합니다. UAT 테스터는 이 시점에서 누구보다 기능을 잘 알고 있습니다.
릴리스 노트 (UAT 결과 기준)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
버전: _______________
날짜: _______________
새로운 기능
- [추가된 기능/역량 — 사용자 친화적 언어]
개선 사항
- [기존 기능 개선 — 사용자에게 더 나은 점]
수정 사항
- [UAT 중 수정된 버그 — 무엇이 고장 났고 이제 해결되었는지]
알려진 문제
- [이 릴리스와 함께 출시되는 P2 버그 — 가능한 경우 해결 방법]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6단계: UAT 보고서
모든 세션이 완료되고 승인이 수집된 후 전체 UAT 보고서를 생성합니다.
═══════════════════════════════════════════════════════════════
UAT 보고서
기능/릴리스: [이름]
버전/빌드: [버전]
날짜: [오늘]
UAT 리드: [이름]
═══════════════════════════════════════════════════════════════
경영진 요약
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
결정: GO / CONDITIONAL / NO-GO
총 시나리오: [N]
통과: [N] ([X]%)
실패: [N] ([X]%)
차단됨: [N] ([X]%)
실행되지 않음: [N] ([X]%)
열려 있는 블로커: [N] P0 / [N] P1 / [N] P2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
카테고리별 통과율
┌──────────────────────┬──────────┬────────┬─────────┬────────┐
│ 카테고리 │ 총계 │ 통과 │ 실패 │ 비율 │
├──────────────────────┼──────────┼────────┼─────────┼────────┤
│ 정상 경로 │ [N] │ [N] │ [N] │ [X]% │
│ 예외 케이스 │ [N] │ [N] │ [N] │ [X]% │
│ 오류 상태 │ [N] │ [N] │ [N] │ [X]% │
│ 교차 플랫폼 │ [N] │ [N] │ [N] │ [X]% │
│ 접근성 │ [N] │ [N] │ [N] │ [X]% │
│ 성능 │ [N] │ [N] │ [N] │ [X]% │
│ 오프라인/연결성 │ [N] │ [N] │ [N] │ [X]% │
├──────────────────────┼──────────┼────────┼─────────┼────────┤
...