> ## Content Index
> Fetch the complete content index at: https://www.sharehows.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# 제안서 첫 문장을 고객이 윗사람 앞에서 그대로 말하게 하라, 20년 마케터의 문제 정의법
- URL: https://www.sharehows.com/jeanseo-ceos-munjangeul-gogaegi-wissaram-apeseo-geudaero-malhage-hara-20nyeon-maketeoyi-munje-jeongyibeob/
- Published: 2026-10-26T04:29:59.000Z
- Updated: 2026-10-26T04:29:59.000Z
- Description: 고객 담당자는 제안서를 들고 윗사람에게 간다. 그때 할 첫마디가 문제 정의 한 문장이다. 현상·원인·영향으로 좁히고, 모르는 것은 [추정]으로, 기준값 없는 효과 숫자는 쓰지 않는 법을 정리했다.
- Author: 김재원

지난 9월에 만든 기업용 제안서 최종본 20쪽을 심사위원 기준으로 다시 채점했다. 내 제안서라 점수를 박하게 줬다. 디자인은 끝까지 한 틀로 갔다. 3쪽은 회사 소개가 아니라 고객 문제 셋으로 열었다. 여기까지는 괜찮았다.

점수가 가장 낮게 나온 항목은 제안 목적이었다. 이 고객에게 무엇이 얼마나 달라지는지가 어디에도 없었다. 4쪽 숫자는 시장 숫자였다. 19쪽 KPI 표에는 지금 값도 목표 값도 비어 있었다. 고객 문제를 셋이나 적었는데, 고객 담당자가 윗사람에게 "이래서 검토해야 합니다"라고 말할 한 문장은 없었다.

## 담당자에게는 첫마디가 필요하다

지난 편에서 제안서는 우리가 없는 회의실에서 읽힌다고 썼다. 그 회의실에서 담당자가 가장 먼저 하는 말은 정해져 있다. "이런 문제가 있어서, 이런 회사에서 이런 제안이 왔습니다." 문제 정의 한 문장은 그 첫마디다.

그래서 문제 정의의 주인은 우리가 아니다. 담당자가 입으로 옮길 수 있어야 한다. 소리 내어 읽었을 때 담당자의 말투로 들리지 않으면 실패한 문장이다. 나는 문장을 고른 뒤 담당자가 팀장 책상 앞에서 그 말을 하는 장면을 떠올려 본다. 어색하면 고친다.

## 첫 번째 착각: 문제는 크게 잡아야 무게가 실린다

제안서에서 가장 흔한 문제 정의는 이런 모양이다. "귀사는 스마트 팩토리 전환에 뒤처져 경쟁력이 떨어지고 있습니다." 거창하다. 그래서 쓸모가 없다.

이 문장에는 고객이 한 말이 하나도 없다. 원인도 영향도 우리가 지어냈다. "디지털 전환"이나 "경쟁력"은 담당자 한 사람이 책임질 수 없는 크기다. 담당자가 이 말을 들고 들어가면 팀장은 "그래서 우리 공장에 뭐가 문제라는 건데"라고 되묻는다. 문제를 크게 잡을수록 제안은 가벼워진다. 무게는 크기가 아니라 구체성에서 나온다.

하나 더 있다. 제안서 한 건에 문제 정의는 하나만 둔다. 내 제안서가 문제 셋으로 열고도 목적이 약했던 이유가 여기 있다. 셋을 나란히 놓으면 담당자는 무엇을 먼저 말할지 고르지 못한다. 나머지 문제는 본문에서 다루면 된다.

## 현상·원인·영향, 세 조각을 한 문장에

문장을 좁힐 때는 틀을 쓴다. 현상, 원인, 영향을 한 문장에 잇는다.

- 현상: 고객이 겪는 일. 고객이 한 말로 쓴다.
- 원인: 그 일이 생기는 까닭. 확인한 것과 추정을 나눈다.
- 영향: 그 일이 회사에 주는 손해나 부담. 확인한 것만 숫자로 쓴다.

