DoD - Definition of Done vs DoR - Definition of Ready

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 - 품질 보증

Definition of Ready(DoR, 준비 완료 정의) 는 백로그 항목이 스프린트에 선택되기 전에 충족해야 하는 조건의 집합입니다. 팀과 Product Owner가 합의한 기준으로, 항목이 개발을 시작하기에 충분히 준비되었는지를 판단합니다.

쉽게 말해, "이 항목을 개발하기 시작해도 되는가?" 에 대한 체크리스트입니다.

DoR은 Definition of Done(DoD)의 "입구 조건" 역할을 합니다. DoR이 스프린트의 시작 품질을 보장한다면, DoD는 완료 품질을 보장합니다.

스프린트 플래닝 효율화

DoR을 충족하지 않는 항목이 스프린트 플래닝에 올라오면:

• 플래닝 시간이 길어짐
• 요구사항 논의로 시간 소비
• 모호한 항목으로 인한 개발 중 블로커 발생

DoR을 활용하면 플래닝에서는 "무엇을 할 것인가"와 "어떻게 할 것인가"에 집중할 수 있습니다.

품질 향상

• 불명확한 요구사항으로 인한 재작업 방지
• 개발 중 이해관계자 확인 대기 시간 감소
• 사이클 타임 단축

팀 효율성 향상

• 개발자가 작업을 시작하자마자 바로 코딩에 집중 가능
• 스프린트 중 범위 변경 감소
• 예측 가능성 향상

기본 체크리스트

[ ] 사용자 스토리가 명확하게 작성되어 있다 (역할, 행동, 가치가 정의됨) [ ] 인수 기준(Acceptance Criteria)이 정의되어 있다 [ ] 팀이 요구사항을 이해하고 동의한다 [ ] 스토리 포인트로 추정이 완료되었다 [ ] 외부 의존성이 식별되고 해결되었다 [ ] UI/UX 디자인이 준비되어 있다 (해당하는 경우) [ ] 기술적 제약사항이 파악되었다

네이버/카카오 수준의 상세 체크리스트

[ ] 사용자 스토리가 INVEST 원칙을 충족한다 [ ] 인수 기준이 Given-When-Then 형식으로 작성되었다 [ ] Figma 디자인이 개발자에게 공유되었다 [ ] API 명세서가 작성되었다 [ ] 데이터 모델 변경이 식별되었다 [ ] 보안 요구사항이 검토되었다 [ ] 성능 기준이 정의되었다 (응답 시간 등) [ ] 접근성 요구사항이 확인되었다 [ ] QA 테스트 시나리오가 준비되었다 [ ] 모니터링/로깅 요구사항이 정의되었다 [ ] 기술 부채 영향이 평가되었다 [ ] 스토리 크기가 스프린트 내 완료 가능하다 

분야별 추가 기준

프론트엔드 팀:

• Figma 디자인 확정
• 반응형 디자인 가이드 제공
• 컴포넌트 라이브러리 호환성 확인

백엔드 팀:

• API 스펙 정의 완료
• 데이터베이스 스키마 변경 계획 수립
• 외부 API 연동 문서 준비

모바일 팀:

• 지원 OS/디바이스 범위 확인
• 오프라인 동작 요구사항 정의
• 앱 스토어 정책 준수 확인

리파인먼트 세션에서의 DoR 활용

백로그 리파인먼트에서 DoR은 항목의 준비 상태를 점검하는 도구입니다:

1. 백로그 항목 검토: Product Owner가 다음 스프린트 후보 항목 제시
2. DoR 점검: 팀이 각 항목을 DoR 체크리스트로 평가
3. 갭 식별: 충족하지 못한 조건 파악
4. 액션 설정: 부족한 부분을 채우기 위한 구체적 행동 정의
5. 추정: DoR을 충족한 항목에 대해 플래닝 포커로 추정

리파인먼트 타임라인

