한 대형 보험사의 리스크 팀은 이미 Fiddler를 사용하고 있습니다. 수년 동안 모델 리스크 거버넌스 (model-risk governance)가 요구하는 감사 산출물 (audit artifacts)과 함께 수십 개의 예측 모델 (predictive models)을 드리프트 모니터링 (drift monitoring) 하에 운영해 왔습니다. 그러다 같은 조직에서 에이전트 (agents)를 배포하기 시작했습니다. 보험금 분류 워크플로우, 문서 요약 파이프라인, 그리고 400명의 엔지니어에게 배포된 코딩 어시스턴트 등이 그 예입니다. Fiddler의 대응은 일관적입니다. 이미 보유하고 있던 플랫폼을 확장했기 때문입니다. 이제 동일한 콘솔에서 애플리케이션 (application), 세션 (session), 에이전트 (agent), 트레이스 (trace), 스팬 (span)을 모두 다룹니다. 환각 (Hallucination), 독성 (toxicity), PII/PHI (개인 식별 정보/개인 건강 정보), 그리고 탈옥 (jailbreak) 시도 등이 고객의 자체 환경 내에서 실행되는 모델에 의해 실시간으로 점수화됩니다. 하나의 벤더, 하나의 거버넌스 우산 아래에서 예측 모델 (predictive)과 에이전트 모델 (agentic)이 나란히 운영됩니다.

반면, 10명 규모의 스타트업에 근무하는 한 플랫폼 엔지니어가 동일한 질문—지난 분기에 배포한 3개의 에이전트를 어떻게 거버넌스 (govern) 할 것인가?—을 던졌을 때, Fiddler의 가격 페이지의 모든 단계(Free라고 표시된 단계 포함)가 "데모 요청 (Request demo)"으로 끝난다는 사실을 발견합니다.

이 두 가지 상황은 그 어떤 기능 목록보다 이 비교의 축을 더 잘 설명해 줍니다. Fiddler는 엔터프라이즈 관측성 (enterprise observability) 및 보안 플랫폼으로서, 신뢰할 수 있는 위치 선정과 자금 지원을 바탕으로 AI 제어 평면 (AI control plane)으로 재포지셔닝했습니다. Waxell은 모니터링을 통해 제어 평면에 도달하는 방식이 아니라, 집행 계층 (enforcement layer)에서 시작하는 제어 평면이며, 단일 팀이 영업 상담 없이도 바로 활성화할 수 있는 플랫폼입니다.

Fiddler AI는 엔터프라이즈 AI 관측성 (Observability) 및 보안 플랫폼으로, 원래 예측형 ML 모델 모니터링을 위해 구축되었으나 현재는 "AI 에이전트를 위한 제어 평면 (control plane)"으로 자리매김하고 있습니다. 이 플랫폼은 애플리케이션에서 스팬 (span)에 이르기까지 계층적 가시성을 제공하며, 고객의 환경에서 실행되는 전용 Centor Models를 사용하여 에이전트의 입력과 출력을 실시간으로 점수화합니다. 또한, 2026년 4월 Lumeus를 인수한 이후, 코딩 에이전트가 작동하는 코드 생성 계층 (code-generation layer)으로 정책 집행 (policy enforcement) 범위를 역방향으로 확장하고 있습니다. Waxell은 집행 우선 (enforcement-first) 방식으로 구축된 AI 제어 평면 (AI control plane)입니다. Observe는 단 두 줄의 코드로 에이전트를 계측 (instrument)하고 다음 단계가 실행되기 전에 50개 이상의 정책 카테고리에 따라 모든 실행을 평가하며, MCP Gateway는 160개 이상의 업스트림 커넥터 전반에서 진행 중인 도구 호출 (tool calls)을 관리하고, Runtime은 중대한 워크플로 (high-stakes workflows)의 각 단계를 통제합니다. Fiddler는 에이전트가 무엇을 했고 그것이 얼마나 위험해 보였는지를 매우 정밀하게 알려줍니다. Waxell은 그것이 실행될지 여부를 결정합니다.

Fiddler AI는 무엇을 위해 구축되었는가?

