promkr 뉴스레터 2026년 8월호

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

1. Claude Code Routines를 이용한 일일 성능 최적화

원문: Autonomous Optimization with Claude Code · Frederic Branczyk · 2026-05-06

Polar Signals는 연속 프로파일링 데이터를 Claude Code에 연결해 성능 개선 작업을 매일 실행하는 사례를 소개합니다. Polar Signals Cloud는 CPU, 메모리, GPU 프로파일을 수집하고 저장하는 서비스입니다. 기존에는 엔지니어가 Flamegraph 등을 분석해 코드를 고쳤습니다. 글에서는 이 분석과 수정 과정을 Claude Code의 Routines에 맡기는 구성을 제시합니다.

연결에는 Polar Signals MCP와 OAuth를 사용합니다. OAuth 지원으로 Claude Code Web/Desktop에서도 장기 인증 토큰을 복사하지 않고 MCP에 인증할 수 있습니다. Cloud 커넥터의 MCP 주소는 https://api.polarsignals.com/api/mcp이며, 고급 OAuth 설정의 클라이언트 ID는 polarsignals-mcp-claude-desktop입니다. Routines는 일정이나 특정 트리거에 따라 프롬프트를 실행하며, 이 사례에서는 매일 실행하도록 설정했습니다.

루틴은 지난 하루의 프로파일을 분석하고 그 전날과 비교한 보고서를 작성합니다. 시스템 전체에 이익이 될 설계 변경을 발견하면 개선 내용과 근거를 짧게 기술하도록 했습니다. CPU 사용량을 1% 넘게 개선할 수 있는 유의미한 발견이 있으면 PR을 만드는 조건도 넣었습니다. Polar Signals는 며칠간 실행한 결과, 메모리 할당 감소로 한 워크로드에서 20% 개선을 얻었다고 밝힙니다. 더 나은 해시 알고리즘을 선택하거나 전날 반영한 코드에서 개선점을 찾은 사례도 보고했습니다.

2. Cloudflare의 배포 판정과 Thanos 질의 최적화

원문: Scaling with safety: Cloudflare’s approach to global service health metrics and software releases · Harshal Brahmbhatt, Kevin Deems, Nina Giunta, Michael Hoffmann · 2025-05-05

Cloudflare의 Health Mediated Deployments(HMD)는 서비스 메트릭으로 새 코드의 배포 지속, 일시 중단, 자동 복구를 결정합니다. 엔지니어가 경보 규칙이나 SLO를 설정하면 HMD가 Thanos에 질의해 상태를 판단합니다. 글의 예시는 최근 10분간 HTTP 500 응답 비율을 SLI로 삼고, 이를 0.1% 미만으로 유지하는 SLO입니다. 새 코드가 실행되는 범위에서 성공률이 예상과 달리 낮아지면 이전 버전으로 되돌립니다.

HMD는 과거 인시던트 데이터로 신호 악화에 얼마나 빨리 반응하는지도 검증합니다. Prometheus 보존 기간을 지난 데이터는 R2에서 읽습니다. Cloudflare는 서로 다른 시계열 45억 개를 1년간 보존하며, 약 8페타바이트의 데이터를 1,700만 개 객체에 저장한다고 설명합니다. 백테스트 배치 하나가 수십만 건의 PromQL 질의와 수백만 건의 R2 요청을 만들 수 있습니다. Cloudflare는 여러 최적화를 적용해 배치 실행 시간을 약 30시간에서 2시간으로 줄였다고 보고했습니다.

자주 쓰는 배포 대상 조회는 각 데이터 센터의 Prometheus에서 recording rule로 미리 계산했습니다. 질의 시 처리하는 시계열 범위가 전체 장비에서 실제 배포 대상으로 줄어듭니다. 서비스 SLI마다 recording rule을 늘리는 방식은 쓰기 시점의 계산 비용이 커서, Thanos 분산 질의 엔진도 도입했습니다. 데이터 센터에서 부분 집계를 계산하고 중앙에서 합치는 방식입니다. Cloudflare의 전역 count(node_uname_info) 측정에서는 분산 실행이 평균 3~5배 빨랐습니다.

배치 부하는 우선순위 기반 동시 실행 제어와 무작위 지연으로 조절합니다. 장애를 조사하는 엔지니어의 질의를 우선하며, Thanos의 SLO가 악화되면 배치 요청량을 줄입니다. 성공 시 허용 동시 요청 수를 하나 늘리고, 실패율이 임계값을 넘으면 허용량을 축소합니다. 잘못된 신호가 전체 요청을 막지 않도록 최소 요청률도 둡니다. 객체 스토리지의 임의 I/O를 줄이려는 Parquet 저장 실험도 소개하지만, 확실한 결론을 내리기에는 이른 단계라고 명시했습니다.

