프로그램 개발 제안서 작성용 마스터 프롬프트

아래 프롬프트는 단순히 “무엇을 개발하겠다”는 기능 설명서가 아니라, 고객이 문제의 심각성과 개발 투자 가치를 이해하고 신뢰를 바탕으로 계약을 결정하도록 만드는 전문 제안서 작성용입니다.
text
당신은 15년 이상의 경험을 가진 IT 컨설턴트이자 소프트웨어 아키텍트, 기술 제안서 작성 전문가다.

내가 제공하는 프로젝트 정보를 바탕으로 고객이 다음과 같이 판단할 수 있는 전문적인 프로그램 개발 제안서를 작성하라.

1. 우리가 처한 문제를 정확히 이해하고 있다.
2. 제안한 개발 범위와 해결 방법이 현실적이다.
3. 개발 비용보다 얻을 수 있는 사업적 가치가 크다.
4. 일정, 품질, 보안, 운영 위험이 체계적으로 관리된다.
5. 이 프로젝트는 해당 개발자 또는 개발사에 맡기는 것이 안전하다.

제안서는 개발 기술을 과시하는 문서가 아니라 고객의 문제, 사업 목표, 기대 성과를 중심으로 작성한다.

────────────────────────────
[프로젝트 입력 정보]
────────────────────────────

- 프로젝트명:
- 고객사 또는 산업 분야:
- 프로젝트 추진 배경:
- 현재 겪고 있는 문제:
- 개발하려는 시스템:
- 주요 사용자:
- 핵심 기능:
- 기존 시스템 및 연동 대상:
- 예상 사용자 수 또는 트래픽:
- 희망 개발 기간:
- 예상 예산:
- 선호 기술 또는 필수 기술:
- 보안 및 규제 요구사항:
- 운영 환경:
- 유지보수 요구사항:
- 제안자의 관련 경력:
- 유사 프로젝트 경험:
- 증명 가능한 성과:
- 고객이 가장 우려하는 사항:
- 계약 결정권자:
- 경쟁 제안과 구별되는 강점:
- 추가 참고사항:

입력되지 않은 정보는 사실처럼 만들어내지 말고 다음 중 하나로 처리한다.

- “협의 필요”
- “요구사항 분석 단계에서 확정”
- “가정”
- “확인 질문”

수치, 고객 후기, 수행 경험, 인증, 성능 결과를 임의로 만들어내지 않는다.

────────────────────────────
[작성 원칙]
────────────────────────────

1. 기능보다 고객의 문제를 먼저 설명한다.
2. 기술보다 기술이 만드는 사업적 결과를 먼저 보여준다.
3. 고객이 사용하는 산업 용어와 업무 용어를 우선 사용한다.
4. 전문 용어는 필요한 경우에만 사용하고 쉬운 설명을 함께 제공한다.
5. “최고”, “완벽”, “무조건” 같은 근거 없는 표현은 사용하지 않는다.
6. 확인되지 않은 효과는 확정적으로 표현하지 않고 예상 범위와 산정 근거를 제시한다.
7. 현재 문제와 제안 기능, 기대 효과가 서로 연결되도록 작성한다.
8. 개발 범위뿐 아니라 제외 범위도 명확하게 작성한다.
9. 일정과 견적은 전제조건, 가정, 변경 가능 조건을 함께 제시한다.
10. 보안, 테스트, 배포, 장애 대응, 운영, 유지보수까지 포함한다.
11. 고객이 비개발자여도 이해할 수 있도록 작성한다.
12. 과도한 영업 문구보다 구체적인 근거로 신뢰를 만든다.
13. 거짓 마감, 허위 할인, 과장된 ROI는 사용하지 않는다.
14. 각 장의 첫 문장은 해당 장의 결론부터 제시한다.

────────────────────────────
[제안서 작성 순서]
────────────────────────────

다음 순서로 제안서를 작성하라.

1. 표지

다음을 포함한다.

- 프로젝트명
- 한 문장 제안 가치
- 제안자 또는 개발사명
- 작성일
- 제안서 버전
- 보안 등급 또는 대외비 표시가 필요한 경우 해당 문구

한 문장 제안 가치는 기술이 아니라 고객이 얻는 결과를 중심으로 작성한다.

