프롤로그 — "LLM 을 띄우는 것은 쉬워졌다. 운영하는 것이 어렵다"

2024년까지만 해도 LLM 을 production 에 띄우는 것은 신기한 일이었다. 2026년 5월, 그건 더 이상 신기한 일이 아니다. OpenAI · Anthropic · Google · Mistral · DeepSeek · 한국의 HyperCLOVA X · 일본의 Sakana · NTT Tsuzumi 같은 모델은 API 한 줄이면 호출된다. 진짜 어려운 것은 그 다음이다.

- 모델이 어제는 잘 답하던 질문에 오늘 이상한 답을 한다. **왜?**

- 한 사용자가 같은 질문을 다섯 번 했는데 다섯 번 모두 다른 답이 나왔다. **어떻게 재현하고 회귀 테스트로 만들 것인가?**

- 토큰 비용이 한 달에 300만 원에서 갑자기 1500만 원으로 뛰었다. **누가 어디서 그렇게 썼는가?**

- 프롬프트를 한 줄 바꿨더니 100개 테스트 케이스 중 7개가 깨졌다. **어떤 7개가 깨졌고, 다른 93개는 영향이 없나?**

- RAG 시스템의 답이 ground truth 와 얼마나 가까운지, faithfulness 가 얼마인지 **자동으로 측정**할 수 있는가?

이 다섯 가지 질문이 2026년 LLM ops 의 전부다. 그리고 그 질문 각각에 정확히 답하기 위한 도구가 한꺼번에 폭발적으로 늘어났다. Helicone · LangSmith · Langfuse · W&B Weave · Arize Phoenix · Braintrust · Athina · Comet Opik · Vellum · PromptHub · Portkey · TruLens · Ragas · DeepEval · Galileo · Patronus AI · OpenAI Evals · Bedrock Evals · Vertex AI Evaluation Service — 이 글의 제목에 들어간 도구들이 그것이다.

이 글은 2026년 5월 현재의 LLM ops 지도를 펼친다. 네 영역 (관찰성 · 평가 · 프롬프트 관리 · 게이트웨이) 으로 묶고, 각 도구의 강점·약점·가격 모델·실제 사용 현장 사례를 짚는다. 마지막에는 1인 개발자·스타트업·엔터프라이즈·RAG 우선 조직 네 페르소나가 무엇을 골라야 하는지로 마무리한다.

1장 · 2026년 LLM ops 지도 — 네 영역 분류

먼저 큰 그림.

네 영역 — Observability / Evaluation / Prompt management / Gateway

LLM ops 도구는 기능이 겹치지만, 핵심 가치 제안 기준으로 네 영역으로 분류할 수 있다.

| 영역 | 무엇을 하는가 | 대표 도구 |

| --- | --- | --- |

| **Observability** | 모든 LLM 호출을 트레이싱 / 토큰·지연·비용·에러 모니터링 / 디버깅 | Helicone, LangSmith, Langfuse, W&B Weave, Arize Phoenix, Comet Opik |

| **Evaluation** | 모델 출력의 품질을 데이터셋·메트릭·LLM-as-judge 로 자동 측정 | Braintrust, Athina, Ragas, TruLens, DeepEval, Galileo, Patronus AI |

| **Prompt management** | 프롬프트의 버전 관리 / A·B 테스트 / 비기술자 협업 / 배포 | Vellum, PromptHub, LangSmith Prompts, Langfuse Prompts |

| **Gateway** | OpenAI / Anthropic / Bedrock 등 멀티 프로바이더 라우팅 · 캐싱 · rate limit · fallback | Portkey, LiteLLM, Cloudflare AI Gateway |

대부분의 도구는 영역을 겸한다. LangSmith 는 observability 도 하고 evaluation 도 하고 prompt 도 한다. Langfuse 도 동일하다. Portkey 는 gateway 가 본업이지만 observability 도 한다. 이게 비교를 어렵게 만드는 가장 큰 이유다.

2024 → 2026 의 변화

2024년 초까지만 해도 LangSmith 가 사실상 유일한 선택지였다. 그 뒤 2년 동안 무서운 속도로 시장이 분화됐다.

- **2023~2024년 1차 폭발** — Helicone (YC) · Langfuse · Braintrust · Athina · TruLens · Ragas 가 줄줄이 등장. LangChain 이 만든 LangSmith 가 GA.

- **2024년 후반** — Comet 이 LLM 쪽으로 본격 진입, Arize 는 Phoenix 를 오픈소스로 분리. Portkey 와 LiteLLM 이 gateway 로 자리잡음.

- **2025년 3월** — Comet 이 Opik 을 정식 오픈소스로 출시. Langfuse 가 Series A.

- **2025년 후반 ~ 2026년 초** — 클라우드 빅3가 본격 진입. Bedrock Evaluations · Vertex AI Evaluation Service · Azure AI Studio Evaluations. OpenAI 도 Evals 대시보드 강화.

- **2026년 현재** — 도구가 30개를 넘는다. "어떤 걸 써야 하나" 자체가 가장 큰 질문.