Fiddler는 에이전트 중심의 흐름 (agentic wave)이 몰려오기 수년 전부터 존재해 왔으며, 그 역사는 낡은 유산이라기보다 진정한 자산입니다. Fiddler는 전통적인 예측 모델 모니터링 (predictive model monitoring)과 에이전트 관측성 (agentic observability)을 한 지붕 아래에 둘 수 있는 소수의 벤더 중 하나입니다. 이는 보험사나 은행이 신용 점수 모델과 LLM 에이전트를 모두 관리해야 하며, 두 개의 거버넌스 프로그램을 운영하고 싶어 하지 않는 규제 산업 분야에서 매우 중요합니다.

가시성 모델은 트레이스 단위(trace-by-trace)가 아닌 계층적(hierarchical)입니다. Fiddler 스스로도 이 점을 명확히 정의하고 있습니다. Fiddler는 자사를 "시스템 전반의 통찰력을 드러내는 풍부하고 문맥을 인식하는 성능 경험"이라고 설명하며, 명시적으로 "한 번에 하나의 트레이스만 디버깅하는 경험이 아님"을 강조합니다. 실제로 이는 세션(session), 에이전트(agent), 트레이스(trace), 스팬(span)으로 이어지는 집계 대시보드(aggregate dashboards)를 의미하며, 주변 문맥과 함께 실패한 스팬을 정확히 찾아내는 계층적 근본 원인 분석(root-cause analysis), 그리고 멀티 에이전트 시스템(multi-agent systems)의 병목 현상을 드러내기 위한 에이전트 간 의존성 매핑(cross-agent dependency mapping)을 포함합니다.

점수 산정 아키텍처(scoring architecture)는 가장 강력한 기술적 차별점입니다. Fiddler의 Trust Service는 이전의 Trust Models라 불리던, 목적에 맞게 구축된 Centor Models를 고객의 환경 내부에서 완전히 실행합니다. 제3자 LLM 판사(LLM judge)로의 외부 API 호출이 없으므로, 프로덕션 규모에서 눈에 보이지 않게 쌓이는 체크당 비용이 발생하지 않으며, 80ms 미만의 지연 시간(latency)을 주장합니다. 자체 평가기를 원하는 팀은 자신들만의 판사(judge)를 가져와 사용할 수도 있습니다. 이는 실제 비용 문제에 대한 진정한 해답이며, 프런티어 모델(frontier model)을 가드레일 SDK로 감싸는 것보다 아키텍처 측면에서 훨씬 더 진지한 접근 방식입니다.

라이프사이클(lifecycle)은 진정으로 엔드 투 엔드(end-to-end)이며, 점점 더 확장되고 있습니다. 골든 데이터셋(golden datasets) 및 챌린저 데이터셋(challenger datasets)을 활용한 개발 단계의 평가, 프롬프트 실험, 엣지 케이스(edge-case) 스트레스 테스트는 프로덕션 모니터링으로 이어지며, 이는 다시 다음 반복(iteration) 단계로 피드백됩니다. 2026년 4월, Fiddler는 코딩 에이전트가 작동하는 IDE, CLI, MCP 경계까지 제어 평면(control plane)을 확장하기 위해 특별히 Lumeus를 인수했습니다. 이는 리스크가 집중되는 지점에 대한 날카로운 통찰입니다. 프레임워크 지원은 OpenTelemetry를 기반으로 하며 LangGraph, Amazon Bedrock, AWS Strands Agents, Google ADK에 대한 네이티브 통합을 제공합니다.

Fiddler는 2026년 1월 RPS Ventures가 주도한 3,000만 달러 규모의 시리즈 C(Series C) 투자를 유치하며 총 누적 투자액 1억 달러를 달성했습니다. 이는 명확한 논거를 실행하고 있는 자본력이 탄탄한 기업입니다.

Fiddler의 범위는 어디까지인가?

아래의 한계점들은 모니터링에 뿌리를 둔 플랫폼의 경계이지, 결함이 아닙니다.