3. 텔레메트리 비용 증가와 샘플링의 적용 조건

원문: 2026年にオブザーバビリティのコストにどう向き合うか · ymotongpoo · 2026-08-21

Grafana Labs 개발자 애드보킷인 저자는 텔레메트리를 모두 저장하기 어려워졌을 때 샘플링을 선택지로 알아야 한다고 주장합니다. AI가 개발과 운영을 더 많이 담당할수록 실제 실행 결과를 관측할 필요가 커진다는 관점입니다. 조사하는 AI 에이전트에도 텔레메트리가 입력으로 필요하다고 설명합니다. 이는 저자의 해석이며, AI 에이전트 도입이 텔레메트리 필요량을 몇 퍼센트 늘리는지 보여 주는 조사는 찾지 못했다고 밝힙니다.

근거로 인용한 Honeycomb 사례에서는 평일 최대 병합 건수가 2025년 상반기 약 30건에서 2026년 4월 약 74건으로 늘었습니다. 코드베이스는 16.5개월 동안 97만 줄에서 194만 줄로 증가했습니다. 인시던트 건수도 변경량에 대체로 비례해 늘어, 2026년 1분기는 평소의 1.7배, 2분기는 2.9배였다고 전합니다. Grafana Labs의 2026년 조사에서는 응답자의 50%가 다음 해 지출 증가를 예상했습니다. 증가 이유로 적용 범위 확대를 든 비율은 63%, 벤더 가격 인상은 25%였습니다. 저자는 벤더가 수행하거나 의뢰한 조사라는 점을 감안해야 한다고 덧붙입니다.

저자는 OpenTelemetry 표준화와 생성형 AI가 계측 작업을 쉽게 만들어 적용 범위를 넓힌다고 설명합니다. 비용 목표나 계약상 데이터량에 맞춰 샘플링 비율을 자동 조정하는 제품도 소개합니다. Grafana Cloud Adaptive Traces의 2025년 12월 설명 글은 고객의 트레이스 수집량이 통상 75~90% 줄어든다고 보고했습니다. 저자는 이 기능을 예산 초과와 관측 포기 사이에서 선택할 수 있는 수단으로 제시합니다.

샘플링을 먼저 도입하자는 주장은 아닙니다. 저자는 샘플링이 데이터를 버리는 행위이므로 가능하면 전체를 저장하는 편이 가장 좋다고 명시합니다. 월 수백 GB 정도라면 전체 저장으로도 문제가 없는 경우가 많으며, 보존 기간 단축이나 헬스 체크 데이터·DEBUG 로그 제외로 예산을 맞출 수 있다면 그 방법을 선호합니다. 샘플링은 이런 대책으로도 부족할 때 사용하는 수단입니다. 무엇을 얼마나 버릴지 설계하고, 해당 비율을 선택한 이유를 설명할 수 있어야 한다는 입장입니다.

4. Elasticsearch 메트릭 벤치마크 재현의 미완료

원문: 比我快 30 倍? Prometheus 开发者回应 Elasticsearch 新指标引擎的性能测试 · jiekun.dev · 2026-05-16

이 글은 Elasticsearch의 새 시계열 엔진 벤치마크와 Prometheus 코어 개발자 Goutham Veeramachaneni의 재현 시도를 소개합니다. Elasticsearch는 엔진 개편으로 샘플당 저장 공간을 25 Bytes에서 3.75 Bytes로 줄였고, OpenTelemetry 형식의 데이터 인덱싱 성능을 50% 높였으며, 질의 소요 시간을 160배 줄였다고 발표했습니다. Prometheus보다 30배 빠르다는 비교도 이 발표에 포함됐습니다.

재현 시도의 출발점은 저장 공간 수치였습니다. 글은 Prometheus가 일반적으로 샘플당 1.5 Bytes까지 압축할 수 있는데 벤치마크에는 9.31 Bytes로 제시됐다고 지적합니다. 저장 데이터 모델이 비슷한 Mimir는 3.93 Bytes라는 점도 의문으로 들었습니다. Goutham은 데이터가 아직 압축되지 않은 WAL에만 있었을 가능성을 제기했습니다. 이는 확인된 원인이 아니라 추정입니다. CPU와 메모리 사용량이 비교 자료에 없다는 점도 문제로 꼽았습니다.

