모바일 개발에서 태스크 그루밍: 정의, 목적 및 수행 과정

태스크 그루밍이란?

Backlog Grooming(정리)은 다가오는 스프린트를 위해 Product Backlog 태스크를 준비하는 과정입니다. Product Owner와 개발 팀이 태스크를 검토하는 회의입니다: 요구사항을 명확히 하고, Acceptance Criteria를 추가하고, 복잡성을 추정하고, 의존관계와 위험을 식별합니다. Scrum Guide에는 “그루밍”이라는 필수 이벤트가 없습니다 — 이는 Sprint Planning에서 불확실성을 줄이기 위해 Scrum 팀이 채택하는 추가 실무입니다. 권장되는 빈도는 스프린트당 한 번이며, 60분을 초과하지 않아야 합니다.

“그루밍”이라는 용어는 본질을 반영합니다: 팀은 백로그를 “빛다”, 고다된 태스크를 제거하고, 불명확한 것을 명확히 하고, 너뭄 큰 태스크를 분해합니다. 모바일 개발에서는 플랫폼 특성 때문에 그루밍이 특히 중요합니다: Android 태스크가 iOS 버전과 복잡성이 다를 수 있으며, targetSdk, compileSdk 및 API 레벨 호환성을 고려해야 합니다. 그루밍이 없으면, Sprint Planning이 혼란에 빠집니다 — 팀이 처음으로 태스크를 보고 추정할 수 없어 예측 불가능함과 마감 지연이 발생합니다.

그루밍의 결과는 Sprint Planning에 준비된 여러 태스크입니다: 설명, Acceptance Criteria, 추정이 있고 Definition of Ready를 칬충합니다. Product Owner는 우선순위에 따라 태스크를 그루밍해야 합니다: 현재 스프린트에 가장 근접한 것이 가장 상세하게 됩니다. 3—4 스프린트 달리 있는 태스크는 에픽 레벨로만 남겨둑니다. 점진적 정리 기법(Progressive Refinement): 태스크가 스프린트에 가까울수록 설명이 더 상세해집니다. 현재 스프린트 태스크 — 완전 정리 (AC, 디자인, API 명세서). 2 스프린트 달리 있는 태스크 — 스토리 레벨 (구현 세부사항 없는 사용자 스토리). 3+ 스프린트 달리 있는 태스크 — 에픽 레벨 (이름과 비즈니스 가치만).

Definition of Ready: 태스크가 스프린트에 준비되었을 때

Definition of Ready (DoR)는 Sprint Backlog에 포함되기 전에 태스크가 칬충해야 할 기준의 체크리스트입니다. DoR은 Product Owner와 팀 간의 계약입니다: PO는 개발에 필요한 모든 정보가 있음을 보장하고, 팀은 태스크를 추정하고 완료할 수 있음을 보장합니다. DoR은 보편적이지 않습니다 — 각 팀이 자체 기준을 정의합니다. DoR이 없으면, 불명확한 요구사항으로 태스크가 스프린트에 들어가 재작업과 마감 지연이 발생할 수 있습니다.

모바일 개발에 대한 일반적인 DoR: 1) Acceptance Criteria가 설명되어 있음 (Given-When-Then 형식). 2) UI 태스크의 경우 Figma에 디자인 목업이 준비되어 있음 (모든 상태: default, loading, error, empty state). 3) API 명세서가 승인되어 있음 (OpenAPI/Swagger, 요청 및 응답 예시). 4) 스토리 포인트 추정이 있음. 5) 다른 태스크에 대한 의존관계가 식별되어 있음. 6) 태스크가 미완료 외부 컴포넌트에 의존하지 않음. 7) 모바일 특성: 대상 OS 버전 정의, feature flag 필요성, 고구 API 레벨 지원.

태스크 추정 기법

Planning Poker는 그루밍에서 가장 인기 있는 추정 기법입니다. 각 개발자는 피보나치 숬(1, 2, 3, 5, 8, 13, 21)가 적힌 카드 덱을 받습니다. PO가 태스크를 제시하고 설명합니다. 논의 후 모두 동시에 카드를 보여줍니다. 추정이 큰 차이가 나면(예: 3과 13), 개발자들이 이유를 설명하고 다시 투표합니다. 반복은 합의가 날 때까지 계속됩니다. Planning Poker의 목적은 정확한 추정이 아니라 태스크 이해의 차이를 발견하는 것입니다.

T-Shirt Sizing은 빠른 추정을 위한 간단한 기법입니다: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). 한꼬려의 크기를 필요로 하는 많은 태스크가 있을 때 초기 백로그 분류에 적합합니다. T-Shirt Sizing 후에는 다음 스프린트 태스크에 대해 Planning Poker로 더 정확한 추정이 이루어집니다. Affinity Estimation은 숫자를 사용하지 않고 태스크를 테이블에 가장 간단한 것부터 가장 복잡한 것까지 정렠한 후 클러스터로 그룹화하고, 각 클러스터가 추정을 받는 그룹 정렬 기법입니다.

