promkr 뉴스레터 2026년 7월호

이 호에 실린 소식 7개의 원문을 읽고 요약했습니다. 뉴스레터 설명이 아니라 링크가 가리키는 글의 내용을 기준으로 썼습니다. 한 해 전체의 흐름은 2026년 소식에 있습니다.

1. Airbnb의 vmagent 기반 대규모 메트릭 집계

원문: How Airbnb Built a High-Volume Metrics Pipeline with OpenTelemetry and vmagent · Pablo Fernandez · 2026-05-20

VictoriaMetrics가 Airbnb의 메트릭 파이프라인 전환 사례를 소개합니다. 기존 시스템은 애플리케이션의 StatsD 라이브러리, 자체 수정한 Veneur, 외부 벤더 백엔드로 구성했습니다. Airbnb는 새 Prometheus 기반 저장소와 개방형 표준에 맞추려고 OTLP를 채택했습니다. 전환 중에는 기존 StatsD와 OpenTelemetry Collector 경로를 함께 운영하며 새 파이프라인을 검증했습니다.

저장 전 집계는 기존 시스템에서도 중요한 요구였습니다. instance나 hostname 같은 레이블을 그대로 저장하면 카디널리티가 커져 백엔드에 부담을 주기 때문입니다. Veneur를 계속 쓰려면 Prometheus 프로토콜과 데이터 모델에 맞춘 재작성이 필요했습니다. Prometheus recording rules는 원시 시계열을 먼저 저장해야 하므로 목적에 맞지 않았습니다. Airbnb는 스트리밍 집계와 샤딩을 지원하고 코드 규모가 약 10K LOC인 vmagent를 선택했습니다.

파이프라인은 상태를 보관하지 않는 라우터와 상태를 보관하는 집계기 계층으로 나눴습니다. 라우터의 -remoteWrite.shardByURL.ignoreLabels=instance,host 설정은 집계에서 없앨 레이블을 샤딩 키에서도 제외합니다. 이에 따라 service와 region이 같은 샘플은 같은 집계기로 갑니다. 원문의 예에서는 서로 다른 instance와 host를 가진 값 10과 12를 합쳐, service와 region만 남긴 값 22를 출력합니다.

스트리밍 집계는 규칙별 상태를 메모리에 유지하고 설정한 간격마다 결과를 백엔드에 보냅니다. 레이블만 지우는 방식과 달리 여러 입력 시계열의 값을 합칩니다. VictoriaMetrics는 Airbnb가 자체 수정한 vmagent와 수백 개 집계기 파드로 단일 클러스터에서 초당 1억 샘플 이상을 처리했다고 밝힙니다. 집계 후에는 전체 요청 수를 조회할 수 있지만, 특정 인스턴스가 처리한 요청 수처럼 제거한 레이블을 기준으로 한 조회는 할 수 없습니다.

2. AI 근본 원인 분석의 추론과 입력 준비 실험

원문: The hard part of AI root cause analysis is no longer the model · Nikolay Sivko · 2026-06-30

Coroot의 Nikolay Sivko는 AI 근본 원인 분석에서 모델의 추론 능력과 모델 주변의 데이터 준비 체계를 구분해야 한다고 주장합니다. 필요한 증거를 받지 못한 실패를 추론 실패로 판단해서는 안 된다는 뜻입니다. Coroot는 모델이 도구를 호출하며 조사하게 하는 대신, 결정론적 파이프라인으로 신호를 연관 짓고 분석 결과를 압축합니다. 이번 실험은 이렇게 준비한 동일한 문맥을 모델에 주어 추론을 비교했습니다.

실험에서는 Chaos Mesh의 NetworkChaos로 catalog와 Postgres 데이터베이스 db-main 사이에 네트워크 지연을 넣었습니다. 쿼리 지연과 타임아웃이 퍼지면서 front-end에서 502 오류가 발생했습니다. 입력에는 네트워크 RTT와 연결 지연, 실험 시작 시점을 보여 주는 Kubernetes 이벤트가 포함됐습니다. 저자는 네트워크 지연이 Postgres 쿼리 시간에도 반영돼 데이터베이스 자체가 느려진 것처럼 보이는 신호가 판단을 어렵게 했다고 설명합니다.

11개 모델에 각각 한 번씩 같은 프롬프트를 제공했습니다. 입력은 약 9,800토큰, 출력은 약 1,000토큰이었습니다. 통과 기준은 실험을 원인으로 지목하고, front-end까지의 장애 전파를 설명하며, 실험과 재생성 스케줄을 모두 제거하도록 제시하는 것이었습니다. Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro Preview, DeepSeek-V4-Pro, GLM-5.2가 통과했습니다. 사건당 비용은 각각 $0.0743, $0.0492, $0.0397, $0.0166, $0.0132였습니다.

