업무와 학습에서 LLM을 자주 쓰는 순간은 생각보다 반복됩니다. 문서를 요약하고, 필요한 항목만 추출하고, 텍스트를 분류하고, 자료 기반으로 질의응답을 하고, 아이디어를 브레인스토밍하고, 글을 작성/편집하고, 코드를 생성합니다. 이 챕터는 그 7가지 작업을 "복붙 가능한 기본 레시피"로 정리한 것입니다.
아래 템플릿은 다음 원칙을 전제로 합니다.
프롬프트는 지시(Instruction) + 맥락(Context) + 입력(Input) + 출력 형식(Output)을 갖출수록 결과가 안정적입니다.1
요약처럼 길고 복잡한 입력에서는 원문과 지시를 명확히 분리하는 방식이 작업 유지에 도움이 됩니다.2
추출/분류처럼 자동화가 목표라면, 스키마(데이터 계약)를 먼저 제시하고 JSON만 출력하게 만드는 편이 좋습니다.34
사용법: 템플릿을 '복사 → 채우기 → 재요청'으로 굴리기
각 레시피에는 대괄호 []로 표시된 자리표시자가 있습니다. 그 부분만 바꿔 넣으면 됩니다.
작업이 잘 안 될 때는 보통 프롬프트 전체를 갈아엎을 필요가 없습니다. 다음 중 하나만 조정해도 개선되는 경우가 많습니다.
입력 경계(구분자, 제공 범위)를 더 명확히 하기
출력 형식(JSON/표/목차/길이)을 더 단단히 고정하기
성공 기준(포함/제외, 우선순위)을 한 문장 더 추가하기
레시피 1) 요약(Summarization): 목적별 요약을 한 번에 뽑아내기
요약은 "짧게"보다 "무엇을 위해"가 먼저입니다. 실행 요약인지, 학습용인지, 보고용인지에 따라 뽑아야 할 정보가 달라집니다.2
템플릿: 다목적 요약(핵심 + 실행 + 질문)
[역할]
너는 [직무/분야]에서 문서를 빠르게 파악해 의사결정에 도움을 주는 요약 담당자다.
[입력 문서]
### 문서 시작
[여기에 원문을 붙여넣기]
### 문서 끝
[요청]
아래 형식으로 요약해라.
1) 한 문장 요약(최대 30자)
2) 핵심 요점 5개(각 1문장)
3) 의사결정/업무에 필요한 액션 아이템 3개(각각: 담당/기한/다음 단계 포함)
4) 불확실하거나 추가 확인이 필요한 질문 3개
[제약]
- 원문에 없는 사실은 추측하지 말고, 필요한 경우 "원문에 근거 없음"이라고 적어라.
- 숫자/기간/조건은 가능하면 원문 표현을 유지하라.
- 출력은 한국어로만 작성하라.변형: 독자 수준을 바꾸는 요약(Plain language)
의학·법률·기술 문서처럼 난도가 높다면 독자 수준을 지정해 요약 품질을 안정화할 수 있습니다.2
### 문서 시작
[원문]
### 문서 끝
위 문서를 비전문가(중학생 수준)가 이해할 수 있도록 설명하듯 요약해라.
- 분량: 약 [200~300]단어
- 전문 용어가 나오면, 문장 안에서 짧게 뜻을 덧붙여라(괄호 사용 가능)
- 반드시 다음 질문에 답하라: 목적/방법/결과/의미레시피 2) 추출(Extraction): 비정형 텍스트 → 구조화(JSON)
추출은 "요약"이 아니라 "필드 채우기"입니다. 출력이 자동 처리될 예정이라면, 스키마를 먼저 제시하고 JSON만 출력하게 만드는 접근이 유리합니다.34
템플릿: 스키마 우선 JSON 추출
너는 데이터 추출 모델이다. 아래 [스키마]에 맞춰 텍스트에서 정보를 추출하라.
[규칙]
- 출력은 오직 JSON 1개만 허용한다(설명/주석/코드블록 금지).
- 스키마에 없는 키를 추가하지 마라.
- 값이 없으면 null로 둬라.
- 근거가 불확실하면 null로 두고, 추측하지 마라.
[스키마(JSON)]
{
"doc_type": "email | meeting_notes | contract | article | other",
"entities": [
{"name": "string", "type": "person | org | product | place | other"}
],
"dates": ["YYYY-MM-DD"],
"requests": ["string"],
"decisions": ["string"],
"risks": ["string"],
"next_actions": [
{"action": "string", "owner": "string|null", "due": "YYYY-MM-DD|null"}
]
}
[텍스트]
### 시작
[여기에 원문]
### 끝현장 팁: 검증/수정 루프를 전제로 설계하기
LLM이 가끔 JSON을 깨뜨리거나 여분의 문장을 섞는 문제는 흔합니다. 그래서 실무에서는 "생성 → 검증 → (깨지면) JSON만 고치기" 같은 수리 루프를 함께 둡니다.3
레시피 3) 분류(Classification): 라벨을 고정하고 흔들림 줄이기
분류는 라벨이 곧 제품 인터페이스입니다. 라벨의 철자, 대소문자, 허용값을 확정하지 않으면 결과가 매번 조금씩 달라집니다. 필요하면 짧은 예시를 2~3개 넣어 출력 형식을 '학습'시키면 흔들림이 줄어듭니다.1
템플릿: 단일 라벨 분류(출력 고정)
너는 텍스트 분류기다.
[라벨]
- positive: 긍정/만족/추천
- neutral: 중립/사실 전달
- negative: 불만/비판/거부
[규칙]
- 출력은 라벨 1개만, 소문자로만 출력하라.
- 다른 설명은 쓰지 마라.
[입력]
[분류할 문장/문단]템플릿: 다중 라벨 분류(여러 개 가능)
너는 다중 라벨 분류기다.
[라벨]
- billing
- bug
- feature_request
- account
- other
[규칙]
- 해당되는 라벨을 모두 고르되, 최대 2개까지만 선택하라.
- 출력은 JSON 배열만 허용한다. 예: ["bug", "account"]
[입력]
[고객 문의/피드백 텍스트]레시피 4) Q&A(자료 기반 질문답변): 근거 중심으로 답하기
Q&A에서 가장 흔한 실패는 "아는 척"입니다. 해결책은 간단합니다. 답의 근거를 입력에서만 찾게 하고, 없으면 없다고 말하게 만듭니다. 또한 문서를 함께 주고 "문서 밖 지식 사용 금지"를 명시하면, 답변이 자료 중심으로 돌아옵니다.1
템플릿: 근거 인용형 Q&A
너는 [분야] 문서 기반 질의응답 도우미다.
[지시]
- 아래 문서 내용만 근거로 답하라.
- 문서에 근거가 없으면 "문서에서 확인 불가"라고 답하라.
- 답변은 (1)결론 (2)근거 (3)추가 확인 질문 순서로 작성하라.
[문서]
### 시작
[문서/노트/정책/보고서]
### 끝
[질문]
[사용자 질문]변형: 표로 답하기(정책/요건 비교)
[문서]
### 시작
[정책/요건 텍스트]
### 끝
[요청]
아래 질문에 답하되, 표로 정리해라.
열: 항목 | 허용/금지 | 조건 | 근거 문장(짧게)
질문: [질문]레시피 5) 아이디어/브레인스토밍: 양(量)과 다양성(Variety)을 분리하기
브레인스토밍은 한 번에 "좋고 다양한" 아이디어를 뽑으려 하면 흔히 평범해집니다. 그래서 작업을 두 단계로 나누는 방식이 잘 작동합니다.
1단계에서 많이 뽑고, 2단계에서 중복을 제거하며 방향을 넓힙니다.
템플릿: 2단계 브레인스토밍(생성 → 다양화)
너는 [직무/역할]로서 아이디어를 대량 생성하고, 그 다음 다양화를 수행한다.
[문제]
- 주제: [무엇에 대한 아이디어인지]
- 타깃: [대상]
- 목표: [전환/학습/홍보/문제해결 등]
- 제약: [예산/시간/채널/금지 표현 등]
[1단계: 아이디어 생성]
아이디어를 20개 제시하라. (한 줄 제목만)
[2단계: 다양화]
1단계 목록을 보고,
- 서로 비슷한 아이디어를 묶어 5개 군집으로 정리하고
- 각 군집마다 "가장 독특한 아이디어 1개"로 재작성하라.
[출력 형식]
- 군집명: ...
- 선택 아이디어: ...
- 한 줄 설명: ...레시피 6) 작성/편집(Writing & Editing): 초안 생성과 교정을 분리하기
글쓰기는 "잘 쓰기"보다 "정확히 쓰기"가 먼저입니다. 초안 생성과 편집을 한 번에 하면, 문장이 그럴듯해지는 대신 목적과 제약을 놓치기 쉽습니다.
템플릿: 글 초안 생성(목표/독자/톤/구조 고정)
[역할]
너는 [매체]에 글을 쓰는 [직무]다.
[목표]
- 글의 목적: [설득/설명/공지/리뷰/가이드]
- 독자: [누구인지, 지식 수준]
- 원하는 행동(CTA): [구독/구매/내부 공유/다음 단계]
[맥락]
핵심 소재/자료:
[메모/링크 요약/원문 발췌]
[제약]
- 분량: [예: 1,200~1,500자]
- 톤: [예: 간결하고 단정하게]
- 금지: [예: 과장 표현 금지, 경쟁사 언급 금지]
[출력]
- 제목 5개 제안 후, 가장 적합한 제목 1개를 선택해 본문 작성
- H2 소제목 3개로 구성
- 마지막에 '다음 단계' 3문장템플릿: 교정/편집(규칙 기반)
너는 편집자다. 아래 원고를 규칙에 맞게 교정하라.
[규칙]
- 의미는 유지하되, 중복·군더더기·모호한 표현을 제거하라.
- 수치/고유명사/인용은 임의로 바꾸지 마라.
- 문장 길이를 평균적으로 더 짧게 만들어라.
[출력]
1) 교정본
2) 변경 이유(중요한 것만 5개 이내)
[원고]
### 시작
[원고 본문]
### 끝레시피 7) 코드 생성(Code Generation): 요구사항을 테스트 가능하게 쓰기
코드 생성은 "코드만 달라"가 아니라 "문제 정의를 정확히 써 달라"에 가깝습니다. 언어, 입력/출력, 제약, 예시, 테스트까지 주면 품질이 크게 올라갑니다.1
템플릿: 함수/모듈 생성(입출력·예시·테스트 포함)
너는 시니어 [언어] 개발자다.
[요구사항]
- 작업: [무엇을 구현할지]
- 언어/버전: [예: Python 3.11]
- 제약: [시간복잡도/라이브러리 제한/금지 사항]
[입력]
- 입력 형식: [예: 문자열 s, 정수 k]
- 출력 형식: [예: 정수 하나]
[예시]
- 입력: ...
출력: ...
- 입력: ...
출력: ...
[품질 기준]
- 엣지 케이스를 명시적으로 처리하라: [예: 빈 입력, null, 음수, 큰 값]
- 함수에 타입 힌트/주석을 포함하라.
- 간단한 단위 테스트를 [pytest/Jest/etc]로 5개 작성하라.
[출력]
1) 구현 코드
2) 핵심 로직 설명(5문장 이내)
3) 테스트 코드변형: 코드 리뷰/리팩터링(동작 유지)
너는 코드 리뷰어다.
[목표]
- 버그 가능성, 가독성, 성능, 보안 취약점을 점검하라.
- 동작은 유지한 채 리팩터링 대안을 제시하라.
[제약]
- 변경 전/후 차이를 요약하라.
- 가능한 경우, 수정된 코드 스니펫을 함께 제공하라.
[대상 코드]
<CODE_START language="[언어]">
[코드 붙여넣기]
<CODE_END>중첩 코드블록이 필요한 환경에서는 위처럼 사용자 정의 구분자(<CODE_START> ... <CODE_END>)를 쓰는 편이 안전합니다. 마크다운 삼중 백틱 안에 다시 삼중 백틱을 넣으면 렌더러에 따라 형식이 깨질 수 있기 때문입니다.
참고
2Large Language Model Prompt Engineering for Complex Summarization - ISE Developer Blog
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.