MoSCoW는 언제 쓰나요?
해야 할 일이 시간과 사람보다 많을 때, 전부를 "중요"로 두는 대신 이번 범위에 넣을 것과 뺄 것을 합의하는 방법입니다. 소프트웨어 개발에서 출발했지만 이사, 행사, 결혼 준비, 이벤트 기획처럼 마감이 있는 일에도 그대로 쓸 수 있습니다. 이름은 Must·Should·Could·Won't의 앞글자를 이어 발음하기 좋게 만든 것이고, 중간의 소문자 o는 읽기 쉽게 끼워 넣은 글자입니다. 1990년대 중반 오라클의 데이 클레그(Dai Clegg)가 고안해 DSDM 방법론에서 채택되며 퍼진 것으로 알려져 있습니다.
네 칸을 가르는 질문
칸 이름만으로는 "Should와 Could가 어떻게 다른가"가 흐려지기 쉽습니다. 항목마다 아래 질문을 던져 보면 합의가 빨라집니다. 핵심은 "중요한가"가 아니라 "이번 마감 안에서 빠졌을 때 무슨 일이 생기는가"입니다.
| 분류 | 의미 | 확인 질문 |
|---|---|---|
| Must | 없으면 이번 이사가 성립하지 않거나 법적·금전적 문제가 생김 | 이걸 빼면 이삿날을 미뤄야 하는가? |
| Should | 중요하지만 우회 방법이 있고 당장 없어도 이사는 가능 | 빼면 불편하지만 임시 방편이 있는가? |
| Could | 시간과 자원이 남을 때만 하는 것 | 이번 범위에서 빠져도 아무도 곤란하지 않은가? |
| Won't | 이번에는 하지 않기로 합의한 것 (영구 제외가 아님) | 다음 기회로 미룬다고 팀이 동의했는가? |
예시: 2주 뒤 이사 준비 12개 항목 나누기
이사까지 2주가 남았고 준비에 쓸 수 있는 시간이 대략 32시간이라고 가정한 가상의 사례입니다. 할 일마다 예상 소요 시간을 적어 분류했습니다(Won't는 계획 시간에서 제외).
| 할 일 | 분류 | 시간 |
|---|---|---|
| 이사 업체 견적 3곳 비교 후 계약 | Must | 3h |
| 전입신고와 주소 이전 | Must | 1h |
| 인터넷 이전 신청 | Must | 0.5h |
| 가스·전기 정산 | Must | 1h |
| 대형 폐기물 배출 신고 | Must | 1.5h |
| 짐 박스 포장 (방 4개 전체) | Must | 12h |
| 커튼·블라인드 실측과 주문 | Should | 2h |
| 냉장고 비우기와 청소 | Should | 2h |
| 현관 도어락 교체 | Should | 1h |
| 이삿날 입주 청소 업체 예약 | Could | 1h |
| 새 수납장 조립 | Could | 4h |
| 집들이 | Won't | 5h |
처음 분류에서는 Must가 19시간으로, 계획한 29시간의 65.5%를 차지합니다. 짐 포장 12시간 전체를 Must로 둔 것이 원인입니다. DSDM 계열 설명에서는 Must가 계획된 작업량의 대략 60%를 넘지 않게 두라는 지침이 소개된다고 알려져 있습니다. 이유는 예상 못 한 일이 생겼을 때 Should와 Could를 줄여서 대응할 여유를 남기기 위해서입니다. 이 예시는 그 기준을 넘으니 항목을 쪼개 보는 것이 좋습니다. 포장을 "매일 쓰는 물건 7시간(Must)"과 "계절 지난 물건 5시간(Should)"으로 나누면 Must는 14시간, 계획 29시간의 48.3%로 내려가고 Should가 34.5%, Could가 17.2%가 됩니다. 이제 일정이 밀려도 Must 14시간만 지키면 되고, 줄일 수 있는 Should와 Could가 합쳐 15시간 남습니다(확보 시간 32시간 중 계획은 29시간).
이처럼 MoSCoW의 가치는 분류 결과보다 분류하는 대화에 있습니다. "전부 Must"라고 느끼던 항목을 쪼개서 Must 일부만 지키면 되는 구조로 바꾸는 과정이 범위 조정입니다. 도구의 "‹ ›" 버튼은 항목을 옆 칸으로 옮겨주므로 이런 재분류를 빠르게 해볼 수 있습니다.
지연이 생기면 어떻게 되는가: 분류 조정 후 계산
분류를 조정한 뒤 계획 29시간이 확보 시간 32시간 안에 들어와 있습니다. 하지만 실제 작업은 예상보다 더 걸리는 경우가 많습니다. 아래 표는 모든 작업이 일정 비율만큼 더 걸린다고 가정했을 때(조정 후 Must 14시간, Should·Could 합계 15시간 기준) 필요한 시간과 줄여야 하는 시간을 계산한 것입니다.
| 예상보다 더 걸림 | 전체 필요 시간 | Must만 필요한 시간 | 확보 시간 초과분 | Should·Could에서 줄일 시간 | Must가 32h 안에 들어오나 |
|---|---|---|---|---|---|
| 0% | 29.0h | 14.0h | 0.0h | 0.0h | 예 |
| 10% | 31.9h | 15.4h | 0.0h | 0.0h | 예 |
| 20% | 34.8h | 16.8h | 2.8h | 2.8h | 예 |
| 30% | 37.7h | 18.2h | 5.7h | 5.7h | 예 |
| 50% | 43.5h | 21.0h | 11.5h | 11.5h | 예 |
표를 보면 지연이 클수록 초과분이 늘고, 그만큼을 Should와 Could에서 덜어 내야 합니다. 이 여유가 MoSCoW에서 Must 비율을 낮게 유지하라고 하는 이유입니다. 만약 처음 분류처럼 Must가 19시간이었다면 20% 지연만 나도 Must만으로 22.8시간이 필요해 줄일 수 있는 항목이 거의 없는 상태가 됩니다. 표의 비율은 가정값이므로 자신의 지난 일정 지연 경험에 맞춰 보세요.
두 번째 예시: 동아리 축제 부스 준비
시간이 아니라 "안전·책임" 관점이 분류를 가른 가상의 사례도 봅니다. 대학 동아리가 축제에서 음식 부스를 운영하는데 준비 인시(사람 시간)가 정해져 있다고 합시다.
| 할 일 | 분류 | 인시 |
|---|---|---|
| 부스 신청서 제출과 배치 확인 | Must | 2h |
| 판매 품목 재료 구매 | Must | 4h |
| 현금 보관과 거스름돈 준비 | Must | 1h |
| 안전 점검(전기·화기) | Must | 2h |
| 현수막 제작 의뢰 | Should | 3h |
| 담당 교대표 작성 | Should | 2h |
| SNS 홍보 게시물 3개 | Could | 4h |
| 포토존 소품 제작 | Could | 6h |
| 자체 굿즈 제작 | Won't | 10h |
계획 대상은 Won't를 뺀 24인시이고, 이 중 Must가 9인시로 37.5%입니다. 이 사례에서 눈여겨볼 점은 "안전 점검"이 Must라는 것입니다. 시간이 모자라면 가장 먼저 미루고 싶은 항목이지만 빠지면 행사 자체가 성립하지 않을 수 있으므로 이 행사에 맞게 바꾼 질문("빼면 부스를 열 수 없거나 사고 위험이 생기는가?")의 답이 분명히 "예"입니다. 반대로 자체 굿즈(10인시)는 인기가 있을 듯해도 이번 범위에서는 Won't로 합의했습니다. 만약 합의 없이 슬그머니 시작했다면 10인시가 Must와 Should에 쓸 시간을 잠식했을 것입니다. 이처럼 Won't는 "버리는 칸"이 아니라 다른 항목을 지키기 위한 방패입니다.
분류 회의 진행법
- 항목을 먼저 전부 적습니다. 이 단계에서는 칸을 정하지 않고 판단도 하지 않습니다. 이 도구에서는 아무 칸에나 추가한 뒤 ‹ › 버튼으로 옮겨도 됩니다.
- Won't부터 정합니다. 가장 합의하기 쉬운 "이번에는 하지 않을 것"을 먼저 가르면 나머지 논쟁이 줄어듭니다.
- Must 후보에 확인 질문을 던집니다. "빠지면 마감 자체가 무너지는가?"에 "예"가 아니면 한 칸 내립니다.
- 시간·비용을 항목 옆에 적고 비율을 계산합니다. 이 도구의 비율은 항목 수 기준이라 시간 기준 계산은 별도로 해야 합니다.
- 점검 시점을 정합니다. 일정의 절반이 지난 시점에 한 번 더 분류를 열어 보도록 달력에 적어 둡니다.
다른 우선순위 기법과의 차이
MoSCoW는 칸으로 "범위"를 합의하는 데 강하고, 점수 계산 기법은 "순서"를 정하는 데 강합니다. 이메일·업무처럼 급한 정도가 핵심이면 아이젠하워 매트릭스가 어울리고, 하나의 칸에 항목이 몰렸을 때는 점수 기법으로 순서를 가립니다. 모든 항목에 같은 방법을 쓸 필요는 없으며, 먼저 MoSCoW로 범위를 자르고 Must 안에서만 점수를 매기면 분석 부담도 줄어듭니다.
Must 비율 표시 읽는 법
칸을 채우면 도구가 Must·Should·Could의 항목 수 비율을 보여주고, Must가 60%를 넘으면 안내를 띄웁니다. 이 도구는 시간을 입력받지 않기 때문에 항목 수 기준이며, 위 예시처럼 시간(또는 비용, 인력)이 항목마다 크게 다르면 실제 비율과 차이가 날 수 있습니다. 참고용 신호로만 보고, 정확한 판단은 항목별 작업량으로 직접 계산하세요.
흔한 실수
- 모든 항목을 Must로 둔다. 구분이 없어집니다. 마감이 하루 당겨졌을 때 무엇을 버릴지 정하는 것이 목적입니다.
- Won't를 비워 둔다. 하지 않을 일을 말로 확인하지 않으면 나중에 슬며시 범위가 늘어납니다. 제외 목록은 합의의 증거입니다.
- 사람의 선호로 분류한다. "내가 좋아해서 Must"가 아니라 빠졌을 때의 결과로 판단하세요.
- 한 항목이 너무 크다. 이사 포장처럼 큰 항목은 일부만 Must일 수 있으니 쪼개서 분류하세요.
- 분류를 한 번 하고 끝낸다. 일정이나 예산이 바뀌면 Should가 Must로 올라오거나 Could가 Won't로 내려갈 수 있습니다. 중간 점검 시점을 정해 두세요.
한계와 다른 도구
MoSCoW는 같은 칸 안의 순서를 정해 주지 않고, 항목의 비용이나 효과도 계산하지 않습니다. 한 칸 안에서 우선순위를 가려야 한다면 RICE 스코어링 도구나ICE 스코어링 도구로 점수를 매기고, 노력 대비 효과를 시각적으로 보고 싶으면임팩트-노력 매트릭스를 쓰세요. 분류가 끝난 이사 준비는이사 체크리스트로 일정별 점검표를 만들면 이어서 관리하기 쉽습니다.
입력한 내용은 어디에 저장되나요?
항목은 이 브라우저의 localStorage에만 저장되며 서버로 전송되지 않습니다. 다른 기기와 브라우저에는 동기화되지 않고, 시크릿 창을 닫으면 사라질 수 있습니다. "전체 초기화" 또는 브라우저 사이트 데이터 삭제로 지울 수 있고, 보관하려면 "텍스트로 복사"를 사용하세요.
자주 묻는 질문
Should have와 Could have는 어떻게 구분하나요?
빠지면 분명한 불편이나 손해가 생기지만 임시 방편이 있으면 Should, 빠져도 거의 아무도 곤란하지 않으면 Could입니다. 팀 안에서 "빠졌을 때 누가 어떻게 곤란한가"를 한 문장으로 답해 보면 구분이 쉬워집니다.
Won't have에 넣은 항목은 영영 안 하는 건가요?
아닙니다. "이번 범위에서는 하지 않기로 합의했다"는 의미일 뿐입니다. 다음 버전이나 다음 계획 때 다시 꺼내 재검토합니다.
Must가 너무 많이 나오면 어떻게 하나요?
먼저 항목을 더 작게 쪼개서 일부만 Must로 남길 수 있는지 봅니다. 그래도 많다면 마감을 늘리거나 인력을 늘리지 않는 한 모두 지킬 수 없다는 뜻이므로, 이해관계자와 범위 또는 일정 중 무엇을 조정할지 합의해야 합니다.
혼자 쓰는 일정에도 MoSCoW가 의미 있나요?
그렇습니다. 이사나 시험 준비처럼 혼자 하는 일도 시간이 부족해지면 무엇을 포기할지 미리 정해 두는 것이 도움이 됩니다. 이때 질문은 "빠지면 누가 곤란한가"가 아니라 "빠지면 내 목표가 무너지는가"로 바꾸면 됩니다.
같은 항목을 두 칸에 넣을 수 있나요?
넣을 수 없습니다. 같은 문장이 이미 어느 칸에 있으면 어느 칸에 있는지 알려 주고 추가하지 않습니다. 한 항목을 둘로 나누어 일부는 Must, 일부는 Should로 두고 싶다면 문장을 구분해서(예: "포장 - 매일 쓰는 물건", "포장 - 계절 지난 물건") 각각 입력하세요.
칸 안에서 순서를 바꿀 수 있나요?
칸 안의 순서를 바꾸는 기능은 없고 입력한 순서대로 쌓입니다. 칸을 옮기면 도착한 칸의 맨 아래에 붙습니다. 순서까지 정해야 한다면 점수 기법을 함께 쓰세요.
Must 비율 60%는 법칙인가요?
이 도구의 안내 기준일 뿐 법칙이 아닙니다. 방법론 설명에서 소개되는 지침을 참고한 값이며, 불확실성이 큰 일이라면 더 낮게, 확실한 일이라면 조금 높게 잡아도 됩니다. 중요한 것은 지연이 났을 때 줄일 수 있는 여유가 남아 있느냐입니다.
항목을 몇 개까지 넣을 수 있나요?
개수 제한은 두지 않았지만, 항목 한 줄은 80자까지 입력할 수 있습니다. 화면이 길어지면 읽기 어려우니 한 번에 10~20개 안팎으로 관리하고, 나머지는 복사해서 문서로 옮기세요.
항목을 다른 칸으로 옮기려면 어떻게 하나요?
항목 오른쪽의 ‹(앞 칸) ›(뒷 칸) 버튼을 누르면 Must, Should, Could, Won't 순서로 이웃한 칸으로 이동합니다. 첫 칸의 ‹와 마지막 칸의 ›는 동작하지 않습니다.