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는 몇 달 만에 투자 비용을 회수합니다.
캐싱은 가장 과소평가된 최적화 기법입니다. 정확 일치 캐싱은 반복되는 프롬프트를 캐치합니다. 시맨틱 캐싱은 동일한 의미를 가진 프롬프트를 캐치합니다. 고 트래픽 시스템에서 시맨틱 캐싱은 발생하기 전 대규모의 API 호출을 제거합니다.
폴백 체인은 요청당 평균 비용을 낮춥니다: 예산이 허용하는 경우 비싼 모델을 선호하고, 세션이 진행됨에 따라 더 저렴하거나 로컬 모델로 폴백합니다.
심화 학습:
- LLM 시스템의 비용 최적화: 토큰 예산 관리, 폴백 모델, 캐싱 — 실제 하드웨어 수치, 손익분기점 테이블, 작동하는 Python 패턴
가드레일(Guardrails)
LLM은 기본적으로 예측 불가능합니다. 가드레일은 모델의 기능을 제거하지 않으면서 들어가는 것과 나오는 것을 제한합니다.
실무에서 중요한 세 가지 가드레일 레이어:
입력 검증은 문제가 모델에 도달하기 전에 차단합니다. 프롬프트 정제(sanitization)는 주입 시도를 잡아냅니다. 길이 제한은 토큰 낭비를 방지합니다. 콘텐츠 필터는 추론 비용이 발생하기 전에 정책 위반을 차단합니다.
출력 필터링은 생성 후 문제를 잡아냅니다. 구조적 검증은 예상되는 응답 형식을 보장합니다. 콘텐츠 검사는 유해한 출력을 차단합니다. 사실 확인(중요한 도메인용)은 지식 베이스에 대해 주장을 검증합니다.
안전 메커니즘은 시스템을 장기적으로 보호합니다: 속도 제한은 남용을 방지하고, 토큰 예산은 요청당 비용을 상한으로 설정하며, 컨텍스트 윈도우 관리는 오버플로우와 턴 간 데이터 누출을 방지합니다.
규정 준수 부담이 큰 시스템(GDPR, HIPAA, SOC 2)의 경우, 구조적이고 부가 전용(append-only)인 로그와 데이터 거주지 제어를 갖춘 감사 로깅을 추가하세요.
심화 학습:
- 실무에서의 LLM 가드레일: 입력 검증, 출력 필터링, 안전성 — 실무 가드레일 패턴 및 규정 준수 참고 사항
다중 모델 시스템 설계
단일 모델이 부족할 때, 아키텍처 질문은 다음과 같습니다: 복잡성이 절약되는 것보다 더 많은 비용을 초래하지 않으면서 어떻게 여러 모델을 오케스트레이션할 것인가?
다섯 가지 패턴이 이 공간을 커버합니다:
| 패턴 | 지연 시간 | 비용 | 품질 | 사용 시기 |
|---|---|---|---|---|
| 단일 모델 | 가장 낮음 | 가장 낮음 | 변동 있음 | 프로토타이핑, 일관된 워크로드 |
| 순차적(파이프라인) | 높음 | 중간 | 높음 | 전문화가 필요한 다단계 워크플로우 |
| 병렬(팬아웃) | 낮음 | 높음 | 높음 | 독립적인 작업, 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)이 필요합니다.
