문서 작성 프롬프트 라이브러리

빈 문서 앞에 앉으면 커서는 깜빡이고, 사람은 멈춥니다. 무슨 말을 써야 할지는 어렴풋이 아는데, 첫 문장을 어떻게 꺼내야 할지 몰라 시간이 녹아내리죠. 보고서든 기획서든 제안서든, 일은 이미 시작됐는데 문서는 아직 제목도 없는 상태인 경우가 많습니다.

이럴 때 가장 강력한 무기는 영감이 아니라 검증된 작성 프롬프트입니다. 좋은 프롬프트는 글을 대신 써주는 마법 주문이 아니라, 빈 문서를 움직이게 하는 시동 버튼입니다. 처음부터 완벽한 문장을 얻는 것이 목표가 아닙니다. 바로 손볼 수 있는 초안, 바로 검토할 수 있는 구조, 바로 공유할 수 있는 요약을 빠르게 만드는 것이 핵심입니다.

이번 장에서는 문서 작성 업무에서 가장 자주 쓰는 다섯 가지 영역, 즉 보고서, 기획서, 제안서, 요약문, 초안 작성에 바로 복붙해서 쓸 수 있는 프롬프트를 정리합니다. 읽고 고개만 끄덕이는 장이 아니라, 내일 오전 회의 전에 바로 열어볼 수 있는 장으로 만들겠습니다.

문서 작성은 한 번에 끝내지 말고 세 번에 나눠라

문서가 잘 안 써지는 이유는 대개 글쓰기 실력 부족이 아닙니다. 한 번에 너무 많은 일을 하려 하기 때문입니다. 우리는 머릿속으로 이런 일을 동시에 처리하려고 합니다. 구조도 잡아야 하고, 내용도 써야 하고, 빠진 것도 찾아야 하고, 마지막엔 짧게 요약도 해야 합니다. 그러니 손이 멈춥니다.

문서 작성 프롬프트는 한 개의 거대한 요청보다 세 개의 짧은 요청으로 나눌 때 훨씬 안정적입니다.

• 1차는 생성입니다. 목차와 본문 초안을 만듭니다.

• 2차는 검토입니다. 논리 구멍, 누락 항목, 리스크를 찾습니다.

• 3차는 압축입니다. 임원용 요약, 메신저 공유본, 발표용 핵심 문장으로 줄입니다.

이 흐름을 익히면 문서는 더 빨리 나옵니다. 더 중요한 것은, 덜 막힙니다. 이제 "잘 써야지"가 아니라 "먼저 나오게 하자"로 접근하게 되기 때문입니다.

문서 작성 프롬프트에 늘 붙이면 좋은 안전 문장

문서 초안은 속도가 생명입니다. 하지만 속도만 챙기면 그럴듯한 추측이 섞이기 쉽습니다. 그래서 아래 문장은 거의 만능 안전장치처럼 쓸 수 있습니다.

• 제공한 정보만 사용하고, 없는 내용은 추정하지 말아줘.

• 정보가 부족한 항목은 임의로 채우지 말고 확인 필요로 표시해줘.

• 출력 형식은 반드시 지정한 순서를 지켜줘.

• 마지막에 빠진 항목이나 모호한 표현이 있으면 따로 알려줘.

이 네 줄은 문서를 똑똑하게 만드는 문장이 아니라, 문서를 덜 위험하게 만드는 문장입니다. 실무에서는 이 차이가 아주 큽니다.

보고서 프롬프트 라이브러리

보고서는 대부분 비슷한 고민으로 시작합니다. 배경은 알겠고 데이터도 조금 있는데, 이걸 어떤 순서로 설명해야 할지 모르겠는 상태 말입니다. 보고서는 멋진 문장보다 흐름이 중요합니다. 그래서 처음부터 문단을 잘 쓰려 하지 말고, 결론이 보이는 구조를 먼저 뽑는 프롬프트가 필요합니다.

보고서 초안 생성 프롬프트

가장 자주 쓰는 기본형입니다. 주간 보고, 이슈 보고, 검토 보고, 중간 보고에 두루 쓸 수 있습니다.

