# 옵저버빌리티란? 개발팀을 위한 실전 가이드

URL: https://codebasechat.com/ko/journal/observability-jeongui
Type: blog
Locale: ko
Published: 2026-10-27
Updated: 2026-10-28

---

> 옵저버빌리티란 무엇이고 모니터링과 어떻게 다를까요? 5명에서 50명 규모의 개발팀을 위해 로그, 메트릭, 트레이스와 OpenTelemetry를 실무 중심으로 정리했습니다.

오전 2시입니다. 결제 엔드포인트가 요청 20건 중 약 1건에서 500 오류를 반환하고 있는데, 대시보드는 모두 초록색입니다. "시스템은 괜찮다고 말하는데 사용자는 고장났다고 말하는" 이 간극을 메우는 것이 옵저버빌리티가 존재하는 이유입니다. **옵저버빌리티란** 시스템이 내보내는 데이터(로그, 메트릭, 트레이스)를 보고 시스템 내부에서 무슨 일이 일어나는지 파악하는 능력이며, 미리 준비하지 않은 질문에도 답할 수 있는 상태를 뜻합니다.

마지막 조건이 이 글의 핵심입니다. 나머지는 모두 세부 사항입니다.

## 모니터링과 무엇이 다른가: 알림을 걸어 둔 적 없는 질문

모니터링은 이미 알고 있던 질문에 답합니다. CPU 사용률이 90%를 넘었는가? 오류율이 2%를 넘었는가? 큐 깊이가 늘고 있는가? 메트릭을 고르고 임계값을 정해 두면, 임계값을 넘을 때 호출기가 울립니다.

옵저버빌리티는 아직 던지지 않은 질문에 답합니다. 특정 테넌트가, 특정 앱 버전에서, 특정 배포 이후에만 요청이 4초씩 느려지는 이유는 무엇일까요? 이런 상황을 예측해서 알림을 만들어 둔 사람은 없습니다.

그래서 둘은 경쟁 관계가 아닙니다. 모니터링은 알림 계층이고, 옵저버빌리티는 알림이 울린 뒤, 또는 알림이 없는데 고객이 문의한 뒤에 원인을 조사하게 해 주는 능력입니다. 미리 만들어 둔 대시보드만 있다면 모니터링을 하고 있는 것입니다. 원하는 차원으로 운영 데이터를 잘라 보고, 새 코드를 배포하지 않고도 요청 하나를 여러 서비스에 걸쳐 따라갈 수 있다면 옵저버빌리티를 갖춘 것입니다.

## 세 가지 신호: 메트릭, 로그, 트레이스

대부분의 정의는 "세 가지 기둥"으로 시작합니다. 표현은 다소 딱딱하지만, 세 데이터 유형은 실제로 존재하며 각각 맡는 역할이 다릅니다.

- 
**메트릭**은 시간에 따른 숫자입니다. 요청 빈도, p95 지연 시간, 메모리 사용량이 여기에 해당합니다. 저장 비용이 낮고 조회가 빠르며 "무언가 잘못되었는가?"에 답하기 좋습니다. 하지만 "어떤 요청이, 그리고 왜?"에는 약합니다.

- 
**로그**는 개별 이벤트의 타임스탬프 기록입니다. 결제 실패, 재시도 발생, 기능 플래그 변경 같은 내용을 담습니다. 세부 정보는 풍부하지만, 바쁜 서비스의 구조화되지 않은 로그는 건초더미에서 바늘을 찾는 일이 됩니다.

- 
**트레이스**는 요청 하나가 여러 서비스를 지나가는 경로를 따라갑니다. 각 구간은 시작 시각, 소요 시간, 속성을 가진 스팬입니다. 분산 시스템에서 스택 트레이스에 가장 가까운 것이 트레이스입니다.

![로그 출력물 옆에 여러 서비스의 연결을 손으로 그린 다이어그램](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/f0aa73-i1.webp)

