promkr 뉴스레터 2025년 7월호

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

1. Grafana Tempo 2.8의 TraceQL 확장과 메모리 개선

원문: Grafana Tempo 2.8 release: memory improvements, new TraceQL features, and more · Tiffany Jernigan, Joe Elliott · 2025-06-13

Grafana Tempo 2.8은 TraceQL 검색과 메트릭 함수를 확장하고 컴팩터의 메모리 사용을 줄인 릴리스입니다. 기존 검색은 조건에 맞는 결과를 발견한 순서로 반환하므로 최신 트레이스가 먼저 나온다는 보장이 없습니다. 새 쿼리 힌트 with (most_recent=true)는 최신 결과를 요청하는 기능입니다. Grafana Labs는 일부 쿼리에서 성능이 나빠져 기본 동작으로 적용하지 않았다고 설명합니다.

부모 span ID로 자식 span을 찾는 span:parentID도 추가됐습니다. 메트릭 쿼리에서는 sum_over_time으로 전송 바이트나 span 지속 시간 등의 누적 합계를 계산할 수 있습니다. topk와 bottomk는 값이 크거나 작은 시계열만 남겨 결과의 카디널리티를 제한하는 함수입니다. 예를 들어 span 이름별 rate() 결과에 topk(2)를 붙이면 상위 시계열만 살펴볼 수 있습니다.

컴팩터 개선은 큰 트레이스가 늘면서 드러난 과도한 객체 풀링 문제에서 출발했습니다. Grafana Labs가 OOM 직전 프로파일을 조사했을 때 vParquet4 행 풀이 사용 중 메모리의 85%를 차지했습니다. 2.8에서는 풀링을 줄이고 가비지 컬렉터가 트레이스를 정리하도록 바꿨습니다. 회사는 트래픽과 테넌트가 많은 설치에서 메모리 최고 사용량이 절반 미만으로 줄었다고 보고합니다. 메모리 문제가 계속되면 풀링 값을 더 조정할 수 있다는 설명도 덧붙였습니다.

호환성을 깨는 변경도 포함됐습니다. 2.7에서 사용 중단을 예고한 서버리스 기능을 제거해 querier.search 아래 관련 설정과 메트릭을 더는 사용할 수 없습니다. 기본 HTTP 수신 포트는 80에서 3200으로 변경됐습니다. 속성 크기를 제한하던 max_span_attr_byte는 max_attribute_bytes로 이름이 바뀌었으며, 제한 대상도 span과 리소스에서 이벤트·링크·계측 정보까지 넓어졌습니다.

2. VictoriaLogs를 트레이스 저장소로 활용한 실험

원문: Developer’s Note: Research on Distributed Tracing, Comparing With Tempo and ClickHouse · Zhu Jiekun · 2025-06-09

Zhu Jiekun은 별도 트레이싱 데이터베이스를 만들기 전에 VictoriaLogs로 span을 저장하는 개념 증명을 진행했습니다. span과 구조화 로그는 반복되는 키와 값으로 구성되며, 대량으로 수집하지만 일부만 조회한다는 공통점이 있습니다. 저자는 쓰기 처리량과 압축 효율을 우선하는 LSM-Tree 기반 컬럼 저장 방식이 적합하다고 설명합니다. 실험에서는 span 내용을 필드로 펼치고, 카디널리티가 낮은 서비스 이름과 span 이름을 검색 범위를 좁히는 stream field로 사용했습니다.

비교 대상은 Jaeger와 ClickHouse, Jaeger와 Elasticsearch, Tempo와 S3 조합입니다. 각 저장 구성 요소에 4 CPU와 8 GiB 메모리를 배정하고 SSD 기반 balanced persistent disk를 사용했습니다. 다른 구성 요소에는 병목이 생기지 않을 만큼 자원을 제공했습니다. Elasticsearch 조합은 기본 설정에서 약 5,000 spans/s부터 장애가 발생해 최종 비교에서 제외됐습니다.

