우선순위에 시달리다 공식을 만들었다

"리소스가 부족해서요."

"우선순위가 낮아서요."

어느 회사 어느 부서에서나 협업할 때 가장 많이 나오는 말 아닐까요? 지금 있는 인원으로 주어진 일정을 소화하기에도 바쁘므로 당신의 요청은 당장 들어주기 어렵다는 의미이지요. 한정된 인원이 규칙적인 릴리스 사이클을 지켜가면서 기술 부채도 최소화하며 좋은 프로덕트를 만드는 것은 꽤 어려운 일입니다.

플랫폼 서비스를 만들면 엔드 유저가 둘 이상이기에 각 엔드 유저의 만족도를 올리면서 엔드 유저 경험 사이의 균형을 맞춰야 하는 등 복잡도가 부쩍 올라갑니다. 서비스가 잘 되기 시작하면 파트너들로부터 요구 사항이 몰려오며, 거절하기 힘든 큰 비즈니스 기회로 빠르게 대응해야 할 일이 갑자기 들어오기도 합니다.

사업부나 영업부는 서로 자신들의 요구가 가장 중요하다고 말하고, 그 사이 CEO가 갑자기 그날 떠오른 생각을 메신저로 덜렁 보낼 때도 있습니다. 프로덕트 팀 내에서도 하나의 컴포넌트 팀이 다른 팀의 컴포넌트에 의존해서 원활히 진행이 안되는 경우도 있습니다.

큰일입니다. 서론만 썼는데도 머리가 아파옵니다. 읽는 분들도 마찬가지일 것입니다.

우선순위의 등장

이런 첨예한 상황에 둘러싸이면 우선순위와 그 판단 기준이 중요해집니다. 경영진뿐 아니라 사업, 영업, 운영, CS, 프로덕트 팀 등 모든 이해관계자가 납득할 만한 우선순위의 기준이 있을까요? 프로덕트 책임자에게 우선순위의 결정 권한이 있으니 마음대로 결정하면 되는 것일까요? 우선순위가 높은 것과 낮은 것의 이유는 무엇이며 둘 사이에는 얼마나 차이가 있는 것일까요?

저 역시도 일본의 최대 규모 배달 서비스 '데마에칸(Demaecan, 出前館)'의 쇄신을 진행하면서 450여 명의 프로덕트 팀원들과 수천 명의 관계 부서 분들에게 우선순위를 설정하고 설명해야 하는 상황을 겪었습니다. 시달리는 느낌을 받을 때도 있었습니다.

어느 날 선배 한 분이 조언을 주었습니다. "양식을 하나 만들고 우선순위를 기계적으로 설정해 봐. 아무리 급한 요청이 와도 어떤 양식에 따라 '당신의 우선순위는 22번째입니다'라고 대응하는 프로덕트 팀도 있더라"라는 조언을 들었습니다. 그 양식을 제가 보지는 못했지만요.

며칠 후 우선순위를 논의하는 회의는 또 찾아왔고, 너무나 도망치고 싶던 그날 새벽에 제가 이 회사에 입사한 원인이었던 머신 러닝(OCR 기술로 다니던 스타트업이 피인수됨)이 떠올랐습니다. 머신 러닝에서 힌트를 얻었다지만 실은 통계학을 활용한 것인데요. 진행 중인 프로젝트 몇 가지를 Excel에 넣고 수식화해 보니 만족스러운 결과가 나왔고 머리도 깨끗해지는 느낌을 받았기에 소개하고자 합니다.

제가 이번에 소개하는 우선순위 판단 공식은, 어쩌면 이런 주제의 시도 중 가장 기계적인 접근 방법입니다. 그리고 이는 여러 주관적인 변수와 판단을 최소화하면서 프로덕트의 높은 품질을 유지하기 위한 노력입니다.

판단 가치 고르기 - 우리에게 중요한 것은 무엇인가

매출을 올려야 합니다. 비용을 줄여야 합니다. 운영에 힘을 써야 합니다. 바이럴 효과를 높일 장치를 만들어야 합니다. 센스 있는 UX로 만족감을 높여야 합니다. 이처럼 서비스를 만드는 데에는 참 많은 욕망과 욕구가 있습니다.

모든 관점이 중요하다고 말하고 싶지만, 몇 개로 줄이고 집중할 필요가 있습니다. 그래야 설명도 명료하게 할 수 있고 이해하기에도 쉽습니다. 그 과정에서 어떤 관점은 다른 무언가와 합쳐지거나 대체될 수도 있고, 상황에 따라 더 중요한 관점에 밀려날 수도 있습니다. 예를 들어, 요즘은 IT 업계가 어려워지면서 어떤 서비스든 흑자가 될 수 있는 구조로 만드는 게 중요해졌습니다.