나머지 모델에서는 스케줄 제거 누락, 원시 위젯 ID 노출, 잘못된 리소스 이름, 데이터베이스를 원인으로 오인하는 문제가 나왔습니다. Gemma 4 31B는 원인을 찾았지만 스케줄을 남겼고, Qwen3 Coder Next는 Postgres 확장을 제안했습니다. 저자는 단일 사건이 벤치마크는 아니라고 명시합니다. 그럼에도 이번 결과는 평소 관찰한 경향과 일치한다고 말합니다. 저자는 AI 근본 원인 분석의 추론 문제는 사실상 해결됐으며, 어려운 과제는 모델 호출 전에 적절하고 간결한 문맥을 준비하는 하네스에 있다고 결론짓습니다.

3. OpenTelemetry Go 컴파일 타임 계측 v1 출시

원문: Announcing v1 of OpenTelemetry Go Compile-Time Instrumentation · Kemal Akkoyun (Datadog) · 2026-07-16

OpenTelemetry 커뮤니티가 Go Compile-Time Instrumentation의 첫 안정 버전인 v1을 발표했습니다. Go는 단일 정적 바이너리로 컴파일되므로 시작 시점에 에이전트를 붙이는 자동 계측 방식이 어려웠습니다. 이 프로젝트는 빌드 시점에 계측을 넣어 소스 코드를 수정하지 않고 애플리케이션과 의존성의 트레이스·메트릭을 수집하도록 만듭니다. Alibaba와 Datadog가 2025년 초 SIG 출범 때부터 함께 개발했습니다.

명령줄 도구 otelc는 표준 Go 도구 체인을 감쌉니다. 기존 go build를 otelc go build로 바꾸면 go 뒤의 인자는 도구 체인에 그대로 전달됩니다. 내부적으로는 Go의 -toolexec 기능을 사용해 애플리케이션, 의존성, 표준 라이브러리를 컴파일할 때 계측 코드를 주입합니다. 계측은 바이너리에 포함되므로 실행 시 별도 에이전트를 연결하지 않습니다. 기본 동작은 모듈에서 지원 라이브러리를 찾아 자동으로 계측하는 방식입니다.

v1은 net/http, database/sql, gRPC, Redis와 Go runtime metrics 등을 지원합니다. 생성하는 텔레메트리는 OpenTelemetry semantic conventions를 따릅니다. 지원하지 않는 라이브러리는 SIG의 계측 규칙 형식으로 확장할 수 있습니다. 발표문은 실행 시 계측을 부착하는 방식의 추가 오버헤드가 없다고 설명하며, 후속 과제로 빌드 시간과 실행 비용을 계속 줄이는 작업도 제시합니다.

컴파일 타임 계측은 애플리케이션을 다시 빌드할 수 있다는 조건이 있습니다. 바이너리를 다시 빌드할 수 없거나 프로세스 밖에서 여러 언어를 계측하려면 OBI를, 사용자 정의 스팬과 도메인별 텔레메트리에는 수동 API 계측을 제시합니다. 이 방식들은 함께 사용할 수 있습니다. v1의 지원 범위는 Go 생태계 일부에 한정되며, 향후 라이브러리 지원 확대와 OpenTelemetry Registry 기반 계측 검색·배포를 추진할 계획입니다.

4. 에이전트 트레이스를 위한 LangChain의 SmithDB

원문: We built SmithDB, the data layer for agent observability · Ankush Gola · 2026-05-13

LangChain은 에이전트 관측과 평가에 맞춘 분산 데이터베이스 SmithDB를 공개했습니다. 에이전트 트레이스는 수백 개의 중첩 스팬과 이미지·오디오 같은 큰 데이터를 담으며, 시작 이벤트와 종료 이벤트가 수분에서 수시간 간격으로 도착하기도 합니다. LangChain은 이런 데이터에서 개별 실행 조회, 전문 검색, JSON 필터, 트리 조건 검색, 대화 복원과 집계를 낮은 지연으로 처리하려고 SmithDB를 만들었다고 설명합니다.

