UAT 설계 — 사용자 참여, 알파·베타 운영, 인수 기준 합의 절차

개념

같은 케이스를 돌려도 UAT 는 다른 활동이다

인수 테스트를 처음 맡은 사람이 가장 먼저 하는 실수는 시스템 테스트 케이스를 복사해 놓고 "이걸 사용자가 돌리면 UAT"라고 생각하는 것이다. 케이스가 같아도 두 활동은 다르다. 차이는 범위가 아니라 누가 통과·실패를 선언하는가 에 있다.

마지막 행이 핵심이다. 시스템 테스트는 조직 내부에서 "됐다"고 판단하면 끝나지만, UAT 는 조직 바깥의 누군가가 "받겠다"고 말해야 끝난다. 그래서 UAT 설계의 절반은 테스트 설계가 아니라 사람과 절차의 설계다.

실사용자를 "아무나" 부르면 실패한다

UAT 참여자를 모을 때 흔한 방식은 "현업에서 시간 되는 분"이다. 이 방식은 두 가지를 동시에 망친다. 시간이 되는 사람은 대개 그 업무의 핵심 사용자가 아니고, 핵심 사용자는 시간이 없다.

선정은 세 축으로 한다.

축 1. 업무 역할 커버리지
     - 시스템을 쓰는 역할을 먼저 나열한다 (예: 접수 담당, 심사 담당, 관리자, 정산 담당)
     - 역할마다 최소 1명. 트랜잭션 양이 많은 역할은 2명 이상
     - 한 사람이 여러 역할을 겸하면 "겸한다"는 사실 자체를 기록한다
 
축 2. 숙련도 분포
     - 고숙련자만 모으면 신규 사용자가 부딪힐 문제가 안 나온다
     - 저숙련자만 모으면 업무 예외 케이스가 안 나온다
     - 권장: 고숙련 40% / 중간 40% / 신규·대체인력 20%
 
축 3. 리스크 기반 가중
     - 모듈 4(레슨 2)의 리스크 분석 결과에서 상위 항목이 걸린 업무에 인원을 더 준다
     - 신규 개발 영역, 법·정산이 걸린 영역, 외부 연동이 많은 영역

인원수는 "많을수록 좋다"가 아니다. 참여자가 늘면 피드백의 양이 아니라 중복과 잡음이 늘고, 정리 비용이 폭증한다. 중소 규모 업무 시스템이라면 역할당 12명, 전체 815명이 관리 가능한 범위다.

준비시키지 않은 참여자는 테스터가 아니라 관객이 된다

UAT 실패의 흔한 원인은 참여자가 무엇을 해야 하는지 모른 채 화면 앞에 앉는 것이다. 참여자에게는 준비 패키지 를 미리 준다.

특히 기록 양식 이 결과 품질을 좌우한다. 참여자에게 재현 절차를 요구하는 대신, 양식이 대신 물어 주게 만든다.

[UAT 피드백 양식]
  1. 어떤 업무를 하려 했나요? (한 줄)
  2. 어떤 화면에서, 무엇을 눌렀나요?
  3. 기대한 결과 / 실제 결과
  4. 이 상태로 업무가 가능한가요?
       (가능 / 불편하지만 가능 / 불가능)
  5. 화면 캡처 첨부
  6. 발생 시각 (로그 대조용)

4번 항목이 UAT 만의 질문이다. 시스템 테스트의 심각도(Severity)는 시스템 관점이지만, UAT 에서는 업무가 되는가 가 1차 분류 기준이 되어야 우선순위 협의가 빨라진다.

알파와 베타 — 목적이 다르다

두 용어가 국내 현장에서는 "먼저 하는 것 / 나중에 하는 것" 정도로 뭉개져 쓰인다. 원래의 구분은 장소와 통제 수준 이다.

목적이 다르므로 찾아내는 결함의 종류도 다르다. 알파는 "업무 흐름이 막힌다"를 찾고, 베타는 "특정 브라우저·기기·네트워크·데이터 규모에서 깨진다"를 찾는다. 알파를 건너뛰고 베타부터 열면 치명 결함이 외부 사용자 앞에서 터지고, 베타를 건너뛰면 환경 문제를 출시 후에 만난다.

베타 운영 — 모집·기간·수집·중단

베타는 "열어 두면 알아서 피드백이 온다"가 성립하지 않는다. 네 가지를 미리 정한다.

[모집]
  - 목표 인원과 목표 구성(기기·OS·업무 유형)을 숫자로 적는다
  - 모집 경로(사내 공지 / 기존 고객 / 공개 신청)와 선발 기준
  - 참여 조건: NDA 여부, 피드백 최소 횟수, 보상
 