합의를 위한 양식을 만드는 과정이므로 여러 스테이크 홀더의 의견을 들으며 나열하면 좋습니다. 하지만 모든 가치를 다 고려하면 끝이 없으니 판단 기준을 명확히 하기 위해 몇 가지로 추릴 필요가 있습니다. 제 경우 아래와 같이 선정했는데요. 하나씩 설명하겠습니다.

매출과 비용

프로덕트 메이커는 프로덕트만 집중해서 만들 때 제일 행복하지만, 비즈니스를 지속하기 위해 기본이 되는 매출과 비용을 무시할 수는 없습니다.

프로젝트마다 기대 효과로 매출이 얼마나 늘어난다거나 비용을 얼마나 삭감할 수 있다고 시뮬레이션할 수 있습니다. 예를 들어, 검색 최적화 프로젝트를 진행해 검색 결과에서 구매로 이어지는 전환율이 1% 올라간다고 가정하고 예상되는 매출 향상을 말하는 식입니다. 비용을 줄이는 예시라면, 결제 회사를 변경할 경우 수수료를 몇 퍼센트 낮춰지므로 전월 매출 기준으로 얼마큼 절감된다고 말할 수 있습니다.

여기까지는 어렵지 않았습니다. 특히 사업에서 요청하는 안건이라면 이처럼 금전적인 기대 효과를 필수로 기입하도록 강제하면 좋습니다. 이렇게 두 개의 판단 기준(매출 상승, 비용 절감)은 어렵지 않게 정해졌습니다.

사용자 만족도

하지만 돈의 논리로만 판단하고 만드는 서비스는 반드시 실패합니다. 서비스를 만든다는 것은 사용자에게 사랑을 받고야 말겠다는 강한 의지와 끝없는 노력입니다. 그러므로 돈의 논리와 무관할지라도 사용자에게 즐거움을 주는 시도도 할 수 있어야 합니다. 대표적인 예로 디자인 개선이 있습니다. 아이콘을 좀 더 깨끗하고 트렌드에 맞게 바꾸는 일을 매출 향상이나 비용 절감으로 말하기는 어렵습니다.

그래서 이를 보완하기 위해 생각한 또 하나의 기준은 '만족도'입니다. 문제는 '만족'이라는 것이 꽤나 정성적인 가치라는 점입니다. 이를 어떻게 수치화해 공식에 적용할 수 있을까요?

만족도의 수치화에는 몇 가지 방법이 있습니다. 가장 유용한 방법은 사용자의 목소리를 근거로 수치화하는 것입니다. App Store 리뷰부터 설문조사까지 사용자의 피드백을 집계해 특정 이슈는 의견 중 최상위에 있으므로 만족도 향상에 크게 공헌할 안건이라고 말할 수 있습니다. 이때 저희 팀에서 가꾸고 있는 오픈소스 ABC User Feedback이 큰 도움이 됩니다. ABC User Feedback을 사용하면 이슈마다 몇 개의 피드백이 쌓였고, 그 추이는 어떻게 되는지 쉽게 파악할 수 있습니다.

사용자의 목소리를 정량적으로 수치화 해주는 피드백 수집 및 관리 도구 ABC User Feedback에 대한 자세한 설명은 블로그에 발행한 소개글 사용자의 피드백을 잘 관리하고 활용하기 위한 서비스, ABC User Feedback을 읽어보시기 바랍니다.

또 다른 방법은 베타테스터 또는 임의의 사용자 그룹을 대상으로 설문을 진행하는 것입니다. 프로덕트에서 언제든 가볍게 설문을 보낼 수 있도록 시스템부터 사용자 그룹까지 준비해 놓으면 좋습니다. 간단하게는 '좋아요/싫어요'의 2점 척도로 응답을 받거나, 통상적인 5점 척도로 의견을 받을 수도 있겠습니다.

끝으로 팀의 의지를 가중치로 표현하는 방법이 있습니다. 개인적으로는 처음 공식을 만들 때에는 가장 가볍게 시도할 수 있는 이 방법을 권합니다. 어느 정도 팀 안에서의 공감을 바탕으로 아래와 같이 간단한 2x2 매트릭스를 만들어 볼 수 있습니다.

	기대 효과 작음	기대 효과 큼
신규 기능	하면 좋겠다.	꼭 하고 싶다.
기능 개선	틈날 때 하자.	어쩔 수 없이 해야지.

위 표에서 구체적인 숫자를 기록하지는 않았습니다. 일단은 위와 같이 감각적으로 프로덕트 관점에서의 실현 의지를 기록해 놓고, 추후 그 비중을 숫자로 표현할 예정입니다.

