당신의 앱이 LLM에 프롬프트를 보낸 후 실제로 어떤 일이 일어날까요?

~6분 분량

당신은 client.messages.create(...)를 호출합니다. 몇 백 밀리초(ms) 후, 토큰이 스트리밍되어 돌아오기 시작합니다.

단순해 보이지만, 그렇지 않습니다. 빠르게 훑어볼 수 있도록 섹션을 나누어 전체 경로를 설명합니다.

1. SDK는 데이터가 노트북을 떠나기 전에 작업을 수행합니다

• 메시지를 JSON으로 직렬화 (Serialize)
• 헤더(API key, content-type) 첨부
• HTTP/1.1 vs HTTP/2 결정
• 재시도/백오프 (retry/backoff) 로직 설정

💡 흔한 실수: 요청마다 새로운 클라이언트 인스턴스를 생성하는 것. 이렇게 하면 커넥션 풀링 (connection pooling)을 놓치게 되며, 매번 전체 TCP + TLS 설정 비용을 지불하게 됩니다. 클라이언트를 재사용하세요.

2. DNS: 서버 찾기

api.anthropic.com → Resolver → 203.0.113.42

콜드 룩업 (Cold lookup): 20–120ms. 캐시된 경우: 사실상 무료. 이것이 바로 커넥션 재사용(매 호출마다 DNS를 다시 확인하는 과정을 건너뛰는 것)이 대규모 환경에서 실질적인 이득이 되는 이유입니다.

3. TLS: 채널 암호화

Client → TCP handshake → TLS handshake → Encrypted request →

TLS 1.3은 이를 약 1번의 왕복 (round trip)으로 줄였습니다. 하지만 여전히 무료는 아닙니다. 특히 지연 시간 (latency)이 높은 모바일 네트워크에서는 더욱 그렇습니다.

4. 로드 밸런서 (Load balancer): 당신은 단 하나의 서버에 접속하는 것이 아닙니다

Request → [Load Balancer] → Server A / B / C

상태 확인 (Health checks), 지리적 라우팅 (geographic routing), 트래픽 급증 흡수. 이것이 서버 하나가 죽더라도 당신의 문제가 되지 않는 이유입니다.

5. API 게이트웨이 (API Gateway): 요청을 위한 공항 보안 검색

• 인증 (Auth) — 이 API key가 유효한가? 누구의 계정인가?
• 속도 제한 (Rate limiting) — '시끄러운 이웃 (noisy neighbors)'으로부터 공유 인프라를 보호
• 검증 (Validation) — 잘못된 형식의 JSON이나 잘못된 파라미터는 하류(downstream)의 GPU 시간을 낭비하기 전에 여기서 거부됨

💡 엔지니어링 통찰: 속도 제한은 당신을 괴롭히기 위해 존재하는 것이 아닙니다. 한 명의 클라이언트가 해당 하드웨어를 공유하는 모든 사람의 서비스를 저하시키는 것을 방지하기 위함입니다.

6. 로깅 (Logging) (비동기, 논블로킹)

요청 ID (Request IDs), 토큰 수, 단계별 지연 시간 (per-stage latency) — 이는 디버깅, 남용 탐지, 그리고 당신의 청구서로 이어집니다. 요청을 차단(block)하지는 않습니다.

7. 토큰화 (Tokenization): 단어가 숫자가 됩니다

"Explain quantum entanglement" → [16350, 14294, 4776, 385, 1997]

이것이 직접적으로 영향을 미치는 두 가지 요소:

• 💰 비용 (Cost) — 글자 수가 아닌 토큰 (token) 단위로 청구됨
• 📏 컨텍스트 제한 (Context limit) — "200K 컨텍스트"는 단어 수가 아닌 토큰 예산을 의미함

💡 실제 예시: 코드나 비영어권 텍스트는 동일한 "양"의 의미를 전달하더라도 일반적인 영어보다 더 많은 토큰을 소모하는 경우가 많습니다. 이는 토크나이저 (tokenizer)가 학습 과정에서 해당 패턴을 덜 보았기 때문입니다.

💡 성능 팁: 반복되는 보일러플레이트 (boilerplate)나 시스템 프롬프트 (system prompts)를 다듬으세요. 모든 토큰은 비용과 컨텍스트 공간을 소모합니다.

8. 모델 라우팅 (Model routing)

라우팅 계층 (routing layer)은 용량과 지역을 기반으로 어떤 모델과 클러스터 (cluster)가 요청을 처리할지 결정합니다. 이는 제공업체마다 다르며 상세한 내용은 대부분 문서화되어 있지 않지만, 이러한 일반적인 형태는 어디에서나 흔히 볼 수 있습니다.

9. GPU 스케줄링 (GPU scheduling): 진정한 병목 현상

[사용자 A][사용자 B][사용자 C][사용자 D] → 하나의 GPU에 배치 (batched)

GPU는 웹 서버처럼 즉각적으로 가동될 수 없습니다. 여러 요청을 배치 (batching) 처리함으로써 효율성을 유지합니다. 연속 배치 (Continuous batching) (진행 중인 배치에 새로운 요청을 끼워 넣는 방식) 덕분에 현대의 서빙 (serving) 기술은 단순한 일회성 처리 방식보다 훨씬 더 빠릅니다.

