PMI PMP: Agile, Scrum 및 하이브리드 딜리버리 — 학습 가이드

By Laurynas Brazys · 22 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

다음의 일부입니다: PMP — 학습 가이드. 검증된 답안으로 연습하기: PMI 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

스크럼 역할, 세레모니, 그리고 산출물

스크럼은 의도적으로 작은 역할 구조로 운영됩니다. 복잡한 결과물 전달 과정에서 책임이 분산되는 것이 주요 실패 요인 중 하나이기 때문입니다. **프로덕트 오너(Product Owner)**는 무엇을 그리고 왜에 대한 책임을 집니다. 가치를 정의하고, 백로그의 우선순위를 정하며, 증분(increment)을 수락하거나 거부할 권한을 가집니다. **스크럼 마스터(Scrum Master)**는 프로세스가 얼마나 잘 실행되는지에 대한 책임을 집니다. 장애물을 제거하고, 애자일 프랙티스에 대해 코칭하며, 팀을 방해 요소로부터 보호하는 서번트 리더(servant-leader)입니다. 개발자(Developers)(코더뿐만 아니라 전체 개발팀)는 어떻게에 대한 책임을 집니다. 이들은 스프린트마다 백로그 아이템을 작동하는 증분으로 전환하기 위해 스스로 조직합니다.

이러한 역할은 실제 참여하는 인원으로 채워져야 합니다. 참여하지 않거나 부재중인 프로덕트 오너는 애자일 결과물 전달 과정에서 가장 파괴적인 패턴 중 하나입니다. 실시간 우선순위 지정과 수락이 없으면, 스프린트 리뷰는 가치 검증 이벤트가 아닌 상태 보고 회의가 되고, 피드백 루프는 길어지며, 팀은 잘못된 것을 만드는 방향으로 흘러가게 됩니다. PO가 부재중인 상황에 직면했을 때, 올바른 조치는 스폰서에게 문제를 보고하여 역할을 재정립하는 것이지, 스크럼 마스터가 영구적으로 의사결정을 대리하게 하는 것이 아닙니다.

핵심 세레모니는 닫힌 피드백 루프를 형성합니다:

• 스프린트 계획(Sprint Planning)
  • 목적: 스프린트 목표와 예측 협상
  • 주기: 스프린트 시작 시
  • 주요 산출물: 스프린트 백로그
• 데일리 스탠드업(Daily Standup)
  • 목적: 동기화, 장애물 공유
  • 주기: 매일, 15분으로 시간 제한(timeboxed)
  • 주요 산출물: 당일의 수정된 계획
• 스프린트 리뷰(Sprint Review)
  • 목적: 이해관계자와 함께 증분 검토
  • 주기: 스프린트 종료 시
  • 주요 산출물: 피드백, 업데이트된 프로덕트 백로그
• 스프린트 회고(Sprint Retrospective)
  • 목적: 프로세스 검토
  • 주기: 스프린트 종료 시
  • 주요 산출물: 구체적인 개선 실행 항목

산출물인 프로덕트 백로그(Product Backlog), 스프린트 백로그(Sprint Backlog), **증분(Increment)**은 각각 프로덕트 목표(Product Goal), 스프린트 목표(Sprint Goal), 완료의 정의(Definition of Done)라는 약속(commitment)을 가집니다. 이러한 약속은 스크럼이 ‘반복적 폭포수 모델(iterative waterfall)‘로 변질되는 것을 방지합니다.

백로그 관리와 사용자 스토리

프로덕트 백로그는 살아있는, 순서가 있는 목록이며, 프로젝트 시작 시 고정된 명세서가 아닙니다. 프로덕트 오너는 팀과 협력하여 이를 유지 관리하며, 백로그 상단의 항목들이 작고, 잘 이해되며, 바로 가져갈 수 있도록(ready to pull) 다듬습니다. 일반적으로 매 스프린트마다 팀 역량의 5~10%를 **백로그 개선(backlog refinement)**에 사용합니다.