너는 [업계/직무] 시니어 매니저다.
목표: [보고 대상]에게 제출할 [문서 주제] 보고서 초안을 작성해줘.
배경: [상황 설명]
사용 데이터:
- 사실 1: [내용]
- 사실 2: [내용]
- 사실 3: [내용]
- 제약: [예산/일정/인력 등]
구조: 배경 - 문제 - 분석 - 대안 - 권고 - 리스크
조건:
- 제공한 정보만 사용
- 추정 금지
- 정보가 부족하면 `확인 필요`로 표시
출력:
1. 제목
2. 요약 5줄
3. 본문
4. 결론
5. 다음 액션 체크리스트

이 프롬프트의 좋은 점은 보고서를 "문장 쓰기"가 아니라 "판단 흐름 만들기"로 바꿔준다는 데 있습니다. 특히 결론이 늦게 나와서 읽는 사람을 지치게 만드는 문제를 줄여줍니다.

임원 요약 5줄 프롬프트

보고서가 길어질수록 요약은 따로 뽑아야 합니다. 임원은 대부분 긴 글을 싫어해서가 아니라, 먼저 판단 포인트를 보고 싶어 하기 때문입니다.

위 보고서를 임원 보고용으로 5줄로 다시 요약해줘.
형식:
- 결론 1줄
- 근거 2줄
- 리스크 1줄
- 다음 액션 1줄
조건:
- 단정적으로 쓰되 과장하지 말 것
- 숫자나 사실은 원문에 있는 것만 사용할 것

보고서를 먼저 쓰고 이 프롬프트를 이어서 붙이면, 한 문서가 두 가지 버전으로 생깁니다. 하나는 읽는 문서, 하나는 결정하는 문서입니다.

보고서 검토 프롬프트

초안은 대개 그럴듯합니다. 문제는 그럴듯하다는 것이 늘 안전하다는 뜻은 아니라는 점입니다. 제출 전에 한 번은 "까다로운 검토자 모드"가 필요합니다.

너는 보고서 검토자다.
아래 보고서를 검토해서 다음 항목만 정리해줘.
1. 논리가 비약된 부분
2. 근거가 부족한 부분
3. 리스크가 빠진 부분
4. 표현이 모호한 문장
5. 의사결정자가 추가로 물을 가능성이 큰 질문 5개
출력 형식:
- 문제 지점
- 왜 문제인지
- 수정 방향
조건:
- 새 사실을 만들지 말고, 현재 문서 기준으로만 검토할 것

이 프롬프트는 문서를 더 길게 만드는 데 쓰지 마세요. 더 단단하게 만드는 데 써야 합니다.

기획서 프롬프트 라이브러리

기획서는 "무엇을 하겠다"보다 "왜 이 방식이어야 하는가"를 설득하는 문서입니다. 그래서 아이디어가 좋아도 구조가 약하면 힘을 잃습니다. 기획서에서는 특히 목적, 대상, 실행 방식이 선명해야 합니다.

1페이지 기획서 프롬프트

짧은데 강한 기획서가 필요할 때 쓰는 기본형입니다. 팀장 검토용이나 내부 제안 초안에 잘 맞습니다.

너는 실무형 서비스 기획자다.
아래 정보를 바탕으로 1페이지 분량의 기획서 초안을 작성해줘.
기획 주제: [주제]
목적: [왜 하는지]
대상 사용자/대상 조직: [대상]
현재 문제: [문제]
제안 아이디어: [아이디어]
기대 효과: [효과]
제약 조건: [일정/예산/인력]
구성:
- 기획 배경
- 문제 정의
- 제안 내용
- 실행 방식
- 기대 효과
- 유의 사항
조건:
- 실무자가 바로 검토할 수 있게 간결하게 작성
- 추상어를 줄이고 실제 행동 중심으로 설명
- 정보가 부족하면 `확인 필요` 항목으로 분리

짧은 기획서가 어려운 이유는 쓸 내용이 없어서가 아니라, 버릴 내용을 못 정해서입니다. 이 프롬프트는 그 버리기 작업을 도와줍니다.

실행 계획 분해 프롬프트

기획서는 멋있는데 실행이 흐릿한 경우가 많습니다. 그럴 때는 기획서 다음에 바로 붙일 실행 분해 프롬프트가 필요합니다.

아래 기획안을 실행 계획으로 바꿔줘.
출력 형식:
1. 단계별 실행 항목
2. 각 단계의 목표
3. 담당 역할
4. 예상 기간
5. 선행 조건
6. 주요 리스크
조건:
- 지나치게 낙관적으로 잡지 말 것
- 실제 팀이 움직일 수 있는 수준으로 쪼갤 것
- 표 형식으로 정리할 것