강제 메커니즘(enforcement mechanism)은 공개적으로 명시되어 있지 않습니다. Fiddler의 홍보 문구는 "운영을 보호하기 위해 런타임 가드레일(runtime guardrails)을 강제함", "유해한 노출을 탐지하기 위한 실시간 가드레일(real-time guardrails)"과 같은 강제성 있는 언어를 사용하며, Centor Models는 "실시간 모니터링 및 가드레일을 가능하게 함"이라고 설명됩니다. 이는 단순한 대시보드보다는 강력한 표현입니다. 하지만 Fiddler의 공개 제품 페이지에는 일부 경쟁사들이 명시적으로 밝히는 방식처럼, 가드레일이 에이전트의 다음 동작을 동기식으로 차단(synchronously block)하는지, 아니면 점수를 매기고 경고를 위해 플래그(flag)를 지정하는지에 대해 명시되어 있지 않습니다. 에이전트 관측성(agentic-observability) 페이지에 사용된 동사들은 압도적으로 평가(evaluate), 모니터링(monitor), 분석(analyze), 개선(improve), 탐지(detect), _경고(alert)_에 집중되어 있습니다. 특정 도구 호출(tool call)에 대해 문서화된 강력한 실행 전 차단(pre-execution block) 기능이 필요한 팀은 마케팅 문구에서 이를 추론하기보다 Fiddler 측에 직접 메커니즘을 확인해야 합니다. 이는 Waxell의 자체 경쟁사 조사에서 확인이 필요하다고 지적되었던 공백이며, Fiddler의 공개 페이지를 직접 검토했을 때도 해소되지 않았습니다.

코딩 에이전트 제어(Coding-agent control)는 출시된 기능이 아니라 디자인 파트너 프로그램입니다. Lumeus 기반의 "코딩 에이전트를 위한 제어 평면(Control Plane for Coding Agents)"은 "GA(General Availability) 전... 조기 액세스를 위한" 디자인 파트너를 명시적으로 모집하고 있습니다. 이는 진지한 인수 합병을 배경으로 발표된 신뢰할 수 있는 로드맵이지만, 현재 검토 중인 팀이 평가하고 있는 것은 제품이 아니라 초대장입니다.

MCP 지원은 거버넌스(governance)가 아닌 연결성(connectivity)이며, 현재 프라이빗 프리뷰(private preview) 상태입니다. Fiddler의 MCP 서버는 Fiddler 자체의 관측성 데이터를 MCP 호환 어시스턴트에 노출하여, 엔지니어가 Cursor나 Claude Code 내부에서 트레이스(traces)를 조사할 수 있게 합니다. Fiddler의 문서는 이를 "프라이빗 프리뷰(Private Preview) — 선택된 디자인 파트너에게만 제공됨"으로 분류하고 있으며, SLA(Service Level Agreement)나 SLO(Service Level Objective)가 없고 통지 없이 변경될 수 있는 API를 포함하고 있습니다. 이는 에이전트의 외부 MCP 도구 호출을 제어(govern)하는 것과는 완전히 다른 문제이며, 이 패턴은 해당 카테고리의 거의 모든 관측성 플랫폼에서 일관되게 나타납니다.

셀프 서비스 경로가 없습니다. Fiddler는 실제 트레이스(trace)당 가격을 공개합니다. Developer 티어에서 트레이스당 $0.002를 책정했는데, 이는 맞춤형 견적(custom quotes)이 일반적인 시장에서 이례적인 투명성이며 Fiddler에 유리한 점입니다. 하지만 버튼들이 실제 상황을 말해줍니다. Free는 "데모 요청(Request demo)"이라고 되어 있습니다. Developer는 "데모 요청(Request demo)"이라고 되어 있습니다. Enterprise는 "영업팀 문의(Contact sales)"라고 되어 있습니다. 사용자가 직접 활성화할 수 있는 티어는 없습니다.

Waxell이 추가하는 것

