promkr 뉴스레터 2026년 1월호

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

1. Grafana Labs의 2026년 옵저버빌리티 전망

원문: 2026 observability trends and predictions from Grafana Labs: unified, intelligent, and open · Maggie Cornejo, Alexa Becker · 2026-01-05

Grafana Labs는 IT 의사결정권자 150명과 Grafana Cloud 엔지니어의 의견을 바탕으로 2026년 옵저버빌리티 동향을 전망합니다. 첫 번째 변화는 도구 통합보다 조직의 운영 방식 통합입니다. 글이 인용한 2025년 조사에서 경영진의 73%는 통합 옵저버빌리티를 도입했거나 전환 중이라고 답했습니다. 도구 통합을 중요하게 여긴 비율은 77%였지만, 매우 성공적이었다는 응답은 14%였습니다. 회사는 도구를 모두 통일하기에 앞서 팀이 데이터와 업무 흐름, 목표를 공유하는 방식이 기본이 될 것으로 봅니다.

데이터 수집량보다 보존할 데이터의 가치가 중요해진다는 전망도 제시합니다. Grafana Labs는 Adaptive Telemetry가 중요한 데이터를 유지하면서 보존량을 50%~80% 줄인다고 설명합니다. SLO는 보고와 알림을 위한 지표에서 업무 우선순위를 결정하는 기준으로 이동할 것으로 예상합니다. 조사에서 조직의 86%가 SLO를 사용하고 있지만, 대부분은 여전히 수동적인 지표로 취급한다는 진단입니다. 앞으로는 스프린트 계획과 경영진의 판단에 신뢰성 목표를 반영할 것이라고 봅니다.

AI는 쿼리 생성과 알림 분류를 넘어 장애 조사, 맥락 요약, 수정안 제안에 참여하는 자율 에이전트로 발전할 전망입니다. 2025년에는 조직의 84%가 옵저버빌리티에 AI를 적용하는 방안을 탐색하거나 시험했다고 전합니다. AI 자체도 관측 대상이 됩니다. 회사는 모델에 공급되는 데이터의 출처, 변환, 출력 사이 관계를 이해하는 일이 중요해진다고 설명합니다. 예측의 최신성과 환각 비율을 추적하는 모델 SLO가 등장할 수 있다는 엔지니어의 전망도 담았습니다.

재무·보안·운영 팀이 공통 텔레메트리를 의사결정에 쓰면서 옵저버빌리티의 담당 범위도 넓어질 것으로 예상합니다. OpenTelemetry는 중복 계측과 벤더별 SDK 작업을 줄이는 기본 선택지로 자리 잡는다는 전망입니다. 마지막으로 AI와 클라우드의 탄소 배출을 비용·성능과 함께 측정하는 흐름을 제시합니다. 근거로 인용한 FinOps Foundation의 2025년 보고서에서는 유럽 FinOps 조직의 53%가 탄소 배출을 보고하고 있었습니다.

2. 시그널 해석의 부족과 옵저버빌리티의 미래

원문: Observability’s Past, Present, and Future · Sherwood’s Blog · 2026-01-05

저자는 옵저버빌리티의 문제를 데이터 부족보다 데이터를 이해하고 추론하는 능력의 부족에서 찾습니다. 계측, 대시보드, 알림에 많은 노력을 들였는데도 장애 탐지와 원인 분석, 서비스 신뢰성의 개선이 그 노력에 비례하지 않는다는 주장입니다. 시그널을 만드는 능력은 크게 늘었지만, 이를 해석하고 신뢰성 개선으로 연결하는 능력은 조금 나아지는 데 그쳤다고 진단합니다.

글은 이 문제를 2010년대 소프트웨어의 변화에서 출발해 설명합니다. 클라우드, 컨테이너, 마이크로서비스가 확산되면서 개인이 애플리케이션 전체를 이해하기 어려워졌습니다. CI/CD는 변경 배포 빈도를 높였고, 서비스 사이 상호작용에서 발생하는 실패를 미리 예측하거나 테스트하기도 힘들어졌습니다. 저자는 분산 추적이 이런 애플리케이션을 디버깅하는 도구를 제공했고, 옵저버빌리티는 새로운 조건에서 신뢰성을 생각하는 틀을 제공했다고 서술합니다. 이후 계측과 대시보드, SLO, 런북, 사후 분석이 늘어나면서 수단이던 옵저버빌리티 자체가 목적이 되었다고 비판합니다.