[기간]
  - 최소 2주 권장 — 1주는 "설치·첫인상"만 나온다
  - 업무 주기가 있으면 그 주기를 최소 1회 포함 (월마감이 있으면 월말 포함)
  - 중간 체크포인트를 1회 이상 둔다 (1주 차 리뷰)
 
[피드백 수집]
  - 인앱 피드백 버튼 / 전용 폼 / 정기 설문 — 경로를 하나로 모은다
  - 정성 피드백만 받지 않는다. 사용 로그·크래시 리포트·핵심 지표를 함께 본다
  - "응답하지 않은 참여자"도 데이터다 — 이탈 시점을 본다
 
[중단(kill) 기준]
  - 미리 정하지 않으면 나쁜 베타를 질질 끈다
  - 예: 데이터 손실 결함 1건 발생 시 즉시 중단
  - 예: 1주 차 활성 참여율이 목표의 30% 미만이면 중단하고 원인 조사
  - 예: 크래시율이 기준치를 넘으면 신규 모집 중단 후 수정판 배포

베타 참여자에게 기대 수준을 미리 밝히는 것 도 운영의 일부다. "완성품이 아니다, 데이터가 초기화될 수 있다, 이 기능은 아직 없다"를 먼저 말하지 않으면, 피드백의 상당량이 이미 알고 있는 미완성 항목으로 채워진다.

인수 기준은 UAT 전에 합의되어야 한다

UAT 가 분쟁으로 끝나는 사업에는 공통점이 있다. 인수 기준을 UAT 시작 후에 논의하기 시작했다. 기준 없이 테스트를 시작하면 발견된 모든 항목이 협상 대상이 된다.

합의는 세 시점에 걸쳐 굳힌다.

세 번째 시점의 합의문에는 최소한 이것이 들어간다.

1. 대상 범위와 제외 범위 (모듈 31 레슨 1의 제외 범위 원칙을 그대로 쓴다)
2. 통과 기준
     - 필수 시나리오 100% 통과
     - 미해결 결함: Critical 0, Major 0, Minor 는 합의된 조치 계획이 있으면 허용
3. 재시험 규칙: 수정본 반영 주기, 회귀 범위, 재시험 담당
4. 판정 권한자와 대리인 (출장·휴가 대비)
5. 일정: 라운드 수, 라운드별 기간, 결함 수정 창(window)
6. 기록: 무엇을 증거로 남기고 어디에 보관하는가

특히 판정 권한자를 이름으로 적는 것 이 실무적으로 크다. "현업 협의 후 결정"으로 두면 라운드마다 다른 사람이 다른 기준을 말한다.

UAT 에서 나온 항목 — 결함인가 요구 변경인가

UAT 피드백은 세 갈래로 갈린다. 이 분류를 매일 하지 않으면 마지막 주에 몰려서 감정 싸움이 된다.

판정의 기준은 "합의된 문서에 그렇게 적혀 있는가" 하나다. 여기서 문서가 모호하면 판정이 불가능해지는데, 그것 자체가 요구사항 단계의 결함이다(모듈 2 레슨 3에서 본 모호성 탐지가 여기서 비용으로 돌아온다).

실무적으로 권장하는 운영은 매일 15분 분류 회의 다. 발주·수행 양측이 함께 앉아 전날 접수분을 세 갈래로 나누고, 이견이 있는 항목만 별도 목록에 쌓는다. 이견 목록이 일정 수를 넘으면 그것이 곧 요구사항 품질의 신호다.

UAT 가 실패하는 전형 — 개발 지연을 UAT 기간으로 흡수한다

가장 흔한 실패 패턴은 기법 문제가 아니다. 일정 문제다.

원래 계획
  개발 ████████████  통합시험 ████  UAT ██████  검수 ██
 
실제
  개발 ██████████████████████  통합시험 ██  UAT ██  검수 ██
                              ↑ 여기서 밀린 시간이
                                뒤의 두 칸을 먹었다

이 구조에서 벌어지는 일은 예측 가능하다.

1. 불안정한 빌드로 UAT 를 연다. 첫날 로그인이 안 되고, 참여자들은 "이런 걸 왜 보라고 하느냐"는 인상을 갖는다. 첫인상이 나쁘면 이후 피드백이 감정적으로 기운다.
2. 수정 창(window)이 사라진다. 결함을 찾아도 고칠 시간이 없으니, 고치는 대신 "운영 이관 후 조치"로 미루는 목록이 길어진다.
3. 회귀를 못 돈다. 수정본이 다른 곳을 깼는지 확인할 라운드가 없다.
4. 인수가 조건부로 끝난다. 조건부 인수는 하자보수 기간의 분쟁으로 이월된다(레슨 3).