저자가 제시한 10,000 spans/s 측정에서 CPU 사용량은 VictoriaLogs 0.50 vCPU, ClickHouse 0.69 vCPU, Tempo 1.35 vCPU였습니다. 메모리는 각각 1.15 GiB, 1.12 GiB, 4.26 GiB였으며, Tempo는 사용량 변동 끝에 OOM이 발생했다고 보고합니다. 같은 시간 범위의 저장량은 VictoriaLogs 3.27 GiB, ClickHouse 5.86 GiB였습니다. Tempo의 객체 저장소 측정값은 약 4.4 GiB였지만 수집 간격이 15분이라 정확도가 부족해 로컬 디스크로 재측정했습니다. 이 수치는 저자의 벤치마크 조건에서 나온 결과입니다.

시각화에는 Jaeger HTTP API를 구현해 Jaeger UI와 Grafana를 연결했습니다. VictoriaLogs에는 trace_id 인덱스가 없어 시간 범위를 넓게 잡으면 관련 없는 블록까지 읽어야 합니다. metadata_lookbehind=3d는 최근 3일의 서비스 이름만 조회하고, trace_id_lookbehind_step=7d는 7일씩 검색하다 데이터를 찾으면 멈추는 설정입니다. 글 작성 당시 독립 제품인 VictoriaTraces 개발은 시작하지 않았으며, VictoriaLogs 기반 구현의 가능성을 검증하는 단계였습니다.

3. 함수 실행 시간을 보존하는 Flame Chart

원문: Flame Charts: The Time-Aware Sibling of Flame Graphs · Manoj Vivek · 2025-05-28

Manoj Vivek은 Flame Graph에서 생략하는 시간 정보를 Flame Chart가 어떻게 보여 주는지 설명합니다. Flame Graph는 같은 스택을 합쳐 자원을 많이 소비하는 함수를 찾는 데 적합합니다. Flame Chart는 샘플을 시간순으로 배치하므로 자원을 소비한 시점과 실행 흐름을 살펴보는 시각화입니다. Polar Signals Cloud에는 이 기능이 알파로 추가됐으며, 시각화 설정에서 활성화한 뒤 프로파일 화면에서 선택할 수 있습니다.

Flame Chart의 가로축은 시간이고 사각형의 폭은 실제 경과 시간을 나타냅니다. 같은 함수라도 호출 시점이 다르면 타임라인에 여러 번 등장합니다. 위쪽 눈금은 실행 시각의 기준이며, 사각형은 호출이 시작하고 끝난 위치에 놓입니다. 빈 구간은 스레드가 CPU에서 실행되지 않은 시간입니다. 글은 그 원인으로 I/O 대기, 블로킹 연산, CPU 스케줄링을 제시합니다.

이 시각화에는 샘플이 겹치지 않도록 범위를 제한하는 조건이 있습니다. 단일 CPU 코어나 스레드의 프로파일을 선택하고, thread_id나 cpu처럼 샘플의 비중첩을 보장하는 레이블로 그룹화해야 합니다. 그래야 한 시점의 호출 스택을 하나의 타임라인으로 읽을 수 있습니다. Parca와 Polar Signals Cloud는 하이퍼스레딩을 별도 vCPU로 취급합니다.

주문 처리 예제는 시간 정보의 차이를 보여 줍니다. 프로그램은 주문이 있으면 처리하고, 없으면 100ms 동안 쉽니다. Flame Chart에서는 주문 처리 직후 다음 조회가 시작되는 구간과 주문이 없어 100ms 간격이 생기는 구간을 구분할 수 있습니다. Flame Graph라면 합쳐질 pollNewOrders 호출이 개별 시점에 남으므로 반복문의 분기와 대기 패턴을 읽을 수 있다는 설명입니다.

4. AI-SRE 코파일럿의 활용과 도입 조건

원문: The AI-SRE Frontier: From Hype to Practical Application · Andrew Mallaband · 2025-06-24

