AI Agent 개발 아키텍처: Client부터 LiteLLM, vLLM까지 - 01
중년개발자
@loxo
약 4시간 전
AI Agent 개발 아키텍처: Client부터 LiteLLM, vLLM까지
AI Agent 서비스는 사용자의 요청을 받아 AI가 판단하고 도구를 실행한 뒤, 자연스러운 답변을 돌려주는 시스템입니다. 간단히 말하면 다음 흐름입니다.
1. 전체 시퀀스 흐름
-
사용자가 Client에서 질문을 보냅니다.
예: “이번 달 매출을 요약하고 감소 원인을 알려줘.” -
Client는 Agent API로 요청을 전달합니다.
이때 사용자 인증 정보, 대화 ID, 첨부 파일, 현재 화면의 맥락 등을 함께 보낼 수 있습니다. -
Agent Server는 요청을 이해하고 실행 계획을 세웁니다.
단순 질문이면 바로 모델에 전달하고, 데이터 조회가 필요하면 DB나 사내 API 같은 도구를 호출합니다. -
Agent Server는 LiteLLM을 통해 적절한 AI 모델을 요청합니다.
LiteLLM은 여러 모델 제공자와 모델 서버를 하나의 공통 방식으로 연결해 줍니다. -
LiteLLM은 vLLM 또는 외부 모델 API로 요청을 전달합니다.
사내 GPU에서 오픈소스 모델을 직접 운영한다면 보통 vLLM을 사용합니다. -
vLLM은 GPU에서 모델 추론을 수행합니다.
모델이 답변 또는 “도구를 호출해야 한다”는 지시를 생성합니다. -
Agent Server는 필요하면 도구를 실행하고 결과를 다시 모델에 전달합니다.
예: 매출 DB 조회 → 결과를 모델에 제공 → 분석 문장 생성. -
최종 답변은 Client로 스트리밍되거나 한 번에 반환됩니다.
Client는 이를 채팅 화면, 보고서, 알림 또는 업무 화면에 표시합니다.
2. 구성 요소별 역할
| 구성 요소 | 역할 | 핵심 기능 |
|---|---|---|
| Client | 사용자가 AI와 만나는 화면 | 채팅 UI, 파일 업로드, 답변 표시, 스트리밍 렌더링 |
| Agent Server | AI Agent의 두뇌와 업무 조정자 | 프롬프트 구성, 도구 선택, 실행 순서 제어, 상태 관리 |
| LiteLLM | 모델 연결을 표준화하는 중간 계층 | 모델 라우팅, API 형식 통일, 비용·사용량 추적, 재시도 |
| vLLM | 오픈소스 모델을 빠르게 서빙하는 추론 엔진 | GPU 추론, 동시 요청 처리, 토큰 스트리밍, 모델 호스팅 |
| LLM | 언어 이해·생성 모델 | 질의 이해, 추론, 답변 생성, 도구 호출 판단 |
| Tools | AI가 실제 업무를 수행하도록 돕는 기능 | DB 조회, 웹 검색, 사내 API 호출, 메일·문서 처리 |
| 데이터 계층 | AI가 참고하고 기억할 정보를 관리 | 대화 기록, 사용자 권한, 문서 저장소, 벡터 DB |
3. 각 용어를 쉽게 이해하기
AI Agent
AI Agent는 단순히 문장을 생성하는 챗봇보다 한 단계 더 나아간 시스템입니다. 질문에 답하는 것뿐 아니라, 필요한 정보를 찾고 도구를 사용하며 여러 단계를 거쳐 목표를 수행합니다.
예를 들어 “지난주 장애 원인을 정리해 줘”라는 요청을 받으면 Agent는 장애 로그를 조회하고, 관련 배포 기록을 찾고, 내용을 분석해 보고서를 만듭니다.
LLM
LLM(Large Language Model)은 많은 텍스트를 학습한 언어 모델입니다. 사람의 언어를 이해하고 다음에 올 내용을 예측하여 답변을 만듭니다. GPT, Llama, Qwen 등이 대표적인 LLM입니다.
다만 LLM 자체는 최신 사내 데이터나 실시간 시스템 정보를 자동으로 알지 못합니다. 그래서 Agent, 검색, 데이터베이스, 도구 연결이 필요합니다.
AI Serving
AI Serving은 학습이 끝난 모델을 실제 서비스에서 사용할 수 있도록 운영하는 일을 뜻합니다. 사용자의 요청을 모델에 전달하고, GPU에서 추론한 결과를 빠르게 돌려주는 서버 운영 영역입니다.
쉽게 말하면 모델이 “똑똑한 엔진”이라면, AI Serving은 그 엔진을 많은 사용자가 안정적으로 사용할 수 있게 만드는 운영 시스템입니다.
vLLM
vLLM은 오픈소스 LLM을 GPU에서 효율적으로 실행하기 위한 모델 서빙 엔진입니다. 여러 사용자의 요청을 동시에 처리하고, 답변을 토큰 단위로 빠르게 보내는 데 강점이 있습니다.
주로 다음과 같은 경우에 사용합니다.
- 사내 환경에서 Llama, Qwen 같은 오픈소스 모델을 운영할 때
- 모델 사용 비용과 데이터 보관 위치를 직접 통제해야 할 때
- 많은 동시 사용자를 빠르게 처리해야 할 때
LiteLLM
LiteLLM은 여러 AI 모델과 제공자를 공통 인터페이스로 연결하는 통합 계층입니다. 개발자는 한 가지 API 형식으로 요청을 보내고, 내부적으로는 OpenAI API, Anthropic API, Azure, vLLM 등 다양한 대상에 연결할 수 있습니다.
LiteLLM을 사용하면 특정 모델에 코드가 강하게 묶이지 않습니다. 예를 들어 기본 모델은 사내 vLLM으로 사용하다가, 고난도 작업만 외부 상용 모델로 보내는 정책을 만들 수 있습니다.
RAG
RAG(Retrieval-Augmented Generation)는 AI가 답변하기 전에 관련 문서를 찾아 참고하게 하는 방식입니다. 내부 규정, 제품 문서, 회의록처럼 모델 학습에 없던 지식을 답변에 반영할 때 사용합니다.
일반적인 흐름은 문서 검색 → 관련 내용 추출 → LLM에 참고 자료로 전달 → 근거 기반 답변 생성입니다.
Vector DB
Vector DB는 문서의 의미를 숫자 벡터로 저장하고, 질문과 의미가 비슷한 문서를 찾아주는 데이터베이스입니다. RAG에서 “질문과 관련된 문서 찾기”를 담당합니다.
4. 권장 아키텍처 관점
서비스를 설계할 때는 “모델을 호출한다”는 관점보다 다음 네 가지 계층으로 나누는 것이 좋습니다.
Presentation 계층
사용자가 사용하는 웹, 모바일, Slack, 사내 포털 등의 화면입니다. 사용성, 응답 스트리밍, 파일 업로드, 대화 이력 표시가 중요합니다.
Orchestration 계층
Agent의 핵심 계층입니다. 어떤 모델을 쓸지, 어떤 도구를 호출할지, 어떤 순서로 작업할지 결정합니다. 서비스의 비즈니스 규칙과 권한 검증도 이 계층에 둡니다.
Intelligence 계층
LLM과 모델 서빙 시스템이 위치합니다. LiteLLM은 모델 선택과 연결을 담당하고, vLLM은 사내 GPU에서 모델을 실행합니다.
Data & Platform 계층
대화 이력, 문서, 사용자 정보, 권한, 로그, 모니터링 데이터를 다룹니다. 실제 서비스 품질과 보안은 이 계층의 완성도에 크게 좌우됩니다.
5. 개발해야 할 항목
필수 개발 항목
-
Client 채팅 화면
질문 입력, 답변 스트리밍, 대화 이력, 오류 안내, 파일 첨부 기능을 제공합니다. -
Agent API
요청을 받고 사용자 권한을 확인하며, Agent 실행 결과를 반환합니다. -
Agent 실행 로직
시스템 프롬프트, 모델 호출, 도구 호출, 결과 검증, 재시도 정책을 구현합니다. -
Tool 연동
사내 DB, 문서 시스템, 검색 시스템, 업무 API를 안전한 형태로 연결합니다. -
LiteLLM 설정
vLLM과 외부 모델 제공자를 등록하고, 모델별 라우팅·Fallback·사용량 측정 정책을 구성합니다. -
vLLM 운영 환경
모델 파일, GPU 서버, API 엔드포인트, 동시 처리량, 장애 대응을 구성합니다. -
대화·문서 데이터 저장
대화 기록은 관계형 DB에, 문서 검색용 벡터 데이터는 Vector DB에 저장하는 구성이 일반적입니다.
운영에 반드시 필요한 항목
-
인증과 권한 관리
사용자가 볼 수 있는 문서와 실행할 수 있는 도구를 엄격히 제한해야 합니다. -
관측성
요청 시간, 모델 응답 시간, 도구 호출 성공률, 토큰 사용량, 오류율을 기록하고 모니터링합니다. -
비용 관리
모델·사용자·기능별 토큰 사용량을 추적하고, 고비용 모델 사용 정책을 관리합니다. -
안전장치
프롬프트 인젝션 방어, 민감정보 마스킹, 위험한 도구 실행 승인, 출력 검증이 필요합니다. -
평가 체계
대표 질문 세트를 만들고 정확성, 근거성, 응답 속도, 도구 성공률을 지속적으로 측정합니다.
6. 실무에서 자주 추가되는 기능
모델 라우팅
모든 요청에 가장 비싼 모델을 쓰지 않고, 난이도·업무 유형·보안 조건에 따라 모델을 선택하는 기능입니다.
예를 들어 간단한 요약은 작은 사내 모델(vLLM), 복잡한 추론은 고성능 모델, 민감 데이터는 외부 전송이 없는 사내 모델로 처리할 수 있습니다.
Fallback
기본 모델 서버에 장애가 있거나 응답이 느릴 때, 다른 모델 또는 다른 서버로 자동 전환하는 기능입니다. LiteLLM 같은 통합 계층이 이 정책을 관리하기 좋습니다.
Human-in-the-loop
메일 발송, 결제, 데이터 삭제처럼 중요한 행동은 AI가 바로 실행하지 않고 사람의 승인 후 처리하게 하는 방식입니다.
메모리
짧은 대화 맥락뿐 아니라 사용자의 선호, 이전 작업, 팀 규칙을 저장해 다음 대화에 활용하는 기능입니다. 다만 개인정보와 오래된 정보 문제를 고려해 저장 범위와 만료 정책을 설계해야 합니다.
7. 시작하기 좋은 최소 구성
처음부터 복잡한 멀티 에이전트 구조를 만들 필요는 없습니다. 다음 순서가 현실적입니다.
- Client + Agent API + 단일 모델 연결
- LiteLLM을 추가해 모델 호출 방식을 표준화
- vLLM으로 사내 오픈소스 모델 서빙
- 한두 개의 안전한 도구 연동
- 문서 검색 기반 RAG 추가
- 로그, 평가, 권한, 비용 관리 고도화
- 필요할 때만 복잡한 워크플로 또는 다중 Agent 도입
핵심은 LLM을 중심으로 모든 것을 설계하는 것이 아니라, Agent Server를 중심으로 모델·도구·데이터·보안을 조합하는 것입니다. LiteLLM은 모델 선택과 연결을 유연하게 만들고, vLLM은 자체 모델 서빙의 성능과 통제권을 제공합니다. 이 둘 위에 안전한 Agent 실행 계층과 신뢰할 수 있는 데이터 계층을 갖추면 실제 업무에 사용할 수 있는 AI Agent 시스템을 만들 수 있습니다.