웹 제작사 제안서와 상담 시트를 Claude Code로 절반 시간에 끝내기

금요일 저녁, 다음 주 월요일에 경쟁 PT가 잡혔습니다. 요건은 슬랙에 파편처럼만 남아 있고, 영업이 상담하며 적은 메모는 구글 문서 세 개에 흩어져 있는데 그마저도 목록 중간에서 끊겨 있습니다.

저는 이 상태에서 혼자 야근하며 제안서를 조립하곤 했습니다. 표지, 과제 정리, 사이트맵 안, 일정, 견적 전제 조건까지. 새벽 2시, 겨우 완성한 제안서를 다시 보니 상담에서 분명히 들었던 “채용 강화가 이번 분기 최우선”이라는 한마디가 어디에도 반영돼 있지 않았습니다. 들었는데 옮기지 못한 겁니다.

웹 제작사 디렉터라면 이 “들었는데 흘려보내는” 감각이 익숙할 겁니다. 제안서와 상담 시트는 만드는 수가 많은데도 매번 백지에서 다시 쓰는 사람이 많습니다. 이 부분을 생성형 AI에 맡기면, 비는 시간을 “제안의 내용을 다듬는” 쪽으로 돌릴 수 있습니다. 오늘은 그 구체적인 방법을, 복사해서 바로 쓸 수 있는 프롬프트와 검증 스크립트와 함께 적어 보겠습니다.

핵심 요약

제안서와 상담 시트는 “형식이 정해진 문서”라서 Claude Code 같은 생성형 AI와 잘 맞습니다. 초안의 70%는 맡길 수 있습니다.
맡기는 것은 “흩어진 정보의 정리”와 “형식에 흘려 넣는 초안”입니다. 제안 전략과 견적 금액의 최종 판단은 사람이 합니다. 여기를 섞으면 사고가 납니다.
상담 메모를 건네 제안서 뼈대를 잡게 하면, 제 손에서는 1건당 90분이 40분 안팎으로 줄었습니다.
클라이언트의 회사명과 개인정보를 학습에 쓰이지 않게 하는 설정, 정보를 건네는 방식에는 주의가 필요합니다. 뒤에서 체크리스트로 정리했습니다.
복사해서 쓰는 프롬프트 템플릿, 상담 시트 마크다운 템플릿, 제안서 누락을 기계적으로 점검하는 검증 스크립트를 실었습니다.

독자상: 어떤 웹 제작사 디렉터에게 효과가 있나

상정하는 건 이런 처지의 사람입니다. 직원 5~~30명 정도의 제작사에서 디렉터가 영업까지 겸하고 있다. 월에 2~~5건의 제안을 내고, 경쟁 PT와 상호 견적도 많다. 디자이너나 개발자는 따로 있지만, 상담과 제안서 작성은 디렉터 한 명에게 몰려 있다.

이 처지의 고민은 대개 비슷합니다. 제안의 내용으로 승부하고 싶은데 문서를 다듬는 작업에 시간을 빼앗긴다. 상담은 분위기가 좋았는데 메모가 파편적이라 나중에 재현이 안 된다. 템플릿은 있지만 건마다 조금씩 달라서 결국 손으로 고친다.

생성형 AI가 효과를 내는 건 바로 이 “다듬는 작업” 부분입니다. 제안의 발상 자체를 AI에 통째로 던지는 게 아닙니다.

웹 제작사의 업무 흐름과, 어디서 시간이 녹는가

제안까지의 흐름을 나열하면 시간이 녹는 지점이 보입니다.

문의 접수와 1차 회신
상담(대면·온라인)에서 메모 작성
메모를 정리해 요건을 정리
사이트맵·와이어프레임 방향성 결정
일정과 개략 견적 구성
제안서(슬라이드 또는 문서)로 정리
사내 검토 후 제출

이 중 3번과 6번이 가장 큰 병목입니다. 상담 메모는 날것 그대로는 못 쓰니 정리에 시간이 걸립니다. 제안서는 매번 비슷한 구성인데도 건마다 정보를 손으로 흘려 넣다 보니 다시 돌아오는 일이 잦습니다.

제 감각으로는 1건당 제안서 작성만으로 90~~120분. 월 3건이면 그것만으로 5~~6시간이 “문서 정형”에 사라지고 있었습니다.

자주 생기는 재작업과 곤란한 일

실제로 저지른 것들을 솔직히 늘어놓습니다.

