사업계획서를 새로 쓰고 계신가요 — 이미 만든 것을 잇는 법

공고 마감이 일주일 남았습니다. 사업계획서를 열어놓고 처음부터 쓰고 있습니다.

그런데 지난 몇 달 동안 만든 게 적지 않습니다. 고객 정의도 해봤고, 화면도 그려봤고, 인터뷰도 했습니다. 파일은 다 있습니다.

그런데 사업계획서에는 그중 무엇도 그대로 안 들어갑니다. 결국 새로 씁니다.

왜 다시 쓰게 되는가

산출물이 없어서가 아닙니다. 산출물끼리 서로를 근거로 삼고 있지 않아서입니다.

• 페르소나 문서에는 고객이 어떤 사람인지 적혀 있습니다.
• 기능 목록에는 무엇을 만들지 적혀 있습니다.
• 그런데 그 고객이라서 이 기능이 먼저다라는 연결은 어디에도 안 적혀 있습니다.

각각은 잘 만들었는데 따로 놉니다. 그래서 사업계획서에 옮기려고 하면, 옮기는 게 아니라 그 자리에서 논리를 새로 만들게 됩니다. 시간이 걸리는 건 문서 작성이 아니라 없던 연결을 급하게 만드는 일입니다.

심사위원이 묻는 건 끊어진 자리입니다

발표 자리에서 나오는 질문은 대체로 정해져 있습니다.

"이 기능은 어디서 나온 건가요?"
"이 고객이 정말 이걸 필요로 하나요?"
"왜 이걸 먼저 만드시나요?"

세 질문 다 같은 걸 묻고 있습니다. 앞 단계와 뒤 단계 사이가 이어져 있느냐입니다.

기능이 많아도 설득이 안 되는 경우가 여기서 생깁니다. 기능 자체가 부족한 게 아니라, 그 기능이 어디서 나왔는지가 문서에 없어서입니다.

한 줄로 이어보기

만든 것들 사이에 이 문장을 넣어보시면 끊어진 자리가 보입니다.

"○○이기 때문에 △△을 만든다."

전체를 이으면 이런 사슬이 됩니다.

1. 고객이 이런 상황이고 — (고객 정의)
2. 그 상황에서 여기서 막히는데 — (여정·문제 정의)
3. 실제로 막히는지 확인해봤고 — (인터뷰·검증)
4. 그래서 이걸 먼저 만들고 — (기능 우선순위)
5. 이렇게 만든다 — (화면·요구사항)

한 칸씩 "그래서"로 넘어가는지 읽어보시면 됩니다. "그래서"가 안 붙는 자리가 끊어진 자리입니다.

자주 끊어지는 자리 중 하나가 3번과 4번 사이입니다. 인터뷰는 했는데 그 결과가 기능 우선순위를 바꾸지 않은 경우입니다. 이러면 4번은 인터뷰 전에 이미 정해져 있던 것이고, 3번은 뒤에 붙인 장식이 됩니다. 심사에서 이 지점이 잘 드러납니다.

사업계획서는 이 사슬을 형식만 바꾼 것입니다

여러 사업계획서 양식이 이 순서와 크게 다르지 않습니다. 이름만 다릅니다.

• 문제 인식 ← 1번 + 2번 (고객이 이런 상황이고, 여기서 막힌다)
• 실현 가능성 / 근거 ← 3번 (확인해봤다)
• 개발 계획 / 우선순위 ← 4번 (그래서 이걸 먼저 만든다)
• 제품 개요 ← 5번 (이렇게 만든다)
• 시장·경쟁 ← 1번의 확장 (이런 고객이 얼마나 있나)

사슬이 이어져 있으면 옮기는 작업이 됩니다. 안 이어져 있으면 쓰는 작업이 되고, 그래서 오래 걸립니다.

제안서도 구조가 비슷합니다. 받는 사람이 심사위원에서 고객사로 바뀔 뿐, "왜 이걸 이 순서로 하는가"를 묻는 건 같습니다.

안 이어지는 칸이 알려주는 것

사슬을 그려보면 빈칸이 나옵니다. 빈칸을 급하게 채우기 전에, 그 빈칸이 어떤 종류인지 한 번 보시면 좋습니다.

• 1→2가 안 이어짐 — 고객은 정했는데 그 고객의 문제가 아니라 내가 아는 문제를 적어둔 경우입니다.
• 2→3이 안 이어짐 — 문제를 정의했는데 확인은 안 한 경우입니다. 지금 할 수 있는 가장 작은 확인이 무엇인지 정하면 됩니다.
• 3→4가 안 이어짐 — 확인 결과가 우선순위에 반영되지 않은 경우입니다. 확인해서 알게 된 것 중 계획을 바꾼 것이 하나라도 있는지 보시면 됩니다.
• 4→5가 안 이어짐 — 우선순위는 정했는데 만들 것의 범위가 안 정해진 경우입니다.

빈칸은 문서의 결함이 아니라 아직 안 한 일의 목록에 가깝습니다. 이걸 알고 마감을 맞는 것과 모르고 맞는 것은 다릅니다.

AI에게 시킬 때

이미 만든 파일들을 넣고 "사업계획서 써줘"라고 하면, AI는 빈 곳을 그럴듯한 문장으로 메웁니다. 사슬이 끊어진 자리도 매끄럽게 연결된 것처럼 써집니다. 읽을 때는 좋아 보이는데, 질문이 들어오면 그 자리에서 막힙니다.

이렇게 요청하시면 다르게 나옵니다.

"이 문서들을 읽고, 각 기능이 어느 고객 문제에서 나왔는지 연결해줘. 문서에서 근거를 못 찾은 기능은 '근거 없음'이라고 표시하고 지어내지 마."

'근거 없음' 표시가 많이 나오는 게 나쁜 결과가 아닙니다. 그 목록이 발표 전에 채워야 할 것입니다.

오늘 한 가지만 한다면

지금 만들고 있는 기능 중 하나만 골라, 위로 거슬러 올라가 보세요.

이 기능 ← 왜? ← 어떤 문제 때문에 ← 그 문제는 누가 겪나 ← 그걸 어떻게 확인했나

네 번 안에 확인한 사실까지 닿으면 그 기능은 사업계획서에 쓸 수 있습니다. 중간에서 끊기면, 끊긴 그 자리가 지금 채워야 할 칸입니다.

---

만든 자료는 있는데 하나로 안 이어진다면
2분 진단으로 지금 먼저 손댈 과제 하나와 2주 파일럿 시작안, 사람이 꼭 확인해야 할 리스크를 정리해서 보실 수 있습니다. 편하신 만큼만 답하셔도 괜찮습니다.

STAR-T AI 사업 운영 진단 →

---

각주

① 참고자료·확인일
이 글은 외부 통계·연구를 인용하지 않습니다. 근거는 예비 창업자 개인 컨설팅 500건 이상 누적(이력 SSOT 기준)입니다. 본문에 수치는 사용하지 않았습니다. 확인일 2026-08-06.

② 안 쓴 수치
"사업계획서 통과율", "지원사업 선정률" 같은 수치는 쓰지 않았습니다. 저희가 측정한 값이 아니고, 공고·분야마다 편차가 커서 일반화할 수 없기 때문입니다. 저희 강의·컨설팅 만족도나 실적 수치, 사내 설문·CS 응답의 수치나 직접 인용도 이 글에서는 사용하지 않았습니다.

③ 만든 방식
AI로 초안을 만들고 사람이 검증·편집했습니다. 발행 전 사실·톤·법무 3개 검수를 거쳤습니다.