Waxell은 Fiddler의 표현이 조심스러워지는 지점에서 시작합니다. Observe는 pip install waxell-observe로 설치하며, 재빌드(rebuild) 없이 단 두 줄의 코드로 에이전트(agent)를 계측(instrument)하고, 200개 이상의 라이브러리를 자동 계측(auto-instruments)합니다. 그런 다음 각 실행을 50개 이상의 정책 카테고리 — 감사(Audit), 콘텐츠(Content), 제어(Control), 비용(Cost), 중단(Kill), LLM, 운영(Operations), 품질(Quality), 속도 제한(Rate-Limit), 안전(Safety), 스케줄링(Scheduling), 컴플라이언스(Compliance), 위임(Delegation), 신원(Identity), 개인정보 보호(Privacy), 추론(Reasoning) — 에 대해 1,000개 이상의 정책 전반에서 p95 기준 0.045ms의 속도로 평가합니다. 예산 상한선(Budget ceilings)은 에이전트가 상한선에 도달했을 때 청구서에 나타나는 대신 실행을 중단시킵니다. 정책 카테고리는 OWASP LLM Top 10, NIST AI RMF, ISO 42001, EU AI Act, GDPR 및 HIPAA와 매핑되므로, 동일한 집행을 통해 감사인이 요구하는 증명(attestation)을 생성할 수 있습니다.

Waxell은 또한 Fiddler이 도달하지 못하는 영역도 관리합니다. MCP Gateway는 160개 이상의 업스트림 커넥터(upstream connectors) 앞에 테넌트당 하나의 URL을 배치하여, 전송 중인 개인정보(PII)를 비식별화(redacting)하고, 비밀 정보(secrets)가 게이트웨이를 떠나지 않도록 차단하며, 에이전트가 도구를 호출하기 전 지문 인식(fingerprint) 단계에서 프롬프트 인젝션(prompt injection)을 방지하기 위해 도구 설명을 스캔합니다. 또한 모든 도구를 5단계 신뢰 모델(Pending, Drift, Trusted, Blocked, Removed)을 통해 추적하므로, 정의를 몰래 변경하는 서버는 드리프트(drift)로 감지됩니다. 파괴적인 작업은 인간의 승인을 위해 대기 상태로 전환됩니다. Runtime은 고위험 금융, 임상 및 인프라 워크플로우의 각 단계를 제어하며, 모든 수준에서 킬 스위치(kill switches)를 제공하고 미국 또는 EU의 데이터 레지던시(data residency)를 준수합니다. Waxell Endpoints는 직원 기기(60개 이상의 제공업체 도메인, macOS 및 Windows) 전반에 걸쳐 AI를 탐지하며, 이는 Fiddler의 Lumeus 인수가 목표로 하는 것과 동일한 섀도우 AI(shadow-AI) 사각지대를 다루는 것으로, IDE가 아닌 디바이스 측면에서 접근합니다.

그리고 진입 방식 또한 성격이 다릅니다. 무료로 시작할 수 있고, 두 줄의 설정만 필요하며, 데모 요청이 필요하지 않습니다.

기능 비교

세 가지 시나리오, 두 가지 서로 다른 무게 중심

시나리오: 모델 리스크 거버넌스(model-risk governance) 하에서 예측 ML 모델과 에이전트를 병행하여 운영하는 경우.
Fiddler이 더 강력한 적합성을 가집니다. 신용 모델에 대한 드리프트 모니터링(drift monitoring)과 에이전트 관측성(agentic observability)을 하나의 플랫폼으로 통합하는 것은 소수의 벤더만이 할 수 있는 일이며, ML 관측성 분야에서 Fiddler이 쌓아온 수년의 경험은 쉽게 복제할 수 없습니다. Waxell은 에이전트 측면을 잘 관리하지만, ML 모델 모니터링 제품은 아닙니다.

시나리오: 점수 산정(scoring)이 아니라 에이전트 중단(stopped)이 필요한 경우.
Waxell. 정책(Policies)이 단계 실행 전에 평가되며, 예산(budgets)이 한도에 도달하면 실행을 중단하고, 모든 수준에서 킬 스위치(kill switches)가 존재하며, MCP 게이트웨이(MCP Gateway)가 실행 중인 도구 호출(tool call)을 차단하거나 보류합니다. Fiddler의 가드레일(guardrails)은 실시간 및 환경 내(in-environment)에서 실행되지만, 공개 문서에는 동기식 차단(synchronous blocking) 여부가 명시되어 있지 않으므로, 엄격한 강제 집행(hard enforcement) 요구 사항이 있는 팀은 Fiddler 측에 직접 확인해야 합니다.