스프린트 N 스프린트 N+1 ├─── 리파인먼트 ──┤ ├─── 플래닝 ──── 개발 ────┤ │ │ │ │ │ DoR 점검 및 │ │ DoR 충족 항목만 │ │ 준비 작업 │ │ 스프린트에 투입 │

리파인먼트에서 DoR을 점검하고, 다음 스프린트 플래닝까지 부족한 부분을 보완합니다.

공식 스크럼의 입장

DoR은 스크럼 가이드에 포함되지 않습니다. 스크럼 가이드에는 DoD(Definition of Done)만 명시되어 있습니다.

찬성 의견

• 스프린트 중 재작업과 블로커를 크게 줄임
• 팀과 Product Owner 간의 기대치 정렬
• 예측 가능성 향상
• 신규 팀에게 좋은 가이드라인 제공

반대 의견 (안티패턴 관점)

일부 애자일 전문가들은 DoR을 안티패턴으로 봅니다:

• 경험주의 방해: 불확실성을 받아들이는 스크럼의 원칙에 반함
• 관문(Gate) 형성: 팀의 자율성과 유연성을 제한
• 과도한 사전 분석: 워터폴 방식의 "빅 업프론트 디자인"으로 회귀
• Product Owner 부담: 모든 항목을 완벽히 준비해야 한다는 압박

균형 잡힌 접근

DoR을 가이드라인으로 사용하되, 절대적 규칙으로 만들지 마세요:

• DoR의 80% 이상 충족하면 스프린트에 투입 가능
• 미충족 항목은 스프린트 중 해결 가능한지 팀이 판단
• 팀의 성숙도에 따라 DoR을 유연하게 조정
• 정기적으로 DoR 항목을 회고에서 검토

삼성 SDS

대규모 엔터프라이즈 프로젝트에서 DoR을 활용하여 요구사항 품질을 관리합니다. 특히 고객사와의 요구사항 합의 과정에서 DoR 체크리스트가 의사소통 도구로 활용됩니다.

카카오

카카오의 일부 팀에서는 "3-Amigos 세션"(Three Amigos)을 DoR 충족의 핵심 활동으로 운영합니다. PO, 개발자, QA가 함께 모여 사용자 스토리를 검토하고, BDD 시나리오를 작성하면 DoR을 충족한 것으로 간주합니다.

네이버

네이버의 개발 팀은 "Ready 보드"를 별도로 운영하여, 백로그에서 DoR을 충족한 항목만 Ready 보드로 이동시키는 시각적 관리 방법을 사용합니다.

DoR이 없으면 어떤 문제가 생기나요?

요구사항이 모호한 항목이 스프린트에 들어가면: 개발 중 잦은 확인 필요, 방향 변경, 재작업 증가, 스프린트 목표 미달성 등의 문제가 발생합니다.

DoR 체크리스트는 누가 만드나요?

팀 전체가 합의하여 만듭니다. Product Owner, 개발자, 테스터가 각자의 관점에서 필요한 조건을 제시하고, 팀이 최종 합의합니다.

DoR이 충족되지 않은 항목을 꼭 거부해야 하나요?

반드시 그런 것은 아닙니다. 중요한 것은 위험을 인식하고 관리하는 것입니다. DoR 미충족 항목을 스프린트에 넣되, 미충족 조건으로 인한 리스크를 팀이 이해하고 수용한다면 진행할 수 있습니다.

어느 정도의 DoR이 적절한가요?

5-10개 항목이 적절합니다. 너무 적으면 의미가 없고, 너무 많으면 관문이 되어 속도를 떨어뜨립니다. 팀의 경험과 프로젝트 특성에 맞게 조정하세요.

• DoD - 완료 정의
• 백로그 - 작업 목록
• 스프린트 플래닝 - 스프린트 계획
• Product Owner - 제품 소유자
• BDD - 행동 주도 개발
• 사이클 타임 - 사이클 타임