현재의 문제로는 오래 걸리는 계측, 갱신되지 않는 대시보드, 잘못 울리는 모니터, 맥락이 부족한 알림을 듭니다. 표준화된 로그와 이름 규칙을 적용하고 알림을 세심하게 조정한 팀도 실제 실행 중인 애플리케이션을 정확하게 이해하기 어렵다는 설명입니다. 저자가 지적하는 간극은 도구나 절차를 성실히 갖추는 것과 보유한 데이터에서 의미를 읽어내는 것 사이에 있습니다.

미래 전망에서는 AI가 코드 작성 비용을 낮추고 기능 출시와 코드베이스 확대를 가속한다고 주장합니다. 더 많은 사람이 애플리케이션을 만들면서 유지·운영해야 할 소프트웨어도 급증한다는 논지입니다. 저자는 이 복잡성에 대응할 수단으로 옵저버빌리티를 지목하지만, 현재의 형태로는 충분하지 않다고 봅니다. 글은 새로운 옵저버빌리티의 필요성을 제기하는 데서 끝나며, 구체적인 제품 설계나 구현 방안은 제시하지 않습니다.

3. Grafana Mimir 3.0의 읽기·쓰기 분리와 쿼리 엔진

원문: Grafana Mimir 3.0 release: performance improvements, a new query engine, and more · Dimitar Dimitrov, Nick Pillitteri, Vladimir Varankin · 2025-11-03

Grafana Mimir 3.0은 메트릭 수집과 조회가 서로 영향을 주는 문제를 줄이고, 쿼리의 메모리 효율을 높인 릴리스입니다. Grafana Labs는 대규모 Mimir 클러스터를 직접 운영하고 고객의 운영 경험을 살펴본 결과를 설계에 반영했다고 설명합니다. 이번 개선은 Mimir 기반 관리형 서비스인 Grafana Cloud Metrics에도 제공됩니다. 회사 내부의 대규모 클러스터에서는 성능과 신뢰성을 높이면서 자원 사용량이 최대 15% 감소했다고 밝힙니다.

이전 버전에서는 ingester가 읽기와 쓰기 경로에 모두 참여해 무거운 쿼리가 수집 성능을 떨어뜨릴 수 있었습니다. 새 설계는 Apache Kafka를 수집과 조회 사이의 비동기 버퍼로 사용합니다. 기반 구성 요소인 ingest storage가 읽기와 쓰기를 분리하므로 각 경로를 독립적으로 확장할 수 있습니다. Grafana Labs의 내부 시험에서는 무작위 ingester 장애로 읽기 경로에 장애가 생길 확률도 크게 줄었습니다. 특히 ingester 장애가 발생하기 시작하는 초기 구간에서 감소 폭이 컸다고 설명합니다.

Mimir Query Engine인 MQE는 Mimir 2.17에서 도입됐으며, 3.0에서는 기본 쿼리 엔진입니다. 기존 Prometheus PromQL 엔진이 샘플을 일괄 처리하는 방식과 달리, MQE는 스트리밍 방식으로 각 단계에 필요한 샘플만 불러옵니다. Grafana Labs는 이 방식이 최대 메모리 사용량을 최대 92% 줄이고, 부하가 큰 상황의 쿼리 속도와 신뢰성을 개선한다고 설명합니다. Grafana Labs에 따르면 MQE는 PromQL과 100% 호환됩니다.

업그레이드에는 설계 변경을 고려한 준비가 필요하다고 원문은 안내합니다. 기존 방식의 Mimir 클러스터 외에 두 번째 클러스터를 배포·설정할 수 있어야 합니다. Prometheus나 OpenTelemetry Collector 같은 쓰기 클라이언트는 여러 엔드포인트로 데이터를 보낼 수 있어야 하고, Grafana 같은 읽기 클라이언트는 새 엔드포인트로 전환할 수 있어야 합니다. 양쪽 클러스터의 Helm 또는 Jsonnet 설정을 수정할 수 있는 것도 전제입니다.

4. Keep의 알림 통합과 워크플로 자동화

원문: Keep - Open-source AIOps platform · Keep

