들어가며

2~3장에서는 모델이 내부에서 어떻게 동작하는지, 추론 서버를 어떻게 구성하는지 살펴봤습니다. 이번 4장은 실제 배포를 위한 애플리케이션과 운영대비로 확장하여 살펴보겠습니다. 실제 LLM 애플리케이션은 모델 한 번을 호출하고 끝나지 않습니다. 계획을 세우고, 자료를 찾고, 도구를 실행한 뒤 다시 모델을 호출합니다.

이때 모델 서빙은 순수한 추론 문제가 아니라 시스템 아키텍처 문제가 됩니다. 모델의 토큰 생성 속도뿐 아니라 호출 간 의존성, 리소스 배치, 장애 처리, 비용과 품질을 함께 관리해야 합니다.

4장은 이 문제를 네 가지 관점으로 설명합니다.

1. 에이전트 워크플로우가 서빙 요구사항을 어떻게 바꾸는가?
2. 프로덕션 LLM 서빙 플랫폼은 어떤 계층으로 구성되는가?
3. 직접 구축과 클라우드 서비스 사이에서 어디를 선택할 것인가?
4. 그 선택을 어떤 성능 지표로 검증할 것인가?

위 네 가지 관점을 이해하기 위해 현재(2026년 8월 기준) 에이전트 워크로드의 대두와 기존 서빙으로 부족한 점에 대해 알아봅니다. 이후 엔터프라이즈 서빙을 위한 계층형 아키텍처 소개, 그리고 빌드와 클라우드 간 차이점과 운영 시 주요하게 살펴볼 성능지표에 대해 알아봅니다.

4장에서 워크로드와 판단 기준을 세우고 나면 6~9장의 캐싱, 배칭, 메모리 관리, 스케줄링, 병렬화를 “무엇을 개선하기 위한 기술인가”라는 관점에서 이해할 수 있습니다.

에이전트 워크로드가 바꾸는 모델 서빙

단일 요청에서 제어 루프로

전통적인 모델 서빙은 요청 하나를 추론 한 번에 대응시킵니다.

요청 → 모델 → 응답

에이전트는 모델을 제어 루프 안에서 반복 호출합니다.

요청 → 계획 → 검색·도구 → 모델 → 재계획 → 최종 응답

에이전트는 상위 목표를 해석하고, 필요한 행동을 고른 뒤, 중간 결과에 따라 다음 단계를 결정합니다. 호출 순서와 횟수는 입력과 실행 결과에 따라 달라질 수 있습니다.

이 변화는 서빙 시스템에 다음 부담을 줍니다.

• 사용자 작업 하나가 여러 모델 호출을 만든다.
• 순차 호출은 지연을 누적한다.
• 병렬 호출은 순간 부하를 늘린다.
• 입력 컨텍스트와 전체 토큰 사용량이 증가한다.
• 중간 결과와 대화 상태를 보존해야 한다.
• 모델, 검색기, 도구 사이의 오케스트레이션이 필요하다.
• 실패, 재시도, 취소의 범위가 작업 전체로 넓어진다.

Agent Autonomy

전통적 애플리케이션은 개발자가 정한 실행 순서를 따릅니다. Agent는 사용자 목표를 해석하고 사용할 능력과 순서를 선택합니다.

전통적 애플리케이션
개발자가 실행 순서 결정 → 프로그램이 그대로 실행

LLM Agent
목표 해석 → 능력 선택 → 실행 경로 구성 → 결과 반환

자율성은 어디까지나 허용된 도구, 권한, 비용, 반복 횟수 안에서 움직이게 하는 것이 핵심입니다. 이번 Knowledge Agent도 미리 등록된 액션 안에서만 계획을 만듭니다.

실습 코드로 확인하는 에이전트 워크로드

현재 실습 코드의 구성 요소는 다음 개념과 대응합니다.

Knowledge Agent는 에이전트가 만드는 호출 구조를 보여줍니다. 그러나 GPU와 추론 엔진 운영은 API 제공자 뒤에 숨겨져 있습니다. 이제 이 숨겨진 계층을 프로덕션 LLM 서빙 아키텍처로 펼쳐봅니다.