상담 누락. 예산 감각과 공개 희망일을 빠뜨려 묻지 못하고, 제안서를 낸 뒤 “예산 초과입니다”라는 말을 듣고 다시 만들었습니다.
메모 해석 어긋남. “모바일 대응하고 싶다”가 반응형 대응인지 전용 앱인지 애매한 채로 제안해, 견적이 두 배 어긋났습니다.
템플릿 재사용 실수. 이전 건의 회사명이 표지에 남은 채로 제출할 뻔했습니다. 이건 정말 식은땀이 납니다.
제안서 누락. 유지보수 비용 기재를 잊어, 수주 후 “월정액은 못 들었다”며 분쟁이 됐습니다.

이런 일의 대부분은 “정해진 항목을 매번 빠짐없이 채우기”만으로 막을 수 있습니다. 사람이 매번 손으로 하면 빠집니다. 그러니 기계에 지키게 합니다.

도입 전과 도입 후, 무엇이 달라졌나

비포·애프터를 표로 정리합니다.

항목	도입 전	도입 후
상담 메모 정리	손으로 30분 들여 정서	AI가 5분에 구조화, 사람이 확인
제안서 뼈대 작성	백지에서 60분	템플릿에 흘려 넣어 20분
누락 점검	기억에 의존	검증 스크립트로 자동 점검
표지 회사명 실수	가끔 발생	템플릿 변수화로 거의 0
1건당 합계	90~120분	40~60분

전략을 생각하는 시간은 줄지 않습니다. 줄어드는 건 “정형과 확인” 시간뿐입니다. 거기가 바로 자동화하고 싶던 부분이라, 저에게는 노린 그대로였습니다.

Use case 1: 상담 메모에서 제안서 뼈대를 잡기

가장 효과가 큰 게 이겁니다. 상담 직후의 날것 메모를 건네, 제안서 목차에 맞춘 초안을 잡게 합니다.

Claude Code라면 상담 메모 텍스트 파일을 프로젝트에 두고 그대로 읽힐 수 있습니다. 복사해서 붙여 넣어도 되지만, 파일을 직접 읽히는 쪽이 옮겨 적는 실수를 줄여 줍니다.

아래 프롬프트를 템플릿으로 사용하세요.

당신은 웹 제작사 디렉터의 보조 역할입니다.
첨부한 상담 메모를 읽고, 아래 목차로 제안서 초안을 작성하세요.

# 목차
1. 고객의 현재 과제(메모에서 읽어낼 수 있는 범위로. 추측은 "추측"이라고 명시)
2. 본 프로젝트의 목표
3. 예상 사이트맵(주요 페이지만)
4. 진행 방식과 대략적인 일정
5. 개략 전제 조건(금액은 쓰지 말고, 견적에 필요한 전제만 목록으로)

# 지킬 것
- 메모에 없는 것은 지어내지 않는다. 부족한 부분은 "확인 필요"로 끝에 모은다
- 전문 용어는 클라이언트가 읽는다는 전제로 쉽게 바꿔 쓴다
- 단정하지 말고, 제안의 초안으로 작성한다

핵심은 “메모에 없는 건 지어내지 못하게” 묶는 것입니다. AI는 빈칸을 채우고 싶어 하므로, 내버려 두면 존재하지 않는 요건을 멋대로 만듭니다. “확인 필요”로 몰아내게 하면, 상담 누락이 그대로 눈에 보입니다.

Use case 2: 상담 시트 자체를 건마다 최적화하기

상담 시트는 고정 질문지를 돌려쓰기 쉽지만, 업종이나 건의 규모에 따라 물어야 할 것이 달라집니다. 채용 사이트와 쇼핑몰은 묻는 순서도 내용도 다릅니다.

그래서 건의 개요를 건네 질문지를 다시 짜게 합니다.

다음 건을 위한 첫 상담 질문 목록을 만들어 주세요.

# 건 개요
- 업종: 치과 클리닉
- 목적: 신규 환자 예약 증가
- 규모: 10페이지 정도의 기업 사이트 + 예약 동선

# 출력 형식
- "반드시 묻는 질문"과 "가능하면 묻는 질문"으로 나눈다
- 각 질문에, 왜 묻는지(제안·견적의 어디에 영향을 주는지)를 한마디 덧붙인다
- 예산·공개 희망일·기존 사이트 유무·사진 소재 준비는 반드시 포함한다

“왜 묻는지”를 덧붙이게 하면, 상담 당일에 디렉터 본인의 이해도 깊어집니다. 신입 디렉터 교육에도 쓸 수 있었습니다.

Use case 3: 여러 메모 통합과 제안서 체재 점검

영업·디렉터·고객 측 이메일처럼 정보가 여러 군데 흩어져 있을 때, 이를 한 장으로 통합하게 합니다. 아래 체크리스트를 제안서 최종 확인에 사용하세요.

표지의 회사명·건명이 이번 것으로 되어 있는가
예산 감각, 또는 견적의 전제가 적혀 있는가
공개 희망일과 일정에 모순이 없는가
유지보수·운용 비용의 처리가 명시돼 있는가
사이트맵과 견적 페이지 수가 일치하는가
상담에서 나온 최우선 요청이 반영돼 있는가
“확인 필요” 항목이 미해결인 채로 제출되지 않았는가