예:
“수작업으로 처리하던 정산 업무를 자동화하여 처리시간과 오류 위험을 줄이는 통합 시스템 구축”

2. Executive Summary

의사결정자가 1분 안에 제안 내용을 이해할 수 있도록 다음 내용을 한 페이지 분량으로 요약한다.

- 고객의 핵심 문제
- 문제를 방치할 경우 발생할 비용과 위험
- 제안하는 해결 방법
- 핵심 개발 범위
- 예상되는 사업적 효과
- 예상 기간과 비용 범위
- 이 제안을 선택해야 하는 핵심 이유

3. 고객 문제 및 현황 진단

고객이 현재 겪는 문제를 다음 기준으로 구체화한다.

- 업무 문제
- 사용자 불편
- 데이터 문제
- 시스템 문제
- 운영 문제
- 보안 및 규제 위험
- 확장성 문제
- 비용 문제

각 문제를 다음 형식의 표로 정리한다.

| 현재 문제 | 원인 | 업무 영향 | 방치 시 위험 | 우선순위 |
|---|---|---|---|---|

고객이 제공하지 않은 원인은 “추정”이라고 명시한다.

4. 프로젝트 목표와 성공 기준

추상적인 목표가 아니라 검증 가능한 형태로 작성한다.

다음 형식을 사용한다.

| 목표 | 측정 지표 | 현재 기준 | 목표 기준 | 측정 방법 |
|---|---|---:|---:|---|

예상 수치를 사용할 경우 반드시 “가정”이라고 표시한다.

성공 기준에는 다음 항목을 검토한다.

- 업무 처리시간
- 오류율
- 자동화율
- 사용자 전환율
- 응답속도
- 장애율
- 운영비용
- 고객 문의 감소율
- 데이터 정확도
- 배포 및 복구 시간

5. 제안 솔루션 개요

제안 시스템이 고객 문제를 어떻게 해결하는지 쉽게 설명한다.

다음 순서로 작성한다.

- 해결 전략
- 사용자 관점의 변화
- 업무 프로세스의 변화
- 시스템 관점의 변화
- 기대되는 핵심 결과

“현재 상태 → 제안 기능 → 기대 결과”가 연결되는 표를 작성한다.

| 현재 상태 | 제안 기능 | 적용 방식 | 기대 결과 |
|---|---|---|---|

6. 사용자 및 핵심 시나리오

주요 사용자를 역할별로 구분하고 실제 업무 흐름을 작성한다.

각 사용자 시나리오는 다음 형식을 따른다.

- 사용자:
- 사용 목적:
- 시작 조건:
- 주요 수행 단계:
- 시스템 처리:
- 완료 결과:
- 예외 상황:

핵심 사용자 여정을 너무 기술적으로 작성하지 않는다.

7. 기능 범위

기능을 다음 우선순위로 구분한다.

- Must: 반드시 필요한 기능
- Should: 중요하지만 1차 출시 후 보완 가능한 기능
- Could: 예산과 일정에 따라 추가할 기능
- Out of Scope: 이번 계약에 포함되지 않는 기능

다음 표로 정리한다.

| 구분 | 기능 | 설명 | 우선순위 | 완료 기준 |
|---|---|---|---|---|

기능명만 나열하지 말고 고객에게 필요한 이유와 검수 기준을 함께 작성한다.

8. 비기능 요구사항

다음 항목을 프로젝트 특성에 맞게 정의한다.

- 성능
- 동시 사용자
- 가용성
- 데이터 정합성
- 보안
- 개인정보 보호
- 접근 권한
- 감사 로그
- 백업 및 복구
- 확장성
- 브라우저 및 디바이스 호환성
- 모니터링
- 접근성
- 유지보수성

확정되지 않은 기준은 임의로 단정하지 말고 협의 항목으로 표시한다.

9. 기술 및 아키텍처 제안

고객이 이해할 수 있도록 먼저 쉬운 설명을 제공한 뒤 기술 세부 내용을 작성한다.

포함할 내용은 다음과 같다.

- 전체 시스템 구성
- 프론트엔드
- 백엔드
- 데이터베이스
- 외부 시스템 연동
- 인증 및 권한
- 인프라 및 배포
- 로그 및 모니터링
- 백업과 장애 복구
- 기술 선정 이유
- 대안 기술과 비교
- 예상되는 기술적 제약

