같은 프로젝트, 마지막 한 달.
수행사 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·인수조건·검증방법·합부) 를 발주사와 함께 작성하고 서명으로 고정한다.
- 모호한 형용사를 측정 가능한 수치·조건으로 바꿔, 합부를 사람이 아니라 기준이 판정하게 한다.
- 단계별 검수(설계·중간·단위 산출물)를 두어 마지막에 몰리지 않게 한다 — 최종 검수가 처음 보는 자리가 되면 안 된다.
- 검수 대상(요구 충족)과 하자(검수 후 발견 결함) 의 경계를 미리 정의해, 무엇이 잔금 지급 조건이고 무엇이 하자보수로 넘어가는지 구분한다.
검수는 통과시켜 달라고 부탁하는 자리가 아니라, 미리 합의한 표를 함께 확인하는 자리여야 합니다.
심화 — 기준을 다 채워도 도장이 안 찍히는 이유
심화: 검수의 역학 — 서명의 무게와 검수 지연이라는 협상 카드
본문은 '기준을 미리 합의하면 검수는 확인 작업이 된다'고 정리했습니다. 그런데 현장에서는 인수 기준을 다 충족했는데도 검수확인서에 도장이 안 찍히는 일이 흔합니다. 기준의 문제가 아니라 서명이라는 행위의 무게 때문입니다.
- 서명자의 개인 리스크: 검수확인서에 서명한 발주사 담당자는 이후 그 시스템에서 문제가 터지면 "검수를 부실하게 한 사람"이 됩니다. 특히 공공·금융처럼 감사가 강한 조직에서 서명은 개인의 경력 리스크입니다. 그래서 기준 충족 여부와 무관하게 서명은 미뤄집니다 — "위에 보고하고요", "다음 달 감사 끝나고요". 검수가 늦는 이유의 절반은 기술이 아니라 이 심리입니다.
- 검수 지연은 협상 카드가 됩니다: 검수 전까지 잔금은 묶여 있고, 프로젝트는 형식상 '진행 중'입니다. 이 상태가 발주사에게 유리하다는 것을 아는 순간, 검수 지연은 무기가 됩니다 — "검수 전이니까 이것도 좀 봐 주세요"라며 개선 요청이 계속 들어오고, 수행사는 잔금 때문에 거절하지 못합니다. 검수가 늦어질수록 무상 작업이 쌓이는 구조입니다.
- 기한 조항이 방어선입니다: 공공 계약은 국가계약법령상 검사 기한(계약상대자가 검사를 요청하면 일정 기일 내 검사)이 있어 공문으로 검수를 요청하면 시계가 돌기 시작합니다. 민간은 그런 기본값이 없으므로 계약서에 검사 기한과 간주 검수 조항("검수 요청 후 N일 내 서면 이의가 없으면 검수한 것으로 본다")을 넣는 것이 수행사의 몇 안 되는 방어선입니다. 그리고 이 조항은 검수 요청을 공문으로 보내야 작동합니다 — 구두·메신저 요청은 기산점이 되지 않습니다.
- 하자의 경계도 게이밍됩니다: 검수 후 하자보수 기간에 '하자'라는 이름으로 사실상의 기능 개선을 요구하는 관행이 있습니다. 하자는 '검수 시점 기준을 충족하지 못한 결함'이고, 새 요구는 유상 변경입니다 — 이 경계를 검수 기준표와 함께 미리 글로 그어 두지 않으면(계약·과업범위·M/M·검수), 하자보수 기간이 무상 2차 프로젝트가 됩니다.
규모별로도 다릅니다. 대형 공공은 감리의 시정조치 확인이 사실상 검수의 선행 게이트라 절차는 무겁지만 예측 가능하고, 중소 민간은 절차가 가벼운 대신 기한 조항이 없으면 검수가 무한정 표류할 수 있습니다. 어느 쪽이든 원칙은 같습니다 — 검수를 상대의 선의에 맡기지 말고, 기한·간주·공문이라는 절차에 태우는 것입니다.
상황: 오픈은 예정일에 했고 시스템은 안정적으로 운영 중입니다. 그런데 발주사 담당 과장이 "이 화면 하나만 더 고쳐주시면 바로 검수 올릴게요"를 반복한 지 넉 달째입니다. 그동안 처리한 '하나만 더'가 15건, 남겨둔 인력 2명의 투입이 누적 4 M/M을 넘었고 잔금 30%는 미수입니다. 12월 말, 그 과장이 인사이동으로 떠나고 새 담당자가 옵니다 — "저는 이 사업 경위를 모릅니다. 처음부터 다시 검토하겠습니다."
원인: 세 겹입니다. (1) 계약서에 검사 기한·간주 검수 조항이 없어 검수를 미뤄도 발주사가 잃는 것이 없었고, (2) 검수 요청을 공문이 아니라 구두와 메일로만 해서 법적으로는 검수를 '요청한 적조차 없는' 상태였으며, (3) '하나만 더'를 변경요청 절차 없이 계속 받아 줘 검수 지연이 발주사에게 이득이 되는 구조를 수행사 스스로 유지시켰습니다. 담당자 교체는 원인이 아니라 이 구조가 언젠가 맞을 결말이었을 뿐입니다.
진단: 검수 요청 공문 발송 이력을 확인합니다 — 없다면 기산점이 존재하지 않으므로 지연에 대한 항변 근거도 없습니다. 다음으로 오픈 이후 처리한 요청 15건을 목록화해 각각이 '검수 기준 미충족(하자성)'인지 '신규 요구(변경성)'인지 분류하고, 투입 공수를 정량화합니다. 이 두 가지가 협상 테이블에 올릴 수 있는 전부입니다.
해결: 즉시 공문으로 검수를 요청해 기산점을 만들고, 인수 기준표 대비 충족 증빙(시험 결과·운영 실적)을 첨부합니다. 잔여 요청은 하자성/변경성으로 분류한 목록을 공문에 함께 실어 "하자성은 하자보수로 이행, 변경성은 별도 협의"로 경계를 긋습니다. 새 담당자에게는 '처음부터 재검토'가 아니라 기존 합의 문서(인수 기준표·단계별 검수 기록)를 근거로 잔여 쟁점만 좁혀 줍니다 — 단계별 검수 기록이 남아 있다면 최종 검수는 마지막 단계만 다투면 됩니다. 재발 방지로는 표준 계약에 검사 기한·간주 검수 조항을 넣고, 오픈 후 요청은 건수와 무관하게 전부 변경요청 대장에 태우는 것 — '좋은 관계를 위한 무상 처리'가 사실은 검수를 늦추는 유인이었다는 점을 조직이 학습해야 합니다.
한국 SI에서 '검수'는 단순한 형식이 아니라 대금·책임의 분기점입니다. 흐름은 보통 이렇게 갑니다.
- 단계별 검수: 분석·설계·구현 등 단계마다 산출물(요구사항정의서·설계서·시험결과서 등)을 발주사가 확인합니다. 마지막에 몰지 않기 위한 장치입니다.
- 인수 시험(UAT): 발주사(현업 사용자)가 실제 업무 시나리오로 시스템을 직접 검증합니다. 여기서 쓰는 도구가 바로 인수 기준 표와 검수 체크리스트입니다.
- 최종 검수 · 검수확인서: 합의한 인수 기준 충족을 공식 확인하고 발주사가 검수확인서에 서명·날인합니다. 이 시점이 통상 잔금 지급의 근거이자 하자담보(하자보수) 기간의 기산점이 됩니다.
- 하자 vs 검수 대상: 검수 후 발견되는 결함은 보통 '하자'로 분류돼 하자보수 기간 동안 보수합니다. 그래서 무엇이 '검수해야 할 요구'이고 무엇이 '하자'인지의 경계를 검수 기준에서 미리 그어 두는 것이 분쟁을 막는 핵심입니다.
관리자(PM/PMO)로서 당신의 일은 코드를 검사하는 게 아니라, '완료의 정의'를 착수 시점에 글과 표로 고정하고, 검수를 협상이 아니라 확인 작업으로 설계하는 것입니다. 협력사가 실제 구현을 하더라도, 인수 기준·검수 절차·검수확인서의 책임은 관리자에게 있습니다. 잘 만든 인수 기준 표 한 장이, 마지막 달의 소송 한 건을 막습니다.
실전 랩으로 손에 익히기: 품질·검수 실습 — 완료 기준·인수 조건을 착수 전 합의하고 검수·UAT 절차를 설계합니다.
관련 모듈로 더 깊이:
- 범위와 요구사항 — 검수 기준의 출발점인 범위·요구사항 정의
- 요구사항정의서·검수확인서·릴리즈노트·SLA 리포트 — 인수 기준·검수 체크리스트 산출물을 작성하는 법
- 계약·과업범위·M/M·검수 — 검수확인서가 대금·하자담보와 묶이는 계약 구조
다음 모듈에서는 이렇게 합의한 기준과 결과를 이해관계자와 어떻게 커뮤니케이션하는가 — 보고의 대상·주기·형식과, 좋은 소식보다 나쁜 소식을 먼저 전하는 보고 원칙을 다룹니다.