소스 코드 구성

실습 코드는 Agent를 중심으로 구성됩니다. Planner가 실행할 Action 순서를 정하고, RAGSystem이 질문과 관련된 PDF 청크를 찾습니다. ActionExecutor는 검색 근거를 답변·요약·분석 프롬프트에 연결하며, 실제 모델 호출은 LLMManager가 담당합니다. containers.py는 이 객체들을 생성하고 의존성을 조립합니다.

flowchart TD
    C[containers.py
의존성 조립] --> A[agent.py
Agent]
    A --> P[planner.py
Planner]
    A --> R[rag_system.py
RAGSystem]
    A --> X[actions.py
ActionExecutor]
    P --> L[llm_manager.py
LLMManager]
    X --> L
    X --> R
    R --> E[Embedding API]
    L --> G[Chat API]

질문은 Agent.process_query()로 들어옵니다. 쉬운 예시의 경우 검색 후 Action 하나를 실행하고, Planning 경로는 계획을 만든 뒤 검색 결과를 같은 근거로 유지하면서 Action을 순서대로 실행합니다.

Actions

Action은 Agent가 실행할 수 있도록 명시적으로 등록된 재사용 가능한 능력입니다. 현재 Knowledge Agent의 액션은 네 개입니다.

샘플에서는 모든 액션이 LLM 호출 + 전용 프롬프트로 구현됩니다. 실제 Agent의 액션은 다음까지 확장될 수 있습니다.

• 웹 검색과 API 호출
• 데이터베이스 질의
• 파일 처리
• 워크플로우 실행
• 다른 Agent 호출
• 사용자에게 보이지 않는 중간 추론

Action을 분리하면 Planner는 구현 세부사항 대신 이름과 입력 계약을 보고 실행 경로를 구성할 수 있습니다.

Planning

Planner는 사용 가능한 액션을 바탕으로 질문에 적합하다고 판단한 실행 순서를 만듭니다. LLM 계획은 최적성을 보장하지 않으므로 생성 결과를 그대로 실행해서는 안 됩니다.

Knowledge Agent는 다음 순서로 계획을 처리합니다.

계획 프롬프트 생성
→ LLM이 JSON 계획 생성
→ 구조·액션 이름·단계 수 검증
→ 실패 시 규칙 기반 fallback

사용자는 “문서를 찾고, 요약하고, 분석하라”는 세부 순서를 직접 지정하지 않아도 됩니다. 대신 시스템은 허용할 액션, 최대 단계 수, 실패 처리와 비용 상한을 정해야 합니다.

Tool Calling과 MCP

Tool Calling은 모델이 사용할 도구와 인자를 구조화해 제안하는 동작입니다. 애플리케이션이 실제 도구를 실행하고 결과를 다시 모델에 전달합니다.

sequenceDiagram
    actor U as User
    participant A as Agent
    participant L as LLM
    participant T as Tool

    U->>A: 요청
    A->>L: 요청 + 사용 가능한 도구
    L-->>A: 도구 선택 + 인자
    A->>T: 도구 실행
    T-->>A: 실행 결과
    A->>L: 결과 전달
    L-->>A: 다음 판단 또는 최종 답변
    A-->>U: 응답

MCP(Model Context Protocol)는 애플리케이션이 도구와 데이터 소스를 표준 방식으로 연결하도록 돕습니다. Host가 MCP Server의 도구 정보를 모델에 제공하고, 모델이 호출을 선택하면 애플리케이션이 이를 실행합니다.

Tool Calling과 MCP는 같은 개념이 아닙니다.

• Tool Calling: 모델이 도구 사용을 선택하고 구조화된 호출을 만드는 동작
• MCP: Host, Client, Server 사이의 도구·데이터 연결 규격

현재 Knowledge Agent에는 실제 Tool Calling이나 MCP가 없습니다. 네 액션은 모두 애플리케이션 내부의 LLM 프롬프트입니다. MCP는 이 샘플을 실제 외부 도구로 확장할 때 사용할 수 있는 다음 단계입니다.

