CELL AI DEVLOG

1~3편에서 라우팅 전략·폴백·프로덕션 배포를 다뤘습니다. 4편은 그 다음 단계입니다. 6개의 기본 전략이 모두 "어느 배포로 보낼까"를 결정했다면, 여기서는 "어떤 모델 티어로 보낼까"를 결정하는 콘텐츠 기반 라우팅을 다룹니다. 그리고 프로덕션 현장에서 실제로 쓰이는 세 가지 아키텍처 패턴 — 고가용성 멀티 리전, 비용 최적화 3티어, 하이브리드 클라우드+로컬 — 을 완전한 config.yaml과 함께 정리합니다. 시리즈의 마무리로, LiteLLM의 한계도 솔직하게 다룹니다.이 포스트 한 줄 요약 → Tag 라우팅: x-litellm-tags 헤더로 요청을 특정 배포 그룹으로 분류 → 복잡도 라우터: 임베딩 API 호출 없이 규칙 기반으로 서브밀리초 분류 → 시맨틱 라우터: 발화(utterance) 임..

1편에서 라우팅 전략을, 2편에서 폴백과 장애 대응을 다뤘습니다. 코드는 완성됐지만 프로덕션에 올리면 달라지는 게 있습니다. 단일 프로세스로 돌리면 멀티 인스턴스 간 RPM/TPM 상태를 공유할 수 없고, API 키를 코드에 박으면 팀원에게 공유할 수 없고, 누가 얼마나 쓰는지 보이지 않으면 월말에 청구서로 알게 됩니다. 3편은 그 세 가지를 해결합니다. Redis로 멀티 인스턴스 상태 동기화, Docker/K8s Proxy 서버 배포, Virtual Key로 팀별 예산과 Rate Limit 관리, Langfuse·Prometheus 연동까지 — 프로덕션에서 LiteLLM이 실제로 어떻게 운영되는지 전부 다룹니다.이 포스트 한 줄 요약 → Redis 없이 멀티 인스턴스 → 각 인스턴스가 독립적으로 RPM..

2024년 4월 9일 UTC 13:00, Anthropic 클러스터에 장애가 발생했습니다. 단일 Anthropic 키에 의존하던 한 팀의 고객 지원 코파일럿은 1시간 동안 완전히 다운됐습니다. 엔지니어가 수동으로 SDK의 base_url을 OpenAI로 바꾸고 재배포하는 데 14분이 걸렸습니다. 같은 해 11월 OpenAI 장애로 2시간, 2025년 2월 Gemini 장애로 반나절. 이 팀이 LiteLLM 폴백을 설정했다면 세 번의 다운타임 모두 자동으로 흡수됐을 것입니다. 폴백은 "있으면 좋은 것"이 아닙니다. 1편의 라우팅 전략이 정상 트래픽을 분산한다면, 2편의 폴백·재시도·쿨다운은 장애 시 시스템을 살려두는 안전망입니다. 이 포스트 한 줄 요약 → 폴백 3종: fallbacks (일반 오류) · ..

LLM 프로덕션에서 단일 엔드포인트에 의존하는 순간 리스크가 시작됩니다. Azure OpenAI 리전이 다운되거나, OpenAI가 Rate Limit을 내뱉거나, 트래픽 폭증으로 TPM 한도가 터질 때 — 이 모든 상황을 코드 한 줄 바꾸지 않고 흡수하는 것이 LiteLLM Router입니다. 100개 이상의 LLM 프로바이더를 단일 OpenAI 호환 인터페이스로 추상화하면서, 6가지 라우팅 전략과 자동 폴백·재시도를 제공합니다. 이 편에서는 Router의 내부 구조와 6가지 전략 각각이 어떻게 동작하는지, 언제 무엇을 써야 하는지를 실전 코드와 함께 완전히 정리합니다.이 포스트 한 줄 요약 → LiteLLM Router: 동일 model_name으로 여러 배포를 등록하면 자동 로드밸런싱 → 핵심 내부 ..

"에이전트를 더 많이 쓰면 더 좋아진다." 2024년의 믿음이었습니다. 2026년 프로덕션 현장의 데이터는 다른 이야기를 합니다. Princeton NLP 연구에서 단일 에이전트가 동일한 툴과 컨텍스트를 주었을 때 멀티에이전트를 64%의 태스크에서 동등하거나 능가했습니다. 멀티에이전트는 정확도를 평균 2.1% 올리지만 비용은 약 2배입니다. Gartner가 Q1 2024에서 Q2 2025 사이 멀티에이전트 도입 문의가 1,445% 급증했다고 보고할 동안, Cognition은 "Don't Build Multi-Agents"를 발표했다가 8개월 후 "Devin이 Devin을 관리할 수 있다"로 돌아왔습니다. 이것이 이 분야의 현주소입니다. 5가지 핵심 패턴을 구조·코드·트레이드오프와 함께 정리하고, 언제 단..

