promkr 뉴스레터 2026년 9월호

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

1. Polylane의 텔레메트리 기반 PR 위험 평가

원문: How we prevent slop from hitting prod · Vi Tran, Boris Tane · 2026-09-21

Polylane은 코드 변경이 배포된 뒤 실제 서비스에 악영향을 줄지 PR 단계에서 평가하는 기능을 만들었습니다. 테스트와 코드 리뷰가 변경 내용에 집중한다면, 이 기능은 변경이 적용될 시스템의 현재 상태를 조사합니다. 결과는 조사 근거를 붙인 “go” 또는 “no-go” 댓글입니다. 원문의 예시에서는 초당 약 38건의 쓰기가 발생하는 테이블에 CONCURRENTLY 없이 인덱스를 만드는 변경을 찾아, 인덱스 생성 중 쓰기가 차단된다고 알립니다.

평가의 출발점은 클라우드 리소스와 저장소를 연결한 컨텍스트 그래프입니다. Terraform, CloudFormation, Wrangler 파일 등에서 배포 관계를 찾고, PR이 영향을 줄 리소스를 추립니다. 에이전트는 이 정보와 diff, PR 설명, 커밋을 받아 장애로 이어질 인과 경로를 조사합니다. 각 경로에는 코드 위치, 로그, 메트릭, 설정 키 등의 근거를 붙입니다. 실제 텔레메트리로 확인한 경로는 confirmed, 일부 연결을 추정한 경로는 plausible, 반박 근거를 찾은 경로는 refuted로 기록하며, confirmed가 하나라도 있으면 평가를 실패로 처리합니다.

영향 예측에는 자체 호스팅한 Toto-2.0-22m을 사용합니다. 요청률, 오류율, 지연 시간, 큐 깊이처럼 함께 움직이는 시계열을 최대 16개까지 묶어 예측합니다. 예시에서는 시간 단위 관측값 64개로 이후 24시간의 중앙값과 p10–p90 구간을 구합니다. 에이전트는 중앙값뿐 아니라 예측 구간이 위험 판단의 임계값을 넘는지도 살핍니다. 저자들은 이 기능이 가장 실험적인 부분이며 효과를 계속 측정 중이라고 밝힙니다.

PR 검사에 허용한 시간은 2~3분이지만, 초기 구현은 중앙값이 거의 7분이고 20분까지 걸리기도 했습니다. Polylane은 에이전트 턴을 최대 30단계로 제한하고 남은 단계를 모델에 알렸습니다. 새 커밋이 오면 진행 중인 평가를 취소하고 새 대화를 시작하되, 완료된 평가가 있으면 후속 커밋의 작은 diff와 기존 결과를 재사용합니다. 저자들은 개선 후 지연 시간이 목표 범위에 들어왔다고 보고합니다. 고객당 주당 2.3건이라는 예방 실적은 위험 지적, 엔지니어의 수정, 재평가 통과, PR 병합을 모두 충족한 건을 세는 Polylane의 자체 지표입니다.

2. ClickHouse의 PromQL과 TimeSeries 엔진 공개

원문: Introducing ClickHouse’s new TimeSeries Engine: Your drop-In Prometheus replacement · James Cunningham · 2026-09-15

ClickHouse는 ClickHouse Cloud의 PromQL과 TimeSeries 테이블 엔진, ClickStack의 PromQL 지원을 private preview로 공개했습니다. 기존 PromQL을 SQL로 다시 작성하지 않고 Prometheus 메트릭을 ClickHouse에 저장하고 질의하는 기능입니다. 이번 공개 범위는 저장과 질의입니다. 기존 Prometheus 서버, 에이전트, OpenTelemetry Collector와 스크레이프 설정은 유지하며, 규칙 평가 기능은 추후 발표 대상으로 남겨 두었습니다.