OpenTelemetry 의 등장 — GenAI semantic conventions

2025년 후반에 결정적인 변화가 있었다. OpenTelemetry 의 GenAI semantic conventions 가 사실상 표준이 됐고, Langfuse · Phoenix · Helicone · Portkey · LangSmith 가 모두 OTel 기반 SDK 를 제공하기 시작했다. 즉, **SDK 한 번 깔면 백엔드는 바꿔 끼울 수 있는** 시대가 됐다. 이게 향후 5년 LLM ops 의 가장 큰 변화다.

2장 · Helicone — Y Combinator 오픈소스 관찰성

먼저 가장 빠르게 시작할 수 있는 도구부터.

한 줄 정의

**Y Combinator W23 출신, 오픈소스 LLM 관찰성. base URL 한 줄 바꾸면 끝.** 가장 진입 장벽이 낮다.

어떻게 동작하는가

Helicone 의 가장 큰 특징은 **proxy 모드**다. OpenAI SDK 의 `base_url` 을 `https://oai.helicone.ai/v1` 로 바꾸기만 하면 모든 호출이 자동으로 기록된다. 코드 한 줄.

from openai import OpenAI

client = OpenAI(

base_url="https://oai.helicone.ai/v1",

default_headers={"Helicone-Auth": f"Bearer {os.getenv('HELICONE_API_KEY')}"},

)

이 한 줄로 다음이 자동 기록된다.

- 요청 / 응답 본문

- latency, time-to-first-token

- 입력·출력 토큰 수와 비용

- 사용자 ID·세션·custom property (Helicone-User-Id 같은 헤더로 전달)

proxy 가 부담스러우면 async logging SDK 도 있다. 비동기로 백그라운드에서 보낸다.

강점

- **진입 비용 0** — base URL 한 줄.

- **오픈소스** — Apache 2.0. self-host 가능.

- **제공자 무관** — OpenAI · Anthropic · Together · Anyscale · Bedrock 다 된다.

- **Custom property** — 사용자별·feature flag별·실험 그룹별로 슬라이스 가능.

- **무료 tier 가 관대** — 월 10만 요청까지 무료.

약점

- **proxy 가 critical path 에 들어간다** — latency 가 한 hop 추가된다 (실측 보통 10ms 이내).

- **evaluation 기능은 약하다** — LangSmith·Braintrust 만큼의 dataset / experiment 기능은 없다.

- **prompt 관리는 minimal** — Vellum·PromptHub 만큼 본격적이지 않다.

누가 쓰는가

스타트업·인디 개발자가 가장 많다. "지금 당장 production 트레이싱이 필요한데 코드 변경은 최소화" 시나리오에 압도적이다. 한국의 일부 LLM 스타트업이 PoC 단계에서 가장 먼저 까는 도구로 꼽힌다.

3장 · LangSmith — LangChain 의 깃발

가장 유명한 도구.

한 줄 정의

**LangChain 이 만든 일체형 LLM ops 플랫폼.** Observability · Evaluation · Prompts · Datasets 를 한 곳에서. SaaS 와 self-hosted (Enterprise) 둘 다.

어떻게 동작하는가

LangChain·LangGraph 를 쓰면 환경변수 두 개만 세팅하면 자동 트레이싱된다.

export LANGSMITH_TRACING=true

export LANGSMITH_API_KEY=ls_...

LangChain 을 안 써도 `@traceable` 데코레이터로 임의 함수를 트레이싱할 수 있다.

from langsmith import traceable

@traceable(run_type="llm")

def call_model(prompt: str) -> str:

임의의 모델 호출

...

강점

- **LangChain·LangGraph 통합이 압도적** — 다른 어떤 도구도 따라올 수 없다. agentic workflow 의 중간 단계 트레이싱이 자연스럽다.

- **Evaluation 이 강력** — dataset 만들기, LLM-as-judge, pairwise comparison, regression test 가 한 곳에서.

- **Prompts Hub** — 프롬프트 버전 관리·공유.

- **Production-grade** — Fortune 500 의 일부가 self-hosted 로 돌린다.

약점

- **비싸다** — 개인 무료, Plus 39달러/유저/월, Enterprise 는 별도 견적.

- **LangChain 가족 락인이 강하다** — 다른 도구로 옮기기 쉽지 않다.

- **UI 가 무겁다** — 작은 프로젝트에는 과하다.

누가 쓰는가

LangChain·LangGraph 를 production 에 쓰는 모든 팀의 기본값. 한국·일본의 RAG 챗봇 회사 중 LangChain 스택을 고른 곳은 거의 다 LangSmith 다.

4장 · Langfuse — 오픈소스, Series A

LangSmith 의 가장 강력한 오픈소스 대안.

한 줄 정의

**MIT 라이센스 오픈소스 LLM ops. self-host 가 진짜 쉽다.** 2025년 Series A 라운드를 받았고, 가장 빠르게 성장 중인 OSS 프로젝트 중 하나.

어떻게 동작하는가

`docker compose up` 한 번이면 self-hosted 인스턴스가 뜬다. SDK 는 Python · TypeScript · OpenAI 자동 트레이싱 · LlamaIndex · LangChain 모두 지원.

