Cloud & DevOps

모니터링과 옵저버빌리티 — 실전 구축 가이드

한 줄 요약: 모니터링은 '무엇이 문제인가'를 알려주고, 옵저버빌리티는 '왜 문제인가'까지 알려준다. 로그/메트릭/트레이싱의 3가지 신호를 수집해야 한다. 프로덕션 서비스 운영에서 장애 감지와 원인 분석의 핵심인 옵저버빌리티 스택 구축법을 정리한다. Prometheus, Grafana, OpenTelemetry, Sentry 등 도구의 역할과 실전 설정을 다룬다.

by Lee발행: 2026-04-13

한 줄 요약: 모니터링은 '무엇이 문제인가'를 알려주고, 옵저버빌리티는 '왜 문제인가'까지 알려준다. 로그/메트릭/트레이싱의 3가지 신호를 수집해야 한다.

프로덕션 서비스 운영에서 장애 감지와 원인 분석의 핵심인 옵저버빌리티 스택 구축법을 정리한다. Prometheus, Grafana, OpenTelemetry, Sentry 등 도구의 역할과 실전 설정을 다룬다.

옵저버빌리티의 3기둥

Logs: 무엇이 일어났는가 (이벤트 기록). Metrics: 얼마나 일어났는가 (수치 데이터). Traces: 어떤 경로로 일어났는가 (요청 추적). 셋을 조합해야 문제의 전체 그림이 보입니다.

옵저버빌리티의 3대 축: 로그(Logs)는 이벤트의 상세 기록이다. 에러 메시지, 요청 파라미터, 스택 트레이스를 포함한다. 메트릭(Metrics)은 시계열 숫자 데이터다. CPU 사용률, 응답 시간 p95, 초당 요청 수(RPS) 등. 트레이싱(Traces)은 하나의 요청이 여러 서비스를 거치는 경로를 추적한다. 마이크로서비스 환경에서 병목을 찾는 핵심 도구다.

도구 스택: 메트릭 수집은 Prometheus, 시각화는 Grafana, 로그 수집은 Loki 또는 ELK(Elasticsearch+Logstash+Kibana), 트레이싱은 Jaeger 또는 Tempo. OpenTelemetry(OTel)는 이 3가지 신호를 하나의 SDK로 수집하는 표준이다.

OpenTelemetry Node.js 초기화
// tracing.ts
import { NodeSDK } from '@opentelemetry/sdk-node';
import { OTLPTraceExporter } from
  '@opentelemetry/exporter-trace-otlp-http';

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: 'http://otel-collector:4318/v1/traces'
  }),
  instrumentations: [getNodeAutoInstrumentations()]
});
sdk.start();

알림 설계 원칙

알림이 너무 많으면 '알림 피로(Alert Fatigue)'가 발생해 중요한 알림을 놓치게 된다. 원칙 1: 즉각 대응이 필요한 알림만 Slack/PagerDuty로 보낸다. 원칙 2: SLO(Service Level Objective) 기반으로 알림을 설정한다 — 예: '응답 시간 p99가 5분 동안 2초 초과'. 원칙 3: 모든 알림에 대응 가이드(runbook)를 링크한다.

시작 추천: 처음에는 Sentry(에러 모니터링) + Grafana Cloud(무료 플랜으로 메트릭/로그/트레이싱 통합)로 시작하라. 이 두 도구만으로 대부분의 중소 규모 서비스의 옵저버빌리티 요구를 충족할 수 있다.

1인 개발자 관점에서 이 주제가 왜 중요한가

이 글의 주제(모니터링과 옵저버빌리티 — 실전 구축 가이드)를 다룰 때 저는 버셀 + 깃허브 액션으로 자동 배포를 운영하는 입장 관점에서 봅니다. 단순히 새 기능을 소개하는 입장이 아니라, 12개 한국어 사이트를 1인으로 운영하면서 매일 클로드 코드를 켜두고 작업하는 입장이라 의사결정의 기준이 다소 좁고 실용적인 편입니다. 신기술이 출시될 때마다 곧바로 도입하기보다는 우선 한두 사이트에 시범 도입해 두고, 운영 부담이 늘지 않는지 며칠 지켜본 뒤 전체 확산을 결정하는 식입니다.

