VictoriaMetrics, 메트릭·로그·트레이스 및 AI 지원 문제 해결을 위한 VictoriaStack 출시

VictoriaMetrics가 메트릭, 로그, 분산 추적 제품을 통합 운영 모델로 묶은 오픈 소스 옵저버빌리티 스택 VictoriaStack을 선보였다. 이번 출시는 엔지니어링 팀이 전체 모니터링 환경을 교체하거나 모든 신호를 하나의 데이터베이스에 넣지 않고도 텔레메트리 범위를 넓힐 수 있도록 하는 것을 목표로 한다.

VictoriaStack은 메트릭용 VictoriaMetrics, 로그용 VictoriaLogs, 트레이스용 VictoriaTraces를 결합한다. 팀은 필요한 신호부터 도입하고 나중에 다른 신호를 추가할 수 있으며, 공통 배포 도구와 OpenTelemetry 지원을 통해 구성 요소들을 연결할 수 있다.

이번 발표는 이 모델을 AI 지원 운영으로도 확장한다. 공식 Model Context Protocol 서버와 에이전트 스킬을 이용하면 어시스턴트가 스택 전반의 텔레메트리를 조사할 수 있으며, 어떤 변경 사항을 적용할지는 엔지니어가 계속 결정한다.

세 가지 신호, 세 가지 전문 데이터베이스

메트릭, 로그, 트레이스는 서로 다른 운영 질문에 답한다. 메트릭은 요청률, 오류 건수, 메모리 사용량과 같은 동작을 시간에 따라 요약한다. 로그는 이벤트와 그 세부 정보를 기록한다. 분산 트레이스는 여러 서비스를 거치는 요청의 흐름을 추적해 시간이 어디에 쓰였는지, 장애가 어디서 발생했는지를 보여준다.

장애가 발생하면 엔지니어는 먼저 메트릭에서 지연 시간 급증을 발견하고, 트레이스를 통해 문제를 특정 서비스로 좁힌 다음, 로그를 살펴 근본적인 오류를 확인할 수 있다. 이러한 신호를 일관된 워크플로로 통합하면 저장 요건을 동일하게 만들지 않고도 조사 시간을 줄일 수 있다.

VictoriaStack의 아키텍처 문서에는 공통 구성 요소 모델을 공유하는 독립 데이터베이스가 설명되어 있다. 각 데이터베이스는 단일 바이너리로 실행하거나 수집, 저장, 쿼리 기능을 분리한 클러스터로 실행할 수 있다. 스택은 라우팅과 부하 분산을 위한 진입점으로 vmauth를 사용할 수 있다.

쿼리 인터페이스도 각 제품에 맞게 유지된다. VictoriaMetrics는 PromQL 호환 MetricsQL을 사용하고, VictoriaLogs는 LogsQL을 사용하며, VictoriaTraces는 LogsQL과 Jaeger 및 Tempo 호환 API를 지원한다. 따라서 통합 운영이 단일 데이터베이스나 범용 쿼리 언어 하나만 사용한다는 뜻은 아니다.

세 가지 핵심 데이터베이스는 모두 Apache 2.0 라이선스로 제공된다. 회사는 엔터프라이즈 기능과 상용 지원도 제공하며, 세 가지 신호를 지원하는 완전 관리형 VictoriaMetrics Cloud 서비스도 운영한다.

OpenTelemetry로 수집 계층 연결

OpenTelemetry는 애플리케이션을 계측하고 텔레메트리를 내보내는 공통 방식을 제공한다. OTLP 프로토콜은 VictoriaStack의 메트릭, 로그, 트레이스 전반에서 지원되므로 데이터가 서로 다른 백엔드에 저장되더라도 일관된 수집 경로를 사용할 수 있다.

애플리케이션이 소수의 서비스에서 분산 시스템으로 확장될 때 이 차이는 중요하다. 계측은 애플리케이션의 동작을 설명하는 데 도움이 되어야 하며, 텔레메트리의 전송 대상을 바꾸더라도 각 서비스의 모니터링 코드를 전면 재설계할 필요가 없어야 한다.

이 스택은 적절한 경우 다른 수집 형식도 지원한다. 예를 들어 Prometheus 기반 메트릭 수집 환경을 이미 갖춘 팀은 해당 생태계를 유지하면서 로그나 트레이싱을 함께 도입할 수 있다. 프로토콜 호환성은 마이그레이션 작업을 줄여 주지만, 보존 기간과 용량, 쿼리 패턴은 엔지니어링 차원에서 결정해야 한다.

Kubernetes 배포의 경우 VictoriaMetrics는 일반적인 관리 도구로 Operator와 Helm 차트를 안내한다. 이를 통해 각 신호의 워크로드에 맞춰 개별적으로 확장할 수 있는 유연성은 유지하면서 배포와 업그레이드를 더욱 일관되게 만드는 것이 목표다.

