MoSCoW

출시일이 먼저 정해지는 프로젝트가 있습니다. 계약서에 날짜가 적혀 있거나 행사에 맞춰야 하는 경우입니다. 이런 일정에서 가장 자주 벌어지는 사고는 기능을 못 만드는 게 아니라, 마지막 2주에 무엇을 빼야 할지 아무도 합의하지 못하는 것입니다.

빼자는 말이 나오면 대화가 늘 같은 자리에서 막힙니다. 영업은 그 기능 때문에 계약이 걸려 있다고 하고, 개발은 지금 빼면 구조를 다시 짜야 한다고 하고, 디자인은 그거 없으면 화면이 반쪽이라고 합니다. 셋 다 틀린 말이 아닙니다. 문제는 그 자리에서 처음 순위를 매기려 한다는 것이고, 일정이 코앞인 상태에서는 어느 쪽도 물러서지 못합니다.

점수를 매기는 방식도 이 상황에서는 잘 듣지 않습니다. RICE처럼 도달 범위와 영향을 곱해 노력으로 나누면 1위부터 꼴찌까지 줄이 서지만, 정작 알고 싶은 것은 순서가 아니라 선입니다. 12위까지가 필수인지 7위까지가 필수인지는 점수가 답해 주지 않습니다. MoSCoW 는 줄을 세우는 대신 선을 긋습니다. 1994년 소프트웨어 개발 방법론 하나에서 정리된 말이고, 날짜는 고정이고 범위가 움직이는 프로젝트를 전제로 만들어졌습니다.

이름은 네 등급의 머리글자입니다. 사이의 소문자 o 는 발음을 위해 넣은 것이고 뜻이 없습니다.

1. Must have — 이게 없으면 출시라고 부를 수 없는 것입니다. 판단 기준은 취향이 아니라 결과입니다. 빠진 채로 내보냈을 때 법에 걸리거나, 제품이 동작하지 않거나, 약속한 계약을 어기게 되는지를 봅니다.
2. Should have — 없으면 아프지만 출시는 되는 것입니다. 대개 우회로가 있습니다. 자동으로 처리되지 않아 운영팀이 손으로 하면 되는 종류입니다.
3. Could have — 있으면 좋고 없어도 아무도 크게 아쉬워하지 않는 것입니다. 일정이 밀릴 때 가장 먼저 잘려 나가는 자리이고, 잘리라고 만들어 둔 자리이기도 합니다.
4. Won't have — 이번에는 안 한다고 못 박은 것입니다. 논의하지 않았다는 뜻이 아니라 논의한 뒤 뺐다는 뜻입니다. 이 등급이 MoSCoW 에서 가장 자주 생략되고, 생략하면 방법 전체가 헐거워집니다.

진행은 네 단계입니다.

1. 후보를 제품 백로그에서 한 목록으로 꺼내고 크기를 비슷하게 맞춥니다. 며칠짜리와 몇 달짜리를 같은 표에 올리면 등급이 뒤섞입니다.
2. 제품·개발·영업이 한자리에서 등급을 붙입니다. 혼자 매기면 나중에 그 등급이 부정당합니다.
3. 필수 등급의 분량을 잽니다. 기준은 전체 일정의 60퍼센트 아래입니다. 8주 프로젝트라면 필수가 5주 안에 끝나야 합니다.
4. 남은 40퍼센트에 권장과 선택을 순서대로 채웁니다. 이 구간은 계획이 아니라 여유분입니다.

3번이 이 방법의 전부라고 해도 됩니다. 필수가 8주를 꽉 채우면 무엇도 늦을 수 없는 계획이 되고, 그런 계획은 첫 주에 장애 하나만 나도 무너집니다.

맞는 자리는 분명합니다. 날짜가 고정돼 있고 범위를 조절할 수 있는 프로젝트입니다. 기업 고객에게 3월 1일 납품을 약속한 상황, 행사 당일에 맞춰 페이지를 여는 상황이 여기 해당합니다. 이때 팀에 필요한 것은 어느 기능이 3순위인지가 아니라 오늘 밤에 무엇을 잘라도 되는지입니다.

