AI Engineering Academy · 강의

프로덕션 아키텍처 설계

최종 프로젝트를 선택하고 RAG 처리 과정, 에이전트 계층, 캐싱, 관측 가능성, API를 포함한 전체 아키텍처의 윤곽을 그린 다음, 설계 결정과 절충안을 문서화합니다.

레슨 1/413개 단계

프로덕션 아키텍처 설계은(는) CoddyKit의 무료 AI Engineering Academy 강의입니다. 이것은 4개 중 1번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 AI Engineering Academy 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. AI Engineering Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

최종 프로젝트 선택

최종 프로젝트는 이 트랙에서 배운 RAG, 에이전트, 스트리밍, 캐싱, 관찰 가능성, 보안을 모두 연결합니다. 좋은 최종 프로젝트는 최소 세 가지의 서로 다른 AI 구성 요소가 필요할 만큼 충분히 복잡하면서도, 몇 달이 아니라 며칠 안에 출시할 수 있을 정도로 범위가 작아야 합니다. 대표적인 예로는 운영 수준의 문서 질의응답 도우미, 사람의 감독이 포함된 자율 연구 에이전트, 기업 데이터 추출 파이프라인이 있습니다.

시스템 구성 요소 식별

먼저 시스템에 필요한 서로 다른 구성 요소를 나열하세요. 운영 수준의 AI 엔지니어링 프로젝트에는 일반적으로 다음이 포함됩니다. 수집 계층(문서 로드, 청크 분할, 임베딩, 벡터 저장소 색인), 검색 계층(하이브리드 검색, 재순위 지정), 에이전트 계층(함수 호출, 도구 실행), API 계층(FastAPI 백엔드, 스트리밍 엔드포인트), 관찰 가능성 계층(추적, 지표, 경고)입니다. 코드를 작성하기 전에 구성 요소 간 데이터 흐름을 간단히 그려 보세요.

# Component inventory for a Document QA Assistant:
COMPONENTS = [
    'document_ingestion',   # PDF/Word -> chunks -> embeddings -> pgvector
    'hybrid_retriever',     # BM25 + dense + RRF
    'reranker',             # Cohere rerank
    'qa_agent',             # GPT-4o with RAG + function calling
    'semantic_cache',       # Redis + embedding similarity
    'streaming_api',        # FastAPI StreamingResponse
    'tracing',              # LangSmith or Langfuse
    'prompt_injection_filter', # Input sanitization
    'eval_pipeline',        # Automated quality scoring
]

적절한 기술 스택 선택

새로움보다는 팀의 숙련도와 시스템의 실제 요구 사항을 기준으로 기술을 선택하세요. 합리적인 기본 스택은 다음과 같습니다. API 계층에는 FastAPI, 벡터 저장소에는 pgvector(기존 PostgreSQL 인프라를 재사용), 파이프라인 조합에는 LangChain LCEL, 의미 기반 캐싱과 속도 제한 상태 관리에는 Redis, 추적에는 LangSmith, 사용자 데이터와 평가 결과에는 PostgreSQL을 사용합니다. 더 단순한 선택지로 요구 사항을 충족할 수 없을 때만 구성 요소를 추가하세요.

# Technology decisions and their rationale
STACK = {
    'api':           ('FastAPI',    'Async support, OpenAPI docs, streaming easy'),
    'vector_store':  ('pgvector',   'Already on PostgreSQL, no extra infra'),
    'llm_primary':   ('gpt-4o',     'Best quality for the use case'),
    'llm_fallback':  ('claude-3.5', 'Different provider for resilience'),
    'cache':         ('Redis',      'Sub-ms lookup, TTL support built-in'),
    'tracing':       ('LangSmith',  'Native LangChain integration'),
    'embedding':     ('text-embedding-3-small', 'Good quality, low cost'),
    'reranker':      ('Cohere',     'Best-in-class rerank API'),
}

