LLM을 지배하는 건 코드가 아니라 프롬프트다

 

결과물 중심의 접근과 달리 프롬프트 엔지니어링 자체를 깊이 있게 탐구한 실전 가이드다. LLM의 구조와 작동 원리, 효과적인 프롬프트 설계 기법, 대화형 워크플로 구성, 성과 평가까지 실무에 필요한 내용을 체계적으로 다룬다. 특히 ‘모델이 학습한 패턴을 모사하는 프롬프트를 설계해야 원하는 출력을 얻을 수 있다’는 원칙을 중심으로, 명확한 언어 사용과 검증된 패턴의 활용, 정보 최소화 등 실질적인 전략을 제시한다. 프롬프트를 ‘쓰는 법’이 아니라 ‘왜 그렇게 써야 하는지’를 설명하며, 시행착오를 줄이는 이론적 기반을 제공한다. 단순한 활용법을 넘어 LLM을 도구로 활용하는 사고방식 자체를 훈련할 수 있게 돕는다.

[목 차]

옮긴이 머리말 ix

베타리더 후기 x

시작하며 xii

감사의 글 xv

표지에 대하여 xvi

 

PART I 기본 원리

CHAPTER 1 프롬프트 엔지니어링 소개 3

1.1 LLM은 마법이다 4

1.2 언어 모델: 어쩌다 우리가 여기까지 왔지? 7

1.3 프롬프트 엔지니어링 14

1.4 요약 16

 

CHAPTER 2 LLM의 이해 18

2.1 LLM은 무엇인가? 19

2.2 LLM이 세상을 보는 방법 26

2.3 한 번에 토큰 한 개 33

2.4 온도와 확률 37

2.5 트랜스포머 아키텍처 41

2.6 요약 47

 

CHAPTER 3 대화형으로 넘어가기 48

3.1 인간 피드백을 통한 강화학습 50

3.2 지시형에서 대화형으로 56

3.3 지금도 변하고 있는 API 61

3.4 극본 작성으로서의 프롬프트 엔지니어링 67

3.5 요약 69

 

CHAPTER 4 LLM 애플리케이션 설계하기 71

4.1 루프 구조 71

4.2 순전파 확대해보기 82

4.3 LLM 애플리케이션 품질 평가 89

4.4 요약 91

 

PART II 핵심 기술

CHAPTER 5 프롬프트 내용 95

5.1 콘텐츠 출처 97

5.2 정적 콘텐츠 98

5.3 동적 콘텐츠 110

5.4 요약 134

 

CHAPTER 6 프롬프트 구성하기 135

6.1 이상적인 프롬프트 구조 135

6.2 어떤 종류의 문서인가? 139

6.3 스니펫 형식 지정하기 150

6.4 탄력적 스니펫 153

6.5 프롬프트 요소 간 관계 155

6.6 최종 프롬프트 구성 157

6.7 요약 161

 

CHAPTER 7 모델 제어 162

7.1 모델 제어 162

7.2 텍스트를 넘어서: 로그 확률 168

7.3 모델 선택 175

7.4 요약 182

 

PART III 전문가 역량

CHAPTER 8 대화형 에이전시 187

8.1 도구 활용 188

8.2 추론 201

8.3 작업 기반 상호작용을 위한 콘텍스트 208

8.4 대화형 에이전트 구축 213

8.5 요약 219

 

CHAPTER 9 LLM 워크플로 221

9.1 대화형 에이전트로 충분할까? 223

9.2 기본 LLM 워크플로 226

9.3 고급 LLM 워크플로 242

9.4 요약 246

 

CHAPTER 10 LLM 애플리케이션 평가 247

10.1 LLM 애플리케이션 평가 248

10.2 오프라인 평가 249

10.3 온라인 평가 265

10.4 요약 269

 

CHAPTER 11 미래를 전망하며 270

11.1 다중 모달 처리 271

11.2 요약 277

 

찾아보기 279

[본 문]

사람과 마찬가지로 LLM도 단일 문자를 읽지 않는다. 모델에 텍스트를 전송하면 처음에는 텍스트를 토큰(token)이라고 부르는 여러 문자로 구성된 단위(chunk)로 나뉜다. 일반적으로 서너 자 길이지만 일반적인 단어나 문자 시퀀스에 대한 더 긴 토큰도 있다. 모델에서 사용되는 토큰 집합을 어휘(vocabulary)라고 한다. / 텍스트를 읽을 때 모델은 먼저 토크나이저(tokenizer)를 통해 텍스트를 토큰 시퀀스로 변환한 다음 LLM에 전달된다. 그러면 LLM은 일련의 토큰(내부에서는 숫자로 표현된다)을 생성하고, 이는 다시 텍스트로 변환된 다음 사용자에게 반환된다. (27쪽)

 