외부 지식을 컨텍스트에 공급하는 방법

LLM은 파라미터에 저장된 지식만으로 모든 질문에 답할 수 없습니다. 최신 정보, 사내 문서, 도메인 지식을 사용하려면 외부 지식을 컨텍스트에 넣어야 합니다.

RAG와 CAG는 각각 LLM에 외부 지식을 공급하는 컨텍스트 전략입니다. Agent 없이도 사용할 수 있지만 Knowledge Agent에서는 답변 근거를 제공하는 능력으로 사용됩니다.

RAG

RAG(Retrieval-Augmented Generation)는 질문마다 관련 지식을 검색해 프롬프트에 넣습니다.

기본 RAG는 오프라인과 온라인 워크플로우로 나뉩니다.

오프라인
문서 파싱 → 청킹 → 임베딩 → 벡터 인덱스

온라인
질문 임베딩 → 유사도 검색 → 관련 청크 → LLM

오프라인에서는 PDF나 HTML을 일반 텍스트로 바꾸고 작은 청크로 나눕니다. 각 청크의 임베딩을 미리 계산해 벡터 인덱스에 저장합니다. 온라인에서는 질문 임베딩과 가까운 청크를 찾아 질문과 함께 모델에 전달합니다.

청킹은 검색 단위를 결정합니다.

문서 전체가 아니라 관련 청크만 넣으면 제한된 컨텍스트 윈도우를 효율적으로 사용할 수 있습니다. 반면 잘못된 청크를 고르면 모델은 필요한 근거를 받지 못합니다. 프로덕션 RAG에는 ranking, 중복 제거, 다중 소스 검색, 품질 평가 같은 단계가 추가됩니다.

CAG

CAG(Cache-Augmented Generation)는 지식 컨텍스트를 미리 처리하고 생성된 KV cache를 이후 질의에서 재사용합니다.

지식 문서 → 모델 prefill → KV cache 저장
                            ↓
질문 1 ───────────────────→ 답변
질문 2 ───────────────────→ 답변

질의마다 검색하는 단계를 줄일 수 있어 고정된 지식 집합에 반복 질의할 때 유리합니다. 대신 긴 컨텍스트를 처리할 메모리와 KV cache 수명 관리가 필요합니다. 긴 문맥 안에서 필요한 정보를 제대로 찾지 못하는 문제도 고려해야 합니다.

현재 Knowledge Agent에는 CAG가 구현돼 있지 않습니다. vector_db/index.json은 문서 임베딩을 재사용하기 위한 파일이며 모델의 KV cache가 아닙니다.

RAG와 CAG의 트레이드오프

RAG는 품질만, CAG는 성능만 담당하는 식으로 나눌 수 없습니다. 둘 다 품질, 지연, 비용에 영향을 줍니다. 검색한 지식 중 반복 사용하는 부분을 cache하는 방식처럼 함께 사용할 수도 있습니다.

Knowledge Agent가 만드는 호출 그래프

앞에서 살펴본 Actions, Planning, RAG를 Knowledge Agent 사례로 묶어봅니다.

Direct

Direct 경로는 질문을 검색하고 답변 액션 하나를 실행합니다.

질문 → 질문 임베딩 → 검색 → 답변 LLM → 응답

계획 호출이 없어 경로와 비용을 예측하기 쉽습니다.

Planning

Planning 경로는 LLM이 액션 순서를 먼저 구성합니다.

질문 → 계획 LLM → 질문 임베딩 → 검색 → 액션 LLM 1..N → 응답

질문에 맞춰 요약과 분석을 조합할 수 있지만 계획 생성과 액션별 모델 호출이 추가됩니다.

모델 서빙에 발생하는 부담

같은 질문도 실행 정책에 따라 호출 수, 토큰, 지연, 비용이 달라집니다. Planning 경로의 여러 호출이 순차적으로 연결되면 각 단계의 지연이 전체 응답 시간에 누적됩니다. 여러 Agent나 도구를 병렬로 호출하면 순간 동시성도 커집니다.

모델과 도구의 호출 계층도 다릅니다.