아키텍처 다이어그램 그리기

각 구성 요소, 구성 요소 사이를 흐르는 데이터, 흐름의 방향을 보여 주는 데이터 흐름 다이어그램으로 시스템 아키텍처를 문서화하세요. 수집 경로(오프라인: 문서 → 청크 → 임베딩 → 벡터 저장소)와 질의 경로(온라인: 사용자 질의 → 캐시 확인 → 검색 → 재순위 지정 → LLM → 스트리밍 응답)를 모두 포함하세요. 이 다이어그램은 구현의 길잡이가 되며 새로운 팀원이 시스템을 즉시 이해하도록 도와줍니다.

# Data flow (ASCII art):
#
# INGESTION PATH (offline):
# Documents --> Loader --> Chunker --> Embedder --> pgvector
#                                             |
#                                         BM25 index
#
# QUERY PATH (online):
# User Query
#    |-> Semantic Cache (hit: return) -> miss:
#    |-> Hybrid Retriever (BM25 + dense)
#    |-> Cohere Reranker
#    |-> LangChain LCEL Chain
#    |-> GPT-4o (streaming) --> FastAPI StreamingResponse
#    |-> LangSmith (trace every step)

API 계약 조기 정의

백엔드 로직을 구현하기 전에 FastAPI에서 API 엔드포인트와 요청/응답 스키마를 정의하세요. 이렇게 하면 API와 프런트엔드 소비자 사이에 계약이 만들어지고 병렬 개발이 가능해집니다. 모든 엔드포인트를 OpenAPI 설명과 함께 문서화하세요. 최소한 문서 수집, 채팅/질의, 대화 기록, 평가 결과, 시스템 상태를 위한 엔드포인트를 정의해야 합니다.

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(title='Document QA Assistant', version='1.0')

class QueryRequest(BaseModel):
    question: str
    conversation_id: str | None = None
    max_chunks: int = 5
    stream: bool = True

class QueryResponse(BaseModel):
    answer: str
    sources: list
    cached: bool
    latency_ms: int
    trace_id: str

@app.post('/query', response_model=QueryResponse)
async def query_endpoint(request: QueryRequest):
    pass  # implementation next lesson

비용 추정 및 예산 책정

백엔드 코드를 한 줄도 작성하기 전에 시스템의 월간 API 비용을 추정하세요. 예상 일일 활성 사용자 수 × 사용자당 질의 수 × 질의당 평균 토큰 수를 계산합니다. DAU가 100명이고, 하루에 10번 질의하며, 질의당 토큰이 3,000개인 시스템을 GPT-4o 가격으로 운영한다면 하루 300만 토큰, 즉 대략 하루 45달러 또는 한 달 1,350달러가 됩니다. 이 추정치를 통해 시스템의 경제성을 판단하고 어떤 최적화(캐싱, 모델 라우팅)를 구현할 가치가 있는지 파악할 수 있습니다.

# Cost estimation model
DAU = 100           # daily active users
QPD = 10            # queries per user per day
TOKENS_PER_QUERY = {
    'prompt_tokens': 2000,  # system + context + question
    'completion_tokens': 500
}

PRICE_GPT4O_INPUT = 2.50 / 1_000_000   # per token
PRICE_GPT4O_OUTPUT = 10.00 / 1_000_000  # per token

daily_cost = DAU * QPD * (
    TOKENS_PER_QUERY['prompt_tokens'] * PRICE_GPT4O_INPUT +
    TOKENS_PER_QUERY['completion_tokens'] * PRICE_GPT4O_OUTPUT
)
print(f'Daily: ${daily_cost:.2f}, Monthly: ${daily_cost * 30:.2f}')

수집 파이프라인 계획

