같은 프로젝트, 마지막 한 달.
수행사 PM은 "다 끝났습니다, 검수만 하면 됩니다"라고 말합니다. 발주사 담당자는 화면을 열어 보더니 "이게 끝이라고요? 모바일에서 깨지고, 대량 업로드는 멈추고, 보고서 양식도 우리가 말한 거랑 다른데요"라고 답합니다.
수행사는 "그건 처음 범위에 없었다"고 하고, 발주사는 "당연히 되는 줄 알았다"고 합니다. 양쪽 다 거짓말을 하는 게 아닙니다. 단지 '완료가 무엇인지'를 시작할 때 같이 적어 두지 않았을 뿐입니다.
이 한 줄의 누락이 잔금 지급을 멈추고, 관계를 망가뜨리고, 때로는 소송으로 갑니다. 반대로 착수 시점에 인수 조건과 검수 기준을 측정 가능하게 합의해 둔 팀은, 마지막 달이 '판정'이 아니라 **'체크리스트 확인'**으로 조용히 끝납니다.
이 모듈은 그 차이 — 품질을 어떻게 정의하고, 무엇을 '완료'로 보며, 검수를 분쟁 없이 닫는가 — 를 다룹니다.
- 1품질을 "요구사항 충족"으로 정의하고, 품질 보증(QA·과정)과 품질 통제(QC·검사)를 구분해 설명할 수 있다
- 2완료 기준(Definition of Done)과 인수 조건(Acceptance Criteria)의 차이와 역할을 자기 말로 정리할 수 있다
- 3모호한 요구를 측정 가능한 인수 조건으로 다시 쓸 수 있다
- 4한국 SI의 단계별 검수·최종 검수·검수확인서·하자 구분 절차를 설명할 수 있다
- 5인수 기준 표와 검수 체크리스트를 직접 작성해 검수 분쟁을 예방할 수 있다
품질이란 '요구사항 충족'이다
비싸게 만드는 것이 아니라, 약속한 것을 채우는 것
품질이라고 하면 흔히 '더 좋게, 더 화려하게'를 떠올립니다. 하지만 프로젝트 품질의 정의는 더 건조합니다 — 합의된 요구사항을 충족하는 정도입니다. 요구한 적 없는 화려한 기능을 붙이는 것은 품질이 아니라 금도금(gold plating), 오히려 일정과 리스크를 늘리는 낭비입니다.
그래서 품질은 두 축으로 나눠 봅니다.
- 합치성(conformance): 약속한 명세대로 만들었는가. (요구ID 대비 충족)
- 적합성(fitness for use): 그래서 사용자가 실제로 쓸 수 있는가. (목적 충족)
두 축이 모두 차야 '품질이 있다'고 말합니다. 명세는 다 채웠는데 정작 쓸 수 없으면 적합성 실패, 잘 쓰이지만 약속과 다르면 합치성 실패입니다. 검수 분쟁은 대개 이 둘 중 어디를 기준으로 볼지부터 어긋나면서 시작됩니다.
핵심 전환: 품질은 **'얼마나 잘 만들까'**의 문제이기 전에, **'무엇을 충족해야 하는가를 먼저 합의했는가'**의 문제입니다.
QA와 QC — 과정을 다듬는가, 결과를 검사하는가
예방(QA)과 검출(QC)은 다른 일이다
품질 활동은 시점과 초점이 다른 두 갈래로 나뉩니다. 둘을 섞어 쓰면 '왜 우리는 테스트를 그렇게 했는데도 불량이 나오지?' 같은 혼란이 생깁니다.
| 구분 | 품질 보증(QA, Quality Assurance) | 품질 통제(QC, Quality Control) |
|---|---|---|
| 질문 | 올바른 방식으로 일하는가 | 만들어진 산출물이 기준에 맞는가 |
| 초점 | 프로세스·표준·절차 | 결과물·산출물 |
| 성격 | 예방(불량이 안 나오게) | 검출(나온 불량을 걸러냄) |
| 시점 | 일하는 동안 상시 | 산출물이 나온 뒤 |
| 활동 예 | 코딩 표준, 동료 리뷰 절차, 체크리스트, 프로세스 감사 | 테스트 실행, 산출물 검토, 결함 기록, 합부 판정 |
| 한 줄 | "제대로 일하면 결과가 좋다" | "결과를 직접 재서 거른다" |
비유하면, QA는 레시피와 주방 위생 규칙을 갖추는 일이고, QC는 나온 음식을 맛보고 통과시킬지 정하는 일입니다. 좋은 레시피만 있고 시식이 없으면 가끔 상한 게 나가고, 시식만 하고 레시피가 없으면 매번 운에 맡깁니다. 둘 다 필요합니다.
검수(인수 시험)는 본질적으로 발주사가 수행하는 QC입니다. 그래서 수행사가 QA(개발 중 리뷰·내부 테스트)를 게을리하면, 발주사의 QC 단계에서 결함이 쏟아져 일정이 무너집니다.
완료 기준(DoD)과 인수 조건(Acceptance Criteria)
'언제 끝났다고 할 것인가'를 두 층위로 적는다
'완료'는 한 단어처럼 보이지만, 실제로는 두 가지 약속이 겹쳐 있습니다.
완료 기준(Definition of Done, DoD) 은 모든 작업에 공통으로 적용되는 '끝났다'의 정의입니다. 팀이 한 번 정해 두고 모든 기능·산출물에 반복 적용합니다. 예: "코드 리뷰 통과 + 단위 테스트 통과 + 문서 갱신 + 스테이징 배포 확인 + 담당자 데모 완료"여야 '완료'라고 부른다. DoD가 없으면 사람마다 '됐다'의 기준이 달라집니다(개발자는 '내 PC에서 됨', QA는 '테스트 통과', PM은 '배포까지').
인수 조건(Acceptance Criteria) 은 개별 요구사항(기능) 하나하나가 충족해야 할 구체적 조건입니다. 요구마다 다르고, '입력 → 동작 → 기대 결과'를 검증 가능하게 적습니다. 검수의 합부는 결국 이 조건으로 가립니다.
| 구분 | 완료 기준(DoD) | 인수 조건(Acceptance Criteria) |
|---|---|---|
| 적용 범위 | 모든 작업에 공통 | 요구사항(기능)마다 개별 |
| 정하는 주체 | 주로 수행팀 내부 합의 | 발주사·수행사 공동 합의 |
| 질문 | "우리가 일을 끝냈다고 부를 조건은?" | "이 기능이 통과하려면 무엇을 만족해야 하나?" |
| 예 | 리뷰·테스트·문서·배포·데모 완료 | "카카오 로그인 시 3초 내 메인 이동, 실패 시 사유 표시" |
모호한 표현은 인수 조건에서 추방해야 합니다. '사용자 친화적', '안정적', '빠르게', '잘 동작' 같은 말은 사람마다 다르게 읽혀 검수 때 그대로 분쟁이 됩니다.
| 모호한 요구 | 측정 가능한 인수 조건으로 다시 쓰기 |
|---|---|
| "로그인이 빨라야 한다" | "정상 입력 시 응답이 평균 1초 이내, 최대 3초 이내" |
| "대량 업로드가 잘 돼야 한다" | "1만 행 엑셀 업로드가 60초 이내 완료, 실패 행은 사유와 함께 리포트" |
| "보고서가 보기 좋아야 한다" | "합의된 양식(샘플 v3) 그대로 PDF 출력, 합계 행 표시, 페이지 번호 포함" |
| "보안이 되어야 한다" | "비밀번호 8자 이상·해시 저장, 5회 실패 시 잠금, 전 구간 HTTPS" |
그림: QA(과정 예방)와 QC(결과 검출)를 나누고, 완료 기준과 인수 조건을 착수 때 측정 가능하게 합의하면 검수는 판정이 아니라 확인이 된다.
직접 해보기 — 인수 기준 표와 검수 체크리스트 만들기
아래는 발주사가 말로 전한 요구입니다. 각 요구를 검수 때 누가 봐도 같은 판정이 나오도록 인수 조건으로 다시 쓰고, 어떻게 검증할지(검증 방법)와 합부 칸을 둔 표를 채워 보세요.
요구1: "회원가입이 간편해야 한다."
요구2: "주문 내역을 빠르게 조회할 수 있어야 한다."
요구3: "장애가 나도 데이터가 안 날아가야 한다."
아래 양식으로 표를 완성합니다. '합부' 칸은 검수 당일 채웁니다(지금은 비워 둠).
| 요구ID | 인수 조건(측정 가능) | 검증 방법 | 합/부 |
|--------|----------------------|-----------|-------|
| REQ-01 | ... | ... | |
| REQ-02 | ... | ... | |
| REQ-03 | ... | ... | |
인수 기준 표: 요구ID · 인수조건 · 검증방법 · 합부인수 기준 표가 '무엇을 충족해야 하나'라면, 검수 체크리스트는 '검수 당일 어떤 순서로 무엇을 눌러 확인하나'입니다. 위 요구 중 하나(예: 주문 조회)를 골라, 재현 가능한 절차로 검수 체크리스트를 만들어 보세요.
| No | 점검 항목 | 수행 절차 | 기대 결과 | 결과(O/X) | 비고 |
|----|-----------|-----------|-----------|-----------|------|
| 1 | ... | ... | ... | | |
작성 후 스스로 물어보세요: "이 체크리스트를 처음 보는 사람이 그대로 실행해도 같은 판정이 나오는가?" 그렇지 않다면 절차나 기대 결과가 아직 모호한 것입니다.
검수 체크리스트: 항목 · 절차 · 기대결과 · 결과- 요구1 변환 예: "이메일·비밀번호 2개 입력 + 인증메일 1회로 가입 완료, 입력 단계 3개 이하" / 검증: 신규 계정 가입을 처음부터 끝까지 수행해 단계 수와 성공 확인
- 요구2 변환 예: "최근 3개월 주문 목록이 2초 이내 표시, 100건 이상이면 페이지네이션" / 검증: 주문 100건 계정으로 조회해 응답 시간 측정
- 요구3 변환 예: "DB 장애 후 복구 시 직전 5분 이내 데이터 유실 0건(백업·복제 기준)" / 검증: 장애 주입 후 복구해 마지막 주문 데이터 존재 확인
- 잘 쓴 인수 조건의 공통점: 입력·동작·기대 결과·수치 기준이 있어 "O/X"를 객관적으로 가릴 수 있다
- 검수 체크리스트의 핵심: "처음 보는 사람이 그대로 따라 해도 같은 결과"가 나오는 재현 가능한 절차인가
- 여전히 "빠르게/잘"이 남아 있다면 그 줄이 바로 검수 당일 다툼이 될 줄 — 지금 수치로 바꾼다
현장에서 자주 보는 함정
증상: 개발은 끝났는데 검수에서 막힙니다. 발주사는 "당연히 되어야 할 기능이 빠졌다", 수행사는 "그건 계약 범위가 아니었다"고 맞섭니다. 잔금 지급이 멈추고, 며칠이면 끝날 검수가 몇 주를 끕니다.
원인: '완료'와 '검수 대상'의 경계를 착수 시점에 글로 못 박지 않았기 때문입니다. 인수 조건이 모호했거나(=합부를 객관적으로 못 가림), 무엇이 '검수 대상 기능'이고 무엇이 '하자' 또는 '추가 요구'인지 기준이 없었던 것입니다. 검수가 '확인'이 아니라 '협상'이 되어 버립니다.
해결 방향:
- 착수 시점에 인수 기준 표(요구ID·인수조건·검증방법·합부) 를 발주사와 함께 작성하고 서명으로 고정한다.
- 모호한 형용사를 측정 가능한 수치·조건으로 바꿔, 합부를 사람이 아니라 기준이 판정하게 한다.
- 단계별 검수(설계·중간·단위 산출물)를 두어 마지막에 몰리지 않게 한다 — 최종 검수가 처음 보는 자리가 되면 안 된다.
- 검수 대상(요구 충족)과 하자(검수 후 발견 결함) 의 경계를 미리 정의해, 무엇이 잔금 지급 조건이고 무엇이 하자보수로 넘어가는지 구분한다.
검수는 통과시켜 달라고 부탁하는 자리가 아니라, 미리 합의한 표를 함께 확인하는 자리여야 합니다.
한국 SI에서 '검수'는 단순한 형식이 아니라 대금·책임의 분기점입니다. 흐름은 보통 이렇게 갑니다.
- 단계별 검수: 분석·설계·구현 등 단계마다 산출물(요구사항정의서·설계서·시험결과서 등)을 발주사가 확인합니다. 마지막에 몰지 않기 위한 장치입니다.
- 인수 시험(UAT): 발주사(현업 사용자)가 실제 업무 시나리오로 시스템을 직접 검증합니다. 여기서 쓰는 도구가 바로 인수 기준 표와 검수 체크리스트입니다.
- 최종 검수 · 검수확인서: 합의한 인수 기준 충족을 공식 확인하고 발주사가 검수확인서에 서명·날인합니다. 이 시점이 통상 잔금 지급의 근거이자 하자담보(하자보수) 기간의 기산점이 됩니다.
- 하자 vs 검수 대상: 검수 후 발견되는 결함은 보통 '하자'로 분류돼 하자보수 기간 동안 보수합니다. 그래서 무엇이 '검수해야 할 요구'이고 무엇이 '하자'인지의 경계를 검수 기준에서 미리 그어 두는 것이 분쟁을 막는 핵심입니다.
관리자(PM/PMO)로서 당신의 일은 코드를 검사하는 게 아니라, '완료의 정의'를 착수 시점에 글과 표로 고정하고, 검수를 협상이 아니라 확인 작업으로 설계하는 것입니다. 협력사가 실제 구현을 하더라도, 인수 기준·검수 절차·검수확인서의 책임은 관리자에게 있습니다. 잘 만든 인수 기준 표 한 장이, 마지막 달의 소송 한 건을 막습니다.
관련 모듈로 더 깊이:
- 범위와 요구사항 — 검수 기준의 출발점인 범위·요구사항 정의
- 요구사항정의서·검수확인서·릴리즈노트·SLA 리포트 — 인수 기준·검수 체크리스트 산출물을 작성하는 법
- 계약·과업범위·M/M·검수 — 검수확인서가 대금·하자담보와 묶이는 계약 구조
다음 모듈에서는 이렇게 합의한 기준과 결과를 이해관계자와 어떻게 커뮤니케이션하는가 — 보고의 대상·주기·형식과, 좋은 소식보다 나쁜 소식을 먼저 전하는 보고 원칙을 다룹니다.