프롬프트 작성법 치트시트

핵심: 맥락 없는 신입에게 일을 맡기듯

LLM은 똑똑하지만 우리 규칙과 사정을 전혀 모르는 신입과 같다. 원하는 것을 정확히 설명할수록 결과가 좋아진다. 검사법은 간단하다. 프롬프트를 이 일을 모르는 동료에게 보여 줬을 때 헷갈려 한다면 모델도 헷갈린다.

역할 부여("너는 숙련된 마케팅 컨설턴트다")는 답의 관점과 어휘를 그 분야에 맞춘다. 한 문장으로도 효과가 있지만, 역할만으로는 부족하다. 무엇을, 왜, 어떤 모양으로 원하는지가 함께 있어야 한다.

프롬프트를 채우는 7칸

칸	할 일	효과
1. 목표	이 결과로 무엇을 하려는지 밝힌다	모델이 우선순위를 판단할 기준이 생긴다
2. 맥락	역할, 배경, 독자, 지금까지의 사정을 준다	답의 기준점이 생긴다
3. 과제	수행할 작업을 구체적으로, 순서가 중요하면 번호 목록으로	결과물이 분명해진다
4. 세부 사항	고려할 조건과 그 이유를 덧붙인다	이유를 알면 모델이 규칙을 일반화한다
5. 제약	지킬 한계와 범위를 적는다	엉뚱한 답을 막는다
6. 형식	결과물의 구조·분량을 지정한다	바로 쓸 수 있는 모양으로 나온다
7. 예시	원하는 답의 샘플을 3~5개 보여 준다	형식·어조·구조를 가장 확실하게 맞춘다

원칙

원칙	덜 효과적	더 효과적
분명하게	"대시보드 만들어 줘"	"관련 기능과 상호작용을 최대한 넣은 분석 대시보드를 만들어 줘"
이유를 붙인다	"말줄임표 쓰지 마"	"음성 합성으로 읽히니 말줄임표는 쓰지 마. 읽을 방법이 없다"
금지 대신 할 일을	"마크다운 쓰지 마"	"매끄럽게 이어지는 산문 문단으로 써 줘"
예시는 다양하게	비슷한 예시 하나	실제 쓰임과 닮고, 가장자리 경우까지 다른 예시 여러 개를 `<example>` 태그로
구조를 나눈다	지시·자료·입력을 한 덩어리로	`<instructions>`, `<context>`, `<input>`처럼 태그나 소제목으로 구분
복잡하면 단계로	한 번에 모든 것	"먼저 분석하고, 그다음 요약하고, 그다음 실행 항목을 만들어 줘" 또는 프롬프트 여러 개로 연결
프롬프트 문체 = 출력 문체	글머리표 범벅인 프롬프트로 산문을 요구	원하는 출력과 비슷한 모양으로 프롬프트를 쓴다

대문자 강조는 아낀다. CRITICAL, MUST를 남발하면 최신 모델은 오히려 과하게 반응한다. 평범한 문장으로 쓰고 이유를 붙이는 쪽이 낫다.
"10점 만점짜리로"보다 평가 기준을 준다. 스스로 점수를 매기게 할 때도 무엇을 기준으로 볼지 적어야 개선이 일어난다.
추론 모델에는 생각 과정을 일일이 지시하지 않는다. 단계별 사고는 모델이 스스로 한다. 대신 성공 기준과 확인 방법을 준다.

역할·어조·형식 고르기

역할, 어조(Tone), 문체(Writing style), 출력 형식(Format)은 고정된 칸으로 두고 값만 바꿔 끼우면 매번 고민하지 않아도 된다. 역할에는 「숙련된」「전략적인」 같은 수식어로 전문성의 결을 한 번 더 지정한다.

쓰임	역할	어조·문체	제약·형식
제품 소개 글	숙련된 카피라이터	친근한 어조, 이점 중심	한국어, 간결한 문장, 글머리표 5개 이내
시장 조사 요약	데이터 사이언티스트	사실 기반, 비교형	신뢰할 수 있는 출처를 밝히고, 표로
사용자 인터뷰 정리	UX 리서처	정보 전달형, 해결책 중심	구체적인 이름은 `{Name}` 같은 변수로 바꾸고, JSON으로

글의 AI 티 줄이기

LLM이 쓴 글에는 읽는 사람이 바로 알아채는 버릇이 있다. 영어 표현을 그대로 옮긴 번역투(「조용히 실패했다」, 「파괴적인 영구 손상 작업」), 문장마다 끼어드는 긴 줄표(em dash), 뜻보다 무게만 있는 수식어가 대표적이다. 「자연스럽게 써 줘」 같은 막연한 요청보다 검증된 문체 규칙을 이름으로 주는 쪽이 잘 듣는다.

방법	하는 일	효과
오웰의 여섯 규칙	조지 오웰이 「정치와 영어(Politics and the English Language)」(1946)에 적은 규칙을 지시나 스킬로 넣는다: 흔한 비유를 쓰지 않는다, 짧은 단어가 되면 긴 단어를 쓰지 않는다, 뺄 수 있는 단어는 뺀다, 능동태로 쓴다, 일상어가 있으면 외래어·전문어를 쓰지 않는다, 어색해질 바에는 규칙을 깬다	상투어와 군더더기가 준다
ASD-STE100	항공 정비 문서용 통제 언어 「Simplified Technical English」 규칙에 맞추게 한다: 한 단어 한 뜻, 절차 문장은 20단어 이하, 한 문장에 지시 하나, 능동태·명령문	기술 문서·절차가 짧고 모호하지 않게 된다
개조식 먼저	내용을 글머리표로 먼저 쓰게 하고, 단어 선택을 따로 검토한 뒤 문장으로 푼다	내용과 표현을 나눠 고칠 수 있다
독자와 장르 지정	「상급자에게 올리는 보고 문서처럼」, 「현업 전문가가 쓰듯」	감탄·과장 없이 결론 먼저 쓰는 문체로 바뀐다
다듬기 단계 분리	쓰는 프롬프트와 다듬는 프롬프트(스킬)를 나눈다. 다듬기 단계에는 금지 표현 목록과 바꿀 표현을 함께 준다	한 번에 다 시킬 때보다 버릇이 덜 남는다

금지 표현 목록만 주면 비슷한 다른 상투어로 바꿔 쓰기 쉽다. 위 「금지 대신 할 일을」 원칙대로 바꿔 쓸 방법(쉼표·괄호로 잇기, 문장 나누기)까지 적는다. 한국어 글의 문장 규칙은 에코의 글쓰기 규칙과 글쓰기 원칙: 구조, 설득, 문장력에 있다.

앱에 넣는 프롬프트: 구성 요소

앱 안의 프롬프트는 앱과 모델 사이의 구조화된 계약이다. 구성 요소별로 나눠 두면 각각 버전 관리·테스트·개선할 수 있고, 팀이 함께 보는 산출물이 된다. 위의 7칸을 앱 관점에서 다시 나누면 이렇다.

구성 요소	역할	블로그 제목 생성기 예
맥락(Context)	모델의 역할과 도메인	"블로그 작성자를 돕는 글쓰기 도우미다"
지시(Instruction)	할 작업	"주어진 스타일로 대안 제목 3개를 만든다"
입력 변수(Input variables)	앱이 실시간으로 넣는 값	`${blogPostContent}`, `${titleStyle}`
출력 형식(Output format)	기대하는 구조	`{ "titles": [...] }` JSON만
예시(Examples)	다른 입력에 대한 모범 답	입력 JSON → 출력 JSON 한 쌍
제약(Constraints)	일관성·안전·브랜드를 지키는 한계	128자 미만, 초안 문장 복사 금지, 이모지·낚시성 표현 금지

지시와 출력 형식만으로 시작하고, 결과를 보며 필요한 구성 요소를 하나씩 더한다. 정보마다 목적이 분명해야 한다. 예시나 세부가 너무 많으면 모델이 헷갈리고, 지연과 비용(서버 모델이라면)이 늘어난다. 어떤 구성 요소를 더할지는 평가 주도 개발로 정한다. 시스템 프롬프트와 사용자 프롬프트에 어떻게 나눌지는 시스템 프롬프트 설계 패턴에 있다.

프롬프트 기법 네 가지

기법	방법	잘 맞는 곳	주의
제로샷(Zero-shot)	작업만 설명한다	백과사전식 질문 같은 단순한 작업. 모든 개선의 기준선	실서비스에선 대개 조건과 논리를 더해야 한다
퓨샷(Few-shot)	입력 → 출력 예시를 보여 준다	감성 분류 같은 유사 예측 과제, 제목 생성처럼 구조가 뚜렷한 작업	출력 공간이 넓은 장문·열린 작업은 예시로 덮을 수 없다
생각의 사슬(Chain-of-thought)	답하기 전에 단계별로 추론하게 한다. 단계를 지정하거나 모델에게 맡긴다	글 개요 짜기, 복잡한 의사 결정. 추론 모델의 핵심 원리	추론 과정만큼 계산·비용·지연이 늘어난다. 정말 필요할 때만
자기 성찰(Self-reflection)	첫 출력을 모델이 비평하고 고치게 한다	편집·다시 쓰기처럼 반복 개선이 이득인 작업	기본 프롬프트가 잘 돌아간 뒤에 얹는다

퓨샷 예 (감성 분류)
사용자 메시지를 "positive" / "negative" / "neutral" 중 하나로 분류한다.
Input: "I love this product! It works perfectly."   Output: { "label": "positive" }
Input: "This is terrible. I want a refund."          Output: { "label": "negative" }

기법을 고를 때는 이 과제가 유추(퓨샷), 단계적 추론(생각의 사슬), 반복 개선(자기 성찰) 중 무엇으로 가장 잘 풀리는지 묻는다. 모델마다 권장 방식이 다르니 쓰는 모델의 공식 프롬프트 가이드도 확인한다.

더 깊게 시키기: 야심의 네 방향

모델에게 일을 맡길 때 같은 일을 빨리 하는 데서 멈추면 능력의 일부만 쓴다. 야심(ambition)을 네 방향으로 나눠 보면 무엇을 더 요구할지 보인다.

방향	뜻	요구하는 법
속도(Speed)	같은 일을 더 빨리	기본값. 따로 궁리할 것이 적다
고도(Altitude)	작업이 아니라 그 뒤의 결과를 맡긴다	「다음에 무슨 일이 일어나길 바라나」를 묻는다. 버그 하나 고치기 → 앱을 크래시 없이 유지하기. 회의 자료 만들기 → 가장 급한 결정 세 개와 찬반 근거 뽑기 → 그 회의가 존재하는 목적을 더 잘 이루는 방식 설계하기. 대신 모델이 혼자 돌 수 있게 데이터 접근, 재현·검증 환경을 먼저 만들어 줘야 한다
깊이(Depth)	그 분야 최고 전문가처럼 한 층 더 내려간다	전문가의 어휘가 아니라 도구와 방법을 쓰게 한다(마크다운 표 대신 데이터베이스와 통계 모델). 비현실적으로 높은 목표를 당연한 듯 제시한다(10초 → 5초가 아니라 200ms). 원자료를 주고 믿고 있던 가정을 반박해 보게 한다. 검증은 모델 자신이 아니라 바깥의 판정자(돌려 볼 수 있는 도구)에게 맡긴다
범위(Range)	여러 분야의 관점과 기법을 끌어온다	명사를 동사로 바꾼다(「분기 보고서」 → 「바쁜 사람들이 30분 안에 인과관계를 믿고 불확실한 결정을 내리게 하기」). 그 일에 필요한 팀(분석가, 기자, 편집자, 공매도 투자자, 포렌식 회계사)을 꾸려 각 분야가 무엇을 하는지를 묻는다. 그 사람처럼 쓰게 하는 역할극은 결과를 낫게 하지 않는다

깊이를 끌어내는 메타 프롬프트

프롬프트를 고쳐 쓰기 전에 모델이 먼저 네 가지에 답하게 하고, 그 답대로 프롬프트를 다시 쓰게 한다. 목표는 더 크게가 아니라 더 깊게다.

이 작업을 더 크게가 아니라 더 깊게 하고 싶다. 다시 쓰기 전에
1) 이 분야 최고 전문가라면 내가 요청하지 않은 어떤 일을 더 할지 말하고,
2) 이미 가공된 자료 말고 그들이 출발점으로 삼을 가장 원시적인 자료를 짚고,
3) 그들이 쓸 구체적인 방법과 도구를 대고,
4) 너나 나 말고 무엇이 결과가 맞다는 걸 보여 줄지 말하라.
그다음 정확히 그것을 요구하도록 내 프롬프트를 다시 써라.

그 밖의 요령

목표를 먼저 정의한다. 무엇을 얻고 싶은지 모르면 프롬프트도 흐려진다.
결과를 확인할 기준을 정해 둔다. 기준이 있어야 프롬프트를 고쳤을 때 나아졌는지 안다.
세부 사항은 많을수록 좋지만, 정리해서 준다. 긴 자료는 앞에, 질문은 끝에 둔다.
여러 모델·대화를 역할별로 나눠 쓴다. 한 결과를 다음 단계의 입력으로 넘긴다.
답을 평가하고 피드백한다. 한 번에 끝내지 말고 고쳐 가며 다듬는다.
결과가 기대와 다르면 「내가 무엇을 요청하지 않았나」부터 찾는다. 말하지 않은 상식적 요구를 알아서 채우지 못하는 것은 사람도 같다. 빠진 요구사항, 다음에 미리 적을 것, 예시로 들 다른 앱의 기능을 기록해 두고 다음 프롬프트에 넣는다. 모델 등급보다 요구사항을 명확히 적는 쪽이 결과에 더 크게 영향을 준다.

정리

프롬프트는 목표 + 맥락 + 과제 + 제약 + 형식 + 예시의 조합이다.
규칙에는 이유를 붙이고, 금지보다 할 일을 적는다.
예시는 형식을 맞추는 가장 확실한 방법이다.
역할·어조·형식은 칸을 정해 두고 값만 바꿔 끼운다.
글의 AI 티는 오웰 규칙·ASD-STE100 같은 이름 있는 문체 규칙과 별도 다듬기 단계로 줄인다.
빠르게 하는 데서 멈추지 말고 고도(결과를 맡기기), 깊이(전문가의 도구와 바깥 검증), 범위(여러 분야의 기법)로 요구를 넓힌다.
기법은 제로샷 기준선에서 시작해 퓨샷 → 생각의 사슬 → 자기 성찰 순으로 필요한 만큼만 더한다.
AI는 마음을 읽지 못한다. 원하는 것을 말로 꺼내 놓는 만큼 답이 좋아진다.

버그 제보