이 점검은 사람 눈으로도 할 수 있지만, 뒤에서 기계로 점검하는 방법을 싣습니다. 눈으로만 보면 반드시 새어 나갑니다.

AI에 맡기는 범위와, 사람이 반드시 판단하는 범위

여기를 애매하게 두면 사고가 납니다. 선 긋기를 표로 정리했습니다.

작업	AI에 맡긴다	사람이 판단한다
메모 정리·구조화	O	최종 확인
목차에 맞춘 초안	O	맥락 보정
질문지 재구성	O	당일의 깊이 파기
제안 전략·차별화 방향	△ 초안만	◎ 최종 결정
견적 금액 확정	X	◎
클라이언트 제출 가부	X	◎

금액과 제출의 최종 판단은 절대로 사람이 합니다. AI가 낸 개략 견적을 그대로 고객에게 내는 건, 신입에게 견적을 통째로 맡기고 말없이 제출하게 하는 것과 같습니다. 초안까지가 담당 범위라고 딱 잘라 두면, 안심하고 쓸 수 있습니다.

제안서 누락을 자동으로 점검하는 검증 스크립트

눈으로만 보는 점검은 지쳐 있으면 새어 나갑니다. 그래서 제안서 마크다운을 읽고 “필수 항목이 들어 있는지”를 기계적으로 확인하는 작은 스크립트를 두겠습니다. Node.js가 있으면 동작합니다.

제안서를 마크다운으로 쓰는 전제입니다. 슬라이드라도 텍스트로 내보내 통과시키면 쓸 수 있습니다.

import { readFile } from "node:fs/promises";

// 제안서에 반드시 넣고 싶은 항목과, 그것을 나타내는 키워드
const checks = [
  { label: "과제 정리", keywords: ["과제", "현재"] },
  { label: "목표", keywords: ["목표", "목적", "KGI", "KPI"] },
  { label: "사이트맵", keywords: ["사이트맵", "페이지 구성"] },
  { label: "일정", keywords: ["일정", "공정", "공개"] },
  { label: "견적 전제", keywords: ["전제", "개략", "견적"] },
  { label: "유지보수 운용", keywords: ["유지보수", "운용", "월정액"] },
];

const file = process.argv[2] || "proposal.md";
const text = await readFile(file, "utf8");

let missing = 0;
for (const c of checks) {
  const hit = c.keywords.some((k) => text.includes(k));
  if (hit) {
    console.log(`OK  ${c.label}`);
  } else {
    console.log(`NG  ${c.label}  <- 이 항목이 보이지 않습니다`);
    missing++;
  }
}

// 이전 건의 회사명이 남아 있지 않은지 간단 점검
const ghost = ["주식회사 샘플", "OO 주식회사", "이전 건"];
for (const g of ghost) {
  if (text.includes(g)) {
    console.log(`NG  자리표시자 "${g}" 가 남아 있습니다`);
    missing++;
  }
}

if (missing === 0) {
  console.log("\n전 항목 통과. 제출 전 최종 육안 확인으로.");
} else {
  console.log(`\n${missing}건의 누락이 있습니다. 고친 뒤 제출하세요.`);
  process.exitCode = 1;
}

사용법은 이게 전부입니다.

node check-proposal.mjs proposal.md

수십 줄밖에 안 되지만, 유지보수 비용 누락과 표지 회사명 잔존이라는 “늘 저지르는 2대 실수”를 이걸로 막을 수 있습니다. 키워드는 자사 제안서의 표현에 맞춰 추가하세요. 완벽한 판정이 아니라, 사람 앞에 두는 “마지막 문지기”로 쓰는 게 딱 맞는 사용법입니다.

참고로 Claude Code에 이 스크립트를 실행시키고, 결과를 보고 제안서를 고치는 데까지 맡기는 흐름도 만들 수 있습니다. 기초 방법은 Claude Code 시작 가이드에 정리해 두었습니다.

보안과 개인정보 주의점

클라이언트 정보를 다루므로 여기는 대충 할 수 없습니다. 최소한 이것만은 지키세요.

학습 이용을 끈다. 업무로 쓴다면, 입력 내용이 학습에 쓰이지 않는 요금제·설정을 고른다. Anthropic의 이용약관·개인정보 방침에서 처리 방식을 확인해 둔다.
건네는 정보는 최소한으로. 제안 뼈대 작성에, 고객 담당자의 개인 휴대폰이나 견적 원가까지 건넬 필요는 없다. 필요한 범위만 건넨다.
익명화한 뒤 건넨다. 회사명이나 개인명을 “A사”, “담당자 X”로 치환한 뒤 처리시키고, 마지막에 사람이 실명으로 되돌린다. 이것만으로 새어 나갔을 때의 피해가 줄어든다.
생성물은 반드시 사람이 확인. AI가 쓴 문장을 그대로 고객에게 내지 않는다. 오류나 과장된 표현이 섞일 수 있다.

