모니터링 vs 옵저빌리티: 관찰의 시대, 시스템을 ‘이해하는’ 기술로

Monitoring vs Observability: 관찰의 시대, 시스템을 ‘이해하는’ 기술로

클라우드 네이티브 환경이 보편화되면서, 시스템 운영자는 더 이상 단일 서버의 상태만 살펴보지 않습니다.

수십, 수백 개의 마이크로서비스가 서로 연결된 복잡한 구조 속에서, “문제가 생겼다”는 사실보다 “왜 생겼는가”를 빠르게 파악하는 것이 핵심 과제가 되었습니다.

바로 이 지점에서 ‘모니터링(Monitoring)’과 ‘옵저빌리티(Observability)’의 차이가 시작됩니다.

Monitoring vs Observability 삽화 이미지

 

1. 모니터링(Monitoring)과 옵저빌리티(Observability)의 출발점

🔷 시스템 관찰의 진화: 로그 → 메트릭 → 트레이스

시스템을 관찰하는 방식은 시대의 변화와 함께 끊임없이 진화해왔습니다.

 

초기에는 단순히 로그(Log)를 남겨 시스템의 동작과 이벤트를 기록하는 수준이었습니다.

로그는 개발자와 운영자가 문제를 추적하는 기본 수단이었지만, 장애의 발생 시점이나 전체적인 성능 흐름을 파악하기엔 한계가 분명했습니다.

 

이후 등장한 것이 메트릭(Metrics) 기반의 모니터링입니다.

CPU 사용률, 메모리 점유율, 요청 처리량 등 정량적인 데이터를 수집하여 시스템의 상태를 한눈에 볼 수 있게 되었죠. 이를 통해 이상 징후를 조기에 탐지하거나, 성능 추세를 장기적으로 분석할 수 있었습니다.

하지만 현대의 서비스 환경은 훨씬 더 복잡합니다.
마이크로서비스 아키텍처(MSA)와 클라우드 네이티브 구조에서는 하나의 요청이 여러 서비스와 네트워크 구간을 연쇄적으로 거칩니다. 이 과정에서 어디서 병목이 발생하는지, 어떤 구간이 지연을 유발하는지 파악하려면 단순한 수치 관찰로는 부족합니다.

이때 필요한 것이 바로 트레이스(Trace) 기반의 관찰입니다.

트레이스는 “하나의 요청이 시스템 내부에서 어떤 경로로 이동했는가”를 시각적으로 보여줍니다.

예를 들어 요청이 A 서비스 → B 서비스 → DB로 전달되는 동안의 지연 시간과 호출 관계를 세밀하게 추적할 수 있습니다.

즉, 트레이스는 요청 흐름의 지도를 그리는 기술이라 할 수 있습니다. 이를 통해 운영자는 병목 구간을 빠르게 찾아내고, 장애의 근본 원인을 파악할 수 있습니다.

 

🔷 단순 감시(Monitoring)에서 통찰(Observability)로

지금까지의 모니터링(Monitoring)은 시스템의 “상태를 감시”하는 데 초점을 맞췄습니다.
CPU 사용률이 일정 임계치를 넘으면 경보가 울리고, 트래픽이 급증하면 운영자가 대시보드를 확인하는 방식이 대표적이죠. 이 접근은 문제가 “있다”는 사실을 알려주는 역할에 충실합니다.

 

하지만 문제는 그 다음입니다.
알람이 울렸을 때, 우리는 종종 “그렇다면 왜 이런 현상이 생겼는가?”라는 질문에 답하지 못합니다. 메트릭은 단지 결과를 보여줄 뿐, 그 이면의 원인까지 설명하지는 않기 때문입니다.

 

이 지점에서 등장하는 개념이 바로 옵저빌리티(Observability) 입니다.
옵저빌리티는 단순히 데이터를 모으는 것이 아니라, 그 데이터를 통해 시스템 내부 상태를 추론할 수 있는 능력을 의미합니다.
즉, 옵저빌리티는 “관찰의 기술”을 넘어서 “이해의 기술”입니다.

 

모니터링이 “이상이 발생했다”고 알려주는 수준이라면, 옵저빌리티는 “왜 그런 이상이 발생했는가”를 설명할 수 있게 해줍니다.
따라서 옵저빌리티는 단순한 감시 도구가 아니라, 복잡한 시스템을 이해하고 개선하기 위한 사고방식이자 아키텍처 설계 원칙으로 발전했습니다.

 

2. 모니터링의 한계와 실무적 활용

🔷 모니터링의 핵심 구성요소: Metrics, Alerts, Dashboards