수집기는 Prometheus remote-write v1으로 메트릭을 보내고, TimeSeries 테이블은 메트릭 메타데이터와 레이블 집합, 타임스탬프가 붙은 값을 저장합니다. Grafana 같은 도구는 Prometheus HTTP API 호환 인터페이스에 연결합니다. Prometheus의 remote-read 백엔드로 쓰거나, clickhouse-client의 promql dialect 및 SQL의 prometheusQuery, prometheusQueryRange 함수로 질의할 수도 있습니다. ClickHouse는 이 경로들이 서버 내부의 같은 PromQL 구현을 사용한다고 설명합니다.

저자는 PromQL 지원을 단순한 문법 변환으로 보지 않습니다. 스크레이프 간격의 흔들림과 누락, counter 재시작, histogram 버킷의 재결합처럼 데이터 해석에 필요한 조건을 보존해야 하기 때문입니다. ClickHouse는 이 책임을 서버가 맡아 기존 대시보드와 질의의 의미를 유지하겠다고 밝힙니다. 발표 시점의 PromQL 지원 범위는 85%를 넘으며, 더 많은 대시보드가 동작하도록 함수와 연산자 지원을 늘릴 계획입니다.

ClickStack에서는 차트 편집기에 PromQL을 직접 입력하고 차트, 대시보드, 시계열·스칼라 질의를 사용할 수 있습니다. 외부 Prometheus 호환 엔드포인트로 질의를 전달하거나 변수를 넣어 메트릭·로그·트레이스의 필터를 맞추는 기능도 제공합니다. 시각적 PromQL 빌더와 PromQL 알림은 아직 지원하지 않습니다. TimeSeries 테이블에는 remote-write 경로로 수집해야 하며, ClickStack의 기본 OTLP 경로는 이 테이블을 채우지 않습니다. Native Histograms, 다운샘플링, Recording Rules와 Alerting Rules, remote-write v2 등은 향후 지원 계획에 포함됩니다.

3. LLM 시대 옵저버빌리티의 빠른 피드백 경쟁

원문: It’s The End Of Observability As We Know It (And I Feel Fine) · Austin Parker · 2025-06-09

Honeycomb의 Austin Parker는 옵저버빌리티 도구의 경쟁 기준이 바뀐다고 주장합니다. 기존 도구는 방대한 텔레메트리를 사람이 이해할 수 있도록 대시보드, 알림, 샘플링으로 압축해 왔습니다. 이제 LLM이 데이터를 직접 조사하면 보기 좋은 그래프와 쉬운 계측만으로는 차별화하기 어렵다는 설명입니다. 저자는 LLM이 분석을, OpenTelemetry가 계측을 보편적인 기능으로 만든다고 봅니다.

근거로 제시한 것은 Honeycomb 내부 시연입니다. 저자는 며칠 동안 만든 에이전트에 Claude Sonnet 4와 Honeycomb MCP 서버를 연결하고, 프런트엔드 서비스에서 약 4시간마다 나타나는 지연 급증을 조사하도록 요청했습니다. 에이전트는 추가 프롬프트나 훈련 없이 80초 동안 도구를 8번 호출해 조사 결과를 냈습니다. 저자가 밝힌 비용은 60센트이며, 조사 과정은 사람이 BubbleUp으로 이상 구간과 기준 구간을 비교하는 흐름과 비슷했습니다.

부록의 에이전트 출력은 지연이 checkout 작업에 집중됐다고 보고합니다. 최근 24시간의 느린 checkout 작업 485건과 Python 요청 라이브러리, 반복되는 사용자 및 장바구니 정보를 근거로 부하 테스트나 합성 트래픽일 가능성을 제시했습니다. 부하 테스트 여부는 확인할 항목으로 남겼습니다. 이 사례에서 저자가 강조하는 것은 사람이 시각화를 따라가며 수행하던 조사 과정을 도구 호출형 에이전트가 한 번의 요청으로 진행했다는 점입니다.

