LLM 아키텍처: 프로덕션 AI를 위한 시스템 설계
모델을 실행하는 것은 인프라 문제입니다. 그러나 모델로부터 가치를 얻어내는 것은 아키텍처 문제입니다.
인프라 계층(런타임, 하드웨어, API 엔드포인트 등)은 무엇을 할 수 있는지를 결정합니다. 아키텍처 계층은 요청에 대해 실제로 어떤 일이 일어나는지를 결정합니다: 어떤 모델이 처리할지, 비용은 얼마나 들지, 어떤 검증이 이루어질지, 그리고 실패는 어떻게 포착될지를 결정합니다.
대부분의 시스템은 단일 모델과 아키텍처 없이 시작됩니다. 이는 프로토타이핑 단계에서는 올바른 접근입니다. 하지만 프로덕션 환경에서는 리스크가 됩니다.
LLM 아키텍처는 “호출할 수 있는 모델"을 “신뢰할 수 있는 시스템"으로 전환하는 설계 결정을 포괄합니다.
LLM 아키텍처의 스택 내 위치
LLM 아키텍처는 3층 모델의 중간에 위치합니다:
| 계층 | 포괄 범위 | 관련 영역 |
|---|---|---|
| 모델 | 런타임, 서빙, GPU 설정 | LLM 호스팅 · LLM 성능 |
| 아키텍처 | 라우팅, 비용, 가드레일, 오케스트레이션 | 여기에 있습니다 |
| 애플리케이션 | AI 어시스턴트, RAG 파이프라인, 에이전트 | AI 시스템 · RAG |
아키텍처 계층은 초기 단계에서 종종 생략됩니다. 하지만 모델이 하나보다 많거나, 작업 유형이 하나보다 많거나, 사용자가 하나보다 많다면 아키텍처는 필수적이 됩니다. 이 클러스터의 모든 아키텍처 패턴은 “모든 것에 하나의 모델” 접근법이 더 이상 작동하지 않게 됨에 따라 탄생했습니다.
클러스터 맵
이 클러스터의 다섯 가지 주제는 서로 연결되어 있습니다. 가장 논리적인 경로를 위해 다음 순서로 읽어보세요:
- 여기에 있습니다 — 이 기둥: LLM 아키텍처란 무엇이며, 구성 요소들이 어떻게 맞물려 있는지
- 프롬프트 — LLM을 위한 효과적인 프롬프트 작성 — 기초: 모델이 받는 입력을 형성하는 것
- 라우팅 — 모델 라우팅 전략 — 디스패처: 어떤 모델이 무엇을 처리할지 결정
- 비용 — LLM 시스템의 비용 최적화 — 토큰 예산 관리, 캐싱, 로컬 대 API 경제성
- 안전 — 실무에서의 LLM 가드레일 — 입력 검증, 출력 필터링, 규정 준수
- 오케스트레이션 — 다중 모델 시스템 설계 — 순차적, 병렬적, 계층적, 앙상블 패턴
시간이 하나뿐이라면 라우팅부터 시작하세요. 아키텍처가 시작되는 결정 지점이 바로 그곳입니다.
프롬프트 엔지니어링
프롬프트 엔지니어링은 모델에 가장 가까운 계층입니다. 라우팅, 캐싱, 가드레일 이전에 프롬프트가 존재합니다. 모델에 보내는 것이 얻는 결과를 결정합니다.
실제로 중요한 실용적 기법들:
- 명확성과 구조 — 명확한 지시가 교묘한 프레임보다 뛰어난 성과를 냅니다
- 구체적인 예시 — 퓨 쇼트(few-shot) 예시는 모델의 행동을 고정시킵니다
- 역할 부여 — 역할 기반 프롬프트는 톤과 제약 조건을 명확히 합니다
- 다양한 접근법 — 다양한 포맷은 모델이 반응하는 요소를 드러냅니다
- 컨텍스트 관리 — 포함하는 정보가 모델이 중요하게 여기는 것을 형성합니다
프롬프트 엔지니어링은 일회성 작업이 아닙니다. 이는 작업 요구사항과 모델의 행동 사이의 지속적인 교정 과정입니다.
심화 학습:
- LLM을 위한 효과적인 프롬프트 작성 — 언어 모델 성능을 위한 실용적 기법
모델 라우팅
라우팅 계층은 어떤 모델이 어떤 요청을 처리할지 결정합니다. 라우팅 계층이 없으면 모든 요청이 동일한 모델로 전송됩니다 — 종종 간단한 작업에는 너무 크고, 복잡한 작업에는 너무 작은 모델이 사용됩니다.
네 가지 라우팅 전략이 대부분의 프로덕션 사례를 커버합니다:
| 전략 | 최적화 대상 | 적합한 상황 |
|---|---|---|
| 역량 기반 | 작업 품질 | 복잡도가 혼합된 워크로드 |
| 비용 인식 | 토큰 지출 | 예산이 제한된 시스템 |
| 지연 시간 인식 | 응답 시간 | 인터랙티브 도구 및 실시간 채팅 |
| 하이브리드 | 세 가지 모두 | 실제 제약이 있는 프로덕션 시스템 |
폴백 체인(fallback chain)은 실패를 처리합니다: 최상의 모델부터 가장 신뢰할 수 있는 모델까지 순서대로 배치하고, API 중단으로 인해 속도 제한되거나 종료될 수 없는 로컬 모델로 마무리합니다.
심화 학습:
- 모델 라우팅 전략: 로컬 대 API, 비용 인식, 지연 시간 인식 — 역량 기반, 비용 인식, 지연 시간 인식 라우팅 및 Python 코드
비용 최적화
LLM 비용은 사용량에 비례하여 선형적으로 증가합니다. 실제로 청구서를 줄이는 전략들:
토큰 예산 관리는 세션별, 작업별 또는 적응형 제한을 설정합니다. 적응형 예산은 실제 사용량을 추적하고 시간이 지남에 따라 할당량을 조율합니다.
로컬 추론은 비용 구조를 완전히 바꿉니다. 하드웨어 상각 후, 로컬 모델은 전기 요금만 지불하고 실행됩니다. 적정 수준의 사용량을 하는 GPU는 몇 개월 안에 그 비용을 회수합니다.
캐싱은 가장 과소평가된 최적화 기법입니다. 완전 일치 캐싱(exact-match caching)은 반복되는 프롬프트를 캐치합니다. 시맨틱 캐싱(semantic caching)은 동일한 의미를 가진 프롬프트를 캐치합니다. 고 트래픽 시스템에서 시맨틱 캐싱은 실제 호출 전에 API 호출의 상당 부분을 제거합니다.
폴백 체인은 요청당 평균 비용을 줄입니다: 예산이 허용할 때 비싼 모델을 선호하고, 세션이 진행됨에 따라 더 저렴하거나 로컬 모델로 폴백합니다.
심화 학습:
- LLM 시스템의 비용 최적화: 토큰 예산 관리, 폴백 모델, 캐싱 — 실제 하드웨어 수치, 손익분기점 표 및 작동하는 Python 패턴
가드레일
LLM은 기본적으로 예측 불가능합니다. 가드레일은 모델에 들어가고 나오는 것을 제약하되, 모델의 기능을 제거하지 않습니다.
실무에서 중요한 세 가지 가드레일 계층:
입력 검증은 문제가 모델에 도달하기 전에 차단합니다. 프롬프트 정제(sanitization)는 인젝션 시도를 잡아냅니다. 길이 제한은 토큰 낭비를 방지합니다. 콘텐츠 필터는 추론 비용이 발생하기 전에 정책 위반을 차단합니다.
출력 필터링은 생성 후 문제를 잡아냅니다. 구조적 검증은 예상되는 응답 형태를 보장합니다. 콘텐츠 체크는 해로운 출력을 차단합니다. 사실 확인(중요 도메인용)은 지식 베이스에 대한 클레임을 검증합니다.
안전 메커니즘은 시스템을 장기적으로 보호합니다: 속도 제한은 남용을 방지하고, 토큰 예산은 요청당 비용을 상한 처리하며, 컨텍스트 윈도우 관리는 오버플로우와 턴 간 데이터 누출을 방지합니다.
규정 준수가 중요한 시스템(GDPR, HIPAA, SOC 2)의 경우, 구조화되고 부가 전용(append-only)인 항목과 데이터 거주지 제어를 갖춘 감사 로깅을 추가하세요.
가드레일은 모델 대화 처리를 담당하지만, 에이전트가 도구를 호출하고 작업을 다른 에이전트에 위임하면 두 번째 보안 계층이 필요합니다: 누가, 누구를 대신하여, 어떤 감사 추적(audit trail)으로 행할 수 있는지. 이는 모델 I/O 필터링이 아닌 프로토콜 보안입니다.
심화 학습:
- 실무에서의 LLM 가드레일: 입력 검증, 출력 필터링, 안전 — 실용적 가드레일 패턴 및 규정 준수 참고사항
- A2A 및 MCP 에이전트 보안: 신원, 위임, 감사 추적 — 프롬프트 안전성을 넘어선 에이전트 프로토콜 보안: 신원, 권한 부여, 게이트웨이 및 위임 제어
다중 모델 시스템 설계
단일 모델로는 충분하지 않을 때, 아키텍처 질문은 다음과 같습니다: 복잡성이 절약하는 것보다 더 많은 비용을 초래하지 않으면서 여러 모델을 어떻게 오케스트레이션할 것인가?
다섯 가지 패턴이 공간을 커버합니다:
| 패턴 | 지연 시간 | 비용 | 품질 | 적합한 상황 |
|---|---|---|---|---|
| 단일 모델 | 가장 낮음 | 가장 낮음 | 변동적 | 프로토타이핑, 균일한 워크로드 |
| 순차적 (파이프라인) | 높음 | 중간 | 높음 | 전문화가 필요한 다단계 워크플로우 |
| 병렬적 (팬-아웃) | 낮음 | 높음 | 높음 | 독립적 작업, A/B 테스트 |
| 계층적 (플래너-실행자) | 높음 | 높음 | 가장 높음 | 전문가 실행이 필요한 복잡한 추론 |
| 앙상블 | 중간 | 가장 높음 | 가장 높음 | 합의를 요구하는 중요한 결정 |
경험칙: 실제 제약 조건을 처리할 수 있는 가장 간단한 패턴부터 시작하세요. 대부분의 프로덕션 시스템은 역량 기반 라우팅만으로는 부족해졌을 때만 병렬 또는 계층적 구조로 나아갑니다.
심화 학습:
- 다중 모델 시스템 설계: 어떤 모델을 언제 그리고 왜 사용할 것인가 — 작동하는 Python 코드 및 트레이드오프 표가 포함된 다섯 가지 패턴 모두
아키텍처 결정 프레임워크
무엇을 언제 추가할지에 대한 빠른 분류를 위해 이 프레임워크를 사용하세요:
| 문제 | 해결책 | 추가 시점 |
|---|---|---|
| 비용이 너무 높음 | 비용 인식 라우팅, 캐싱, 로컬 추론 | API 비용이 실제 예산 항목이 될 때 |
| 지연 시간이 너무 높음 | 지연 시간 인식 라우팅, 더 작은 모델 | 사용자가 느림을 인지할 때 |
| 품질이 일관되지 않음 | 역량 기반 라우팅, 폴백 체인 | 간단한 작업이 비싼 모델을 받거나 복잡한 작업이 저렴한 모델을 받을 때 |
| 사용자가 시스템을 남용함 | 입력 검증, 속도 제한 | 신뢰할 수 있는 팀 외의 접근을開放할 때 |
| 응답이 안전하지 않거나 정책에 벗어남 | 출력 필터링, 콘텐츠 가드레일 | 일반 사용자를 서비스할 때 |
| 하나의 모델이 모든 것을 처리함 | 다중 모델 설계 | 워크로드가 복잡성을 정당화할 정도로 분화될 때 |
| 프롬프트가 작동하지 않음 | 프롬프트 엔지니어링 반복 | 항상 — 프롬프트는 작업이 진화함에 따라 조정이 필요함 |
아키텍처는 하향식(bottom-up)으로 구축하세요. 프롬프트 엔지니어링은 항상 범위 내에 있습니다. 비용/품질 트레이드오프가 현실적이 될 때 라우팅을 추가하세요. 외부 사용자를 서비스할 때 가드레일을 추가하세요. 다중 모델 오케스트레이션은 마지막으로 추가하세요.
LLM 아키텍처와 다른 주제 간의 관계
LLM 아키텍처는 여러 관련 클러스터의 교차점에 위치합니다:
인프라 (이 계층 아래):
- 2026년 LLM 호스팅: 로컬, 자체 호스팅 및 클라우드 인프라 비교 — 런타임(Ollama, llama.cpp, vLLM), 하드웨어 및 서빙 결정. 아키텍처 패턴은 이용 가능한 인프라에 의존합니다. 비용 인식 라우팅은 로컬 모델과 API 모델이 모두 실행 중일 때만 의미가 있습니다.
- 2026년 LLM 성능: 벤치마크, 병목 현상 및 최적화 — 지연 시간 수치, VRAM 제한, 처리량 측정치. 이는 라우팅 및 모델 선택 결정의 경험적 입력값입니다.
애플리케이션 계층 (이 계층 위):
- AI 시스템: 자체 호스팅 어시스턴트, RAG 및 로컬 인프라 — 라우팅, 가드레일 및 오케스트레이션 결정을 소비하는 시스템. 다중 모델 아키텍처는 프로덕션 AI 어시스턴트의 전제 조건입니다.
- 검색 증강 생성(RAG) 튜토리얼 — RAG 자체가 아키텍처 패턴입니다: 컨텍스트를 LLM으로 공급하는 검색 파이프라인. 이 클러스터의 라우팅, 비용 및 가드레일 패턴은 RAG 파이프라인 내부에서도 적용됩니다.
운영 계층:
- 관찰 가능성: 모니터링, 메트릭스, Prometheus 및 Grafana 가이드 — 프로덕션 LLM 아키텍처는 관찰 가능성이 필요합니다. 비용 추적, 지연 시간 모니터링 및 가드레일 위반 메트릭스는 인프라 계층이 아닌 아키텍처 계층에서 계측(instrumentation)가 필요합니다.