💡 이것이 호출마다 지연 시간 (latency)이 달라지는 이유이기도 합니다. 하드웨어를 공유하고 있기 때문입니다.

10. KV 캐시 (KV Cache): 빠른 생성의 비결

토큰 1 → 계산 + 캐시 (cache)
토큰 2 → 캐시 재사용 + 새 토큰만 계산

이 기술이 없다면, 매번 새로운 토큰을 생성할 때마다 대화 전체를 다시 처리해야 할 것입니다. 이 기술 덕분에 생성 속도가 빠르게 유지되지만, 캐시는 컨텍스트 길이 (context length)에 따라 커지며 요청이 활성화되어 있는 동안 계속해서 GPU 메모리를 점유합니다.

이는 또한 **프롬프트 캐싱 (prompt caching)**의 메커니즘이기도 합니다. 호출 간에 공유되는 접두사 (prefix, 예: 시스템 프롬프트)에 대해 캐시된 상태를 재사용함으로써 비용과 지연 시간을 줄입니다.

11. 트랜스포머 추론 (Transformer inference) (모두가 상상하는 부분)

토큰당 과정: 임베딩 (embed) → N개의 트랜스포머 계층 (transformer layers, 셀프 어텐션 (self-attention) + 피드 포워드 (feed-forward)) 통과 → 어휘 사전 (vocabulary)에 대한 확률 분포 생성 → 다음 토큰 샘플링 (sample).

💡 흔한 실수: 더 높은 temperature가 반드시 더 똑똑한 모델을 의미하지는 않습니다. 이는 단지 샘플링의 무작위성 (randomness)을 변경할 뿐입니다.

12. 스트리밍 (Streaming): 타이핑하는 것처럼 느껴지는 이유

Prompt → [t1] → [t1,t2] → [t1,t2,t3] → ...

토큰은 한 번에 하나씩 생성(자기회귀 (autoregressive))되며, 각 토큰이 준비될 때마다 보통 Server-Sent Events (SSE)를 통해 사용자에게 스트리밍됩니다.

💡 성능 팁: 한 문장보다 긴 사용자 대상 응답은 항상 스트리밍을 사용하세요. 총 소요 시간은 동일하지만, 체감 지연 시간 (perceived latency)이 대폭 감소합니다. 빈 화면 대신 밀리초 (ms) 단위로 첫 번째 토큰이 나타나기 때문입니다.

13. 병렬로 실행되는 과금 (Billing)

입력 토큰 (Input tokens) + 출력 토큰 (Output tokens)이 측정됩니다 (캐시된 토큰 (cached tokens)은 종종 더 저렴합니다). 이는 인보이스 (invoice)에 반영되며, 때로는 5단계의 속도 제한기 (rate limiter)로 실시간 할당량 (quota) 체크 정보를 다시 전달합니다.

💡 길고 반복되는 시스템 프롬프트 (system prompt)는 제공업체가 캐싱 (caching)을 통해 반복되는 접두사 (prefix)에 할인을 제공하지 않는 한, 조용히 큰 비용 항목이 됩니다.

전체 파이프라인, 하나의 다이어그램

Your Code → SDK → DNS → TLS → Load Balancer → Gateway (auth/limit/validate)
   → Logging → Tokenization → Routing → GPU Scheduling → KV Cache
   → Inference → Generation → Streaming → (Billing, parallel) → Your Code

약 15개의 시스템, 서로 다른 팀, 서로 다른 하드웨어가 1초도 채 되지 않는 짧은 시간 내에 협력합니다.

요약 (TL;DR)

• 이것은 우선적으로 분산 시스템 (distributed systems) 문제이며, 그 다음이 ML 문제입니다.
• 연결을 재사용하세요 — DNS + TLS 비용이 누적됩니다.
• 토큰 = 비용 + 컨텍스트 예산 (context budget)이며, 이를 하나의 자원으로 취급하세요.
• 지연 시간 변동성 (Latency variance) = GPU 배치 (batching)의 문제이지, "더 깊은 사고"의 문제가 아닙니다.
• KV 캐시 (KV cache) = 긴 채팅이 서버 측에서 더 많은 비용이 드는 이유입니다.
• 스트리밍 (Streaming) = 실제 속도가 빨라지는 것이 아니라, "체감" 속도가 좋아지는 것입니다.

토론: 에이전트 체인 (agent chains)이 도구 호출 (tool calls) 위에 도구 호출을 쌓아갈 때, 이러한 오버헤드의 얼마만큼이 매 단계마다 중복될까요? 그리고 무엇을 하나의 공유 레이어로 통합해야 할까요?

제공업체별 세부 사항 (라우팅, 스케줄링, 캐싱)은 다를 수 있습니다. 위의 패턴은 특정 제공업체의 정확한 내부 구조가 아니라, 대규모 LLM 서빙 시스템 전반에 걸쳐 공통적으로 나타나는 패턴입니다.

참고 자료: Anthropic Docs · OpenAI Docs · Vaswani et al.,