모바일 개발에서는 추정이 플랫폼 복잡성을 고려해야 합니다. Android 태스크가 5 SP로 추정되는 반면, 동일한 태스크가 iOS에서는 3 SP가 될 수 있습니다(그 반대일 수도 있음). 이것은 정상적입니다: 다른 플랫폼은 구현 복잡성이 다릅니다. 팁: 팀이 크로스 플랫폼이라면 각 플랫폼별로 별도로 추정하세요. 상대적 스케일을 사용하세요: 기존 태스크(예: 텍스트와 버튼이 있는 화면) = 1 SP. 나머지 모든 것은 그것에 상대적입니다. Scrum.org(2025)에 따르면, 3—4 스프린트 후 팀의 추정 정확도는 실제 복잡성의 ±20%에 도달합니다.

분해: 큰 태스크를 나누는 방법

8 SP보다 큰 태스크는 더 작은 태스크로 분해되어야 합니다. 큰 태스크는 한 스프린트에서 완료할 수 없고, 추정하기 어령고, 진행이라는 느낌을 주지 않습니다. 분해 기법: 수평 레이어(UI → ViewModel → Repository → Network/DB) 또는 수직 슬라이스(기능: 한 화면 전체)로 태스크를 나늹니다. 수평 분해는 모바일 개발에 더 적합합니다: 하위 태스크 1 — UI 레이아웃 (XML/Jetpack Compose/SwiftUI), 하위 태스크 2 — ViewModel + State, 하위 태스크 3 — Repository + Network, 하위 태스크 4 — 단위 테스트.

수직 분해는 사용자 스토리를 독립적인 가치가 있는 작은 스토리로 나누는 것입니다. 예: 에픽 “쇼핑 카트” → 스토리 1 “카트에 상품 추가”, 스토리 2 “카트 표시”, 스토리 3 “카트에서 상품 제거”, 스토리 4 “결제”. 각 스토리는 고유한 비즈니스 가치가 있고 독립적으로 출시될 수 있습니다. SPoK (Kano에 의한 스토리 포인트): 비즈니스 가치(Must-have, Should-have, Could-have)에 따라 스토리를 순위매길 하고 가치 순으로 구현합니다.

그루밍에서 분해 체크리스트: 1) 태스크가 8 SP보다 큽니까? → 분해하세요. 2) Acceptance Criteria가 정의되어 있나요? → 없으면 추가하세요. 3) 다른 태스크에 의존하나요? → 의존관계를 식별하고 문서화하세요. 4) 불확실성이 있나요? → 주 태스크 전에 Spike(조사)를 추가하세요. 5) 디자인이 필요한가요? → 목업 준비 상태를 확인하세요. INVEST 규칙: Independent(다른 것엀서 독립), Negotiable(협상 가능), Valuable(비즈니스에 가치 있음), Estimable(추정 가능), Small(작음), Testable(테스트 가능). 태스크가 INVEST를 칬충하지 않으면 스프린트에 준비되지 않았다는 뜻입니다.

그루밍 과정: 단계별

1단계: 워밍업 (5분). Scrum Master가 팀에게 그루밍의 목적과 DoR을 상기시킵니다. 팀은 보드를 보고, PO가 논의될 태스크를 보여줍니다. 2단계: 태스크 검토 (30분). PO가 현재 스프린트의 끝과 다음 스프린트의 시작에서 태스크를 순차대로 제시합니다. 각 태스크에 대해: 이름, 설명, Acceptance Criteria(있다면), 디자인 링크, API 명세서. 팀이 확인 질문을 합니다: “빈 상태에 대한 목업이 있나요?”, “어떤 HTTP 메소드인가요?”, “iOS 최소 배포 대상이 뭐인가요?”

3단계: 추정 (15분). 팀이 Planning Poker 또는 T-Shirt Sizing으로 태스크를 추정합니다. 차이가 2 SP를 초과하면 이유를 논의하고 다시 투표합니다. 규칙: 태스크를 추정할 수 없는 경우(요구사항이 불명확하거나 디자인이 없음) — PO에게 돌려주고 다음 그루밍에 확인사항과 함께 보냅니다. 불확실한 요소가 있는 태스크는 추정하지 마세요 — 스프린트에서 오류가 발생할 것입니다. 4단계: 결과 기록 (10분). PO가 Jira/Linear에 추정을 기록하고, 태스크 설명을 업데이트하고 우선순위를 설정합니다.

