---
type: knowledge
domain: qa
status: active
last-reviewed: 2026-07-27
---

# 검수·UAT 대응 실전

> 한 줄 정의
> 검수(UAT)는 외주 프로젝트의 관문이다 — 목표는 "통과시키기"가 아니라 **착수 전 합의된 기준으로 통과·미통과가 기계적으로 판정되게 만드는 것**이다. 검수 시나리오 문서 자체의 작성법은 [[시나리오·예외사항 문서 작성법]], 계약·잔금 연결은 [[SI 수주와 범위 관리]] — 여기는 검수 기간의 운영이다.

## 검수 계획 — 착수 전 합의만 유효하다

검수 직전에 정하는 기준은 기준이 아니라 협상이다. 다음 항목을 **착수(늦어도 개발 중반) 전에** 표로 합의하고 서면화한다:

| 합의 항목 | 내용 | 없으면 |
|----------|------|--------|
| 기간·상한 | 검수 기간 + "N영업일 내 피드백 없으면 승인 간주" | 무기한 검수 = 잔금 무기한 유예 → [[SI 수주와 범위 관리]] |
| 참여자 | 발주사 수행 인원·판정 권한자·수행사 지원 창구 | 판정 권한 없는 사람의 피드백이 기준을 흔든다 |
| 시나리오 범위 | 검수 대상 시나리오 목록 (확정본 기준) | 검수 중 시나리오가 늘어난다 |
| 통과 기준 | 심각도 등급별 허용 건수 (아래 절) | "느낌상 안정화되면" |
| 결함 처리 SLA | 심각도별 응답·수정 목표, 수정 배포 창구·주기 | 결함 하나로 검수 전체가 정지한다 |

- 심각도 등급의 정의 표는 [[결함 관리 실전]]과 같은 것을 쓴다 — 검수용 등급을 따로 만들면 판정이 두 벌이 된다.
- 검수 시나리오는 검수 개시 전에 **확정·배포**돼야 한다 — 확정 없이 진입하면 테스트 중에 기준이 흔들린다 → [[시나리오·예외사항 문서 작성법]] 라이프사이클.

## 검수 환경 — 운영 동형 + 준비된 데이터

- 검수 환경은 **운영과 같은 형태**(버전·설정·연동 대상)여야 한다. "검수는 통과했는데 오픈하니 다르다"의 대부분은 환경 차이다 — 검수 환경에서만 켜진 설정·목킹된 연동을 검수 전에 제거하거나 명시한다.
- 검수 데이터는 시나리오의 기대값과 짝으로 준비한다 — 어떤 케이스에 어떤 데이터를 쓰는지 시나리오에 명시돼 있어야 판정이 된다.
- 실데이터 사본을 쓰려면 발주사 승인 + 반출·PII 규율을 따른다 — 데이터 소유권은 발주사에 있고, 수행사 로컬 반출은 계약·규제 사안이다 → [[개인정보와 컴플라이언스]].

## 검수 시나리오는 발주사 언어로

- 시나리오의 축은 시스템 단계가 아니라 **발주사의 업무 흐름**이다 — 현업이 읽고 따라 하며 자기 업무가 되는지 판정할 수 있어야 한다. 작성 규칙 전체(업무 단위·필수 3요소·예외 발굴)는 [[시나리오·예외사항 문서 작성법]]이 정본.
- TC와 자동 테스트의 추적(TC ID를 테스트 이름에 박아 조회로 증명)은 [[백엔드 테스트 실전]] — 검수 회의에서 "테스트했는데요"는 근거가 아니고, 추적표의 구멍이 곧 검수 리스크 목록이다.
- 시나리오 컨펌은 별도 단계다 — 수행사가 만든 시나리오를 발주사가 승인해야, 그 시나리오의 통과가 검수 통과의 근거가 된다.

## 검수 중 지원 체제

| 체제 | 내용 |
|------|------|
| 재현 지원 | 발주사가 겪은 현상을 수행사가 그 자리(또는 당일)에서 재현 확인 — "재현 안 됨" 회신으로 닫지 않는다 → [[결함 관리 실전]] |
| 당일 트리아지 | 접수된 결함을 당일 3분류(결함/CR/사용법)·심각도 판정 — 미분류 적체가 검수 불신의 시작이다 |
| 수정 배포 창구 | 검수 환경 배포는 창구·주기를 하나로 (수시 배포는 "테스트하던 판이 바뀌는" 불신을 만든다) — 배포마다 수정 결함 목록을 공지 |
| 스모크 후 재개 | 수정 배포 직후 스모크 통과를 확인하고 검수 재개를 알린다 → [[QA 원리]] 스모크 10분 규칙 |

