Definition of Done(DoD, 완료 정의)란 무엇인가요?

Definition of Done(DoD, 완료 정의) 는 스크럼 프레임워크에서 제품 인크리먼트(Increment)가 "완료"되었다고 간주하기 위해 충족해야 하는 품질 기준의 집합입니다.

스크럼 가이드(2020)에 따르면, DoD는 인크리먼트의 품질 측정 기준으로서 투명성을 제공하는 공식 아티팩트입니다. 모든 제품 백로그 항목이 DoD를 충족해야만 인크리먼트의 일부가 됩니다.

쉽게 말해, "이 작업은 정말로 끝났는가?" 에 대한 객관적인 기준입니다. "코드를 작성했다"는 것만으로는 "완료"가 아닙니다.

품질 보장

DoD 없이는 "완료"의 의미가 팀원마다 다를 수 있습니다:

• 개발자 A: "코드 작성 완료 = 완료"
• 개발자 B: "테스트까지 완료 = 완료"
• QA: "모든 테스트 통과 = 완료"
• PO: "사용자에게 전달 가능 = 완료"

DoD는 이런 모호함을 제거하고, 모든 팀원이 동일한 완료 기준을 공유하게 합니다.

투명성

이해관계자가 "이 기능은 완료되었습니다"라는 말을 들었을 때, DoD 덕분에 그것이 실제로 무엇을 의미하는지 명확히 알 수 있습니다.

예측 가능성

일관된 DoD는 팀의 벨로시티 측정을 정확하게 만들어, 향후 스프린트 계획의 신뢰도를 높입니다.

기술 부채 방지

DoD에 코드 품질 기준을 포함함으로써 기술 부채의 누적을 체계적으로 방지합니다.

기본 DoD

[ ] 코드가 작성되고 피어 리뷰가 완료되었다 [ ] 단위 테스트가 작성되고 통과한다 [ ] 코드가 코딩 표준을 준수한다 [ ] CI 빌드가 성공한다 [ ] 기능이 인수 기준(AC)을 충족한다 [ ] 릴리스 가능한 상태이다

성숙한 팀의 DoD (네이버/카카오 수준)

코드 품질: [ ] 코드 리뷰 승인 (최소 2명의 리뷰어) [ ] 코딩 표준 및 스타일 가이드 준수 [ ] 정적 코드 분석 통과 (SonarQube) [ ] 코드 커버리지 80% 이상 테스트: [ ] 단위 테스트 작성 및 통과 [ ] 통합 테스트 작성 및 통과 [ ] E2E 테스트 통과 (핵심 시나리오) [ ] 회귀 테스트 통과 [ ] 성능 테스트 기준 충족 (응답 시간 < 200ms) 보안: [ ] 보안 취약점 스캔 통과 [ ] 입력 유효성 검사 구현 [ ] 개인정보 처리 기준 준수 배포: [ ] CI/CD 파이프라인 통과 [ ] 스테이징 환경에서 검증 완료 [ ] 롤백 절차 확인 [ ] 모니터링 및 알림 설정 문서: [ ] API 문서 업데이트 [ ] 변경 사항 릴리스 노트 작성 [ ] 운영 가이드 업데이트 (해당하는 경우) 인수: [ ] Product Owner의 인수 기준 검증 [ ] 접근성 기준 충족 (WCAG 2.1 AA) [ ] 다국어 지원 확인 (해당하는 경우) 

분야별 특화 DoD

프론트엔드:

[ ] 크로스 브라우저 테스트 (Chrome, Safari, Edge) [ ] 반응형 디자인 검증 (모바일, 태블릿, 데스크톱) [ ] Lighthouse 성능 점수 90+ [ ] 접근성 검사 통과

백엔드:

[ ] API 응답 시간 SLA 충족 [ ] 데이터베이스 마이그레이션 스크립트 준비 [ ] 에러 처리 및 로깅 구현 [ ] API 문서(Swagger/OpenAPI) 업데이트

모바일 (삼성 갤럭시/Android & iOS):

[ ] 최소 지원 OS 버전에서 테스트 [ ] 다양한 화면 크기에서 UI 검증 [ ] 메모리 누수 검사 [ ] 배터리 소비 테스트

팀 성숙도에 따른 DoD 진화

DoD는 살아있는 문서로, 팀이 성장함에 따라 함께 발전합니다:

초기 단계 (신규 팀):

[ ] 코드 작성 완료 [ ] 기본 테스트 통과 [ ] 코드 리뷰 1명 [ ] CI 빌드 성공

성장 단계:

