창업 사업계획서 문제 정의: 관찰·발언·가설·해결을 나누는 5가지 기준
창업 사업계획서 문제 정의: 관찰·발언·가설·해결을 나누는 5가지 기준
사업계획서의 ‘문제 인식’은 제품 소개를 앞에 배치하는 칸이 아닙니다. 아직 확인하지 않은 고객 행동을 사실처럼 쓰거나, 해결책을 먼저 정한 뒤 문제를 끼워 맞추면 다음 장의 시장·제품·성장 계획도 흔들립니다. 이 글은 초기 창업팀이 관찰한 사실, 고객의 표현, 팀의 해석, 해결 가설, 검증 결과를 같은 문장에 섞지 않고 정리하는 방법을 다룹니다.
K-Startup 창업에듀는 창업준비 과정에서 아이디어 도출, 사업기회 포착, 아이템 개발 및 검증, 사업모델 구축, 사업계획서 작성을 별도 학습 주제로 안내합니다. 이는 특정 지원사업의 심사 기준이나 선정 결과를 뜻하지 않습니다. 다만 문제를 정의하고 해결책을 설계하는 일을 하나의 완결된 주장으로 묶지 않는 출발점으로 삼을 수 있습니다.
먼저 구분할 것: 관찰, 발언, 해석, 가설, 결과는 서로 다른 기록입니다
현장에서 확인한 화면 이탈, 문의 내용, 업무 처리 시간 같은 것은 관찰 기록입니다. 인터뷰에서 들은 문장은 고객 발언입니다. 그 둘을 보고 ‘이 때문에 결제를 포기한다’고 이해한 순간부터는 팀의 해석이 됩니다. 새 기능·서비스·운영 방식으로 이 문제를 줄일 수 있다는 문장은 가설이고, 실제 출시·실험 뒤의 값만 검증 결과입니다.
이 다섯 층을 분리하면 사업계획서가 약해지는 것이 아니라 검토 가능한 문서가 됩니다. 예를 들어 “고객이 반복 입력을 싫어해 자동화 기능이 필요하다”라는 한 문장에는 관찰·추정·해결책이 모두 들어 있습니다. 대신 어떤 화면에서 무엇을 봤는지, 고객이 실제로 어떤 표현을 했는지, 팀이 무엇을 원인으로 가정하는지, 무엇을 시험할지로 나눠야 다음 질문에 답할 수 있습니다.
기준 1: 문제는 제품명이 아니라 관찰 가능한 상황으로 시작합니다
‘AI 업무 도구가 필요하다’, ‘통합 플랫폼이 부족하다’처럼 범위가 큰 문장은 문제 정의보다 제품 범주에 가깝습니다. 처음에는 누가, 어느 업무에서, 어떤 제약 아래, 무엇을 완료하지 못했는지를 적습니다. 예시는 “신규 담당자가 동일한 서류의 최신 버전을 찾지 못해 확인 요청을 반복했다”처럼 사건 단위로 남기는 방식입니다. 이 예시는 특정 기업이나 고객의 사실이 아니라 기록 형식의 예시입니다.
관찰 문장에는 시간·인원·손실액을 억지로 넣지 않아도 됩니다. 아직 측정하지 않은 숫자를 만들어 넣기보다, 관찰의 출처와 범위를 표시하는 편이 낫습니다. 내부 상담 메모, 공개 문의, 사용성 테스트, 업무 동행처럼 출처를 쓰고, 한 번의 사례인지 반복해서 보였는지도 별도로 표시합니다. 사례 하나는 문제의 가능성을 보여줄 수 있어도 시장 전체의 증거가 되지는 않습니다.
기준 2: 고객 발언은 요약과 원문을 구분해 보관합니다
인터뷰 메모를 “고객은 간편함을 원했다”라고 요약하면 누가 어떤 조건에서 그렇게 말했는지 사라집니다. 원문을 모두 공개할 필요는 없지만, 문서 안에서는 발언의 맥락을 복원할 수 있어야 합니다. 대상자의 역할, 발생 상황, 말한 내용, 후속 질문, 팀의 요약을 따로 둡니다. 개인정보와 영업비밀은 제거하고, 동의 범위 밖의 녹음·계정 정보·연락처는 넣지 않습니다.
고객의 표현이 곧 요구사항이나 구매 의사라는 뜻도 아닙니다. 같은 불편을 말해도 직접 해결할 수 있는지, 다른 대안을 쓰는지, 지금 해결할 우선순위인지 확인이 필요합니다. K-Startup 창업에듀의 과정 목록에는 고객 공감, 고객 요구사항 정의, 수요 탐색, 고객분석과 목표고객 접근이 각각 포함되어 있습니다. 이를 한 번의 인터뷰 완료로 대체하지 말고, 무엇을 아직 모르는지 적는 체크포인트로 씁니다.
우리 사업계획서의 문제 가설과 검증 순서를 함께 정리하기
기준 3: 팀의 해석은 ‘사실’이 아니라 검증할 가설로 표시합니다
관찰과 발언을 읽고 원인을 해석하는 일은 필요합니다. 다만 “반복 문의가 많다”에서 “가격이 원인이다” 또는 “온보딩을 바꾸면 해결된다”로 바로 넘어가면 다른 설명을 잃기 쉽습니다. 원인을 하나로 확정하지 말고, 가능한 설명과 반증 조건을 함께 적습니다. 예를 들어 안내 문구를 바꿔도 동일한 단계에서 이탈이 계속되면 문구 가설은 약해진다는 식입니다.
가설에는 대상, 상황, 예상 변화, 관찰 방법을 포함합니다. ‘기능을 만들면 좋아질 것’보다 ‘특정 단계에서 안내 순서를 바꿨을 때 사용자가 다음 단계로 넘어가는지 관찰한다’가 검증 가능한 문장입니다. 하지만 이 문장도 결과가 아닙니다. 실험 전에는 가설, 실행 중에는 관찰 중, 종료 뒤에는 조건과 한계가 포함된 결과로 상태를 바꿉니다.
기준 4: 해결책은 문제 증거와 별도의 선택지로 비교합니다
문제가 보였다고 해서 앱 개발이 유일한 답은 아닙니다. 안내 문서, 운영 절차, 템플릿, 수동 지원, 기존 도구 연결, 기능 개발은 서로 다른 비용과 검증 범위를 가집니다. 해결책 장에서는 각 선택지가 어떤 문제 가설을 겨냥하는지, 지금 만들지 않는 것은 무엇인지, 확인 뒤 무엇을 바꿀지를 명확히 합니다. 이렇게 하면 ‘서비스를 만들었다’는 사실과 ‘문제가 해결됐다’는 판단을 분리할 수 있습니다.
기존 공개 글 창업 사업계획서 제품 로드맵은 확정 범위·가설·의존성·관찰 순서를 제품 계획에 연결하는 글입니다. 이번 글은 그보다 앞 단계인 문제 기록에 집중합니다. 로드맵이 일정표를 정리한다면, 문제 정의는 그 일정표가 검증하려는 질문을 정리합니다.
기준 5: 검증 결과는 성공 문구가 아니라 다음 결정으로 남깁니다
소수의 피드백, 클릭, 문의가 있었다고 제품 적합성이나 매출 가능성을 단정할 수는 없습니다. 결과 기록에는 대상·기간·조건·관찰값·누락·다음 결정을 함께 둡니다. 같은 결과라도 대상이 바뀌거나 안내 방식이 달라지면 비교 기준이 달라질 수 있습니다. 그래서 좋은 결과만 남기기보다 예상과 달랐던 경우, 응답을 받지 못한 경우, 측정 자체가 불완전했던 경우를 같은 형식으로 적는 편이 다음 의사결정에 더 유용합니다.
사업계획서에는 확정 사실과 검증할 항목을 다른 문장으로 씁니다. 확인된 정보는 출처를 붙이고, 팀이 제안하는 해결 방향은 가설이라고 표시하며, 아직 없는 성과·지원금·선정 결과는 쓰지 않습니다. 각 사업 공고의 자격·일정·제출 기준은 이 일반 글이 아니라 해당 공고 원문에서 다시 확인해야 합니다.
작성 전 10분 점검표
문제 문장이 제품명이나 기능명이 아니라 특정 상황에서 시작하는가?
관찰 사실, 고객 발언, 팀의 해석을 서로 다른 필드로 보관하는가?
한 사례를 시장 전체 또는 일반 고객의 증거처럼 확대하지 않았는가?
원인 가설마다 틀렸음을 알 수 있는 관찰 조건이 있는가?
해결책이 하나뿐이라고 가정하지 않고 운영·도구·기능 대안을 비교했는가?
실행 전 가설과 실행 뒤 결과를 같은 성과 문구로 섞지 않았는가?
지원사업의 자격·선정·금액·일정은 해당 공고 원문에서 별도로 확인할 계획인가?
문제 정의는 설득을 위해 불확실성을 지우는 작업이 아닙니다. 확인한 것과 아직 확인할 것을 분리해, 다음 실험과 제품 선택을 더 구체적으로 만드는 작업입니다. 이 기준을 두면 사업계획서의 해결방안도 과장된 약속 대신 검토 가능한 실행 계획으로 연결할 수 있습니다.
자주 묻는 질문
인터뷰를 몇 명 해야 문제를 확정할 수 있나요?
이 글은 특정 인원 기준을 제시하지 않습니다. 인터뷰 수만으로 문제나 수요를 확정할 수는 없으며, 누구에게 어떤 조건에서 들은 내용인지와 다른 관찰 자료를 함께 봐야 합니다.
사업계획서에 가설이라고 쓰면 약해 보이지 않나요?
확인되지 않은 내용을 사실처럼 쓰는 것보다, 검증 대상·관찰 방법·다음 결정을 명확히 쓰는 편이 문서의 판단 근거를 보여 줍니다. 다만 개별 공고의 작성 양식과 평가 기준은 반드시 해당 공고 원문을 확인해야 합니다.
고객 발언을 그대로 넣어도 되나요?
개인정보·영업비밀·동의 범위를 먼저 확인해야 합니다. 공개할 수 없는 발언은 식별 정보를 제거한 요약으로 처리하고, 요약과 팀의 해석을 구분하는 것이 좋습니다.
해결책을 먼저 만들었다면 문제 정의를 다시 써야 하나요?
이미 만든 해결책을 유지할지 판단하려면, 그 해결책이 겨냥하는 상황과 가설을 뒤늦게라도 분리해 기록할 수 있습니다. 결과를 미리 정하지 말고 실제 관찰 뒤의 다음 결정을 남기세요.
출처
K-Startup 창업에듀, 창업준비·사업계획서 관련 과정 목록 (2026-09-20 확인)
K-Startup 창업에듀, 창업준비·아이템 개발 및 검증·사업계획서 작성 과정 안내 (2026-09-20 확인)
발행일: 2026-09-20 · 작성: 유인어스 정책자금·정부지원사업 인사이트