[개념 이해] 백로그(Product Backlog): 스크럼 팀의 일감 저장소

애자일 개발, 특히 스크럼 방식에서
팀이 무엇을 만들고 어떤 순서로 할지 결정하는 핵심 도구가 있습니다.
바로 **백로그(Product Backlog)**입니다.

이 백로그는 단순한 ‘할 일 목록’이 아닙니다.
제품의 방향성과 우선순위, 팀의 전략이 녹아든 로드맵이자 작업 저장소입니다.

---

백로그란 무엇인가?

**백로그(Product Backlog)**는 제품을 만들기 위해 필요한 모든 작업을 모아둔 리스트입니다.
여기엔 기능, 버그 수정, 기술 부채 해결, 리서치 등 모든 유형의 작업이 포함될 수 있어요.

이 리스트는 고정된 것이 아니라 계속 진화합니다.
시장 변화, 피드백, 스프린트 결과 등을 반영해 계속 업데이트되죠.
그래서 ‘살아있는 문서(living document)’라고도 불립니다.

---

Product Backlog 구성요소

백로그는 보통 아래와 같은 항목들로 구성됩니다:

항목설명

PBI (Product Backlog Item)	백로그에 있는 하나하나의 작업 단위
우선순위(Priority)	고객 가치, 비즈니스 중요도 등에 따라 정렬
스토리포인트/작업량	상대적인 난이도 또는 소요 시간
수락 기준(Acceptance Criteria)	완료되었는지 판단하는 기준
정의(Description)	왜 필요한가, 어떻게 구현할 것인가

---

백로그는 누가 관리하나?

**Product Owner(PO)**가 책임지고 관리합니다.
하지만 아이디어는 팀 누구나 제안할 수 있고,
우선순위 조정은 PO와 팀이 함께 조율하는 경우도 많습니다.

---

스프린트 백로그와의 차이

구분설명

Product Backlog	전체 제품에 대한 모든 작업 목록
Sprint Backlog	이번 스프린트 동안 처리할 작업 목록 (Product Backlog의 일부)

즉, 스프린트 백로그는 제품 백로그에서 골라낸 실행 리스트에 해당하죠.

---

좋은 백로그의 조건

1. 명확하다
   애매한 요구사항은 피하고, 누가 봐도 이해할 수 있도록 작성
2. 작게 나뉘어 있다
   너무 큰 작업은 쪼개서 점진적으로 접근 (에픽 → 스토리 → 태스크)
3. 우선순위가 정해져 있다
   가장 중요한 것부터 눈에 띄게
4. 지속적으로 정리된다
   매주 또는 매 스프린트마다 리파인먼트(Backlog Grooming) 필요

---

실무 팁: 백로그 이렇게 다뤄보세요

• ❗ 모든 걸 다 적을 필요는 없다.
  해야 할 일보다, 해야 될지 모르는 일을 관리하는 것도 중요.
• ✅ 작업 히스토리를 남겨라.
  왜 이 백로그 항목이 생겼는지, 어떤 피드백에서 나왔는지를 간단히 기록.
• 💬 팀과 함께 우선순위를 검토하라.
  PO 혼자 정하는 게 아니라, 팀과 함께 논의하는 게 가장 이상적.

---

마무리하며

백로그는 단순한 TODO 리스트가 아닙니다.
팀이 앞으로 나아가기 위한 나침반이자 연료통입니다.
좋은 백로그가 있다면, 팀은 방향을 잃지 않고 꾸준히 달려갈 수 있습니다.

매 스프린트마다 기능만 점검하지 말고,
백로그도 점검하세요.
그게 바로 팀과 제품이 함께 성장하는 길입니다.