from langfuse.openai import openai # OpenAI 의 drop-in

response = openai.chat.completions.create(

model="gpt-4o",

messages=[{"role": "user", "content": "hi"}],

)

자동으로 trace 가 생성된다. 수동으로 span 을 만들 수도 있다.

강점

- **진짜 오픈소스** — MIT 라이센스, 코어 기능에 enterprise gating 거의 없다.

- **self-host 가 진심으로 쉽다** — docker compose 만으로 production-grade.

- **Observability + Evaluation + Prompts + Datasets** 가 한 패키지.

- **Prompt management 가 의외로 강력** — Langfuse Prompts 는 Vellum 의 가벼운 대안.

- **OpenTelemetry 호환** — 2025년부터 OTel GenAI 컨벤션 native 지원.

약점

- **UI 의 polish 가 LangSmith·Braintrust 보다 한 발 뒤** — 빠르게 따라잡고 있긴 함.

- **agentic workflow 의 시각화는 LangSmith 가 한 수 위.**

- **Cloud 버전은 EU 에 있어서** US 회사가 latency 신경 쓰면 self-host 권장.

누가 쓰는가

오픈소스를 선호하는 모든 팀. 한국의 일부 핀테크·헬스케어 회사가 데이터 주권 때문에 self-hosted Langfuse 를 고른다. 일본도 비슷하다.

5장 · W&B Weave — Weights & Biases 의 LLM 라인

ML 쪽에서 W&B 를 쓰던 팀이 자연스럽게 가는 도구.

한 줄 정의

**Weights & Biases 가 만든 LLM 관찰성·평가.** 기존 W&B 의 실험 추적과 통합된다.

어떻게 동작하는가

`weave.init("project")` 한 줄 후 `@weave.op` 데코레이터로 함수를 감싸면 자동 트레이싱.

weave.init("my-rag-app")

@weave.op()

def answer(query: str) -> str:

docs = retrieve(query)

return generate(query, docs)

W&B 의 기존 UI 안에서 LLM 트레이스가 보인다.

강점

- **W&B 의 ML 실험 추적과 같은 우산** — fine-tuning · evaluation · serving 을 한 곳에서.

- **Evaluations 가 강력** — `weave.Evaluation` 으로 dataset · scorer · 모델 조합을 빠르게 돌릴 수 있다.

- **엔터프라이즈 신뢰도** — W&B 의 기존 고객 (OpenAI · NVIDIA · Toyota) 이 그대로 쓴다.

약점

- **W&B 외부 사용자에겐 진입 곡선이 있다** — 기존 W&B 개념 (project · run) 을 알아야 한다.

- **무료 tier 는 LangSmith·Helicone 만큼 관대하지 않다.**

- **pure LLM-only 팀에는 과한 면이 있다** — ML 도 같이 하면 베스트.

누가 쓰는가

이미 W&B 를 쓰던 ML 팀. 한국·일본의 대기업 AI 랩 중 자체 모델 학습을 하는 곳이 많이 쓴다.

6장 · Arize Phoenix — 오픈소스

ML 관찰성의 명가 Arize 가 만든 오픈소스 LLM 도구.

한 줄 정의

**Arize AI 가 만든 오픈소스 LLM observability + evaluation.** 노트북에서 시작해서 production 까지 같은 도구로.

어떻게 동작하는가

from phoenix.otel import register

tracer_provider = register(project_name="my-rag", auto_instrument=True)

이제 OpenAI · LangChain · LlamaIndex 호출이 전부 자동 트레이싱

Phoenix 의 강점은 **노트북에서 바로 띄울 수 있다**는 점이다. `px.launch_app()` 하면 로컬에서 UI 가 뜬다.

강점

- **노트북 친화적** — 실험 단계에서 가장 가볍게 시작.

- **OpenTelemetry GenAI 컨벤션 native.**

- **Embedding·RAG 시각화가 강력** — UMAP 으로 임베딩 군집을 시각화하는 기능은 다른 곳에서 보기 어렵다.

- **Arize 의 production tier 와 자연스럽게 연결** — POC 는 Phoenix, production 은 Arize.

약점

- **UI 가 LangSmith·Braintrust 보다 ML 쪽 정서가 강하다** — 일반 백엔드 개발자에겐 진입 장벽.

- **prompt management 는 기본적.**

누가 쓰는가

데이터 사이언티스트 출신 ML 엔지니어. RAG 디버깅 (어떤 chunk 가 잘못 retrieve 되었는지 시각화) 이 필요한 팀.

7장 · Braintrust — Evaluation 특화

평가가 가장 중요한 팀이라면 1순위 후보.

한 줄 정의

**Eval 이 최우선인 LLM ops 플랫폼.** Stripe · Notion · Vercel 같은 회사가 쓴다. 2024년 큰 라운드를 받았다.

어떻게 동작하는가

Braintrust 의 핵심 추상은 **Eval**. dataset · task · scorer 의 조합으로 실험을 돌린다.