위 예시는 시장에 새로운 서비스를 선보이는 시점을 가정해 기대 효과가 작든 크든 새로운 경험을 많이 내놓고 싶다는 의지를 나타내고 있습니다. 각 항목의 의미는 회사의 전략에 따라 다를 수 있습니다. 예를 들어, 어떤 안건이든 사용자의 기대 효과가 큰일을 우선하고 싶다면 '기대 효과 큼 + 기능 개선' 항목은 어쩔 수 없이 한다는 정도를 넘어서 '어떻게든 틈틈이 해치운다'는 생각을 가져야 할 것입니다. 안정성이나 운영이 중요한 서비스라면 어차피 예정된 신규 기능은 적을 테니 기능 개선의 비중을 더 크게 둘 것입니다.

레거시 해소

프로덕트를 만들 때 가장 어려운 점은, 겉으로는 작은 변화인데 안으로는 매우 큰 작업을 마주할 때입니다. 어느 프로덕트든 나름의 설계와 기술 부채가 있습니다. 보는 사람에게는 간단해 보여도 건물을 옆으로 1cm 옮기는 일일 수도 있고, 큰 변화처럼 보여도 가벼운 의자를 1cm 옮기는 일일 수도 있습니다.

하나의 안건이 얼마나 많은 컴포넌트를 수정해야 하는지는 프로덕트의 아키텍처로 어느 정도 산출할 수 있습니다. 얼마나 많은 사람들이 움직여서 해결할 수 있는지도 예상 참여자 수를 가늠해 수치화할 수 있습니다.

데마에칸의 경우, 현재 오래된 아키텍처의 백엔드를 100% 재작성하고 교체하는 장기 프로젝트를 진행 중입니다. 그런 만큼 레거시에서 실행해야 하는 프로젝트라면 경제 효과가 대단히 크지 않는 이상 가급적 하지 않는다는 방침을 세워 놓고 있습니다. 결국에는 같은 스펙을 새로운 아키텍처에서 재작업해야 하기 때문입니다. 그러니 급하지 않거나 하지 않아도 심각한 손해가 발생하는 게 아닌 안건이라면 하지 않는 게 좋겠지요.

이런 이유로 '사용자의 만족도'와 마찬가지로 아래와 같이 2x2 매트릭스를 만들었습니다.

	레거시 수정 적음	레거시 수정 많음
레거시에서 실행(재작업 필요)	이 정도는 하자.	절대 안 할 거야.
새로운 아키텍처에서 실행	이런 일이 제일 좋아!	가급적 안 하고 싶다.

위 표를 해석하자면, 왼쪽 위는 레거시에서 동작하는 결과물이지만 조금의 노력만 필요하다면 '이 정도는 하자'는 의미입니다. 활발히 운영 중인 서비스에서 프로덕트 팀에게 요청하는 안건 중에 기대 효과나 의미가 없는 것은 없을 테니, 레거시를 건드린다고 무조건 안 하겠다고 하면 사업적으로 성장하지는 못할 것입니다. 사용자는 우리가 레거시를 다루는지 새로운 아키텍처를 만드는지 아무런 관심이 없기 때문입니다.

오른쪽 위는, 그럼에도 안건이 레거시 컴포넌트 여러 개를 들쑤시며 팀원들도 많이 동원될 수 밖에 없는 일이라면 절대 하지 않겠다는 의지를 보이고, 추후 이를 수치로 표현할 예정입니다.

오른쪽 아래는, 비록 새로운 아키텍처에서 실행될 결과물이지만 레거시 컴포넌트까지 많이 수정해야만 하는 것이라면 차라리 레거시를 버릴 시점에 만드는 게 낫다고 생각할 수 있는 것을 표현한 것입니다. 이커머스에서는 주문 처리나 정산 등 데이터가 여러 컴포넌트에 폭넓게 걸쳐 있는 안건이 이에 해당합니다.

저희의 경우, 프로덕트로서 레거시 해소가 너무나 중요한 과제이기 때문에 레거시에 발목 잡히는 상황을 줄이고자 네 번째 항목은 '레거시 해소'로 정의했습니다.

우선 네 개로 정리

이와 같이 저는 여러 가치 중에서 앞서 소개한 네 가지 기준(매출 상승, 비용 절감, 사용자 만족도, 레거시 의존도)이 프로덕트의 우선순위를 판단할 때 가장 중요하게 작용한다고 설정했습니다.