기획은 멋있고 실행은 막막한 순간, 이 프롬프트가 기획서를 일거리로 바꿔줍니다.

기획서 허점 찾기 프롬프트

좋은 기획서는 반대 질문을 견딥니다. 그러니 제출 전에 일부러 태클을 걸어보는 편이 낫습니다.

너는 보수적인 검토자다.
아래 기획서를 읽고 승인 전에 제기할 만한 반대 의견을 정리해줘.
정리 항목:
- 왜 지금 해야 하는지 불명확한 부분
- 비용 대비 효과가 약한 부분
- 실행 가능성이 낮아 보이는 부분
- 이해관계자 설득이 필요한 부분
- 보완하면 통과 가능성이 높아지는 수정 포인트
조건:
- 비난하지 말고 검토 의견처럼 작성
- 각 항목마다 보완 제안 1개 포함

기획서의 적은 비판이 아니라 무관심입니다. 그러니 미리 공격받아보는 편이 낫습니다.

제안서 프롬프트 라이브러리

제안서는 내부 문서보다 한 단계 더 까다롭습니다. 읽는 사람이 "좋아 보이네"가 아니라 "그래서 당신이 뭘 해줄 수 있는데?"를 묻기 때문입니다. 제안서는 상대의 문제를 먼저 정리하고, 우리 해결책을 그 다음에 올려야 힘이 생깁니다.

고객 맞춤 제안서 초안 프롬프트

가장 기본이 되는 프롬프트입니다. 고객사 제안, 협업 제안, 내부 투자 제안에도 응용할 수 있습니다.

너는 B2B 제안서 작성 경험이 많은 컨설턴트다.
아래 정보를 바탕으로 [상대 조직/고객]에게 제출할 제안서 초안을 작성해줘.
상대의 상황: [현재 문제/니즈]
우리가 제안하는 내용: [서비스/프로젝트/아이디어]
핵심 차별점: [차별점]
예상 일정: [일정]
예산 또는 비용 범위: [예산]
기대 효과: [효과]
구성:
- 제안 배경
- 상대의 문제 정의
- 제안 내용
- 실행 방식
- 일정 및 범위
- 기대 효과
- 협업 요청 또는 다음 단계
조건:
- 우리 자랑보다 상대 문제 해결 중심으로 작성
- 과장 표현 금지
- 확인되지 않은 성과 수치는 만들지 말 것

제안서가 자꾸 자기소개서처럼 길어진다면, 이 프롬프트를 쓰는 순간 훨씬 낫게 잡힙니다. 핵심은 "우리가 누구냐"보다 "상대에게 어떤 변화가 생기느냐"입니다.

제안 가치 문장 정리 프롬프트

제안서는 본문도 중요하지만, 첫 장의 메시지가 더 중요할 때가 많습니다. 한 문장으로 가치가 안 보이면 다음 페이지는 잘 안 읽힙니다.

아래 제안 내용을 바탕으로 첫 장에 들어갈 가치 제안 문장을 5개 써줘.
조건:
- 상대가 얻는 변화가 바로 보이게 작성
- 길이는 각 문장 25자~40자 정도
- 추상적 표현보다 결과 중심으로 작성
- 서로 다른 톤으로 제안: 보수형, 실무형, 설득형, 데이터형, 간결형

이 프롬프트는 제안서 제목, 표지 문구, 발표 첫 문장까지 한꺼번에 해결해주는 작은 효자입니다.

범위와 제외사항 정리 프롬프트

제안서에서 가장 자주 생기는 사고는 "이것도 해주는 줄 알았는데요?"입니다. 그래서 범위와 제외사항을 분명히 적는 프롬프트가 필요합니다.

아래 제안 내용을 기준으로 수행 범위와 제외사항을 구분해서 정리해줘.
출력 형식:
1. 포함 범위
2. 제외 범위
3. 고객 측 준비 사항
4. 일정에 영향을 주는 전제 조건
조건:
- 애매한 표현 대신 테스트 가능한 문장으로 작성
- 추정하지 말고 현재 정보 기준으로만 정리
- 나중에 오해가 생길 수 있는 부분은 `주의`로 표시