Andrew Mallaband의 LinkedIn 기사를 기준으로 정리했습니다. 저자는 AI-SRE의 당장 실현 가능한 역할을 사람의 장애 조사를 돕는 코파일럿으로 제시합니다. AI가 텔레메트리를 선별하고 조사할 지점을 좁히면 엔지니어의 인지 부담을 줄일 수 있다는 주장입니다. 이를 뒷받침하는 조건으로 데이터 품질, 엔지니어링 작업과 효과의 가시성, 사업 목표와의 연결을 꼽습니다.

기사에서 MCP는 LLM이 관측 데이터와 도구에 접근하는 연결 수단입니다. 저자가 인용한 Honeycomb 사례에서는 Claude Sonnet 4가 도구를 8회 호출해 프런트엔드 지연 급증의 원인을 찾았습니다. 소개된 소요 시간은 80초, 비용은 60센트입니다. Dash0 사례는 MCP 서버에서 얻은 트레이스 데이터를 LLM이 분석하고 진단 결과를 화면에 제시하는 데모입니다. 이 사례들은 기사에서 소개한 개별 조사와 시연 결과입니다.

Kerno와 Groundcover는 AI에 제공하는 실행 맥락과 데이터 전처리를 강조합니다. Kerno는 서비스 의존성, 성능 병목, API 스키마를 개발 도구에 전달하며, 회사 발표상 에이전트의 토큰 사용량이 35% 줄었습니다. Groundcover는 반복 로그를 패턴으로 압축하고 통계적으로 유의미한 트레이스 속성과 이상 징후를 드러냅니다. Groundcover가 밝힌 전처리 효과는 LLM 처리 비용 60% 감소입니다. 두 업체 모두 eBPF 기반 수집을 활용한다고 소개합니다.

저자는 시연과 초기 도입 사례가 늘어도 폭넓게 검증된 고객 성과는 아직 부족하다고 평가합니다. 높은 투자비, 불확실한 수익, 자동 복구를 맡길 신뢰 부족, 기존 업무와의 통합이 장애물입니다. 특히 빠른 트레이스 진단은 충분한 계측 범위를 전제로 하지만 많은 기업이 이를 구축 중입니다. 저자는 사람이 판단하는 조사 보조에서 시작해 익숙하고 잘 이해한 문제의 복구 자동화로 점진적으로 확장하는 경로를 제안합니다.

5. Humanlog의 로컬 로그·트레이스 분석

원문: humanlog.io · humanlog.io

Humanlog 소개 페이지는 노트북에서 로그와 트레이스를 수집하고 CLI나 브라우저 UI로 분석하는 작업 흐름을 안내합니다. 데이터는 사용자가 공유를 선택하기 전까지 기기에 남습니다. 조회 결과를 팀원에게 전달할 때는 공유 링크를 만드는 방식입니다. 로컬 수집과 분석, 선택적 결과 공유를 하나의 도구에 묶었습니다.

입력 경로로는 표준 입력과 OTLP 수집을 제공합니다. 로그 파일을 cat app.log | humanlog로 전달하거나, kubectl logs -l app=apisvc -f | humanlog처럼 Kubernetes 로그 스트림을 바로 연결할 수 있습니다. OpenTelemetry 연동 예제는 OTEL_EXPORTER_OTLP_ENDPOINT를 http://localhost:4317로 지정합니다. 애플리케이션을 배포하기 전에 span과 트레이스 맥락, span 사이의 관계를 로컬에서 확인하는 용도입니다.

질의 언어는 파이프라인 방식으로 필터링과 집계를 연결합니다. 페이지의 summarize histogram(duration, 10) by bin(_time, 1m) 예제는 시간을 1분 단위로 묶어 duration 히스토그램을 집계합니다. spans | filter name == "db_query"는 이름이 일치하는 span을 실시간으로 조회하는 예제입니다. Humanlog는 로그와 트레이스의 실시간 스트리밍, 질의 결과의 자동 차트 생성도 기능으로 소개합니다.

페이지 하단에는 호스팅 서비스의 방향 변경이 안내돼 있습니다. humanlog.io의 호스팅 도구는 쉬어 가며, 새 프로젝트인 minitape로 이동한다는 내용입니다. 로컬 도구의 설치 안내와 별도로 minitape 출시 소식을 받을 이메일 등록을 제공하고 있습니다.