저자는 앞으로 개발과 운영의 모든 단계에서 빠르고 짧은 피드백 주기가 중요해진다고 주장합니다. AI가 관측 결과를 바탕으로 수정안을 제안하거나, 사용자 영향을 조사해 사람의 승인을 받거나, 더 높은 자율성으로 소프트웨어를 작성하고 최적화하는 형태를 예상합니다. 사람이 사라진다는 주장은 하지 않으며, 산업의 구체적인 미래 모습도 단정하지 않습니다. 그가 제시한 경쟁 조건은 1초 미만의 질의 성능, 통합 데이터 저장소, 사람과 AI가 함께 작업하는 흐름입니다.

4. LLM 이전 AIOps의 한계와 P99의 실용성

원문: Lessons from the pre-LLM AI in observability: anomaly detection and AIOps vs P99 · Jacek Migdal · 2025-02-24

Quesma의 Jacek Migdal은 LLM 이전의 옵저버빌리티 AI를 돌아보며, 범용 이상 탐지의 시연 효과와 현장 효용 사이에 차이가 있었다고 주장합니다. 여러 벤더가 이상 탐지를 도입하고 AIOps라는 용어가 확산됐지만, 글에서 인용한 2021년 조사에서는 SRE의 12%만 이를 정기적으로 사용했습니다. 매우 가치 있다고 응답한 비율은 7.5%였고, 거의 40%는 전혀 사용하지 않았습니다. 이 수치는 당시 조사 결과로 제시됩니다.

저자는 실제 시스템에 이상 현상이 많아도 대부분은 중요하지 않다는 점을 문제로 짚습니다. 알고리즘이 이들을 찾아내면 오탐과 알림 피로가 늘어나지만, 실제로 중요한 문제는 일회성 사건이나 예외 상황인 경우가 많습니다. 이런 문제를 해석하려면 깊은 맥락이 필요하다는 설명입니다.

대안의 출발점으로는 요청률, 오류율, 지연 시간으로 구성한 RED 메트릭과 요청 지연의 P99를 제시합니다. 저자는 통계 기반 알림이 불투명한 모델보다 이유를 설명하기 쉽고, 영향을 받은 사용자와 요청을 추적할 출발점도 준다고 평가합니다. P99만으로 충분하다는 주장은 아닙니다. 대부분의 기업에는 더 넓은 SLO와 오류 예산 관리가 필요하며, 이를 큰 규모에서 일관되게 유지하기 어렵다고 설명합니다.

유용했던 ML 기능으로는 반복 로그의 패턴 그룹화, 과거 데이터와 추세에 따른 자동 임계값, 특정 상황의 예측 알림을 꼽습니다. 디스크 사용량이 임의의 비율을 넘었는지보다 향후 48시간 안에 가득 찰지를 알리는 예시가 여기에 해당합니다. 이런 기능은 점차 AI라는 이름 대신 일상적인 도구 기능으로 자리 잡았다는 평가입니다. 저자는 제품 평가에서도 화려한 시연보다 고객 자신의 데이터로 수행한 검증, 실제 업무에 자연스럽게 정착하는지 여부, 갱신 시점의 기능 사용률을 보라고 권합니다.

5. 컨테이너 이미지 태그 기반 Grafana 배포 표시

원문: The Easiest Way to Track Kubernetes Deployments in Grafana · Netanel Avraham · 2025-05-11

Netanel Avraham은 애플리케이션이나 CI/CD 파이프라인을 수정하지 않고 Grafana에 Kubernetes 배포 시점을 표시하는 방법을 소개합니다. 장애 조사 중 메트릭 변화가 새 버전 배포와 맞물리는지 확인하려는 목적입니다. 별도의 배포 기록 코드를 유지하는 대신, 컨테이너 이미지 정보에 관한 Prometheus 질의를 Grafana annotation에 연결합니다.

