LLM API 기초와 운영 감각

LLM API는 챗봇, RAG, 에이전트가 공통으로 올라가는 진입점이며, 토큰 비용과 지연, 출력 품질, 운영 안정성을 함께 다뤄야 한다. 이 스크립트는 메시지 구조, 샘플링, structured output, streaming, 비용 최적화, 장애 대응까지 API 운영 관점의 핵심을 정리한다.

Layer: L12
Duration: 길이 미정
Generated: 2026. 5. 25. 오후 4:30:25

원본 문서 읽기 오디오 파일 열기

Script Companion

오디오와 함께 스크립트 보기

01
LLM API를 이해한다는 것은 단순히 모델을 한 번 호출하는 방법을 익히는 데서 끝나지 않는다. 챗봇, RAG, 에이전트는 모두 이 API 위에 올라가고, 호출 한 번의 모양이 비용, 지연, 품질, 운영 안정성으로 이어진다. input 토큰과 output 토큰은 비용에 직접 연결되고, prefill과 decode는 지연의 성격을 나눈다. temperature, top_p, top_k, penalty 같은 sampling 설정은 답변의 다양성과 hallucination에 영향을 준다. 운영 단계에서는 structured output, retry, error handling, rate limit까지 함께 봐야 production 요건을 만족할 수 있다.
02
가장 기본이 되는 구조는 OpenAI가 정착시킨 Chat Completion 메시지 형식이다. 이 표준은 Anthropic, Google, OpenRouter 같은 주요 provider가 호환하거나 흉내 내는 형태로 널리 쓰인다. system은 모델의 역할, 페르소나, 규칙을 담고 보통 가장 앞에 온다. user는 사용자 입력이고, assistant는 이전 turn의 모델 응답이나 모델이 호출한 tool을 나타낸다. tool은 function calling 흐름에서 tool 실행 결과를 담는다. 중요한 점은 API가 stateless라는 것이다. 모델은 대화를 기억하는 것이 아니라, 매 호출마다 전체 대화 기록을 다시 입력으로 받는다.
03
Sampling 파라미터는 forward pass 이후 next-token 분포에서 어떤 토큰을 뽑을지 정하는 규칙이다. Greedy decoding은 temperature를 0으로 두고 가장 확률 높은 토큰만 선택하는 방식이다. 결정적이고 다양성이 없기 때문에 분류나 코드처럼 정답이 명확한 작업에 적합하다. Temperature는 logits를 T로 나누어 softmax 분포의 sharpness를 조정한다. 분류와 코드는 T=0, 요약과 번역은 T=0.2에서 0.5, 창작은 T=0.7에서 1.2가 문서의 기준이다. 다만 temperature=0이라도 완전 결정적이라고 보면 안 된다. floating point, batch 차이 때문에 일부 provider에서 다른 결과가 나올 수 있고, OpenAI는 seed와 system_fingerprint로 더 강한 재현성을 확인한다.
04
Top-p는 nucleus sampling이라고도 하며, 확률 누적이 p 이상이 되는 최소 토큰 집합 안에서만 sampling한다. Temperature와 함께 자주 쓰이지만, 둘 다 강하게 조정하면 효과가 중첩되므로 보통 temperature 또는 top_p 중 하나만 조정하는 쪽이 권장된다. Top-k는 상위 k개 토큰만 sampling하는 방식이고, top_k=50이 흔한 default지만 OpenAI API에서는 직접 노출하지 않는다. Frequency penalty와 presence penalty는 긴 챗봇 세션에서 반복 답변을 줄이는 데 유용하다. 여기서 핵심은 파라미터가 장식이 아니라 출력의 결정성, 다양성, 반복성에 영향을 주는 운영 레버라는 점이다.
05
Structured output은 자유 텍스트 대신 검증 가능한 구조로 출력하도록 강제하는 방식이다. JSON Mode는 JSON 형식 자체를 보장하지만 schema 일치까지 보장하지는 않는다. OpenAI의 response_format에서 type json_schema와 strict true를 쓰는 Structured Outputs, Anthropic의 tool_use, outlines와 Instructor 같은 라이브러리는 더 강한 제약을 제공한다. strict true는 grammar-constrained decoding으로 schema에서 벗어난 토큰 자체를 막아 100% schema 일치를 보장한다. Outlines는 regex나 grammar로 토큰 단위 제약을 걸고, Instructor는 Pydantic 모델로 schema를 정의한 뒤 retry를 붙인다. Agent의 tool calling, RAG의 citation, 데이터 추출에서는 이 구조화가 사실상 필수에 가깝다.
06
Streaming은 응답을 토큰 단위로 흘려보내는 Server-Sent Events 방식이다. 장점은 TTFT, 즉 Time To First Token을 줄여 사용자가 응답이 시작됐다고 느끼게 만든다는 점이다. 다만 전체 응답이 끝나는 Total latency와는 다른 지표이므로 둘을 구분해야 한다. Streaming의 까다로운 지점은 structured output이나 tool calling과 결합할 때 드러난다. JSON이 완성되기 전의 partial JSON을 어떻게 parsing할지, chunk를 그대로 client에 흘릴지, 백엔드에서 buffer 후 처리할지 정해야 한다. Vercel AI SDK, LangChain, LlamaIndex, Anthropic streaming=true는 이 흐름을 다루는 도구와 옵션으로 등장한다.
07
Multimodal I/O는 텍스트만이 아니라 이미지, 오디오, 비디오를 입출력으로 다루는 영역이다. Vision 입력은 OpenAI GPT-4o, Anthropic Claude 4.x, Google Gemini 2.x가 모두 지원한다. 다만 이미지는 토큰화되어 비용이 누적되고, OpenAI 기준으로 1024×1024 이미지는 약 765 tokens로 계산된다. OpenAI gpt-4o-audio는 음성 입력과 출력을 통합하고, Gemini는 비디오 직접 입력을 지원하며, 1시간 비디오는 약 1M tokens로 제시된다. Whisper는 음성을 텍스트로 바꾸는 전용 도구다. 운영에서는 provider별 이미지 가격, 텍스트보다 큰 비전 모델 latency, 이미지에 PII가 포함되는 privacy 위험을 함께 확인해야 한다.
08
Provider를 비교할 때는 모델 성능만이 아니라 인터페이스, structured output, context, multimodal, enterprise 통합을 같이 본다. 2026-04 라인업 기준으로 OpenAI는 GPT-5.4, GPT-4.1, o3와 o4-mini를 포함하고, structured output strict, Responses API, Realtime이 특징이다. Anthropic은 Claude Opus 4.7, Sonnet 4.6, Haiku 4.5를 제시하며 긴 출력 안정, extended thinking, 자연스러운 tool use가 강조된다. Google은 Gemini 2.5 Pro와 Flash로 1M+ context와 multimodal, video가 강점이다. OpenRouter, Together, Groq, Fireworks는 Llama 4, DeepSeek-V3/R1, Qwen3, gpt-oss 같은 open-weight 모델을 다양한 가격과 latency로 제공한다. AWS Bedrock과 Azure OpenAI는 enterprise IAM, VPC, 컴플라이언스 쪽의 선택지다.
09
비용 모델은 단순하지만 운영 영향은 크다. 기본 공식은 input_tokens 곱하기 price_in 더하기 output_tokens 곱하기 price_out이고, output이 보통 4배에서 5배 비싸다. 문서의 예시에서 GPT-4o는 1M 토큰 기준 input 2.50달러, output 10달러이고, GPT-4o-mini는 0.15달러와 0.60달러다. o3는 2달러와 8달러, Claude Opus 4.7은 5달러와 25달러로 제시된다. 특히 Opus 4.7은 새 토크나이저가 같은 텍스트에 최대 35% 더 많은 토큰을 만들 수 있어 명목 단가가 같아도 실비용이 늘 수 있다. 그래서 운영에서는 provider docs 확인과 a/b 토큰 카운트 검증이 필요하다.
10
비용 절감 기법의 중심에는 prompt caching, Batch API, 모델 라우팅, output 길이 제한, reasoning budget 조절이 있다. Prompt caching은 같은 prefix를 재사용할 때 효과가 크고, Anthropic의 5분 TTL 기준으로 hit은 input 가격의 10%, write는 1.25배로 제시된다. OpenAI는 automatic prefix caching을 제공하며 prompt가 1024 토큰 이상이면 자동 활성화되고 이후 128 토큰 단위로 cache hit이 누적된다. 공식 수치로 latency 최대 80% 감소, input 비용 최대 90% 감소가 가능하다. 다만 prefix 중간에 user_id나 timestamp 같은 변동 토큰이 들어가면 그 지점부터 전부 miss가 난다. 고정 prefix인 system과 few-shot을 앞에 두고, 사용자별 변동 데이터는 뒤로 배치하는 것이 가장 큰 단일 leverage다.
11
Inference internals에서는 prefill과 decode를 구분해야 한다. Prefill은 input 토큰에 비례하고 batch 처리 효율이 좋다. Decode는 output 토큰에 비례하며 batch 1에서는 GPU 활용률이 낮다. continuous batching과 PagedAttention은 decode throughput을 끌어올리는 도구로 소개된다. Speculative decoding은 작은 draft 모델이 K개 토큰을 미리 만들고 target 모델이 한 번의 forward pass로 검증하는 방식이다. 문서의 2026 벤치마크에서는 vLLM과 EAGLE-3가 low-concurrency, 즉 동시 요청 10 미만 구간에서 2배에서 3배 decode 가속을 보인다. 하지만 draft 모델 acceptance rate가 0.55 미만이면 검증 오버헤드가 이득을 상쇄하고, 응답 길이 100 토큰 미만이거나 동시 요청 100 이상이면 효과가 거의 없어진다.
12
운영에서 오류 처리는 주변 작업이 아니라 핵심 작업이다. 흔한 오류는 rate limit 429, context length exceeded 400, content filter 400 또는 403, timeout 504, invalid JSON이다. 429는 TPM, RPM, concurrency 한도를 넘었다는 신호이고 exponential backoff가 필요하다. context length exceeded는 input과 output이 max_context를 넘은 것이므로 truncate나 RAG 분할을 검토한다. invalid JSON은 structured output strict=false일 때 발생할 수 있고, strict mode나 retry가 해결 실마리가 된다. Production 패턴으로는 circuit breaker, fallback model, dead-letter queue가 언급된다. LangChain, LlamaIndex, Vercel AI SDK도 retry와 fallback을 빌트인으로 제공한다.
13
Prompt, RAG, fine-tune, agent 선택은 정량 신호로 다시 판단해야 한다. Prompt only에서 RAG로 이동하는 신호는 inline context가 50k tokens를 넘어 호출당 비용이 0.10달러 이상으로 커지거나, 갱신 주기 24시간 미만의 외부 지식 때문에 stale 답변이 생길 때다. RAG에서 fine-tune을 검토하는 신호는 retrieval recall이 0.7 미만으로 정답 chunk가 누락되거나, 동일 system prompt가 1k 토큰을 넘는데도 핵심 행동과 톤이 잡히지 않을 때다. Prompt에서 agent로 넘어가는 기준은 검색, 요약, DB쓰기 같은 multi-step 분기가 필요해질 때다. 반대로 agent 평균 step 수가 1.5회 이하면 overhead만 늘 수 있으므로 단일 호출과 structured output으로 회귀하는 편이 맞다.
14
마지막으로 LLM API는 특별한 동시에 익숙한 API 시스템이다. Chat completion은 RPC나 REST endpoint에, streaming은 Server-Sent Events나 WebSocket에, structured output strict는 gRPC schema나 JSON Schema validation에 대응한다. Prompt caching은 HTTP cache, ETag, CDN, redis cache와 유사하고, rate limit과 retry는 API gateway의 Throttling, Backoff, Circuit Breaker 패턴으로 볼 수 있다. 일반 공식은 input, 정책, 처리, output의 4단계다. LLM API가 다른 점은 비결정성과 토큰 비용이 전면에 있다는 것이다. 그래서 플랫폼 엔지니어는 provider 교체 가능한 추상화 layer, input과 output 토큰 분리 측정, cache hit ratio 추적, strict mode 기본값, TTFT 관측, retry와 fallback 표준화를 함께 설계해야 한다.

같은 레이어

L12에서 이어 듣기

원본 문서: content/topics/L12/llm-api-basics.md
오디오 파일: /podcasts/l12-llm-api-basics.mp3