6. AlertSnitch의 알림 이력 저장과 Loki 연동

원문: AlertSnitch: A Powerful Tool for Visualizing Alert History · Mike Hsu

Mike Hsu의 LinkedIn 게시글을 기준으로 정리했습니다. 저자는 4년간 활동이 없던 AlertSnitch를 포크했다고 소개합니다. 기존 도구는 AlertManager의 알림 이벤트를 MySQL이나 PostgreSQL 같은 데이터베이스에 영구 저장했습니다. 지난 알림을 시각화하고 정기적으로 검토해 시스템의 취약한 부분을 찾기 위한 용도입니다. 알림 발생부터 해결까지의 MTTR도 추적할 수 있다고 설명합니다.

포크에서는 저장 백엔드에 Grafana Loki를 추가했습니다. 저자는 운영 부담을 줄이고 Grafana와의 연동을 강화하려는 변경이라고 밝힙니다. Grafana를 사용 중인 팀이 알림 이력을 조회할 수 있도록 맞춤 대시보드도 제공했습니다. 게시글에는 이 목적과 변경 범위가 소개돼 있으며, 구체적인 설정이나 성능 측정 결과는 담겨 있지 않습니다.

7. HolmesGPT의 반복 조사와 백그라운드 점검

원문: HolmesGPT — The CNCF SRE Agent · Robusta.Dev

제공된 GitHub README는 HolmesGPT를 장애 원인을 조사하는 오픈소스 AI 에이전트이자 CNCF Sandbox 프로젝트로 소개합니다. Robusta.Dev가 처음 만들었고 Microsoft가 주요 기여자로 참여했습니다. 에이전트는 여러 출처의 실시간 관측 데이터를 반복해서 조회하며 원인을 좁힙니다. Kubernetes뿐 아니라 VM, 클라우드 서비스, 데이터베이스와 SaaS도 조사 대상입니다.

README의 Operator Mode는 사람이 문제를 발견해 조사를 시작해야 하는 흐름을 백그라운드 점검으로 확장합니다. 배포 시 애플리케이션과 함께 상태 점검을 실행하거나, 예약한 점검으로 회귀를 탐지하는 방식입니다. 문제를 찾으면 Slack으로 수정 방안을 알리고, GitHub 연동이 있으면 수정 PR을 열 수도 있다고 설명합니다. Operator 자체는 Kubernetes에서 실행하지만 점검 대상은 연결된 다른 데이터 소스까지 포함합니다.

대량 데이터 처리에는 서버 측 필터링, JSON 트리 탐색, 도구 출력 변환을 사용합니다. 큰 응답이 LLM의 컨텍스트 창을 채우지 않도록 줄이는 장치입니다. 도구별 메모리 한도, 큰 결과의 디스크 스트리밍, 자동 출력 예산으로 OOM 종료를 막는 기능도 소개합니다. Prometheus 메트릭과 PromQL, Loki 로그, Tempo 트레이스를 조회할 수 있으며, 사용자 정의 도구와 REST API도 연결할 수 있습니다.

알림 연동은 외부 시스템에서 조사 대상을 가져오고 분석 결과를 다시 기록하는 방식입니다. AlertManager, PagerDuty, OpsGenie, Jira 등을 지원하며, Slack과 Microsoft Teams 연동은 Robusta에서 제공합니다. LLM 공급자는 OpenAI, Anthropic, Azure, Bedrock, Gemini 등을 선택할 수 있습니다. README의 데이터 보호 설명은 기본 설계가 읽기 전용 접근과 RBAC 권한을 따른다고 명시합니다. 라이선스는 Apache 2.0입니다.

8. AI Reliability Engineering과 SRE의 확장

원문: AI Reliability Engineering: Welcome to the Third Age of SRE · The New Stack

제공된 원문 자료에는 기사 제목과 The New Stack의 구독 안내만 있고 기사 본문은 없습니다. 제목은 AI Reliability Engineering을 SRE의 세 번째 시대로 제시합니다.