- 검수 중 발견된 범위 밖 요구는 그 자리에서 수용하지 않는다 — CR 회부가 원칙이고, 즉시 거절도 아닌 영향 산정으로 응답한다 → [[SI 수주와 범위 관리]].

## 통과 조건 — 명문화된 숫자만 기준이다

- 형식: **"치명 0건 + 중요 N건 이하 + 잔여 결함은 기한 합의된 목록으로"** — 등급 정의와 건수 상한이 문서에 있어야 판정이 산수가 된다. "느낌상 안정화" "전반적으로 만족"은 기준이 아니다 → [[요구사항과 완료 조건]].
- 판정 근거는 시나리오별 기대값 대 실측값의 대조 결과다 — 판정 기준 없는 스크린샷 뭉치는 검수 결과서가 아니다.
- 통과 기준에 못 미치면 재검수 조건(수정 후 어떤 범위를 다시 도는지)도 미리 정해 둔다 — 전량 재검수인지 실패 시나리오+회귀 세트인지에 따라 일정이 주 단위로 달라진다.

## 조건부·부분 검수의 함정

- "일단 오픈하고 나머지는 추후 보완" 식 조건부 검수는 실무에서 흔하다 — 받아들이되, **잔여 결함 목록 + 항목별 수정 기한 + 그 외는 통과**를 반드시 서면으로 남긴다. 구두 조건부 검수는 "검수 안 끝났다"와 구분이 안 되고, 잔금과 하자보수 개시가 공중에 뜬다.
- 부분 검수(모듈별 검수)는 경계를 명시한다: 통과된 모듈의 재검수 요구는 다른 모듈 결함이 그 모듈에 **영향을 준 경우**로 한정 — 아니면 마지막 모듈 검수가 전체 재검수가 된다.
- 발주사 사유의 검수 지연(인원 미배정·데이터 미제공)도 기록하고 일정 영향을 즉시 공지한다 — 종료 시점 책임 공방의 방어 자료다.

## 검수 완료 = 하자보수 개시 — 스냅샷을 남긴다

검수 통과 시점에 다음을 **기준 시점 스냅샷**으로 고정해 양측이 보관한다. 이 스냅샷이 하자보수 기간 "무상 결함 vs 유상 CR" 판정의 정본이다 → [[결함 관리 실전]]:

- 검수 결과서 (시나리오별 판정 + 판정 근거)
- 잔여 결함 목록과 합의 기한
- 통과 시점의 요구사항·시나리오 확정본 버전
- 검수 통과 버전의 소스·배포 식별자 (무엇이 통과한 판인지)

## 안티패턴

- **검수 직전에 기준 협상** — 결함이 이미 보이는 상태에서 통과 기준을 정하면 기준이 아니라 흥정이다.
- **개발자용 테스트 문서를 검수 시나리오로 재사용** — 시스템 단계 나열은 현업이 판정할 수 없다 → [[시나리오·예외사항 문서 작성법]].
- **검수 중 수시 배포** — 발주사가 테스트하던 판이 소리 없이 바뀌면 그날까지의 결과가 전부 무효 취급된다.
- **결함 지적을 방어부터** — 검수장에서 "그건 원래 그래요"로 응수하면 3분류 판정 자체를 불신하게 된다. 접수 → 재현 → 판정의 순서를 지킨다.
- **구두 조건부 검수** — 서면 없는 "일단 오픈"은 검수 완료도 미완료도 아닌 최악의 상태다.

## 관련 문서

- [[00_QA 허브]] — 09_QA 진입점
- [[QA 원리]] — 스모크·회귀 범위·판정의 원리
- [[결함 관리 실전]] — 검수 중 결함의 3분류·심각도 정의·하자보수 판정
- [[시나리오·예외사항 문서 작성법]] — 검수 시나리오 문서의 작성 정본
- [[백엔드 테스트 실전]] — TC ↔ 자동 테스트 추적
- [[SI 수주와 범위 관리]] — 검수 기간 상한·승인 간주·CR·잔금의 계약 측 정본
- [[요구사항과 완료 조건]] — 통과 기준을 기계 검증 가능한 문장으로
- [[개인정보와 컴플라이언스]] — 검수 데이터의 PII·반출 규율