• LLM, 임베딩, 비전 모델: 모델 추론 endpoint
• 웹 검색, DB, 파일 시스템: 일반 API 또는 MCP Server

에이전트 플랫폼은 둘을 하나의 작업으로 조율하지만 모든 도구가 모델 서빙 서비스인 것은 아닙니다.

엔터프라이즈 LLM 서빙의 계층형 아키텍처

프로덕션 LLM 플랫폼은 역할과 변경 속도가 다른 여러 계층의 조합입니다. 단순히 모델을 실행하는 것을 넘어, 서비스로서의 운영을 위해서라면 추가로 감당해야하는 부분이 어떻게 존재하는지 알아봅니다. 내용은 아래와 같습니다:

• 인증(authentication)
• 과금 정책(pricing)
• 리소스 관리
• 네트워킹
• 최적화
• 실험(experimentation, 즉 A/B 테스트 등)
• 관측성(observability)
• 온콜 지원

Public API

Public API는 클라이언트와 플랫폼의 계약입니다.

• 요청·응답 스키마
• 인증과 권한
• 스트리밍
• 가격 책정
• rate limit과 quota(이하 쿼터)
• 요청 검증과 버전 관리

API가 단순하면 사용하기 쉽지만 세밀한 제어가 어렵습니다. 기능을 많이 노출하면 유연해지지만 호환성과 운영 부담이 커집니다.

API 관리의 주요 포인트는 아래와 같습니다:

• High concurrency : 수백만 동시 연결 처리 (고동시성)
• Fair usage and monetization : 쿼터/어뷰징 방지/정확한 과금 (공정 사용·수익화)
• Low-latency global access : 지역 라우팅·캐싱으로 최근접 리전 서빙 (저지연 글로벌 접근)
• Security : 인증·테넌트 격리·네트워크 공격 방어 (보안)

리소스 관리

이 계층은 모델, 사용 사례, 고객 워크로드를 여러 리전에서 서비스하기 위해 필요한 인프라 하드웨어 자원(예: CPU, GPU, 메모리, 디스크, 네트워킹)을 관리합니다. 예산 검토와 비용배분 통합 시 함께 고려됩니다.

주요 포인트는 아래와 같습니다:

• Capacity planning : 수요 예측 및 과다 프로비저닝 방지(용량 계획)
• GPU utilization : 데이터센터 전반의 이기종 GPU 풀 고가동률 유지(GPU 활용률)
• Customer prioritization : 중요 워크로드에 쿼터/예약을 강제하면서 저우선순위는 선점 가능하게 스케줄링(고객 우선순위)

모델 선택과 오케스트레이션

이 계층은 요청을 어떤 모델과 실행 경로로 보낼지 결정합니다. 요청마다 어떤 모델을 쓸지, 여러 모델을 오케스트레이션하는 것도 함께 결정합니다. 오케스트레이션으로는 speculative decoding, model families 간 라우팅 등이 있습니다.

• 모델 라우팅
• fallback과 재시도
• 프롬프트와 컨텍스트 조립
• 에이전트와 도구 실행
• 비용·품질 정책

작은 모델은 빠르고 저렴하지만 어려운 질문의 품질이 낮을 수 있습니다. 큰 모델은 품질이 높지만 비용과 지연이 증가합니다. 라우팅은 이 차이를 요청별로 조정하는 정책입니다.

주요 포인트는 아래와 같습니다:

• Cost–quality trade-offs : 모든 작업에 최대 모델이 필요한 건 아님(예: OpenAI가 기본값으로 gpt-4o-mini 사용) → 쿼리를 이해해서 triaging해야 함(비용-품질 트레이드오프)
• Load balancing : 모델 풀 전반에 트래픽 분산(로드 밸런싱)
• Latency-sensitive use cases : 지연에 민감한 케이스엔 더 작고 빠른 모델이나 speculative decoding 적용

모델 분산 서빙

모델 분산 서빙 계층은 모델 실행을 위한 분산 인프라를 이야기합니다. 이는 일반적으로 두 가지 그룹으로 나뉘는데, 대형 모델을 위한 분산 모델 호스팅과 불필요한 계산을 줄이기 위한 분산 캐싱(예: KV 캐싱, 프롬프트 캐싱, 시맨틱 캐싱)입니다.

