- 출처 : AI 시대의 질문력 프롬프트 엔지니어링 / 류한석 지음
1. 기본 개념
- LLM : Large Language Model : 대규모 언어 모델
- 모델 : 추상화 도구
2. 프롬프트 엔지니어링이 중요한 이유
- 동일한 AI 모델을 사용하더라도 프롬프트 설계에 따라, 사용자의 역량에 따라 완전히 다른 품질의 결과물을 출력할 수 있다.
- AI모델은 맥락에 민감하다.
3. 프롬프트 3가지 유형
- 서술형
- 지침형
- 함수형
4. 프롬프트 제어 시 글자 수 제어가 어려운 이유
- 토큰 기반 처리
- 확률적 예측 방식
- 정확한 길이 추적의 어려움
4-1. Q
- 질문 내용 :
LLM이 글자 수를 판단하기에는 정홛한 계산이 어려운 걸로 알고 있어.
토큰 수로 계산해야되는데 그것도 한계가 있는 걸로 알고 있는데
만약 프롬프트에 짧게 길게 간단히 자세히 라고 명시를 했을 때
각 단어 별 글자 수는 대략 몇이 되는지 알려줘
4-2. A
맞아. LLM은 “정확히 N글자”를 맞추는 데 약하고, 보통은 토큰 단위 + 문맥적 감각으로 길이를 조절해.
그래서 프롬프트에 쓰는 “짧게 / 길게 / 간단히 / 자세히”는 정확한 글자 수라기보다 응답 밀도와 범위에 대한 신호에 가깝다.
대략 이렇게 잡으면 돼.
| 표현 | LLM이 보통 이해하는 느낌 | 한국어 기준 대략 글자 수 |
|---|---|---|
| 짧게 | 핵심만, 1~3문장 | 약 100~300자 |
| 간단히 | 핵심 설명 + 최소 예시 | 약 300~700자 |
| 길게 | 배경 설명 포함, 여러 문단 | 약 1,000~2,500자 |
| 자세히 | 원리, 예시, 비교, 주의점 포함 | 약 1,500~4,000자 이상 |
조금 더 실무적으로 쓰면 이렇게야.
짧게 설명해줘
→ 3문장 이내, 200자 안팎
간단히 설명해줘
→ 핵심 개념 + 예시 1개, 500자 안팎
자세히 설명해줘
→ 원리, 예시, 장단점 포함, 2,000자 안팎
길게 설명해줘
→ 배경부터 단계적으로, 2,000~3,000자 이상
다만 “길게”와 “자세히”는 다르다고 보는 게 좋아.
길게는 분량 중심이야. 문장이 많고 설명이 늘어날 가능성이 커.
자세히는 밀도 중심이야. 분량도 늘지만, 더 중요한 건 빠뜨리지 말고 구조적으로 설명하라는 뜻에 가깝다.
그래서 프롬프트 품질만 보면 보통은 이렇게 쓰는 게 더 정확해.
500자 이내로 간단히 설명해줘.
핵심 개념 3개만 bullet로 정리해줘.
예시는 1개만 포함해줘.
또는
초보자가 이해할 수 있게 1,500자 내외로 자세히 설명해줘.
원리 → 예시 → 주의점 순서로 작성해줘.
정리하면, 단어별 감각은 이 정도로 보면 돼.
짧게 ≈ 100~300자
간단히 ≈ 300~700자
자세히 ≈ 1,500~4,000자
길게 ≈ 1,000~3,000자 이상
프롬프트에서 가장 안정적인 건 “짧게/자세히” 같은 감각어 + 글자 수/문장 수/항목 수 제한을 같이 주는 것이야.
5. Example 구분 : 제로샷, 원샷, 퓨샷 프롬프팅
1. 제로샷
- 단순하고 명확한 질문
- 일반적인 지식이나 정보를 요청
- 모델이 익숙한 패턴의 작업을 요청할 때
- 빠른 답변이 필요하고 정확도가 크게 중요하지 않는 경우
2. 원샷
- 하나의 예시만으로도 모델이 사용자의 의도를 충분히 파악할 수 있을 때
- 하나의 예시로 일관된 출력을 유도할 수 있을 때
- 모델이 작업의 전반적인 맥락은 이해하고 있지만, 출력 형식이나 표현 바식에 대한 명확한 가이드가 필요할 때
- 특정 문체, 톤, 형식 등의 예시를 통해 원하는 스타일을 모델에 전달하고자 할 때
3. 퓨샷
- 매우 일관성 있는 형식으로 출력을 유도하고 싶을 때
- 복잡하거나 추상적인 과제에 대해 모델이 올바른 방향을 잡기 어려운 상황에서 여러 개의 예시를 통해 작업 방식이나 기대 출력을 명확히 전달하고자 할 때
- 분류, 요약, 변역 등 비교적 명확한 입력-출력 쌍이 있는 작업에서 정답률을 높이고 싶을 때
- 예시들을 기반으로 패턴을 일반화하여 새로운 입력에도 적절히 대응할 수 있도록 할 때
- 다양한 케이스를 포괄하는 규칙을 이해시키고 싶을 때
5-1. Q
- 질문 내용 :
프롬프트에 적절한 예시를 줄 때
제로샷, 원샷, 퓨 샷을 적절히 사용해서 구분하는데
이에 대한 의도에 따른 결과를 미리 어떻게 판단하지?
세 번 다 테스트를 해보고 결정하는 건가?
5-2. A
꼭 제로샷 / 원샷 / 퓨샷을 전부 테스트해보고 결정해야 하는 건 아니야. 실무에서는 먼저 의도와 출력 난이도를 보고 예측한 다음, 애매한 경우에만 비교 테스트하는 게 효율적이야.
핵심은 이거야.
모델이 이미 잘 아는 일은 제로샷 출력 형식이나 톤을 맞춰야 하면 원샷 판단 기준이 미묘하거나 패턴을 학습시켜야 하면 퓨샷
| 작업 | 제로샷 적합도 |
|---|---|
| 요약 | 높음 |
| 번역 | 높음 |
| 일반 설명 | 높음 |
| 맞춤법 교정 | 높음 |
| 간단한 분류 | 높음 |
| 코드 설명 | 높음 |
예상 결과 제로샷은 빠르고 간단하지만, 출력 스타일이 약간 흔들릴 수 있어.
예를 들어 “간단히 요약해줘”라고만 하면 어떤 때는 3줄, 어떤 때는 7줄이 나올 수 있어. 즉, 정확한 형식보다 의미 전달이 중요할 때 좋다.
| 작업 | 원샷 적합도 |
|---|---|
| 특정 답변 포맷 맞추기 | 높음 |
| 말투 맞추기 | 높음 |
| 보고서/블로그 스타일 맞추기 | 높음 |
| 카드뉴스 문장 스타일 | 높음 |
| 특정 예시 구조 반복 | 높음 |
예상 결과
원샷은 모델이 “아, 이런 형식이구나” 하고 따라갈 확률이 높아져.
다만 예시가 하나뿐이라서 모델이 그 예시에 너무 끌려갈 수 있어. 예를 들어 예시에 Redis가 나오면, 다음 답변에서도 Redis식 비유나 구조를 과하게 따라 할 수 있다.
그래서 원샷은 형식은 중요하지만 판단 기준이 복잡하지 않을 때 쓰는 게 좋아.
| 작업 | 퓨샷 적합도 |
|---|---|
| 미묘한 감정 분류 | 높음 |
| 회사 내부 기준에 따른 분류 | 높음 |
| 상품 리뷰 라벨링 | 높음 |
| CS 문의 유형 분류 | 높음 |
| 좋은 답변/나쁜 답변 기준 학습 | 높음 |
| 특정 문체 재현 | 높음 |
예상 결과
퓨샷은 출력 안정성이 높아져. 대신 프롬프트가 길어지고, 예시 품질이 나쁘면 오히려 결과가 망가져.
특히 퓨샷은 예시의 다양성이 중요해. 비슷한 예시만 5개 넣는 것보다, 경계가 다른 예시 3개가 훨씬 낫다.
실무 판단표
| 상황 | 추천 방식 |
|---|---|
| 일반 설명, 요약, 번역 | 제로샷 |
| 간단한 형식 지정 | 제로샷 + 명확한 포맷 지시 |
| 특정 답변 스타일이 필요함 | 원샷 |
| 결과물 샘플과 비슷하게 만들어야 함 | 원샷 |
| 분류 기준이 애매함 | 퓨샷 |
| 회사/서비스 내부 규칙이 있음 | 퓨샷 |
| 좋은 예/나쁜 예를 구분해야 함 | 퓨샷 |
| 실패 비용이 큼 | 퓨샷 + 테스트 |
6. 페르소나
1. 패턴
- 모델에 지시를 내리는 프롬프트를 일정한 형식이나 구조로 만드는 방식
2. 페르소나 패턴 사용 이유
- 모델의 사고 능력을 특정한 관점이나 전문성에 맞춰 조정한다.
- 사용자가 원하는 더욱 맞춤화되고 깊이 있는 응답을 제공하도록 한다.
- 기술적 단계를 거쳐 응답을 생성
- 입력 처리
- 컨텍스트 이해
- 응답 생성
- 응답 최적화
- 출력 제공
3. 튜링 테스트
- AI의 발전을 측정하는 대표적인 기준
- 인간과 구별할 수 없을 정도로 인간답게 행동할 수 있는지를 평가하는 방법
4. AGI (Artificial General Intelligence, 인공일반지능)
- 정의 : AI 연구의 중대한 목표로, 인간과 동등하거나 그 이상의 범용적인 사고 능력을 지닌 AI 시스템을 의미
- 다양한 상황과 문제에 유연하게 적응하고 대응할 수 있는 보편적 지능을 갖추고 있다.
7. 마크다운
1. 이점
- 가독성 향상
- 모델의 이해도 향상
- 일관성 유지
- 프롬프트 재사용
2. 마크다운 문법
- 제목
# ~ ###### (6개)
- 강조
- 이탤릭
- 강조
취소
- 목록
- -,+,* 중 하나로 시작
- 링크
- 이미지
- 
- 코드
print("Hello")코드블록
- 인용문
로 시작
- 수평선
- ***, ---
- 표
8. 간단한 프롬프트 공식
"역할 부여" + "배경 정보 제공" + "작업 지시" + "출력 형식 정의"
9. GKP (Generated Knowledge Prompting)
- 두 단계로 나눠서 요청하는 것 (이중 프롬프트 방식)
- 모델이 스스로 추론해서 새로운 지식을 만들어낸다는 게 핵심이다.
10. 프롬프트 강화 3가지 전략
- 맥락 반영 (Context)
- 시간적 맥락
- 지리적 맥락
- 감정적 맥락
11. RAG : 검색 - 증강 - 생성
- 최신정보 활용
- 정확성 향상
- 투명성
- 맞춤형 지식 통합
- 유연성
12. 프롬프트 패턴의 역할, 한계
- 프롬프트 패턴의 특징
- 일관성
- 반복 사용
- 구조화된 접근
- 효율성 향상
- 기반 지식 확립
13. 템플릿 패턴
- 핵심 (플레이스홀더) 활용
14. 대안접근법 패턴
- 처리 단계
- 문제 인식과 분석
- 대안 탐색
- 장단점 분석
- 추천 제공
모델에 특정 작업이나 문제 해결을 요청할 때, 사용자가 제시한 방안 외에 다른 여러가지 대안을 찾아서 제안하도록 하는 방법
15. 이용자 페르소나 패턴
- 누구를 대상으로 답변하는 지에 따라 다른 형태로 답변을 조정.
- 예시
나를 [대상]이라고 가정하고
16. 인지 검증자 패턴
복잡한 문제를 더 잘 다루는 방법
자연스러운 사고의 흐름을 모델에 안내하는 효과적인 방법
예시
정확한 결론을 도출하기 위해 질문을 다양한 세부 질문으로 나누어서 답변을 작성합니다. 모든 답변을 종합적으로 판단해서 결론을 작성해 주세요.구체적 방법
- 명확한 지시어 구성
- "이 질문에 답하기 위해 먼저 필요한 하위 질문들을 나열하고, 각각에 답한 후 종합적 결론을 도출하세요."
- "이 문제를 해결하기 위해 단계적으로 접근하되, 각 단계마다 필요한 정보를 분석하고 검증한 후 진행하세요."
- 답변 구조화 요청
다음 구조로 답변해 주세요 1. 하위 질문 목록 2. 각 하위 질문에 대한 분석 3. 종합적 결론 4. 추가 고려사항 - 적절한 복잡성 수준 설정
- 간단한 문제 : "2~3개의 핵심 하위 질문으로 나누어 분석하세요."
- 복잡한 문제 : "이 문제를 최소 5개의 서로 다른 관점에서 검토하고, 각 관점별로 필요한 하위 질문들을 생성하여 분석하세요."
- 상반된 관점 요청
- "이 질문을 분석할 때 찬성과 반대 입장 모두에서 하위 질문을 생성하고 검토하세요."
- 메타인지 활용 강화
- "각 하위 질문에 답한 후, 그 답변의 신뢰 수준을 평가하고, 어떤 제약이나 불완전한 점이 있는지도 함께 설명해 주세요."
- "결론을 내리기 전에, 중요한데도 간과된 측면이 있는지 다시 한번 점검해 주시기를 바랍니다."
- 명확한 지시어 구성
17. 메타언어 생성 패턴
- 우리만의 약속이나 단축키 같은 것 사용
- 기본 원칙
- 간결성
- 명확성
- 일관성
- 확장성
- 예시
당신은 내 학습 코치입니다. 내가 "CHECK:[내용]"이라고 하면: - 내용에 철차/문법 오류가 있으면, 수정사항을 알려주세요. - 내용이 정확하면 "학습 완료:[잘한 점]"이라고 응답해 주세요.
18. 무한 생성 패턴
- 사용자가 같은 프롬프트를 반복해서 입력하지 않고도 계속해서 LLM의 출력을 자동으로 생성하는 강력한 방법
- 예시
[출력]을 한번에 [단위]개씩 무한 생성해 주세요.
19. 거부 차단기 패턴
- LLM으로부터 답변을 거부당할 때, 모델에게 그 이유와 대안을 알려달라고 요구하는 방법
- 정책 필터
- 부적절한 내용 차단
- 저작권 보호
- 개인정보 보호
- 예시
당신이 다음의 내 질문에 답변할 수 없다면, 왜 답변할 수 없는지 설명해 주세요. 그리고 답변할 수 있는 다른 방식으로 질문을 재구성해서 알려주세요: [질문]" - 패턴 효과적 사용 방법
- 단계적 대화 전략
- 교육적 목적 명시
- 가상 시나리오 활용
20. 5W1H 프레임워크의 활용
- 누가, 무엇을, 언제, 어디서, 왜, 어떻게 요소를 포함됨
- 모델에게 제공하는 정보와 맥락을 명확히 하여, 모델이 보다 정확한 답변을 제공할 수 있음
- 한계
- 유연성 부족
- 과도한 정보 제공
- 창의적인 해결책의 제한
21. 프롬프트 프레임워크
CO-STAR 프레임워크
- Context (배경 정보, 맥락)
- Objective (목표)
- Style (스타일)
- Tone (톤, 말투, 어조)
- Audience (독자, 청중)
- Response (응답 형식)
FOCUS 프레임워크
- Function (해야 할 일)
- Objective (목표 설정)
- Context (배경 정보, 맥락)
- Utility (용도)
- Specifications (세부사항)
ROSES 프레임워크
- Role (역할)
- Objective (목표)
- Scenario (상황)
- Expected Solution (기대 결과)
- Steps (단계)
RISEN 프레임워크
- Role (역할)
- Instructions (지시사항)
- Steps (단계)
- Expectations (기대치)
- Narrowing / Novelty (범위 좁히기 / 창의성 강화)
BAB 프레임워크
- Before (이전 상황)
- 문제의 명확한 정의
- After (이후 상황)
- 성과의 구체적인 정의
- Bridge (변화의 다리)
- 핵심 솔루션 요청
22. CoT 기법
정의 : Chain-of-Thought는 LLM의 사고 과정을 인간의 논리적 추론 과정과 유사하게 구조화하여 복잡한 문제 해결 능력을 끌어 올리는 기법
구체적 방법
- 단계 설정
- 추론 과정 유도
- 메타인지적 접근 활용
- 반복적 개선 활용