글에 따르면 Goutham은 원래 벤치마크와 같은 metricsgenreceiver로 초당 260만 샘플을 2시간 동안 Prometheus에 기록했습니다. 결과는 샘플당 평균 5 Bytes였으며, 기록 중 CPU 사용량은 약 800%, 메모리는 7 GB였습니다. Elasticsearch 시험에는 CPU 24개와 메모리 96 GB를 갖춘 Mac을 사용했지만, 처리량이 부족해 완료 예상 시간이 40시간으로 표시됐습니다. Goutham은 40시간을 기다릴 생각이었습니다. 그러나 제한 시간을 이미 120초로 설정했는데도 곧 쓰기 시간 초과가 발생했습니다. 디스크 읽기량이 쓰기량과 비슷했다는 관찰도 전합니다.

Elasticsearch 쪽 시험은 끝내 완료되지 않았습니다. 따라서 이 글에는 동일 조건에서 성능 비교를 마친 결과가 없습니다. Goutham은 자신의 글에서 Elasticsearch가 실제로는 잘 동작하고 최적화도 훌륭할 수 있지만, 지금은 그 결과를 신뢰할 수 없다고 말합니다. 저자는 재현 과정의 문제만으로 Elasticsearch의 최적화가 거짓이라고 단정할 수는 없다고 선을 긋습니다. Goutham이 ClickHouse JSONBench와 비슷한 형태의 메트릭 전용 공통 벤치마크를 제안했다는 내용으로 논의를 이어갑니다.

5. AI 기반 원인 분석과 옵저버빌리티 데이터 레이크

원문: From Reactive to Predictive: Entering the AI Era of Observability · Megan Reynolds · 2025-03-11

Megan Reynolds가 LinkedIn에 게시한 글을 기준으로 정리했습니다. 저자는 Vertex Ventures US의 투자 관점에서 AI가 옵저버빌리티의 복잡성을 높이는 원인이자 자동화 수단이라고 주장합니다. AI 생성 코드, 비결정적 애플리케이션, 에이전트 작업은 한 번의 사용자 행동을 여러 처리 단계로 확장합니다. 그 결과 텔레메트리 메타데이터 조합인 카디널리티가 증가하고, 대시보드만으로 문제를 찾기 어려워진다는 설명입니다.

저자는 AI 기반 근본 원인 분석(RCA)이 로그 질의, 트레이스 연관 분석, 배포 이력 확인을 자동화할 것으로 전망합니다. 사례로 든 Cleric은 숙련된 SRE의 조사 순서를 따르고 조사할 때마다 접근법을 개선하는 도구입니다. 저자는 사람이 직접 질의하는 도구의 응답 속도와, AI가 원인을 찾아 전체 대응 시간을 줄이는 목표를 구분합니다. 기존 업체는 사람 중심의 화면과 작업 방식에 맞춰져 있어 전환이 어렵다고 평가하지만, 축적한 텔레메트리와 인시던트 데이터는 자동화에서 유리한 자산이라고 인정합니다.

저장과 분석을 분리하는 옵저버빌리티 데이터 레이크도 주요 주제입니다. 저자는 메트릭·로그·트레이스·이벤트를 서로 연관 짓고 빠르게 질의하는 능력이 필요하다고 설명합니다. OpenTelemetry와 Iceberg 같은 공개 표준을 활용하는 업체에는 성능을 일부 양보해 비용을 크게 낮추거나, 고객별 분석처럼 새로운 사용자를 겨냥한 고성능 기능을 제공하는 기회가 있다고 봅니다. 대규모 기업이 내부 데이터 처리 도구와 기존 UI를 조합해 자체 관측 체계를 만드는 흐름도 소개합니다.

완전 자율 운영은 이미 달성한 기능이 아니라 장기 전망입니다. 저자는 초기 업체가 반복 가능한 좁은 문제에 집중하고, 고객과 협력해 정확성과 신뢰를 입증해야 한다고 주장합니다. 인터뷰한 한 개발자는 모든 인시던트의 원인과 수정안을 2년간 정확히 제시해야 자율 실행을 신뢰하겠다고 답했습니다. 기존 업체의 AI 기능도 고객 사례가 없으면 실제 사용 여부가 불분명하다고 적었습니다.

6. OpenTelemetry 메트릭의 S3 직접 저장 실험

원문: Storing telemetry in blob storage · GitHub

이 실험 README는 텔레메트리를 AWS S3 같은 객체 스토리지에 직접 저장하는 구성을 설명합니다. 모든 데이터를 옵저버빌리티 백엔드로 보낼 때 발생할 수 있는 큰 저장 비용을 피하는 것이 실험 목적입니다. 데이터는 수작업으로 만들지 않고 OpenTelemetry Collector의 표준 테스트 도구인 telemetrygen으로 생성합니다. Collector의 AWS S3 exporter가 데이터를 저장하며, 실제 S3 대신 LocalStack으로 로컬에서 검증합니다.

