How to use this book

Who this book is for

This book is for backend and full-stack developers who put LLM features into real products, and for engineers who move AI feature PoCs (proofs of concept) into production. At least one year of experience working with HTTP APIs is sufficient. If requests and responses, status codes, retries and JSON are familiar terms, you can follow almost everything in this book.

The gap between a PoC and a production feature is larger than it may seem. A PoC aims to “work reasonably well”. In production, among tens of thousands of daily calls, one malformed response, one payment executed twice or one unexpected cost increase becomes a problem. This book focuses on closing that gap. It does not cover training models yourself or operating GPU clusters. It covers using a provider's LLM API safely and economically as one component of an application.

How this book is organized

The main text covers the five domains of the Promotion exam, one per chapter.

Each chapter follows the same sequence. Learning objectives and an Introduction set the direction, and Key concepts explains all the knowledge and skills in the exam scope. Going deeper explores trade-offs and failure analysis, while At work follows problems at fictional organizations from the initial problem through to a decision. Common mistakes covers the same families of misconceptions targeted by exam distractors, and Summary at a glance is for review the day before the exam. Unlike the exam, the self-checks require written answers. They test whether you can recall and apply concepts without multiple-choice options; answers and explanations are collected in Appendix B. Each chapter can be read on its own: when another chapter's content is needed, it is briefly recapped in context.

The exam at a glance

There are five question types: single choice, multiple choice, true or false, ordering and matching. On the exam paper, every question is answered by choosing one number from ①–⑤. For multiple choice, you select a combination of statements a, b and c in the <Statements> box; for true or false, a combination of statements you judge correct; and for ordering and matching, one of the proposed sequences or sets of pairs.

What the questions look like

Every question starts with a concrete situation at a fictional company. Two or three sentences describe the team, the feature being built, the scale of data and traffic, and the problem. One question follows. Critical constraints are highlighted in bold. Requirements such as “waste caused by retries must also be reduced” or “do not change the model” determine the correct answer.

Most questions involve judgment under two or more constraints. They are designed so that changing one condition changes the right answer. Ask “Which choice best fits these conditions?” rather than “Is this a good feature?” Each wrong option contains one common practical misconception: that every error can be retried, that correct format means correct content, or that streaming reduces cost. By reading Common mistakes carefully, you can eliminate wrong options first, even on unfamiliar questions.

After submitting a free practice set or mock exam, you can see explanations for each option and the supporting documentation. Read explanations even for questions you answered correctly to check whether your reasoning matched the intended rationale. Promotion exam questions and explanations are not disclosed.

Six-week study plan

This plan assumes one hour a day, five days a week. The hands-on tasks are meaningful only if you actually call an API, so prepare an API key from one provider and a small testing budget first.

Notation and sources

• Product names, API names and parameters keep their original spelling, as in max_tokens and Messages API.
• Vendor-specific facts (parameter names, limits, pricing multipliers and retention periods) were checked against official documentation on October 20–21, 2026. Supporting pages are listed at the end of each chapter and in Appendix D.
• LLM APIs change every few weeks. Principles come first; vendor-specific facts serve as examples. Check the documentation again rather than memorizing numbers.
• Model names and prices appear only where needed, preserving the exact scope stated in the documentation, such as “models released after Claude Opus 4.6”.
• Legal references follow Korea's current Personal Information Protection Act (PIPA), effective September 11, 2026, as published by the National Law Information Center. Legal explanations in this book are for educational purposes and do not constitute legal advice.
• All companies and people in the examples are fictional.