3줄 요약
- 품질은 사후 검사가 아니라 계획 단계에서 설계하는 것이다. 예방 비용이 실패 비용보다 항상 싸다.
- DoD(완료 정의)와 인수 기준(Acceptance Criteria)을 팀이 사전에 합의하지 않으면 “다 됐다”는 말이 사람마다 달라진다.
- 소프트웨어 품질 통제는 CI·자동화 테스트로 상시화하고, PSTA에서 완료는 상태값으로 이진 판정한다.
“이번 스프린트 다 완료했습니다.” — “그런데 테스트는요?” — “…그건 다음에요.”
이 대화, 한 번쯤 겪어봤을 것이다. 개발자는 기능 구현을 마쳤다. PM은 배포를 기다리고 있다. 그런데 발주사 담당자가 화면을 열어보더니 “이게 완성이에요?”라고 한다. 누가 틀렸는가? 사실 아무도 ‘완료’가 무엇인지 미리 정해두지 않았을 뿐이다.
PMBOK 8장은 품질 관리(Quality Management) 지식영역을 다룬다. 품질이란 무엇인가에 대한 PMBOK의 정의는 명쾌하다. 품질이란 요구사항을 충족하는 정도다. 좋은 것, 고급스러운 것이 아니라, 애초에 합의한 기준에 부합하는지 여부다. 그리고 그 기준을 누가, 언제, 어떻게 정하느냐가 품질 관리의 핵심이다.
📖 PMBOK 8장이 말하는 것: 품질은 계획하는 것이다
PMBOK 8장은 품질 관리를 세 개의 프로세스로 구분한다.
- 품질 관리 계획(Plan Quality Management): 어떤 품질 기준을 어떻게 충족할 것인지 사전에 정의한다. 품질 측정지표, 체크리스트, 수용 기준을 이 시점에 확정한다.
- 품질 보증(Manage Quality): 프로세스가 올바르게 실행되고 있는지 감사(Audit)한다. 산출물이 아니라 ‘일하는 방식’이 기준에 맞는지 확인하는 것이다.
- 품질 통제(Control Quality): 실제 산출물을 기준과 비교·검사(Inspection)한다. 결함을 찾아 수정하고, 인수 여부를 판정한다.
이 세 프로세스는 순서가 중요하다. 계획 없이 통제부터 하면, 무엇을 기준으로 검사하는지 모호해진다. PMBOK이 강조하는 핵심 원칙은 두 가지다. 첫째, 예방(Prevention)이 검사(Inspection)보다 싸다. 결함을 나중에 발견해 고치는 비용은 처음부터 제대로 만드는 비용보다 몇 배 크다. 이를 COQ(품질 비용, Cost of Quality)로 정량화한다. COQ는 적합 비용(교육·테스트 등 예방 투자)과 비적합 비용(재작업·클레임 등 실패 대가)으로 나뉜다. 둘째, 인수(Acceptance)는 계약의 종료 조건이다. 인수 기준(Acceptance Criteria)이 사전에 명시되어 있지 않으면 인수는 감정과 협상의 영역으로 밀려난다.
✅ 읽으며 좋았던 점: “품질은 검사가 아니라 설계다”
솔직히 말하면, 8장을 읽기 전까지 품질 관리는 “배포 전에 QA팀이 테스트하는 것” 정도로 생각했다. 그런데 PMBOK의 시각은 달랐다. 품질은 마지막 단계에서 점검하는 것이 아니라, 프로젝트 착수 시점에 계획하고 설계해야 하는 것이다.
COQ 개념도 인상적이었다. “테스트에 돈을 더 쓰면 나중에 재작업 비용이 줄어든다”는 논리는 단순하지만, 숫자로 보여줄 수 있으면 경영진 설득 자료가 된다. 버그를 스테이징에서 잡는 것이 프로덕션에서 잡는 것보다 훨씬 싸다는 건 SW 개발자라면 누구나 동의한다. 품질 보증과 품질 통제를 개념적으로 분리한 것도 유용하다. 보증은 프로세스를, 통제는 산출물을 본다. “올바른 방식으로 일하고 있는가”와 “만든 것이 기준에 맞는가”는 다른 질문이고, 둘 다 필요하다.
⚠️ 현장과의 괴리: DoD가 없으면 “완료”는 존재하지 않는다
문제는 현장이다. SW 프로젝트에서 품질 관리는 PMBOK이 그린 그림처럼 깔끔하게 작동하지 않는다.
가장 큰 현장 문제는 DoD(Definition of Done, 완료 정의)의 부재다. DoD란 “이 기능이 완료됐다고 말할 수 있으려면 어떤 조건을 모두 충족해야 하는가”를 팀이 사전에 합의한 기준이다. 코드 작성만이냐, 코드리뷰까지냐, 테스트 통과까지냐, 문서화까지냐. DoD가 없으면 “완료”는 개인마다 다른 뜻이 된다. 어떤 개발자는 기능이 돌아가면 완료라고 생각하고, PM은 버그가 없어야 완료라고 생각하고, 발주사는 자신들이 직접 테스트해서 통과해야 완료라고 생각한다.
두 번째는 발주사-수행사 간 검수 분쟁이다. 계약서에 “기능 A를 구현한다”고만 적혀 있고 인수 기준이 없으면, 수행사는 구현했다고 하고 발주사는 기대와 다르다고 한다. 법적 분쟁까지 번지는 경우도 있다. 세 번째는 프로세스 기반 품질 보증이 SW 팀에 맞지 않는다는 점이다. 2주 스프린트로 빠르게 반복하는 팀에서 감사 문서를 매번 작성하는 것은 현실적이지 않다. 코드리뷰와 자동화 테스트가 그 역할을 대신한다.
🔧 실전 번역: 소프트웨어 팀의 품질관리는 이렇게
현장에서 PMBOK 8장의 원칙을 실제로 작동시키려면 몇 가지 도구와 습관이 필요하다.
- 팀 DoD(완료 정의) 사전 합의: 킥오프 시 “이 조건을 모두 충족해야 완료”라는 체크리스트를 팀 전체가 동의한다. 예: ① 코드리뷰 통과 ② 단위 테스트 통과 ③ QA 환경 확인 ④ 문서 업데이트. 한번 합의하면 매 스토리마다 재논의할 필요가 없다.
- 스토리별 인수 기준(Acceptance Criteria) 명시: 백로그 아이템마다 Given-When-Then 형태로 “이 기능이 올바르게 작동하는지 어떻게 확인하나”를 적는다. 인수 기준이 있으면 발주사와의 검수 기준이 명확해지고, “다 됐다”는 말의 의미가 달라지지 않는다.
- CI/CD로 품질 통제 상시화: 코드가 병합될 때마다 자동화 테스트가 실행되는 파이프라인은 상시 품질 통제다. 파이프라인이 실패하면 머지가 막히는 구조가 PMBOK의 “예방이 검사보다 싸다”를 코드로 구현한 것이다.
- “완료”는 이진(Binary): “70% 완료”는 관리할 수 없다. DoD 체크리스트의 모든 항목이 통과됐으면 완료, 하나라도 미통과면 미완료다.
- 검수 근거 보관: 발주사 인수 시 화면 캡처·테스트 리포트를 남긴다. 나중에 분쟁이 생겼을 때 기록이 있는 쪽이 유리하다.
아래는 소프트웨어 검수 기준과 기존 방식의 비교다.
| 구분 | DoD·인수기준 없음 | DoD·인수기준 명시 |
|---|---|---|
| 완료 판단 | 개인마다 다름 | 체크리스트로 이진 판정 |
| 검수 분쟁 | 잦음 (기대 불일치) | 드묾 (기준 사전 합의) |
| 품질 통제 시점 | 배포 직전 몰아서 | PR·CI 단계마다 상시 |
| 재작업 비용 | 높음 (늦게 발견) | 낮음 (일찍 발견) |
| 발주사 신뢰 | 흔들림 | 검수 근거로 유지 |
🟥 PSTA로 보면 / 🟨 PSTA도 아쉬운 점
PSTA로 보면
PSTA에서 품질 통제의 핵심은 Action 상태값으로 완료를 이진 판정하는 구조다. Action은 할 것(TODO) → 하는 중(IN_PROGRESS) → 완료(DONE) → 반려(REJECTED)의 상태만 존재한다. “거의 다 됐어요” 같은 중간 상태는 없다. 이것이 팀 내에서 DoD를 강제하는 가장 단순한 장치다.
또한 산출물과 보고서를 스냅샷으로 박제(보관)하는 기능이 있다. 발주사 검수 시 무엇을 언제 제출했는지, 어떤 상태였는지를 타임스탬프와 함께 기록으로 남길 수 있어 검수 분쟁의 사전 예방 근거가 된다. “다 됐다는데 안 됐다”는 분쟁에서 기록이 있는 쪽이 유리하다.
다만 PSTA도 아쉬운 점이 있다. 품질 게이트·QA 워크플로·테스트 케이스 관리 기능은 없다. DoD 체크리스트를 PSTA 안에서 정의하거나, 특정 조건을 모두 통과해야 상태 전환이 허용되는 품질 게이트 기능은 지원하지 않는다. CI/CD 파이프라인 연동이나 자동화 테스트 결과 집계도 마찬가지다. 품질 보증을 체계적으로 하려면 Jira·TestRail·GitHub Actions 같은 별도 QA 도구가 필요하고, PSTA는 그 결과를 받아 완료 여부를 기록하는 역할을 한다.
🎓 이 장을 떼면 당신은 이것을 할 수 있다
- 프로젝트 킥오프 시 팀 DoD(완료 정의)를 작성하고, 구성원 전체의 동의를 받을 수 있다.
- 백로그 스토리마다 인수 기준(Acceptance Criteria)을 명시해, 발주사와의 검수 분쟁을 사전에 예방할 수 있다.
- 예방 비용(테스트·코드리뷰)과 실패 비용(재작업·클레임)의 트레이드오프를 설명하고, 예방에 투자하는 근거를 경영진에게 제시할 수 있다.
- 품질 보증(프로세스 감사)과 품질 통제(산출물 검사)의 차이를 설명하고, 팀의 개발 프로세스에 어느 것이 부족한지 진단할 수 있다.
- CI 파이프라인·코드리뷰·자동화 테스트가 PMBOK 품질 통제의 SW 버전임을 팀에 설명하고, 도입을 제안할 수 있다.
❓ FAQ
DoD(완료 정의)란 무엇인가?
DoD(Definition of Done, 완료 정의)란 팀이 사전에 합의한 “이 작업이 완료됐다고 인정받으려면 충족해야 하는 조건의 목록”이다. 예를 들어 “코드리뷰 통과 + 단위 테스트 작성 + QA 환경 확인 + 기술 문서 업데이트”라는 조건이 모두 충족되어야 비로소 완료로 인정된다. DoD가 없으면 완료의 의미가 사람마다 달라지고, 반복적인 재작업과 소통 비용이 발생한다.
인수 기준(Acceptance Criteria)을 어떻게 작성하나?
인수 기준은 백로그 스토리마다 “이 기능이 올바르게 작동하는지 어떻게 확인하나”를 서술한 조건이다. 가장 실용적인 형식은 Given-When-Then이다. 예: “Given: 로그인된 사용자 / When: 파일 업로드 / Then: 완료 알림 + 목록 노출.” 이 형식으로 작성하면 개발자·테스터·발주사가 동일한 기준으로 완료를 판단할 수 있다.
소프트웨어 검수 분쟁을 어떻게 예방하나?
가장 효과적인 예방책은 착수 시 인수 기준을 문서로 합의하는 것이다. “기능 A를 구현한다”가 아니라, 조건·동작·결과까지 구체적으로 적어야 한다. 개발 중간에 발주사 데모를 반복하면 최종 검수 시 기대 불일치를 줄일 수 있다. 검수 결과는 화면 캡처·리포트로 보관해 분쟁 근거로 활용한다.
품질 보증과 품질 통제의 차이는?
품질 보증(Quality Assurance)은 프로세스를 본다. “우리 팀이 올바른 방식으로 일하고 있는가?”를 감사하는 활동이다. 품질 통제(Quality Control)는 산출물을 본다. “우리가 만든 것이 기준에 맞는가?”를 검사하는 활동이다. SW 프로젝트에서 품질 보증은 코드리뷰 프로세스·개발 표준 준수 점검이고, 품질 통제는 테스트 실행·버그 추적·인수 검수다. 둘 다 있어야 품질이 관리된다.
팀의 DoD를 지금 당장 한 장으로 만들어보고 싶다면, 주니크에 문의하거나 PSTA에서 직접 시작해볼 수 있다.
『PMBOK 완독기』 시리즈
← 이전: 05. 원가관리: EVM·번다운 (7장)
→ 다음: 07. 자원관리: RACI와 역할 분담 (9장)