가치를 선정하는 기준은 회사마다, 부서마다 다를 것입니다. 이미 충분히 효율적이거나 감당 가능한 수준이어서 비용 절감은 그다지 중요하지 않다고 생각하는 회사도 있을 것입니다. 검토했던 다른 기준으로는 사용자 수나 PU(Paid User), 작업 기간, 코드 변화량, 자동화 기여 등이 있었습니다. 일부는 다른 기준에 종속적인 관계여서 포함할 수도 있었습니다. 예를 들어 PU는 매출 상승 요소 중 하나라고 말할 수 있습니다.

이제 선정한 판단 기준에 따라 데이터를 입력하고 중요도에 따라 가중치를 정할 차례입니다.

데이터 입력

Excel만 한 게 없지

Excel을 열고 대규모 프로젝트만 우선 입력해 봤습니다. 프로젝트 항목이 많을수록 채워 넣어야 할 숫자가 많으니, 규모가 있고 필요한 숫자가 어느 정도 보이는 프로젝트부터 시도해 봅니다. 매출 상승과 비용 절감 항목에 대해서는 이미 받아놨던 숫자가 있으므로 아래와 같이 입력했습니다.

보시다시피 매출 상승 또는 비용 절감과 아무 상관 없는 프로젝트도 있습니다. 이 단계까지 오는 과정에서 표시 방식을 통일하는 이득도 얻었습니다. 어떤 프로젝트는 전환율(Conversion Rate)을 기준으로 작성했거나, 월 단위가 아닌 년 단위로 작성한 경우도 있었습니다. 이들을 일관된 매출 상승액과 월 단위로 통일할 수 있었습니다.

이제 비어 있는 사용자 만족도와 레거시 해소 항목에 점수를 넣겠습니다. 이 둘은 0.1의 정밀도로 조절하기에는 모호한 점이 많습니다. 정밀한 표현이 가능해도, 어차피 정밀하게 판단할 기준이 없으면 과감하게 정밀도를 낮출 필요가 있습니다. 앞서 2x2 매트릭스를 활용해 수치를 설정했는데요. 하나씩 살펴보겠습니다.

먼저 사용자 만족도는 아래와 같이 입력했습니다.

	기대 효과 작음	기대 효과 큼
신규 기능	0.7	1.0
기능 개선	0.2	0.4

위 표를 해석하자면, 신규 기능 행이 기능 개선 행보다 숫자가 큽니다. 이로써 신규 기능을 선보이는 데 힘을 주고 싶다고 말할 수 있습니다. 현재 저희 서비스는 유저들에게 새로운 경험을 선사하는 게 중요하므로 기능 개선보다 신규 기능에 더 높은 점수를 줬습니다.

그 다음 레거시 해소는 아래와 같이 점수를 부여했습니다.

	레거시 수정 적음	레거시 수정 많음
레거시에서 실행(재작업 필요)	0.5	0.0
새로운 아키텍처에서 실행	1.0	0.2

위 표에서 눈에 띄는 숫자가 있습니다. 0.0입니다. 이는 레거시를 많이 고치는 작업이면서 레거시에서 작동해야 하는 프로젝트로, '안하고야 말겠다'는 의지를 표현한 숫자라고 볼 수 있습니다. 만약 레거시 해소를 더 적극적으로 하고 싶다면 0.5 마저도 0.0으로 수정해서 새로운 아키텍처에서 실행할 수 있는 프로젝트만 고려하겠다는 의지를 숫자로 표현할 수도 있습니다.

결과적으로 모든 기준에 필요한 데이터를 입력한 모습은 아래와 같습니다.

데이터는 준비됐으니 이제 본격적으로 우선순위 공식을 적용해 볼 차례입니다.

우선순위 다항식 만들기

서론에서 말했듯 모티브는 오늘날의 머신 러닝입니다. 최소 단위는 가중치가 있는 다항식 한 개로, 입력값으로 트레이닝 데이터를 넣고 기대하는 결과에 가깝도록 여러 번, 여러 층으로 반복하면서 가중치를 최적화하는 게 통상적인 안면 인식 기술 같은 딥러닝 로직입니다.

우선순위 다항식을 만들 때 차용한다면 아래와 같이 나타낼 수 있습니다.

$Priority = (매출\:상승 \times w_{1}) + (비용\:절감 \times w_{2}) + (사용자\:만족도 \times w_{3}) + (레거시\:해소 \times w_{4})$

입력한 프로젝트 데이터에 위 수식을 적용할 수 있습니다. 단, 여기에 위 데이터의 숫자를 단순히 입력하기 전에 전처리 과정으로 각각의 기준을 단위와 무관하도록 0.0에서 1.0 사이의 범위로 정규화(normalization)할 필요가 있습니다. 또한 가중치(w) 4개의 총합은 1.0으로 만들어야 합니다.

정규화하기