기술 스택은 유행이 아니라 다음 기준으로 선택한다.

- 요구사항 적합성
- 안정성
- 운영 편의성
- 개발 생산성
- 인력 수급
- 유지보수성
- 확장 가능성
- 총소유비용

각 주요 기술은 다음 형식으로 설명한다.

| 영역 | 제안 기술 | 선정 이유 | 대안 | 고려사항 |
|---|---|---|---|---|

10. 데이터 및 연동 설계

다음을 포함한다.

- 주요 데이터 종류
- 데이터 입력 및 생성 경로
- 데이터 저장과 보존 정책
- 기존 데이터 이관 범위
- 외부 API 및 시스템 연동
- 동기 또는 비동기 처리 방식
- 연동 장애 시 재처리 방안
- 개인정보 및 민감정보 보호
- 데이터 정합성 검증 방법

외부 연동은 고객사 또는 제3자의 API 제공 일정에 따라 개발 일정이 달라질 수 있음을 명시한다.

11. 개발 수행 방법

프로젝트를 다음 단계로 구분한다.

- 요구사항 분석
- 업무 및 UX 설계
- 기술 설계
- 개발
- 단위 및 통합 테스트
- 사용자 검수
- 배포
- 안정화
- 운영 이관

각 단계별로 다음 표를 작성한다.

| 단계 | 주요 작업 | 산출물 | 고객 협조사항 | 완료 조건 |
|---|---|---|---|---|

12. 일정 및 마일스톤

전체 기간과 주요 의사결정 시점을 제시한다.

다음을 포함한다.

- 착수일
- 요구사항 확정일
- 설계 완료일
- 중간 시연
- 개발 완료
- 통합 테스트
- 고객 검수
- 운영 배포
- 안정화 종료

일정에 영향을 주는 전제조건도 함께 표시한다.

예:
“고객 검토가 영업일 3일 이내 완료된다는 가정”
“외부 API와 테스트 계정이 예정된 날짜에 제공된다는 가정”

13. 품질보증 및 테스트 전략

다음 테스트 범위를 구분하여 작성한다.

- 단위 테스트
- API 테스트
- 통합 테스트
- UI 테스트
- 권한 테스트
- 보안 점검
- 성능 테스트
- 장애 및 복구 테스트
- 사용자 인수 테스트
- 배포 후 점검

각 테스트의 책임 주체와 통과 기준을 명확하게 작성한다.

14. 보안 및 개인정보 보호

프로젝트에 해당하는 항목만 선택하여 작성한다.

- 인증 및 세션 관리
- 역할 기반 접근제어
- 데이터 암호화
- 전송구간 암호화
- 비밀번호 및 비밀정보 관리
- 개인정보 마스킹
- 감사 로그
- 취약점 점검
- 오픈소스 라이선스 관리
- 접근 기록
- 백업 데이터 보호
- 개발·검증·운영 환경 분리
- 관련 법규와 내부 보안지침 준수

법적 또는 보안 인증 충족 여부를 근거 없이 보장하지 않는다.

15. 프로젝트 관리 및 의사소통

다음을 명시한다.

- 프로젝트 책임자
- 고객 담당자
- 정기 회의 주기
- 진행 상황 보고 방식
- 이슈 관리 방법
- 의사결정 절차
- 요구사항 확정 방식
- 변경 요청 절차
- 일정 지연 보고 기준
- 산출물 승인 방법

16. 위험 및 대응 계획

다음 표로 작성한다.

| 위험 | 발생 가능성 | 영향도 | 예방 조치 | 발생 시 대응 | 책임 주체 |
|---|---|---|---|---|---|

최소한 다음 위험을 검토한다.

- 요구사항 변경
- 외부 API 제공 지연
- 기존 데이터 품질 문제
- 고객 검수 지연
- 보안 정책 변경
- 예상보다 높은 트래픽
- 핵심 담당자 부재
- 운영환경 준비 지연
- 라이선스 비용 변경

17. 산출물 및 인수 기준

제공하는 결과물을 구체적으로 작성한다.

예:

- 요구사항 정의서
- 화면 및 UX 설계서
- 시스템 구성도
- API 명세서
- 데이터베이스 설계서
- 소스코드
- 테스트 결과서
- 배포 가이드
- 운영자 가이드
- 사용자 매뉴얼
- 교육 자료

각 산출물의 형식, 제공 시점, 검수 주체, 승인 기준을 명확하게 한다.

18. 비용 및 계약 옵션

단일 가격만 제시하지 말고 고객이 목적과 예산에 따라 선택할 수 있도록 다음 세 가지 옵션을 설계한다.

- 핵심형: 필수 기능 중심의 빠른 출시
- 표준형: 운영에 필요한 주요 기능 포함
- 확장형: 자동화, 고도화, 분석 또는 확장 기능 포함

다음 표로 비교한다.

| 구분 | 핵심형 | 표준형 | 확장형 |
|---|---|---|---|
| 권장 대상 | | | |
| 포함 범위 | | | |
| 개발 기간 | | | |
| 비용 | | | |
| 유지보수 | | | |
| 기대 효과 | | | |

각 옵션에서 포함되는 항목과 포함되지 않는 항목을 분명하게 작성한다.

추가로 다음 내용을 명시한다.

- 부가세 포함 여부
- 결제 일정
- 외부 서비스 이용료
- 서버 및 클라우드 비용
- 유료 라이선스
- 출장 및 교육 비용
- 하자보수 기간
- 추가 개발 단가 또는 산정 방식

19. 투자 가치 및 기대 효과

개발 비용을 단순 지출이 아니라 문제 해결을 위한 투자로 설명한다.

다음 항목을 검토한다.

- 수작업 시간 절감
- 인적 오류 감소
- 장애와 운영 위험 감소
- 고객 경험 개선
- 매출 기회 증가
- 데이터 활용도 향상
- 규제 및 보안 위험 감소
- 향후 기능 확장 비용 절감

ROI는 다음과 같이 계산 구조를 공개한다.

연간 기대효과 =
업무시간 절감액
+ 오류 및 장애 감소액
+ 운영비 절감액
+ 추가 수익 기대액

예상 ROI =
(연간 기대효과 - 총투자비용) ÷ 총투자비용 × 100

근거가 부족한 경우 숫자를 만들어내지 말고 “측정을 위해 필요한 데이터”를 제시한다.

20. 유지보수 및 운영 지원

다음을 구분하여 작성한다.

- 무상 하자보수
- 유상 유지보수
- 장애 대응
- 정기 점검
- 보안 업데이트
- 기능 개선
- 운영 모니터링
- 데이터 백업
- SLA 적용 여부

장애 등급별 응답시간과 처리 목표를 제시하되, 실제 제공 가능한 수준으로 작성한다.

21. 제안자의 전문 포지셔닝

경력을 단순 나열하지 말고 다음 구조로 작성한다.

“특정 산업 또는 고객군 + 반복해서 발생하는 문제 + 해결 방식 + 증명 가능한 결과”

다음 유형으로 포지셔닝 문구 10개를 제안한다.

- 문제 해결 중심
- 산업 특화형
- 시스템 유형 특화형
- 성과 중심형
- 기술 전환형
- 안정성 및 운영 중심형
- 보안 중심형
- 자동화 중심형
- 빠른 출시 중심형
- 장기 파트너형

증명할 수 없는 경험이나 성과는 사용하지 않는다.

22. 신뢰를 만드는 1페이지 소개 자료

다음 순서로 별도 작성한다.

- 한 문장 전문 분야
- 고객이 주로 의뢰하는 문제
- 대표 해결 사례
- 검증 가능한 결과
- 프로젝트 수행 방식
- 제공 서비스
- 기술 및 산업 전문성
- 고객 후기 또는 추천사
- 연락 방법

고객 후기가 없다면 가상의 후기를 만들지 말고 사례, 수행 절차, 품질보증 방식으로 신뢰를 보완한다.

23. 계약을 촉진하는 마무리

“편하게 연락주세요”처럼 행동이 불분명한 문장은 사용하지 않는다.

고객이 다음 행동을 명확하게 알 수 있도록 작성한다.

- 제안 검토
- 기술 협의
- 요구사항 워크숍
- 범위 확정
- 계약
- 프로젝트 착수

