3장: LLM 통합 아키텍처 패턴

LLM 통합의 다섯 가지 패턴

1장에서 AI 시대의 새로운 아키텍처 관심사를, 2장에서 AI-Native 설계 원칙을 살펴보았습니다. 이번 장에서는 이 원칙들을 구체적인 아키텍처 패턴으로 발전시킵니다. LLM을 시스템에 통합하는 방식은 크게 다섯 가지 패턴으로 분류되며, 실무에서는 여러 패턴을 조합하여 사용합니다.

패턴 1: AI Gateway

AI Gateway는 모든 LLM 호출을 중앙화된 단일 진입점으로 통과시키는 패턴입니다. API 게이트웨이가 마이크로서비스 앞에 위치하는 것과 동일한 개념이지만, AI 특화 기능을 추가로 제공합니다.

Gateway가 담당하는 핵심 역할은 API 키 중앙 관리, 서비스별 요율 제한, 토큰 사용량과 비용 추적, 프롬프트/응답 로깅입니다. 개별 서비스가 프로바이더 키를 직접 관리하지 않으므로 보안이 강화되고, 모든 AI 호출의 관측 가능성이 한 곳에 집중됩니다.

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
 
app = FastAPI()
 
class CompletionRequest(BaseModel):
    model: str
    messages: list[dict]
    max_tokens: int = 1024
    service_id: str  # 호출 서비스 식별
 
@app.post("/v1/completions")
async def create_completion(request: CompletionRequest):
    if not await rate_limiter.check(request.service_id):
        raise HTTPException(429, "요청 한도 초과")
 
    start = time.monotonic()
    response = await route_to_provider(request)
    latency = (time.monotonic() - start) * 1000
 
    await metrics.track_usage(
        request.service_id, request.model,
        response.input_tokens, response.output_tokens,
    )
    return response

패턴 2: Model Router

Model Router는 요청의 특성에 따라 적절한 모델로 라우팅하는 패턴입니다. 모든 요청에 최고 성능 모델을 사용할 필요는 없습니다. 단순한 분류 작업에 Opus를 사용하면 비용 낭비이고, 복잡한 추론에 Haiku를 사용하면 품질 저하입니다.

라우팅 기준은 작업 유형(분류, 요약, 코드 생성), 입력 토큰 수, 요구되는 품질 수준 등으로 설정합니다. 정적 규칙에서 시작하되, 실제 사용 데이터를 기반으로 A/B 테스트를 통해 "이 작업에서 Haiku가 Sonnet과 동등한 품질을 내는가?"를 검증하고 라우팅을 조정합니다. 실패 시 상위 모델로 자동 폴백하는 체인도 함께 구성합니다.

패턴 3: Chain/Pipeline

Chain 패턴은 여러 LLM 호출을 순차적으로 연결하여 하나의 복잡한 작업을 처리하는 패턴입니다. 각 단계의 출력이 다음 단계의 입력이 됩니다.

단일 프롬프트로 모든 것을 처리하는 것보다 Chain이 유리한 이유가 있습니다. 각 단계를 독립적으로 테스트하고 최적화할 수 있으며, 단계별로 다른 모델을 사용할 수 있습니다. 중간 결과를 캐싱하여 재사용하거나, 특정 단계가 실패하면 그 단계만 재시도할 수 있습니다.

interface ChainStep<TIn, TOut> {
  name: string;
  execute(input: TIn): Promise<TOut>;
}
 
class Chain {
  private steps: ChainStep<unknown, unknown>[] = [];
 
  addStep<TIn, TOut>(step: ChainStep<TIn, TOut>): this {
    this.steps.push(step as ChainStep<unknown, unknown>);
    return this;
  }
 
  async execute<TIn, TOut>(input: TIn): Promise<TOut> {
    let result: unknown = input;
    for (const step of this.steps) {
      result = await step.execute(result);
    }
    return result as TOut;
  }
}

패턴 4: Orchestrator

Orchestrator 패턴은 Chain보다 복잡한 워크플로우를 처리합니다. 조건 분기, 병렬 실행, 루프, 인간 승인 등을 포함하는 다단계 AI 워크플로우를 조율합니다.

Orchestrator는 상태 머신(State Machine) 또는 DAG(Directed Acyclic Graph)로 구현됩니다. LangGraph가 이 패턴의 대표적인 구현체입니다. 각 노드가 AI 호출이나 도구 실행이고, 엣지가 조건 분기를 나타냅니다.

패턴 5: RAG 아키텍처

RAG(Retrieval-Augmented Generation)는 외부 지식 저장소에서 관련 문서를 검색하여 프롬프트에 주입하는 패턴입니다. LLM의 환각 문제를 줄이고 최신 정보를 제공합니다.

RAG의 핵심은 Retriever와 Generator의 분리입니다. 검색 품질이 생성 품질을 결정하므로, 검색 파이프라인의 최적화가 전체 시스템 성능의 핵심입니다. 문서 청킹 전략, 임베딩 모델 선택, 하이브리드 검색(벡터 + 키워드), 리랭킹 모델 적용 등 각 구성 요소를 독립적으로 튜닝할 수 있다는 것이 RAG 아키텍처의 강점입니다.

패턴 선택 가이드

실무에서는 이 패턴들을 조합합니다. Gateway를 통해 모든 요청을 받고, Router가 모델을 선택하며, RAG Chain을 실행하는 Orchestrator가 전체를 조율하는 구조가 전형적입니다.

다음 장 미리보기

4장에서는 이벤트 드리븐 AI 파이프라인을 다룹니다. LLM의 높은 지연 시간과 가변적인 처리 시간을 효과적으로 다루기 위한 메시지 큐, 스트리밍 처리, 비동기 추론 패턴을 살펴보겠습니다.