매출과 비용은 예상 금액(원/월)단위이고, 레거시 해소나 만족도는 그렇지 않습니다. 이를 모두 상관없이 최소 0.0에서 최대 1.0으로 만들 필요가 있습니다.

우선 금액에 대해서는 가장 높은 수를 1.0으로 두고, 최대 효과 대비 각 프로젝트는 얼마나 작은 규모인지 비율을 나타내도록 했습니다. 어느 프로젝트가 매출 상승에 더 많이 기여할지 상대 평가를 하는 셈입니다. 비용에 대해서도 마찬가지로, 어느 프로젝트가 더 비용 감소에 공헌할 수 있는지 프로젝트 간에 상대 평가를 합니다.

이를 위해 Excel에 열(column)을 하나씩 추가합니다. 매출 상승 우측에 매출 상승률, 비용 절감 우측에 비용 절감률을 추가합니다. 매출 상승률의 경우 입력한 수식은 아래와 같습니다.

$매출 \; 상승률=\frac{매출 \; 상승액}{매출 \; 상승액 \; 중 \; 최고액}$

제대로 된 정규화 공식은 최댓값-최솟값을 분모로 두는 등 존재하는 숫자의 범위 안으로 설정할 필요가 있습니다. 제 경우에는 매출 상승에 0원이 있기에 최솟값은 어차피 0이 되므로 최댓값만 따지도록 단순화할 수 있습니다.

Excel로는 아래와 같이 표현할 수 있습니다. 열의 제목에는 판단 기준과 원본 데이터를 구분 수 있도록 굵은 글씨를 적용했습니다.

위 예시에서 매출 상승에 가장 크게 기여할 프로젝트는 'No.8 배달 지역 2단계 설정'이며 1.00을 보이고 있습니다. 숫자의 정밀도는 소수점 둘째 자리까지 표시했습니다. 소수점 하나만 했더니 0.0으로 보이는 경우도 있었기 때문입니다.

이것이 너무 단순한 방법처럼 보일 수도 있습니다. 단점이라면 최댓값이 너무 압도적이면 다른 프로젝트들이 짓눌리다 못해 사소해 보이는 문제가 나타날 수 있습니다. 이를 보완하려면 비율로 판단하기보다는 0.1~1.0 사이에 균등한 간격으로 분포하도록 수치화할 수도 있습니다. 그 외에도 몇 가지 보간법이 있겠지만 숫자를 정렬하고 그 사이를 적당히 나눈다는 본질에서는 벗어나지는 않으므로 생략하겠습니다.

가중치 설정하기

제 경우 매출을 높이는 것은 전사적으로도 가장 중요하므로 35% 가중치를 뒀습니다. 그 외에 다른 숫자들도 다소 정밀하진 않지만 경영진의 공감대가 있을 만큼은 조정해 봤습니다. 그 결과는 아래와 같았습니다.

$Priority = (매출\:상승 \times 0.35) + (비용\:절감 \times 0.2) + (사용자\:만족도 \times 0.3) + (레거시\:해소 \times 0.15)$

가중치는 처음에 적당하다고 생각하는 임의의 값을 넣어보며 조금씩 조정합니다. 이는 회사와 시장 상황에 따라 워낙 다르므로 정답은 없습니다.

예를 들어, 저는 처음엔 매출 상승이 너무 중요한 가치였기에 50%로 설정해 봤습니다. 그랬더니 다른 세 개의 가치가 모두 하찮아지는 문제가 있어서 조금씩 매출 상승의 비중을 낮추었습니다. 매출 상승의 가중치를 35%로 조정한 후에야 제가 만든 수치로 제가 설명할 수 있겠다는 생각이 들었습니다. 최종적으론 아래와 같이 시각화할 수 있었습니다.

위 수치를 이용해 아래와 같이 동료들에게 말할 수 있겠습니다.

"현재 우리는 무엇보다도 매출 상승이 중요하므로 이 기준이 가장 큰 비중을 차지합니다. 그다음으로 지금은 시장을 개척하는 단계이니 사용자의 만족도(0.3)가 비용 절감(0.2)보다 중요한 때입니다. 레거시는 우리에게 꼭 해결해야 하는 과제이므로 우선순위 판단에서도 그 의지를 보이고자 하나의 판단 기준으로 넣었습니다."

가중치까지 결정했으면 아래와 같이 수식을 적용해 봅니다.

Excel의 Conditional Formatting 기능으로 막대그래프를 배경에 칠해서 시각화했습니다. 우선순위 결과가 들쭉날쭉한 게 보입니다. 이제 우선순위가 높은 프로젝트는 다른 프로젝트보다 얼마나 높은지 숫자로 말할 수 있게 되었습니다.