실행 전제는 Docker와 호환되는 컨테이너 런타임과 compose 명령을 지원하는 클라이언트입니다. docker compose up으로 서비스를 시작하면 LocalStack이 otel-collector 버킷을 생성하고 준비 상태를 출력합니다. README는 첫 실행이 실패하면 다시 실행해야 할 수도 있다고 안내합니다. AWS s3.PutObject => 200 로그는 Collector가 버킷에 텔레메트리를 저장했다는 확인 신호입니다.

Collector는 OTLP gRPC 수신 주소를 0.0.0.0:4317로 설정하고, telemetrygen도 여기에 맞춥니다. awss3/metrics exporter에는 리전, 버킷, metrics 접두사를 지정합니다. LocalStack 연결에는 disable_ssl: true, s3_force_path_style: true를 적용하고 endpoint를 LocalStack 서비스로 바꿉니다. README는 일반적인 실제 AWS 연결에서는 이런 재정의가 필요하지 않다고 설명합니다. 메트릭 파이프라인은 otlp receiver와 awss3/metrics exporter를 연결합니다.

저장 결과는 awscli 서비스 안에서 확인합니다. 버킷의 객체 목록에서 파일 하나를 골라 표준 출력으로 읽는 방식입니다. 예시 JSON에는 resourceMetrics 아래 gen이라는 gauge 메트릭과 데이터 포인트가 들어 있습니다. 문서는 이 저장·조회 확인 절차를 제시하며, 비용 절감액이나 처리 성능 측정값은 제공하지 않습니다.

7. telemetry.dev의 LLM 트레이스와 비용 추적

원문: LLM Observability & Telemetry for AI Agents · telemetry.dev

telemetry.dev는 모델 호출, 도구 실행, 검색 단계를 하나의 트레이스로 연결하는 OpenTelemetry 기반 서비스입니다. 제품 소개 페이지는 실패한 호출과 느린 단계를 찾고, 토큰 사용량·추정 비용·지연·오류를 함께 확인하는 기능을 설명합니다. 트레이스는 이름으로 검색하거나 상태, 프레임워크, 세션 등으로 필터링합니다. 오류 유형과 상태를 얼마나 자세히 보여 줄 수 있는지는 계측 코드가 어떤 정보를 보내는지에 달려 있습니다.

연결에는 자체 TypeScript·Python SDK 또는 기존 OTLP/HTTP exporter를 사용할 수 있습니다. 자체 SDK를 추가하지 않고 표준 OTLP 트레이스를 보내는 경로도 지원합니다. TypeScript SDK는 Node와 엣지 런타임의 함수, 모델 호출, 도구, 에이전트를 기록합니다. Python SDK는 데코레이터와 컨텍스트 매니저로 동기·비동기 코드를 계측합니다. 서비스는 지원하는 필드를 정규화해 스팬, 토큰, 비용을 일관된 형태로 표시하며, OTLP 수집 API는 로그와 메트릭도 받습니다.

비용은 수집 시점에 보고된 토큰 사용량과 모델 가격 목록으로 계산합니다. 가격 정보가 있으면 캐시 읽기·쓰기 토큰에 별도 요율을 적용하며, 추론 토큰은 별도로 과금하지 않습니다. 스팬에 명시된 비용이 있으면 그 값을 우선합니다. 일치하는 모델 가격이나 토큰 사용량이 없으면 계산 비용을 제공하지 않습니다. 무료 요금제는 월 30,000 수집 단위, 14일 보존, 프로젝트 1개, 사용자 좌석 2개를 포함합니다. 정규화된 스팬 하나, OTLP 로그 레코드 하나, 메트릭 데이터 포인트 하나가 각각 수집 단위 하나를 사용합니다.

입출력 내용 수집은 기본적으로 켜져 있습니다. 인식 가능한 프롬프트, 응답, 도구 페이로드 필드는 환경별 설정으로 저장 전에 제외할 수 있습니다. 이 설정이 수집 엔드포인트로의 전송까지 막지는 않으며, 로그·오류·사용자 지정 속성의 임의 내용도 제거하지 않습니다. 서비스는 기본 및 프로젝트별 마스킹 패턴을 적용하지만 모든 민감 정보를 잡아내지는 못한다고 명시합니다. 전송 자체를 막으려면 내보내기 전에 계측 코드에서 민감한 내용을 제거해야 한다고 안내합니다.