그루밍 결과: Sprint Planning에 완전히 준비된 3—7 개의 태스크 (DoR, 추정, 디자인, API 포함). PO가 백로그를 업데이트합니다: 고다된 태스크를 제거하고, 중복을 병합하고, 우선순위를 조정합니다. 중요: 그루밍이 PO의 작업을 끝내지 않습니다 — 그루밍 세션 사이에 PO는 다음 태스크를 준비해야 합니다. 권장되는 속도: PO가 그루밍에 사용할 3—4 개의 태스크를 준비하고, 팀이 그것들을 처리합니다. 백로그에 50개 이상의 태스크가 있는 경우, PO는 그루밍 전에 우선순위 설정(MoSCoW 또는 Weighted Shortest Job First)을 수행해야 합니다.

그루밍과 Sprint Planning의 차이점

그루밍은 준비입니다. 약속이 없습니다 — 태스크는 단지 명확하고 추정될 뿐입니다. Sprint Planning은 약속입니다. 팀은 그루밍에서 준비된 태스크 중에서 선택하고 스프린트내에 완료할 것을 약속합니다. 주요 차이점: 그루밍은 특정 스프린트에 엾협지 않습니다(전체 백로그 정리), 그루밍 중에는 Sprint Goal이 없고, 그루밍은 스프린트 중 언제든지 진행할 수 있습니다. Sprint Planning은 스프린트 시작시에 진행되며 항상 Sprint Goal을 도출합니다.

그루밍에서 태스크는 추정만되고 스프린트에 포함되지 않습니다. Planning에서는 준비된 풀에서 태스크가 선택됩니다. 그루밍이 없으면 Sprint Planning에 6–8시간이 걸립니다 (4시간 대신), 팀이 처음 태스크를 보고 빠르게 추정할 수 없기 때문입니다. 80/20 규칙: Sprint Planning에서 80% 태스크가 완전히 준비되어야 하고(그루밍을 거쳐야 함), 20% 신규 태스크(긴급 버그, 혿픽스)일 수 있습니다. Planning에서 20% 이상의 태스크가 미추정된 경우 그루밍이 불충분했다는 뜻입니다.

그루밍의 일반적인 실수

실수 1: 한 달에 한 번 그루밍. 팀이 3—4 스프린트분의 태스크를 쌓아 2시간 만에 모두 정리하려고 합니다. 결과: 절반의 태스크가 미추정으로 남고, Planning이 하룻동안 걸립니다. 해결책: 그루밍은 정기적이어야 합니다 — 스프린트당 한 번, 60분. 태스크가 많으면 스프린트 중간에 두 번째 그루밍을 추가하세요. 많은 태스크를 표면적으로 하는 것보다 적은 수의 태스크를 참저히 그루밍하는 것이 더 좋습니다. 속도: 그루밍 세션당 3—5 개의 태스크가 완전한 논의와 추정을 받습니다.

실수 2: 문맥 없이 추정. PO가 디자인, API, AC 없이 “쇼핑 카트 화면 구현” 태스크를 제시합니다. 팀이 “눈치로” 13 SP라고 추정합니다. Planning에서 실제로는 5 SP인 것으로 드러나옵니다(화면이 간단하기 때문). 해결책: 디자인이나 API가 없으면 태스크를 추정하지 않습니다. PO는 그루밍 전에 자료를 준비해야 합니다. 규칙: “목업 없음 = 추정 없음”. 예외: Spike 태스크 — 불확실성 조사, 디자인 없이 별도로 추정됨 (조사 복잡성에 따라 2–5 SP).

실수 3: 그루밍이 Planning으로 변함. 팀이 개인에게 태스크를 분배하고 누가 뭐를 할지 논의하기 시작합니다. 해결책: 그루밍은 명확화를 위한 것이지 분배를 위한 것이 아님을 상기시키세요. 분배는 스프린트 시작 후 Daily에서 됩니다. 그루밍은 “뭐를 할까?”, Planning은 “언제 할까?”, Daily는 “누가 하고 있나?”를 답합니다. 한 회의에서 이 질문들을 혼합하면 각각의 효과성이 떨어집니다. Scrum Master는 Planning 같은 논의를 중지하고 태스크 명확화에 초점을 다uc2dc 맞추어야 합니다.

실수 4: Tech Debt 무시. 그루밍에서는 새로운 기능만 논의되고, 기술 태스크는 무시됩니다. 3—4 스프린트 후, 기술 부케가 위험 수뤀으로 쌓이멸 것입니다. 해결책: 각 그루밍에서 적어도 1개의 기술 태스크가 추정되어야 합니다. 비율: 기능 3개 당 기술 태스크 1개. Tech Debt Ratio 메트릭을 사용하세요: 스프린트의 기능 태스크에 대한 기술 태스크 비율. 목표값: 0.25–0.3 (기술 부케에 25–30% 시간). 비율이 0.2 미만이면 다음 스프린트에서 개발 속도가 감소합니다.