반대로 안 맞는 자리도 분명합니다.

날짜가 고정되지 않은 상시 개발에는 쓰지 않습니다. 잘라야 할 이유가 없으니 등급이 의미를 잃고, 시간이 지나면 모든 항목이 필수로 올라갑니다. 이런 일에는 가치-노력 매트릭스처럼 가치와 드는 품을 두 축에 놓고 사분면에 붙이는 방식이 낫습니다.

후보를 미세하게 줄 세워야 할 때도 맞지 않습니다. 같은 등급 안에서는 순서가 없기 때문입니다. 권장 등급에 열두 건이 들어 있으면 그중 무엇을 먼저 할지는 MoSCoW 가 답하지 않습니다. 그 답이 필요하면 ICE처럼 영향·확신·용이성에 점수를 매겨 곱하는 방식을 등급 안에서 한 번 더 돌립니다.

가장 큰 한계는 등급이 협상 도구로 변하기 쉽다는 점입니다. 필수가 절반을 넘는 표를 받았다면 그 표는 우선순위가 아니라 요구 목록입니다. 막는 방법은 규칙을 숫자로 못 박는 것뿐입니다. 필수가 60퍼센트를 넘으면 등급을 다시 매긴다고 정해 두고, 넘었을 때 실제로 되돌려 보냅니다.

"이번 스프린트 필수가 70퍼센트예요. 다시 매겨야 합니다."

여유분이 없어 계획이 성립하지 않는다는 지적입니다.

"그건 Won't have 로 적어 두죠. 다음 분기에 다시 봅니다."

빼되 잊지는 않겠다는 약속입니다.

"필수만 나가도 고객이 쓸 수 있나요?"

등급을 제대로 매겼는지 되묻는 질문입니다.

페이지덱이 기업 고객 첫 계약에서 3월 1일 납품을 약속했을 때 이 방법을 썼습니다. 요구사항은 서른한 건이었고 팀에 남은 시간은 7주였습니다. 지현이 세 시간짜리 회의를 잡아 영업 수아와 개발 태오를 같이 앉혔습니다.

첫 결과는 필수가 열아홉 건이었습니다. 태오가 산정해 보니 6주가 넘었고, 규칙대로 되돌려 다시 매겼습니다. 두 번째에 필수는 아홉 건으로 줄었습니다. 관리자 계정 권한 설정은 필수로 남았고, 사용 현황 대시보드는 계약서에 없다는 이유로 권장으로 내려갔으며, 화면 색을 고객사 색으로 바꾸는 요구는 Won't have 에 적혔습니다. 2월 마지막 주에 장애가 하나 터졌고, 그때 잘린 것은 권장 등급 세 건이었습니다.

네 등급을 중요도 순서로 읽는 경우가 많습니다. 필수가 제일 중요하고 제외가 제일 안 중요하다는 식입니다. 실제로는 중요도가 아니라 이번 기한 안에서의 필요 여부를 나눈 것입니다. 회사의 장기 방향에서 가장 중요한 기능이 이번 분기에는 제외로 갈 수 있습니다. 중요도 순서로 읽으면 제외 칸에 넣는 일이 그 기능을 깎아내리는 것처럼 느껴져 아무도 거기에 항목을 넣지 않게 됩니다.

한 번 매기면 끝이라고 보는 오해도 있습니다. 등급은 프로젝트 중간에 바뀝니다. 만들어 보니 필수인 줄 알았던 것이 없어도 되는 경우가 나오고, 반대도 나옵니다. 매주 한 번씩 표를 다시 보는 팀과 첫 회의 결과를 그대로 들고 가는 팀의 차이는 마지막 주에 드러납니다. 뒤쪽은 두 달 전 정보로 무엇을 자를지 정하게 됩니다.