우선순위가 높은 점수부터 낮은 점수까지 정렬하면 아래와 같습니다.

좋습니다! 이제 전사적으로 8번 프로젝트인 '배달 지역 2단계 설정'이 제일 중요하다는 게 명확해졌습니다. 이 프로젝트는 레거시 해소가 0.2점으로 많은 레거시 컴포넌트를 수정해야 하고 레거시 인프라에서 실행되지만, 그럼에도 전사적으로 중요한 의미가 있으므로 해내야 할 것입니다.

디버깅

하나씩 살펴보면 항목마다 작은 악마가 숨어있습니다. 악마는 숫자를 왜곡합니다. 예를 들어, '매출 상승'의 기대치는 어디까지나 '잘 됐을 경우'를 가정하므로 허수가 있습니다. 그에 비해 비용 절감은 비교적 명확합니다. 이미 현실에서 비용을 지출하고 있기에 대체 효과도 계산할 수 있기 때문입니다.

사용자의 만족도는 수치화했을 뿐, 아직 나름의 주관이 들어갈 여지가 있습니다. 레거시에 대한 판단 역시, 언젠가 미래에는 AI가 모든 코드와 인프라를 분석해 정확한 수치를 내놓을 수 있겠지만, 지금은 그다지 과학적인 판단이라고 볼 수는 없습니다. 대부분의 프로젝트는 기획도 완전하지 않은 상태일테니 정밀하게 측정하기에는 한계가 있습니다.

가중치도 마찬가지입니다. 위 예시에서는 '매출 상승'의 가중치를 35%라고 했지만, 34%는 어떨까요? 36%는 어떨까요? 이처럼 가중치가 아직 정밀하다고 볼 수는 없습니다. 이 글에서 소개하는 공식은 숫자로 말할 수 있고, 수치화로 객관성의 탈을 쓴 것처럼 보이지만 숫자 하나하나에는 어느 정도의 부정확함과 불완전함이 내포돼 있습니다.

이 공식은 어디까지나 협업과 커뮤니케이션 수단입니다. 가중치와 2x2 매트릭스의 숫자를 조정하며 우선순위가 뒤바뀌는 항목들을 확인하고, 나 자신이 마음 편히 설명할 수 있을 때까지 조정해 봅니다. 정렬 결과를 보며 어떻게 해도 기대했던 결과와 너무 다르게 나온다면, 원본 데이터라고 할 수 있는 각 프로젝트의 값에 문제가 있을 가능성이 큽니다. 저 역시 이럴 때 각 프로젝트의 매출 상승 기대치나 비용 절감 금액을 다시 검토해 봤습니다. 특히 어느 정도 인간적인 판단이 들어갈 여지가 있는 사용자 만족도를 다시 살펴보곤 했습니다. 사용자 만족도가 아니라 CEO의 기대감을 사용자 만족도로 착각했던 항목도 있어서 교정한 적도 있습니다.

사용자 만족도는 철저하게 사용자 한 명에게 주는 가치로 판단하면 좋습니다. 예를 들어 거리에 따라 여러 단계로 배달비를 차등 부과하자는 프로젝트가 있다고 가정합시다. 이것을 만드는 우리는 단일 배달비를 여러 단계로 나누므로 무척 새로운 기능이고 개발에 필요한 노력도 많을 것입니다. 그렇다면 이 프로젝트는 신규 기능일까요? 한 명의 사용자 입장에서 볼 때에는 원래부터 지불하던 배달비를 조금 다른 금액의 배달비로 경험할 뿐이므로 신규 기능보다는 기능 개선이라고 말할 수 있습니다. 하지만 한 명의 사용자가 배달 수단에 따라 배달비를 선택할 수 있는 프로젝트가 있다면 이는 신규 기능이라고 말할 수 있습니다.

이처럼 우선순위 공식은 수치화의 탈을 쓴 양식이지만 숫자로 표시하기까지 인간적인 판단이 들어갈 여지가 많습니다. 저는 이것이 나쁘다고 생각하지 않습니다. 우선순위 판단의 이유를 말할 때 모호하게 말하던 언어를 숫자의 언어로 바꾼 것뿐이지 우선순위를 판단하던 감각이 달라지는 것은 아닙니다.

정렬된 우선순위 결과가 충분히 공감을 얻을 수 있겠다는 생각이 들면, 주요 스테이크 홀더들과 공유하며 공감을 얻을 수 있도록 합니다. 저는 아래와 같은 순서대로 설명을 했습니다.