QA 가 이 상황에서 할 수 있는 일은 일정을 되돌리는 것이 아니라 선택지와 대가를 문서로 만드는 것 이다.

[UAT 착수 가능 여부 보고 — 한 장]
  현재 빌드 상태: 필수 시나리오 24건 중 8건이 실행 불가 (로그인·권한)
  선택지 A: 예정대로 착수  → 예상: 1주 차가 환경 대응으로 소진, 유효 UAT 1주
  선택지 B: 1주 연기 후 착수 → 검수 일정 1주 순연 필요
  선택지 C: 범위 축소 착수  → 정산 모듈을 2차 라운드로 분리
  권고: B. 근거는 8건이 전부 선행 기능이라 후속 시나리오가 모두 막힌다는 점
  결정자: (이름)   결정일: (날짜)

핵심은 QA 가 결정하지 않는다 는 것이다. UAT 착수 여부는 사업 결정이다. QA 는 결정에 필요한 사실과 대가를 정확히 만들고, 결정과 근거를 기록으로 남긴다. 이 기록이 나중에 검수 단계에서 "왜 이렇게 됐는가"에 답하는 유일한 문서가 된다.

실무에서 왜 필요한가

인수 테스트는 테스트 활동 중에서 유일하게 돈과 직접 연결된 단계 다. 다른 레벨의 테스트가 실패하면 일정이 밀리지만, 인수가 실패하면 대금 지급이 멈추고 계약 조항이 움직인다. 그래서 여기서는 "결함을 더 찾는 능력"보다 "끝낼 수 있게 만드는 능력"이 값을 갖는다.

제품 조직에서도 구조는 같다. 베타를 열었는데 중단 기준이 없어 나쁜 빌드가 2주를 가면, 회수되는 것은 결함 리포트가 아니라 초기 사용자의 신뢰다. 알파에서 잡았어야 할 치명 결함을 베타에서 만나면 그 비용은 앱스토어 별점으로 남는다.

그리고 UAT 설계는 QA 가 사업 전체를 보는 시야를 갖고 있는지가 드러나는 자리 다. 참여자를 어떻게 고를지, 기준을 언제 합의할지, 지연을 어떻게 보고할지는 테스트 기법 지식으로 답할 수 없다. 이 레슨의 표와 양식은 그 시야를 문서 형태로 갖춰 두기 위한 것이다.

실습 과제

과제 1 — 참여자 선정표 만들기 (20분)

다음 시스템의 UAT 참여자 선정표를 만든다.

중견 제조사의 구매·자재 관리 시스템 교체. 사용자는 구매 담당 12명, 자재 입출고 담당 20명, 검수 담당 5명, 정산 담당 3명, 관리자 2명. 월말 마감 업무가 있고, 외부 공급사 포털과 연동된다. 신규 개발 비중이 큰 영역은 정산과 공급사 연동이다.

표에는 역할, 인원, 숙련도 구성, 선정 이유, 대체 인원을 적는다. 총 인원이 15명을 넘으면 줄이고, 줄이면서 무엇을 포기했는지 를 한 줄로 남긴다.

과제 2 — UAT 착수 기준 합의문 쓰기 (25분)

같은 시스템에 대해 UAT 착수 2주 전에 쓸 합의문을 본문의 6개 항목 형식으로 작성한다. 다음 조건을 반영한다.

• 공급사 포털 연동은 외부 사업자 일정 때문에 UAT 2주 차에야 붙는다
• 발주 측 판정 권한자는 구매팀장이고, 월말 마감 주에는 참석이 어렵다
• 수행사는 결함 수정본을 주 2회(화·금) 배포할 수 있다

작성 후, 이 합의문에서 가장 분쟁 가능성이 높은 문장 하나 를 고르고 왜 그런지 적는다.

과제 3 — 분류 판정 연습 (15분)

UAT 3일 차에 접수된 다음 피드백을 결함 / 요구 변경 / 사용법 문의로 분류하고, 판정 근거를 한 줄씩 적는다. 근거가 "문서 확인 필요"로 끝나는 항목이 있으면 그것도 답이다 — 어떤 문서의 어느 부분을 봐야 하는지까지 적는다.