수집 파이프라인은 필요할 때 또는 일정에 따라 실행되는 오프라인 일괄 처리로 설계하세요. 지원할 문서 유형(PDF, DOCX, HTML, 일반 텍스트), 청크 분할 전략, 임베딩 모델, 각 벡터와 함께 저장할 메타데이터 필드를 정의합니다. 메타데이터는 필터링된 검색에 매우 중요합니다. 메타데이터가 없으면 특정 날짜 범위, 작성자 또는 범주의 문서로 검색을 제한할 수 없습니다.

from dataclasses import dataclass
from typing import Optional

@dataclass
class ChunkMetadata:
    doc_id: str
    source_file: str
    page_number: Optional[int]
    section_title: Optional[str]
    created_at: str
    author: Optional[str]
    doc_type: str  # 'pdf', 'docx', 'html'

# Ingestion config
INGESTION_CONFIG = {
    'chunk_size': 800,
    'chunk_overlap': 100,
    'embedding_model': 'text-embedding-3-small',
    'embedding_dimensions': 1536,
    'batch_size': 100,  # chunks per embedding API call
}

보안 아키텍처 결정

보안은 나중에 덧붙이지 말고 처음부터 결정하세요. 사용자를 인증하는 방법(JWT, API 키), 사용자별로 검색할 수 있는 데이터(pgvector 질의의 행 수준 보안), 프롬프트 주입을 탐지하는 방법, 적용할 출력 검사, 다중 요소 확인이 필요한 작업을 정의합니다. 각 결정은 시스템 전반의 아키텍처 선택에 영향을 미치는 성능상의 고려 사항을 동반합니다.

SECURITY_DECISIONS = {
    'auth': 'JWT with 24h expiry',
    'data_isolation': 'tenant_id column in all vector metadata, filter on every query',
    'injection_detection': 'rule-based pre-filter + LLM secondary check for complex inputs',
    'output_scanning': 'check for PII, system prompt leakage patterns',
    'destructive_actions': 'require confirmation token for delete operations',
    'rate_limiting': '20 queries/minute per user, 429 with Retry-After header',
    'key_storage': 'AWS Secrets Manager, rotated every 90 days'
}

성공 지표 정의

시스템을 구축하기 전에 성공의 기준을 정의하세요. 구체적이고 측정 가능한 성공 기준은 개발의 초점을 유지하고 배포 여부를 명확하게 판단할 수 있게 합니다. 다음 지표를 포함하세요. 품질(테스트 세트의 평가 점수), 지연 시간(p95 TTFT 및 전체 시간), 비용(질의당 목표 비용), 신뢰성(가동 시간 SLA)입니다. 모든 기여자가 동일한 목표를 공유할 수 있도록 이 내용을 프로젝트 README에 게시하세요.

SUCCESS_METRICS = {
    # Quality
    'min_correctness_score': 4.0,       # out of 5, LLM-as-judge
    'min_retrieval_hit_rate': 0.85,     # top-5 chunk contains answer
    # Latency
    'p95_ttft_ms': 800,                 # time to first token
    'p95_total_latency_ms': 8000,       # full response
    # Cost
    'max_cost_per_query_usd': 0.05,     # $0.05 per Q&A
    # Reliability
    'target_uptime': 0.999,             # 99.9%
    'cache_hit_rate_target': 0.25,      # 25% queries served from cache
}

아키텍처 절충안 문서화

모든 아키텍처 결정에는 절충안이 따릅니다. 아키텍처 결정 기록(ADR)에 어떤 결정을 내렸는지, 어떤 대안을 검토했는지, 왜 이 선택을 했는지를 명시적으로 문서화하세요. 예를 들어 '이미 PostgreSQL을 운영하고 있으므로 운영 부담을 줄이기 위해 Pinecone 대신 pgvector를 선택했다. 절충안: 샤딩 없이는 최대 규모가 약 1,000만 벡터로 제한된다.'와 같이 작성할 수 있습니다. 미래의 팀원은 이러한 투명성에 감사할 것입니다.