우선 왜 이런 양식을 마련했는지 설명합니다. 그동안 우선순위를 말할 때 단순히 '높다/낮다'로만 이야기해 왔는데 높다면 얼마나 높은지, 다른 우선순위를 뒤집을 정도로 높을 때 그 근거는 무엇이었는지 객관적으로 파악하기 어려웠다는 문제를 제기하고, 수치화와 객관화, 시스템화가 필요하다고 말합니다.
표의 각 항목을 설명합니다. 왜 네 개의 판단 기준을 선정했으며, 각각은 왜 판단 기준이 될 자격이 있는지 회사와 시장의 상황, 서비스의 현황과 방향성을 공유하며 말합니다. 판단 기준을 선정한 과정과 이유를 말할 때는 모든 스테이크 홀더의 공감을 얻는 게 중요합니다. '레거시 해소' 같은 기준은 프로덕트 팀의 사정을 모르는 다른 부서에서는 관심이 없을 수 있기 때문입니다. 예를 들어 레거시를 해소하는 만큼 더욱 다양한 요구 사항을 빠르게 소화할 수 있다고 말할 수 있습니다.
그다음, 기본 공식을 소개하고 정규화의 필요성을 말합니다. 정규화를 거친 후 눈에 띄게 비중 차이가 나는 프로젝트가 나온다면, 왜 이런 결과가 나왔는지 설명하면 더욱 친절하게 느낄 수 있을 것입니다.
이제 가중치를 설명할 차례입니다. 이 중에서 가중치를 설명하는 게 가장 중요합니다. 가중치는 우리 모두가 무엇을 중요하게 생각하는지 합의하고 동의를 구하는 과정이기 때문입니다. 이 과정에서 스테이크 홀더의 의견을 들으며 다시 조정하는 경우도 발생할 것입니다.
최종 결과를 보며 모두가 동의하면 한 분기는 이 공식과 수치에 근거해 판단하겠다고 선언합니다.

여기까지 진행하면서 저 스스로를 돌아보기도 했습니다. 프로덕트 팀 내부에서도 하고 싶은 게 많았는데요. 회사 전체가 한마음으로 지속 가능한 서비스를 만들려면 프로덕트 팀 스스로도 자신이 하고 싶은 일이 얼마나 의미가 있는지 객관화해서 살펴보는 훈련이 필요합니다. 이 공식에 따라 프로덕트 팀이 하고 싶은 일의 우선순위가 다른 안건보다 낮다면 그것은 그것대로 인정하는 자세도 필요합니다.

실제로 제가 제안했던 프로젝트가 비용 절감과 만족도 관점에서 무척 의미 있다고 생각했지만, 결과를 보니 순위가 그리 높지 않아서 '그래... 지금은 이것보다 중요한 게 있지'라며 속으로 되뇌었던 적도 있습니다.

주기적으로 조정하겠다고 말하기

시장 상황이나 서비스의 성장, 경쟁 서비스의 출현 등 상황은 시시각각 변하므로 처음의 기준과 가중치를 유지할 수는 없습니다. 일정 기간마다 회고를 하며 비율을 조정하고 공유할 필요가 있습니다. 변경이 크게 발생한다면 선정한 기준 중 없앨 것과 새로 채용할 기준이 나올 수도 있습니다.

회사와 프로덕트의 규모에 따라 다르지만, 제 경험상 대체로 하나의 프로젝트는 한 분기를 기준으로 판단하는 게 적당한 기간이었습니다. 즉, 3개월 또는 4개월마다 회고를 하고 회사의 방향과 시장 상황에 맞춰 최적점을 찾도록 조정하면 좋습니다.

예를 들어 저희 팀 예시를 보면, 레거시 쇄신 프로젝트가 끝나갈 때쯤에는 레거시 해소의 의미가 적어질 테니 다른 기준을 만들 필요가 있습니다. 예정된 미래라고 할 수 있습니다.

팁 - 릴리스 시각화와 컴포넌트 필터

우선순위 형식을 정하고 스테이크 홀더를 만나며 설명하다 보니 부가적인 정보를 추가해 이해를 도울 필요가 있었습니다. 그래서 우선순위 결과 오른쪽 두 개 열을 추가했습니다. 하나는 릴리스 예정 시기를, 또 하나는 프로젝트마다 주로 담당할 컴포넌트를 입력했습니다.

릴리스 예정 시기는 YYMM 형태로 넣어 보고, 시기에 따른 배경색도 넣어 보니, 우선순위대로 어느 정도 순차적으로 작업하고 있는지 보였습니다.

참고로 배경색은 위와 같은 Conditional Formatting 규칙을 지정해 표시했습니다. 글 작성일 기준으로 한 해가 지난 2025년에 완성될 프로젝트는 노란색으로 눈에 띄게 표시했습니다.

