완료의 정의(DoD) — 품질 게이트를 팀 합의로 만들기

개념

같은 "완료"라는 단어, 세 사람이 다른 뜻으로 쓴다

개발자   "완료했습니다"  = 코드를 짰고 내 PC에서 돈다
QA       "완료했습니다"  = 테스트했고 결함이 없다
PO       "완료했습니다"  = 사용자가 쓸 수 있는 상태다

이 세 정의가 문서화되지 않으면, 스프린트 리뷰에서 충돌이 일어나는 대신 스프린트 리뷰가 끝난 뒤 운영에서 충돌이 일어난다 . 완료의 정의(Definition of Done, DoD)는 이 세 문장을 하나로 합치는 작업이다.

스크럼 가이드에서 DoD의 정확한 위치

2020년판 스크럼 가이드는 DoD를 증분(Increment)에 붙은 확약(commitment) 으로 정의한다. 세 개의 산출물에 각각 확약이 하나씩 붙는 구조다.

여기서 두 가지가 따라 나온다.

1. DoD는 증분 전체에 적용된다. 스토리 하나가 아니라 이번 스프린트에서 나온 결과물 전체가 이 기준을 만족해야 한다.
2. DoD를 만족하지 못한 작업은 증분에 포함되지 않는다. "80% 완료" 같은 것은 없다. 스크럼 가이드는 이 경우 그 작업이 다음 스프린트 백로그로 돌아간다고 본다.

조직 차원의 DoD가 이미 있으면 팀은 그것을 최소선으로 삼아 더 엄격하게만 만들 수 있다. 완화할 수는 없다.

AC · DoD · 릴리스 기준 — 세 층을 구분한다

모듈 2(레슨 4)에서 인수 기준(AC)과 DoD가 다르다는 것을 이미 봤다. 여기서는 한 층을 더 붙여 세 층으로 본다.

핵심 구분 — AC는 "무엇을 만들었는가", DoD는 "어떻게 만들었는가", 릴리스 기준은 "내보내도 되는가"에 답한다. DoD에 "배송비 규칙이 맞다"를 넣으면 안 되고(그건 AC), AC에 "코드 리뷰를 받았다"를 넣으면 안 된다(그건 DoD).

릴리스 기준은 모듈 4(레슨 5)의 Go/No-Go 판정에서 다룬다. 스프린트마다 릴리스하는 팀에서는 DoD와 릴리스 기준이 합쳐지기도 하지만, 합칠 때도 두 층이 있었다는 것은 기억해 둬야 한다 — 합쳐 두면 "이번 릴리스만 예외" 협상이 DoD 전체를 무너뜨린다.

검증 가능한 DoD 문장 쓰기

DoD 항목의 유일한 품질 기준은 두 사람이 따로 판정해도 같은 답이 나오는가 다.

DoD 초안 — 여기서 빼면서 시작한다

처음부터 완벽한 DoD를 쓰려 하면 합의가 안 된다. 넉넉한 초안을 놓고 "지금 못 지키는 것"을 덜어내는 방식 이 빠르다. 덜어낸 항목은 버리지 않고 "언젠가 넣을 목록"으로 남긴다.

[코드]
  - 작성자 외 1인 이상 PR 승인
  - 정적 분석 Blocker/Critical 0건
  - 새 로직에 단위 테스트가 있고 전체 단위 테스트가 통과한다
 
[테스트]
  - AC의 모든 항목에 대응하는 테스트가 실행·통과했다
  - 회귀 자동화 스위트가 그린이다
  - 실패한 자동화 케이스가 있으면 원인이 분류됐다(제품 결함 / 케이스 결함 / 환경)
  - 탐색 차터 1건 이상 수행, 세션 노트 남김
 
[통합·배포]
  - 스테이징에 배포되어 실제로 동작하는 것을 팀원 1인 이상이 확인했다
  - 기능 플래그가 있으면 끈 상태와 켠 상태 모두 확인했다
  - 롤백 방법이 PR 또는 티켓에 적혀 있다
 
[문서·데이터]
  - API가 바뀌었으면 문서와 변경 이력이 갱신됐다
  - DB 마이그레이션이 있으면 롤백 스크립트가 함께 있다
  - 운영 지표·로그에서 이 기능을 확인할 방법이 있다
 