클라이언트와의 계약에 “재위탁이나 외부 도구 이용 제한”이 있는 경우, 생성형 AI에 통과시키기 전에 반드시 확인하세요. 여기를 건너뛰면 효율화는커녕 신뢰 문제가 됩니다.

간단한 ROI 기준

대략 계산해 봅니다. 제안서 1건당 90분이 50분으로 줄어든다고 하면 40분 단축. 월 3건이면 2시간. 디렉터의 시급을 가령 4만 원으로 잡으면 월 8만 원어치 시간이 빕니다.

금액보다 큰 건, 그 2시간을 “제안의 내용을 다듬기”, “경쟁사를 조사하기”에 돌릴 수 있다는 점입니다. 문서 정형에 쓰던 시간을 수주율에 영향을 주는 작업으로 옮길 수 있습니다. 이건 숫자보다 효과가 큽니다.

프롬프트의 정밀도를 올리면 더 줄어듭니다. 작성 요령은 제안을 통과시키는 프롬프트 고급 기법이나 작업을 빠르게 하는 요령 모음이 참고가 됩니다. 팀에 공유하는 프롬프트 규칙은 CLAUDE.md 베스트 프랙티스도 함께 보면 좋습니다.

자주 묻는 질문

Q. AI가 만든 제안서를 그대로 고객에게 내도 되나요? 내지 마세요. 초안입니다. 전략의 타당성, 금액, 표현은 사람이 반드시 고칩니다. 내는 건 사람이 확인해 책임질 수 있는 상태가 된 뒤입니다.

Q. 상담 메모가 손글씨라 지저분한데 쓸 수 있나요? 사진을 텍스트로 변환한 뒤 건네면 쓸 수 있습니다. 다만 오독이 섞이므로, 고유명사와 숫자(예산·날짜)는 사람이 다시 봐 주세요.

Q. 우리 템플릿에 맞출 수 있나요? 맞출 수 있습니다. 자사 목차를 프롬프트에 붙여 넣으면, 그 형식으로 써 줍니다. 한 번 만든 프롬프트는 팀에서 공유해 돌려쓰면 좋습니다.

Q. 디자인에 관해 물어도 도움이 되나요? 방향성의 초안은 되지만, 디자인의 최종 판단은 디자이너에게 맡기세요. AI는 “말로 정리하는” 건 잘하지만, 비주얼의 좋고 나쁨에 대한 최종 판단은 사람의 영역입니다.

Q. 전문 지식이 없어도 운용할 수 있나요? 할 수 있습니다. 프롬프트를 붙여 넣고 결과를 확인하는 것만이라면 코드는 필요 없습니다. 팀 전개 방식은 비엔지니어를 위한 Claude Code 활용에 정리해 두었습니다.

실제로 시험해 본 결과

저는 손에 있던 과거 상담 메모 5건분으로 이 흐름을 시험했습니다. 확인한 건 세 가지입니다.

첫 번째는 시간. 뼈대 작성은 평균 60분에서 20분 안팎으로 줄었습니다. 완성까지의 합계로도 90분이 40~50분에 들어간 건이 많았습니다. 극적으로 빨라진다기보다, “늘 막히던 정형의 단차”가 사라진 느낌이었습니다.

두 번째는 상담 누락입니다. “메모에 없는 건 지어내지 못하게” 묶은 효과가 커서, 과거 메모에서 예산이나 공개일이 빠져 있던 건은 제대로 “확인 필요”에 줄을 섰습니다. 기억에 의존할 때보다 확실히 잡아냅니다.

세 번째는 검증 스크립트입니다. 일부러 유지보수 비용을 지운 제안서와, 이전 건의 회사명을 남긴 제안서를 통과시켰더니, 둘 다 NG로 멈췄습니다. 제출 직전의 마지막 보루로는 충분히 쓸 수 있습니다.

결론적으로, 제안의 발상은 지금처럼 사람이 합니다. 하지만 그 앞 단계의 “흩어진 정보를 다듬기”, “형식에 흘려 넣기”, “누락을 확인하기”는 이제 손으로 하지 않아도 됩니다. 비는 시간을 제안의 내용에 돌린다 - 이 사용법이 웹 제작사 디렉터에게는 가장 효과적이라고 느낍니다.

팀에서 구조로 돌리고 싶다, 연수로 도입하고 싶다는 경우에는 연수·상담 창구로 연락 주세요.