본문이 없어 저자가 정의한 신뢰성의 범위, 기존 SRE와의 차이, 근거와 사례는 확인할 수 없습니다. 따라서 뉴스레터의 소개를 원문에서 확인한 주장으로 옮기지는 않았습니다.

9. Go 전역 배열 증가로 발생한 Pod 성능 저하

원문: Why Our Pods Were Breaking Bad (and How We Fixed Them) · Kshitij Nawandar · 2024-12-11

Kshitij Nawandar는 Razorpay의 UPI Switch에서 시간이 지날수록 워커의 CPU와 메모리 사용량이 늘어난 문제를 추적합니다. 서비스는 초당 거의 100건의 트랜잭션을 처리했으며, Collect와 Verify 같은 주요 API의 지연도 나빠졌습니다. Pod 수와 자원 한도를 늘려도 문제가 계속됐고, Pod를 재시작하면 잠시 회복했습니다. 다른 인프라 구성 요소는 정상으로 확인돼 애플리케이션 내부를 조사했습니다.

팀은 CPU 사용량이 5코어에 이른 Pod 하나의 힙과 GC 지표를 살폈습니다. 힙에는 여유가 있었고 운영체제로 메모리를 반환하는 동작도 확인됐습니다. 그런데 GC는 계속 활발하게 실행됐으며, 초당 GC 횟수와 CPU 사용량 사이에 높은 상관관계가 나타났습니다. 팀은 GC가 CPU를 소비한다고 의심했고, 빈도를 줄이기 위해 GOGC를 기본값 100%에서 150%로 조정하는 방안을 검토했습니다.

원인을 찾는 데 사용한 도구는 Go의 pprof입니다. 팀은 여러 시점에 /debug/pprof/heap, /debug/pprof/profile, /debug/pprof/goroutine에서 프로파일을 수집했습니다. 분석 결과 전역 배열이 계속 커지고 있었으며, 이 배열과 연결된 메모리 소비 증가가 GC와 CPU 부담을 키웠습니다. 저자는 코드 한 줄을 바꿔 문제를 고쳤다고 설명하지만, 구체적인 수정 코드는 제시하지 않습니다.

저자가 보고한 수정 후 Pod CPU 사용량은 하루 동안 약 150m로 안정됐습니다. 워커의 최대 메모리 사용량은 700 MiB에서 약 50 MiB로 줄었고, Collect API 지연은 445ms에서 223ms로 낮아졌습니다. 자원 고갈로 인한 지연 급증도 더는 관찰되지 않았습니다. 글은 GC·힙 지표의 지속적인 관찰과 시간에 따른 프로파일 비교를 원인 규명에 사용한 절차로 제시합니다.

10. PromQL 쿼리의 파싱과 실행 과정

원문: Inside PromQL: A closer look at the mechanics of a Prometheus query · Bryan Boreham · 2024-10-09

Prometheus 메인테이너 Bryan Boreham은 쿼리 문자열이 저장소 조회와 연산을 거쳐 API 응답이 되는 과정을 설명합니다. 기준 구현은 Prometheus 2.54와 3.0 베타입니다. 파서는 셀렉터·함수·집계·연산자를 노드로 갖는 AST를 만들고, 엔진은 트리를 순회하며 각 셀렉터의 Select()를 호출합니다. 내장 저장소는 레이블 값마다 시계열 ID 목록인 postings를 보유합니다. 조건에 맞는 목록의 교집합을 구하고, 불일치 조건에 해당하는 시계열은 제외합니다.

정규식도 조회 방식에 영향을 줍니다. status=~"200|404"처럼 고정 문자열 집합만 일치하는 표현은 가능한 값을 전부 검사하지 않고 인덱스에서 직접 찾습니다. 이후 엔진은 시계열의 반복자로 필요한 시점의 샘플을 읽습니다. 글은 range vector와 range query를 구분합니다. [5m] 같은 range vector는 표현식 안에서 시계열별 일정 구간의 샘플을 가리키고, range query는 시작부터 끝까지 일정 간격으로 표현식 전체를 실행하는 요청입니다.