[예외]
  - 위 항목 중 지키지 못한 것이 있으면 티켓으로 등록되고 PO가 인지했다

마지막 [예외] 블록이 실제로 가장 중요하다. 예외 경로가 없는 DoD는 압박이 오면 그냥 무시되고, 한 번 무시된 DoD는 다시 서지 않는다. 예외를 금지하는 대신 예외를 기록하게 만든다.

스토리별 추가 조건 — DoD를 부풀리지 않는 법

"개인정보를 다루는 스토리는 보안 리뷰가 필요하다"를 DoD에 넣으면, 개인정보와 무관한 스토리 95%가 불필요한 체크를 달고 다닌다. 이럴 때는 DoD 대신 조건부 체크리스트 를 쓴다.

DoD (모든 스토리 공통)             ← 짧게 유지
  + 조건부 항목
      개인정보 필드를 추가/변경했다면 → 보안 리뷰
      결제 흐름을 건드렸다면        → 결제 회귀 스위트 전체 실행
      외부 연동을 추가했다면        → 장애 시 폴백 동작 확인
      DB 스키마를 바꿨다면          → 데이터 마이그레이션 리허설

조건부 항목은 스토리 템플릿의 체크박스로 넣어 두면 리파인먼트에서 자동으로 걸린다. DoD는 짧을수록 지켜진다.

DoD를 진화시키는 회고 질문

DoD는 한 번 만들고 두는 문서가 아니다. 회고에서 두 가지 질문으로 갱신한다.

1. "지난 스프린트에 운영으로 나간 결함 중, DoD에 무엇이 있었다면 막혔을까?" → 항목 추가 후보
2. "DoD 항목 중 최근 3스프린트 동안 한 번도 문제를 잡지 못한 항목은?" → 항목 삭제 후보

두 번째 질문을 안 하면 DoD가 계속 길어지기만 하고, 결국 형식적으로 체크만 하게 된다. 추가만 있고 삭제가 없는 체크리스트는 죽은 체크리스트다.

DoD와 미완료 스토리 — 스프린트 경계에서의 처리

DoD를 만족하지 못한 스토리는 스프린트 리뷰에서 "완료"로 시연하지 않는다. 처리 규칙을 미리 정해 둔다.

마지막 행이 실전에서 가장 자주 일어난다. 이때 QA의 역할은 막는 것이 아니라 선택지와 대가를 명확히 만들고 결정을 기록하는 것 이다(모듈 43 레슨 7의 한 장짜리 상태 보고와 같은 논리다).

실무에서 왜 필요한가

DoD가 없는 팀에서는 품질 기준이 QA 개인의 권위 에 실린다. "이건 나가면 안 됩니다"라고 QA가 말할 때 그 근거가 문서가 아니라 경험이면, 그 말은 개인 의견으로 들리고 일정 압박 앞에서 무너진다. DoD는 그 말을 "팀이 합의한 기준의 3번 항목을 아직 못 지켰습니다"로 바꾼다. 같은 내용이지만 협상 구조가 완전히 다르다.

또 DoD는 신규 입사자의 온보딩 문서 로 가장 효율이 높다. "우리 팀은 이렇게 일합니다"를 열 페이지 문서로 쓰는 대신, DoD 한 장을 보여 주면 절반은 전달된다. 남은 절반은 첫 스토리를 함께 끝내면서 채워진다.

실습 과제

과제 1 — 세 층 분류하기 (12분)

다음 항목을 인수 기준(AC) · 완료의 정의(DoD) · 릴리스 기준 중 어디에 속하는지 분류하고, 그렇게 판단한 이유를 한 줄씩 적는다.

1. 비밀번호는 8자 이상이어야 하고 미만이면 "8자 이상 입력" 메시지가 뜬다
2. 작성자 외 1인 이상이 PR을 승인했다
3. 미해결 Critical 결함이 0건이다
4. 쿠폰과 포인트를 동시에 쓰면 쿠폰이 먼저 적용된다
5. 회귀 자동화 스위트가 그린이다
6. 앱스토어 심사가 통과됐다
7. 새 로직에 단위 테스트가 있다
8. 주문 취소는 배송 시작 전까지만 가능하다