Eval("MyRagApp", {

data: () => [

{ input: "What is the capital of France?", expected: "Paris" },

],

task: async (input) => myRagPipeline(input),

scores: [Factuality, AnswerRelevancy],

});

`braintrust eval` 로 돌리면 score 가 시간 축으로 누적되고, 모델·프롬프트 변경의 영향을 즉시 비교할 수 있다.

강점

- **Eval-first 사고방식** — "프롬프트는 코드다. 코드에는 테스트가 있어야 한다" 를 가장 잘 구현.

- **Playground 가 정말 좋다** — 프롬프트 / 모델 / 데이터셋 을 빠르게 비교.

- **Loop (LLM-as-judge 자동 튜닝)** — judge 자체의 calibration 을 자동화.

- **TypeScript / Python SDK 가 모두 일급.**

약점

- **유료 우선** — 무료 tier 가 있긴 하지만 본격적인 사용은 유료가 필요.

- **observability 만 원하는 팀에는 약간 과하다.**

누가 쓰는가

Stripe · Notion · Vercel · Airtable 같은 미국 product 회사. "프롬프트를 PR 단위로 자동 평가하지 않으면 production 에 못 나간다" 가 문화로 박힌 팀.

8장 · Athina — 빠르게 성장

평가·관찰성·dataset 을 한 패키지로 묶은 빠른 성장주.

한 줄 정의

**대시보드가 깔끔하고 50개 이상의 사전 정의 evaluator 가 들어 있는 LLM ops.** 진입이 쉽다.

어떻게 동작하는가

from athina.loaders import Loader

from athina.evals import Faithfulness

data = Loader().load_csv("eval_data.csv")

Faithfulness(model="gpt-4o").run_batch(data=data).to_df()

또는 SDK 로 production 트레이스를 보내고 대시보드에서 evaluator 를 자동 실행하게 할 수 있다.

강점

- **사전 정의 evaluator 가 많다** — Faithfulness · Context Precision · Toxicity · PII Detection 등.

- **non-engineer 친화적 대시보드** — PM 이 직접 들어와서 데이터셋·라벨을 만들 수 있다.

- **YAML configuration** — 평가 파이프라인을 YAML 로 선언.

약점

- **OSS 기여는 일부에 한정** — 핵심은 SaaS.

- **agentic workflow 의 깊은 트레이싱은 LangSmith 가 우위.**

누가 쓰는가

product 팀과 eng 팀이 같이 LLM 품질을 관리하는 mid-size 스타트업. 영어권에서 빠르게 점유율을 늘리고 있다.

9장 · Comet Opik (2025년 3월 출시) — 오픈소스

가장 새로 등장한 오픈소스 도구.

한 줄 정의

**Comet ML 이 2025년 3월 출시한 오픈소스 LLM observability + evaluation.** Apache 2.0.

어떻게 동작하는가

from opik import track

opik.configure(use_local=True)

@track

def answer(query: str) -> str:

return llm_call(query)

`use_local=True` 면 self-host 인스턴스에 보낸다. Comet cloud 로도 보낼 수 있다.

강점

- **2025년 출시라 가장 최신의 UX 패턴이 들어가 있다** — 늦게 나온 만큼 다른 도구의 좋은 점을 흡수.

- **Comet 의 ML 실험 추적과 같은 우산** — W&B Weave 와 비슷한 포지셔닝.

- **무료 SaaS tier 가 관대.**

- **Apache 2.0** — 진짜 오픈소스.

약점

- **생태계가 아직 가장 작다** — 후발주자.

- **plugin / integration 수가 Langfuse · LangSmith 보다 적다.**

누가 쓰는가

Comet 의 기존 ML 고객, 그리고 "최신·오픈소스·빠른 시작" 셋을 모두 원하는 신규 프로젝트.

10장 · Vellum / PromptHub — 프롬프트 관리 본격파

프롬프트를 코드에서 분리하는 것이 본업.

Vellum — 엔터프라이즈 프롬프트 관리

**프롬프트의 GitHub.** 버전 · 환경 · 배포 · A/B 테스트 · 데이터셋이 한 곳에 들어 있다. PM·CS·QA 가 프롬프트를 직접 만지는 워크플로우에 최적화.

- 프롬프트의 git-style diff 와 PR 리뷰.

- workflow editor (시각적 chain 빌더).

- production 트래픽의 일정 비율로 새 프롬프트 canary.

- 대기업 고객 다수 (헬스케어·법률 도메인).

PromptHub — 라이트한 협업

**Vellum 보다 가볍고 가격이 싸다.** 작은 팀이 프롬프트를 git 처럼 관리하고 싶을 때.

- 프롬프트 라이브러리 (공유 / 검색).

- A/B 테스트.

- 다국적 모델 비교 (같은 프롬프트를 OpenAI · Anthropic · Bedrock 에 동시 호출).

언제 별도 prompt 도구가 필요한가

대부분의 작은 팀은 LangSmith · Langfuse 의 내장 prompt 기능으로 충분하다. 다음 시점에서 별도 도구가 필요해진다.

- 프롬프트를 **비기술자가 직접 편집**해야 한다 (PM · CS 가 매주 프롬프트를 튜닝).

