PART1. 시작할 것인가, 말 것인가
기획자가 되고 나서 초반에는 별다른 고민 없이 내부 결정권자의 판단에 따라 프로젝트에 투입되었다. 프로젝트에 따라 정해진 일정 안에서 무리 없이 진행되는 경우도 있었지만, 대부분은 오픈이 가까워질수록 일정이 빠듯해졌다. 야근은 물론 휴일을 반납하는 일이 반복되었고, 상황에 따라 추가 인력이 투입되는 것도 특별한 일은 아니었다.
연차가 쌓이면서 한 가지 변화가 생겼다. 프로젝트에 투입되기 전, 나는 내가 맡게 될 일이 할 수 있는 프로젝트인지, 아니면 해야 하는 프로젝트인지를 먼저 생각하게 되었다.
조직에 속한 기획자에게 프로젝트는 대부분 위에서 정해진다. 의견을 낼 수는 있지만, 결정이 내려지고 나면 선택지는 많지 않다. 그래서 가능 여부보다, 이 프로젝트를 어떤 조건에서 시작하게 되는지를 먼저 보게 된다.
프리랜서 기획자의 경우에는 상황이 조금 다르다. 경기가 좋아 진행 예정인 프로젝트가 많을 경우, 할 수 있는 프로젝트가 아니라 해야 하는 프로젝트를 선별해 선택할 수 있다. 그러나 경기가 좋지 않을 때는 선택지가 빠르게 줄어든다. 그 순간에는 프리랜서 역시 할 수 있는 프로젝트라도 붙잡아야 하는 상황에 놓인다. 결국 형태만 다를 뿐, ‘해야 하는 프로젝트’ 앞에서의 고민은 크게 다르지 않다.
할 수 있는 프로젝트와 해야 하는 프로젝트
이 두 질문은 비슷해 보이지만, 실제로는 전혀 다른 의미를 가진다.
결론부터 말하면, 할 수 있는 프로젝트는 생각보다 많다. 일정이 빠듯하면 야근으로 버틸 수 있고, 필요하다면 인력을 더 투입할 수도 있다. 그래도 일정이 맞지 않으면 기능을 쪼개어 어떻게든 오픈 시점을 맞출 수 있다. 하지만 이런 방식은 프로젝트를 해결하는 방식이라기보다, 결국 사람이 감당하는 방식에 가깝다.
반면, 해야 하는 프로젝트는 많지 않다. 해야 하는 프로젝트는 일정이 빠듯할수록 범위와 우선순위를 다시 정의하게 만든다. 무엇을 먼저 만들 것인지, 무엇을 지금 하지 않아도 되는지를 구조적으로 판단하게 한다. 요구사항이 추가되면 그 영향도를 기준으로, 어디까지를 구축 범위로 가져갈지 분명한 선을 긋게 된다.
내가 말하는 해야 하는 프로젝트란, 사람이 버티는 구조가 아니라 구조를 먼저 다시 보게 만드는 프로젝트다.
기획자는 프로젝트를 최종 결정하는 사람이 아니다. 계약을 체결하는 것도, 일정을 확정하는 것도 대부분은 조직의 장이나 PM의 역할이다. 조직에 속해 있든, 프리랜서로 일하고 있든, 기획자가 프로젝트의 시작 여부를 단독으로 결정할 수 있는 경우는 많지 않다.
그래서 내가 말하는 ‘판단’은 프로젝트를 중단시키기 위한 권한이 아니다. 이 프로젝트를 어떤 조건에서 시작해야 하는지, 무엇이 전제가 되어야 하는지를 드러내는 일에 가깝다. 기획자는 결정을 내리는 사람이 아니라, 결정이 가능하도록 기준을 먼저 만들어 두는 사람에 가깝다.
이 과정에서 기획자는 프로젝트를 시작하기 전과 진행 과정에서, 어디에서 무너질 수 있는지를 가장 먼저 체감하는 사람이 된다. 제안요청서에 적힌 요구사항이 현실에서는 어떤 형태로 구현되는지, 그 요구사항이 일정과 구조에 어떤 영향을 미치는지를 기획자는 가장 먼저 연결해서 보게 되기 때문이다. 그래서 이 단계에서 기획자의 판단은 아주 조용하게 이루어진다.
“이 일정은 조금 무리일 것 같은데요.”
“이 요구사항은 진행하다 보면 범위가 커질 수 있을 것 같아요.”
“이 부분은 추가 협의가 필요해 보입니다.”
이 말들은 자칫 방어적으로 들릴 수도 있고, 결정을 미루는 말처럼 보일 수도 있다. 하지만 이런 판단이 곧바로 “하지 말자”로 이어지는 것은 아니다. 다만 이 질문을 건너뛴 채 프로젝트를 시작하면, 이후 문제가 생겼을 때 기획자는 훨씬 더 힘들어진다. 이 질문을 생략한 프로젝트는 진행 중에 계속해서 같은 질문을 되돌려 받게 되기 때문이다.
“왜 일정이 더 필요하다는 거죠?”
“왜 이 요구사항은 지금에 와서야 어렵다고 하는 거죠?”
“왜 처음의 말과 달라요?”
이 질문들은 결국 같은 지점으로 돌아온다.
처음에, 이 프로젝트를 왜 시작했는지.
이 판단을 건너뛰었던 프로젝트가 기억이 난다. 해당 프로젝트는 처음부터 요구사항이 명확하지 않았다. 기능 목록은 있었지만 무엇이 핵심인지, 무엇을 반드시 오픈 시점에 구현해야 하는지는 드러나지 않았다. 또한 실무자들은 많았지만 결정권을 가진 사람은 보이지 않았다. 그럼에도 프로젝트는 시작됐다. 할 수 있어 보였기 때문이다.
프로젝트가 중반을 넘기면서 문제가 본격적으로 드러났다. 회의에서 결정이 되었던 것이 결정권자의 의견에 따라 변경이 되었다. 구조가 바뀌었고, 그에 따라 전체 사용자 흐름을 다시 설계해야 했다. 이미 진행 중이던 작업 위에 새로운 요구사항이 덧붙여졌고, 합의됐다고 생각했던 내용들은 다시 논의 테이블 위로 올라왔다. 요구사항은 늘어났지만 일정은 그대로였다. 오히려 마케팅 일정과 내부 일정이 겹치며 개발 기간은 더 줄어들었다.
결국 오픈 일정은 한 차례 미뤄졌다. 하지만 일정이 늘어났다고 해서 문제가 해결된 것은 아니었다. 부족한 시간을 메우기 위해 더 많은 인력이 투입됐고, 휴일 근무가 일상이 되었다. 크리스마스도 예외는 아니었다. 사람은 늘어났지만 구조는 바뀌지 않았다. 결정권은 여전히 불분명했고, 요구사항은 계속해서 움직였다. 프로젝트는 끝났지만 그 과정에서 남은 것은 완성의 성취감보다 버텼다는 기억에 가까웠다.
지금 돌아보면 이 프로젝트에서 가장 아쉬운 지점은 기획의 디테일이 아니라, 시작할 때 던지지 못했던 질문이었다. 이 프로젝트에서 누가 결정하는가, 요구사항이 바뀔 수 있는 범위는 어디까지인가, 일정이 흔들릴 때 무엇을 지킬 것인가. 이런 질문들을 시작 전에 충분히 하지 않았기 때문에, 프로젝트는 끝까지 사람이 버티는 구조로 흘러갔다.
그래서 나는 프로젝트를 마주할 때마다 스스로에게 같은 질문을 던진다. 이 프로젝트는 우리가 버틸 수 있는 구조인가, 아니면 버티는 사람만 남게 되는 구조인가.