Home / 에이전트 운영 / 운영 아키텍처
Note

운영 아키텍처

프로덕션 아키텍처, 배포 토폴로지, 관측성 구축, 알럿

⏱ 35분 158 / 189

운영 아키텍처

프로덕션 아키텍처, 배포 토폴로지, 관측성 구축, 알럿

배포는 끝이 아니라 시작이다

프로덕션 에이전트의 5대 운영 과제와 해법

에이전트 운영 아키텍처

프로덕션 AI Agent의 과제와 해법

PART 1 · 아키텍처

운영 아키텍처

프로덕션 에이전트가 마주하는 과제와 이를 받치는 계층 구조의 조감

4대 과제 → 4계층 아키텍처

프로덕션 에이전트의 근본 과제를 계층 구조로 받아냅니다.

  • 4대 과제 — 비결정성 · 지연 불확정 · 비용 폭발 · 장애 전파
  • 레퍼런스 아키텍처 — Client → Gateway → Runtime → Observability
  • Runtime 내부 — Model · Tools · Memory · Guardrails
  • Gateway — 인증 · 라우팅 · 정책
takeaway

Gateway가 제어를, Runtime이 실행을, Memory가 상태를, Observability가 가시성을 맡습니다 — 계층이 과제를 나눠 받는 구조입니다.

PART 1 · 아키텍처

프로덕션 4대 과제

AI 에이전트를 프로덕션에 배포하면 만나는 근본적 과제

비결정성

같은 입력에 다른 출력 — 테스트·재현·디버깅이 어려움

지연 불확정

도구 호출 수에 따라 응답 시간 변동 — SLA 보장 어려움

비용 폭발

멀티턴·멀티에이전트에서 LLM 호출 기하급수적 증가

장애 전파

하나의 도구/에이전트 실패 → 전체 시스템 연쇄 장애

takeaway

네 과제에는 모니터링 · 비용 관리 · 장애 대응 · 배포 전략이 순서대로 대응합니다 — 비결정성은 모니터링이, 비용 폭발은 비용 관리가 받아냅니다.

PART 1 · 아키텍처

레퍼런스 아키텍처

4계층 — Client → Gateway → Runtime → Observability

PART 1 · 아키텍처

에이전트 구성요소 포함 관계

Agent를 이루는 컴포넌트의 계층 구조

모니터링과 옵저버빌리티

보이지 않으면 관리할 수 없다

PART 2 · 모니터링

모니터링

운영자의 시선으로 보는 호출 흐름과 지연 구간 — 요청이 어디서 시간을 쓰는지 짚는 운영 관점

보이지 않으면 관리할 수 없다

운영 관점의 모니터링 — 요청이 어디서 시간을 쓰는지 호출 흐름으로 짚습니다.

  • 호출 시퀀스 — Client → Gateway → Agent → Tool → LLM
  • 지연 3대 구간 — 1차 추론 · 도구 실행 · 2차 추론
  • 수집·대시보드 체계 — 관측성 전담 모듈 연결
takeaway

OpenTelemetry 3축 수집과 Golden Signals 대시보드는 에이전트 관측성 모듈이 전담합니다 — 여기서는 운영자가 봐야 할 호출 흐름과 지연 구간만 다룹니다.

PART 2 · 모니터링

에이전트 호출 흐름

요청부터 응답까지의 시퀀스 — 1차 추론·도구 실행·2차 추론이 지연의 3대 구간

비용 관리

토큰 한 개가 비용이다

PART 3 · 비용

비용 관리

비용이 발생하는 지점과 이를 줄이는 두 가지 손잡이의 조감

토큰 한 개가 비용이다

비용이 어디서 발생하는지 보고, 티어링과 컨텍스트 관리로 줄입니다.

  • 비용 구조 — LLM 토큰 비용이 지배적 (구성 비율은 예시)
  • 모델 티어링 — 복잡도에 따라 경량 · 대형 모델 분배
  • SlidingWindow — 전체 히스토리 대신 요약 압축
  • ContextOffloader — 도구 결과는 미리보기만 컨텍스트에
takeaway