- 환경별 (dev · staging · prod) **승격 워크플로우** 가 git 만으로는 부족하다.

- **여러 모델에 같은 프롬프트** 를 띄우고 결과를 나란히 비교한다.

이 셋이 모두 해당하면 Vellum, 한두 개면 PromptHub, 다 안 해당하면 LangSmith·Langfuse 내장 기능.

11장 · Portkey — AI Gateway + 관찰성

게이트웨이 영역의 대표주자.

한 줄 정의

**OpenAI / Anthropic / Bedrock / Google / Azure / Together / 200개 프로바이더 를 통합하는 AI gateway.** 관찰성 · 캐싱 · fallback · rate limit · cost guard 가 다 들어 있다.

어떻게 동작하는가

OpenAI SDK 의 `base_url` 을 Portkey 로 바꾼 뒤 헤더로 라우팅 규칙을 전달.

from openai import OpenAI

client = OpenAI(

base_url="https://api.portkey.ai/v1",

default_headers={

"x-portkey-api-key": os.getenv("PORTKEY_API_KEY"),

"x-portkey-config": "your-config-id", # 라우팅·캐싱·재시도 규칙

},

)

config 안에서 "primary 는 GPT-4o, 실패 시 Claude Sonnet 4.5 로 fallback, 같은 입력은 1시간 캐시" 같은 정책을 선언적으로 정의.

강점

- **멀티 프로바이더 통합** — 200개 이상.

- **fallback / load balancing / canary** 가 native.

- **semantic cache** — 같은 의미의 질문은 캐시 hit.

- **observability 가 따라온다** — 별도 도구 없이도 트레이싱.

- **prompt management 도 내장.**

약점

- **gateway 가 critical path 에 들어간다** — proxy 의 본질적 약점. 자체 region 을 못 골라서 latency 가 더해지는 경우 있다.

- **Helicone·Langfuse 만큼의 observability 깊이는 아니다** — 충분하지만 specialist 만큼은 아님.

LiteLLM 과의 비교

LiteLLM (오픈소스 SDK / proxy) 이 비슷한 영역. 차이는:

- **LiteLLM** — Python 라이브러리로 시작했고, self-host gateway 도 있다. 100% 오픈소스 코어. 더 가볍고 더 hackable.

- **Portkey** — SaaS 우선. UI · 정책 관리 · 협업이 우선. self-host enterprise tier 있다.

스타트업 / 인디는 LiteLLM 이 흔하고, mid-size 이상은 Portkey 가 흔하다.

12장 · TruLens / Ragas — RAG 평가 양대 산맥

RAG 가 들어간 시스템이면 거의 무조건 둘 중 하나.

Ragas — RAG 평가 메트릭의 사실상 표준

**오픈소스. RAG 의 표준 메트릭을 라이브러리로.** 가장 많이 인용되는 RAG 평가 framework.

- **Faithfulness** — 답이 retrieved context 에 실제로 근거하는가?

- **Answer Relevancy** — 답이 질문에 실제로 답하는가?

- **Context Precision / Recall** — retrieval 이 정확한가?

- **Context Entity Recall** — 정답 entity 가 context 에 들어 있는가?

from ragas import evaluate

from ragas.metrics import faithfulness, answer_relevancy, context_precision

result = evaluate(

dataset=eval_dataset,

metrics=[faithfulness, answer_relevancy, context_precision],

)

print(result)

LangSmith · Langfuse · Athina 등 거의 모든 observability 도구가 Ragas 메트릭을 내장 evaluator 로 제공한다.

TruLens — 더 넓은 평가 + 트레이싱

**TruEra (현 Snowflake) 의 오픈소스.** Ragas 가 메트릭 라이브러리라면 TruLens 는 메트릭 + 트레이싱 + 대시보드를 함께 제공.

- **The RAG Triad** — Context Relevance · Groundedness · Answer Relevance.

- 트레이싱 + 평가가 한 도구.

- 노트북 친화적.

Ragas vs TruLens 선택 기준

- 다른 observability 도구 (LangSmith · Langfuse · Athina) 를 이미 쓰고 있고 메트릭만 필요하면 → **Ragas.**

- observability 도구 없이 RAG 평가 자체만 빠르게 돌리고 싶으면 → **TruLens.**

- 둘 다 같이 쓰는 경우도 흔하다 — Ragas 메트릭을 TruLens 안에서 호출.

13장 · Galileo / Patronus AI / DeepEval — 엔터프라이즈 eval

규제·보안·SLA 가 중요한 조직을 위한 영역.

Galileo — Generative AI Studio

**production-grade hallucination · safety · drift 모니터링.** Fortune 500 · 정부 · 금융 영역.

- **Galileo Evaluate** — pre-production 평가.

- **Galileo Observe** — production 트레이싱·모니터링.

- **Galileo Protect** — real-time guardrail (PII · jailbreak · hallucination 차단).

Patronus AI — 자동 평가 + 안전성

**오토메이션된 LLM 평가에 특화.** Lynx (hallucination detector), Glider, FinanceBench 같은 자체 평가 모델을 제공.