제안서는 잘 팔리는 것도 중요하지만, 잘 안 꼬이는 것도 중요합니다. 이 프롬프트는 바로 그 역할을 합니다.

요약문 프롬프트 라이브러리

요약은 짧게 줄이는 일이 아닙니다. 중요한 것을 남기는 일입니다. 그래서 요약이 어려운 것입니다. 특히 긴 문서, 회의 메모, 조사 자료, 보고서 초안을 빨리 공유해야 할 때는 좋은 요약 프롬프트가 시간을 크게 줄여줍니다.

6줄 요약 프롬프트

문서를 빠르게 공유해야 할 때 가장 실용적인 형식입니다.

아래 문서를 6줄로 요약해줘.
형식:
1. 문서 목적 1줄
2. 핵심 내용 3줄
3. 리스크 또는 유의사항 1줄
4. 다음 액션 1줄
조건:
- 문장마다 하나의 포인트만 담을 것
- 모호한 표현보다 결론 중심으로 쓸 것
- 제공된 문서 밖의 내용은 추가하지 말 것

이 요약은 메신저 공유, 상사 보고, 회의 전 브리핑에 특히 강합니다.

원페이지 브리프 프롬프트

여러 자료를 모았는데 아직 정식 보고서까지는 필요 없을 때, 브리프 형태가 아주 유용합니다.

아래 자료를 바탕으로 원페이지 브리프를 작성해줘.
자료: [기사/회의 메모/리서치 메모/문서 초안]
구성:
- 한 줄 요약
- 지금 중요한 이유
- 핵심 사실 3개
- 시사점 3개
- 우리가 해야 할 다음 행동
조건:
- 비전문가도 이해할 수 있게 쉽게 쓸 것
- 전문 용어가 나오면 짧게 풀어 쓸 것
- 정보 부족 항목은 따로 표시할 것

브리프는 문서를 짧게 만드는 기술이 아니라, 읽는 사람의 시간을 아끼는 기술입니다.

긴 문서에서 의사결정 포인트만 뽑는 프롬프트

읽을 시간은 없고 판단은 해야 할 때 쓰는 프롬프트입니다.

아래 문서에서 의사결정에 필요한 내용만 추려줘.
출력 형식:
- 무엇을 결정해야 하는가
- 선택 가능한 대안은 무엇인가
- 각 대안의 장단점
- 추천안
- 바로 물어봐야 할 확인 질문 3개
조건:
- 배경 설명은 최소화하고 판단 포인트 중심으로 정리
- 근거가 문서에 없는 내용은 넣지 말 것

이 프롬프트는 특히 회의 전 10분이 금인 날에 강합니다.

빈 문서 탈출용 초안 프롬프트 라이브러리

아무 자료도 없지는 않은데, 그렇다고 문서 형태로 정리된 것도 없을 때가 있습니다. 메모 몇 줄, 머릿속 아이디어, 회의 때 들은 말, 캡처한 수치 몇 개. 이런 상태에서 바로 본문을 쓰려 하면 손이 멈춥니다. 그럴 때는 "문서 완성"을 요구하지 말고 "시작점 생성"을 요구해야 합니다.

첫 장 스타터 프롬프트

문서의 문을 열어주는 프롬프트입니다.

나는 아래 정보만 가지고 문서를 시작하려고 한다.
주제: [주제]
목적: [목적]
독자: [독자]
현재 떠오른 메모:
- [메모 1]
- [메모 2]
- [메모 3]
이 상태에서 문서를 시작할 수 있게 다음만 만들어줘.
1. 제목 후보 5개
2. 추천 목차 1개
3. 문서 첫 문단 초안
4. 본문에 더 채워야 할 정보 목록
조건:
- 완성본처럼 쓰지 말고 출발점이 되게 작성
- 가장 실무적인 방향으로 제안

막막함은 대부분 빈칸이 너무 많아서 생깁니다. 이 프롬프트는 빈칸을 질문 목록으로 바꿔줍니다.

문장 다듬기 프롬프트

초안은 있는데 너무 구어체이거나, 말하듯 써서 문서 톤이 약할 때 쓰면 좋습니다.

아래 문장을 문서용 문체로 다듬어줘.
조건:
- 의미는 바꾸지 말 것
- 군더더기 표현 제거
- 더 짧고 명확하게 만들 것
- 보고서/기획서에 어울리는 문어체로 수정
출력:
1. 수정본
2. 왜 바꿨는지 한 줄 설명