SmithDB는 Rust로 작성했고 Apache DataFusion 쿼리 엔진과 Vortex 파일 도구를 용도에 맞게 수정했습니다. 영구 데이터는 객체 저장소에, 세그먼트 메타데이터는 작은 Postgres 메타스토어에 둡니다. 수집·쿼리·컴팩션 서비스는 상태를 보관하지 않는 형태로 구성해 컴퓨팅 자원을 추가하며 확장합니다. 쓰기를 메모리에 모았다가 정렬된 불변 세그먼트로 저장하는 LSM 방식이며, 쿼리 서비스는 SSD와 메모리 캐시를 적극적으로 사용합니다.

최신 실행을 찾는 쿼리는 최근 시간 구간부터 읽고, 정확성을 지킬 수 있는 시점에 중단해 스캔 범위를 줄입니다. 최신 파일을 쓴 수집 노드가 살아 있으면 해당 노드의 캐시에서도 읽습니다. 하나의 실행은 여러 이벤트로 저장하고 조회할 때 병합합니다. 종료 이벤트가 추가될 가능성이 큰 최근 데이터는 너무 일찍 큰 파일로 합치지 않습니다. 큰 입력·출력 필드는 기본 실행 필드와 분리해 요청받을 때만 읽고, 전문 검색과 JSON 필터에는 객체 저장소에 맞춘 역색인을 사용합니다.

LangChain이 제시한 지연은 트레이스 트리 조회 P50 92ms·P99 595ms, 실행 필터링 P50 82ms·P99 434ms, 전문 검색 P50 400ms·P99 870ms입니다. 게시 당시 US Cloud 수집 트래픽과 스레드를 포함한 트레이싱 UI 쿼리 트래픽의 100%가 SmithDB를 사용했습니다. 메타데이터·피드백·텍스트·트리 필터도 이전을 마쳤습니다. 실행 규칙, 대량 내보내기, 실험 기능 통합은 마무리 단계였으며, LangSmith 자체 호스팅 배포 지원은 후속 계획으로 제시했습니다.

5. Kubernetes 이벤트의 사용자 정의 집계 설계

원문: Enhancing Kubernetes Event Management with Custom Aggregation · Rez Moss · 2025-06-10

Rez Moss는 Kubernetes 이벤트를 장기 보관하고 서로 연결하는 집계 시스템을 Go 예제로 설명합니다. 글은 대규모 클러스터에서 분당 수천 개의 이벤트가 발생할 수 있지만 기본 보존 기간은 1시간이라고 짚습니다. 서로 다른 구성 요소에서 발생한 관련 이벤트가 자동으로 연결되지 않고, 표준화된 심각도·분류와 유사 이벤트 묶음도 부족하다는 점을 설계의 출발점으로 삼습니다.

시스템은 Event Watcher, Event Processor, Storage Backend로 나눕니다. Watcher는 Kubernetes API를 감시해 이벤트를 전달합니다. Processor는 분류, 심각도, 연관 ID와 메타데이터를 붙입니다. 연관 분석 전략으로는 시간 구간, 같은 리소스, 인과관계를 제시하며, 예제 키는 네임스페이스·리소스 종류·이름을 조합합니다. 저장 계층은 대량 이벤트 조회, 유연한 보존 정책과 집계 쿼리를 지원하도록 설계합니다.

패턴 탐지 예제는 이벤트의 Reason, 리소스 종류, 네임스페이스가 같은 항목을 묶습니다. 이벤트가 3개 미만인 그룹은 제외하고, 시간순으로 정렬한 뒤 발생 빈도를 계산합니다. 분당 0.5건을 초과하는 그룹을 패턴으로 기록하며 표본은 최대 3개 남깁니다. 이 방식으로 반복되는 노드 압력, 파드 스케줄링 실패와 네트워크 문제를 찾도록 합니다. 알림 예제는 규칙에 맞는 이벤트에서 알림을 생성하는 개념적 초안이며, 완성된 해결책은 아니라고 명시합니다.

운영 설계에는 처리 속도 제한, API 서버 수준의 필터링, 저장 작업의 배치 처리를 권합니다. 처리량 확대를 위해 여러 워커와 리더 선출을 제시하고, API 제한에는 백오프를 적용하도록 합니다. API 서버 연결이 끊겼을 때의 처리, 저장소 장애 중 버퍼링, 지수 백오프 재시도도 포함합니다. 글은 이 예제들을 요구에 맞춰 확장하는 출발점으로 제시하며, 이상 탐지와 관측 플랫폼 연동 등은 향후 확장 항목으로 남깁니다.

6. 화면 문맥을 활용하는 Headlamp AI Assistant

원문: Introducing Headlamp AI Assistant · Joaquim Rocha (Microsoft) · 2025-08-07