# Architecture Decision Records (ADRs):
#
# ADR-001: Use pgvector for vector storage
# Decision: pgvector in existing PostgreSQL
# Alternatives: Pinecone, Weaviate, Qdrant
# Reason: No new infra, row-level security native, familiar operations
# Trade-offs: Limited to ~5M vectors before performance degrades
#
# ADR-002: GPT-4o as primary model
# Decision: gpt-4o for all user-facing queries
# Alternatives: gpt-4o-mini (cheaper), Claude (alternative)
# Reason: Highest quality for use case, Claude as fallback
# Trade-offs: $0.04/query vs $0.002 for gpt-4o-mini

배포 토폴로지 개략화

인프라 코드를 작성하기 전에 시스템의 배포 방식을 정의하세요. 각 구성 요소를 배포 단위에 매핑합니다. FastAPI 백엔드는 Docker 컨테이너, 수집 파이프라인은 별도의 작업자 서비스, pgvector는 관리형 PostgreSQL 인스턴스, Redis는 관리형 캐시로 배포합니다. 수평 확장이 가능한 무상태 구성 요소와 신중한 확장 전략이 필요한 상태 저장 구성 요소를 구분해 지정하세요. 배포 다이어그램을 작성하면 나중에 재작업하는 데 드는 시간을 크게 줄일 수 있습니다.

# Deployment topology:
#
# Internet -> Load Balancer (AWS ALB)
#                |
#            FastAPI API  (stateless, 2-4 containers, auto-scale)
#                |
#         +------+------+
#         |             |
#    pgvector        Redis Cache
#  (AWS RDS Postgres) (Elasticache)
#         |
#    Ingestion Worker  (separate container, manual trigger)
#         |
#    LangSmith (external SaaS, traces only)
#
# All containers in same VPC, no public access to DB/cache

빠른 확인

운영 환경의 AI 시스템 아키텍처 설계에 대한 이해도를 확인해 보세요.

이번 단원 요약

이번 단원에서는 다음을 배웠습니다. 구성 요소 목록과 데이터 흐름 다이어그램은 코딩을 시작하기 전에 공유된 아키텍처 비전을 만듭니다. 사전에 정의한 API 계약은 병렬 개발을 가능하게 하고 요구 사항을 명확히 합니다. 또한 미리 정의한 성공 지표는 품질, 지연 시간, 비용, 신뢰성 목표에 대해 팀의 방향을 일치시킵니다. 다음으로 핵심 RAG 및 에이전트 기능을 구현합니다.

무료로 시작

AI 튜터와 함께 Python을(를) 배우세요 — 무료

브라우저에서 실제 코드를 작성하고 실행하며, 24/7 AI 튜터로부터 즉각적인 도움을 받고, 웹이나 앱에서 중단한 부분부터 계속 학습하세요.

코스
30
레슨
120

자주 묻는 질문

“프로덕션 아키텍처 설계” 강의는 무료인가요?

네 — “프로덕션 아키텍처 설계” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 AI Engineering Academy 강의 전체를 잠금 해제할 수 있습니다. AI Engineering Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

“프로덕션 아키텍처 설계”에서 뭘 배우나요?

최종 프로젝트를 선택하고 RAG 처리 과정, 에이전트 계층, 캐싱, 관측 가능성, API를 포함한 전체 아키텍처의 윤곽을 그린 다음, 설계 결정과 절충안을 문서화합니다. 브라우저에서 직접 실행하는 실습 코드로 AI Engineering Academy을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

AI Engineering Academy을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 AI Engineering Academy은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 1번째 강의입니다.

“프로덕션 아키텍처 설계” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 AI Engineering Academy 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 AI Engineering Academy 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

  1. 프로덕션 아키텍처 설계
  2. 핵심 RAG 및 에이전트 기능 구현
  3. 강화하기: 보안, 캐싱, 안정성
  4. 평가, 배포, 회고
← AI Engineering Academy(으)로 돌아가기