사용자 스토리는 익숙한 패턴을 따릅니다: [페르소나]로서, [혜택]을 위해 [기능]을 원한다. 혜택에 대한 부분은 기능만큼이나 중요합니다. 이를 통해 팀은 대안적인 해결책을 제안할 수 있고, PO는 우선순위가 변경되었을 때 해당 스토리가 여전히 할 가치가 있는지 결정할 수 있습니다.

**인수 조건(Acceptance criteria)**은 PO가 스토리를 수락하는 관찰 가능하고 테스트 가능한 조건입니다. 이는 완료의 정의(Definition of Done)와 다릅니다. 인수 조건은 스토리별로 특정되는 반면(예: 로그인 화면이 5회 실패 후 잠기는가?), DoD는 모든 스토리에 보편적으로 적용됩니다(예: 코드 리뷰, 테스트, 문서화, 스테이징 배포가 완료되었는가?).

이해관계자가 프로젝트 중간에 새로운 요구사항을 가져왔을 때(이전 작업과 유사하더라도), PO는 단순히 날짜를 불쑥 말해서는 안 됩니다. 올바른 대응은 해당 요청을 백로그 후보 아이템으로 기록하고, 팀과 협력하여 크기를 산정한 후(상대적 추정을 위해 참조 스토리를 기준으로 사용할 수 있음), 기존 아이템 대비 가치에 따라 백로그에 배치하는 것입니다. 이전 작업과의 유사성은 크기 산정을 가속화할 수는 있지만, 우선순위 결정 과정을 건너뛰게 하지는 않습니다.

DoR, DoD, 그리고 이터레이션 계획

**준비의 정의(Definition of Ready)**는 스프린트 진입에 대한 관문입니다. 스토리가 스프린트 내에서 완료할 수 있을 만큼 작고, 명확한 인수 조건을 가지며, 알려진 의존성이 식별되고, 팀이 이해했을 때 준비된 상태(ready)가 됩니다. DoR을 강제하면 팀이 미완성된 작업을 가져와 스프린트 중간에 해결되지 않은 질문으로 인해 중단되는 것을 방지할 수 있습니다.

**완료의 정의(Definition of Done)**는 완료에 대한 관문입니다. 이는 ‘코딩을 마쳤다’를 ‘잠재적으로 출시 가능한 증분이다’로 바꾸는, 협상 불가능한 공유 체크리스트입니다. 견고한 DoD는 일반적으로 자동화된 테스트 통과, 코드 리뷰, 보안 스캔 통과, 문서 업데이트, 그리고 결정적으로 성능 및 관측 가능성과 같은 비기능적 요구사항 해결을 포함합니다. 운영 및 QA 팀을 DoD 정의에 참여시키는 것은, 증분이 스프린트 리뷰에서는 ‘작동’하지만 프로덕션의 실제 부하에서는 붕괴되는 패턴을 방지합니다. 만약 스프린트 후에 운영팀이 성능 문제를 제기하고 관련 데이터가 이미 로그에 존재한다면, 성숙한 대응은 그 우려 사항을 개선(refinement) 과정으로 가져와 DoD에 성능 임계값을 추가하고, 그 차이를 해결하기 위한 백로그 아이템을 생성하는 것이지, ‘범위 밖’이라고 일축하는 것이 아닙니다.

MVP, 릴리스 계획, 그리고 점진적 배포

**최소 기능 제품(Minimum Viable Product)**은 팀이 실제 사용자를 대상으로 핵심 가설을 테스트할 수 있게 해주는 가장 작은 단위의 일관된 결과물입니다. 그 목적은 단순히 결과물 전달이 아니라 학습입니다. 그 위에 릴리스 계획이 더해집니다. MVP 이후 점진적 릴리스로 이어지는 로드맵이 주어지면, 팀은 속도(velocity)를 대략적인 가이드로 사용하여 어떤 기능이 어떤 릴리스에 포함될지 예측합니다.

점진적 배포는 조직에 선택권, 즉 의견이 아닌 증거에 기반하여 방향을 바꿀 수 있는 능력을 제공합니다. 사용자에게 무언가를 보여주기 전에 ‘완벽한’ 릴리스를 기다리는 것은 애자일이 특별히 방지하고자 설계된 안티패턴입니다.

← 팀 리더십 및 리소스 관리 · 모든 도메인 · 범위 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →