프롬프트 작성법 치트시트

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

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으로

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

앱 안의 프롬프트는 앱과 모델 사이의 구조화된 계약이다. 구성 요소별로 나눠 두면 각각 버전 관리·테스트·개선할 수 있고, 팀이 함께 보는 산출물이 된다. 위의 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" }

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

그 밖의 요령

목표를 먼저 정의한다. 무엇을 얻고 싶은지 모르면 프롬프트도 흐려진다.
결과를 확인할 기준을 정해 둔다. 기준이 있어야 프롬프트를 고쳤을 때 나아졌는지 안다.
세부 사항은 많을수록 좋지만, 정리해서 준다. 긴 자료는 앞에, 질문은 끝에 둔다.
여러 모델·대화를 역할별로 나눠 쓴다. 한 결과를 다음 단계의 입력으로 넘긴다.
답을 평가하고 피드백한다. 한 번에 끝내지 말고 고쳐 가며 다듬는다.

정리

프롬프트는 목표 + 맥락 + 과제 + 제약 + 형식 + 예시의 조합이다.
규칙에는 이유를 붙이고, 금지보다 할 일을 적는다.
예시는 형식을 맞추는 가장 확실한 방법이다.
역할·어조·형식은 칸을 정해 두고 값만 바꿔 끼운다.
기법은 제로샷 기준선에서 시작해 퓨샷 → 생각의 사슬 → 자기 성찰 순으로 필요한 만큼만 더한다.
AI는 마음을 읽지 못한다. 원하는 것을 말로 꺼내 놓는 만큼 답이 좋아진다.

버그 제보