모니터링(Monitoring)은 시스템이 “정상적으로 작동하고 있는가”를 감시하는 첫 단계입니다.
이를 위해 대부분의 운영 환경은 세 가지 구성 요소를 중심으로 구축됩니다.

 

1. Metrics (지표)

시스템의 상태를 수치로 표현한 데이터입니다.
CPU 사용률, 메모리 점유율, 네트워크 트래픽, 요청 응답 시간 등은 모두 대표적인 메트릭입니다.
예를 들어, Prometheus는 이러한 메트릭을 주기적으로 수집하여 시계열(time-series) 형태로 저장합니다.

2. Alerts (경보)
특정 지표가 사전에 정의한 임계값(threshold)을 초과하면 자동으로 알림을 발생시킵니다.

예를 들어, 응답 시간이 2초 이상 지속되거나 에러율이 5%를 초과하면 Slack이나 이메일로 경보를 보낼 수 있습니다.

이를 통해 운영자는 장애 발생 직전에 대응할 수 있습니다.

3. Dashboards (대시보드)

수집된 데이터를 한눈에 시각화하는 도구입니다.

Grafana나 Kibana 같은 대시보드는 여러 서비스의 상태를 실시간으로 보여주며, 운영자가 직관적으로 이상 징후를 감지할 수 있도록 돕습니다.

이 세 가지가 결합된 시스템은, 가장 기본적인 수준의 운영 효율성을 제공합니다.
즉, 모니터링은 시스템의 현재 상태를 “보는 눈”을 만들어 주는 것입니다.

 

🔷 장애 탐지와 경보의 역할

모니터링의 가장 큰 장점은 장애를 조기에 감지할 수 있다는 점입니다.
예를 들어 Prometheus + Alertmanager 조합을 구축하면 다음과 같은 자동화가 가능합니다.

“HTTP 요청 응답 시간이 2초를 초과하고, 에러율이 5%를 넘을 경우 즉시 알람 전송.”

 

이런 설정을 통해 운영자는 이상 징후를 신속하게 인지하고, 장애 발생 전 사전 대응이 가능합니다.

이는 특히 SLA(Service Level Agreement)를 준수해야 하는 서비스 환경에서 매우 중요합니다.

모니터링은 이러한 자동 경보 체계를 통해 시스템 가용성을 유지하는 데 기여합니다.

 

또한, 과거 데이터를 바탕으로 트렌드 분석을 수행하면 장기적인 용량 계획(capacity planning)에도 활용할 수 있습니다.
예를 들어 “지난 3개월간 CPU 사용률 추세를 보면, 서버 리소스를 20% 확장해야 한다”는 식의 의사결정을 지원할 수 있습니다.

 

🔷 하지만 ‘왜’에 답하지 못하는 이유

하지만 모니터링의 한계는 명확합니다.

그것은 바로 “무엇이 일어났는가”는 알려주지만 “왜 일어났는가”에는 답하지 못한다는 점입니다.

예를 들어, 대시보드에 “응답 시간이 평소보다 느려졌다”는 경고가 표시되었다고 가정해 봅시다.

운영자는 이를 보고 즉시 문제를 인지할 수 있지만, 원인을 파악하기까지는 여전히 긴 시간이 필요합니다.

▸ 네트워크 지연 때문인가?
▸ 특정 마이크로서비스의 병목 현상인가?
▸ DB 쿼리 락(lock) 때문인가?
▸ 혹은 캐시 서버가 만료되어 백엔드 요청이 폭증한 것인가?

 

모니터링은 이 질문들에 대해 원인을 추적할 단서를 제공하지 않습니다.

결국 운영자는 여러 로그를 뒤지고, 각 서비스의 상태를 일일이 점검해야 합니다.

즉, 모니터링은 “증상(Symptom)”만 보여줄 뿐, “근본 원인(Root Cause)”은 설명하지 않습니다.

 

이 문제는 시스템이 복잡해질수록 더 심화됩니다.

마이크로서비스, 쿠버네티스, 클라우드 인프라 환경에서는 서비스 간 의존성이 매우 높기 때문에, 한 곳의 장애가 다른 여러 컴포넌트로 연쇄적인 영향을 미치는 경우가 많습니다.

이럴 때 단순한 메트릭만으로는 전체 맥락을 파악하기 어렵습니다.

 

---

반응형

3. 옵저빌리티(Observability)의 본질

🔷 “무엇이 일어났는가”에서 “왜 일어났는가”로

옵저빌리티(Observability)는 단순히 데이터를 수집하거나 시각화하는 개념이 아닙니다.

그보다 훨씬 깊은 철학을 담고 있습니다.