1. 발주서 저장 후 목록으로 돌아오면 검색 조건이 초기화된다
2. 승인 대기 건이 20건 넘으면 화면이 3초 이상 느려진다
3. 엑셀 다운로드 버튼이 어디 있는지 못 찾겠다
4. 단가를 소수점 둘째 자리까지 넣고 싶은데 첫째 자리까지만 된다
5. 공급사 코드를 입력하면 "존재하지 않는 코드"가 뜨는데 실제로는 있는 코드다
6. 마감 후에도 전표 수정이 되는데, 우리 규정상 막혀야 한다

자가 체크리스트

• UAT 와 시스템 테스트의 차이를 판정 주체·기준 문서·실패의 의미로 설명할 수 있다
• UAT 참여자를 역할 커버리지·숙련도 분포·리스크 가중 세 축으로 선정할 수 있다
• 참여자 준비 패키지의 구성물을 나열하고 각각이 없을 때 생기는 문제를 말할 수 있다
• 알파와 베타를 장소·통제·목적으로 구분하고, 순서를 건너뛸 때의 대가를 설명할 수 있다
• 베타의 모집·기간·수집 경로·중단 기준을 포함한 운영 계획을 쓸 수 있다
• 인수 기준 합의의 세 시점과 각 시점의 참여자를 말할 수 있다
• UAT 착수 기준 합의문에 들어갈 6개 항목을 빠짐없이 나열할 수 있다
• UAT 피드백을 결함·요구 변경·사용법 문의로 가르는 판정 근거를 설명할 수 있다
• 개발 지연이 UAT 기간을 먹을 때 QA 가 무엇을 만들고 무엇을 결정하지 않는지 구분할 수 있다

흔한 실수

• 시스템 테스트 케이스를 그대로 UAT 케이스로 쓴다. 참여자가 기능 목록을 클릭하게 되고, 업무 흐름에서만 드러나는 문제가 안 나온다. UAT 는 시나리오 단위로 쓴다.
• 참여자를 "시간 되는 사람"으로 채운다. 핵심 업무의 예외 케이스를 아는 사람이 빠지면, UAT 를 통과하고 운영 첫 달에 터진다.
• 인수 기준을 UAT 시작 후에 논의한다. 기준이 없으면 발견된 모든 항목이 협상 대상이 되고, 협상력이 큰 쪽이 이긴다. 품질과 무관한 결과가 나온다.
• 알파를 건너뛰고 베타부터 연다. 치명 결함이 외부 사용자 앞에서 터지고, 그 인상은 수정으로 회수되지 않는다.
• 중단 기준 없이 베타를 연다. 나쁜 빌드가 계획된 기간을 다 채우고, 그동안 쌓인 피드백의 대부분이 이미 아는 문제로 중복된다.
• UAT 결함을 전부 "고쳐야 할 것"으로 받는다. 요구 변경을 결함으로 받으면 범위가 무제한으로 늘고, 결함을 요구 변경으로 미루면 계약 위반이 된다. 매일 분류한다.
• 개발 지연을 UAT 기간으로 흡수한다. 가장 흔하고 가장 비싼 실수다. 흡수하지 말고, 선택지와 대가를 문서로 만들어 결정권자에게 올린다.
• 판정 권한자를 직책으로만 적는다. 사람이 바뀌거나 자리를 비우면 라운드마다 기준이 흔들린다. 이름과 대리인을 함께 적는다.

참고 자료

• ISTQB Certified Tester Foundation Level Syllabus — 테스트 레벨 정의에서 인수 테스트(알파·베타 포함)의 위치. 최신판 원문 확인
• ISTQB Glossary — acceptance testing, alpha testing, beta testing, operational acceptance testing 정의
• ISO/IEC/IEEE 29119-2 Test processes — 테스트 레벨별 프로세스 정의. 모듈 8에서 다룬 문서
• 레슨 s1-m02-l03 — 요구사항의 모호성·공백 찾기 (UAT 분쟁의 상류)
• 레슨 s1-m02-l04 — 인수 기준(Acceptance Criteria) 쓰기
• 레슨 s2-m04-l01 — 테스트 계획과 전략, 레벨별 책임 배분
• 레슨 s2-m04-l05 — 릴리스 Go/No-Go 판정 (UAT 착수 판정과 같은 논리)
• 레슨 s2-m06-l01 — 결함 생명주기·심각도·우선순위 (UAT 피드백 분류의 하류)
• 레슨 s2-m56-l03 — 공공 SI 검수 절차 (UAT 이후 발주처 검수로 이어지는 흐름)