PART1. 시작할 것인가, 말 것인가
실무를 하다 보면 일정에는 이상한 공통점이 있다. 대부분의 일정은 프로젝트가 시작되기도 전에 이미 정해져 있다는 점이다. 그 일정을 기준으로 내부 보고 일정, 마케팅·홍보 일정, 외부 공개 일정과 개발 기간이 역산되어 끼워 맞춰진다.
이렇게 만들어진 일정은, 제안요청서에서는 계획처럼 보이지만 실제로는 결과에 가깝다. 동시에 반드시 지켜야 할 마지노선이 되기도 한다. 오픈 일정이 흔들리면, 그에 따라 다른 일정들도 함께 흔들리기 때문이다.
그래서 제안요청서를 받으면 중요하게 살펴보는 항목 중 하나가 일정이다. 오픈 일정을 기준으로 설계, 디자인, 개발, 테스트, 검수 일정을 역산해본다. 일정이 빠듯해 보이면 공수를 다시 산정하고, 인력을 늘리면 가능한지, 기능을 쪼개면 맞출 수 있는지부터 고민한다.
하지만 여러 프로젝트를 거치면서 일정을 바라보는 시선은 조금 달라졌다. 이제는 일정이 빠듯한지보다, 왜 이 일정이 나왔는지를 먼저 보게 된다.
일정이 경고로 바뀌는 순간
일정의 여유나 촉박함보다 중요한 것은, 그 일정이 어떤 전제를 기준으로 만들어졌는지다. 일정이 빠듯해도 기준과 전제가 명확하다면 조정할 수 있는 선택지는 비교적 분명해진다. 무엇을 줄일 수 있고, 무엇은 반드시 지켜야 하는지가 이미 정리되어 있기 때문이다.
반대로 일정이 길어 보이더라도, 그 일정이 무엇을 전제로 만들어졌는지 알 수 없다면 작은 변경 하나에도 전체 계획은 쉽게 흔들린다. 결국 중요한 것은 일정 그 자체가 아니라, 이 일정이 어떤 판단을 거쳐 만들어졌는지, 무엇을 지키기 위해 정해진 일정인지를 아는 일이다. 이 전제가 보이지 않는 일정은 기준이 되지 못하고, 상황에 따라 계속 대응해야 하는 조건으로 남게 된다.
일정이 위험 신호가 되는 순간은 대개 이런 형태로 나타난다. 일정은 정해져 있는데 개발 범위가 정해지지 않았을 때, 검수나 심사 같은 필수 단계가 일정에 제대로 반영되지 않았을 때, 그리고 “일단 오픈하고 보자”는 말이 자연스럽게 따라붙을 때다.
실제로 “일단 오픈하고 보자”는 판단으로 오픈을 진행한 프로젝트가 있었다. 오픈 일정은 절대 미룰 수 없는 조건이었고, 테스트는 끝나지 않은 상태였다. 이미 발견된 오류도 있었지만 “치명적이지 않다”는 판단 아래 “오픈 후 바로 잡자”는 결론으로 서비스는 예정대로 공개되었다. 결과는 예상보다 훨씬 치명적이었다. 단순한 불편 수준이 아니라 서비스의 핵심 흐름에 문제가 생겼고, 그로 인해 며칠 동안 정상적인 운영이 어려운 상태가 이어졌다.
이 경험을 통해 분명히 알게 된 것이 있다. “일단 오픈하고 보자”는 말은 속도를 내겠다는 선택이 아니라, 리스크를 감수하겠다는 선언에 가깝다는 점이다. 그리고 그 리스크는 대부분 기능이 아니라 신뢰와 구조에 먼저 영향을 준다.
오픈은 끝이 아니라 시작이다. 문제가 있는 상태로 시작된 서비스는 이후의 모든 대응을 ‘수습’의 형태로 만들고, 그 부담은 운영과 기획 단계에서 계속 누적된다. 그래서 일정이 빠듯한 상황에서 “일단 오픈하고 보자”는 말이 나올 때, 기획자는 실행 여부보다 그 이후를 감당할 수 있는 구조인지를 먼저 물어야 한다.
일정이 부족할 때, 기획 일정이 왜 항상 먼저 당겨질까
일정이 빠듯한 프로젝트일수록 이런 말이 함께 나온다.
“기획은 최대한 빨리 끝내고, 개발하면서 맞춰보죠.”
“상세한 건 진행하면서 정리해도 될 것 같아요.”
이 말들은 속도를 내자는 제안처럼 들리지만, 실제로는 불확실성을 뒤로 미루겠다는 의미에 가깝다. 그리고 그 불확실성은 언젠가 반드시 문제의 형태로 드러난다. 기획 단계에서 드러나면 그나마 조정할 수 있는 선택지가 남아 있지만, 개발이 끝난 뒤 테스트 단계에서 터지면 선택지는 급격히 줄어든다. 그때 남는 방법은 대개 하나, 사람의 시간을 더 쓰는 것이다.
기획자는 일정을 직접 결정하는 사람은 아니다. 하지만 일정이 흔들릴 때 가장 먼저 영향을 받는 사람이다. 일정이 줄어들 때 가장 먼저 조정 대상이 되는 것이 기획 단계이기 때문이다. 아직 코드가 작성되지 않았고, 눈에 보이는 결과물이 없다는 이유로 기획 일정은 가장 쉽게 줄어드는 대상이 된다.
기획 일정이 줄어들면 검토와 정리는 생략되고, 논의는 결정으로 둔갑한다. 그리고 이 상태에서 만들어진 기획서는 이후 단계에서 “왜 이렇게 되었는지”를 계속해서 설명해야 하는 문서가 된다. 결국 기획 단계에서 줄어든 시간은 이후 단계에서 계속된 수습과 대응으로 이어진다.
일정이 위험해지는 순간
일정이 빠듯하다는 신호는 숫자보다 맥락에서 드러난다.
- 왜 이 일정은 절대 미룰 수 없는가.
- 이 일정이 흔들리면 무엇이 가장 먼저 영향을 받는가.
- 이 일정 안에서 정말 조정 가능한 것은 무엇인가.
이 질문에 아무도 명확하게 답하지 못한다면, 그 일정은 조율하는 대상이 아니라 그냥 버텨야 하는 일정이 된다.
이 장에서 말하고 싶은 것은 결국 하나다. 일정이 빠듯한 프로젝트가 모두 나쁜 프로젝트는 아니다. 하지만 일정이 왜 빠듯한지 설명되지 않는 프로젝트는 대부분 위험하다.
기획자가 먼저 해야 하는 질문
기획자가 해야 할 일은 일정을 맞출 방법을 찾는 것이 아니라, 이 일정이 어떤 전제 위에서 만들어졌는지를 드러내는 일이다. 예를 들어 이 일정이 마케팅 캠페인 때문에 고정된 것인지, 내부 보고 일정이나 외부 공개 일정과 맞물려 정해진 것인지를 분명히 하는 일이다.
그래서 나는 일정을 볼 때마다 스스로에게 먼저 묻는다.
- 이 일정은 조정할 수 있는 계획인가,
- 아니면 사람이 버텨야만 가능한 결과인가.
이 질문에 답하지 못한 채 프로젝트를 시작하면, 오픈이 다가올수록 선택지는 점점 줄어든다. 결국 남는 것은 늘 비슷하다. 사람을 더 투입할 것인가, 휴일을 반납할 것인가, 아니면 누군가가 더 많은 책임을 떠안을 것인가.
다음 장에서는 요구사항을 정리하기 전에, 그 요구가 협의를 통해 얼마나 변경될 수 있는 상태인지 먼저 확인해야 하는 이유에 대해 다뤄보려한다.