Keep은 제품 소개 페이지에서 여러 시스템의 알림과 이벤트를 모아 필요한 정보를 보강하고 대응 작업을 자동화하는 플랫폼으로 소개됩니다. 페이지 상단의 공지 배너는 Keep이 Elastic과 함께한다는 소식을 알립니다. 연결 대상은 모니터링 도구뿐 아니라 사고 대응, 티켓, 소스 관리, 변경 관리, CMDB 시스템까지 포함합니다. Keep은 양방향 연동으로 알림과 시그널의 상태를 동기화한다고 밝힙니다. 페이지에는 Datadog, CloudWatch, Grafana, PagerDuty, GCP Monitoring 등이 연동 대상으로 제시됩니다.

수집한 알림은 공통 화면에서 조회합니다. Common Express Language로 데이터를 검색하고 조건별로 나누어 분석하며, 규칙 기반 그룹화로 알림을 묶습니다. 자동화 엔진은 GitHub Actions와 유사한 YAML 기반 방식에 UI를 더한 형태로 소개됩니다. MySQL 조회 결과를 알림에 붙이거나, Jira 티켓을 갱신하거나, Python 스크립트를 실행하는 작업을 구성할 수 있습니다. 통합, 수집·조회, 워크플로 자동화는 OSS·Cloud·Enterprise에 제공하는 단계로 표시되어 있습니다.

AI 기반 알림 상관관계 분석은 Keep Enterprise 전용 기능으로 구분됩니다. Keep은 매일 수천 건의 알림을 처리하는 기업을 대상으로 과거 사고와 지식 베이스를 활용해 알림 사이 관계를 찾는다고 설명합니다. 지속적인 피드백으로 성능을 개선한다는 설명도 포함되어 있습니다. Enterprise 소개에는 AI 기반 요약 기능도 명시되어 있어, 오픈소스 알림 관리 기능과 제공 범위가 구별됩니다.

배포 방식은 직접 호스팅하는 오픈소스 도구, Keep이 배포를 관리하는 Cloud, 클라우드와 온프레미스를 지원하는 Enterprise로 나뉩니다. 기존 연동 기능을 선택하거나 직접 맞춤 연동을 만들 수 있습니다. 페이지는 알림 소음과 대응 부담을 줄이는 효과를 주장하지만, 이를 입증하는 측정 조건이나 성능 수치는 제시하지 않습니다.

5. Rails Mini Profiler의 요청별 성능 분석

원문: Rails Mini Profiler · hschne

Rails Mini Profiler의 README는 특정 Rails 요청이 느린 이유를 찾는 개발 도구를 소개합니다. 애플리케이션의 요청을 자동으로 프로파일링하고, 저장된 요청을 검색하거나 상세 실행 내역을 살펴볼 수 있습니다. 상세 화면에서는 데이터베이스와 뷰 렌더링에 사용한 시간을 확인하고 개별 트레이스를 좁혀 봅니다. README는 지속적인 성능 모니터링보다 요청의 지연 원인 분석과 개발자 사용 경험에 초점을 맞췄다고 설명합니다.

설치는 Gemfile에 rails_mini_profiler를 추가한 뒤 gem 설치, 설치 생성기 실행, 생성된 마이그레이션 검토와 적용 순서로 진행합니다. 생성기는 초기화 파일과 /rails_mini_profiler 경로를 추가합니다. 프로파일링 정보는 기본적으로 애플리케이션 데이터베이스에 저장하며, 별도 데이터베이스와 테이블 이름을 설정할 수 있습니다. 오래된 기록을 자동으로 지우는 기능은 없어 README는 주기적인 정리 작업을 추가하도록 권고합니다.

Flamegraph 기록에는 stackprof가 필요하고, 화면 렌더링에는 Speedscope를 사용합니다. 기본 설정은 요청마다 Flamegraph를 기록하므로 상당한 성능 저하가 발생할 수 있다고 경고합니다. flamegraph_enabled와 flamegraph_sample_rate로 동작을 조정하고, 요청 매개변수 rmp_flamegraph로 개별 요청의 설정을 바꿀 수 있습니다. README에 따르면 StackProf는 동시 요청을 처리하지 못해 일부 요청의 Flamegraph 기록이 생략될 수 있습니다.

