납품 분쟁을 막는 방패: AC를 인수 테스트(UAT)로 바꾸고 사인오프 받는 법
프로젝트는 왜 마지막에 실패할까요? '완료'의 기준이 없었기 때문입니다. 수용 기준(AC)을 테스트 케이스로 바꾸고 정식으로 UAT 서명을 받는 법을 소개합니다.
프리랜서의 악몽: "작동은 하는데..."
"디자인은 컨펌했었는데, 막상 눌러보니까 느낌이 좀... 여기 좀 바꿀 수 있을까요?"
이 말은 보통 런칭 2일 전에 나옵니다. 코드는 완벽합니다. 요구사항도 지켰습니다. 하지만 클라이언트는 승인해주지 않습니다.
왜일까요? 검수 기준을 명확한 시나리오가 아니라 "느낌"에 맡겼기 때문입니다.
"완료(Done)"의 정의를 선점하지 못하면, 무한 수정의 굴레에 빠지게 됩니다. 여기서 탈출하는 유일한 방법은 **수용 기준(AC)**과 **사용자 인수 테스트(UAT)**로 방어선을 구축하는 것입니다.
방어 파이프라인: AC → Test Case → Sign-off
"믿으세요, 다 했습니다"라는 말은 통하지 않습니다. 문서가 필요합니다. 방어 파이프라인은 모호한 합의를 이진법적인(0/1) 증거로 바꿉니다.
1. 수용 기준 (User Story AC): 계약서
분석/설계 단계 작성
AC는 약속입니다. 조건을 설명합니다.
"이메일 형식이 아니면 제출할 수 없다."
2. 테스트 케이스 (Test Case): 대본
개발 완료 전 작성
TC는 증명입니다. 행동을 설명합니다.
"1단계: 'invalid-email' 입력. 2단계: 제출 클릭. 3단계: 에러 메시지 노출 확인."
3. UAT 사인오프 (Sign-off): 입금 트리거
납품 단계 실행
사인오프는 종결입니다. 결과를 승인합니다.
"테스트 케이스 12번이 통과됨을 확인합니다."
모호함의 비용
왜 이렇게 팍팍하게 굴어야 할까요? "직감"은 비싸기 때문입니다. 클라이언트에게 "그냥 한번 써보세요"라고 하면, 그들은 요구사항이 아니라 기분에 따라 테스트합니다.
- 모호한 피드백: "느낌이 별로예요." (대응 불가능, 무한 수정)
- 테스트 케이스 피드백: "3단계에서 에러 메시지가 안 뜹니다." (대응 명확, 10분 컷)
테스트를 선형적인 파이프라인으로 강제하면, 납품 과정에서 불필요한 감정 소모를 없앨 수 있습니다.
심층 분석: 모호함에서 검증된 결과로
하나의 기능이 이 파이프라인을 통과하며 어떻게 변하는지 봅시다. 기능: 비회원 주문
| 단계 | 입력 | 명확성 |
|---|---|---|
| 요구사항 | "로그인 없이 살 수 있어야 함." | 🚩 낮음. 정보는 저장되나? 이메일은? |
| 수용 기준 (AC) | "새로고침 해도 장바구니 유지. 영수증용 이메일 필수." | ⚠️ 중간. 새로고침 두 번 하면? |
| 테스트 케이스 | "1. 상품 담기. 2. 거침. 3. 유지 확인. 4. 로컬스토리지 확인." | ✅ 높음. 통과/실패 명확함. |
"요구사항"만 보고 개발에 뛰어들면, 추측 게임을 하는 겁니다. 코딩 전에 "테스트 케이스"로 변환하면, 정해진 대본대로 연기하는 겁니다.
누가 대본을 쓰나요?
자주 묻는 질문입니다. 이 귀찮은 건 누가 하죠?
| 역할 | 책임 | 산출물 |
|---|---|---|
| 기획자 / PM | "무엇(What)"을 정의 | 유저 스토리 & 수용 기준 (AC) |
| QA / 리드 개발자 | "어떻게(How)"를 검증 | 테스트 케이스 (단계별 지시문) |
| 클라이언트 | "승인(Yes)"을 수행 | UAT 실행 & 사인오프 |
클라이언트가 테스트 케이스를 쓰게 해선 절대 안 됩니다. 그들은 오직 실행만 해야 합니다. 여러분의 일은 채점표를 쥐여주고 "여기 체크만 하세요"라고 말하는 겁니다.
싸우지 않고 UAT 진행하는 법
많은 PM과 프리랜서가 UAT를 단순히 "마지막 테스트"라고 생각하고 건너뜁니다. 하지만 진짜 UAT는 정치적 행위입니다. 결정을 강요하는 과정이죠.
규칙 1: 절대 "그냥 한번 써보세요"라고 링크만 던지지 마세요
스테이징 링크만 주고 "피드백 주세요"라고 하면, 무덤을 파는 겁니다. 색깔이 어떻고 여백이 어떻고... 50개의 개인적 취향 피드백을 받게 될 겁니다.
반드시 테스트 시트(엑셀/문서)를 같이 보내세요. 클라이언트가 체크박스에 체크하게 만드세요. 통과/실패(Pass/Fail)를 선택하게 해야 합니다.
규칙 2: 테스트 실패는 좋은 겁니다
특정 테스트 케이스가 실패했다면, 그건 재앙이 아닙니다. 그냥 버그 리포트입니다. 문제의 범위를 "전체가 이상해"가 아니라 *"이 기능의 이 부분"*으로 한정 지어주니까요.
규칙 3: 사인오프는 이진법입니다
모든 핵심 테스트 케이스가 통과했다면, 프로젝트는 끝난(Done) 겁니다. 사인오프 이후의 모든 피드백은 **추가 개발(Change Request)**입니다.
방어선 구축을 위한 uDocit의 역할
uDocit은 이 파이프라인의 첫 단추인 요구사항과 AC를 체계적으로 잡아줍니다. 유저 스토리에 수용 기준(AC)을 명확히 적는 것만으로도, 이미 UAT 대본의 절반은 쓴 셈입니다.
(AC를 기반으로 테스트 케이스를 자동 생성해 주는 기능도 준비 중이니 기대해 주세요.)
핵심 요약 코드를 납품하지 마세요. '통과된 테스트'를 납품하세요. 스코프 크립(Scope Creep)을 막는 가장 강력한 방패는, 체크 표시가 된 문서입니다.