가장 큰 비용은 LLM 토큰입니다 — 모델 티어링과 Context Management 두 손잡이로 줄입니다.

PART 3 · 비용

비용 구조

에이전트 비용은 어디서 발생하는가 — 구성 비율은 예시

70% LLM 토큰 비용 (입력+출력)
20% 도구 호출 비용 (Lambda, API)
10% 인프라 (Runtime, Memory, Gateway)
PART 3 · 비용

모델 티어링 전략

작업 복잡도에 따라 모델을 자동 분배

  1. 1
    요청 분류

    Prompt Router가 요청 복잡도를 판단합니다. 분류 결과에 따라 모델 티어가 결정됩니다.

  2. 2
    경량 모델

    간단한 분류·라우팅은 Haiku가 처리합니다. 저비용으로 대량 요청을 감당합니다.

  3. 3
    대형 모델

    복잡한 추론·생성은 Sonnet이 담당합니다. 고품질이 필요한 구간에만 투입합니다.

  4. 4
    결과 합성

    최종 응답 조합은 경량 모델이 수행합니다. 마지막 단계의 비용을 낮춥니다.

takeaway

모든 요청에 대형 모델을 쓰지 않는 것이 핵심입니다 — 고품질이 필요한 구간에만 Sonnet을 투입하고 나머지는 경량 모델이 감당합니다.

PART 3 · 비용

Context Management로 토큰 절감

SlidingWindow + ContextOffloader로 비용 대폭 절감

컨텍스트 관리 매 턴 전체 히스토리 전송 SlidingWindow + 요약 압축
도구 결과 전체 JSON 그대로 컨텍스트에 ContextOffloader로 미리보기만
비용 (예시) 턴당 평균 8K 토큰 턴당 평균 2K 토큰

스케일링과 장애 대응

장애는 반드시 온다

PART 4 · 장애

스케일링과 장애 대응

장애 전파를 끊는 패턴과 부하에 대응하는 스케일링 전략의 조감

장애는 반드시 온다

실패를 전제로 차단·폴백·재시도 패턴을 설계하고, 부하는 두 축으로 받아냅니다.

  • 서킷 브레이커 — 연속 실패 시 자동 차단
  • 그레이스풀 디그레이드 — 차단된 기능 대신 폴백 응답
  • 운영 루프 — 관측 → 평가 → 최적화 → 배포
  • 스케일링 2축 — 세션 기반 · 토큰 기반
takeaway

장애 대응 패턴이 전파를 끊고, 운영 루프가 개선을 반복하며, 스케일링이 부하를 받아냅니다.

PART 4 · 장애

장애 대응 3대 패턴

서킷 브레이커 · 그레이스풀 디그레이드 · 타임아웃

  1. 1
    서킷 브레이커

    연속 N회 실패 → 해당 도구/에이전트 자동 차단

  2. 2
    그레이스풀 디그레이드

    차단된 기능 대신 폴백 응답 제공

  3. 3
    타임아웃 + 재시도

    도구별 max_execution_time + 지수 백오프

PART 4 · 장애

운영 개선 루프

관측 → 평가 → 최적화 → 배포 — 지속적 개선 사이클

PART 4 · 장애

스케일링 전략

부하 증가에 대응하는 2가지 축 — 동시 세션 수와 분당 토큰 처리량

세션 기반 스케일링

  • 동시 활성 세션 수 기준
  • AgentCore: 5,000 세션 (US)
  • MicroVM 단위 격리
  • 콜드스타트 — Idle 세션 재사용으로 회피(컴퓨트 과금 없는 대기)

토큰 기반 스케일링

  • 분당 토큰 처리량 기준
  • Service Tier로 우선순위 제어
  • Reserved > Priority > Standard > Flex
  • 피크 시 자동 오버플로우
takeaway

세션 기반은 동시 사용자 수에, 토큰 기반은 분당 처리량과 우선순위에 대응합니다 — 워크로드의 병목 축을 먼저 확인합니다.

관측하고, 제어하고, 점진적으로 배포합니다.

레퍼런스 아키텍처 · OpenTelemetry · 토큰 예산 · 서킷 브레이커 · 카나리 배포