![문제 정의의 세 조각: 현상은 고객의 말로, 원인은 확인과 추정을 나눠, 영향은 확인된 것만 숫자로](https://www.sharehows.com/content/images/2026/10/figure01-5.png)

책의 가상 회사 M사는 공장에 진동 센서를 파는 회사다. 고객사 K사 팀장은 "돌발 정지 때문에 야간조가 자주 멈춘다"고 했다. M사가 고른 문장은 이렇다. "야간조 설비가 예고 없이 멈추고, 고장 전 징후를 볼 수단이 없어, 원청 납기와 점검 기록 요구에 대응하기 어렵습니다." 60자 안팎이다. 담당자가 숨 한 번에 말할 수 있다.

![나쁜 문제 정의와 좋은 문제 정의 비교: 스마트 팩토리 전환에 뒤처져 대 야간조 설비가 예고 없이 멈추고](https://www.sharehows.com/content/images/2026/10/figure02-5.png)

이 문장은 AI에게 한 번에 받지 않는다. 후보 세 개를 받아 고른다. 세 후보는 강조점이 달라야 한다. 현장 부담, 납기, 원청 요구처럼 갈래를 나눠 두면 담당자가 어느 쪽 이야기를 하고 싶은지 대화에서 드러난다. 지시문은 이렇게 쓴다.

> \[고객이 한 말을 정리한 표\] \[고객 조사 한 장\]  
> 고객사의 문제 정의 문장 후보 세 개를 만든다.  
> 각 후보는 현상, 원인, 영향을 한 문장에 담는다. 60자 안팎.  
> 규칙:  
> \- 현상은 고객이 한 말에서만 가져온다. 원문의 핵심 단어를 살린다.  
> \- 원인과 영향 가운데 고객 자료나 공개 자료로 확인되지 않은 부분은 \[추정\]을 붙인다.  
> \- 우리 제품 이름, 우리 기능 이름을 넣지 않는다.  
> \- 각 후보 아래에 \[추정\]을 확인할 질문을 하나씩 적는다.  
> \- 세 후보는 서로 강조점이 달라야 한다.

## 두 번째 착각: 문제 정의에 우리 제품이 보여야 한다

영업을 오래 한 사람일수록 문제와 해법을 한 문장에 넣고 싶어 한다. "실시간 설비 모니터링 체계가 없어 손실이 생깁니다." 읽는 순간 답이 보인다. 그래서 좋은 문장이라고 착각한다.

나는 반대로 본다. 문제 정의에 우리 제품이 비치면 담당자는 그 문장을 사내에서 쓰기 어렵다. "센서가 없어서 문제"라고 말하는 순간 담당자는 업체를 대변하는 사람이 된다. 결재 라인은 그 냄새를 금방 맡는다. 문제 정의는 고객의 문장이고, 해법은 다음 쪽에 있어도 늦지 않다. 문제를 우리 제품 모양으로 깎으면 고객은 문제가 아니라 영업을 읽는다.

## 모르는 것은 \[추정\]이라고 쓴다

원인과 영향에는 확인하지 못한 부분이 꼭 남는다. 그 자리에 \[추정\]을 붙인다. 보내기 전까지 \[추정\]을 질문으로 바꿔 확인한다. 확인하지 못한 채 보내야 하면 제안서에도 "확인이 필요한 부분"이라고 밝힌다. 고객이 틀린 추정 하나를 발견하면 나머지 문장까지 의심한다.

M사도 1차 미팅 전에는 "원청 점검 기록 요구"에 \[추정\]을 달아 두었다. 미팅에서 팀장이 작년 원청 감사 이야기를 꺼냈고, 그때 \[추정\]을 뗐다. 질문 하나가 문장 한 조각을 사실로 바꿨다.

질문은 고객이 답하기 쉬워야 한다. 닐 라컴의 『SPIN Selling』은 상담 질문을 상황, 문제, 시사, 필요 확인의 네 갈래로 나눈다. 제안서를 준비할 때는 뒤의 두 갈래가 특히 쓸모 있다. 문제가 회사에 주는 영향, 풀렸을 때 달라지는 것을 고객 입으로 듣는 질문이다. 한 질문에는 한 가지만 묻는다. 고객이 답을 모를 법하면 "대략이라도 괜찮습니다"를 붙인다. "센서가 있으면 편하시겠죠?"처럼 우리 제품을 암시하는 질문은 바꾼다.

## 기준값이 없으면 효과 숫자를 쓰지 않는다

문제 정의가 서면 목적의 나머지 절반이 남는다. 풀리면 무엇이 얼마나 달라지는가. 결재권자가 가장 먼저 옮겨 적는 줄이고, 그만큼 가장 먼저 의심받는 줄이다. 가정과 근거 없는 "○○% 개선"은 심사에서 가장 먼저 질문을 받는다.

그래서 효과 숫자에는 네 가지를 함께 붙인다. 지금 값, 바뀐 뒤 값, 가정, 근거다. 바뀐 뒤 값은 한 값이 아니라 범위로 쓴다. "40% 절감"보다 "월 2\~4회에서 월 1\~2회로(가정: 센서를 붙인 설비 10대, 야간조 기준)"가 사내 보고에서 덜 공격받는다. 정지 1시간당 손실처럼 돈으로 바꾸는 계산은 고객이 준 단가로만 한다. 우리가 단가를 지어 넣으면 그 한 줄 때문에 나머지 숫자까지 의심받는다.

![효과 숫자에 붙이는 네 칸: 지금 값, 바뀐 뒤 값, 가정, 근거 — 가상 사례 M사의 실제 기입 예](https://www.sharehows.com/content/images/2026/10/figure03-5.png)

여기서 많은 사람이 멈칫한다. 고객이 지금 값을 모르면 어떻게 하나. M사도 그랬다. 돌발 정지 횟수는 미팅에서도 답을 듣지 못했다. 팀장은 "정확한 건 기록을 봐야 한다"고 했다. M사는 숫자를 추정해 넣지 않았다. 대신 "돌발 정지 횟수와 정지 시간은 시범 도입 첫 달에 함께 기록합니다"라고 썼다. 목표 범위는 기준값이 나온 뒤 고객과 함께 정한다고 적었다.

숫자를 약속하지 않은 제안서가 약해 보이는가. 내 판단은 반대다. 무엇을 언제 재서 성공을 판단할지가 분명하면 그것도 숫자로 말하는 목적이다. 심사위원이 보는 것은 숫자의 크기보다 그 숫자를 믿을 수 있는가다. 내 제안서 19쪽에 필요했던 것도 큰 숫자가 아니었다. "지금 값은 진단 1주차에 재고, 목표 범위는 그때 고객과 함께 정한다" 한 줄이었다.

![문제 정의의 흔한 실수 네 가지와 고친 방향: 크게 정의, 숫자 지어 넣기, 문제 정의 여러 개, 효과를 한 값으로](https://www.sharehows.com/content/images/2026/10/figure04-5.png)

## 이번 주에 해 볼 다섯 가지

1. 진행 중인 제안서의 첫 문단을 소리 내어 읽는다. 고객 담당자의 말투로 들리지 않으면 다시 쓴다.
2. 문제 정의가 여러 개면 하나만 남긴다. 나머지는 본문으로 내린다.
3. 그 문장에서 우리 제품 이름과 기능 이름을 지운다.
4. 확인하지 못한 조각에 \[추정\]을 붙이고, 조각마다 고객에게 물을 질문을 하나씩 만든다. 다섯 개를 넘기지 않는다.
5. 효과 숫자마다 지금 값, 바뀐 뒤 값, 가정, 근거를 붙인다. 지금 값이 없으면 숫자를 지우고 언제 무엇을 잴지를 쓴다.

## 한 문장이 해 주지 않는 것

좋은 문제 정의 한 문장이 수주를 정하지는 않는다. 고객이 아직 문제를 느끼지 않는다면 이 문장은 공허하다. 그럴 때는 문장을 다듬기보다 고객을 한 번 더 만나는 편이 낫다. 기준값을 첫 달에 재자는 제안도 고객이 시범 도입에 동의해야 의미가 있다. 이 방법은 판정할 기준을 줄 뿐, 결재를 대신 받아 주지 않는다.

그래도 순서는 바뀌지 않는다. 쪽을 늘리기 전에, 디자인을 고르기 전에, 담당자가 윗사람 앞에서 할 첫마디부터 정한다. 그 한 문장이 서면 제안서의 나머지 쪽은 그 문장을 받치는 근거가 된다.

## 이 글의 바탕이 된 책

이 글은 《고객의 말로 쓰는 제안서》 4장 「문제 정의: 한 문장과 확인 질문」과 실전 사례를 바탕으로 썼다. 책은 0장부터 12장까지 자료 출처대장, 고객 조사, 세 열 연결표, 문제 정의, 한 쪽 요약, 가격과 다음 단계, 검수를 순서대로 따라 하게 짰다. 그대로 복사해 쓰는 AI 지시문 28개와 워크시트 양식, 실제 기업용 제안서를 12판까지 고친 기록을 함께 실었다. 책 속 M사와 K사는 가상 사례다. 이 책은 수주를 보장하지 않는다.

제안서 연재 다음 편에서는 고객이 사내 회의에서 대신 설명하게 만드는 한 쪽 요약을 다룬다.

[《고객의 말로 쓰는 제안서》 자세히 보기](https://www.latpeed.com/products/p-Z0J?utm%5Fsource=sharehows&utm%5Fmedium=column&utm%5Fcampaign=proposal%5Fseries&utm%5Fcontent=%EC%A0%9C%EC%95%88%EC%84%9C%5Fep2)