함수는 대체로 시계열별 값을 변환하지만, 집계는 지정한 레이블 그룹별 결과를 만듭니다. 벡터 사이의 이항 연산에는 레이블 매칭이 필요합니다. on(host)와 group_left(team)을 쓰면 host로 대응 관계를 찾고 한쪽의 team 레이블을 결과에 붙입니다. 엔진은 한쪽 시계열의 레이블 서명을 해시 테이블에 넣고 다른 쪽의 대응 항목을 찾습니다. 시계열이 새로 생기거나 사라질 수 있어 매 시간 단계마다 이 과정을 반복하므로 비용이 큰 연산이 될 수 있습니다.

실행 결과는 엔진 밖의 HTTP API 계층에서 JSON으로 변환합니다. URL에 &stats=1을 추가하면 준비 시간과 전체 실행 시간 등의 통계도 얻습니다. OpenTelemetry 트레이싱은 AST 노드별 실행 관계를 보여 주고, Go 프로파일링은 CPU와 메모리 사용을 조사하는 수단입니다. 저자는 range query 결과가 처리 후 레이블 순으로 정렬되므로 표현식에 정렬 함수를 넣어도 불필요한 작업만 늘어난다고 설명합니다. 세부 동작은 이후 버전에서 바뀔 수 있다는 전제도 명시했습니다.

11. 사람의 판단을 유지하는 협력형 장애 대응 에이전트

원문: Avoiding the ironies of automation · Chris Evans · 2025-03-26

incident.io의 Chris Evans는 AI 장애 대응 도구를 만들면서 자동화가 사람의 숙련도를 약화시키는 문제를 다룹니다. 출발점은 Lisanne Bainbridge의 1983년 논문 「Ironies of automation」입니다. 일상적인 작업을 기계에 맡기면 사람이 연습할 기회가 줄고, 자동화가 실패했을 때 필요한 판단력과 맥락도 부족해질 수 있다는 논지입니다. Evans는 장애를 예방 장치가 모두 실패한 뒤의 인간 중심 활동으로 보고, 사람과 기계가 협력하는 제품을 제안합니다.

글은 과도한 자동화의 위험을 가상 사례로 설명합니다. 피곤한 엔지니어가 AI의 서버 재부팅 제안을 검토 없이 승인하거나, AI가 모호한 로그만 보고 상태 페이지에 데이터 손실을 알리는 상황입니다. AI가 마케팅 이메일로 트래픽이 늘어난 사정을 모른 채 서비스를 확장해 공유 데이터베이스에 과부하를 일으키는 사례도 있습니다. 이 예시에서 AI는 가진 정보로는 그럴듯한 결정을 내리지만, 주변 사정을 놓쳐 더 큰 문제를 만듭니다.

incident.io가 제시하는 설계 방향은 판단의 근거와 불확실성을 드러내는 협력형 에이전트입니다. 에이전트가 변경을 되돌렸다고 통보하기보다 장애 직전 병합한 PR과 의심스러운 코드를 제시하는 방식입니다. 서비스가 원인이라고 단정하는 대신 오류율 그래프, 타임아웃 로그, 설정 변경 시각을 함께 보여 줍니다. 신뢰할 만한 가설과 조사 경로를 제시하되, 중요한 결정을 사람이 검토하고 책임지도록 언어와 UI를 설계하겠다는 설명입니다.

과거 장애 기록도 학습 재료로 활용합니다. 같은 알림이 몇 번 발생했는지만 알려 주는 대신, 이전 배포 뒤 큐 적체가 생겼던 사건과 관련 기록을 연결합니다. 기계는 검색·종합·패턴 탐색을 맡고, 대응자는 근거를 비교하며 시스템의 동작 모델을 다듬습니다. 글에서 설명한 내용은 incident.io가 개발 중인 제품의 원칙과 계획이며, 저자는 향후 몇 달 안에 구현할 것으로 기대한다고 밝혔습니다.