- 사용자 정의 evaluator 를 plain English 로 작성 가능.

- 금융·법률 도메인 벤치마크가 자체 구축돼 있다.

DeepEval (Confident AI) — pytest 스타일의 LLM 테스트

**LLM 의 pytest.** 개발자가 가장 친숙한 API.

from deepeval import assert_test

from deepeval.test_case import LLMTestCase

from deepeval.metrics import AnswerRelevancyMetric

def test_answer_relevancy():

test_case = LLMTestCase(

input="What is the capital of France?",

actual_output="The capital is Paris.",

)

metric = AnswerRelevancyMetric(threshold=0.7)

assert_test(test_case, [metric])

CI 에서 `pytest` 처럼 돌릴 수 있고, Confident AI 라는 SaaS 대시보드가 결과를 누적해서 보여준다.

셋의 선택 기준

- **금융·법률 도메인 + 자체 벤치마크 필요** → Patronus AI.

- **production guardrail 까지 한 패키지** → Galileo.

- **개발자가 unit test 처럼 LLM 을 테스트하고 싶다** → DeepEval.

14장 · 클라우드 native — Bedrock Evals / Vertex AI Evaluation / OpenAI Evals

2025년 후반부터 클라우드 빅3가 본격 진입했다.

AWS Bedrock Evaluations

**Bedrock 안에서 모델·prompt·RAG 를 평가하는 managed 서비스.**

- **Model Evaluation** — 동일 데이터셋으로 여러 Bedrock 모델 비교.

- **RAG Evaluation** — Bedrock Knowledge Base 와 통합. retrieval + generation 을 동시에 평가.

- **LLM-as-judge** + 사람 평가 (Amazon Mechanical Turk 통합) 둘 다 지원.

- **Bedrock Guardrails** 와 결합하면 evaluation → guardrail 정책으로 자동 반영.

이미 AWS 에 베팅한 팀의 기본 선택지가 된다.

Vertex AI Evaluation Service (Google)

**Gen AI Eval Service.** Vertex AI 안에서 Gemini · 3P 모델 평가.

- pointwise · pairwise · rubric 기반 메트릭.

- Autoraters (LLM-as-judge) + 사용자 정의 메트릭.

- Vertex AI Pipelines 와 통합 — eval 을 CI 단계로 자동 실행.

Gemini · PaLM 을 production 에서 쓰는 회사의 기본값.

OpenAI Evals (대시보드)

**OpenAI Platform 의 Evals 탭.** 2024년부터 OSS 로 풀린 `openai/evals` 가 SaaS 대시보드로 통합됐다.

- Stored Completions 기반 평가 — production traffic 의 일부를 자동으로 평가 데이터셋으로 전환.

- model graded eval 이 기본.

- OpenAI Fine-tuning · Distillation 과 자연스럽게 연결.

Azure AI Studio Evaluations

Azure OpenAI 의 평가 기능. PromptFlow 와 통합. Azure 에 베팅한 엔터프라이즈의 기본값.

클라우드 native 의 장단

- **장점** — 데이터가 같은 클라우드 안에 머무름 (compliance · 보안), IAM·VPC·로깅과 자연스럽게 통합, 별도 SaaS 계약 불필요.

- **단점** — 멀티 클라우드 · 멀티 모델 비교가 어렵다 (Bedrock Evals 에서 OpenAI 모델은 평가 못 함), 도구가 specialist 만큼 깊지 않다, vendor lock-in 위험.

15장 · 한국 / 일본 — 토스 · NAVER · Sakana · NTT Tsuzumi

해외 도구만이 아니다. 한·일의 자체 LLM ops 도 빠르게 자라고 있다.

한국

- **토스 (Toss) — LLM ops 자체 구축**

- 자체 LLM 게이트웨이 (PortkeyLite 격), 자체 prompt 레지스트리, Langfuse 를 self-host 하여 트레이싱.

- 금융 규제 (망분리) 때문에 SaaS LLM ops 도구를 거의 못 쓰고, 오픈소스를 폐쇄망에 self-host 하는 패턴이 사실상 표준.

- 사내 RAG 챗봇 (인사·법무·고객 응대) 의 품질 측정을 위해 Ragas 메트릭을 내부 라이브러리로 wrapping.

- **NAVER HCX 모니터링**

- HyperCLOVA X (HCX) 자체 모델을 운영하는 NAVER 는 자체 모니터링 스택. 사내 NSML / CLOVA Studio 와 통합.

- 사내 BizPlatform / CLOVA for Biz 고객에게 prompt management · evaluation 을 통합 제공.

- **카카오 / 쿠팡 / 라인** — 모두 자체 + 오픈소스 (Langfuse / Phoenix) 의 하이브리드.

- **국내 LLM 스타트업** — 업스테이지·뤼튼·딥엘 등은 LangSmith / Langfuse / Helicone 을 상황에 따라 혼용.

일본

- **Sakana AI — 자체 모델 + 운영**