AI 에이전트, 텔레메트리 전반을 조사

VictoriaStack은 두 가지 방향에서 AI에 접근한다. 옵저버빌리티 시스템은 에이전트형 애플리케이션이 생성하는 텔레메트리를 처리해야 하며, AI 어시스턴트는 엔지니어가 해당 텔레메트리를 조사하는 일을 도울 수 있다.

회사의 AI 도구 문서에는 메트릭, 로그, 트레이스용 MCP 서버가 각각 설명되어 있다. 이 서버들은 시계열 쿼리, 로그 필드 탐색, 서비스와 작업 찾기, 트레이스 검색과 같은 구조화된 기능을 제공한다. 메트릭 통합 기능은 카디널리티, 쿼리 동작, 알림 설정에 대한 조사도 지원한다.

회사의 에이전트 스킬 저장소에는 여러 신호를 활용한 조사와 관련 운영 작업을 위한 재사용 가능한 워크플로가 추가되어 있다. 어시스턴트는 대시보드 하나에 의존하거나 오류 메시지를 붙여 넣는 대신, 여러 신호를 아우르는 문제 해결 절차를 따를 수 있다.

이번 발표는 Claude Code, Codex, Cursor 및 사내 에이전트와 같은 어시스턴트에 읽기 전용 접근 권한을 제공한다고 설명한다. 이에 따라 의도된 워크플로는 조사에 초점을 둔다. 즉, 증거를 수집하고 증상 간 연관성을 파악해 설명을 제안하면, 엔지니어가 실제 적용 여부를 결정한다. 텔레메트리 소스를 에이전트에 연결하는 것만으로 에이전트가 근본 원인을 정확히 파악했다고 단정할 수는 없다.

수집과 쿼리를 별도로 확장

VictoriaStack 빠른 시작에서는 단일 노드 구성과 클러스터 구성을 모두 보여 줍니다. Docker Compose 데모에는 OpenTelemetry 애플리케이션과 수집기, 세 가지 데이터베이스, Grafana, vmalert, vmauth가 포함됩니다. 문서에서는 이 로컬 환경이 프로덕션 배포가 아닌 시연용임을 명확히 밝힙니다.

클러스터 모델에서 수집 및 쿼리 구성 요소는 상태를 저장하지 않아 서로 독립적으로 확장할 수 있지만, 스토리지 구성 요소는 데이터를 유지합니다. 이 구조는 서로 다른 부하 요인을 분리합니다. 유입되는 텔레메트리가 늘어나면 수집 용량을 확충해야 할 수 있고, 조사를 수행하는 엔지니어나 에이전트가 늘어나면 쿼리 수요가 증가할 수 있습니다.

스토리지 계획도 여전히 중요합니다. 문서에 따르면 데이터베이스는 로컬 파일 시스템에 텔레메트리를 저장하며, S3 또는 Google Cloud Storage는 백업에 사용되고 객체 스토리지 기반 쿼리 계층으로는 사용되지 않습니다. 또한 스토리지 샤드 수를 줄이는 작업은 복잡하다고 설명합니다. 토폴로지를 선택하고 성장을 예측할 때 이러한 특성을 고려해야 합니다.

한꺼번에 마이그레이션하지 않고 조화롭게 구성하는 스택

VictoriaMetrics는 KubeCon + CloudNativeCon North America 2026에서 VictoriaStack을 선보입니다. 시연에서는 OTLP 계측이 적용된 Kubernetes 애플리케이션이 세 가지 텔레메트리 신호를 각각 해당 백엔드로 전송한 뒤, 여러 신호를 아우르는 문제 해결 워크플로를 보여 줍니다.

VictoriaMetrics의 공동 창업자이자 엔지니어링 매니저인 Roman Khavronenko는 발표문에서 “에이전트 시대에는 텔레메트리가 늘고 이를 처리하는 방식에 대한 요구도 커질 것입니다”라고 말했습니다. 그는 이러한 수요 증가에 맞춰 확장성과 효율성을 중심으로 VictoriaStack을 설계했다고 밝혔습니다.

실용적인 접근 방식은 점진적으로 도입하는 것입니다. 유용한 수집 생태계는 유지하고, 부족한 신호를 추가하며, 그에 따라 늘어나는 서비스를 더욱 일관된 모델로 관리할 수 있습니다. 텔레메트리 양과 조사 수요가 증가하는 상황에서 각 구성 요소가 얼마나 잘 연동되는지가 VictoriaStack의 가치를 좌우합니다. 동시에 팀은 데이터 저장 위치와 각 신호의 확장 방식을 직접 관리할 수 있습니다.