PART1. 시작할 것인가, 말 것인가
제안요청서를 받으면 일정만큼이나 요구사항도 중요하게 보게 된다. 무엇을 만들어야 하는지, 페이지는 몇 개인지, 관리자 기능은 어디까지 필요한지. 그리고 자연스럽게 이 요구사항들이 가능한지부터 계산한다.
나 역시 처음에는 그랬다. 요구사항을 하나씩 체크하며 구현이 가능한지, 공수는 얼마나 드는지, 사업 추진 일정 안에서 시스템 오픈이 가능한지부터 따져보았다. 하지만 여러 프로젝트를 거치면서 요구사항을 바라보는 순서는 조금 달라졌다. 이제는 요구사항 그 자체보다, 그 요구사항이 협의를 통해 변경 가능한 상태인지를 살펴본다.
제안요청서의 구조는 이미 답을 말하고 있다
제안요청서를 보면 대부분 사업개요 다음에 제안요청 내역이 나온다. 상세한 기능 설명보다 앞서 무엇을 요청하는지부터 정리되어 있다는 점은 의미가 있다. 요구사항은 독립된 목록이 아니라, 사업의 전제와 맥락 위에서 정의된 결과물이기 때문이다. 그리고 이 제안요청 내역 안에는 대개 두 가지 중요한 정보가 함께 들어 있다. 이 프로젝트가 어떤 전제를 깔고 있는지, 이번 제안에서 어디까지를 오픈 범위로 보고 있는지다.
전제조건에는 이 프로젝트가 어떤 기준을 충족해야만 시작될 수 있는지가 담겨 있다. 기술력, 과제 수행 능력, 보안 및 컴플라이언스에 대한 필수 요건, 그리고 홈페이지 운영을 위해 반드시 충족해야 할 필수 요건 등. 이 항목들은 단순한 참고 사항이 아니라, 이 프로젝트에 누가 참여할 수 있는지, 어디까지 책임질 수 있는지를 미리 제한하는 조건들이다. 전제조건을 제대로 읽지 않으면 요구사항은 쉽게 오해된다. 기능 목록만 보면 가능해 보이는 일도 이 전제조건들을 함께 놓고 보면 사실상 불가능하거나 현실적으로 무리가 되는 경우도 있기 때문이다. 따라서 기획자는 요구사항보다 먼저 이 전제조건들이 실제로 어떤 의미를 가지는지를 확인한다.
제안범위는 무엇을 해달라는 요청인 동시에, 무엇까지를 우리의 책임으로 볼 것인지를 가늠하게 만드는 기준이다. 그리고 제안범위 하단에는 대개 이런 문장이 함께 적혀 있다.
“아래 명시된 내용 외에도 추가 요청사항이 발생할 수 있습니다.”
형식적으로는 유연성을 열어두는 문장처럼 보이지만, 이 문장이 들어가는 순간 제안범위는 고정된 기준이 아니라 열려 있는 상태가 된다. 무엇이 추가 요청인지, 어디까지가 제안범위인지, 그 경계는 문서 어디에도 명확하게 드러나지 않는다. 결국 이 문장은 “지금 정리된 요구사항이 최종은 아니다”라는 전제를 깔고 프로젝트를 시작하겠다는 선언에 가깝다.
문제는 이 전제가 요구사항 하나하나보다 훨씬 강하게 작동한다는 점이다. 제안서에 명시된 기능보다, 제안범위 하단에 적힌 이 한 줄의 문장이 이후 논의의 기준이 되는 경우도 많다.
“이건 추가 요청이 아니라 당연히 포함된 줄 알았어요.”
“처음부터 가능하다고 생각했는데요.”
이 말들은 대부분 이 문장 위에서 자연스럽게 등장한다.
결정은 누가 하느냐보다, 언제 끝나는지가 중요하다
기획자는 요구사항을 보기 전에, 이 프로젝트에서 누가 어디까지 결정할 수 있는지를 먼저 묻는다. 프로젝트의 담당자는 명시되어 있지만, 그 담당자가 어떤 수준까지 결정을 확정할 수 있는지는 문서에 드러나지 않는 경우가 많다. 이때 회의에서는 의견이 오가지만, 결정은 늘 “내부 검토 후”라는 말과 함께 다음 단계로 미뤄진다. 이런 구조에서는 요구사항이 확정되지 않은 상태로 계속 쌓이게 된다. 그리고 무엇이 언제 확정되는지 알 수 없기 때문에, 그만큼 일정 역시 불확실해진다.
결정의 주체보다 더 중요한 것은, 그 결정이 언제 확정되었다고 말할 수 있는가다. 어떤 기능이 언제까지 확정되는지, 무엇은 바뀔 수 있고 무엇은 그 이후로 더 이상 바뀌지 않는지에 대한 기준이 있어야 한다. 이 기준이 없다면 요구사항은 언제든 다시 열려 있는 상태로 남게 되고, 그 불확실성은 프로젝트가 진행될수록 점점 더 큰 리스크로 돌아온다.
요구사항보다 먼저 살펴봐야 할 것 중 하나는 정책이다. 겉보기에는 단순한 기능처럼 보이지만, 실제로는 운영 정책과 깊게 엮여 있는 요구들이 있기 때문이다. 이런 경우 정책이 바뀌는 순간, 요구사항의 범위는 순식간에 커질 수 있다.
문제는 이 변화가 기능 변경으로 인식되지 않는 경우가 많다는 점이다. 대개는 “운영상 필요한 조정”이라는 말로 다뤄진다. 그러다 보니 요구사항이 늘어나고 있다는 사실조차 뒤늦게 인식되기도 한다. 설령 인식되더라도, “운영상 필요”라는 이유가 붙는 순간 사실상 거절하기 어려운 선택지가 된다. 그 결과 요구사항은 공식적인 변경 절차를 거치지 않은 채, 조용히 프로젝트 범위 안으로 흡수되곤 한다.
운영이 정리되지 않으면, 기획은 끝나지 않는다
또 하나 놓치기 쉬운 것은 구축 이후의 운영이다. 운영의 주체는 누구인지, 운영 인력은 확보되어 있는지, 이슈가 발생했을 때 누가 판단하고 누가 책임지는지. 이 질문들에 대한 답이 없다면 요구사항은 구축을 기준으로만 정의된다. 그리고 운영 단계에 들어서는 순간, 그 요구사항은 계속해서 수정되기 시작한다. 문제는 그 수정의 대부분이 다시 기획자에게 돌아온다는 점이다.
그래서 요구사항을 검토할 때 기획자는 자연스럽게 다음과 같은 질문들을 던지게 된다.
“이 요구는 누가 결정했는가.”
“이 요구는 언제 확정되었는가.”
“이 요구는 정책이 바뀌면 어디까지 영향을 받는가.”
“이 요구는 오픈 이후에도 그대로 유지될 수 있는가.”
이 질문들에 명확한 답이 없다면, 그 요구사항은 언젠가 다시 변경될 가능성이 높다. 지금은 문제 없어 보일지라도, 운영이 시작되는 순간 다시 논의의 대상이 되기 쉽기 때문이다.
이 장에서 말하고 싶은 것은 결국 하나다. 요구사항은 기획의 출발점이 아니라, 여러 판단이 쌓여 만들어진 결과에 가깝다. 그 요구사항이 누가 언제 어떤 기준으로 정했는지를 확인하지 않은 채 시작한 기획은, 결국 다시 손보게 된다. 그래서 기획자는 요구사항을 바로 정리하기보다, 먼저 이 요구가 어떤 판단 위에서 만들어졌는지를 살펴본다. 이 부분이 분명하지 않을수록, 기획자는 한 번 더 멈춰서 요구사항을 바라보게 된다.
다음 장에서는 질문을 정리하는 순간 기획이 시작되는 이유를 정리한다.
요구사항은 답이 아니라, 질문을 만드는 출발점에 가깝기 때문이다.