시스템이 외부로부터 관찰되었을 때, 그 내부 상태를 유추할 수 있는 능력 이것이 바로 옵저빌리티의 핵심입니다.

즉, 옵저빌리티는 “무엇이 일어났는가(What happened)”가 아니라 “왜 일어났는가(Why it happened)”를 설명할 수 있도록 시스템을 설계하는 접근 방식입니다.

예를 들어, 단순히 “응답 시간이 늘었다”는 사실을 아는 것에 그치지 않고, 그 지연이 특정 API 호출의 DB 쿼리 병목 때문인지,
혹은 외부 서비스 통신의 타임아웃 때문인지를 한눈에 파악할 수 있어야 합니다.

이처럼 옵저빌리티는 운영자가 “직감에 의존하지 않고 근본 원인을 빠르게 파악”하도록 돕는 체계입니다.
이런 이유로 현대의 DevOps, SRE, 클라우드 네이티브 환경에서는 옵저빌리티를 “운영 효율성의 끝판왕”이자 “복잡성을 다루는 언어”로 받아들이고 있습니다.

 

🔷 옵저빌리티의 세 가지 축: Logs / Metrics / Traces

옵저빌리티는 세 가지 기둥으로 구성됩니다.

바로 로그(Log), 메트릭(Metrics), 그리고 트레이스(Traces)입니다.
이 세 요소는 서로 보완적인 관계를 가지며, 시스템을 다양한 시점에서 입체적으로 이해할 수 있게 만듭니다.

요소	역할	도구 예시
Logs	이벤트의 상세 기록 (발생 시점, 컨텍스트, 스택 트레이스 등)	Loki, Elastic Stack
Metrics	성능 지표의 수치화 및 추세 분석	Prometheus
Traces	요청(Request)의 흐름을 시각화 및 상관 분석	Jaeger, Tempo

 

🔸Logs - 사건의 “기록”

로그는 시스템의 이벤트 단위를 세밀하게 기록합니다.
예를 들어 “DB 연결 실패”, “사용자 로그인 요청 처리 완료” 같은 정보들이죠.
로그는 문제의 구체적인 맥락(Context)을 파악하는 데 필수적입니다.

 

🔸Metrics - 상태의 “지표화”

메트릭은 시스템의 성능을 수치로 표현합니다.
CPU 사용률, 요청 수, 에러율, 메모리 사용량 등은 모두 메트릭 데이터입니다.
이를 통해 시스템이 정상 범위 내에서 작동 중인지를 실시간으로 확인할 수 있습니다.

 

🔸Traces - 흐름의 “시각화”

트레이스는 요청이 여러 마이크로서비스를 거쳐 처리되는 전체 경로를 추적합니다.
예를 들어, 사용자의 로그인 요청이
API Gateway → Auth Service → Database
로 흐른다면, 각 구간별 지연 시간과 상태를 트레이스로 시각화할 수 있습니다.

 

🔷 OpenTelemetry: 옵저빌리티의 표준 기반

과거에는 각 서비스마다 서로 다른 방식으로 로그, 메트릭, 트레이스를 수집했습니다.
그러나 이런 비표준 환경은 관리가 어렵고 통합 분석도 쉽지 않았습니다.
이를 해결하기 위해 등장한 것이 바로 OpenTelemetry(OTel)입니다.

 

OpenTelemetry는 CNCF(Cloud Native Computing Foundation)에서 주도하는 오픈소스 프로젝트로, Logs / Metrics / Traces를 표준화된 형식으로 수집·전송하는 통합 프레임워크입니다.

 

그 구조는 다음과 같습니다.

Instrumentation → Collector → Backend

1. Instrumentation
애플리케이션 코드에 계측 코드를 추가하거나, 라이브러리 자동 계측(auto-instrumentation)을 통해 요청, 지연 시간, 에러 등의 데이터를 자동으로 수집합니다.

 

2. Collector
다양한 소스에서 들어온 데이터를 받아 변환하고, 필요 시 필터링 또는 집계 작업을 수행한 뒤 백엔드로 전송합니다.

 

3. Backend
Prometheus, Loki, Tempo, Grafana 같은 분석·시각화 도구가 여기에 해당합니다.
이곳에서 최종적으로 데이터를 조회하고 상관 분석을 수행합니다.

 

즉, OpenTelemetry는
“각기 다른 데이터 형식을 하나의 공통 언어로 통합하는 표준 인터페이스”입니다.
이 덕분에 Prometheus나 Jaeger, Grafana 같은 도구들이 서로 쉽게 연결될 수 있으며, 운영자는 로그·메트릭·트레이스를 단일 관점에서 분석할 수 있습니다.

 

