Rocks, Pebbles, Sand 우선순위 프레임워크 (Rocks, Pebbles, Sand Prioritization Framework)
1. Overview (개요)
Rocks, Pebbles, Sand 프레임워크는 Stephen Covey의 지질학 항아리 비유를 발전시킨 업무 우선순위 설정 방법론이다. Jason Cohen이 실무 적용을 위해 체계화한 이 프레임워크는 업무를 크기와 임팩트(impact)에 따라 세 가지 카테고리로 분류하고, 각 카테고리별로 다른 의사결정 방식과 최적화 목표를 적용한다.
핵심 원칙:
- 큰 일을 먼저 스케줄링하지 않으면 시간이 부족함
- 단순한 크기 분류가 아닌 임팩트 극대화가 목적
- 각 카테고리는 서로 다른 우선순위 프레임워크와 목표를 가짐
카테고리별 요약:
| Rocks | Pebbles | Sand | |
|---|---|---|---|
| 노력(Effort) | ≥3개월 | 1-4 스프린트 | ≤1 스프린트 |
| 최대화(Maximize) | 임팩트(Impact) | ROI | 처리량(Throughput) |
| 관점(Outlook) | 장기적 | 단기적 | 즉각적 |
| 범위(Scope) | 전략적 | 전술적 | 모든 범위 |
| 의사결정 방식 | 숙고형 | 분석형 | 직관형 |
| 경영진 역할 | 의사결정자 | 관찰자 | 없음 |
| PM 역할 | 추진자 | 의사결정자 | 의사결정자(개발팀 참여) |
2. When to Use (사용 시기)
적용 상황
- 애자일 팀이 전략적 방향을 잃고 있을 때
- "열심히 일하지만 진전이 없다"는 느낌이 들 때
- 긴급하지만 중요하지 않은 일들이 전략적 업무를 밀어낼 때
- 팀의 업무가 회사 전략과 연결되지 않는다고 느낄 때
- 스프린트 계획이 체계적이지 않을 때
적용 조건
- 최소 3개월 이상의 계획 수립이 가능한 조직
- 전략적 목표가 명확히 정의되어 있을 때
- PM과 경영진의 역할이 구분되어 있을 때
- 팀이 자율적으로 Sand를 관리할 수 있는 성숙도를 가질 때
3. Process (프로세스)
단계 1: Rocks 정의 (3-12개월)
최대화 목표: 임팩트(Impact)
특징:
- 연간 1-3개만 완수 가능
- 극적이고 측정 가능한 임팩트 필수
- 전략적이어야 함 - 가장 중요한 도전과제 공략
- ROI가 아닌 임팩트 최대화 (논란의 여지가 있지만 중요함)
의사결정:
- Binstack 프레임워크 사용하여 최대 임팩트 아이디어 선택
- 경영진이 최종 결정, PM이 주도
- 숙고형 의사결정 - "애자일"하지 않은 전략적 결정
주의사항:
- 호프스태터의 법칙(Hofstadter's Law): 예상보다 항상 더 오래 걸림
- "좋음"이 "위대함"의 적 - 충분히 임팩트 있는 아이디어가 없다면 찾는 것이 우선
단계 2: Pebbles 정의 (1-4 스프린트)
최대화 목표: ROI (투자 대비 수익)
특징:
- 측정 가능한 임팩트 필수
- 4 스프린트 초과 시 Rock으로 재분류
- 전술적 승리 - 현재 직면한 도전과제 공략
의사결정:
- PM이 결정권 보유
- [정보 필요: 특정 ROI 분석 프레임워크 필요]
- 고객 니즈, 경쟁사, 전략, 지표 종합 판단
주의사항:
- ROI 계산의 호프스태터 문제 - 실제는 예상의 절반이 될 수 있음
- 범위 축소 시 임팩트도 감소하는 딜레마
단계 3: Sand 정의 (≤1 스프린트)
최대화 목표: 처리량(Throughput)
특징:
- 개별적으로는 측정 불가능하지만 대량 실행 시 중요
- UI 개선, 버그 수정, 리팩토링, 보안 패치 등
- "천 번의 베임으로 인한 죽음"의 반대 개념
의사결정:
- 직관과 욕구 기반 - 측정이나 지표가 아닌
- 팀이 자율적으로 스케줄링
- 최소한의 관리 오버헤드
주의사항:
- 관리 프로세스가 실제 작업보다 오래 걸리는 것 방지
- 불필요한 템플릿 작성이나 형식 강요 금지
단계 4: 스프린트 계획 실행
우선순위 순서:
- 시간 critical한 항목 (크기 무관)
- 현재 Rock의 스토리 1개 이상
- 현재 Pebble의 스토리 1개 이상
- Sand
4. Outputs (산출물)
주요 산출물
- Rock 로드맵: 연간 1-3개의 전략적 이니셔티브
- Pebble 백로그: 1-4 스프린트 단위 전술적 개선사항
- Sand 목록: 지속적 개선을 위한 작은 작업들
- 스프린트 계획: 균형잡힌 작업 배분
측정 지표
- Rocks: 전략적 목표 달성도
- Pebbles: ROI 실현율
- Sand: 스프린트당 완료 항목 수 (처리량)
5. Limitations (한계)
공통 문제와 해결책
"시간 critical" 항목이 너무 많을 때
- 메타 문제: 팀이 효과적이지 못함
- 이를 해결하는 것이 Rock보다 우선
- 근본 원인 진단 필요 (생산성, 소유 범위, 아키텍처 의존성 등)
Rock 기아 현상 (Starving the Rock)
- 스프린트당 스토리 1개는 너무 적음
- 아이젠하워 매트릭스(Eisenhower Matrix) 함정 - 긴급한 일 vs 중요한 일
- Pebble을 일시 중단 고려
여러 개의 Pebble 동시 진행
- 컨텍스트 스위칭으로 생산성과 사기 저하
- 예외: Pebble이 거의 완료되었거나 1주 이상 블로킹될 때
Sand 제로 현상
- 제품 품질 저하와 엔지니어 불만족
- Sand 전용 스프린트 고려
- Rock이나 Pebble 일시 중단 고려
균형 강박증
- 매 스프린트 완벽한 균형은 불필요
- 수개월 단위로 균형 유지가 중요
- 의도적 불균형이 때로는 더 효과적 (집중도 향상)
6. Case Study (사례)
사례 1: 위대한 디자인 달성
상황: 디자인이 주요 차별화 요소인 제품 적용:
- Rock: 전체적인 디자인 시스템 구축
- Pebbles: 주요 화면별 개선
- Sand: 픽셀 단위 조정, 색상 미세 조정, 폰트 최적화 결과: 수천 개의 Sand가 모여 "정말 잘 만들어진" 소프트웨어 완성
사례 2: 보안 패치 vs 전략 프로젝트
상황: 긴급 보안 패치와 중요한 Rock의 충돌 적용:
- 시간 critical 항목으로 보안 패치 우선 처리
- Rock 스토리는 최소 1개 유지
- Sand는 다음 스프린트로 연기 결과: 보안 유지하면서 전략적 진전도 확보
사례 3: npm 패키지 업그레이드
상황: minimist 1.2.2에서 1.2.3으로 업그레이드 잘못된 접근:
- 형식적인 유저 스토리 작성
- 불필요한 템플릿 필드 채우기
- 회의에서 우선순위 논의 올바른 접근:
- 한 줄 설명: "minimist를 1.2.3 이상으로 업그레이드 (보안 패치)"
- 엔지니어가 자율적으로 처리 결과: 관리 오버헤드 없이 몇 분 만에 완료
참고:
- Rocks 선택 시 Binstack 프레임워크 활용 권장
- Pebbles의 ROI 분석 시 [검증 필요: 특정 프레임워크 참조]
- 호프스태터의 법칙은 시간과 임팩트 모두에 적용됨