최소 관측 — 로그·메트릭·트레이스

관측 (observability) 이라는 단어가 풀스택 도입을 떠올리게 만들지만, 작은 시스템부터 풀 스택을 도입하면 운영 비용이 가치를 앞지르기 쉽습니다.

1. 3 Pillars

관측의 자리는 흔히 세 기둥으로 정리됩니다.

세 기둥은 서로 보완합니다. 메트릭이 이상을 알리고, 로그가 그 시점의 사건을 보여주고, 트레이스가 그 요청이 어디서 느려졌는지 보여줍니다.

2. OpenTelemetry

CNCF 의 프로젝트로 2019 년에 OpenTracing (2016) + OpenCensus (2017) 의 합병으로 출발했습니다. 사이트는 opentelemetry.io. 표준 SDK · API · 와이어 포맷 (OTLP) 을 정의해 벤더 종속을 줄입니다.

핵심 모양:

• 애플리케이션은 OpenTelemetry SDK 로 신호를 만듭니다 (traces · metrics · logs).
• OTel Collector (또는 직접) 가 신호를 받아 백엔드로 보냅니다.
• 백엔드 (Tempo · Jaeger · Datadog 등) 는 시각화·검색을 제공합니다.

벤더 락인을 피하려는 자리에서 자주 거론됩니다.

3. 로그의 결

• 구조화 로그 (JSON) — 키-값으로 적어 검색·집계가 가능하게.
• 상관 ID (correlation id / trace id) — 한 요청을 구분하는 키를 모든 관련 로그에 함께 적습니다.
• 레벨 — DEBUG · INFO · WARN · ERROR · FATAL.
• 샘플링 — 너무 많은 로그는 비용·노이즈가 됩니다. 중요한 자리만 또는 비율 샘플링.

{
  "ts": "2026-04-25T01:23:45Z",
  "level": "ERROR",
  "service": "api",
  "trace_id": "0a1b2c...",
  "msg": "DB query timeout",
  "query": "SELECT ... LIMIT 10",
  "elapsed_ms": 5021
}

4. 메트릭의 결

• Counter — 단조 증가 (요청 수·에러 수).
• Gauge — 순간 값 (현재 메모리·연결 수).
• Histogram — 분포 (지연 시간) — p50 · p95 · p99 같은 분위수.
• Summary — 분위수를 클라이언트가 미리 계산.

p99 지연이 평균보다 더 의미 있는 자리가 많습니다. 평균만 보면 꼬리(tail) 가 가린 사용자 경험이 보이지 않습니다.

5. 트레이스의 결

• Span — 한 작업의 시작·끝을 가진 단위.
• Trace — 한 요청에 속한 스팬의 트리.
• 컨텍스트 전파 — 스팬 ID 를 HTTP 헤더 (traceparent) · 메시지 헤더로 전달.
• 샘플링 — 매 요청을 트레이스로 남기면 비쌉니다. 비율·헤드·테일 샘플링.

W3C Trace Context · B3 같은 헤더 표준이 있고 OTel 이 W3C 를 기본으로 합니다.

6. Grafana 스택

• Grafana — 시각화.
• Prometheus — 메트릭 수집·저장.
• Loki — 로그 저장.
• Tempo — 트레이스 저장.
• Mimir — 대규모 메트릭 (분산 Prometheus 호환).

오픈소스이고 자체 호스팅이 가능하지만 5~6 개 서비스를 운영·업그레이드·백업해야 한다는 의미입니다.

7. SaaS 도구들

선택은 다음의 균형입니다:

• 운영 인력의 여유.
• 비용 예측 가능성.
• 데이터 보존 기간·규제.
• 통합 폭 (언어·프레임워크·인프라).

8. 최소 관측 — 4 단계

작은 시스템·단일 서버에서 시작하는 결입니다.

1 단계 — 구조화 로그 + 헬스체크

• 모든 서비스 로그를 JSON 으로.
• /health · /ready 엔드포인트.
• 외부 uptime 모니터 (UptimeRobot · BetterStack · Cronitor) 가 이 엔드포인트를 확인하고 알림.

이 한 단계만으로도 "서비스가 죽으면 안다" 는 자리가 채워집니다.

2 단계 — 에러 추적

• Sentry (또는 비슷한 서비스) 를 붙여 예외를 자동 전송.
• 스택 트레이스·release · 사용자 컨텍스트가 함께 모입니다.
• 비용 예측 가능한 자리.

3 단계 — 핵심 메트릭

• 요청 수 · 에러율 · p95 지연 정도를 노출.
• Prometheus + 작은 Grafana, 또는 클라우드 매니지드 메트릭.
• 알림은 핵심 지표 1~2 개로 시작.

4 단계 — 트레이싱

• 다중 서비스 호출이 늘면 트레이스의 가치가 커집니다.
• OpenTelemetry SDK + 백엔드 (Tempo · Jaeger · SaaS) 결합.
• 샘플링으로 비용 통제.

9. 어떤 정보가 결국 보여야 하나

각 단계의 이름·도구가 다르더라도 다음 정보가 결국 보여야 합니다.

• 지난 1 시간의 에러 수와 p95 지연.
• 지금 진행 중인 알람.
• 어떤 사용자·요청이 영향을 받았는가.

10. 자주 걸리는 자리

풀 스택 조기 도입 — 작은 시스템에 5 개 서비스를 띄우면 관측 자체의 운영 부담이 본 시스템보다 커집니다. 단계적 도입이 안전합니다.

로그에 비밀 — 패스워드·토큰·개인정보가 로그에 남습니다. 마스킹 라이브러리·필터로 막습니다.

카디널리티 폭주 — 메트릭 라벨에 사용자 ID·요청 ID 를 넣으면 시계열 수가 폭증합니다.

트레이스 누락 — 비동기·메시지 큐 경로에서 컨텍스트 전파가 끊어지는 자리. 명시 전파.

알림 피로 — 알람이 너무 많으면 모두 무시됩니다. 핵심 1~3 개로 시작 + 점진 추가.

샘플링의 의미 — 1% 샘플링 트레이스는 디버그용으로 충분할 때가 많지만 드문 에러를 놓칩니다. 헤드·테일 샘플링 결정.

시간 동기화 — 서버 간 시간이 어긋나면 트레이스·로그 상관이 어긋납니다. NTP.

벤더 종속 — SaaS 의 자체 SDK 만 쓰면 이전이 어렵습니다. OpenTelemetry 같은 표준 인터페이스 위에서 구성합니다.

하고픈 말

관측은 운영 사고 후에야 가치가 보이는 자리입니다. 그래도 풀 스택을 한 번에 들이는 일은 운영 부담만 키웁니다. 1 단계 구조화 로그 + 헬스체크부터 시작해 사고가 부족한 자리만 다음 단계로 가는 흐름이 가장 안전합니다.

Next

• github-actions
• vitest-pytest-infra

OpenTelemetry · W3C Trace Context · Prometheus · Grafana · Loki · Sentry · Charity Majors 글 을 참고합니다.