옵저버빌리티란? 모니터링과 다른 점과 시작 방법
요약
옵저버빌리티는 시스템이 이미 내보내는 로그, 메트릭, 트레이스만으로 처음 보는 장애의 원인까지 설명할 수 있는 능력입니다. 모니터링은 알려진 장애 유형을 감시하고, 옵저버빌리티는 새로운 질문에 답합니다. 핵심은 고카디널리티 필드를 보존하고 신호를 상관시키는 것이며, 작은 팀은 핵심 경로 하나부터 계측을 시작하면 됩니다.
옵저버빌리티란 시스템이 이미 내보내는 텔레메트리만으로, 아무도 예상하지 못한 장애를 포함해 시스템이 왜 이상하게 동작하는지 설명할 수 있는 능력입니다. 모니터링은 체크아웃 지연 시간이 800ms를 넘었다는 사실을 알려 줍니다. 옵저버빌리티는 그 지연이 어떤 테넌트, 어떤 의존성, 어떤 배포 때문인지 새벽 3시에 새 코드를 배포하지 않고도 묻게 해 줍니다.
장면을 하나 떠올려 보십시오. 알림이 울립니다. 결제 API의 p99가 180ms에서 1.4초로 올랐습니다. 대시보드의 CPU, 메모리, 에러율은 모두 초록색입니다. 미리 만들어진 패널은 모두 서비스가 정상이라고 말하지만, 고객들은 아니라고 말합니다. 그 다음 10분 동안 무엇을 하느냐가 이 글 전체의 주제입니다.
정의를 도구보다 먼저 따져야 하는 이유
이 용어는 제어 이론에서 왔습니다. 외부로 나오는 출력만으로 내부 상태를 추론할 수 있으면 그 시스템은 관찰 가능하다고 봅니다. 소프트웨어가 이 개념을 빌려왔고, 벤더들이 이를 늘려서 "대시보드 제품"이라는 뜻이 되어 버렸습니다. 그 확장된 의미는 무시하는 편이 낫습니다.
엔지니어링 팀에게 더 유용한 정의는 더 좁습니다. 시스템이 프로덕션에서 동작에 관한 새로운 질문에 새 계측 코드를 배포하지 않고도 답할 수 있으면 관찰 가능한 것입니다. 핵심 단어는 "새로운"입니다. 임계값 알림은 지난 분기에 누군가 적어 둔 질문에 답합니다. 관찰 가능한 시스템은 지금 여러분이 던지는 질문에 답합니다.
이것은 순수성 검사가 아닙니다. 완벽하게 관찰 가능한 시스템을 가진 팀은 없고, 목표는 점수가 아닙니다. 목표는 "무언가 잘못되었다"에서 "이 변경이 원인이다"까지 가는 길을 짧게 만드는 것입니다. 탐지까지 걸리는 평균 시간과 원인을 이해하기까지 걸리는 평균 시간은 서로 다른 숫자인데, 대부분의 팀은 앞의 것만 추적합니다.
모니터링과 옵저버빌리티는 무엇이 다른가
모니터링은 이미 알고 있는 장애 유형에 대한 점검 모음입니다. 5분 동안 CPU 90% 초과, 에러율 1% 초과, 큐 깊이 10,000 초과 같은 것입니다. 저렴하고 안정적이며, 여전히 필요합니다. 옵저버빌리티가 그것을 대체하지는 않습니다.
차이는 장애가 처음 보는 유형일 때 드러납니다. 모니터링은 과거 장애로 만들어집니다. 옵저버빌리티는 다음 장애를 위해 만들어지는데, 그 장애는 정의상 아직 본 적이 없는 것입니다.
간단한 테스트가 있습니다. 최근 장애 세 건을 떠올리고 근본 원인을 어떻게 찾았는지 물어보십시오.
누군가 미리 만들어진 대시보드를 보았고 답이 거기 있었다면, 모니터링이 제 역할을 한 것입니다.
누군가 여섯 대의 호스트에서 로그를 검색하고 가설을 세운 뒤, 로그 한 줄을 추가해 재배포하여 확인했다면, 그것은 옵저버빌리티의 공백입니다.
실제 답이 고객이 보낸 스크린샷에서 나왔다면, 두 문제가 모두 있는 것입니다.
둘이 경쟁 관계인지 논쟁할 필요는 없습니다. 둘은 계층입니다. 모니터링은 연기 감지기이고, 옵저버빌리티는 불이 난 뒤 건물을 돌아다니며 어느 회로에서 시작되었는지 알아내는 능력입니다.
세 가지 신호와 각각이 실패하는 지점
로그, 메트릭, 트레이스가 표준 세 가지 신호입니다. 각각 다른 질문에 답하며, 벤더 가이드가 자주 건너뛰는 실패 지점이 있습니다.
메트릭은 시간에 따라 집계된 수치입니다. 요청률, 에러율, 지연 백분위, 포화도 같은 것입니다. 저장 비용이 낮고 조회가 빨라서 알림은 대개 여기에 걸립니다. 실패 지점은 집계 자체입니다. p99가 1.4초라는 것은 무언가 느리다는 뜻일 뿐, 느린 요청이 모두 한 고객의 한 샤드에 속한다는 사실은 알려 주지 못합니다.
로그는 개별 이벤트의 타임스탬프 기록입니다. 가장 많은 세부 정보를 담지만, 강제로 구조를 입히지 않으면 구조가 가장 적습니다. 실패 지점은 양과 비용입니다. 구조화되지 않은 로그는 무엇을 검색해야 하는지 이미 아는 사람만 찾을 수 있으므로, 디버깅 도구를 흉내 내는 모니터링 도구가 되기 쉽습니다.
트레이스는 하나의 요청이 서비스 경계를 넘어가는 경로를 각 홉의 span과 시간으로 따라갑니다. 요청의 모양을 보여 주는 유일한 신호입니다. 이 호출은 하류 의존성에서 900ms를 기다렸고, 그 의존성은 세 번 재시도했다는 사실이 보입니다. 실패 지점은 커버리지입니다. 트레이스 컨텍스트를 버리는 서비스 하나가 체인을 끊고, 구멍이 난 트레이스는 권위 있어 보이기 때문에 아무것도 없는 것보다 나쁩니다.
세 가지 신호를 모두 갖추는 것과 관찰 가능한 상태인 것은 같지 않습니다. 핵심은 상관관계입니다. 메트릭 급등에서 거기에 기여한 트레이스로, 그리고 그 정확한 요청의 로그로 이동할 수 있어야 합니다. 세 신호가 공통 식별자 없이 서로 다른 도구에 있다면, 그것은 모니터링 시스템 세 개와 그 사이를 이어 주는 사람 한 명입니다.
카디널리티가 디버깅 가능 여부를 가르는 이유
카디널리티는 필드가 가질 수 있는 서로 다른 값의 개수입니다. status_code는 스무 개 정도입니다. customer_id는 수십만 개입니다. request_id는 요청마다 하나씩 있습니다.
장애 중에 가장 필요한 필드는 대개 고카디널리티 필드입니다. "어느 고객이 영향을 받았는가"는 customer_id 질문입니다. "느린 요청을 처리하는 빌드는 무엇인가"는 deploy_version 질문입니다. 저장 모델이 고카디널리티 필드에 고유 시리즈마다 비용을 매기거나 조용히 버린다면, 장애를 풀어 줄 질문을 던질 수 없게 됩니다.
이것이 메트릭만 있는 구성과 관찰 가능한 구성 사이의 실제 아키텍처 경계입니다. 사전 집계된 메트릭은 나중에 필요할 차원을 버립니다. 넓고 구조화된 이벤트는 그 차원을 보존하고, 사후에 잘라 볼 수 있게 합니다.
서비스 가장자리에서 유용한 이벤트가 어떤 모습인지 예를 들어 보겠습니다. 요청 하나당 구조화된 레코드 하나이며, 나중에 신경 쓰게 될 어떤 기준으로든 자를 수 있을 만큼 맥락을 담습니다.
logger.info("request.completed", {
trace_id: span.traceId,
route: "/v1/payments",
customer_id: ctx.customerId,
deploy_version: process.env.BUILD_SHA,
flag_variant: flags.get("new-ledger-path"),
db_ms: timings.db,
upstream_ms: timings.upstream,
status: res.statusCode,
duration_ms: elapsed,
});여기에 기능 플래그 변형(flag variant)이 들어 있다는 점에 주목하십시오. 공개된 사후 분석 사례 중 상당수는 변경에서 시작하며, 플래그 평가도 하나의 변경입니다. 변형이 이벤트에 없다면, 느린 요청이 새 경로에 있는 요청인지 물을 수 없습니다.
같은 장애를 옵저버빌리티가 있을 때와 없을 때 비교하면
결제 시나리오를 다시 보겠습니다. 같은 알림, 같은 1.4초 p99입니다.
옵저버빌리티가 없으면 루프는 이렇습니다. 서비스 대시보드를 열고 아무것도 찾지 못합니다. 데이터베이스 대시보드를 열고 역시 아무것도 찾지 못합니다. 장애 채널에서 최근 배포가 있었는지 묻습니다. 누군가 설정 변경을 기억하고, 다른 사람은 동의하지 않습니다. 40분이 지나면 도움이 될지 보려고 마지막 배포를 되돌립니다. 도움이 되지 않습니다. 원인은 일부 테넌트에 대한 플래그 롤아웃이었기 때문입니다.
옵저버빌리티가 있으면 루프는 이렇습니다. 느린 요청을 flag_variant로 묶으면 그중 100%가 new-ledger-path에 있다는 것이 보입니다. customer_id로 묶으면 대형 테넌트 세 곳이 대부분의 트래픽을 차지한다는 것이 보입니다. 트레이스 하나를 열면 원장 호출이 순차 쿼리 40개로 퍼지는 모습이 보입니다. 전체 시간은 몇 분입니다. 여러분은 배포가 아니라 플래그를 끕니다.
두 번째 루프에 필요하지 않았던 것을 보십시오. 미리 준비된 대시보드가 필요하지 않았습니다. 누군가 "플래그 변형"이 흥미로운 차원이라고 미리 예측할 필요도 없었습니다. 데이터가 넓고 조회 가능한 형태로 거기 있기만 하면 되었습니다.
이것이 허니컴(Honeycomb)의 주장을 한 단락으로 요약한 것이며, 그 주장은 설득력이 있습니다. 다만 그것이 공짜라고 말하지는 않습니다.
비용은 얼마이며, 비싼 버전을 건너뛰어야 할 사람은 누구인가
텔레메트리는 도구의 문제이기 전에 데이터 양의 문제입니다. Grafana Labs의 2025년 옵저버빌리티 설문 조사(실무자 1,255명 대상)에 따르면 조직 평균은 여덟 개의 서로 다른 옵저버빌리티 도구를 운영하고 있으며, 새 도구를 고를 때 가장 많이 언급되는 기준은 비용입니다. 이 두 사실은 연결되어 있습니다. 팀들은 각 도구가 일부분을 해결하기 때문에 도구를 계속 늘리고, 그 뒤에서 겹치는 수집 비용을 모두 지불합니다.
대부분의 팀 규모에서 통하는 실용적인 원칙은 다음과 같습니다.
독점 에이전트 대신 OpenTelemetry로 계측하십시오. 수집기(collector) 하나가 샘플링, 필터링, 라우팅을 한곳에서 처리합니다. 백엔드를 바꾸는 일이 재계측 프로젝트가 아니라 설정 변경이 됩니다.
트레이스는 의도적으로 샘플링하십시오. 모든 에러와 모든 느린 요청은 남기고, 정상적으로 빠른 요청은 샘플링합니다. 고정 1%의 헤드 기반 샘플링은 정작 필요한 트레이스를 버릴 수 있습니다.
로그는 기록할 때 구조를 입히십시오. 자유 텍스트를 조회 시점에 파싱하는 것은 필드를 얻는 가장 비싼 방법입니다.
신호별로 보존 정책을 정하십시오. 메트릭은 1년, 넓은 이벤트는 2주, 디버그 로그는 3일입니다. 지난 분기의 디버그 로그가 필요했던 사람은 아무도 없었습니다.
서비스가 몇 개이고 온콜 순환이 하나뿐이라면 전체 플랫폼 접근법은 건너뛰어도 됩니다. 작은 팀은 두세 개의 핫 패스에서 구조화된 로그, RED 메트릭, 트레이스만으로도 대부분의 효과를 얻습니다. 값비싸고 모든 것을 해결하겠다는 계약은, 서비스가 많아서 아무도 전체 토폴로지를 머릿속에 담지 못하는 시점에 가치가 있습니다. 우리의 경험으로는 대략 서비스 30~40개를 넘어설 때입니다.
어떤 도구를 살펴볼 만한가
도구 선택은 직접 얼마나 운영하고 싶은지, 카디널리티가 어떤 모양인지, 청구서를 얼마나 감당할 수 있는지에 달려 있습니다. 짧고 의견이 담긴 둘러보기입니다.
Datadog은 가장 폭넓은 상용 옵션입니다. 메트릭, 로그, 트레이스, 프로파일링을 한 플랫폼에서 제공하며 이들 사이의 상관관계가 강합니다. 그 통합의 대가는 호스트 수, 커스텀 메트릭, 수집되는 로그 양에 따라 커지는 청구서입니다. 벤더 하나로 통일하고 싶고 그에 맞는 예산이 있다면 가치가 있습니다. 계약하기 전에 커스텀 메트릭 항목을 꼭 확인하십시오.
Grafana는 자체 호스팅하거나 관리형 스택으로 구매할 수 있는 오픈 컴포넌트를 원할 때의 기본 선택지입니다. Prometheus 스타일 메트릭 및 OpenTelemetry 파이프라인과 잘 맞습니다. 대신 운영 부담이 따릅니다. 조립의 더 많은 부분을 직접 소유하게 되며, 위 설문의 도구 난립 수치가 여러분에게도 그대로 적용됩니다.
SigNoz는 오픈 소스이며 OpenTelemetry 네이티브인 옵션으로, 로그, 메트릭, 트레이스를 하나의 데이터 저장소에 담습니다. 앞서 말한 상관관계 지점에서 중요합니다. 저장소가 공유되면 메트릭에서 트레이스, 로그로 넘어가는 이동이 탭 전환이 아니라 쿼리가 되기 때문입니다. 네 개의 프로젝트를 이어 붙이지 않고 자체 호스팅하고 싶은 팀에게 합리적입니다.
Better Stack은 가동 시간 모니터링, 장애 알림, 로그 관리를 중소 팀에 맞춘 가격으로 묶어 제공합니다. "고객이 알려 줘서 장애를 아는" 상태에서 체계적인 상태로 옮겨 가는 첫 단계로 합리적입니다. 무거운 트레이스 요구사항이 있는 대규모 서비스 메시에는 덜 맞습니다.
바다를 끓이지 않고 작게 시작하려면
도구 평가부터 시작하지 마십시오. 최근 장애 세 건과 정직한 질문 하나로 시작하십시오. 우리가 물어볼 수 있었으면 좋았을 질문은 무엇이었는가?
엔지니어 50~200명 규모 팀에서 효과가 있었던 순서는 다음과 같습니다.
중요한 요청 경로 하나를 고르고 OpenTelemetry로 처음부터 끝까지 계측하십시오. 결제, 로그인, 새벽 3시에 여러분을 깨우는 것이면 무엇이든 됩니다.
서비스 가장자리에서 요청마다 넓은 구조화 이벤트 하나를 내보내십시오. 고객, 버전, 플래그 변형, 하류 소요 시간을 포함합니다.
그 경로에 SLO 하나를 정의하고 원시 임계값이 아니라 소진율(burn rate)로 알림을 거십시오. 소진율 알림은 사용자 영향에 대해 호출하고, 2단계의 텔레메트리가 이유를 알려 줍니다.
게임 데이를 실행하십시오. 아직 알림을 걸지 않은 장애를 주입하고, 코드를 쓰지 않은 사람이 그것을 찾는 데 얼마나 걸리는지 보십시오. 그 숫자가 기준선입니다.
첫 경로가 실제 장애에서 값을 증명한 뒤에만 한 번에 한 경로씩 범위를 넓히십시오.
옵저버빌리티는 플랫폼으로 구매되지만 습관으로 자리 잡습니다. 그 습관은 코드 리뷰에서 "이것을 설명하려면 무엇을 알아야 하는가?"라고 묻는 것입니다. 장애 중이 아니라 장애 전에 묻는 것입니다.
최근 장애 회고를 펼쳐 보십시오. "로그를 추가해서 확인했다"는 문장을 찾으십시오. 그런 문장마다 프로덕션에서 시스템이 답하지 못한 질문이 있었던 것입니다. 그중 몇 개가 기록에 남아 있으며, 그중 오늘도 여전히 답할 수 없는 것은 몇 개입니까?