프로파일링 정보는 사용자 ID별로 분리되며 기본 식별값은 IP 주소입니다. user_provider나 명시적인 사용자 승인 코드로 식별 방식을 바꿀 수 있습니다. Rails 이외의 애플리케이션은 지원하지 않고, API 전용 Rails 애플리케이션은 추가 설정이 필요합니다. README는 프로젝트가 초기 개발 단계여서 호환성을 깨는 변경이 반복될 수 있으며, 사전 릴리스 기간에는 업그레이드 마이그레이션을 제공하지 않는다고 명시합니다.

6. DuckDB를 이용한 NGINX 로그 분석

원문: Using DuckDB to analyze NGINX logs · 2024-10-27

저자는 DDoS 대응 중 Cloudflare의 사용자 정의 WAF 규칙을 개선하려고 수백만 건의 NGINX 로그를 분석했습니다. 이 글은 Loki에 저장된 로그를 내려받아 DuckDB에서 SQL로 집계한 과정을 설명합니다. 분석에 앞서 ingress-nginx의 log-format-upstream으로 로그를 JSON 형식으로 바꾸고, log-format-escape-json으로 변수 값이 JSON에 맞게 이스케이프되도록 설정했습니다. 정규식으로 기본 로그 형식을 파싱하는 작업을 줄이기 위한 선택입니다.

사용자 ID가 포함된 경로를 같은 엔드포인트로 묶는 작업은 NGINX에서 처리했습니다. 저자는 DuckDB에서 원하는 URI 정규화 방법을 찾지 못해 ngx_http_map_module로 특정 경로를 공통 형태로 치환했습니다. 원래 URI와 정규화한 URI를 로그에 함께 넣는 방식입니다. 이 방식은 동작하지만 확장성이 좋지 않다고 평가합니다. Loki 로그는 logcli로 원시 JSON 형태로 내려받았으며, 예제에서는 시간을 15분 단위로 나누고 최대 병렬 작업자 수를 100으로 설정했습니다.

DuckDB에서는 read_json으로 분할 파일을 읽어 logs 테이블을 만들었습니다. 자동 추론에 모두 맡기지 않고 시간은 TIMESTAMP, 상태 코드는 INT처럼 열의 자료형을 지정했습니다. 저자가 다룬 하루치 NGINX 로그는 약 6천만 행이었고, 유휴 상태에서 메모리를 약 8GB 사용했습니다. 더 긴 기간을 분석할 때는 더 큰 메모리를 갖춘 장비를 선택해야 하며, 그렇지 않으면 DuckDB가 중단될 수 있다고 경험을 전합니다.

분석 쿼리는 IP별 분당 최대 요청 수, 특정 호스트에 요청을 많이 보낸 IP, 개별 IP가 접근한 경로를 집계합니다. 분당 요청 수는 실제 고객을 잘못 제한할 가능성을 줄이면서 Cloudflare 레이트 리밋 값을 정하는 데 사용했습니다. 특정 IP의 경로 목록에서는 취약한 엔드포인트를 찾는 스캐너로 보이는 패턴을 확인했습니다. 저자는 이번 작업을 임시 분석으로 설명하며, 향후 이런 탐지를 자동화하려고 OpenSearch Security Analytics를 평가 중이라고 덧붙입니다.

7. DDoS 대응에서 확인한 차단 효과와 오탐

원문: We got DDoSed · 2024-10-27

저자는 일요일 밤 10시 무렵 ingress-nginx Pod가 반복해서 중단되는 알림을 받았습니다. 처음에는 고객 증가로 판단해 노드와 Pod 복제본을 늘렸지만 효과가 없었습니다. 로드밸런서의 새 연결 지표에서 1분 만에 평소의 10배 트래픽이 유입된 사실을 확인한 뒤 DDoS로 판단했습니다. nginx.ingress.kubernetes.io/limit-rps로 요청을 제한해도 Pod는 안정되지 않았습니다. 이 사례에서는 요청을 받아 세고 차단하는 작업 자체를 인프라가 감당하지 못했습니다.