• 대형 모델을 위한 분산 호스팅
• KV 캐시·프롬프트 캐시·시맨틱 캐시 같은 분산 캐싱으로 중복 연산 감소

배치를 크게 하면 GPU 활용률과 처리량이 올라갈 수 있습니다. 하지만 요청이 배치를 기다리는 시간이 늘어 TTFT가 나빠질 수 있습니다. 처리량과 개별 지연 사이의 대표적인 트레이드오프입니다.

주요 포인트는 아래와 같습니다^[1]:

• Hardware limitations : 모델 크기가 단일 GPU 메모리 초과(하드웨어 한계)
• Multi-GPU and multi-node coordination : 멀티GPU/멀티노드가 요청 컨텍스트를 효율적으로 공유해 SLA 유지(코디네이션)
• Caching for efficiency : KV 캐시 인식 라우팅으로 중복 추론 감소(캐싱 효율)

Core Inference

Core Inference는 실제 토큰 생성을 수행합니다. vLLM/Triton/TensorRT-LLM/SGLang 같은 서빙 프레임워크와 FlashAttention/GEMM/PagedAttention 같은 최적화 커널을 웹 엔드포인트로 노출하는 것을 의미합니다.

• 다양한 프레임워크 살펴보기(vLLM/Triton/TensorRT-LLM/SGLang)
• 다양한 최적화기법 살펴보기(FlashAttention, GEMM, PagedAttention)

주요 포인트는 아래와 같습니다:

• 모델별 dependency와 framework가 다를 수 있다.
• model load/unload가 latency spike를 만든다.
• hot model과 cold model의 traffic 차이가 크다.
• 모델 cache eviction 정책이 성능과 비용에 직접 영향을 준다.
• 보안, 격리, observability가 single-model보다 복잡하다.
• Cold start latency
• Hot model scaling

모델 최적화

모델 최적화는 같은 하드웨어에서 더 빠르고 저렴하게 추론하기 위한 기법입니다.

• 양자화
• tensor·pipeline parallelism
• 최적화 커널
• speculative decoding
• 모델 압축

최적화는 속도와 메모리를 개선할 수 있지만 정확도, 구현 복잡도, 하드웨어 종속성이라는 비용이 따릅니다.

관측성, 보안, 정책

이 기능들은 특정 한 계층이 아니라 전체 경로에 걸쳐 있습니다.

• 로그, 메트릭, 분산 추적
• 모델·도구별 지연과 오류율
• 토큰과 비용 집계
• 개인정보와 프롬프트 보호
• 감사 기록
• 품질 평가와 SLO

에이전트 요청은 여러 서비스를 거치므로 개별 호출 로그만으로 전체 병목을 찾기 어렵습니다. 하나의 사용자 작업을 같은 trace로 연결해야 합니다.

서비스 구축 살펴보기

KServe 계열과 Ray 계열

KServe와 Ray Serve는 Kubernetes 위에서 모델 endpoint를 운영하는 서로 다른 선택지입니다. 두 계열의 역할 차이와 FastAPI → KubeRay → Ray Serve LLM → vLLM 예시는 별도 문서에서 살펴봅니다.

직접 구축과 클라우드 서비스 사이

직접 구축과 클라우드는 운영 책임을 어디까지 가져갈지 정하는 갈래를 정하는 것입니다.

완전 관리형 API
  ↕
관리형 모델 엔드포인트
  ↕
관리형 Kubernetes + 오픈소스 서빙
  ↕
자체 클러스터 + 자체 추론 스택

선택 기준

관리형 서비스는 인프라 구축 시간을 줄여줍니다. 대신 모델과 스케줄링을 세밀하게 제어하기 어렵고 사용량 기반 비용에 영향을 받습니다.

직접 구축은 모델, 하드웨어, 배칭 정책을 조정할 수 있습니다. 대신 GPU 유휴 비용, 배포 자동화, 장애 대응, 보안 패치까지 운영 조직이 책임져야 합니다. 별도의 비용효율성, 규제 준수 요구사항이 있지 않으면 택하거나 혹은 벤더 락인을 피하기 위해 택하기도 합니다.

