옵저버빌리티란? 관측성 개념부터 3대 시그널, 도입 순서까지
옵저버빌리티(관측성)가 무엇인지 모니터링과의 차이부터 설명합니다. 로그·메트릭·트레이스 3대 시그널, 장애 예방 방법론, 단계별 도입 순서와 FAQ.
옵저버빌리티(observability, 한국어로 '관측성')란, 시스템이 밖으로 보내는 데이터 — 로그(logs), 메트릭(metrics), 트레이스(traces) — 만으로 시스템 내부 상태를 추론할 수 있는 능력을 말합니다. 제어 이론에서 온 개념으로, 기계를 뜯지 않고 계기판만 보고 내부에서 무슨 일이 일어나는지 알 수 있는가의 문제입니다. 옵저버빌리티가 높은 시스템은 처음 보는 장애가 나도, 데이터를 따라가면 원인에 도달할 수 있습니다.
왜 지금 옵저버빌리티인가 — 장애가 달라졌습니다
10년 전의 장애와 지금의 장애는 성격이 다릅니다.
- 시스템이 흩어졌습니다. 마이크로서비스 환경에서 요청 하나는 로드밸런서, API 게이트웨이, 여러 서비스, 메시지 큐, 데이터베이스를 지납니다. 장애 지점은 그중 어디든 될 수 있습니다.
- 시스템이 움직입니다. 쿠버네티스와 오토스케일링 때문에 서버 목록은 매분 바뀝니다. "3번 서버가 죽었다"는 식의 단순한 진단이 통하지 않습니다.
- 장애가 처음 보는 모양으로 옵니다. 알고 있는 장애(known unknowns)는 알람으로 잡을 수 있지만, 처음 보는 장애(공개 자료에 명시되지 않음 unknowns)는 사전에 규칙을 만들 수 없습니다.
옵저버빌리티는 바로 이 세 번째 문제, "미리 알람을 걸 수 없는 장애"를 다루는 방법론입니다. 사고가 나고 나서 데이터에 자유롭게 질문을 던져 원인을 찾는 것이 핵심입니다.
모니터링과 뭐가 다른가
| 기준 | 모니터링 | 옵저버빌리티 |
|---|---|---|
| 답하는 질문 | 시스템에 문제가 있나? | 왜 문제가 생겼나? |
| 다루는 장애 | 아는 장애(사전 정의된 알람) | 처음 보는 장애(사후 자유 탐색) |
| 데이터 | 집계된 지표 위주, 양이 적음 | 원본 이벤트 보존, 고카디널리티 질의 |
| 하는 일 | 대시보드 확인, 알람 수신 | 사용자 민원에서 출발해 근본 원인까지 드릴다운 |
둘은 대체 관계가 아닙니다. 모니터링은 옵저버빌리티의 한 부분입니다. 메트릭 알람이 "문제가 있다"를 가장 먼저 알려주고, 로그와 트레이스가 "왜"를 답합니다.
관련 가이드Kubernetes란? 개념·작동 원리·도입 판단 기준→
세 가지 시그널: 로그, 메트릭, 트레이스
메트릭(metrics) — 일정 간격으로 재는 숫자입니다. CPU 사용률, 초당 요청 수, p99 지연 같은 것들입니다. 부피가 작고 집계가 쉬워 알람과 장기 추세에 적합하지만, 집계되는 과정에서 디테일이 사라집니다.
로그(logs) — 시스템이 순간순간 남기는 사건 기록입니다. 에러 스택, 요청 상세 같은 것들로 디테일이 가장 풍부하지만, 양이 많고 형식이 제각각이라 모아서 인덱싱하지 않으면 장애 때 못 씁니다.
트레이스(traces) — 요청 하나가 여러 서비스를 지나는 전체 경로를 구간(span)별로 기록한 것입니다. 마이크로서비스 환경에서 "어디가 느린가"는 사실상 트레이스로만 답할 수 있습니다. 자세한 내용은 APM 뜻과 분산 추적을 참고하세요.
셋은 각각이 아니라 연결될 때 답이 됩니다. 메트릭 알람이 울리고 → 트레이스로 느린 서비스를 찾고 → 로그에서 그 시각의 에러를 확인하는 흐름입니다.
플랫폼이 필요한 이유 — 상관관계(correlation)
세 시그널을 따로 모으는 것은 어렵지 않습니다. 어려운 것은 연결입니다. 같은 trace ID를 로그에서 바로 검색할 수 있어야 하고, 같은 호스트의 메트릭이 그 위의 서비스와 연결돼야 합니다. 옵저버빌리티 플랫폼의 가치는 이 지점에 있습니다. 통합 데이터 모델 위에서 RUM(실사용자 모니터링), 합성 모니터링(synthetics), 인프라 지표까지 한 화면에서 묶어냅니다. 도구가 시그널 하나를 해결한다면, 플랫폼은 시그널 사이의 연결을 해결합니다.
도입 순서 — 한 번에 다 하지 마세요
- 1단계 — 메트릭 알람: 핵심 서비스의 RED 지표(rate, errors, duration)를 대시보드에 올리고 기본 알람을 겁니다.
- 2단계 — 로그 중앙화: 여러 서버에 흩어진 로그를 한곳에 모아 전문 검색이 되게 합니다.
- 3단계 — 분산 추적: OpenTelemetry(벤더 종속을 피하는 오픈 표준)로 핵심 거래 경로에 트레이스를 붙입니다.
- 4단계 — 상관관계와 SLO: 공통 태그로 세 시그널을 잇고, SLO(서비스 수준 목표)와 에러 버짓으로 알람 우선순위를 관리합니다.
어느 단계에서 막혀도 그 단계까지의 투자는 남습니다. 처음부터 플랫폼 전체를 사들이는 것보다, 이 순서가 실패율이 낮습니다.
관련 가이드APM 뜻: 애플리케이션 성능 모니터링의 원리와 실무→
자주 묻는 질문
Q. 옵저버빌리티 뜻이 정확히 뭔가요?
시스템이 외부로 보내는 데이터(로그·메트릭·트레이스)만으로 내부 상태를 추론할 수 있는 능력입니다. 제어 이론의 observability를 IT 시스템에 옮긴 개념으로, "관측성"이라고도 합니다. 처음 보는 장애의 원인을 데이터로 추적할 수 있으면 관측성이 높은 것입니다.
Q. 옵저버빌리티는 도구를 사면 생기나요?
아니요. 먼저 시스템의 속성이고 팀의 실천입니다. 코드가 충분한 시그널을 보내야 하고, 태그 규칙이 통일돼야 하고, 런북이 있어야 합니다. 도구는 그 시그널을 조회 가능하게 할 뿐입니다. 실천 없는 플랫폼은 비싼 대시보드에 그칩니다.
Q. 작은 팀에도 필요한가요?
모놀리스 하나에 VM 몇 대라면 기본 메트릭과 로그 중앙화로 충분합니다. 옵저버빌리티의 가치는 서비스 수와 장애 비용에 비례해 커집니다. 마이크로서비스로 가고 있거나, SLA 약속이 있거나, 온콜 로테이션을 돌리는 팀이라면 빠를수록 좋습니다.
Q. OpenTelemetry와 무슨 관계인가요?
OpenTelemetry(OTel)는 세 시그널을 만들고 운반하는 오픈 표준입니다. "데이터를 어떻게 수집할 것인가"가 OTel이고, "데이터를 어떻게 저장·연결·조회할 것인가"가 플랫폼입니다. OTel로 수집해 아무 호환 플랫폼으로 보내는 조합이 벤더 종속을 피하는 표준적인 방법입니다.
Q. 비용이 많이 들지 않나요?
관리하지 않으면 그렇습니다. 비용의 대부분은 고카디널리티 메트릭, 로그 전량 인덱싱, 트레이스 전량 보존에서 나옵니다. 메트릭 카디널리티 축소, 로그 등급별 보존, 트레이스 샘플링이 표준적인 통제 수단입니다. 개념과 계산은 Observability Fundamentals Guide(영문)를 참고하세요.
