시리즈 전체의 아키텍처 패턴을 종합하여 프로덕션 AI-Native 시스템을 설계합니다. 전체 아키텍처 다이어그램, 기술 선택, 배포 전략을 다룹니다.
시리즈의 마지막 장에서는 지금까지 다룬 모든 아키텍처 패턴을 종합하여 하나의 프로덕션 시스템을 설계합니다. 구축할 시스템은 AI 기반 고객 서비스 플랫폼입니다. 이 플랫폼은 다음의 핵심 기능을 제공합니다.
이 시스템은 하루 수십만 건의 고객 문의를 처리하며, 99.9%의 가용성과 5초 이내의 응답 시간 SLA를 충족해야 합니다.
모든 요청의 진입점입니다. 인증, 인가, 테넌트 식별, 요청 검증을 수행합니다. 9장에서 다룬 다층 속도 제한이 이 계층에 적용됩니다.
interface IncomingRequest {
tenantId: string;
userId: string;
sessionId: string;
message: string;
metadata: {
channel: "web" | "mobile" | "api";
language: string;
timestamp: string;
};
}
interface ProcessedRequest extends IncomingRequest {
tenantConfig: TenantConfig;
routingDecision: RoutingDecision;
traceId: string;
}
async function handleRequest(req: IncomingRequest): Promise<ProcessedRequest> {
const traceId = crypto.randomUUID();
// 1. 테넌트 구성 로드
const tenantConfig = await tenantConfigService.getConfig(req.tenantId);
// 2. 할당량 검증
const quotaCheck = await tenantConfigService.enforceQuota(req.tenantId, {
tokens: estimateTokens(req.message),
});
if (!quotaCheck.allowed) {
throw new QuotaExceededError(quotaCheck.reason);
}
// 3. 모델 라우팅 결정
const routingDecision = routeToModel({
taskType: classifyIntent(req.message),
inputLength: req.message.length,
userTier: tenantConfig.tier,
qualityRequired: tenantConfig.tier === "enterprise" ? "high" : "medium",
latencyBudgetMs: 5000,
});
return {
...req,
tenantConfig,
routingDecision,
traceId,
};
}
function estimateTokens(text: string): number {
// 한글 기준 대략적인 토큰 추정 (1 토큰 = 약 1.5 글자)
return Math.ceil(text.length / 1.5);
}
function classifyIntent(message: string): string {
// 빠른 규칙 기반 분류 (LLM 호출 전)
if (message.includes("환불") || message.includes("취소")) return "refund";
if (message.includes("주문") || message.includes("배송")) return "order-tracking";
if (message.includes("사용법") || message.includes("어떻게")) return "how-to";
return "general";
}6장의 비용 관리와 7장의 회복 탄력성 패턴이 집중적으로 적용되는 계층입니다. 모델 라우팅, 토큰 예산, 서킷 브레이커, 프롬프트 캐싱이 요청이 실제 LLM에 도달하기 전에 적용됩니다.
이 계층의 설계 원칙은 다음과 같습니다.
무상태로 설계된 추론 워커가 실제 LLM 호출, RAG 검색, 도구 실행을 수행합니다. 9장에서 설계한 수평 확장과 자동 확장 패턴이 적용됩니다.
워커의 처리 흐름은 다음과 같습니다.
고객 서비스 플랫폼에서 RAG는 핵심입니다. 각 테넌트의 제품 매뉴얼, FAQ, 정책 문서 등을 기반으로 정확한 답변을 생성해야 합니다.
멀티테넌시 RAG에서는 벡터 스토어의 네임스페이스 격리가 중요합니다. 테넌트 A의 문서가 테넌트 B의 검색 결과에 포함되면 정보 유출이 발생합니다. 벡터 검색 시 반드시 테넌트 ID 필터를 적용해야 합니다.
고객이 "내 주문 상태를 알려주세요"라고 요청하면, 단순 텍스트 생성이 아닌 실제 주문 관리 시스템에서 데이터를 조회해야 합니다. 도구 실행 계층이 LLM의 도구 호출을 실제 API 호출로 변환합니다.
보안이 핵심 고려사항입니다. LLM이 호출할 수 있는 도구와 접근할 수 있는 데이터의 범위를 엄격하게 제한해야 합니다. 테넌트별, 사용자별 권한 검증을 도구 실행 전에 수행합니다.
LLM 응답이 사용자에게 전달되기 전, 가드레일 검사와 에스컬레이션 판단이 이루어집니다. 가드레일은 민감한 정보 노출, 부적절한 표현, 사실과 다른 정보를 차단합니다. 에스컬레이션 판단기는 AI가 충분히 답변할 수 없는 복잡한 문의를 식별하여 인간 상담사에게 전달합니다.
| 영역 | 기술 | 선택 근거 |
|---|---|---|
| API Gateway | Kong / AWS API Gateway | 속도 제한, 인증 내장 |
| 추론 워커 | Node.js (TypeScript) | 비동기 I/O, 스트리밍 지원 |
| 세션 저장소 | Redis Cluster | 저지연 읽기/쓰기, TTL 관리 |
| 벡터 스토어 | Pinecone / Qdrant | 네임스페이스 격리, 메타데이터 필터 |
| 메인 DB | PostgreSQL | 테넌트 설정, 대화 이력 영구 보관 |
| 메시지 큐 | Redis Streams / SQS | 비동기 작업 처리, 에스컬레이션 |
| 관측 가능성 | Langfuse + Grafana | AI 트레이싱 + 인프라 메트릭 |
| 컨테이너 | Kubernetes (EKS) | 자동 확장, 롤링 배포 |
| LLM 제공자 | Anthropic (주), OpenAI (백업) | 멀티 프로바이더 회복 탄력성 |
# 추론 워커 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: inference-worker
labels:
app: ai-cs-platform
component: inference
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 2
maxUnavailable: 0
template:
spec:
terminationGracePeriodSeconds: 120
containers:
- name: inference-worker
image: ai-cs-platform/inference-worker:latest
resources:
requests:
cpu: "500m"
memory: "1Gi"
limits:
cpu: "2000m"
memory: "4Gi"
readinessProbe:
httpGet:
path: /health/ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
httpGet:
path: /health/live
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
env:
- name: REDIS_URL
valueFrom:
secretKeyRef:
name: ai-cs-secrets
key: redis-url
- name: ANTHROPIC_API_KEY
valueFrom:
secretKeyRef:
name: ai-cs-secrets
key: anthropic-api-keymaxUnavailable을 0으로 설정하면 롤링 배포 중에도 항상 원래 수의 파드가 가동됩니다. AI 서비스에서 배포 중 용량 감소는 응답 시간 증가로 직결되므로, 무중단 배포를 위해 이 설정이 중요합니다.
배포는 카나리(Canary) 전략을 사용합니다. 새 버전을 전체 트래픽의 5%에 먼저 적용하고, 8장에서 설계한 관측 가능성 체계로 품질 메트릭을 모니터링합니다. 에러율, 환각 감지율, 사용자 피드백 점수가 기준치 이내이면 점진적으로 트래픽을 100%까지 올립니다.
하루 100,000건의 요청을 처리하는 시나리오의 월간 비용 추정입니다.
| 항목 | 월간 예상 비용 | 비고 |
|---|---|---|
| LLM API (Sonnet 주력) | $3,000 - $5,000 | 모델 라우팅으로 최적화 |
| LLM API (Haiku 경량) | $200 - $400 | 분류, 간단한 응답 |
| LLM API (Opus 복잡) | $500 - $1,000 | 전체의 5% 미만 |
| 벡터 스토어 | $200 - $500 | 테넌트 수에 비례 |
| Redis Cluster | $300 - $600 | 세션, 캐시 |
| Kubernetes (EKS) | $500 - $1,000 | 워커 노드 |
| 관측 가능성 | $200 - $400 | Langfuse, Grafana |
| 총 예상 비용 | $4,900 - $8,900 | 캐싱 적용 후 |
캐싱을 적용하지 않은 경우 LLM API 비용만 $8,000 - $12,000으로 추정됩니다. 50%의 캐시 적중률을 달성하면 LLM 비용을 약 절반으로 줄일 수 있습니다.
시스템 운영에 필요한 대시보드를 세 가지로 구성합니다.
운영 대시보드: 실시간 요청량, 응답 시간, 에러율, 서킷 브레이커 상태, 큐 깊이를 표시합니다. 운영팀이 시스템 상태를 한눈에 파악할 수 있어야 합니다.
품질 대시보드: 환각 감지율, 가드레일 트리거율, 사용자 피드백 점수, 에스컬레이션 비율의 시간대별 추이를 표시합니다. AI 엔지니어가 모델 성능을 모니터링합니다.
비용 대시보드: 모델별 비용, 테넌트별 비용, 캐시 절감액, 월간 예산 대비 소진율을 표시합니다. 경영진과 재무팀이 비용 현황을 추적합니다.
10장에 걸쳐 AI 시대의 소프트웨어 아키텍처를 살펴보았습니다. 각 장에서 다룬 핵심 내용을 정리합니다.
| 장 | 핵심 주제 | 이 프로젝트에서의 적용 |
|---|---|---|
| 1장 | AI 시대의 아키텍처 변화 | 전체 설계 철학 |
| 2장 | LLM 통합 패턴 | 추론 워커의 LLM 호출 |
| 3장 | 프롬프트 엔지니어링 아키텍처 | 테넌트별 프롬프트 관리 |
| 4장 | RAG 아키텍처 | 지식 베이스 기반 답변 생성 |
| 5장 | 캐싱 전략 | 시맨틱 캐시, 프롬프트 캐시 |
| 6장 | 비용 관리 | 토큰 예산, 모델 라우팅 |
| 7장 | 장애 대응 | 서킷 브레이커, 폴백 체인 |
| 8장 | 관측 가능성 | 트레이싱, 품질 모니터링 |
| 9장 | 확장성 | 멀티테넌시, 자동 확장 |
| 10장 | 실전 프로젝트 | 전체 패턴 종합 |
AI 네이티브 시스템 아키텍처는 전통적인 아키텍처 지식 위에 AI 고유의 패턴을 쌓는 과정입니다. 비결정적 출력, 토큰 기반 비용, 외부 모델 의존성이라는 새로운 제약 조건 아래에서, 신뢰성 있고 비용 효율적이며 확장 가능한 시스템을 설계하는 것이 핵심입니다.
아키텍처는 한 번에 완성되지 않습니다. 이 시리즈에서 제시한 패턴 모두를 처음부터 구현할 필요는 없습니다. 가장 시급한 문제(보통 비용 또는 품질)부터 해결하고, 시스템이 성장함에 따라 점진적으로 패턴을 추가하는 접근이 현실적입니다.
이것으로 "AI 시대의 소프트웨어 아키텍처" 시리즈를 마칩니다. 이 시리즈가 AI 시스템을 설계하고 운영하는 데 실질적인 도움이 되었기를 바랍니다.
이 글이 도움이 되셨나요?
관련 주제 더 보기
AI 시스템의 수평 확장, 멀티테넌시 아키텍처, 속도 제한, 공정 스케줄링, 그리고 대규모 AI 서비스 운영을 위한 인프라 설계를 다룹니다.
LLM 기반 시스템의 관측 가능성 설계 — 트레이싱, 메트릭, 로깅, 프롬프트 버전 관리, 품질 모니터링, 그리고 AI 특화 대시보드 구축을 다룹니다.
AI 시스템의 장애 시나리오와 회복 탄력성 패턴 — 서킷 브레이커, 폴백, 재시도, 타임아웃, 모델 장애 조치, 그리고 그레이스풀 디그레이데이션을 다룹니다.