가장 자주 보는 변수는 버셀 무료 티어 한도 vs 유료 전환 시점, 그리고 1인 개발자의 현금흐름 한계입니다. 두 변수는 신기술을 도입할지 말지 결정할 때 거의 매번 영향을 줍니다. 글의 본문은 위의 두 축을 직접 명시하지는 않지만, 본문에서 다루는 항목을 이 축에 비춰 보시면 본인 환경에 맞는지 빠르게 판단할 수 있습니다. 특히 한국어 응답 품질의 미세한 한계 같은 운영 변수는 도구 자체 성능보다 더 큰 영향을 주는 경우가 많기 때문에 본문 비교표를 볼 때 같이 떠올리시면 좋습니다.

한 가지 더 강조하면, Cloud & DevOps 영역의 글을 읽을 때 저는 본문이 다루는 도구·서비스가 ① 한국 결제 가능 여부 ② 한국어 응답 품질 ③ 종량제 비용의 예측 가능성 ④ 1인 개발자 학습 시간 대비 효과, 네 항목을 모두 충족해야 실제 도입을 결정합니다. 네 항목 중 하나라도 명확하지 않으면 도입을 1~2주 미루는 편이고, 그 사이 같은 카테고리의 다른 글도 확인합니다.

본문의 각 비교·코드·체크리스트는 이 네 항목 중 어느 부분에 영향을 주는지 의식하면서 보시면 더 빠르게 결론에 도달하실 수 있습니다. 본 사이트의 다른 Cloud & DevOps 글과 함께 보시면 같은 평가 축이 반복되는 것을 확인하실 수 있습니다. 토픽 페이지 또는 같은 카테고리 태그를 따라가시면 동일한 평가 기준이 적용된 글을 한 번에 모아 보실 수 있습니다.

본인 환경에 적용하기 전 확인할 체크포인트

본문의 내용을 본인 환경에 적용하기 전에 다음 항목을 빠르게 확인하시면 도입 실패 가능성을 줄일 수 있습니다.

공식 문서 버전 일치 — 본문 작성 시점과 현재 배포 버전이 다른 경우, 같은 명령어가 다르게 동작할 수 있습니다.
한국 결제·환율 검증 — 카드 결제, 부가가치세 처리, 원화 환산 시점에 따라 실제 청구액이 본문 예시와 다를 수 있습니다.
기존 스택과의 호환성 — Next.js·Vercel·Supabase 같은 기본 스택과 충돌이 없는지 패키지 의존성을 먼저 확인하세요.
롤백 절차 사전 정리 — 도입 후 문제가 생겼을 때 1회 명령으로 이전 상태로 되돌릴 수 있는 절차를 도입 전에 메모해 두시면 운영 부담이 크게 줄어듭니다.

위 네 항목을 모두 통과하면 보통 1~2시간 내에 도입을 마칠 수 있고, 통과하지 못한 항목이 있다면 그 항목을 우선 해결한 뒤 다시 시작하는 것이 효율적입니다.

자주 묻는 질문

더 깊게 공부하려면 어떤 자료를 보면 좋을까요?

표준부터 잡고 싶다면 OpenTelemetry 공식 문서를 추천합니다. 로그·메트릭·트레이스 세 신호를 하나의 SDK로 다루는 방법이 언어별로 정리돼 있어서, 본문의 Node.js 초기화 코드에서 한 걸음 더 나아갈 때 바로 참고할 수 있습니다. 시각화·알림 쪽은 Grafana 공식 문서의 PromQL(Prometheus 쿼리 언어)과 SLO·알림 룰 작성 가이드를 먼저 보시는 게 효율적입니다. 운영 철학을 잡고 싶다면 Google의 SRE 책(무료 공개판)에서 SLO와 에러 버짓 개념을 읽어 보시길 권합니다. 이 세 키워드(OpenTelemetry, PromQL, SLO)만 익혀도 중소 규모 스택은 충분히 설계하실 수 있습니다.

