PART 2. 계약 전에 이미 시작된 일들
견적은 공수 산정이 아니라, 리스크를 배분하는 일이다.
견적을 낼 때, 기획자가 받게 되는 요청 중 하나는 일정과 투입 인원에 대한 자료다.
견적 담당자는 전체 금액을 계산하지만, 그에 앞서 PM은 예상 일정의 틀을 잡고, 디자이너와 개발팀에는 각자의 작업 범위와 소요 시간을 묻는다. 기획자에게도 예외는 아니다. 기획 단계에 어느 정도의 시간이 필요한지, 어디까지를 범위로 보고 있는지에 대한 설명이 함께 요구된다.
이 정보들은 보통 WBS라는 형태로 정리된다. 작업을 단위로 나누고, 순서를 잡고, 대략적인 기간을 배치하는 방식이다. 이 과정에서 일정이 만들어지고, 그 일정 위에 투입 인원이 얹히면서 공수가 계산된다. 그리고 이 공수를 기준으로 견적이 산정된다. 중요한 것은 WBS 그 자체가 아니다. WBS는 견적을 계산하기 위한 출발점일 뿐이고, 실제로는 어떤 전제를 기준으로 일정을 선정했는지가 더 중요하다.
겉으로 보면 견적은 숫자의 합처럼 보인다. 하지만 실제로는 판단의 결과에 가깝다. 이 프로젝트를 어떤 조건으로 완주하겠다는 선택이 숫자로 드러난 것이다.
예전에 이런 경험이 있었다. 견적서를 전달한 뒤, 고객사로부터 이런 문의를 받았다.
“견적금액이 너무 비싼 것 같아요.”
그 프로젝트는 기간이 매우 짧았고, 요구된 기능은 많았다.
다만 화면 수나 겉으로 보이는 서비스 구조만 놓고 보면 비교적 단순해 보일 수도 있는 프로젝트였다. 그래서 고객사 입장에서는 정해진 예산 안에서, 예상한 일정 내에 충분히 오픈이 가능하다고 판단했던 것으로 보인다.
하지만 실제 구현을 기준으로 보면 상황은 전혀 달랐다. 각 기능은 단순해 보였지만 서로 긴밀하게 연결되어 있었고, 정책과 예외 처리, 운영 시나리오를 함께 고려해야 했다. 충분한 검토와 테스트가 없으면 오픈 이후 곧바로 문제가 드러날 가능성이 높은 구조였다.
일정도 이미 고정되어 있었다. 일정은 조정할 수 없는 전제로 주어졌고, 그 안에서 모든 작업을 마쳐야 했다.
이 상황에서 선택지는 명확했다. 범위를 줄일 수 없다면, 일정을 늘릴 수 없다면, 결국 투입 방식을 조정할 수밖에 없다. 그래서 견적은 높아질 수밖에 없었다. 기술적으로 특별히 어려워서가 아니라, 시간이 필요한 작업을 제한된 일정 안에 담기 위해 인력을 동시에 투입해야 하는 구조였기 때문이다.
겉으로 보면 기간과 인력은 단순히 비례한다고 생각하기 쉽다. 예를 들어 기간이 2달이고 투입 인원이 1명이라면, 기간을 1달로 줄이면 2명을 투입하면 되는 것처럼 보인다. 하지만 실제 프로젝트는 그렇게 단순하게 나뉘지 않는다. 일정이 절반으로 줄어든다고 해서 필요한 인력이 정확히 두 배로 끝나는 경우는 드물다.
작업 간 의존 관계가 있고, 병렬로 나눌 수 없는 구간이 있으며, 인력이 늘어날수록 커뮤니케이션과 정렬 비용도 함께 증가한다. 그래서 일정이 압축될수록 필요한 인력은 단순히 두 배가 아니라 그 이상으로 늘어나기도 한다. 견적이 높아지는 이유는 기술 난이도 때문이라기보다, 제한된 시간 안에서 안정성을 유지하기 위한 선택의 결과에 가깝다.
고객사에게 견적과 관련된 이 부분을 설명하는 일은 쉽지 않았다.
“겉보기보다 복잡합니다”라는 말은 자칫 변명처럼 들릴 수 있기 때문이다. 기능이 많아 보이지 않는 상황에서 비용이나 공수가 늘어나는 이유를 납득시키는 일은 언제나 조심스럽다.
그래서 우리는 추상적인 설명 대신, 실제 작업 기준으로 이야기를 풀어갔다. 기능의 개수를 말하기보다 기능 간 연결 관계와 정책 조건, 예외 처리 범위에 대해 설명했다. 또한 검토와 테스트 시간이 왜 필요한지, 어떤 구간은 병렬로 진행할 수 없고 어떤 구간은 추가 인력이 필요한지, 그리고 인력을 줄이거나 일정을 그대로 둘 경우 어떤 위험이 생길 수 있는지를 구체적인 작업 흐름 기준으로 설명했다.
결국 중요한 것은 “복잡하다”는 판단을 말로 전달하는 것이 아니라, 그 판단이 나오게 된 구조를 함께 보게 하는 일이었다.
그제서야 논의의 방향이 바뀌었다. 비용이 많고 적음의 문제가 아니라, 이 프로젝트를 어떤 조건으로 진행할 것인가에 대한 이야기로 옮겨갔다. 일정과 공수에 대한 전제를 다시 확인했고, 그에 맞춰 견적 역시 조정되었다.
돌이켜보면 이 프로젝트는 구조적으로 여유 있는 프로젝트는 아니었다. 조건을 바꾸지 않는 한, 일정 안에 일을 밀어 넣기 위해 사람의 부담이 커질 수밖에 없는 구조였다. 실제로 진행은 가능했지만, 그 부담이 어디에 쌓이게 될지는 비교적 분명한 상태였다. 그럼에도 이 프로젝트는 진행되었다. 여러 현실적인 이유로 “하지 않는다”는 선택하기가 쉽지 않았기 때문이다.
이 경험을 통해 더 분명해진 것이 있다. 견적이 높게 느껴질 때, 그 이유는 숫자 자체에 있는 경우가 드물다. 대부분은 그 숫자가 만들어질 수밖에 없었던 조건에 있다.
WBS는 일정표이기도 하지만, 동시에 작업의 전제가 어디까지 설정되어 있는지를 보여주는 문서이기도 하다. 이 전제를 바탕으로 일정과 투입 방식이 결정되고, 그 위에 견적이 만들어진다.
견적에 대한 최종 협의는 보통 PM이나 계약 당사자가 진행한다. 다만 그 협의에 앞서, 왜 이 금액으로 산정되었는지, 왜 이런 형태의 WBS가 구성되었는지에 대한 설명은 기획자와 함께 정리되는 경우가 많다.
이 장에서 말하고 싶은 것은 하나다. 견적은 숫자를 계산하는 과정처럼 보이지만, 실제로는 어떤 조건과 전제를 기준으로 프로젝트를 진행할 것인지에 대한 판단에 가깝다. 그리고 그 판단이 어떤 문서와 설명 위에서 만들어졌는지를 정리하는 과정에 기획자가 함께 서게 되는 경우가 많다.
다음 장에서는 계약 협의가 시작된 이후, 제안 단계에서는 드러나지 않았던 요구사항들이 왜 다시 등장하는지, 그리고 방향성 합의와 요구사항 사이에 생기는 시간차가 프로젝트에 어떤 영향을 주는지를 이야기해보려 한다.