분류 후, 8개 중 애매해서 두 층에 걸치는 항목 이 있는지 찾고 왜 그런지 설명한다.

과제 2 — 우리 팀 DoD v1 만들기 (25분)

본문의 초안에서 시작한다. 각 항목을 세 갈래로 나눈다.

완성된 v1이 8~12개 항목 을 넘으면 조건부 체크리스트로 옮길 것이 있는지 다시 본다. 마지막으로 각 항목에 대해 "두 사람이 따로 판정해도 같은 답이 나오는가"를 확인한다.

과제 3 — 예외 처리 규칙 설계 (15분)

다음 시나리오에 대해 팀이 따를 예외 처리 규칙을 쓴다. 누가 결정하고, 무엇을 기록하고, 언제 해소하는지를 반드시 포함한다.

릴리스 전날, 회귀 자동화 스위트 중 3건이 빨간색이다. 조사해 보니 2건은 테스트 코드가 낡아서 실패하는 것이고, 1건은 원인이 불명확하다. DoD의 "회귀 스위트 그린" 항목을 만족하지 못한다. PO는 이번 릴리스에 마케팅 일정이 걸려 있어 미룰 수 없다고 한다.

자가 체크리스트

• 스크럼 가이드에서 DoD가 어느 산출물의 확약인지 말할 수 있다
• AC·DoD·릴리스 기준의 범위와 작성 주체를 각각 구분할 수 있다
• 임의의 DoD 문장을 보고 검증 가능한지 판정하고 고칠 수 있다
• DoD를 짧게 유지하기 위해 조건부 체크리스트를 쓸 수 있다
• DoD 항목을 추가하는 회고 질문과 삭제하는 회고 질문을 둘 다 말할 수 있다
• DoD 미충족 스토리의 스프린트 경계 처리 규칙을 설명할 수 있다
• 예외 처리 경로가 왜 필요한지, 없으면 무슨 일이 생기는지 말할 수 있다
• 조직 DoD와 팀 DoD의 관계(강화만 가능)를 설명할 수 있다

흔한 실수

• DoD를 QA가 혼자 쓴다. 그러면 그것은 DoD가 아니라 QA의 요구사항 목록이 된다. 개발·PO가 함께 만들지 않은 기준은 압박이 오면 가장 먼저 버려진다.
• AC와 DoD를 섞는다. DoD에 기능 요구사항이 들어가거나, AC에 "코드 리뷰 완료"가 들어간다. 스토리마다 달라지는 것은 AC, 모든 스토리에 같은 것은 DoD다.
• 항목이 30개인 DoD를 만든다. 길면 형식적으로 체크만 하게 된다. 공통 항목은 10개 안팎으로 두고 나머지는 조건부 체크리스트로 옮긴다.
• 예외 경로 없이 "절대 예외 없음"으로 선언한다. 첫 번째 압박에서 그냥 무시되고, 그다음부터는 DoD가 없는 것과 같아진다. 예외를 기록하게 만드는 편이 훨씬 강하다.
• 한 번 만들고 방치한다. 운영 결함이 나올 때마다 "DoD에 무엇이 있었다면 막혔을까"를 묻지 않으면 DoD는 늙는다. 동시에 삭제 질문을 하지 않으면 비대해진다.
• DoD 미충족을 부분 완료로 인정한다. "90% 완료"를 허용하는 순간 번다운도 예측도 의미를 잃는다. 크기가 문제라면 스토리를 쪼개는 것이 답이다(레슨 3).

참고 자료

• The 2020 Scrum Guide — DoD를 증분의 확약으로 정의한 원문. 2026년 현재 최신판
• Scrum Guide Revisions — 판본별 변경 이력(2020년판에서 확약 개념 도입)
• What is a Definition of Done? (Scrum.org) — DoD 해설과 흔한 오해
• 레슨 s1-m02-l04 — 수용 기준(Acceptance Criteria)과 요구사항의 관계
• 레슨 s2-m04-l05 — 릴리스 Go/No-Go 판정
• 레슨 s2-m07-l08 — 애자일에서 QA가 실제로 하는 일 (DoD 작성 과제 포함)
• 레슨 s2-m48-l01 — 테스트 4분면과 스프린트 내 테스트 타이밍