DoD가 왜 중요한가 – 프로젝트 품질과 신뢰를 지키는 핵심 기준
프로젝트를 진행하다 보면, “이 작업이 진짜 끝났다고 말할 수 있을까?”라는 질문이 자주 발생한다. 특히 소프트웨어나 IT 시스템 개발 같은 지식 기반 프로젝트에서는 결과물이 한눈에 파악되지 않거나, 진행률을 수치화하기 어려워서 더욱 고민스럽다. 이 문제를 명확히 해결하는 방법 중 하나가 바로 DoD(Definition of Done), 즉 완료 정의다. 말 그대로 “어떤 조건을 충족했을 때, 우리는 이 항목을 ‘완료’라고 부르겠다”는 팀의 공통 합의라고 할 수 있다.
DoD가 중요한 이유는 간단하다. 프로젝트 성과를 측정하고, 산출물을 확인하는 과정에서 서로 다른 이해관계자들이 제각기 “이 정도면 완성 아니야?”, “아니 아직 테스트가 안 끝났는데?” 같은 불일치를 겪기 쉽기 때문이다. DoD가 명확하다면, 모두가 같은 표준과 체크리스트에 따라 작업 성과를 인정하고, 결함이나 누락된 기능 없이 안정적으로 프로젝트를 진행할 수 있다. PMBOK(프로젝트관리지식체계)에서 범위관리(Scope Management), 품질관리(Quality Management), 이해관계자관리(Stakeholder Management) 지식 영역이 중요한 이유 역시, 결국 “어떤 기준으로 결과를 받아들이고 확인할 것인가?”를 확립하는 데 있다.
애자일(Agile) 접근법이 확산되면서, DoD라는 개념이 더욱 부상하고 있다. 매 스프린트마다 사용자 스토리가 완료되었다고 선언할 때, 어떤 품질 기준이나 테스트를 만족해야 하는지 미리 정의해 두지 않으면, 스프린트가 끝나고도 결함이 잔뜩 남아 있는 상태가 될 수 있다. 반면, DoD가 명확하면 팀원들은 스토리 포인트를 소진하기 전에 “이 작업이 정말 ‘완료’인지”를 확인하기 위해 일련의 절차(코드 리뷰, 통합 테스트, 문서화 등)를 거치게 된다. 그 결과, 프로젝트 결과물의 품질과 신뢰도는 한층 높아진다.
DoD의 핵심 개념과 구축 프로세스
DoD(완료 정의)란 무엇인가
DoD(Definition of Done)는 특정 작업이 완전히 완료되었다고 보기 위해 충족해야 할 구체적인 조건들을 말한다. 이 조건들은 제품 수준(전반적인 시스템)을 대상으로 할 수도 있고, 스프린트나 이터레이션, 혹은 개별 사용자 스토리마다 세밀하게 다르게 설정될 수도 있다. 예를 들어, 간단히 “개발했음”이라고 적는 대신에,
- 코딩 표준을 준수했다.
- 단위 테스트가 100% 통과했다.
- 핵심 기능 시나리오에 대한 통합 테스트가 완료되었다.
- 사용설명서(Documentation)가 업데이트되었다.
등을 하나의 체크리스트처럼 만들어 두는 방식이 DoD의 전형적인 모습이다.
PMBOK 프로세스와 DoD 설정 절차
- 요구사항 수집(Collect Requirements) & 범위 정의(Define Scope)
- 프로젝트에서 무엇을 만들고, 어떤 기능·결과물을 제공해야 하는지 정한다.
- DoD를 준비하기 전에, 우선 WBS(Work Breakdown Structure)나 사용자 스토리 목록을 갖춰야 한다.
- 범위 확인(Validate Scope)
- PMBOK의 범위관리 중 하나인 범위 확인 프로세스에서는 산출물이 공식적으로 수락되는 과정을 다룬다.
- 여기에 DoD가 구체적 지침으로 활용된다. 예: “테스트 커버리지가 80% 이상이어야 범위 확인을 통과한다.”
- 품질 관리(Manage Quality, Control Quality)
- 완료 정의가 실제로 적용될 때, 품질 표준이나 결함 기준 등이 명시되므로, 이를 일관성 있게 점검해야 한다.
- DoD가 애초에 너무 추상적이면 품질관리에 혼선이 생길 수 있으므로, 측정 가능한 항목들로 구성하는 것이 핵심이다.
- 이해관계자 참여(Stakeholder Engagement)
- 최종 사용자가 원하는 수준의 품질과 기능이 무엇인지 이해관계자들과 협의해야 한다.
- 애자일 환경에서는 제품 소유자(Product Owner)가 DoD 항목을 팀과 함께 정의하거나, 경우에 따라 이해관계자의 요구사항을 반영해 가이드라인을 만든다.
- 통합 변경통제(Perform Integrated Change Control)
- 프로젝트 도중 새 요구사항이나 기준 변화가 발생하면, DoD 역시 업데이트될 수 있다. 예: “추가 보안 점검 절차가 필요하다.”
- 이런 변경이 발생하면, 일정·원가·품질 계획에도 반영이 필요하다.
이런 흐름에서 DoD는 ‘어떤 작업이 끝났다고 말하기 위해 필요한 조건’을 구체화함으로써, 범위·품질·이해관계자관리의 중간다리 역할을 해 준다. 프로젝트 초기에는 DoD가 비교적 간단할 수 있지만, 진행 중에 팀이 성숙해지거나 요구사항이 구체화되면서 점점 더 상세해질 수 있다는 점을 염두에 두어야 한다.
PMBOK 지식 영역과 DoD의 연관성
1) 범위관리(Scope Management)
DoD는 범위 확인(Validate Scope)에 직접적인 영향을 미친다. PMBOK에서 말하는 범위 확인은 산출물이 ‘공식적으로 승인’되는지 여부를 판단하는 프로세스인데, DoD가 없다면 승인 기준이 애매해진다. 예컨대 한 팀원이 “이 기능은 완료입니다”라고 주장하지만, 다른 이해관계자는 “테스트가 충분치 않다”고 반박할 수 있다. 반면 DoD가 명확하면 “결함률 1% 이하, 통합 테스트 2회 이상, 문서 리뷰 완료” 같은 식으로 일치된 평가 기준을 갖출 수 있다.
2) 품질관리(Quality Management)
DoD는 사실상 ‘품질 기준’을 구체화한 것이라고 볼 수 있다. PMBOK 품질관리 프로세스(Plan Quality, Manage Quality, Control Quality)에서 결정된 표준들을 DoD에 반영하면, 팀원들은 각 작업 단위나 스토리를 완료할 때마다 해당 품질 요구사항을 자동으로 체크하게 된다. 예를 들어, 코드 표준화 규칙이나 결함 허용 오차, 성능 기준 등을 DoD 항목으로 추가하면, 모든 팀원이 매번 일일이 상기하지 않아도 자연스럽게 품질 수준을 유지하게 된다.
3) 일정관리(Schedule Management)
DoD가 까다롭거나 상세할수록, ‘완료’ 선언에 이르기까지 필요한 시간이 늘어난다. 이는 일정 추정(Estimate Activity Durations)과 스케줄 관리(Develop Schedule, Control Schedule)에 직접 영향을 준다. 예를 들어, “단위 테스트만 거치면 완료”라고 정의한 경우와 “단위 테스트, 통합 테스트, 보안 점검까지 끝내야 완료”라고 정의한 경우, 당연히 작업 기간이 다르게 잡힐 수밖에 없다. 따라서 일정관리에서 DoD가 얼마나 엄격하느냐가 예산과 일정 예측의 정확도를 좌우한다.
4) 이해관계자관리(Stakeholder Management)
프로젝트 이해관계자, 특히 최종 사용자가 DoD 설정 과정에 참여하면, ‘완료’에 대한 기대치가 명확해져 요구사항 충돌을 예방할 수 있다. PMBOK은 이해관계자 참여(Stakeholder Engagement) 지식 영역에서, 프로젝트에 영향을 주거나 받는 사람들을 적시에 올바로 참여시키는 것을 강조한다. DoD가 이들과 합의 없이 일방적으로 정해지면, 나중에 “이렇게 만들어 놓고 왜 완료라고 주장하느냐?” 같은 반발이 생길 수 있다.
5) 통합관리(Integration Management)
프로젝트 진행 중에 발생하는 모든 변경(품질 기준 변경, 추가 테스트 도입 등)은 통합 변경통제를 거친다. DoD의 항목을 변경하는 일 역시 프로젝트 전체에 영향을 주는 변경이므로, 이를 신중히 검토해야 한다. 예컨대 “이제부터는 모든 사용자 스토리에 성능 테스트가 포함되어야 한다”라는 변경을 새롭게 추가했다면, 그에 따른 일정·비용 영향 분석을 함께 진행해야 한다.
프로젝트 실무에서 발생하는 DoD 이슈와 해결 사례
이제 실제 현장에서 팀이 DoD를 설정하고 유지하는 과정에서 자주 벌어지는 문제와 그 해결 사례를 살펴보자.
이슈 1) DoD가 너무 포괄적이거나 모호함
일부 팀은 DoD에 “모든 기능이 100% 버그가 없어야 한다” 같은 비현실적 문구를 넣는다. 또는 “충분히 테스트되었다”와 같이 애매한 표현을 쓰는 경우도 있다. 이런 모호함은 프로젝트 실행 시점에 각자 다르게 해석해, 완료 여부를 놓고 갈등을 일으킬 수 있다.
해결 사례
A 기업은 전사 ERP 시스템 업그레이드 프로젝트를 진행하며, 초기에 DoD 항목을 “충분한 테스트”라고만 적어 놓았다. 그 결과, 팀마다 ‘충분하다’의 기준이 달라 혼선이 생겼다. 결국, 테스트 커버리지(예: 80% 이상), 주요 시나리오(Top 5 핵심 기능) 성공률 95% 이상, 문서화된 테스트 케이스 100건 이상 수행 등 구체적 수치와 조건을 DoD에 추가했다. 이를 통해 팀이 동일한 기준을 적용하게 되었고, 완료 선언을 둘러싼 분쟁이 크게 줄었다.
이슈 2) DoD가 전혀 없는 상태에서 진행
애자일 프로젝트를 표방하지만, 실제로는 ‘완료 정의’를 마련하지 않은 상태로 스프린트를 진행하는 경우도 있다. 그 결과 스토리는 “완료”라고 보고했으나, 이후 결함이나 누락 사항이 계속 발견되어 “완료되었는데 다시 해야 하는” 악순환이 반복된다.
해결 사례
B 스타트업은 모바일 앱 개발을 애자일 방식으로 추진하면서, 팀원들이 각자 맡은 기능을 “개발 끝!”이라고 선언하면 스프린트를 종료해버렸다. 그런데 실제 배포 단계에 이르러서는 다수의 버그와 미완성 UI가 드러나 재작업이 빈번했다. 이를 해결하기 위해, 간단한 DoD를 도입했다. 예: “코드 리뷰 1회 이상, 단위 테스트 80% 이상, UI 검수 완료, 릴리스 노트 작성” 등. 그 결과 스프린트 종료 후에도 뒤늦은 수정이 줄어들고, 한 번에 최종 사용자에게 배포할 수 있는 품질 수준이 올라갔다.
이슈 3) DoD가 불필요하게 복잡해서 일정 지연
반대 케이스로, DoD 항목을 지나치게 엄격하게 잡은 나머지, 실제로 ‘완료’ 판정을 내리기가 어려워지는 상황이 벌어진다. 예컨대 팀 전체가 테스트 자동화 역량이 부족한데도 “모든 기능은 100% 자동화 테스트 통과”를 요구하거나, 문서화 항목이 너무 많아서 실제 업무 시간보다 문서 작성에 더 많은 시간을 쓰게 되는 식이다.
해결 사례
C 조직은 전통적으로 문서 중심 문화를 갖고 있었다. 새롭게 디지털 플랫폼을 구축할 때, 기존 문서화 절차를 모두 DoD에 넣어 “개발자 가이드, 사용자 매뉴얼, API 스펙, 릴리스 노트 등 모두 완성해야 한다”라고 명시했다. 문제는 실제 실행 과정에서 너무 많은 문서가 필요해, 개발 기간보다 문서 작성 기간이 더 길어지면서 일정이 크게 지연되는 것이었다. 결국 PMO는 중요도가 낮은 문서를 DoD에서 제외하고, 예: “개발자 가이드 핵심만 작성(5페이지 이내), 사용자 매뉴얼은 스프린트별 개요만 정리”처럼 최소화된 항목으로 수정했다. 이렇게 간소화하니 팀이 업무 흐름을 유지하면서도 핵심 문서는 빠짐없이 생산할 수 있게 됐다.
이슈 4) DoD와 통합 변경관리의 불일치
프로젝트 진행 도중, “이제부터는 보안 점검 도구를 추가로 사용하자”라는 식의 변경이 결정되면, 해당 항목이 DoD에 반영되어야 한다. 하지만 이를 정식 절차 없이 팀에게 구두로만 알리는 경우, 이후 “왜 저 팀만 보안 점검이 덜 됐는데 완료라고 칭하는가?” 같은 갈등이 발생한다.
해결 사례
D 회사는 금융권 솔루션을 개발하며, 보안 감사 항목이 중간에 추가되었다. 그러나 팀원들은 기존 DoD 문서에 이 사항이 반영되지 않았다고 해서 “우리는 원래대로 완료”라고 주장했다. 결국 PM이 통합 변경통제(Perform Integrated Change Control) 절차를 재점검해, 변경 요청이 정식 문서로 처리되지 않은 점을 발견했다. 이를 다시 승인 절차에 올려 공식화하고, DoD 문서를 업데이트한 뒤, 해당 변경일 이후에 시작한 스토리에만 이 항목을 적용하도록 결정했다. 덕분에 기존 작업은 갈등 없이 넘어가고, 새 작업부터 보안 점검이 필수화되어 혼란을 줄일 수 있었다.
간단한 DoD 예시와 표
아래 표는 간단한 소프트웨어 개발 프로젝트에서 사용자 스토리를 ‘완료’라 부르기 위해 지켜야 할 DoD 항목을 예시로 든 것이다. 실제로는 프로젝트 특성, 기술 스택, 품질 목표 등에 따라 훨씬 다양하거나 구체적으로 달라질 수 있다.
| 항목 | 세부 내용 | 체크 여부 |
|---|---|---|
| 코드 표준 준수 | (예: PEP8 스타일 준수, ESLint 적용 등) | |
| 단위 테스트 통과 | (커버리지 70% 이상, 주요 기능 분기 전부 테스트) | |
| 통합 테스트 및 빌드 확인 | (CI 환경에서 자동 빌드 및 통합 테스트 성공) | |
| UI/UX 검수 | (디자인 가이드라인 준수, 주요 화면 기능 작동 확인) | |
| 요구사항 문서 갱신 | (새로 추가된 API나 기능을 요구사항 문서에 반영) | |
| 버전 관리 태그 설정 | (Git 등 버전관리 도구에 배포 버전을 태그로 기록) |
팀은 각 스토리나 작업 패키지를 마무리할 때 이 표를 보고 모든 항목을 체크했는지 확인한다. 이 중 하나라도 빠지면 아직 “완료”가 아니므로, 남은 작업을 정비한 뒤 다시 체크해야 한다.
애자일 트렌드와 디지털 툴을 통한 DoD 운영
애자일(Agile) 접근법과 DoD
애자일 스크럼(Scrum) 환경에서 매 스프린트마다 기능이 “완료”되어야 실제 고객 가치가 전달된다고 본다. 이때 DoD는 각 스프린트 또는 각 사용자 스토리 수준에서 “이 기능이 정말 배포 가능(Shippable) 상태인가?”를 결정짓는 열쇠다. 스크럼 팀은 스프린트 계획 회의나 레트로스펙티브 회의에서 DoD를 점검·수정해 더 철저한 테스트나 추가 품질 규칙을 도입하기도 한다.
칸반(Kanban) 방식에서도 비슷하게, 칸반 보드의 ‘Done’ 컬럼에 들어가기 전에 어떤 체크리스트를 통과해야 하는지 DoD를 설정해 두면, WIP(Work In Progress)가 완료되는 순간의 품질을 일정 수준으로 유지할 수 있다.
디지털 요구사항 추적 시스템의 활용
JIRA, Confluence, Trello, Asana, Azure DevOps 등 협업 툴을 사용하면, 각 작업 항목(이슈, 스토리)에 DoD 체크리스트를 추가해놓고, 팀원들이 항목별로 완료했는지 실시간으로 표시하도록 설정할 수 있다. 예를 들어, JIRA 이슈 템플릿에 “DoD 체크리스트” 섹션을 만들어 두고, 코딩 완료, 코드 리뷰, 테스트 결과 링크, 문서 업데이트 여부 등을 하나씩 체크하게 만든다. 이렇듯 자동화된 툴과 DoD가 결합하면, 프로젝트 관리자가 별도로 일일이 확인할 필요 없이, 팀원과 이해관계자가 상시로 “어디까지 준비되었는가?”를 살펴볼 수 있다.
또한 DevOps 파이프라인과 결합하면, 빌드/테스트 자동화 결과가 곧바로 DoD 체크리스트에 반영될 수도 있다. 예컨대 CI/CD 시스템이 테스트 성공 여부를 JIRA에 업데이트해 주어, 실패 시에는 “테스트 미통과” 항목이 자동으로 체크 해제되는 식이다. 이런 방식으로 DoD 준수를 실무 환경에 자연스럽게 녹이면, 매 단계에서 품질과 요구사항 충족 상태를 한눈에 파악하기가 쉬워진다.
적용 시 주의점과 최종 정리
DoD(완료 정의)는 애자일, 폭포수 모델 등 프로젝트 접근방식에 상관없이 적용 가능한 범용적 개념이다. 본질은 “작업 종료를 선언하기 전에 어떤 기준과 체크리스트를 충족해야 하는가?”라는 질문이며, 이는 PMBOK 지식 영역 중에서도 범위관리, 품질관리, 이해관계자관리를 중심으로 일정관리, 통합관리 등과 긴밀히 맞물려 있다.
주의해야 할 사항
- 합의와 협업의 결과물
- DoD는 단독으로 결정해서 팀에게 통보하는 형태가 아니라, 팀 내부와 이해관계자(특히 최종 사용자나 제품 소유자)와 협의하여 만든다.
- 필요한 품질 수준, 위험 관리 요소 등을 고려해 함께 설계해야, 실제로 준수 가능하면서도 프로젝트 목표를 달성하는 기준이 된다.
- 측정 가능하고 현실적인 항목 구성
- “결함 없음”처럼 추상적이거나 비현실적인 표현은 피하고, “결함률 1% 이하”, “테스트 시나리오 10가지 이상 성공” 등 구체적인 수치나 체크 가능 항목을 제시한다.
- 프로젝트 초기에 DoD가 다소 간단한 형태라도, 진행하며 필요한 항목을 점진적으로 확장·수정할 수 있다.
- 상시 업데이트와 교육
- DoD는 한 번 정하고 끝이 아니라, 프로젝트가 진화함에 따라 새로운 요구사항이나 품질 기준이 나타날 때마다 변경될 수 있다.
- 변경된 DoD를 전 팀원이 알 수 있도록 공지하고, 필요 시 교육(코드 리뷰 프로세스, 테스트 자동화 도구 사용 방법 등)을 제공해야 한다.
- 통합 변경통제와 연계
- DoD를 수정하는 일이 곧 일정·비용·품질 계획에 영향 줄 수 있으므로, 이 역시 공식 프로세스를 통해 변경 관리해야 한다.
- DoD 변경 후에는 곧바로 작업 일정이나 예산 산정이 달라질 수 있음을 염두에 두고, PMBOK의 통합관리(Integration Management)와 연계한다.
- 지나친 복잡화 지양
- DoD에 너무 많은 항목을 넣으면, 프로젝트가 진행 불가능할 정도로 문서화나 시험 절차가 과중해질 수 있다.
- 프로젝트 특성, 팀 역량, 일정 등을 고려해 ‘가장 핵심적이고 유익한’ 항목을 우선 채택하고, 필요하면 점차 확장하는 방식이 바람직하다.
결국, DoD는 프로젝트 품질과 이해관계자 만족도를 끌어올리는 데 꼭 필요한 ‘명시적 기준’이며, PMBOK의 여러 프로세스를 실무 수준으로 구체화하는 도구라고 볼 수 있다. 범위관리 측면에서는 완료 기준을 분명히 함으로써 애매한 스코프 확장을 막고, 품질관리 측면에서는 프로젝트 전 단계에 걸쳐 표준을 체계적으로 준수하도록 만든다. 또한 이해관계자관리 관점에서도, “이 정도면 끝났다고 봐도 되겠습니까?”가 아니라 “이 체크리스트를 모두 통과했으니, 완료입니다”라고 말할 수 있으니 분쟁 가능성이 크게 줄어든다.
오늘날 애자일 접근법과 디지털 요구사항 추적 시스템이 합쳐지면서, DoD는 개발 과정에서의 ‘자동화된 품질 게이트(Quality Gate)’ 역할을 해낼 수도 있다. CI/CD 파이프라인, 자동화 테스트, 이슈 트래킹 시스템 등과 DoD가 유기적으로 작동하면, 프로젝트 매니저나 팀원이 별도로 크게 신경 쓰지 않아도 각 스토리나 작업이 일정 수준 이상의 품질을 확보한 상태로 진행되도록 자연스럽게 유도할 수 있다.