내가 납득하지 못하는 프로젝트를 해야 할 때

어느 날 팀장님이 나를 불렀다. “작년에 진행하다가 보류된 A 개선 프로젝트, 이번에 다시 해봐야 할 것 같아요.” 그 말을 듣는 순간, 머릿속에 작년의 회의록과 데이터들이 한꺼번에 떠올랐다. 마음이 무거워졌다.

A 과제는 사용자의 니즈와 부합하지 못해 오픈 후 레거시로만 남아 있는 과제였다. 개선을 위해 여러 방향으로 고민하고 데이터도 찾아봤지만, 사용자의 니즈가 없는 기능을 다시 끌어올리기란 여간 힘든 일이 아니었다. 회사가 추구하는 목표와도 상이해서 결국 진행되지 못한 채 보류 처리가 된 프로젝트였다. 보류라는 단어는 부드럽지만, 실제로는 한 번 죽은 과제를 다시 살리려는 시도에 가깝다.

PM으로 일하다 보면, 자신이 충분히 납득하지 못한 채로 손을 들어야 하는 프로젝트를 만나게 된다. 그럴 때 어떻게 마음을 정리하고 어디까지 자기의 기획을 지킬 것인지, 그 경계를 어떻게 그어야 하는지에 대한 이야기를 이 글에 풀어 보려 한다.

납득하기 전에 다시 묻는 일

나는 팀장님에게 프로젝트의 배경과 목표를 먼저 이해하고 싶다고 말했다. PM으로서 “왜 이걸 다시 해야 하는가”를 모른 채 일을 시작하는 것은 가장 비효율적인 출발이라고 생각했다.

먼저 현재 데이터를 짧게 정리해 다시 공유했다. 해당 기능을 사용하는 사용자가 약 3% 수준에 머물고 있고, 그마저도 다른 기능으로 우회하여 사용한다는 사실. 작년 보류 시점과 비교해도 큰 변화가 없다는 사실. 그리고 이 과제를 다시 진행하려면 3~4개월의 개발 리소스가 필요하다는 사실. 이 정도 리소스를 투입한다면, 같은 분기에 어떤 다른 전략적 목표가 있는지 함께 알고 싶다고 물었다.

팀장님은 “일단 한번 진행해 보시죠. 제가 어제 B 회사 분이랑 미팅을 해 봤는데, 거기서는 그 기능을 사용자가 원하고 있다고 하더라고요”라고 답했다. 외부 업체의 요청이 결정의 근거였다.

이 답을 듣는 순간 PM으로서 두 가지 감정이 동시에 올라왔다. 하나는 “그 한 회사의 요청이 우리 사용자 전체를 대변하지는 않는다”는 분석가의 마음. 다른 하나는 “그래도 결정은 내려졌고, 나는 이 일을 받아야 한다”는 실무자의 마음. 이 두 가지 마음 사이에 서는 일은 PM이라면 누구나 한 번씩은 겪는다.

납득되지 못한 과제를 맡는 일은 많은 IT 회사원이 경험할 것이다. 그럴 때 단순히 거절하거나 단순히 따르는 것 외의 세 번째 길이 필요하다고, 이 시점부터 생각하기 시작했다.

같은 일을 다른 목표로 다시 잡기

PM으로서 이런 상황에 마주했을 때, 나는 다른 목표를 찾아보기로 결심했다. 위에서 내려진 목표가 사용자의 니즈와 어긋난다는 건 데이터로 분명했지만, 같은 개발 리소스를 들여서 다른 가치를 만들 수 있는 길은 있었다.

기존에 제시된 목표는 “그 기능의 사용률을 올리는 것”이었다. 하지만 나는 이 목표를 잠시 옆에 두고, 회사 입장에서 진짜 가치가 될 수 있는 다른 목표를 다시 잡았다. 그 결과 잡은 것이 운영 리소스를 최소화하는 방향이었다. 개발 스펙을 통일화하고, 사용자에게 동일한 프로세스를 제공할 수 있도록 흐름을 단순화하면, 사용률이 크게 늘지 않더라도 운영팀과 CS팀의 부담이 명확히 줄어든다. 이건 사용자에게 직접 보이는 변화는 아니지만, 회사 내부의 자원 측면에서는 분명한 개선이었다.

