UAT가 형식적 서명으로 끝나는 이유
많은 프로젝트에서 현업 담당자가 시스템을 처음 써보는 시점은 오픈 일주일 전입니다. 그때 "월마감 화면이 우리 방식과 다르다"는 의견이 나오면 고칠 시간이 없습니다. 결국 일단 오픈하고 나중에 고치자는 결론으로 검수 확인서에 서명하게 됩니다.
개발사 테스트와 인수 테스트는 목적이 다릅니다
설계서와 똑같이 만들었어도 업무가 돌아가지 않을 수 있습니다. 이 차이를 잡는 것이 UAT의 역할입니다.
형식화되는 세 가지 원인
인수 기준을 먼저 합의하기
요구사항별 인수 기준
요구사항마다 "무엇이 되면 완료인가"를 문장으로 적습니다. 예를 들어 "반품 처리 기능"이 아니라 "출고 후 30일 이내 반품 건을 등록하면 재고가 자동으로 복원되고 매출이 차감된다"처럼 확인 가능한 결과로 정의합니다.
결함 등급과 오픈 조건
| 등급 | 정의 | 오픈 조건 |
|------|------|----------|
| 치명 | 업무 중단, 데이터 손상 | 0건 |
| 주요 | 우회는 가능하나 업무 부담이 큼 | 합의된 건수 이하 + 조치 일정 확정 |
| 경미 | 화면 문구, 사소한 불편 | 오픈 후 처리 가능 |
이 기준이 없으면 결함 하나를 두고 "이건 치명이다", "아니다 경미하다"로 회의가 길어집니다.
계약상 검수 절차와 연결
인수 기준과 오픈 조건을 계약서의 검수 조항이나 부속 문서에 넣어 두어야 합니다. 그래야 검수 완료가 대금 지급, 하자보수 기간의 시작과 자연스럽게 이어집니다.
시나리오와 데이터 준비
업무 흐름 기반 시나리오
"주문 등록 화면 테스트"가 아니라 "주문 → 출고 → 일부 반품 → 월마감"처럼 실제 업무 흐름을 따라가야 합니다. 결함은 대부분 기능과 기능 사이, 그리고 예외 상황에서 나옵니다. 정상 흐름 하나에 예외 시나리오를 2~3개씩 붙여 두는 방식을 권장합니다.
테스트 데이터와 계정
관리자 계정으로만 테스트하면 권한 결함이 오픈 날에야 드러납니다.
일정 확보와 역할 분담
현업 담당자의 테스트 시간을 공식 일정으로 확보해야 합니다. 예를 들어 담당자 5명이 2주 동안 하루 3시간씩 참여하면 150시간입니다. 이 규모를 미리 계산해 부서장의 승인을 받아 두어야 합니다.
실행과 결함 관리
결함 등록과 재테스트 흐름
결함 양식에는 화면·입력값·기대 결과·실제 결과·재현 절차·캡처를 넣습니다. 흐름은 등록 → 개발사 확인 → 수정 → 등록자 재테스트 → 종료 순서로 진행하며, 종료는 등록자만 할 수 있게 합니다.
결함과 변경 요청의 구분
"이 버튼이 있으면 좋겠다"는 결함이 아니라 변경 요청입니다. 인수 기준에 없던 내용은 별도 목록으로 분리하고, 범위·일정·비용 영향을 검토한 뒤 반영 여부를 결정합니다. 이 구분을 하지 않으면 UAT가 끝나지 않습니다.
일일 현황과 오픈 판단 회의
매일 15분 동안 시나리오 진행률, 등급별 미해결 결함 수, 지연 항목을 공유합니다. 오픈 판단 회의에서는 감이 아니라 앞서 합의한 오픈 조건을 충족했는지만 확인합니다.
구독형 개발에서의 상시 인수
한 번에 몰아서 하는 UAT는 부담이 크고 늦습니다. 구독형 개발에서는 2~4주 단위로 배포할 때마다 해당 기능만 작게 인수 테스트를 합니다. 현업이 오픈 일주일 전이 아니라 개발 첫 달부터 시스템을 쓰게 되니, 업무 방식과의 차이를 일찍 발견하고 적은 비용으로 고칠 수 있습니다.
POLYGLOTSOFT는 구독형 개발 서비스에서 단계마다 인수 기준을 고객과 함께 정하고, 배포마다 검수와 피드백을 반복합니다. 고객은 프로젝트 관리 시스템에서 단계별 진행 상황과 마일스톤을 직접 확인할 수 있습니다. 오픈 직전에 처음 시스템을 보는 프로젝트를 피하고 싶다면 POLYGLOTSOFT에 문의해 주시기 바랍니다.