"제안서는 포장지이고 기획은 설계도입니다": Pre-sales와 실행 기획을 분리하여 프로젝트 적자를 막는 테크 리더십 가이드

📌 들어가는 글: 제안서만 들고 시작하는 프로젝트의 비극

"제안서에 이거 다 할 수 있다고 적어서 사업 따왔으니까, 개발팀이 알아서 만들어주세요."

IT 연관 사업이나 SI, 또는 신규 프로젝트 현장에서 너무나 흔하게 발생하는 풍경입니다. 화려한 비전과 추상적인 단어로 가득 찬 제안서 한 장이 그대로 개발팀의 '요구사항 명세서'로 둔갑하여 던져집니다.

결과는 어떨까요? 개발자는 무엇을 만들어야 할지 몰라 헤매고, 예외 케이스 정책이 없어 개발 도중 수시로 스펙이 바뀌며, 기술 검증 없이 약속한 단어 한 줄 때문에 공수가 3배로 늘어납니다. 결국 프로젝트는 지연되고, 야근은 늘어나며, 외주비 투입으로 회사의 프로젝트 이익률(손익)은 바닥을 치게 됩니다.

이 비극의 원인은 개발자의 실력 부족도, 제안 작성자의 무능함도 아닙니다. 바로 '사업을 따오는 영업(Pre-sales)'과 '사업을 실제로 완성하는 실행 기획(Execution Planning)'을 구분하지 못하고 '기획'이라는 단어 하나로 퉁쳐 부르기 때문입니다.

"기획자가 일을 안 한다"고 감정적으로 비판하는 대신, "이 둘을 분리하지 않으면 회사의 이익이 깨진다"는 비즈니스 관점으로 조직을 설득하는 프레임워크와 실무 개선 가이드를 정리해 드립니다.

📊 1. '제안(Pre-sales)'과 '기획(Execution)'의 명확한 차이

경영진과 팀원들에게 가장 먼저 선을 그어주어야 하는 것은 두 영역의 목적과 성격이 완전히 다르다는 점입니다.

🧩 Pre-sales vs Execution Planning 역할 비교표

제안서는 고객을 설득하기 위해 '무엇을 만들 수 있는지' 매력적으로 포장하는 영업용 가설입니다. 반면, 진짜 기획은 그것을 실제 코드로 옮기기 위한 시공 도면(설계도)입니다. 둘은 완전히 다른 영역의 역량을 요구합니다.

💼 2. 감정 싸움 없이 경영진을 설득하는 3가지 비즈니스 프레임

개발팀에서 "기획서가 부실해요"라고 항의하면, 조직에서는 단순한 '부서 간 밥그릇 싸움'이나 '개발자의 징징거림'으로 치부하기 쉽습니다. 회사를 설득하려면 프로젝트 손익과 리스크 논리로 접근해야 합니다.

① 손익 프레임: "제안서는 조감도(포장지)이고, 기획은 시공 도면(설계도)입니다"

💬 설득 논리:
"경영진님, 제안서는 건물을 팔기 위해 그리는 멋진 '조감도'입니다. 하지만 조감도만 가지고 공사를 시작하면 건물이 무너집니다. 실제 공사를 진행하려면 배관, 전기, 자재 사양이 적힌 '시공 도면(설계도)'이 필요합니다.
지금 우리 회사는 조감도만 던져주고 건설 현장(개발팀) 더러 알아서 건물을 지으라고 하는 격입니다. 이 과정에서 발생하는 수많은 재작업과 스펙 변경 때문에 프로젝트 이익률이 다 깎여 나가고 있습니다."

② 프로세스 프레임: "Pre-sales와 Delivery 역량은 완전히 분리되어야 합니다"

💬 설득 논리:
"제안서를 쓰는 영업/제안 단계(Pre-sales)와, 수주 후 이를 실제 제품으로 만드는 실행 단계(Delivery)는 사용하는 역량이 완전히 다릅니다. 제안서를 매력적으로 잘 쓰는 것과, 그 사업을 구체적인 요구사항으로 쪼개어 완성시키는 것은 별개의 전문 업무입니다.
두 역할을 명확히 구분하거나, 최소한 수주 후 제안서를 스펙으로 전환하는 '기획 정제 기간'을 공식적으로 가져야 합니다."

③ 리스크 프레임: "검증 없는 제안 한 줄이 개발 공수 폭탄으로 돌아옵니다"