Grafana Labs가 실무자 1,255명을 대상으로 한 2025년 설문은 팀들이 실제로 어디에 있는지 보여 줍니다. [Grafana의 옵저버빌리티 설문](https://grafana.com/blog/2025/03/25/observability-survey-takeaways)에 따르면 응답자의 95%가 메트릭을, 87%가 로그를 사용했지만 트레이스를 쓰는 비율은 57%에 그쳤습니다. 분산 버그를 가장 잘 찾아 주는 신호가 트레이스인데, 이를 설정해 둔 팀이 가장 적다는 뜻입니다.

"메트릭은 무엇을, 로그는 왜를, 트레이스는 어디를 알려 준다"는 식의 요약은 쓰지 않는 편이 낫습니다. 깔끔해 보이지만 실무에서는 맞지 않습니다. 구조화가 잘된 로그 한 줄이 계측이 부실한 트레이스보다 "어디"에 대해 더 많은 것을 알려 주는 경우가 흔합니다.

## 실무에서 관측 가능한 시스템의 조건

데이터를 내보내는 것은 필요하지만 충분하지 않습니다. 시스템이 관측 가능하려면 데이터가 세 가지 속성을 갖춰야 합니다.

**높은 카디널리티.** 사용자 ID, 테넌트, 빌드 SHA, 리전, 기능 플래그로 필터링할 수 있어야 합니다. 도구가 서비스 이름과 상태 코드로만 미리 집계하게 만든다면, 잘못된 상태에 빠진 테넌트 하나를 찾을 수 없습니다.

**신호를 잇는 맥락.** 모든 로그 줄에 트레이스 ID가 있으면 느린 스팬에서 그 스팬이 남긴 정확한 로그로 바로 이동할 수 있습니다. 이 연결이 없으면 두 개의 이야기를 따로 읽고, 둘이 어떻게 이어지는지 추측해야 합니다.

**유용할 만큼의 세부 정보, 감당할 수 있는 비용.** 대부분의 팀이 여기서 애를 먹습니다. 같은 Grafana 설문에서 응답자들은 모두 합쳐 100개가 넘는 서로 다른 도구, 서비스, 프로젝트를 언급했고, 팀당 평균은 여덟 개였습니다. 도구를 고를 때 비용은 상위권 기준이었습니다. 모든 것을 수집하는 것은 쉽습니다. 그 비용을 감당하는 일은 나중에 알게 됩니다.

벤더 중립 계측 표준인 OpenTelemetry로 시작하면 다음과 같습니다. 스팬 하나를 만들고 새벽 2시에 필요할 속성들을 붙이는 최소한의 Python 예제입니다.

`from opentelemetry import trace

tracer = trace.get_tracer("checkout")

def charge(order):
    with tracer.start_as_current_span("charge_card") as span:
        span.set_attribute("order.id", order.id)
        span.set_attribute("tenant.id", order.tenant_id)
        span.set_attribute("app.version", APP_VERSION)
        result = payment_client.charge(order)
        span.set_attribute("payment.provider", result.provider)
        return result`세 개의 속성이 "결제가 느리다"와 "버전 3.8.1에서 테넌트 4412의 결제가 느리다" 사이의 차이를 만듭니다. [OpenTelemetry 옵저버빌리티 입문서](https://opentelemetry.io/docs/concepts/observability-primer/)는 이 예제 뒤의 개념을 더 깊이 설명하며, 벤더가 설정을 대신해 주더라도 한 번 읽어 볼 만합니다.

## 도구마다 다른 점과 같은 점

마케팅 문구를 걷어내면 대부분의 플랫폼은 같은 세 가지 신호를 수집합니다. 차이는 가격 모델, 질의 능력, 계측을 얼마나 대신해 주는지에 있습니다.

- 
**올인원 플랫폼**은 메트릭, 로그, 트레이스, 알림 등을 한데 묶어 제공합니다. 편리하지만, 트래픽에 따라 청구액이 늘어나는 사용량 기반 요금이 따라옵니다.

- 
**오픈소스 스택**(Prometheus, Loki, Tempo, Grafana 등)은 제어권을 주고 호스트별 라이선스 비용이 없습니다. 대신 직접 운영하고 튜닝해야 합니다.

- 
**OpenTelemetry 네이티브 백엔드**는 표준 형식을 그대로 받아들이므로, 벤더를 바꿔도 모든 서비스를 다시 계측할 필요가 없습니다.

Datadog은 올인원 범주의 기준점입니다. 넓은 기능 범위와 세련된 UI를 제공하지만, 청구서를 매달 검토할 만한 가격입니다. 벤더를 하나로 가져가고 예산이 충분하다면 가치가 있습니다. 비용 예측 가능성이 가장 중요하다면 피하는 편이 좋습니다.

Grafana는 실용적인 오픈소스 선택입니다. 이미 가진 데이터 위에 대시보드부터 시작하고, 필요해지면 로그와 트레이스를 추가할 수 있습니다. 엔지니어링 시간을 어느 정도 투자해야 합니다.

![여러 구간으로 나뉜 분산 트레이스 워터폴이 노트북 화면에 표시된 모습](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/fb03e7-i2.webp)

SigNoz는 처음부터 OpenTelemetry를 중심으로 설계되었고, 메트릭, 로그, 트레이스를 하나의 오픈소스 인터페이스에 담습니다. 올인원 가격 없이 단일 화면 경험을 원하는 팀에 맞는 선택입니다.

New Relic은 두 세계의 중간에 있습니다. 호스팅 플랫폼을 제공하고, 실제 평가가 가능할 만큼 넉넉한 무료 티어가 있습니다. 데모가 아니라, 우리 팀이 실제 운영 질문에 이 도구로 답할 수 있는지를 기준으로 판단하는 것이 맞습니다.

이 중 어느 것도 그 자체로 시스템을 관측 가능하게 만들지는 못합니다. 도구는 질의 인터페이스일 뿐이고, 계측이 핵심입니다.

## 대부분의 가이드가 건너뛰는 부분: 관측은 코드 경계에서 멈춘다

이 도구들을 제대로 쓰기 시작하면 금방 눈에 띄는 간극이 있습니다. 트레이스는 `charge_card`가 3.9초 걸렸고, 느린 부분이 `payment_client` 호출이었다고 알려 줍니다. 하지만 `payment_client`가 실제로 무엇을 하는지, 누가 작성했는지, 왜 백오프 없이 세 번 재시도하는지는 알려 주지 않습니다.

그 답을 얻으려면 관측 도구를 떠나 코드를 읽어야 합니다. 작은 서비스라면 10분이면 됩니다. 네 개 팀이 나눠 맡은 10만 줄짜리 저장소라면, 읽는 시간이 장애 대응에서 가장 긴 부분이 되기도 합니다. 어떤 스팬이 느린지는 정확히 알지만, 그 뒤 코드가 어떻게 연결되어 있는지 파악하느라 한 시간을 씁니다.

이것이 런타임 데이터와 소스 코드 사이의 연결 문제이며, 옵저버빌리티와 코드 이해를 하나의 워크플로를 이루는 두 절반으로 보는 이유입니다.

- 
옵저버빌리티는 런타임에서 **어디**인지를 알려 줍니다. 어떤 서비스, 어떤 스팬, 어떤 테넌트인지입니다.

- 
코드 이해는 소스에서 **왜**인지를 알려 줍니다. 어떤 함수, 어떤 재시도 정책, 어떤 설정인지입니다.

이 고리를 닫은 팀은 "알림 발생"에서 "수정 원인 이해"까지의 시간을 줄입니다. 스팬 이름이 파일에 대응되고, 파일이 담당자와 설명에 대응되는 상태를 말합니다. 대부분 규율의 문제입니다. 스팬 이름을 함수 이름으로 짓고, 저장소 경로를 스팬 속성에 넣고, 서비스마다 짧은 아키텍처 메모를 유지하는 것입니다. 그러면 "결제 호출의 재시도 정책은 어디에 설정되어 있나요?" 같은 질문에 답하는 AI 어시스턴트도 실제로 기댈 수 있는 근거를 갖게 됩니다.

![코드 에디터와 메트릭 대시보드를 나란히 띄우고 작업하는 개발자](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/5fe138-i3.webp)

## 옵저버빌리티가 안 된다고 느끼게 만드는 세 가지 실수

**대시보드를 목표로 삼기.** 대시보드는 오래된 질문에 대해 저장해 둔 답입니다. 대시보드를 40개 만들고 애드혹 질의를 한 번도 연습하지 않은 팀은 결국 더 예쁘게 포장된 모니터링을 갖게 됩니다. 장애가 날 때마다 이렇게 물어보는 것이 좋습니다. 이 질문에 대시보드로 답했는가, 아니면 원시 데이터를 직접 탐색해서 답했는가?

**샘플링을 너무 일찍 하거나 아예 하지 않기.** 바쁜 서비스에서 트레이스를 100% 보관하면 비용이 빠르게 늘고, 무작위로 1%만 보관하면 정작 중요한, 드물게 실패하는 요청을 버리게 됩니다. 보통은 테일 기반 샘플링이 절충안입니다. 느리거나 실패한 트레이스는 남기고 대부분의 정상 트레이스는 버립니다. 첫 청구서가 나오기 전에 결정해 두는 것이 좋습니다.

**속성 이름이 제각각 되기.** 한 서비스는 `user_id`, 다른 서비스는 `userId`, 세 번째는 `uid`를 씁니다. 이제 셋 모두를 가로질러야 하는 질의가 전체 그림의 3분의 1만 보여 줍니다. 테넌트, 사용자, 버전, 플래그 속성에 대한 작은 명명 규칙을 정하고, 사람들이 찾을 수 있는 저장소에 적어 두는 것이 좋습니다.

이것들은 도구의 문제가 아닙니다. 습관의 문제이고, 습관은 벤더를 바꾸는 것보다 고치기 쉽습니다.

## 바다를 끓이지 않고 시작하는 현실적인 방법

지금 아무것도 없다면, 첫 주에 모든 것을 계측하려는 충동은 참는 편이 낫습니다. 엔지니어 5명에서 50명 규모의 팀에 잘 맞는 순서는 다음과 같습니다.

- 
**핵심 사용자 흐름 하나를 고릅니다.** 결제, 가입, 주요 API 호출처럼 시스템 전체가 아니라 한 가지 흐름입니다.

- 
**요청 ID가 포함된 구조화된 로그를 추가합니다.** JSON 형식에 한 줄당 이벤트 하나, 모든 줄에 트레이스 또는 요청 ID를 넣습니다.

- 
**그 흐름에 OpenTelemetry 트레이스를 계측합니다.** 위 예제의 테넌트, 버전, 플래그 속성을 포함합니다.

- 
**서비스 수준 목표(SLO) 두세 개를 정합니다.** 예를 들어 결제 요청의 99.5%가 800 ms 안에 성공하는 식입니다. 알림은 CPU가 아니라 이 목표에 걸어 둡니다.

- 
**실제 장애 하나를 데이터와 대조해 검토합니다.** 새 코드를 배포하지 않고도 원인을 찾을 수 있었습니까? 못 찾았다면, 발견한 공백이 다음 계측 작업입니다.

다섯 번째 단계가 가장 자주 건너뛰어지지만, 여러분이 관측 가능한 상태인지 알려 주는 유일한 단계입니다. 나머지는 배관 작업입니다.

## 저희라면 이렇게 합니다

엔지니어가 20명 미만이라면 OpenTelemetry 계측과 가격을 예측할 수 있는 백엔드로 시작하는 것이 좋습니다. 계측 코드는 이식이 가능하므로 백엔드 선택은 되돌릴 수 있습니다. 경쟁사가 가장 큰 플랫폼을 샀다는 이유로 따라 살 필요는 없습니다.

이미 올인원 도구에 비용을 내고 있다면 전부 뜯어낼 필요는 없습니다. 수집 중인 데이터를 감사하고, 아무도 조회하지 않는 로그를 줄인 뒤, 절약한 비용을 중요한 흐름의 계측에 쓰는 편이 낫습니다.

어느 쪽을 택하든, 스팬이 코드의 어디에 대응하는지 적어 두는 것이 좋습니다. 대시보드는 불이 났다는 것만 보여 줍니다. 왜 불이 시작되었는지는 결국 누군가 소스를 읽어야 알 수 있습니다.

## FAQ

### 옵저버빌리티란 쉽게 말해 무엇인가요?

시스템이 만들어 내는 데이터로 내부에서 무슨 일이 일어나는지 얼마나 잘 파악할 수 있는지를 뜻합니다. 예측하지 못한 문제의 원인을 로그, 메트릭, 트레이스로 찾을 수 있고 새 코드를 배포할 필요가 없다면, 그 시스템은 관측 가능한 상태입니다.

### 옵저버빌리티와 모니터링의 차이는 무엇인가요?

모니터링은 미리 정한 메트릭과 임계값으로 알려진 문제를 지켜봅니다. 옵저버빌리티는 상세한 텔레메트리를 탐색해 알려지지 않은 문제를 조사할 수 있게 해 줍니다. 모니터링은 알림 계층이고, 옵저버빌리티는 알림이 울린 뒤 원인을 찾는 데 쓰는 능력입니다.

### 옵저버빌리티의 세 가지 기둥은 무엇인가요?

메트릭, 로그, 트레이스입니다. 메트릭은 시간에 따른 숫자이고, 로그는 개별 이벤트의 기록이며, 트레이스는 하나의 요청을 여러 서비스에 걸쳐 따라갑니다. 공유 ID로 서로 연결될 때 가장 유용합니다.

### 옵저버빌리티를 갖추려면 OpenTelemetry가 필요한가요?

필수는 아니지만 도움이 됩니다. OpenTelemetry는 로그, 메트릭, 트레이스를 내보내기 위한 벤더 중립 표준입니다. 이 표준으로 계측해 두면 나중에 서비스를 다시 계측하지 않고도 옵저버빌리티 백엔드를 바꿀 수 있습니다.

### 옵저버빌리티는 마이크로서비스에만 필요한가요?

아닙니다. 요청 하나가 여러 서비스를 거치는 분산 시스템에서 효과가 가장 크지만, 데이터베이스, 큐, 외부 API 몇 개를 쓰는 모놀리스도 구조화된 로그와 트레이스의 혜택을 봅니다.

### 옵저버빌리티 비용은 얼마나 드나요?

데이터 양과 도구에 따라 다릅니다. 호스팅 플랫폼은 보통 사용량에 따라 과금되어 트래픽이 늘면 청구액도 늘고, 오픈소스 스택은 라이선스 비용을 엔지니어링 시간과 맞바꿉니다. 사용하지 않는 로그를 버리고 트레이스를 샘플링하는 것이 비용을 통제하는 가장 흔한 두 가지 방법입니다.