.svg)
%201.svg)
%201.svg){kind=icon}
담당자가 프로모션 코드를 발송해 드립니다.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
WhaTap AI를 경험해 보세요.
모니터링 비용을 수집 단에서 줄이는 법
관측 데이터는 한 번 백엔드에 들어가면 줄이기 어렵습니다. 이미 저장한 것을 지운다고 지난달 청구서가 바뀌지는 않고, 보존 기간을 당겨도 효과는 몇 주 뒤에야 나타납니다. 그래서 모니터링 비용을 줄일 수 있는 단계는 대개 저장한 다음이 아니라 저장하기 전입니다.
라벨을 하나 더할 때마다 시계열이 몇 배로 늘어나는 구조는 이 시리즈 1편 메트릭 카디널리티란, 모니터링 비용이 갑자기 뛰는 이유에서 다뤘습니다. 원인을 알았다면 다음은 무엇을, 어디서 줄일지입니다.
Grafana Labs가 2026년 3월 발표한 4차 연간 옵저버빌리티 설문(76개국 1,363명 응답)에서도 비용은 복잡도·오버헤드(38%), 노이즈(설문 원문 signal-to-noise, 34%)에 이어 세 번째 고민(31%)으로 꼽혔습니다. 응답자 절반은 2026년 지출이 더 늘 것으로 봤습니다.
텔레메트리 파이프라인은 왜 저장하기 전에 거르나
텔레메트리(telemetry)는 시스템이 동작하면서 자동으로 만들어 내보내는 측정 데이터 전반, 즉 메트릭·로그·트레이스를 통칭하는 말입니다. OpenTelemetry는 그 데이터를 어떻게 계측하고 어떤 형식으로 주고받을지 정한 오픈소스 프로젝트이지, 텔레메트리라는 말 자체와 같은 뜻은 아닙니다.
텔레메트리 파이프라인은 데이터가 생기는 곳에서 저장소로 가는 경로 중간에 둔 처리 계층입니다. 애플리케이션이 데이터를 백엔드로 곧장 전송하는 대신, 중간의 수집기(collector)가 한 번 받아서 걸러내고 다듬은 다음 보내는 방식입니다. OpenTelemetry Collector가 이런 파이프라인 구조를 구현하는 대표적인 도구이지만, 파이프라인이라는 개념 자체는 특정 표준이나 제품에 종속되지 않습니다.
중간 처리 계층을 두는 이유는 단순합니다. 데이터를 가장 싼 지점에서 걸러낼 수 있기 때문입니다. 저장한 뒤에 줄이려면 이미 수집 요금과 저장 요금을 다 낸 상태이고, 애플리케이션 코드에서 줄이려면 서비스마다 배포를 다시 해야 합니다. 중간 계층에서는 설정 하나만 바꾸면 서비스마다 다시 배포하지 않아도 됩니다.
모니터링 비용을 줄이는 다섯 가지 방법과 각각 잃는 것
잃는 것이 적고 적용이 쉬운 쪽부터 손대는 편이 안전합니다.
속성 필터링부터 봅니다
가장 먼저 볼 곳은 메트릭에 붙은 라벨입니다. 값의 종류가 많은 라벨을 하나 붙이면 시계열 전체가 몇 배로 늘어나기 때문에, 라벨 하나를 떼는 것만으로 효과가 크게 나올 때가 있습니다. 사용자 ID나 요청 ID처럼 값이 사실상 무한한 라벨이 메트릭에 붙어 있다면 그 라벨이 1순위입니다.
잃는 것은 그 라벨로 나눠 보는 분석입니다. 다만 그런 세밀한 구분은 대체로 메트릭보다 로그나 트레이스 쪽이 맞습니다.
값이 많은 라벨 가운데 무엇이 실제로 위험한지는 메트릭 카디널리티 편에서 계산 예시와 함께 정리했습니다. 뗄 라벨을 고를 때 같이 보면 판단이 빠릅니다.
로그 필터링은 건수가 많고 잘 열어보지 않는 것부터
디버그 레벨 로그, 헬스체크 접근 기록, 정적 파일 요청 로그처럼 건수는 많고 실제로 열어보는 일은 드문 항목이 있습니다. 건수만 많은 로그부터 수집기 단에서 제외합니다.
주의할 점은 장애 때 필요해지는 로그를 같이 잘라내지 않는 것입니다. 평소에 안 본다는 것과 장애 때 필요 없다는 것은 다릅니다.
보존 티어는 조회 습관에 맞춰 정합니다
최근 데이터는 빠른 저장소에 두고 오래된 것은 저렴한 저장소로 옮기거나 요약본만 남기는 방식입니다. 판단 기준은 실제 조회 습관입니다. 지난 90일 치 원본을 마지막으로 열어본 것이 언제인지 돌아보면 기준이 잡힙니다.
규제나 감사 요건으로 보관 기간이 정해져 있다면 보관과 조회를 분리합니다. 원본은 저렴한 객체 저장소에 두고, 모니터링 백엔드에는 걸러낸 것만 넣는 구성입니다.
테일 샘플링은 다 받아본 뒤에 고릅니다
트레이스 샘플링에는 두 가지 방식이 있습니다. 헤드 샘플링(head sampling)은 트레이스 전체를 보기 전에, 요청이 시작되는 시점에 남길지 정하는 방식입니다. 흔히 쓰는 것은 일정 비율만 남기는 확률 기반이고, 초당 몇 건까지만 남기는 건수 제한이나 상위 서비스의 결정을 그대로 따르는 방식도 여기 들어갑니다. 구현이 간단한 대신, 하필 느렸던 그 요청이 버려질 수 있습니다.
테일 샘플링(tail sampling)은 정해 둔 대기 시간 안에 도착한 스팬을 모아 본 뒤 에러가 났거나 유독 느린 것만 남깁니다. 문제가 있는 요청을 놓치지 않는 대신, 판단할 때까지 트레이스를 메모리에 들고 있어야 해서 수집기 자원을 더 씁니다.
전제가 하나 있습니다. 판단하려면 한 트레이스의 스팬이 모두 같은 수집기 인스턴스에 모여야 합니다. 그래서 수집기를 여러 대로 늘리는 순간, 트레이스 ID 기준으로 같은 인스턴스에 몰아주는 계층을 앞에 한 겹 더 둬야 합니다.
집계 후 저장은 마지막에 검토합니다
원시 데이터 대신 미리 계산한 요약만 남기는 방식입니다. 저장량은 가장 크게 줄지만, 나중에 다른 각도로 다시 집계할 수 없습니다. 무엇을 볼지 이미 정해 둔 지표에만 적용하는 편이 안전합니다.
무엇을 남길지부터 정합니다
줄일 곳을 고르기 전에 반대쪽부터 정해 두는 편이 낫습니다. 장애가 났을 때 반드시 있어야 하는 데이터가 무엇인지 먼저 목록으로 적고, 그 목록에 없는 것부터 줄이는 방식입니다. 순서를 뒤집어 비용부터 보면 지우기 쉬운 것부터 지우게 되는데, 지우기 쉬운 데이터와 없어도 되는 데이터가 늘 같지는 않습니다.
Grafana 설문에서 비용(31%)보다 복잡도(38%)와 노이즈(34%)가 앞선 점도 같이 볼 만합니다. 덜 모으는 일은 모니터링 비용을 줄이면서 노이즈도 함께 걷어냅니다. 헬스체크 로그를 걷어내면 저장 비용이 줄고, 장애 때 확인해야 할 로그 줄 수도 함께 줄어듭니다.
자주 묻는 질문
샘플링했는데 하필 그 요청의 트레이스가 없으면 어떻게 하나요
테일 샘플링을 쓰면 이 위험이 크게 줄어듭니다. 에러가 났거나 임계보다 느린 트레이스는 우선 남기도록 규칙을 잡기 때문입니다. 대신 잃는 것은 정상적으로 빠르게 끝난 요청의 개별 기록입니다. 다만 특정 사용자의 특정 요청을 사후에 지목해 찾아야 하는 요건이 있다면 샘플링 자체가 맞지 않습니다. 그럴 때는 트레이스를 줄이는 대신 전량을 받되 보존 기간을 짧게 가져가는 쪽이 낫습니다.
얼마나 줄이는 게 적정한가요
절감률만 목표로 잡으면 필요한 데이터까지 깎게 되기 쉽습니다. 목표는 비율이 아니라 질문 목록으로 잡는 편이 낫습니다. 우리 팀이 장애 때 실제로 던지는 질문을 열 개쯤 적고, 줄인 뒤에도 그 질문에 답할 수 있는지 확인하는 방식입니다. 답이 막히는 질문이 나오면 그 방법은 과했다는 뜻입니다.
파이프라인 계층을 따로 두면 그 계층을 운영하는 비용은 안 드나요
듭니다. 수집기를 돌릴 자원이 필요하고, 설정이 하나 더 늘어난 만큼 장애 지점도 하나 더 생깁니다. 특히 테일 샘플링은 트레이스를 잠시 쌓아 두기 때문에 메모리를 꽤 쓰고, 수집기를 여러 대로 늘릴 때는 스팬을 같은 인스턴스로 보내는 계층이 앞에 더 필요해 수집기 층이 사실상 두 겹이 됩니다. 모니터링 지출 자체가 크지 않은 규모라면 층을 늘리는 비용이 절감액보다 클 수 있습니다.
로그를 규정상 전부 보관해야 하는데 필터링이 가능한가요
보관 의무와 모니터링 백엔드 적재를 같은 일로 보지 않으면 됩니다. 실무에서 차이가 나는 지점은 검색까지 가능해야 하느냐입니다. 규정이 요구하는 것이 보관인지, 특정 기간 안의 조회 응답인지 먼저 확인하는 편이 낫습니다. 조회 요건까지 있으면 객체 저장소만으로는 부족하고, 인덱스를 따로 두거나 해당 로그 종류만 백엔드에 남기는 예외를 둬야 합니다.
마치며
반드시 남길 데이터를 먼저 정한 다음, 라벨과 로그처럼 되돌리기 쉬운 것부터 조정합니다. 집계 후 저장처럼 되돌릴 수 없는 선택은 마지막에 검토합니다. 다섯 가지를 다 쓸 필요는 없고, 앞의 두세 개만으로 지출이 충분히 내려가는 경우도 있습니다.
여러 시스템의 로그와 메트릭을 한곳에서 수집하며 무엇을 남기고 무엇을 걸러낼지 설계하는 단계라면, 와탭의 로그 모니터링과 공식 문서를 함께 살펴보시기 바랍니다.
더 읽을거리