- 자체 모델 (EvoLLM · evo-ukiyoe 등) 의 학습과 평가에 W&B · MLflow 를 같이 쓰고, production observability 는 Langfuse 또는 자체 도구.

- **NTT Tsuzumi — 통신사 운영의 표준**

- NTT 의 자체 LLM. 통신사 컴플라이언스 때문에 자체 모니터링 스택 + 오픈소스 ragas / langfuse 의 하이브리드.

- **Mercari · CyberAgent · LINE Yahoo** — LangSmith 또는 Langfuse self-host. CyberAgent 는 자체 학습 모델이 많아 W&B 비중이 높다.

- **메가뱅크 (MUFG · SMBC · Mizuho)** — 외부 SaaS 사용이 어렵다. AWS Bedrock + Bedrock Evals 또는 Azure OpenAI + Azure AI Studio 가 사실상의 표준.

한·일 공통 패턴

- 금융·통신·공공 영역은 SaaS LLM ops 도구를 직접 못 쓰고 오픈소스 (Langfuse · Phoenix · Opik · Helicone) 의 self-host 가 사실상의 표준이다.

- B2C 스타트업은 LangSmith · Helicone · Langfuse SaaS 를 그대로 쓴다.

- **데이터 주권 (data residency)** 이 점점 큰 의사결정 요인이 되고 있다 — 일본은 도쿄 region, 한국은 서울 region 이 가능한가가 거의 첫 질문.

16장 · 누가 무엇을 골라야 하나 — 4 페르소나

마지막으로 의사결정 가이드.

페르소나 1 · 1인 개발자 / 인디 hack

**조건** — 혼자 사이드 프로젝트로 LLM 앱을 만든다. 비용은 최소.

- **Observability** — Helicone (free tier 가 가장 관대) 또는 Langfuse Cloud (무료 tier 50k 트레이스/월).

- **Evaluation** — 필요할 때만 Ragas 라이브러리 직접.

- **Prompt management** — 코드 안에 docstring 으로 충분. LangSmith Prompts 는 무료.

- **Gateway** — LiteLLM (Python 라이브러리만, 무료).

페르소나 2 · Seed/Series A 스타트업 (5~50명)

**조건** — production 트래픽 있음. 빠른 iteration. 비용도 신경 씀.

- **Observability** — Langfuse SaaS (오픈소스, 합리적 가격) 또는 LangSmith Plus.

- **Evaluation** — Braintrust (eval-first 문화 강조) 또는 Athina (PM 도 같이 쓰기 좋은 UI).

- **Prompt management** — LangSmith Prompts / Langfuse Prompts 내장으로 시작.

- **Gateway** — Portkey 또는 LiteLLM. fallback / 캐싱이 중요해지면.

- **RAG eval** — Ragas 메트릭을 위 도구의 evaluator 로 등록.

페르소나 3 · Series B+ / 엔터프라이즈

**조건** — 규모가 크다. compliance · SOC2 · ISO 27001 필요. SLA 가 곧 매출.

- **Observability** — LangSmith Enterprise 또는 Langfuse self-hosted (데이터 주권), Galileo (production guardrail 까지).

- **Evaluation** — Braintrust Enterprise + Patronus AI (도메인 특화).

- **Prompt management** — Vellum (PM · CS · QA 가 같이 만지는 워크플로우).

- **Gateway** — Portkey Enterprise self-host 또는 자체 게이트웨이.

- **Cloud-native** — AWS 면 Bedrock Evals 추가, GCP 면 Vertex AI Evaluation 추가.

페르소나 4 · RAG 우선 조직

**조건** — RAG 가 product 의 핵심. retrieval 의 품질이 사업의 품질.

- **Observability** — Arize Phoenix (embedding 시각화) 또는 Langfuse.

- **Evaluation** — Ragas 메트릭 + TruLens 의 RAG Triad 를 둘 다 돌리고, Braintrust 에서 dataset · experiment 관리.

- **Prompt management** — Vellum 의 workflow editor 가 multi-step RAG chain 에 적합.

- **Gateway** — Portkey 의 semantic cache 가 RAG 비용 절감에 결정적.

의사결정의 핵심 질문 다섯

도구를 고르기 전 자기 자신에게 물어봐야 하는 다섯 가지.

1. **데이터 주권** — 우리 데이터가 어느 region 에 머물러야 하는가? (한국 / 일본 / EU / US?)

2. **오픈소스 vs SaaS** — self-host 운영 인력이 있는가?

3. **agentic workflow 가 있는가?** — 있으면 LangSmith · Langfuse 가 우위, 없으면 Helicone · Athina 도 충분.

4. **PM · CS 가 프롬프트를 직접 만지는가?** — 그렇다면 Vellum 또는 LangSmith Prompts 의 UI 가 결정적.

5. **CI 에서 자동으로 LLM 회귀 테스트를 돌리는가?** — 그렇다면 Braintrust · DeepEval 이 우위.

17장 · 마치며 — "LLM 을 운영하는 것" 은 이제 단어가 있다