이렇게 대안적 목표를 찾으니 프로젝트에 대한 믿음이 천천히 생기기 시작했다. “내가 납득하지 못하는 목표”를 “내가 납득할 수 있는 목표”로 다시 재정의하는 작업. 이건 회사의 결정을 거부하는 것이 아니라, 같은 자원으로 더 의미 있는 가치를 만드는 작업에 가깝다. 그리고 이 작업을 거치고 난 뒤에야 나는 비로소 기획서를 차분하게 쓸 수 있게 되었다.

PM이 지킬 수 있는 작은 선

이 경험을 거치고 나서 정리한 PM의 작은 원칙 몇 가지가 있다.

첫째, 납득하지 못하는 프로젝트라도 일단 데이터로 한 번 말해 본다. 데이터로 한 번 말해 보고 나면, 결정자도 한 번 더 생각하게 되고, 본인도 자신의 의견을 객관적으로 다시 들여다보게 된다. 데이터를 들이대지 않은 채 그저 “이건 사용자가 원하지 않는 것 같아요”라고 말하는 건 의견이지 근거가 아니다.

둘째, 결정이 내려진 뒤에는 빠르게 다음 단계를 본다. 결정의 옳고 그름을 계속 곱씹는 시간은 PM에게 가장 큰 손실이다. 결정이 내려졌다면, 같은 자원으로 어떤 다른 가치를 만들 수 있는지를 빠르게 다시 설계하는 편이 모두에게 이롭다.

셋째, 내 마음속의 “이건 아닌데” 신호는 기록한다. 이 프로젝트가 끝났을 때, 어떤 시점에 어떤 데이터가 어땠는지를 정리해 둔다. 같은 종류의 결정이 또 들어왔을 때, 이 기록이 다음 결정에 분명한 영향을 미친다. 결정 한 번에 지지 않더라도, 회사의 결정 문화는 이런 기록의 누적으로 천천히 바뀐다.

사용률은 늘지 않았지만, 일은 자랐다

결과적으로 사용자는 처음 예상과 달리 3%에서 크게 늘지 않았다. 하지만 B 회사 담당자는 그 기능을 잘 사용하고 있다고 했고, 우리가 새로 잡은 운영 리소스 최소화라는 방향에서는 성공적으로 오픈됐다. 운영팀의 반복 작업이 줄었고, CS팀이 같은 유형의 문의로 시간을 쓰는 일이 눈에 띄게 줄었다.

이 경험은 PM으로서 한 가지 분명한 교훈을 남겼다.

**모든 프로젝트를 내가 100% 납득한 채로 시작할 수는 없다는 것. 그리고 납득하지 못했다고 해서 그 프로젝트에서 얻을 가치가 없는 것도 아니라는 것.

결정자의 목표와 내 목표가 다를 수 있지만, 그 사이에 같은 자원으로 만들어 낼 수 있는 다른 가치가 항상 존재한다는 것.

오늘도 어딘가의 PM은 자기 책상 위에 올라온 프로젝트를 보며, 한 번 더 묻고 있을 것이다. “이게 정말 맞을까?” 그 질문은 사라지지 않을 것이고, 사라져서도 안 된다. 다만 그 질문 뒤에 한 번 더 묻는 질문이 있다면 다행이라고 생각한다. “그렇다면 이 안에서 내가 만들 수 있는 가장 의미 있는 변화는 무엇인가?” 그 질문이 PM의 일을 지치지 않게 만든다.

오늘도 나는 그냥 기획서를 썼다. 하지만 그 기획서는 어제의 나보다 한 뼘 더 자란 사람이 쓴 기획서였다.