데이터는 kube-state-metrics가 노출하는 kube_pod_container_info에서 가져옵니다. 원문의 질의는 pod, namespace, container 레이블로 대상을 선택한 뒤 label_replace로 image의 버전 태그를 추출해 version 레이블에 넣습니다. 이어서 max를 version, container별로 집계하고 changes() 결과가 0보다 큰지 검사합니다. 저자는 이 질의로 새 버전 배포를 감지하고 annotation을 자동으로 추가한다고 설명합니다.

Grafana 설정 위치는 대시보드 설정의 Annotations 탭입니다. annotation 제목에는 https://github.com/your-org/your-repo/releases/tag/{{version}}을 대상으로 하는 링크를 넣습니다. 질의에서 추출한 version이 링크에 들어가므로, 그래프에 표시된 배포 지점에서 해당 GitHub release로 이동할 수 있습니다. 원문은 배포 직후 요청률이 떨어지는 예시로 메트릭과 배포 기록을 함께 보는 용도를 보여 줍니다.

이 방법은 kube-state-metrics의 컨테이너 정보와 이미지 버전 태그를 사용합니다. 적용 절차는 대상에 맞게 질의의 레이블을 조정하고 Grafana annotation을 추가하는 것입니다. 저자가 제시한 효과는 배포 시점을 메트릭 옆에 표시하고, 관련 release 정보를 바로 확인하며, 이후 배포에도 annotation을 자동으로 남기는 데 있습니다.

6. Prometheus 알림 규칙의 필드와 운영 기준

원문: How to Write Effective Prometheus Alert Rules · Squadcast · 2025-01-15

Squadcast는 Prometheus 알림 규칙의 필드, PromQL 조건식, 예제와 운영 시 고려할 점을 설명합니다. 규칙은 수집한 메트릭을 조건식으로 평가하고, 필요한 지속 시간과 대응 정보를 함께 지정하는 방식입니다. 글은 새 팀원도 알림의 의미를 이해할 수 있도록 이름과 설명을 작성하고, 적절한 심각도를 붙이며, 관련 규칙을 묶어 관리하라고 권합니다.

조건식은 메트릭과 레이블 필터, 비교 연산자로 시작합니다. 더 복잡한 조건에는 avg, sum, min, max 같은 집계 함수와 and, or, unless, 벡터 매칭용 on, ignoring을 소개합니다. HTTP 오류 예제는 최근 5분간 상태 코드 500 요청의 초당 발생률을 전체 요청의 초당 발생률로 나눕니다. 이 비율이 5%를 넘는 조건에 for: 5m을 붙이고, severity: critical과 사람이 읽을 설명을 지정합니다.

글은 for를 너무 짧게 설정하면 일시적인 급등에도 알림이 많아지고, 너무 길면 실제 문제의 발견이 늦어진다고 설명합니다. 잡음이 많은 메트릭은 오탐이나 미탐을 만들 수 있으며, 메트릭과 규칙이 늘면 자원 사용량과 관리 부담도 커집니다. 알림 그룹화, 중복 제거, 전달 경로 지정에는 Alertmanager를 추가 구성 요소로 제시합니다. 다른 서비스의 동작에 좌우되는 문제는 개별 서비스 메트릭만으로 정확히 판단하기 어렵다는 한계도 다룹니다.

운영 절차로는 배포 전 규칙 테스트, Alertmanager 동작 확인, 시스템 변화에 맞춘 정기적인 규칙 갱신을 권합니다. 대응 시간을 줄이기 위한 자동화와 유사 사고에 사용할 runbook 작성도 포함합니다. Squadcast는 자사 도구를 관련 팀으로 알림을 전달하고 회고, SLO, 오류 예산을 관리하는 선택지로 소개합니다. 글에서 다루는 주요 규칙 필드는 다음과 같습니다.

• alert: 알림을 식별하는 이름
• expr: 알림 조건을 평가하는 PromQL 식
• for: 조건이 참으로 유지되어야 하는 시간
• labels: 심각도와 대상 서비스 등 추가 정보
• annotations: 요약과 문제 설명 등 사람이 읽는 정보