Headlamp AI Assistant는 Kubernetes 관리와 문제 해결을 돕는 대화형 플러그인입니다. 사용자가 자신의 LLM API 키를 설정해 모델을 선택하면 Headlamp UI에서 질문하고 작업을 요청할 수 있습니다. 애플리케이션 상태를 묻는 넓은 질문에서 시작해 문제가 있는 파드 목록이나 특정 파드의 수정 방법으로 범위를 좁히는 사용 흐름을 제시합니다.

플러그인은 사용자가 현재 Headlamp에서 보고 있는 화면을 문맥으로 활용합니다. 소개문은 실패한 파드 화면에서 원인을 물으면 누락된 환경 변수나 이미지 이름 오타 등을 짚고, 후속 질문에 수정안을 제안하는 예를 듭니다. 소개문은 어시스턴트가 현재 화면을 파악하기 때문에 사용자가 사람 비서와 일하는 듯한 느낌을 받는다고 설명합니다. 저자는 Headlamp의 문맥을 공유하는 일이 간단하지 않으며, 정확한 문맥 전달을 계속 개선하겠다고 밝힙니다.

화면에 없는 정보를 가져오거나 작업을 수행할 때는 Kubernetes 도구를 사용합니다. 파드 목록을 보면서 문제가 있는 Deployment를 요청해도 현재 클러스터에서 관련 데이터를 조회할 수 있습니다. 재시작이 필요한 Deployment를 확인한 뒤 재시작을 요청하는 흐름도 지원합니다. 쓰기 작업은 실행 전에 사용자 허가를 확인합니다.

게시 당시 지원 도구는 Kubernetes 도구뿐이었습니다. Flux 플러그인의 GitOps 정보, Prometheus 모니터링, Helm 패키지 관리와의 연동은 확장 방향으로 제시했으며, MCP 통합도 검토 중이라고 밝혔습니다. 초기 버전의 설치 경로는 데스크톱 Headlamp의 Plugin Catalog 또는 Headlamp 배포용 컨테이너 이미지입니다. 글은 현재 기능을 소개하면서 이후 버전에 반영할 피드백을 받는 단계임을 명시합니다.

7. Uptime Kuma 모바일 모니터링 앱 KumaAlert

원문: KumaAlert - the Uptime Kuma app for iPhone, iPad & Android · Bobby Holmes

KumaAlert는 Uptime Kuma 상태를 iPhone, iPad와 Android에서 확인하는 네이티브 앱입니다. 개발자 Bobby Holmes는 휴대전화가 무음일 때 일반 푸시 알림도 조용해 야간 장애를 놓친 경험을 개발 배경으로 설명합니다. 제공된 제품 페이지는 실시간 상태, 푸시 알림, heartbeat 기록과 홈 화면 위젯을 주요 기능으로 소개합니다.

상태 갱신에는 폴링 대신 Socket.IO를 사용합니다. 모니터별 가동률, 응답 시간과 인증서 만료를 확인하며, 최근 24시간의 검사 기록을 24개 구간과 응답 시간 그래프로 표시합니다. 여러 Uptime Kuma 서버를 연결할 수 있고 LAN·Tailscale 주소의 일반 HTTP 접속도 지원합니다. 모바일에서 일회성 또는 반복 유지보수 시간을 예약해 해당 기간의 알림을 끌 수 있습니다. iPad에는 서버 사이드바, 넓은 대시보드와 Kiosk mode를 제공합니다.

iOS에서는 모니터별로 Critical Alerts를 켜고 별도 음량을 설정할 수 있습니다. 지정한 모니터의 DOWN 알림은 무음 모드, 방해금지와 Focus 설정을 넘어 소리를 냅니다. 서버, 자격 증명과 환경설정은 로그인한 기기 사이에서 암호화해 동기화하며, 암호화 키를 기기에만 두려는 사용자를 위해 종단 간 암호화 선택지도 제공합니다. 제품 페이지는 모니터링 데이터가 기기와 Kuma 인스턴스 사이에 머문다고 설명합니다.

페이지에 표시된 요구 버전은 iOS 17.2 이상, Android 10 이상, Uptime Kuma 1.23.0 이상입니다. 가격은 £3.99 일회성 구매이며 스토어에 따라 현지 통화 상당액으로 표시합니다. 구매는 해당 플랫폼에 적용되고 구독이나 앱 내 구매는 없다고 안내합니다. 등록된 자선단체와 비영리단체에는 신청을 받아 무료 이용을 제공합니다. Uptime Kuma의 공식 앱이 아니라는 점도 페이지에서 밝힙니다.