💬 설득 논리:
"제안서 작성 시 기술적 검증 없이 던진 '단어 한 줄' 때문에 수주 후 개발 공수가 3배로 뛰는 현상이 반복되고 있습니다.
제안서를 쓸 때 기술적 실행 가능성(Feasibility)을 단 10분이라도 사전 검토하거나, 수주 후 세부 스펙으로 다듬는 안전장치를 두어야 일정 연장과 외주 비용 낭비(적자)를 방지할 수 있습니다."

🛠️ 3. 실무에 바로 적용하는 단계별 프로세스 개선안

당장 조직 개편을 할 수 없다면, 기존 업무 플로우에 안전장치(Gate)를 추가하는 방식으로 실무 체계를 전환해야 합니다.

🔄 프로세스 변화 도식

[ 기존의 잘못된 방식 ]
제안서 작성 (단어/비전) ───► (검증 없이 직행) ───► 개발팀 "알아서 만들어" ───► 일정/품질/손익 멸망

[ 개선된 프로세스 ]
제안서 작성 ───► [Gate 1: 수주 후 킥오프] ───► [Gate 2: 기획 정제 (Refinement)] ───► 개발 / 테스트 / 배포
 (Sales)          제안서 ↔ 요구사항 변환          추상적 단어 ➡️ 세부 Task/AC 변환      (DoD 준수)

1️⃣ '수주 후 기획 정제 주간(Refinement Period)' 공식화

사업이 수주되거나 프로젝트가 확정되면, 최소 1~2주는 '제안서를 실제 개발 가능한 요구사항으로 다듬는 정제 기간'으로 일정표에 공식 반영합니다.
이 기간 동안 제안서를 작성한 사람(또는 담당 실행 기획자)이 개발팀과 앉아 추상적인 단어들을 실제 유저 플로우, 예외 정책, 인수 조건(AC)으로 다듬어야 합니다.

2️⃣ 제안서 작성 시 '개발 사전 피드백 Window' 설치

제안서를 작성하는 도중 개발팀에게 "무조건 된다고 적어라"가 아니라, "이 기능 3달 안에 가능한 스펙 맞아?"라고 10분이라도 사전 검토를 받는 핫라인을 만듭니다. 이 짧은 검토만으로도 수천만 원 상당의 공수 폭탄을 사전에 차단할 수 있습니다.

3️⃣ R&R(역할과 책임) 명칭 명확화

회사가 '비즈니스 기획'이라는 명칭을 고수하더라도, 서류상 역할(Role)을 "사업 제안 (Pre-sales)"과 "프로덕트/서비스 기획 (Product Management)"으로 명확히 구분하여 R&R 문서에 올려놓아야 합니다.

💬 4. 테크 리더를 위한 실무 대화 스크립트

경영진이나 관련 팀과의 미팅에서 테크 리더로서 다음과 같이 대화의 물꼬를 터보시길 권장합니다.

🗣️ 추천 스크립트:
"우리 회사가 제안을 통해 사업을 잘 따오는 것은 매우 뛰어난 강점입니다.
다만, '사업을 따오는 기획(제안)'과 '그 사업을 적자 안 나게 완수하는 기획(실행)'은 완전히 다른 영역입니다.

지금처럼 제안서의 추상적인 언어가 그대로 개발팀에 전달되면, 완충 장치가 없어 개발 공수 산정이 불가능해지고 프로젝트마다 지연과 적자 리스크를 안게 됩니다.

제안 수주 직후 이를 실제 개발 스펙으로 전환하는 '기획 정제 단계(Refinement Period)'를 프로세스에 공식 추가하여 프로젝트 이익률을 지키고자 합니다."

🎯 맺음말

영업과 실행은 프로젝트의 양 날개입니다. 영업이 매출을 만들어낸다면, 실행 기획은 그 매출이 실제 '영업이익'으로 남도록 단단한 기초를 다지는 일입니다.

제안서와 기획서를 명확히 구분하고, 사이에 '기획 정제'라는 안전장치를 세우는 것만으로도 수많은 무의미한 야근과 재작업, 그리고 프로젝트 적자를 막아낼 수 있습니다.

오늘 우리의 프로젝트 프로세스를 점검해 보세요. 그리고 조직에 '설계도'를 만드는 정제 시간을 선언해 보시길 바랍니다.