시나리오: 한 팀이 이번 주에 세 개의 에이전트를 관리하고자 하는 경우.
Waxell. 코드 두 줄이면 충분하며, 데모 요청 없이 무료로 시작할 수 있습니다. Fiddler의 트레이스당(per-trace) 가격 책정은 투명하지만, 무료(Free) 티어를 포함한 모든 티어는 먼저 영업 상담(sales conversation)을 거쳐야 합니다.

Fiddler AI를 사용해야 하는 경우

• 예측 ML(predictive ML)과 에이전트형 AI(agentic AI)를 함께 관리하며, 두 영역 모두에 대해 하나의 플랫폼, 하나의 감사 추적(audit trail), 그리고 하나의 벤더 관계를 원하는 경우.
• 멀티 에이전트 시스템(multi-agent systems) 전반에 걸쳐 계층적이고 시스템 전체적인 관측성(observability) — 실패한 스팬(span)까지 파고드는 근본 원인 분석 — 이 주요 요구 사항인 경우.
• 프로덕션 규모에서의 비용 예측 가능성을 위해 외부 LLM 판사(LLM-judge) 호출 없이 환경 내 점수 산정(in-environment scoring)이 중요한 경우.
• 조달 프로세스(procurement process)를 갖춘 엔터프라이즈 구매자이며, 데모를 거쳐야 하는 진입점이 장애물이 아닌 일반적인 절차인 경우.

Waxell을 사용해야 하는 경우

• 문서화된 실행 전 강제 집행(pre-execution enforcement) — 즉, 동작을 설명하는 점수가 아니라 동작을 중단시키는 정책 — 이 필요한 경우.
• 드리프트 탐지(drift detection), 비밀 정보 차단(secret blocking), 파괴적인 작업에 대한 인간의 승인(human approval)과 함께 에이전트 자체의 MCP 도구 호출(tool calls)에 대한 거버넌스가 필요한 경우.
• 섀도우 AI(shadow-AI) 노출이 IDE뿐만 아니라 현재 직원의 노트북에서도 발생하고 있는 경우.
• 계약 체결 전에 두 줄의 설정으로 무료로 시작하여 가치를 증명하고 싶은 경우.

Waxell의 처리 방식: Waxell은 강제 실행 (enforcement)이 기본 단위(primitive)이며 관측성 (observability)은 강제 실행의 결과물인 AI 제어 평면 (AI control plane)입니다. Observe는 단 두 줄의 코드로 사용자가 구축한 에이전트를 계측 (instrument)하며, 200개 이상의 라이브러리를 자동 계측 (auto-instrumenting)합니다. 또한 실행 시마다 50개 이상의 정책 카테고리를 0.045ms p95 속도로 평가합니다. 여기에는 실행을 중단시키는 비용 상한선 (cost ceilings), 개인정보 (PII) 삭제, 콘텐츠 및 안전 게이트, 킬 스위치 (kill switches) 등이 포함되며, 이는 OWASP LLM Top 10, NIST AI RMF, ISO 42001, EU AI Act, GDPR 및 HIPAA에 매핑되어 동일한 강제 실행만으로도 즉시 제출 가능한 감사 (audit) 자료를 생성합니다. MCP Gateway는 160개 이상의 업스트림 커넥터(upstream connectors)를 통해 에이전트가 수행하는 도구 호출 (tool calls)을 관리하며, 5단계 도구 지문 인식 (five-state tool fingerprinting)을 통해 조용한 드리프트 (silent drift)를 포착하고 파괴적인 작업에 대해서는 인간 참여 (human-in-the-loop) 대기 상태를 유지합니다. Runtime은 오류 발생 시 비용이 큰 워크플로의 각 단계를 제어하며, Endpoints는 직원의 기기에서 실행 중인 AI를 찾아냅니다. 사후에 확인하는 대시보드는 거버넌스 (governance)가 아닙니다. 그것은 부검 (autopsy)일 뿐입니다.

FAQ

Waxell은 Fiddler AI의 대안인가요?