실습 환경 비교해보기

초기에는 관리형 API로 기능과 수요를 검증할 수 있습니다. 트래픽과 비용이 커지고 최적화 요구가 분명해지면 일부 계층을 직접 운영하는 방식으로 이동할 수 있습니다.

핵심은 “지금 이 선택이 타당한가”라고 할 수 있습니다. 현재 트래픽, 조직 역량, 규정, 최적화 요구에 비해 어느 수준의 운영 책임이 합리적인지 판단하는 것입니다.

그럼에도 직접 구축하는 걸 알아야 하는 이유

1. 클라우드 벤더가 자체적으로 어디까지 제공해주고, 그 책임의 한계가 어디까진지 살펴볼 수 있습니다
   1. AWS LMI 컨테이너의 옵션이 vLLM의 텐서 병렬화, continuous batching 인지 이해할 수 있습니다
   2. Ray Serve 의 @serve.multiplexed는 LRU 캐시 같은 기능임을 파악할 수 있습니다
2. 트레이드오프를 정량화할 수 있습니다
3. 1, 2가 가능하다면 필요한 부분만 커스텀하여 쓴다면 원하는 대로 쓸 수 있겠죠
4. 디버깅 및 트러블 슈팅 포인트를 파악할 수 있습니다

무엇을 측정해야 하는가

아키텍처 선택은 인상이나 단일 평균값이 아니라 지표로 검증해야 합니다. 측정 가능한 결과와 사용자가 기대하는 성능, 사용자 경험, 운영 비용을 전체적으로 살펴보며 결정해야 합니다. 특히나 위에서 살펴본 에이전트 시스템은 여러 단계의 체인 전체에 걸쳐 지연시간을 증폭시키므로 그 부분에 있어 확장성, 비용효율성을 함께 고려해야하며 직접 구축과 클라우드 간 선택 또한 서비스의 SLO를 충족하기 위해 살펴보아야 합니다.

LLM 서빙의 핵심 성능 지표는 아래와 같습니다^[2]. 결국 지연시간과 대역폭임은 차이가 없지만, 지연시간은 TTFT(Time to First Token), ITL(Inter Token Latency) 를 통해 세부적으로 살펴볼 수 있습니다.

중요한 것은, 현재 시스템의 지표와 비즈니스에서 요구하는 어떤 지표를 챙겨야하는지가 중요합니다.

Latency

E2E Latency

사용자가 요청을 보낸 시점부터 최종 응답을 받을 때까지의 시간입니다. 에이전트에서는 계획, 검색, 도구, 모델 호출이 모두 포함됩니다.

전체 E2E Latency는 TTFT와 ITL 모두가 포함된 모습으로 생각하시면 됩니다.

TTFT

Time To First Token은 요청 후 첫 토큰이 도착할 때까지의 시간입니다. 그렇기 때문에 모델 지연시간을 논의할 때 주로 사용되지요.

이 값은 사용자가 느끼는 응답 시작 속도와 가깝습니다. 큐 대기와 prefill^[3]의 영향을 크게 받습니다.

ITL

Inter-Token Latency(혹은 TPOT, Time per Output Token)는 출력 토큰 사이의 시간입니다. 첫 토큰이 빨라도 ITL이 크면 스트리밍 응답이 끊겨 보입니다. decode^[4] 성능과 스케줄링의 영향을 받습니다.

또한 이 값은 LLM의 자기 회귀 토큰 생성 효율성을 이해하는데도 매우 중요하며, 그렇게 때문에 모델 지연시간을 논할 때 함께 사용될 수 있습니다

평균만 보면 느린 요청을 놓칠 수 있습니다. p50과 함께 p95, p99를 확인해야 합니다. 에이전트 체인에서는 각 단계의 tail latency가 전체 지연으로 누적됩니다.

Throughput

RPS