6편에서 파이프라인을 완성했습니다. 7편은 멈추는 법입니다. LLM 판사가 강력한 도구인 것은 사실이지만, "강력하다"와 "만능이다"는 다릅니다. 판사가 구조적으로 실패하는 영역이 있습니다. 사실 오류를 탐지하는 데 취약하고, 전문 도메인에서 전문가와 일치율이 급락하고, 적대적 입력에 취약하고, 검증 가능한 태스크에서 실행 없이 판단하는 것이 본질적 한계입니다. 이 한계를 모르면 판사가 틀렸을 때 조용히 틀립니다. 무엇이 한계인지, 각각의 대안이 무엇인지, 그리고 이 모든 걸 종합한 하이브리드 평가 아키텍처로 7편을 마무리합니다.7편이 다루는 것 → 한계 1: 사실 오류 탐지 실패 — 왜 유창함이 정확성을 가린다 → 한계 2: 전문 도메인 갭 — 의료·법률·금융에서 일치율 10~15% 하락 → 한계 3:..

평가 파이프라인은 두 가지 잘못된 방향으로 망가집니다. 첫 번째는 "아무것도 안 하기" — 프로덕션에서 품질을 측정하지 않습니다. 두 번째는 "모든 것을 평가하기" — 모든 스팬에 판사 API를 붙여서 비용이 프로덕션 추론과 같아지고, 사용자 응답 지연에 평가 시간이 더해집니다. 2026년 기준으로 대부분의 팀은 레벨 0~1(측정 없음 또는 오프라인 eval만)에 머물고 있습니다. 레벨 2(비동기 프로덕션 모니터링)까지 가는 데 1주일이면 충분하고, 레벨 3(CI 게이트 + 캘리브레이션 주기)까지는 한 달입니다. 이 6편에서 그 구체적인 방법을 전부 코드로 정리합니다.6편이 다루는 것 → 평가 성숙도 5단계 모델 — 현재 어디에 있는지 진단 → 결정론적 샘플링 — 해시 기반 5% 샘플링, 재현 가능성 보..

LLM 판사를 만들고 나서 가장 많이 하는 실수는 "그냥 돌려본다"는 것입니다. 판사가 얼마나 신뢰할 수 있는지 측정하지 않고 사용하는 것입니다. 기존 연구들이 주로 Pearson/Spearman 상관관계에 의존했다면, 더 엄밀한 접근은 Cohen's κ로 실제 일치도를 정량화하는 것입니다. 판사가 실제로 의미 있는 평가를 하고 있는지 알려면 세 가지가 필요합니다. 인간 레이블이 달린 황금 세트, 판사와 인간 판단의 일치도를 측정하는 통계 기법, 그리고 페어와이즈 비교 결과를 절대 강도로 변환하는 Bradley-Terry 모델. 황금 세트 설계부터 통계 검정, Bradley-Terry 구현, 그리고 판사를 신뢰할 수 있는지 판단하는 실용적 기준까지 전부 다룹니다.5편이 다루는 것 → 황금 세트(Golde..

LLM-as-a-Judge 프레임워크는 지금 빠르게 갈라지고 있습니다. API 프론티어 판사(GPT-4o, Claude Opus)에 프롬프트를 얹는 방향이 있고, 오픈소스로 파인튜닝한 전용 판사 모델 방향이 있고, 아예 API 호출 없이 코드로 판사를 합성하는 방향이 있습니다. 각 방향의 대표 프레임워크는 G-Eval, Prometheus 2, PAJAMA, Themis입니다. 그리고 증류된 판사(Distilled Judge)가 이 모두를 아우르는 비용 최적화 전략으로 자리잡았습니다. 무엇이 언제 맞는지, 각 프레임워크의 원리·구현·한계를 실전 코드와 함께 정리합니다. 4편이 다루는 것 → G-Eval (Liu et al. 2023, EMNLP) — CoT + Form-filling + 확률 가중 점수의..

2편에서 7가지 편향을 측정했습니다. 3편은 그것들을 고치는 법입니다. 중요한 전제: "더 좋은 프롬프트"는 해결책이 아닙니다. 2024년 arXiv:2604.23178은 9가지 완화 전략을 5개 판사, 3개 벤치마크, 225개 통제 케이스에서 체계적으로 비교했습니다. 결론은 명확합니다. 편향 완화는 프롬프트가 아니라 기계적 절차로 해결합니다. 각 편향마다 다른 처방이 필요하고, 조합할 때 비용 대비 효율이 달라집니다. 편향별 완화 전략을 코드와 함께, 그리고 실제로 얼마나 효과가 있는지 수치와 함께 정리합니다.3편이 다루는 것 → arXiv:2604.23178의 S1~S8 전략 체계 — 비용·효과 매핑 → 편향 7종 각각에 대한 완화 전략 코드 → Length-Controlled Win Rate (Du..