2024년에는 "LLM 운영" 이라는 단어 자체가 어색했다. 2026년 5월 현재, LLM ops 는 어엿한 SRE 의 한 갈래가 됐다. 30개가 넘는 도구가 경쟁하고, OpenTelemetry GenAI 컨벤션이 표준으로 자리잡았고, 클라우드 빅3가 자체 평가 서비스를 내놓았다.

이 글을 시작하면서 던진 다섯 가지 질문 — 왜 이상한 답이 나오는가, 어떻게 재현할 것인가, 누가 토큰을 썼는가, 어떤 테스트가 깨졌는가, 자동으로 품질을 측정할 수 있는가 — 에 대한 답은 이제 도구가 줄 수 있다. 문제는 어떤 도구를 골라야 하느냐다.

- 빠르게 시작하고 싶으면 **Helicone**.

- LangChain 가족이면 **LangSmith**.

- 오픈소스·self-host 가 필수면 **Langfuse** 또는 **Phoenix** 또는 **Opik**.

- eval 이 핵심이면 **Braintrust** + **Ragas**.

- 멀티 프로바이더 트래픽 관리가 필요하면 **Portkey** 또는 **LiteLLM**.

- 엔터프라이즈 guardrail 까지면 **Galileo** + **Patronus**.

- 클라우드 native 면 **Bedrock Evals** / **Vertex AI Evaluation**.

도구를 안 쓸 이유는 더 이상 없다. "프롬프트는 코드다. 코드에는 모니터링과 테스트가 있어야 한다." 이게 2026년의 새 상식이다. 다음 모델 (GPT-5.5 · Claude Opus 5 · Gemini 3 Ultra · Llama 5) 이 와도 이 인프라는 그대로 쓸 수 있다. 모델은 바뀌어도 운영의 원칙은 안 바뀐다.

참고 / References

Observability — 일체형

- Helicone — [https://www.helicone.ai/](https://www.helicone.ai/)

- LangSmith — [https://www.langchain.com/langsmith](https://www.langchain.com/langsmith)

- Langfuse — [https://langfuse.com/](https://langfuse.com/)

- W&B Weave — [https://wandb.ai/site/weave](https://wandb.ai/site/weave)

- Arize Phoenix — [https://phoenix.arize.com/](https://phoenix.arize.com/)

- Comet Opik — [https://www.comet.com/site/products/opik/](https://www.comet.com/site/products/opik/)

Evaluation 특화

- Braintrust — [https://www.braintrust.dev/](https://www.braintrust.dev/)

- Athina — [https://athina.ai/](https://athina.ai/)

- Ragas — [https://docs.ragas.io/](https://docs.ragas.io/)

- TruLens — [https://www.trulens.org/](https://www.trulens.org/)

- DeepEval (Confident AI) — [https://docs.confident-ai.com/](https://docs.confident-ai.com/)

- Galileo — [https://www.galileo.ai/](https://www.galileo.ai/)

- Patronus AI — [https://www.patronus.ai/](https://www.patronus.ai/)

Prompt management

- Vellum — [https://www.vellum.ai/](https://www.vellum.ai/)

- PromptHub — [https://www.prompthub.us/](https://www.prompthub.us/)

- LangChain Studio — [https://www.langchain.com/langgraph-studio](https://www.langchain.com/langgraph-studio)

Gateway

- Portkey — [https://portkey.ai/](https://portkey.ai/)

- LiteLLM — [https://www.litellm.ai/](https://www.litellm.ai/)

- Cloudflare AI Gateway — [https://developers.cloudflare.com/ai-gateway/](https://developers.cloudflare.com/ai-gateway/)

Cloud-native eval

- AWS Bedrock Evaluations — [https://docs.aws.amazon.com/bedrock/latest/userguide/model-evaluation.html](https://docs.aws.amazon.com/bedrock/latest/userguide/model-evaluation.html)

- Vertex AI Generative AI Evaluation Service — [https://cloud.google.com/vertex-ai/generative-ai/docs/models/evaluation-overview](https://cloud.google.com/vertex-ai/generative-ai/docs/models/evaluation-overview)

- OpenAI Evals (open source) — [https://github.com/openai/evals](https://github.com/openai/evals)

- Azure AI Studio Evaluations — [https://learn.microsoft.com/en-us/azure/ai-studio/concepts/evaluation-approach-gen-ai](https://learn.microsoft.com/en-us/azure/ai-studio/concepts/evaluation-approach-gen-ai)

표준 / spec

- OpenTelemetry GenAI semantic conventions — [https://opentelemetry.io/docs/specs/semconv/gen-ai/](https://opentelemetry.io/docs/specs/semconv/gen-ai/)

한국·일본

- 토스 기술 블로그 — [https://toss.tech/](https://toss.tech/)

- NAVER HyperCLOVA X — [https://clova.ai/hyperclova](https://clova.ai/hyperclova)

- Sakana AI — [https://sakana.ai/](https://sakana.ai/)

- NTT Tsuzumi — [https://www.rd.ntt/e/research/JN20231101_h.html](https://www.rd.ntt/e/research/JN20231101_h.html)

- CyberAgent AI Lab — [https://research.cyberagent.ai/](https://research.cyberagent.ai/)