이 프롬프트는 특히 "말은 되는데 문서 같지는 않은 글"을 정리할 때 좋습니다.

초안 확장 프롬프트

목차까진 나왔는데 본문이 비어 있는 상태라면, 섹션별로 나눠 쓰게 해야 합니다.

아래 목차를 바탕으로 각 섹션의 초안을 작성해줘.
목차: [목차 붙여넣기]
작성 기준:
- 각 섹션은 3~5문장 정도
- 주장 다음에 근거가 오게 작성
- 과장 표현 금지
- 모르는 정보는 `확인 필요`로 표기
출력:
- H2 제목
- 섹션 초안
- 추가로 필요한 정보

문서를 끝까지 한 번에 쓰려 하지 말고, 섹션별로 채우는 습관을 들이면 속도가 훨씬 빨라집니다.

프롬프트를 더 잘 먹히게 만드는 보정 문장

같은 프롬프트라도 마지막 한 줄이 결과를 바꾸는 경우가 많습니다. 아래 문장은 문서 작성 업무에서 특히 자주 쓸 만한 보정 문장입니다.

• 결론을 먼저 쓰고, 근거는 뒤에 정리해줘.

• 읽는 사람이 3분 안에 핵심을 파악할 수 있게 써줘.

• 표로 바꾸면 더 명확한 항목은 표로 정리해줘.

• 빠진 정보가 있으면 문서 끝에 추가 확인 필요 사항으로 모아줘.

• 반대 의견을 받을 수 있는 부분은 유의사항으로 따로 표시해줘.

• 같은 의미의 반복 표현은 줄여줘.

이런 문장은 화려하지 않지만, 실무 문서를 쓸 만하게 만들어주는 힘이 있습니다. 양념보다 간장에 가까운 문장입니다. 없으면 허전하고, 있으면 안정됩니다.

문서 작성 프롬프트를 쓸 때 흔한 실수

문서 작성 프롬프트는 잘만 쓰면 시간을 크게 줄여줍니다. 하지만 몇 가지 실수를 반복하면 오히려 결과를 더 많이 손봐야 합니다.

첫째, 문서 종류만 말하고 독자를 말하지 않는 경우입니다. 같은 보고서라도 임원용, 팀장용, 고객용은 완전히 다릅니다.

둘째, 초안과 최종본을 한 번에 요구하는 경우입니다. 초안은 거칠어도 됩니다. 대신 빨라야 합니다. 완성도는 두 번째 요청에서 올리는 편이 낫습니다.

셋째, 입력 자료 없이 상상으로 쓰게 만드는 경우입니다. 이러면 문장은 그럴듯한데 내용이 허술해집니다.

넷째, 출력 형식을 안 정하는 경우입니다. 그러면 내용은 괜찮아도 바로 붙여 넣기 어려운 결과가 나옵니다.

다섯째, 검토 프롬프트를 빼먹는 경우입니다. 문서는 생성보다 검토에서 품질 차이가 크게 벌어집니다.

문서 작성에서 AI를 잘 쓰는 사람은 한 번에 잘 쓰게 하는 사람이 아니라, 잘 나오고 잘 고치게 만드는 사람입니다.

이 장의 핵심 정리

문서 작성 프롬프트 라이브러리의 목적은 멋진 문장을 뽑는 데 있지 않습니다. 빈 문서 앞에서 멈추는 시간을 줄이는 데 있습니다. 보고서는 구조를 먼저 뽑고, 기획서는 실행으로 쪼개고, 제안서는 상대 문제부터 쓰고, 요약문은 판단 포인트만 남기고, 초안은 시작점부터 만들어야 합니다.

그리고 무엇보다 중요합니다. 문서는 한 번에 완성하려고 할수록 늦어집니다. 생성, 검토, 압축으로 나누면 훨씬 빨라집니다. 이 장의 프롬프트를 전부 외울 필요는 없습니다. 다만 내 업무에 가장 자주 맞는 것 다섯 개만 골라 저장해두세요. 그러면 다음번 빈 문서는 예전만큼 무섭지 않을 것입니다.

깜빡이던 커서는 여전히 깜빡이겠지만, 이제는 적어도 당신이 먼저 멈추지는 않을 겁니다.