제안요청서·제안서·사업계획서·전략기획서: 누가 쓰고 누가 읽는가

제안서 목차를 짤 때 회사 소개부터 놓는 경우가 많습니다. 연혁, 비전, 주요 실적, 조직도 순으로 스무 장쯤 만들고 그다음에 본론으로 들어갑니다. 그런데 발주처가 나눠 준 제안서 평가표를 보면 그 스무 장에 배점이 걸린 항목이 없는 경우가 흔합니다.

이건 문서를 잘못 쓴 것이 아니라 문서의 종류를 잘못 고른 것입니다. 회사 연혁과 비전은 사업계획서의 언어이고, 제안서는 다른 질문에 답하는 문서입니다.

한 묶음으로 읽히지만 작성 주체가 다른 네 문서

전략기획서, 사업계획서, 제안요청서, 제안서는 흔히 "기획 단계 산출물"로 함께 묶입니다. 순서대로 쓰는 문서처럼 보이기도 합니다. 그런데 이 넷은 쓰는 사람이 서로 다릅니다.

문서	쓰는 쪽	읽는 쪽	답하는 질문
전략기획서	우리	우리 경영진	어느 시장에서 어떻게 이길 것인가
사업계획서	우리	투자자·은행·심사역	그래서 이게 돈이 되는가
제안요청서	발주사	수주 후보 여럿	우리에게 필요한 것은 이것이다
제안서	수주 후보	발주사 평가위원	그것을 우리가 이렇게 하겠다

네 칸 중 제안요청서만 작성 주체가 우리가 아닙니다. 이 한 줄이 나머지 차이의 대부분을 설명합니다.

돈의 방향이 반대인 한 쌍, 제안요청서와 제안서

제안요청서(RFP)와 제안서는 따로 존재할 수 없는 한 쌍입니다. 돈을 내는 쪽이 제안요청서를 쓰고, 돈을 받으려는 쪽이 제안서를 씁니다. 반드시 상대가 있고, 상대가 없으면 두 문서 다 의미가 없습니다.

전략기획서와 사업계획서는 반대입니다. 아무도 요청하지 않았는데 우리가 씁니다. 읽는 사람이 회사 안에 있거나(전략기획서), 돈을 대 줄 사람이거나(사업계획서) 할 뿐, 어느 쪽도 "이걸 써서 내라"고 요구받아 쓰는 문서가 아닙니다.

법이 발주자에게 요구사항 상세화를 강제한 배경

제안요청서가 발주자의 문서라는 사실은 관행이 아니라 법에 적혀 있습니다. 소프트웨어 진흥법 제44조는 이렇게 규정합니다.

국가기관등의 장은 소프트웨어사업을 발주하는 경우 소프트웨어사업자가 과업 규모를 산정할 수 있도록 과학기술정보통신부장관이 행정안전부장관과 협의하여 고시하는 기준에 따라 요구사항을 상세하게 작성·공개하여야 한다. (소프트웨어 진흥법 제44조)

주목할 부분은 목적절입니다. "소프트웨어사업자가 과업 규모를 산정할 수 있도록." 제안요청서는 발주자가 자기 생각을 정리하려고 쓰는 문서가 아니라, 수주 후보가 견적을 낼 수 있게 하려고 쓰는 문서라는 뜻입니다.

법이 이걸 의무로 못 박아야 했다는 사실 자체가 무엇을 말하는지는 분명합니다. 요구사항이 부실한 제안요청서가 계속 나왔고, 그 부담이 전부 수주 측으로 넘어갔기 때문입니다.

제안서의 목차를 수주 측이 정하지 못하는 구조

여기서 제안서의 성격이 결정됩니다. 제안요청서가 항목을 정해 공개했다면, 제안서는 그 항목에 답하는 문서입니다. 목차를 우리가 짜는 것이 아니라 상대가 정해 준 격자를 채우는 일에 가깝습니다.

평가 방식이 그렇게 되어 있기 때문입니다. 평가위원은 제안서를 감상하는 것이 아니라 항목별로 점수를 매깁니다. 제안요청서에 없는 항목을 아무리 잘 써도 그 점수를 넣을 칸이 없습니다.

제안서 작성이 비싸다는 것도 법이 인정하는 사실입니다. 같은 법 제52조는 떨어진 후보 중 평가가 우수했던 곳에 제안서 작성비용의 일부를 보상할 수 있게 해 두었습니다(제52조). 비용이 들지 않는 문서라면 보상 조항이 생기지 않았을 것입니다.

전략기획서와 사업계획서를 가르는 숫자의 유무

이 둘의 경계는 앞의 구분만큼 단단하지 않습니다. 회사마다 다르게 쓰고, 한 문서로 합쳐 내는 곳도 많습니다. 저는 실질적인 기준이 하나라고 봅니다. 숫자가 붙었는가.

전략기획서는 방향까지 답합니다. 어느 시장에 왜 들어가는가, 무엇으로 이길 것인가. 사업계획서는 거기에 금액과 기간을 붙입니다. 언제 얼마를 써서 언제부터 얼마를 버는가.