Cloudflare는 DNS에 사용하고 있었지만 프록시가 꺼져 있었습니다. 프록시를 켠 뒤에도 기본 TTL인 300초에 따른 전환 지연이 있었고, Under Attack 모드의 효과는 저자도 확신하지 못했습니다. Managed rules 역시 특정 API 경로를 겨냥한 공격을 차단하지 못했습니다. 서비스 대상 국가만 허용하자 로드밸런서 요청은 약 절반으로 줄었지만 과부하는 계속됐습니다. 공격 요청에 공통으로 나타난 쿼리 매개변수를 차단한 뒤에야 트래픽이 정상 수준으로 돌아왔습니다.

후속 공격에서는 매개변수가 바뀌었습니다. 하지만 저자는 첫 공격 뒤 정상 요청을 분석해 Referer, X-Requested-With, User-Agent 기반 규칙을 미리 만들어 둔 상태였습니다. 저자는 이 규칙들이 당시 가장 효과적이었다고 평가하면서, 공격자가 정상 요청을 관찰해 값을 위조할 수 있다는 한계를 명시합니다. 알려진 공격 IP 차단은 공격자가 IP를 바꾸면 효과를 잃었습니다. 사용자 정의 규칙 뒤에는 IP별 레이트 리밋을 배치했습니다. 글 작성 당시 무료 요금제의 집계 구간은 10초였으며, 저자는 더 긴 구간이 정상 사용자의 순간적인 요청 증가를 잘못 차단하는 일을 줄이는 데 도움이 된다고 설명합니다.

오탐과 설정 충돌도 기록했습니다. 데이터센터 IP에서 모바일 User-Agent가 보인다는 이유로 차단한 주소는 고객 요청을 중계하는 자사 NAT Gateway였습니다. 이후 알려진 자사 IP 목록을 만들어 차단을 건너뛰게 했습니다. 미국발 요청 중에는 접근성 기능에 쓰이는 Google-Read-Aloud도 있었습니다. 또 external-dns가 Cloudflare 프록시를 반복해서 끄는 문제를 발견했습니다. 원문은 Ingress에 external-dns.alpha.kubernetes.io/cloudflare-proxied: "true"를 설정하는 방법을 안내하며, 같은 호스트를 가리키는 모든 Ingress에 적용해야 설정 충돌을 피할 수 있다고 설명합니다.

8. AWS RDS 인스턴스를 찾는 Prometheus HTTP SD

원문: Prometheus Service Discovery for AWS RDS · contember

이 저장소의 README는 AWS RDS 클러스터 인스턴스를 Prometheus의 HTTP Service Discovery 대상으로 제공하는 Go 도구를 소개합니다. RDS 자동 확장으로 인스턴스가 달라지는 상황에서 사용자 CPU 시간이나 연결 수 같은 인스턴스별 메트릭을 측정하려는 용도입니다. 서비스는 클러스터를 탐색하고 /discovery에서 Prometheus HTTP SD와 호환되는 JSON을 반환합니다. 상태 점검용 경로는 /.health입니다.

탐색할 클러스터는 SCRAPER_0_CLUSTER_ARN, SCRAPER_1_CLUSTER_ARN처럼 번호를 붙인 환경 변수에 ARN을 지정합니다. 번호를 늘려 여러 클러스터를 등록하며, 여러 리전과 계정의 클러스터 탐색을 지원합니다. 수신 포트는 PORT로 설정하고 기본값은 8080입니다. AWS 자격 증명은 필요한 경우 설정합니다. ECS와 EKS의 컨테이너 자격 증명도 사용할 수 있습니다. README는 해당 RDS 클러스터가 있는 리전에서 rds:DescribeDBInstances 권한을 부여하도록 안내합니다.

Prometheus Postgres Exporter 연동 예제는 /discovery를 http_sd_configs에 등록하고, 메트릭 경로를 /probe로 설정합니다. 발견한 __address__를 __param_target으로 옮긴 뒤 같은 값을 instance 라벨에 넣습니다. 마지막에는 __address__를 Postgres Exporter 주소로 바꿉니다. 이 구성에서 발견된 RDS 인스턴스 주소는 탐사 대상 매개변수가 되고, 실제 스크레이프 요청은 Exporter로 전달됩니다.

미리 빌드한 Docker 이미지는 Docker Hub에 제공되며, README에 명시된 지원 아키텍처는 ARM입니다. 다른 아키텍처가 필요하면 이슈를 열도록 안내합니다.