이처럼 릴리스 시기를 함께 기록하면 스테이크 홀더에게 설명할 때 '비록 우선순위는 낮지만 예상하고 있던 일정으로는 릴리스되는구나'라며 안심을 줄 수 있습니다. 여기서 릴리스 시기는 프로젝트의 규모와 의존도에 따라 다릅니다. 즉 동시에 몇 개의 프로젝트가 진행될 때 우선순위가 낮은 프로젝트가 더 빨리 릴리스되는 경우도 흔히 있습니다. 따라서 우선순위대로 차근차근 진행되지 않는 것처럼 보일 수도 있지만, 대체로 위는 진하고 아래로 갈수록 밝아지는 추세를 볼 때는 의미가 있습니다.

이때 두 번째로 추가한 컴포넌트 열과 함께 보면 이해도가 높아집니다. 프로젝트의 중심이 되는 컴포넌트를 기록하고 Excel의 필터 기능을 적용해 담당 부서별로 우선순위를 볼 수 있도록 했습니다. 부서별로 필터링했을 때 우선순위의 정렬 순서와 릴리스 시기가 어느 정도 유사한 흐름으로 보인다면 대체로 프로젝트 관리가 잘 되고 있다고 볼 수 있습니다. 팀원들에게도 여러 일 사이에서 퍼즐 맞추기를 하는 게 아니라, 앞으로 반년 또는 그 이상 예정된 프로젝트를 명확한 기준으로 제시해 효율적이고 예측 가능한 결과를 만들도록 유도할 수 있습니다.

조금 더 운영해 보니 연관된 컴포넌트가 여러 개일 때는 제대로 필터링이 안 되는 문제가 있었습니다. 플랫폼 서비스는 한 컴포넌트만 끝냈다고 해결되는 게 아니라 여러 컴포넌트에 걸쳐 있는 경우가 많습니다. 특히 이 목록에 등재될 정도로 규모가 큰 프로젝트는 대부분 그렇습니다. 만약 두 컴포넌트에 걸쳐 팽팽하게 의존성이 걸려 있는 프로젝트라면 같은 값으로 프로젝트를 두 개 등록해 볼 수도 있습니다. '프로젝트 A'를 '프로젝트 A(컴포넌트1)'과 '프로젝트 A(컴포넌트2)', 두 개로 복사해 등록하는 식입니다.

예를 들어 아래와 같습니다.

위와 같이 오렌지색의 프로젝트명에는 C(Consumer), M(Merchant)를 붙여서 하나의 프로젝트지만 두 컴포넌트가 상호 의존적인 프로젝트임을 표시했습니다. 어차피 행마다 점수는 독립적이므로, 동일한 값의 두 프로젝트가 등록돼도 전체 우선순위는 변하지 않습니다. 마치 공동 1등이 있을 때 그다음 순위는 3등이 되는 원리입니다.

이렇게 입력하고 Consumer 영역의 우선순위를 필터링해 확인하면 다음과 같습니다.

위 결과를 보면, 반반 옵션 메뉴 개발의 릴리스는 우선순위가 매우 높지만 릴리스는 10월로 늦은 편입니다. 반면 그보다 우선순위가 낮은 다른 프로젝트는 더 일찍 릴리스할 수 있다고 나오고 있습니다. 따라서 Consumer 컴포넌트를 담당하는 팀과 대화해 지금 어디에 힘을 쏟아야 하는지 논의해서 조정하거나, 어떤 문제 때문에 가장 중요한 프로젝트가 다른 프로젝트보다 늦어지고 있는지 파악할 필요가 있습니다.

다른 팀을 볼까요?

쿠폰 팀은 비교적 평화롭게 우선순위에 맞춰 프로젝트를 진행할 수 있어 보입니다. 우선순위가 높은 것은 6월에, 낮은 것은 두 달 후에 릴리스할 수 있다고 나오기 때문입니다. 이러면 다음 프로젝트로 무엇이 더 가능한지 알아보거나, 없으면 두 프로젝트만 끝내고 리팩토링할 시간을 확보해 줄 수 있습니다.

마치며

지금까지 2년간 규모 있는 프로덕트를 담당하면서 여러 스테이크 홀더에게 보다 명확하게 설명할 수 있고 보다 예측 가능한 결과를 주기 위한 저만의 방법을 소개했습니다. 이 공식 또한 하나의 접근 방법이자, 미래에는 여러 시행착오 중 하나로 남을 수도 있을 것입니다. 그럼에도 좋은 프로덕트를 만들기 위한 노력과 경험의 한 페이지이니, 한 번쯤 저와 비슷한 고민을 하신 분들이라면 시도해 보시길 바랍니다.