🏷️ AI

LiteLLM 라우팅 가이드 - 로드밸런싱, 라우팅 그룹, Auto Router

lemon • 2026-10-22 • AI, DevOps

LLM을 서비스에 연동하면 특정 제공자나 리전에 요청이 집중되어 속도 제한(Rate Limit)과 응답 지연이 발생할 수 있다. 또한 특정 제공자에 장애가 발생하면 서비스 전체가 중단될 위험이 있으며, 단순한 질문에도 고가 모델을 사용하면 불필요한 비용이 발생한다.

이를 해결하려면 요청 분산, 장애 시 자동 전환(fallback), 복잡도에 따른 모델 선택을 통합적으로 수행하는 LLM 로드밸런싱 및 라우팅 체계가 필요하다.

LiteLLM 사용량 추적 가이드 - Virtual Key, 사용자, Usage

lemon • 2026-10-21 • AI, DevOps

사내에서 LLM을 쓰게 하면 곧 “누가 얼마나 썼는가"라는 질문이 나온다. LiteLLM은 Virtual Key, 사용자, 로그를 조합해서 이 답을 주지만, 개념이 여러 층으로 나뉘어 있어서 처음에는 어디에 무엇이 쌓이는지 헷갈린다. 특히 LibreChat 같은 앱이 키 하나를 모든 사용자가 공유하는 구조에서는 더 그렇다. 키 단위 spend는 쌓이지만 사용자별로는 보이지 않거나, 보이더라도 사용자 본인 화면(Your Usage)에는 안 나오는 일이 생긴다.

vllm-mlx 기반 RAG 챗봇 구축 (5) - LibreChat UI와 MCP 도구 연동

lemon • 2026-10-06 • AI, RAG

4편에서는 챗봇과 모델 서버 사이의 LiteLLM 게이트웨이를 구성했다. 이번 편에서는 사용자가 실제로 마주하는 챗봇 UI인 LibreChat을 다룬다. LibreChat은 앞 편에서 만든 구성요소를 하나로 묶는 지점이다. 모델 호출은 LiteLLM으로, 문서 검색은 MCP로 simple-rag에 연결되고, 이 연결은 모두 config/librechat.yaml 한 파일에 정의된다. 이 글은 시작하기, 사용자 등록, 모델 메뉴 구성, LiteLLM 연동, MCP 서버 연동의 순서로 설정을 살펴본 뒤, 챗봇에서 업로드한 문서를 근거로 답하게 하는 과정과 에이전트의 capabilities 설정까지 다룬다.

vllm-mlx 기반 RAG 챗봇 구축 (4) - LiteLLM 게이트웨이와 Fallback 전략

lemon • 2026-10-05 • AI, RAG

3편에서는 문서 검색 API와 MCP 서버를 다루었다. 이번 편에서는 챗봇과 모델 서버 사이에서 요청을 중개하는 LiteLLM의 구성을 설명한다. LiteLLM 설정에서 핵심이 되는 사항은 두 가지다. 하나는 처리할 수 있는 요청의 범위를 정하는 컨텍스트 한도이고, 다른 하나는 로컬 모델이 요청을 처리하지 못할 때의 대응 방식인 fallback이다. 특히 fallback은 문서와 대화를 외부로 내보내지 않는다는 프로젝트의 전제와 충돌할 수 있으므로, 설계 시 프라이버시를 함께 고려해야 한다. 아울러 요청에 사용자 식별 헤더를 붙여 사용량을 사용자별로 나눠 보는 방법도 다룬다.

vllm-mlx 기반 RAG 챗봇 구축 (3) - 문서 검색 API와 MCP 서버

lemon • 2026-10-04 • AI, RAG

2편에서 모델 서버의 메모리를 설계했다. 이번 편은 그 서버를 호출하는 simple-rag를 다룬다. 문서를 청크로 나눠 pgvector에 저장하고, 질문이 오면 관련 청크를 찾아 답을 만들며, 같은 검색을 MCP 도구로 챗봇에 내놓는 서비스다. 코드가 작아서 RAG의 각 단계를 눈으로 따라갈 수 있고, 단계마다 점수와 응답이 어떻게 나오는지도 직접 확인해 볼 수 있다.

vllm-mlx 기반 RAG 챗봇 구축 (2) - 모델 서버 구성과 메모리 설계

lemon • 2026-10-03 • AI, RAG

1편에서 전체 구성을 띄워 봤다. 이번 편은 그중 호스트에서 도는 vllm-mlx를 다룬다. 모델을 띄우는 일은 쉬웠고, 어려웠던 것은 한정된 메모리 안에서 긴 RAG 프롬프트를 감당하게 만드는 일이었다. 각 설정값이 왜 그 값인지, 메모리를 어떻게 나눠 썼는지를 정리한다.

vllm-mlx 기반 RAG 챗봇 구축 (1) - 전체 구성과 설치

lemon • 2026-10-02 • AI, RAG

RAG 챗봇을 만들려면 LLM 서빙부터 임베딩, 리랭킹, 벡터 저장소, 검색 API, 모델 게이트웨이, 챗봇 UI까지 여러 기술 요소가 필요하다. 이 시리즈는 이들을 로컬 환경에 직접 구동하고 연결하면서 각 기술의 역할과 연동 방식을 확인하고, 실제 RAG 챗봇 구축에 필요한 기술 조합을 PoC 형태로 검증한다. 1편에서는 전체 구성을 살펴보고, 설치부터 동작 확인까지 따라 하며 확인한다. 각 요소의 설계와 설정값의 근거는 2편부터 하나씩 다룬다.

Airflow로 시작하는 MLOps 파이프라인 (1) - Kubernetes에 Helm으로 설치하고 DAG 구성하기

lemon • 2026-09-23 • AI, DevOps, MLOps

모델 학습은 데이터 분석, 전처리, 학습, 평가, 등록까지 여러 단계를 순서대로 거친다. 이 단계를 매번 스크립트로 수동 실행하면 실패 지점을 놓치기 쉽고, 재시도나 조건 분기 같은 로직을 직접 코드로 만들어야 한다. Airflow는 이런 단계를 DAG(방향성 비순환 그래프)로 정의하고, 각 단계의 성공/실패/재시도를 스케줄러가 대신 관리해주는 오케스트레이션 도구다. 특히 유용한 건 이 모든 상태를 대시보드를 통해서 확인하고 관리할 수 있다는 점이다. 이런 특성 덕분에 Airflow는 데이터/ML 파이프라인 오케스트레이션 도구 중 가장 널리 쓰인다.

Qdrant 하이브리드 검색 설계 — RAG 검색 파이프라인의 레이어와 결합 전략

lemon • 2026-09-20 • AI, Database

사내 지식을 저장하고 검색하는 RAG 파이프라인 rag-api를 만들면서 가장 변경이 많이 발생한 구간은 retrieval이었다. 초기 구현은 전형적인 naive RAG였다 — 문서를 청크로 분할해 dense embedding으로 인덱싱하고, 쿼리도 같은 embedding space에 투영해 코사인 유사도로 top-k를 가져오는 구조였다. 하지만 이 구조를 실제 문서 검색에 적용해 보니 dense retrieval 단일 구조의 한계가 그대로 드러났다. 제품 코드·에러 코드처럼 semantic 유사도보다 lexical exact match가 중요한 질의에서는 dense 임베딩의 유사도 점수가 오히려 노이즈에 가까웠고, 반대로 표현은 달라도 의미가 같은 질의에서는 lexical matching만으로 recall을 채울 수 없었다. 여러 KB를 동시에 검색하면 KB마다 다른 score distribution을 그대로 합칠 수 없었고, top-k만으로는 놓치는 relevance를 다시 보정할 reranking 단계도 필요했고, 같은 질의가 반복될 때마다 이 파이프라인 전체를 매번 다시 실행하는 것도 비효율이었다.

SpecRelay — Spec 기반 AI 협업 개발 워크플로우 실전 가이드

lemon • 2026-09-19 • AI, DevOps

AI에게 코드를 맡기면 속도는 빨라지지만 두 극단 사이에서 흔들리기 쉽다. 한쪽 극단은 AI에게 구현만 맡기고 기획→설계→검증은 사람이 매 단계 직접 수행·확인하는 방식인데, 이러면 AI에게 위임해 얻으려던 속도 이점을 살리지 못한다. 다른 극단은 설계·분석 없이 AI에게 통째로 위임하는 것(이른바 vibe coding)인데, 이 경우 근거 없는 설계와 추적 불가능한 변경이 쌓인다. 둘 다 대가를 치르지만, 전자는 속도를 못 살리는 비효율에 그치는 반면 후자는 구조적 부채를 코드베이스에 남긴다는 점에서 더 문제다.

AI 기반 애플리게이션 개발 라이프사이클 - 실무 가이드

lemon • 2026-03-08 • AI, DevOps

기존의 폭포수(Waterfall)와 애자일(Agile)은 모두 인간의 인지 속도와 의사소통 비용을 기준으로 설계된 방법론이다. 스프린트는 2주, 회의는 매일, 코드 리뷰는 며칠씩 걸린다. 그 속도에 맞게 프로세스가 짜여 있다. AI는 그 전제를 깨뜨린다. 코드를 생성하고 인프라를 구성하는 속도는 인간의 수십 배에 달한다. 기존 방법론을 그대로 AI에 적용하면 결정적인 불일치(Mismatch)가 발생한다. AI를 단순한 보조 도구로 끼워 넣는 것은 AI의 역량을 제한할 뿐 아니라 기존의 비효율을 고착시킨다.

제대로 쓰려면 구조가 달라야 한다. AI를 보조 도구가 아닌 프로젝트의 컨텍스트를 유지하는 디지털 동료로 정의하고, 그에 맞는 워크플로우를 설계해야 한다. 이 블로그에서는 프로젝트 설정부터 요구분석, 반복 개발, 지식 축적까지 — Claude Code를 중심으로 실제 개발 흐름 전체를 정리했다.