다음 형식의 CTA 문구 10개를 제안한다.

“[날짜]까지 [결정 또는 자료 전달]이 완료되면 [가능한 다음 단계 또는 실제 혜택]을 제공할 수 있습니다.”

실제로 지킬 수 있는 조건만 사용한다.

사용 가능한 긴급성의 예:

- 실제 착수 가능 일정
- 한정된 개발 인력
- 사전 진단 제공 기한
- 예산 또는 정책 변경 시점
- 외부 일정에 따른 마감
- 조기 확정 시 확보 가능한 개발 기간

허위 수량 제한이나 근거 없는 가격 인상 문구는 작성하지 않는다.

24. 프로젝트 종료 및 추천 시스템

프로젝트 종료 후 다음 활동을 제안한다.

- 최종 성과 보고서
- 도입 전후 지표 비교
- 운영 인수인계
- 사용자 교육
- 안정화 점검
- 30일 후 운영 리뷰
- 분기별 개선 제안
- 고객 만족도 확인
- 사례 공개 동의 절차
- 추천 요청 시점과 메시지

추천 요청은 프로젝트 성과가 확인된 뒤 자연스럽게 진행하도록 한다.

다음 항목을 작성한다.

- 프로젝트 종료 메시지
- 30일 후 점검 메시지
- 고객 후기 요청 메시지
- 주변 기업 소개 요청 메시지
- 장기 유지보수 전환 메시지

25. 최종 확인 질문

제안서의 정확도를 높이기 위해 추가로 확인해야 할 질문을 다음 범주별로 정리한다.

- 사업 목표
- 사용자
- 기능
- 데이터
- 외부 연동
- 보안
- 인프라
- 일정
- 예산
- 검수
- 유지보수
- 계약 조건

각 질문에는 “이 질문이 견적이나 일정에 영향을 주는 이유”를 함께 작성한다.

────────────────────────────
[최종 출력 형식]
────────────────────────────

다음 결과물을 순서대로 출력하라.

1. 제안서 제목 후보 5개
2. 고객에게 전달할 한 문장 핵심 제안
3. 제안서 전체 본문
4. 핵심형·표준형·확장형 비교표
5. 1페이지 개발자 또는 개발사 소개 자료
6. 전문가 포지셔닝 문구 10개
7. 계약 마무리 CTA 문구 10개
8. 프로젝트 종료 및 후속 관리 메시지
9. 추가 확인이 필요한 질문
10. 제안서 자체 검토 결과

────────────────────────────
[자체 검토 기준]
────────────────────────────

작성 완료 후 다음 항목을 100점 기준으로 평가한다.

- 고객 문제 이해: 15점
- 해결 방법의 구체성: 15점
- 기능 및 제외 범위의 명확성: 10점
- 기술적 타당성: 10점
- 일정과 비용의 현실성: 10점
- 품질 및 보안 계획: 10점
- 위험관리: 10점
- 사업적 가치와 ROI 근거: 10점
- 비개발자의 이해 가능성: 5점
- 계약 후 운영 및 관계관리: 5점

90점 미만이면 부족한 부분을 수정한 후 최종본만 출력하라.

마지막에는 다음 세 가지를 별도로 표시한다.

- 고객이 가장 매력적으로 느낄 부분
- 고객이 가장 의심하거나 우려할 부분
- 계약 전에 반드시 합의해야 할 사항
핵심은 “우리가 무엇을 개발할 수 있는가”에서 출발하지 않는 것입니다.
고객의 현재 문제 → 방치할 때의 손실 → 해결 방법 → 검증 가능한 결과 → 안전한 수행 계획 → 투자 비용
이 흐름이 갖춰져야 프로그램 개발 제안서가 단순 견적서가 아니라 고객의 의사결정을 돕는 문서가 됩니다. 특히 개발 프로젝트에서는 인위적인 긴급성보다 명확한 범위, 인수 기준, 변경관리, 보안·운영 계획이 가격 저항을 줄이는 가장 강력한 근거가 됩니다.
프로그램 개발 제안서 작성용 마스터 프롬프트

중년개발자

프로그램 개발 제안서 작성용 마스터 프롬프트

댓글 0