모니터링과 옵저버빌리티, 한 줄로 정리하면 어떻게 되나요?

모니터링이 무엇이 문제인지를 알려준다면, 옵저버빌리티는 왜 문제인지까지 파고들 수 있게 해 줍니다. 그 차이를 만드는 것이 로그(무엇이 일어났나)·메트릭(얼마나 일어났나)·트레이스(어떤 경로로 일어났나) 3기둥이고, 이 셋을 OpenTelemetry 표준으로 한 번에 수집해 두는 게 핵심입니다. 처음에는 Sentry로 에러를 잡고 Grafana Cloud 무료 플랜으로 세 신호를 통합한 뒤, 알림은 즉각 대응이 필요한 SLO 기반 항목만 거는 것으로 시작하면 됩니다.

실무에서 처음 도입할 때 가장 먼저 확인할 것은 무엇인가요?

로그·메트릭·트레이스 셋을 한꺼번에 다 깔려고 하지 말고, 에러부터 잡으세요. 처음에는 Sentry로 에러 모니터링을 붙이고 Grafana Cloud 무료 플랜으로 메트릭·로그·트레이싱을 통합하면 중소 규모 서비스 대부분이 커버됩니다. 그다음 OpenTelemetry SDK를 한 번 붙여 세 신호를 같은 표준으로 수집하도록 설계하면 나중에 백엔드(Prometheus·Loki·Tempo 등)를 바꿔도 코드를 다시 안 짜도 됩니다. 알림은 처음부터 욕심내지 말고, 즉각 대응이 필요한 SLO 기반 항목 몇 개만 PagerDuty/Slack으로 보내는 것으로 시작하세요.

가장 자주 발생하는 실수나 함정은 무엇인가요?

가장 흔한 함정은 알림을 과하게 걸어 알림 피로(Alert Fatigue)에 빠지는 것입니다. 사소한 변동에도 알림이 쏟아지면 정작 중요한 장애 알림을 놓치게 되니, 즉각 대응이 필요한 SLO 기반 알림만 보내고 모든 알림에 대응 가이드(runbook)를 링크해 두어야 합니다. 두 번째는 로그·트레이스를 무제한으로 수집해 저장 비용이 폭증하는 경우로, 샘플링과 보관 기간을 미리 정해야 합니다. 세 번째는 로그에 비밀번호나 토큰 같은 PII·시크릿을 그대로 남기는 것으로, 수집 단계에서 필터링하지 않으면 보안 사고로 이어집니다.

다른 대안과 비교했을 때 어떤 상황에 적합한가요?

직접 운영할 여력이 있고 비용을 통제하고 싶다면 Grafana + Prometheus + Loki + Tempo로 직접 스택을 꾸리는 게 적합합니다. 오픈소스라 데이터 보관·샘플링을 마음대로 조정할 수 있지만, 그만큼 설정과 유지보수 손이 많이 갑니다. 반대로 인프라 운영에 시간을 쓰기 어려운 소규모 팀이나 1인 개발자라면 Sentry + Grafana Cloud 무료 플랜 조합으로 시작하는 편이 낫고, 트래픽이 커져 통합 대시보드·자동 상관 분석이 필요해지면 Datadog이나 New Relic 같은 유료 SaaS가 시간을 크게 아껴 줍니다. 다만 SaaS는 로그·트레이스 전송량에 비례해 요금이 빠르게 오르므로, 수집량이 많은 서비스라면 비용을 미리 따져 봐야 합니다.

모니터링옵저버빌리티로그메트릭트레이스