현대 LLM에서 이 Q&A 메커니즘은 마스킹(masking)이라고 하는 하나의 제약을 더 따른다. 모든 미니브레인이 질문에 답할 수 있는 것은 아니다. 질문을 한 미니브레인의 왼쪽에 있는 미니브레인만 그 질문에 답할 수 있다. 그리고 미니브레인은 자신의 답변이 사용됐는지 결코 알 수 없으므로 오른쪽에 있는 미니브레인은 왼쪽에 있는 미니브레인에 결코 영향을 미칠 수 없다. (45쪽)

 

퓨샷 프롬프트는 콘텍스트가 커질수록 확장성이 떨어지고, 결과가 예시에 편향되며, 잘못된 패턴(spurious pattern)을 유도할 수 있다. 이렇게 여러 문제가 있음에도 불구하고, 퓨샷 프롬프트를 사용할 가치가 있을까? 경우에 따라 다르다. 퓨샷 프롬프트는 모델에게 사용자 질문의 다양한 측면을 명확하게 설명해주는 데 가장 쉬운 방법이며, 이러한 위험성은 신중한 평가 과정을 거침으로 완화시킬 수 있다(10장). 따라서 사용자 문제 도메인이 모델에게 불명확한 특정 측면을 포함하고 있고, 프롬프트 공간이 충분히 크고, 편향을 피하기 위해 주의를 기울였다면 퓨샷 프롬프트는 유용한 프롬프트 엔지니어링 도구가 될 수 있다. (110쪽)

 

완성형 모델을 사용하는 경우 인셉션(inception)이라는 기법을 사용할 수 있다. 이 기법은 응답의 시작 부분을 사용자가 직접 작성한다. (...) 응답의 서두를 사용자가 먼저 작성하면, 모델은 자신이 그 답을 시작한 것으로 생각하고 그에 맞춰 나머지 결과도 생성한다. 이 방식은 모델의 지시 준수도를 개선시키고 답변을 파싱하기 쉽게 만들 뿐 아니라 답변이 일반적인 진술로 시작할지 아니면 바로 요점을 짚을지에 대한 불확실성을 피하는 데 도움이 된다. (140쪽)

 

작업이 명확하게 잘 정의됐다면 각 작업에 대한 예제 데이터를 수집해 작업을 개선할 수 있다. 작업 구현 결과가 운영 환경에 반영되기 전에 오프라인에서 프롬프트를 실행해보고 그 결과가 기대한 행동과 일치하는지 점검하는 하네스 테스트(harness test)를 만들어야 한다. 이렇게 해두면 프롬프트를 변경할 때 해당 작업 품질을 저하시키지 않고도 안전하게 배포하기 쉬워진다. 입출력 예시 데이터는 최근 등장한 최적화 기법인 DSPy(https://arxiv.org/abs/2310.03714)와 TextGrad(https://arxiv.org/abs/2406.07496)에서도 유용하게 쓰인다. 이 프레임워크는 I/O 예제를 활용해 프롬프트를 최적화해 제공된 지표에 따라 측정된 품질을 자동으로 향상시킬 수 있다. (241쪽)

 

만약 제안을 직접적으로 평가할 수 없다면 대부분의 애플리케이션은 사용자가 해당 제안을 수락할지 또는 최소한 수락하려는 단계를 취했는지 여부를 점검할 수 있다. 예를 들어, 사용자가 실제로 시카고 여행을 예약했는지를 확인할 수 있다. 제안 내용에 링크가 포함되어 있다면 사용자가 해당 링크를 얼마나 자주 클릭했는지를 나타내는 클릭률(click-through rate)처럼 직접적일 수 있다. 이 지표는 제안 내용이 괜찮아 보였는지만 확인하지 실제로 유용했는지를 확인할 수 없다. 그렇지만 이 지표는 매우 중요한 출발점이 되는 경우가 많다. / 이는 코파일럿에서 발견한 사실(https://oreil.ly/qwR21)이기도 하다. 우리는 이 수용 지표가 사용자들이 느낀 생산성 향상과 함께 매우 강한 상관관계가 있다는 것을 발견했다. (268쪽)