흔히 아는 Requests Per Second입니다. 초당 완료한 요청 수를 나타내죠. 이는 API가 얼마나 많은 사용자 요청을 처리하는지 보여줍니다. 모델이나 전체 서빙 인프라가 일정 시간 내에 처리가능한 요청 수를 수치로 나타냄을 의미합니다.

LLM 특화 부분에서는 단점이 있습니다. 상세한 부분은 후술합니다.

TPS

Tokens Per Second는 초당 처리하거나 생성한 토큰 수입니다. 모델과 추론 엔진의 처리량을 보는 데 유용합니다.

다만 TPS는 생성된 토큰만을 계산하며, 입력토큰, 입력+출력 토큰의 합계는 포함하지 않으므로 벤치마크를 오해하기 쉽습니다.

두 지표를 어떻게 같이 봐야하나요?

RPS와 RPM은 예측 요청 패턴에 민감한데, 단순히 길이 자체만 놓고 요청별로 살펴본다면 긴 출력과 짧은 출력의 지표가 섞여 무의미한 값이 나오게 되죠.

TPS는 토큰당 비용을 계산하는 것에 크게 도움되지만, 벤치마크 점수 조작이 가능합니다. 즉 같은 모델도 입력을 어떻게 배치했는지, 배치를 인위적으로 최적화 했는지에 따라 수치가 다르게 나옵니다.

1. 입력 길이를 줄이면 TTFT가 크게 감소하고, 이는 요청당 작업 부하를 줄이는 효과가 있습니다. 이로 인해 TPS가 실제보다 높게 보이게 됩니다.
2. 더 크거나 최적화된 배치 요청도 TPS를 증가시킬 수 있습니다. 모델 프로세스 병렬성을 극대화하기 위해 배치 크기를 늘리거나, 배치 요청의 입력 및/또는 출력 길이를 균일하게 만들면 GPU 활용도가 향상되고 GPU 유휴 시간이 줄어들어 TPS가 개선될 수 있습니다.

이러한 연유로, 각 지표 뒤 숨은 측정조건을 분석해야 비즈니스에 맞는 선택이 가능합니다.

적절한 접근방법이 있을까요?

이를 위해서 비즈니스에 맞는 게 뭔지 분석을 하고 결정하시기 바랍니다. 아래 체크리스트를 통해 위의 지표를 어떻게 신뢰할 수 있는 지표로 쓸 수 있는지 살펴보시죠.

1. 지연시간과 처리량 간의 트레이드오프를 살펴봅니다
   • 오프라인/배치 워크로드인지? (비용절감에 주안점)
   • 챗봇/실시간 인터랙티브 워크로드인지? (응답성에 주안점)
2. 유스케이스별 "충분히 좋은" 지점 확보
   • 1초를 0.5초로 줄여도 고객의 반응이 미지근하면 다른 최적화로 눈을 돌리는 것이 중요합니다
3. E2E를 TTFT/ITL로 분해
4. 실제 트래픽 패턴을 최대한 그대로 시뮬레이션
   • 긴 프롬프트+짧은 답변 / 짧은 프롬프트+긴 답변 은 다르게 동작합니다
   • 트래픽 또한 균일하지 않습니다. 일자 별 변동도 있을 수 있고 버스트 요청 시 큐잉 지연/실패가 원인일 수도 있지요
5. 실험의 일관성 유지
   • 작게 실험하고 빠르게 체크합니다
6. 하드웨어 활용률 모니터링
   • GPU/CPU/메모리 사용량을 반복추적해서, 병목의 지점을 명확히 파악합니다
   • 모델 자체로 인한 병목인지, 하드웨어 한계인지 구분합니다
7. 지표를 부풀리지 않을 것 (TPS 지표 등을 내 상황에 맞게 확인)
8. 프로덕션에서의 지속적인 모니터링
   • 배포 후에도 사용자의 행동변화로 인한 트래픽 급증/실패까지 모두 관찰해야 합니다
9. 테스트 스위트의 주기적인 재실행
   • 회귀방지, 스케일링 테스트, A/B 테스트 등을 통해 성능이 유지되는지 지속적인 확인이 필요합니다

우선순위를 잡는 방법

