AI를 핵심 컴포넌트로 설계하는 AI-Native 애플리케이션의 설계 원칙 — 분리된 추론, 폴백 전략, 비동기 처리, 그리고 인간-AI 협업 패턴을 다룹니다.
AI-Native 애플리케이션이란 AI를 부가 기능이 아닌 핵심 컴포넌트로 설계한 시스템을 말합니다. 기존 시스템에 AI를 "볼트온(bolt-on)"하는 방식과는 근본적으로 다릅니다. AI의 특성 — 비결정성, 높은 지연, 실패 가능성, 토큰 비용 — 을 아키텍처 설계 단계에서부터 고려합니다.
이번 장에서는 AI-Native 애플리케이션을 설계할 때 반드시 지켜야 할 여섯 가지 핵심 원칙을 다룹니다.
가장 중요한 원칙입니다. LLM 호출 코드가 비즈니스 로직 안에 직접 들어가면, 모델 교체, 프롬프트 변경, 테스트 작성이 모두 어려워집니다.
추론 계층을 인터페이스로 추상화하면, 비즈니스 로직은 AI 프로바이더의 세부 사항을 알 필요가 없습니다. 모델을 교체하거나 테스트에서 목(mock)을 주입하는 것도 간단해집니다.
interface AIService {
complete(prompt: string, options?: CompletionOptions): Promise<string>;
completeStructured<T>(
prompt: string,
schema: ZodSchema<T>,
): Promise<T>;
}
// 비즈니스 로직은 AIService 인터페이스에만 의존
class DocumentService {
constructor(private ai: AIService) {}
async summarize(document: string): Promise<string> {
return this.ai.complete(
`다음 문서를 3문장으로 요약: ${document}`,
);
}
}의존성 주입(Dependency Injection)을 사용하면 테스트에서 AI 서비스를 목으로 교체할 수 있습니다. 비결정적인 LLM 응답에 의존하지 않는 안정적인 단위 테스트를 가능하게 합니다.
LLM은 실패합니다. 환각(Hallucination)을 일으키고, 형식에 맞지 않는 응답을 반환하고, 타임아웃이 발생합니다. AI-Native 설계는 이 모든 실패를 정상 시나리오로 취급합니다.
| 실패 유형 | 원인 | 대응 전략 |
|---|---|---|
| 환각 | 사실이 아닌 내용 생성 | 출력 검증, RAG 활용 |
| 형식 오류 | 구조화된 출력 실패 | 스키마 검증, 재시도 |
| 타임아웃 | 추론 시간 초과 | 타임아웃 설정, 비동기 처리 |
| 요율 제한 | API 호출 한도 초과 | 지수 백오프, 다중 프로바이더 |
핵심은 재시도, 타임아웃, 폴백을 AI 호출의 기본 래퍼로 포함시키는 것입니다. tenacity 같은 라이브러리로 지수 백오프(Exponential Backoff) 재시도를 적용하고, asyncio.wait_for로 타임아웃을 설정합니다.
AI 컴포넌트가 완전히 실패하더라도 시스템 전체가 멈춰서는 안 됩니다. 우아한 성능 저하(Graceful Degradation)는 AI 기능의 수준을 단계적으로 낮추면서도 핵심 서비스를 유지하는 전략입니다.
예를 들어, AI 기반 시맨틱 검색이 실패하면 캐시된 유사 쿼리 결과를 반환하고, 그마저 없으면 규칙 기반 키워드 검색으로 폴백합니다. 사용자에게는 "AI 추천 대신 인기순으로 표시합니다"와 같이 현재 서비스 수준을 투명하게 알리는 것이 신뢰 유지에 중요합니다.
LLM 추론은 본질적으로 느립니다. 비동기 우선(Async-First) 설계는 스트리밍, 이벤트 드리븐, 큐 기반 처리를 기본으로 합니다.
사용자 경험에서 가장 큰 차이를 만드는 것이 스트리밍입니다. 전체 응답이 완성될 때까지 기다리는 대신, 토큰이 생성되는 즉시 사용자에게 전달합니다. 긴 추론 작업은 요청-응답 사이클에서 분리하여 백그라운드로 처리하고, 사용자에게는 작업 ID를 즉시 반환합니다. 이 패턴은 4장에서 더 깊이 다룹니다.
작업의 위험도와 복잡도에 따라 인간의 개입 수준을 조절하는 HITL(Human-in-the-Loop) 패턴이 필요합니다.
| 패턴 | 적용 시나리오 | 예시 |
|---|---|---|
| 완전 자동화 | 위험도 낮음, 되돌리기 가능 | 이메일 분류, 태그 추천 |
| AI 제안 + 인간 승인 | 중간 위험도 | 고객 응대 초안, 코드 리뷰 |
| 인간 처리 + AI 보조 | 높은 위험도 | 의료 진단, 금융 거래 |
HITL 패턴은 단순히 안전장치가 아닙니다. 인간의 피드백을 수집하여 프롬프트를 개선하고 모델 성능을 평가하는 데이터 소스이기도 합니다. 잘 설계된 HITL 파이프라인은 시스템이 시간이 지남에 따라 점점 나아지게 만듭니다.
프롬프트를 코드에 하드코딩하면, 프롬프트를 수정할 때마다 코드를 배포해야 합니다. 프롬프트는 YAML이나 데이터베이스 같은 설정(configuration)으로 관리되어야 합니다.
id: summarize
version: "2.0"
model: claude-sonnet-4-20250514
temperature: 0.3
template: |
다음 문서를 {sentence_count}문장으로 요약해 주세요.
대상 독자: {audience}
문서: {document}
variables:
- sentence_count
- audience
- document프롬프트를 설정으로 분리하면, 코드 배포 없이 프롬프트를 업데이트하고, A/B 테스트를 수행하며, 버전별 성능을 비교할 수 있습니다.
이 원칙들은 서로 독립적이지 않습니다. 추론 분리가 되어야 폴백 전략을 구현할 수 있고, 비동기 설계가 되어야 인간 협업 패턴을 넣을 수 있습니다. 여섯 가지를 종합적으로 적용할 때 비로소 견고한 AI-Native 시스템이 만들어집니다.
3장에서는 이 설계 원칙들을 구체적인 LLM 통합 아키텍처 패턴으로 발전시킵니다. Gateway, Router, Chain, Orchestrator, RAG 등 실무에서 반복적으로 사용되는 패턴들을 Mermaid 다이어그램과 코드 예제로 상세히 살펴보겠습니다.
이 글이 도움이 되셨나요?
관련 주제 더 보기
LLM을 시스템에 통합하는 핵심 아키텍처 패턴 — Gateway 패턴, Router 패턴, Chain 패턴, Orchestrator 패턴, 그리고 RAG 아키텍처의 설계를 다룹니다.
AI 통합이 소프트웨어 아키텍처에 가져온 근본적 변화, 결정론에서 확률론으로의 전환, 그리고 AI-Native 시스템의 핵심 특성을 조망합니다.
이벤트 기반 아키텍처로 AI 워크로드를 처리하는 패턴 — 메시지 큐, 스트리밍 처리, 비동기 추론, 그리고 실시간 AI 파이프라인 설계를 다룹니다.