중소벤처기업부 계열 지원사업이 쓰는 표준 양식이 이 성격을 잘 보여 줍니다. 문제 인식, 실현 가능성, 성장 전략, 팀 구성 네 블록으로 되어 있고, 심사위원은 이 순서로 "돈을 왜 여기에 줘야 하는가"를 확인합니다(K-Startup에 공고마다 양식이 붙습니다). 전략기획서에는 이런 표준 양식이 없습니다. 읽는 사람이 회사 안에 있어서 설득할 외부 심사 기준이 없기 때문입니다.

제안서에 섞인 사업계획서 언어가 깎아먹는 점수

처음 이야기로 돌아오면, 제안서 앞에 붙은 회사 연혁 스무 장이 왜 점수가 안 되는지가 여기서 설명됩니다. 그건 사업계획서의 팀 구성 항목에 들어갈 내용입니다. 투자자는 "이 팀이 해낼 수 있는가"를 보지만, 제안 평가위원은 "이 과업을 어떻게 수행할 것인가"를 봅니다.

실적을 넣지 말라는 뜻이 아닙니다. 같은 실적이라도 제안서에서는 이 과업과 같은 종류의 일을 해 봤다는 증거로 들어가야 배점에 걸립니다. 회사가 얼마나 성장했는지를 보여 주는 실적 나열은 사업계획서의 문법입니다.

반대 방향의 실수도 같은 뿌리입니다. 사업계획서를 제안서처럼 쓰면 수행 방법만 빼곡하고 "누가 왜 돈을 내는가"가 빠집니다.

문서가 아니라 입력으로 들어가는 벤치마킹

벤치마킹을 이 목록에 같이 놓는 경우가 있는데, 벤치마킹은 산출물이 아니라 재료입니다. 네 문서에 전부 들어가지만 각각 증명하는 것이 다릅니다.

전략기획서에서 벤치마킹은 그 시장이 실재한다는 근거입니다. 사업계획서에서는 규모를 추정하는 근거가 됩니다. 제안서에서는 성격이 완전히 바뀝니다. 경쟁사가 무엇을 하는지가 아니라 우리가 이런 일을 해 봤다는 증거로 들어가고, 이건 엄밀히 말해 벤치마킹이 아니라 레퍼런스입니다.

이 차이를 놓치면 제안서에 시장 분석이 들어갑니다. 발주처는 이미 자기 시장을 알고 있고, 알고 싶은 것은 우리가 그 과업을 해낼 수 있는지입니다.

한 가지 더 주의할 점이 있습니다. 벤치마킹은 남이 성공했다는 사실만 알려 줍니다. 그 회사가 성공했다는 것은 시장이 존재한다는 근거일 뿐, 우리가 그 시장에서 돈을 벌 수 있다는 근거가 아닙니다. 전략기획서가 벤치마킹만으로 채워지면 "왜 하필 우리인가"가 비어 있게 됩니다.

중소기업 고객에게는 제안요청서가 없다는 문제

앞의 구분은 발주 절차가 갖춰진 공공·대기업 기준입니다. 중소기업 대상 외주에서는 사정이 다릅니다. 제안요청서를 쓸 수 있는 고객이 드뭅니다. 무엇이 필요한지 말로는 설명하지만 그것을 항목으로 정리해 본 적이 없는 경우가 대부분입니다.

그러면 요구사항 정리를 수주 측이 대신하게 됩니다. 저는 이 상황 자체를 피하기는 어렵다고 봅니다. 문제는 그다음입니다. 우리가 정리한 요구사항으로 우리가 제안하면 검증 단계가 통째로 사라집니다. 법이 제44조로 지키려던 구조, 즉 발주자가 범위를 정하고 수주자가 거기에 답하는 구조가 한쪽으로 접혀 버립니다.

그래서 대신 정리해 준 요구사항을 고객의 언어로 되돌려 확인받는 절차를 따로 두는 편이 안전합니다. 우리 문서에 서명을 받는 것과, 고객이 그 내용을 자기 말로 다시 설명할 수 있는 것은 다릅니다. 후자까지 가야 나중에 "이건 우리가 말한 게 아니다"가 나오지 않습니다.

계약을 기준으로 갈리는 문서의 성격

마지막으로 경계를 하나 그어 두면 헷갈릴 일이 줄어듭니다. 지금까지 다룬 네 문서는 전부 "할까 말까"를 정하는 문서입니다. 계약 이전에 존재하고, 계약이 성사되면 역할이 끝납니다.

계약 이후에 나오는 요구사항 정의서, 화면설계서, 테스트 시나리오는 "어떻게 만들까"를 정하는 문서입니다. 이쪽은 SA 기획을 다룬 글에서 따로 짚었습니다.

SA 기획자가 두 구간에 다 걸쳐 있어서 섞이기 쉽습니다. 제안서에 화면설계서 수준의 상세를 넣으면 계약도 못 딴 일에 설계 공수를 미리 쓰는 셈이고, 반대로 계약 후 요구사항 정의서를 제안서 수준으로 두루뭉술하게 쓰면 범위 분쟁이 그 자리에서 시작됩니다. 문서마다 어느 구간의 물건인지 먼저 확인하면 이 두 실수는 대부분 피할 수 있습니다.