앞서 말씀드렸듯 애플리케이션과 사용 사례에 따라 우선순위가 크게 달라집니다.

에이전틱 워크플로우의 경우

E2E가 최우선 달성입니다. 위에서 살펴본 KnowledgeAgent 의 예시의 경우, 전체 출력을 컨텍스트로 받은 후 작업을 시작할 수 있었죠. 각 단계의 E2E 자체를 빠르게 달성해야함을 의미합니다.

챗봇(스트리밍 응답)

TTFT가 사용자 경험에 가장 큰 영향을 줍니다. 응답성 그 자체라 할 수 있습니다.

출력이 매우 긴 경우

ITL도 중요해지는 시점입니다. ITL이 높으면 응답이 "느릿느릿하다"고 체감되기 때문이지요.

에이전트 작업 수준 지표

에이전트는 모델 지표만으로 설명되지 않습니다. 사용자 작업 전체를 측정해야 합니다.

• 작업당 모델 호출 수
• 작업당 입력·출력 토큰 수
• 계획, 검색, 도구별 지연
• 전체 임계 경로
• 작업 성공률
• 근거 사용률과 OOD 거절률
• 작업당 비용

모델 TPS가 높아도 계획과 도구가 느리면 E2E Latency는 나쁠 수 있습니다. 반대로 빠른 경로가 근거 없는 답을 생성한다면 서비스 품질은 낮습니다.

품질 지표와 성능 지표를 분리하기

Knowledge Agent의 평가 스크립트는 품질과 실행 계약을 확인합니다.

품질과 성능은 함께 봐야 합니다. 임계값을 높이면 OOD 거절률은 좋아질 수 있지만 정상 질문도 더 많이 거절할 수 있습니다. 더 많은 액션은 답변을 풍부하게 만들 수 있지만 지연과 비용을 늘립니다.

현재 실습에서 측정할 수 있는 범위

로컬 Knowledge Agent에서는 다음 값을 확인할 수 있습니다.

• Direct와 Planning의 E2E Latency
• 계획·답변 호출 수
• 입력·출력 토큰 수
• 검색·답변 품질
• OOD에서 차단한 답변 호출 수

현재 CLI는 동기식이며 동시 부하와 스트리밍을 다루지 않습니다. TTFT, ITL, RPS, TPS를 제대로 비교하려면 스트리밍 API와 부하 생성기가 필요합니다. 이 부분은 Bedrock과 KubeRay 실습에서 확장할 수 있습니다.

벤치마크에서는 모델, 입력 길이, 출력 길이, 동시성, warm-up 조건을 고정해야 합니다. 그래야 관리형 서비스와 자체 서빙의 차이를 공정하게 비교할 수 있습니다.

마치며

에이전트 워크플로우가 등장하면서 모델 서빙의 단위는 개별 추론 요청에서 사용자 작업 전체로 바뀝니다. 계획, 검색, 도구, 반복 추론은 호출 수와 토큰을 늘리고, 단계별 지연과 실패를 전체 경로에 전파합니다.

계층형 아키텍처는 이 복잡성을 Public API, 오케스트레이션, 리소스 관리, Core Inference, 모델 최적화로 나눕니다. Kubernetes와 KubeRay는 인프라와 클러스터를 관리하고, Ray Serve는 애플리케이션 deployment와 replica를 조율하며, 추론 엔진은 실제 토큰 생성을 최적화합니다.

직접 구축과 클라우드 서비스 사이의 선택은 운영 책임의 위치를 정하는 일입니다. 빠른 검증과 변동 트래픽에는 관리형 서비스가 유리할 수 있고, 크고 안정적인 트래픽과 강한 커스터마이징 요구에는 직접 구축이 유리할 수 있습니다.

이 판단은 측정으로 검증해야 합니다. E2E Latency, TTFT, ITL, RPS, TPS뿐 아니라 에이전트 작업당 호출 수, 토큰, 비용, 품질을 함께 봐야 합니다. 결국 좋은 서빙 아키텍처는 가장 복잡한 시스템이 아니라 현재 워크로드의 품질 목표를 예측 가능한 비용과 지연으로 만족하는 시스템입니다.