🔷 현대 옵저빌리티 스택의 방향성

최근 실무 환경에서는 다음과 같은 조합이 가장 많이 사용됩니다.

▸ Prometheus: 메트릭 수집 및 시계열 저장
▸ Grafana: 대시보드 및 상관 분석 시각화
▸ Loki: 로그 수집 및 빠른 검색
▸ Tempo: 트레이스 데이터 관리
▸ OpenTelemetry Collector: 데이터 파이프라인의 중심 허브

 

이 조합은 완전한 오픈소스 기반으로도 강력한 옵저빌리티 환경을 구성할 수 있게 해줍니다.
특히 Grafana는 여러 소스(Prometheus, Loki, Tempo)를 통합 대시보드로 연결해 한 화면에서 로그, 메트릭, 트레이스를 동시에 탐색할 수 있도록 지원합니다.

즉, 단일 장애(Event)를 중심으로 “지표 → 로그 → 트레이스”를 연계 탐색하는 것이 가능해진 것입니다.

이 접근은 문제 해결 시간을 획기적으로 단축시키고, 운영자가 근본 원인을 이해하는 속도를 높입니다.

 

4. 실무 비교와 도입 전략

🔷 모니터링에서 옵저빌리티로의 확장 단계

옵저빌리티는 단번에 완성할 수 있는 체계가 아닙니다.
대부분의 조직은 기존 모니터링 환경을 기반으로 점진적으로 발전시켜 나갑니다.
아래는 현실적인 단계별 확장 로드맵입니다.

 

🔸 1단계: 메트릭 중심의 기본 모니터링 구축
가장 먼저 Prometheus와 Grafana를 이용해 시스템의 핵심 지표를 수집하고 대시보드화합니다.
이 단계에서는 CPU, 메모리, 네트워크, 요청 수, 에러율 등 성능 모니터링의 기본 체계를 세우는 것이 목표입니다.

🔸 2단계: 로그의 구조화 및 중앙화
여러 서버와 컨테이너에서 발생하는 로그를 Loki나 Elasticsearch로 통합 관리합니다.

단순한 텍스트 로그를 넘어서, JSON 기반의 구조화 로그(Structured Log) 형태로 변환해 두면 나중에 검색과 분석이 훨씬 효율적입니다.

🔸 3단계: 트레이싱(Tracing) 도입
Jaeger나 Tempo를 통해 요청 흐름 추적(Distributed Tracing)을 도입합니다.
이 단계부터는 요청 단위의 병목, 서비스 간 호출 지연, 비정상 흐름을 시각적으로 분석할 수 있습니다.

🔸 4단계: 데이터 상관분석 및 시각화 통합
Grafana를 중심으로 로그, 메트릭, 트레이스를 한 화면에서 탐색할 수 있도록 구성합니다.
예를 들어 “특정 트레이스 ID를 클릭 → 해당 구간의 로그와 메트릭 자동 조회” 같은 형태로 데이터 간 상관분석(Correlation Analysis) 이 가능해집니다.

🔸 5단계: 지능형 분석(AIOps) 및 자동 대응
일정 수준의 옵저빌리티가 정착되면, 머신러닝 기반의 이상 탐지(AIOps)를 도입할 수 있습니다.
이를 통해 시스템이 스스로 이상 패턴을 인식하고, 운영자가 개입하기 전에 자동 대응을 수행하도록 진화할 수 있습니다.

 

이와 같은 단계별 확장은 “도구를 도입하는 순서”가 아니라 운영 문화와 데이터 신뢰도를 높여가는 과정으로 이해하는 것이 중요합니다.

 

✔️ Grafana + OpenTelemetry 옵저빌리티 아키텍처 예시

┌─────────────────────────────────────────────────────────────┐
│                         Application Layer                   │
│  ┌───────────────────────────────┐    ┌──────────────────┐  │
│  │  Service A (API Server)       │    │  Service B (DB)  │  │
│  │  ↳ OTel SDK (Auto-Instrument) │    │  ↳ OTel SDK      │  │
│  └───────────────────────────────┘    └──────────────────┘  │
│               │                               │              │
└───────────────┼───────────────────────────────┼──────────────┘
                │                               │
                ▼                               ▼
          ┌───────────────────────────────────────────────┐
          │            OpenTelemetry Collector            │
          │───────────────────────────────────────────────│
          │  • Receivers (OTLP, Prometheus, Loki)         │
          │  • Processors (Batching, Filtering)           │
          │  • Exporters (Prometheus Remote Write, Tempo, │
          │              Loki, Grafana Cloud)             │
          └───────────────────────────────────────────────┘
                │          │                │
        ┌───────┘          │                └──────────────┐
        ▼                  ▼                               ▼