[ ] 코드 리뷰 2명 + 자동화 테스트 [ ] 코드 커버리지 70%+ [ ] 정적 분석 통과 [ ] 스테이징 배포 검증

성숙 단계:

[ ] 자동화 테스트 풀 스위트 [ ] 성능/보안 테스트 포함 [ ] 프로덕션 배포 준비 완료 [ ] 모니터링/알림 설정 [ ] A/B 테스트 설정 (해당 시)

DoD 업데이트 시기

• 스프린트 회고: 매 스프린트 회고에서 DoD 점검
• 품질 이슈 발생 시: 프로덕션 장애 후 DoD 강화
• 기술 환경 변화 시: 새로운 도구나 프로세스 도입 시
• 팀 역량 향상 시: 팀이 더 높은 품질 기준을 달성할 수 있을 때

완료 = DoD 충족 + 인수 기준 충족

스프린트 플래닝

스프린트 플래닝에서 DoD는 팀의 용량 계획에 영향을 미칩니다. 엄격한 DoD는 더 많은 시간이 필요하므로, 스프린트에 투입할 항목 수를 현실적으로 계획해야 합니다.

데일리 스크럼

매일 진행 상황을 점검할 때, DoD 기준을 참고하여 항목의 실제 완료 근접도를 판단합니다.

스프린트 리뷰

스프린트 리뷰에서 시연되는 인크리먼트는 DoD를 충족한 것만 포함됩니다. DoD 미충족 항목은 "완료"로 간주하지 않습니다.

스프린트 회고

회고에서 DoD의 적절성을 논의합니다:

• DoD가 너무 낮아서 품질 이슈가 발생했는가?
• DoD가 너무 높아서 팀의 흐름을 방해했는가?
• 추가해야 할 기준이 있는가?

카카오

카카오의 핵심 서비스(카카오톡, 카카오페이)에서는 DoD에 보안 검토와 개인정보 영향 평가가 필수 항목으로 포함됩니다. 한국의 개인정보 보호법(PIPA) 준수가 특히 강조됩니다.

네이버

네이버는 서비스별로 DoD 수준을 차별화합니다. 네이버 페이 같은 금융 서비스는 성능 테스트, 장애 복구 테스트, 감사 로그 등이 DoD에 포함되는 반면, 실험적 서비스는 더 간소한 DoD를 운영합니다.

삼성전자

삼성전자의 소프트웨어 프로젝트에서는 DoD에 글로벌 접근성 기준(WCAG 2.1)과 다국어 테스트가 포함됩니다. 전 세계 시장을 대상으로 하는 제품 특성이 반영된 것입니다.

느슨한 DoD

DoD가 너무 느슨하면:

• 기술 부채가 빠르게 누적
• "완료"된 항목에서 버그가 빈번하게 발견
• 릴리스 전 추가 작업이 필요 ("미완성 완료")

과도한 DoD

DoD가 너무 엄격하면:

• 팀의 속도가 크게 저하
• 팀원의 사기 저하
• 실질적 가치보다 프로세스에 매몰

무시되는 DoD

DoD가 존재하지만 실제로는 준수되지 않는 경우:

• 일정 압박으로 DoD 항목 건너뜀
• 관리자가 "나중에 하면 된다"고 독려
• DoD가 형식적 문서로 전락

DoD를 누가 만드나요?

스크럼 가이드에 따르면 개발자들(Developers) 이 DoD를 만듭니다. 조직에 이미 정의된 DoD가 있다면 그것을 최소 기준으로 삼고, 팀이 추가 기준을 더할 수 있습니다.

DoD와 DoR 중 무엇이 더 중요한가요?

DoD가 더 중요합니다. DoD는 스크럼의 공식 아티팩트이며, 제품 품질에 직접적인 영향을 미칩니다. DoR은 유용하지만 공식 요소는 아닙니다.

모든 팀원이 DoD에 동의하지 않으면?

팀 합의가 핵심입니다. 동의하지 않는 부분에 대해 열린 논의를 하고, 필요하면 실험 기간을 두어 효과를 검증합니다. Scrum Master가 이 과정을 촉진합니다.

DoD 항목을 스프린트 중에 변경할 수 있나요?

원칙적으로 스프린트 중에는 DoD를 변경하지 않습니다. 변경은 회고에서 논의하고, 다음 스프린트부터 적용하는 것이 좋습니다. 단, 심각한 품질 이슈가 발견되면 즉시 강화할 수 있습니다.

• DoR - 준비 완료 정의
• 스크럼 - 스크럼 프레임워크
• 스프린트 - 스프린트
• 백로그 - 백로그
• 기술 부채 - 기술 부채
• QA - 품질 보증