┌──────────────┐    ┌───────────────┐               ┌──────────────┐
│  Prometheus  │    │    Loki       │               │    Tempo     │
│ (Metrics DB) │    │ (Logs Store)  │               │ (Traces DB)  │
└──────────────┘    └───────────────┘               └──────────────┘
        │                  │                               │
        └──────────────────┼───────────────────────────────┘
                           ▼
                ┌───────────────────────────┐
                │         Grafana            │
                │  • Dashboards              │
                │  • Correlation View        │
                │  • Alerting & Explore      │
                └───────────────────────────┘

1️⃣ Application Layer (서비스 계층)

▸ 각 마이크로서비스에 OpenTelemetry SDK를 적용합니다.
▸ Node.js, Go, Python, Java 등 언어별 SDK를 통해 자동 계측(auto-instrumentation)이 가능합니다.
▸ 서비스에서 발생하는 요청/응답, 에러, 지연 시간 등의 데이터가 OTLP(OpenTelemetry Protocol) 형태로 Collector에 전송됩니다.

 

2️⃣ OpenTelemetry Collector (중앙 수집 허브)
▸ 옵저빌리티의 데이터 파이프라인 중심입니다.
▸ 다양한 입력(Receivers) → 처리(Processors) → 출력(Exporters) 단계를 거쳐 데이터를 가공하고 전달합니다.
▸ 예시:
  - Receiver: OTLP, Prometheus, Loki, Jaeger
  - Processor: Batch, Memory Limiter, Attributes Processor
  - Exporter: Prometheus Remote Write / Tempo / Loki

Collector는 로그, 메트릭, 트레이스를 통합 수집해 각각의 저장소로 전달합니다.

 

3️⃣ 데이터 스토리지 계층

▸ Prometheus → Metrics 저장소
  - 시계열(time-series) 데이터 관리
  - Grafana에서 대시보드 기반 시각화

▸ Loki → Logs 저장소
  - 텍스트 로그를 인덱스 없이 빠르게 조회
  - Promtail 또는 OTel Collector로부터 수신

▸ Tempo → Traces 저장소
  - 분산 트레이싱 데이터 관리
  - Trace ID 기반으로 서비스 호출 관계를 탐색

이 세 가지는 각각의 데이터 형태를 담당하면서도 Trace ID 또는 Labels 기반으로 서로 연결됩니다.

 

4️⃣ Grafana (시각화 및 분석 계층)

▸ 옵저빌리티의 최종 인터페이스입니다.
▸ Grafana는 Prometheus, Loki, Tempo의 데이터를 모두 연동하여 Logs ↔ Metrics ↔ Traces 간 상관 분석(Correlation) 을 제공합니다.
▸“Explore” 기능을 통해 특정 트레이스 ID를 클릭하면 해당 로그·지표를 바로 탐색할 수 있습니다.
▸Alerting, Dashboard, Tempo 트레이스 시각화 등을 통합 제공합니다.

✔ 마무리

모니터링은 시스템의 “현재 상태를 감시”하는 기술입니다.
하지만 현대의 인프라는 단일 서버가 아니라,
수십 개의 마이크로서비스와 수많은 의존성 위에서 움직이는 복잡한 생태계입니다.
이제는 단순히 “정상/비정상”을 구분하는 것만으로는 충분하지 않습니다.

이러한 시대적 변화 속에서 옵저빌리티는
시스템이 스스로를 설명할 수 있게 만드는 언어이자 철학으로 자리 잡았습니다.
로그(Log)는 사건을 기록하고, 메트릭(Metrics)은 상태를 수치화하며,
트레이스(Traces)는 맥락(Context)을 연결합니다.
이 세 가지가 조화를 이루어야 비로소 시스템은 “무엇이 일어났는가”뿐 아니라
“왜 일어났는가”까지 이야기할 수 있게 됩니다.

Grafana와 OpenTelemetry 같은 오픈소스 기술은
이 철학을 현실의 운영 환경에 구현할 수 있는 기반을 제공합니다.
Prometheus, Loki, Tempo가 서로 연결되어
한 화면에서 로그·지표·트레이스를 상관분석할 수 있을 때,
우리는 단순한 ‘가시성(Visibility)’을 넘어 ‘이해(Understanding)’의 단계에 도달합니다.

 

 

---

반응형

※ 게시된 글 및 이미지 중 일부는 AI 도구의 도움을 받아 생성되거나 다듬어졌습니다.