Observability & Telemetry Physics

1. Overview

관측 가능성과 텔레메트리 물리학(Observability & Telemetry Physics)은 시스템이 죽었을 때 "서버가 다운됐습니다"라는 현상만 알려주는 멍청한 알람을 버리고, "왜 다운됐으며, 어느 함수의 몇 번째 줄에서 병목이 났는가"를 심문하여 시스템의 뇌를 투명하게 까발리는 내부 투시경을 해부합니다.

학습자는 수만 줄의 로그 텍스트를 눈으로 읽는 원시적 노가다를 끝내고, **로그(Logs), 메트릭(Metrics), 트레이스(Traces)**라는 관측 가능성의 3본주(Three Pillars)를 조립하여 입체적인 사각지대 박멸망을 뜯어봅니다. 나아가 사용자 요청이 30개의 마이크로서비스를 넘나들며 길을 잃을 때, 꼬리표(Trace ID)를 달아 전체 여정을 하나의 그래프로 그려내는 **분산 추적(Distributed Tracing)**을 장악합니다. 마지막으로, 방대한 데이터를 공통 규격으로 수집(OpenTelemetry)하고 샘플링(Sampling)하여 디버깅 비용과 스토리지 비용의 균형을 맞추는 텔레메트리 아키텍처 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Observability (관측 가능성) vs Monitoring: 외부 상태를 '감시'하는 모니터링을 넘어, 내부 상태를 추론할 수 있는 아키텍처적 특성(Observability).
• The Three Pillars (3본주):
  1. Logs (점핑 불가한 이벤트의 기록)
  2. Metrics (시계열 데이터, 시스템의 건강 상태)
  3. Traces (요청의 생애 주기와 인과관계)
• Distributed Tracing (분산 추적): Trace ID, Span ID, Context Propagation (문맥 전파).
• OpenTelemetry: 특정 벤더(Datadog, New Relic)에 종속되지 않는 표준 계측(Instrumentation) 프레임워크.

Out-of-Scope

• Prometheus/Grafana/ELK 구축 및 쿼리 문법: PromQL 작성법이나 Kibana 대시보드 클릭 튜토리얼 $\rightarrow$ 도구 종속적 지식이므로 본 문서에서는 '어떤 데이터를 왜 수집해야 하는가'라는 데이터 물리학에 집중함.
• SLO/SLI 기반 경고(Alerting) 전략: 에러율이 몇 % 일 때 알람을 울릴 것인가 $\rightarrow$ 09-06-02 SLO & Error Budget 영역으로 분리.

Boundaries

• 모니터링(Monitoring) vs 관측 가능성(Observability): 모니터링은 대시보드에 "CPU가 100%다!(What)"라고 띄워주는 행위입니다. 관측 가능성은 한 걸음 더 나아가, "주문 서비스의 쿠폰 계산 로직에서 무한 루프가 돌아서 CPU가 100%가 됐다(Why)"고 대답할 수 있게 시스템이 자신의 창자를 미리 열어두는 설계적 속성입니다. 모니터링은 우리가 '아는 문제'를 감시하지만, 관측 가능성은 우리가 '상상하지 못한 미지의 문제(Unknown-Unknowns)'를 추적하게 해준다는 철학적 경계를 명확히 긋습니다.

3. Counterexample

• 장님 코끼리 만지기 (분산 추적 부재): 결제 실패 알람이 울립니다. 유저가 버튼을 눌렀는데 에러가 났답니다. MSA 환경입니다. A(웹) $\rightarrow$ B(주문) $\rightarrow$ C(할인) $\rightarrow$ D(PG연동) $\rightarrow$ E(포인트) 5개의 서버가 엮여 있습니다. 개발자 5명이 각자 자기 서버 로그만 grep으로 까봅니다. "제 서버엔 에러 없는데요?" 5명 모두 자신의 서버가 범인이 아니라고 우깁니다. 하나의 유저 요청을 관통하는 끈(Trace ID)이 없어, 시스템 전체가 거대한 블랙박스 미궁에 빠져 며칠을 날려 먹는 참사입니다.
• 무지성 로그 폭탄 (비용 폭주): 시스템을 투명하게 만들겠다며, 20대 주니어 개발자가 모든 함수 시작과 끝에 Info 로그를 박고 JSON 페이로드를 통째로 찍어버렸습니다. 트래픽이 몰리는 이벤트 날, 엄청난 I/O 부하로 디스크가 꽉 차서(Disk Full) 정작 비즈니스 로직 서버가 죽어버렸습니다. 더 끔찍한 건, 하루 1TB씩 쌓이는 로그를 AWS CloudWatch에 넣었다가 로그 보관 비용만 월 5천만 원을 청구받은 데이터 수집(Telemetry) 무지의 결말입니다.

4. Prerequisites

• 마이크로서비스 아키텍처 (Basic): 네트워크 홉(Hop)이 늘어날 때 디버깅이 미치도록 어려워지는 이유. (07-04-01 Microservices)
• 로깅 스탠다드 (Basic): 에러(Error), 인포(Info), 디버그(Debug) 레벨 분리. (09-01-04 Construction)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 블랙박스를 유리 상자로 (Observability vs Monitoring)

• Why to Learn: 대시보드에 빨간불이 들어왔을 때 "어... 서버 껐다 켜볼게요"라고 기도하는 주술사 엔지니어를 벗어나, 데이터로 원인을 즉각 추론하는 외과 의사로 진화하기 위함입니다.
• What to Learn:
  • Concepts: Monitoring (모니터링), Observability (관측 가능성), Known-Unknowns vs Unknown-Unknowns, System Internal State.
  • Skills: "CPU 사용량 > 90%"라는 모니터링 룰을 세우는 것을 넘어, 외부에서 튀어나온 출력물(로그, 메트릭)만 보고도 "장바구니 로직의 N+1 쿼리 때문에 CPU가 터졌군"이라고 내부 상태(Internal State)를 역추적(Infer)할 수 있게 코드에 측정 장치(Instrumentation)를 미리 박아 넣기.
• How to Learn:
  • 1단계: 모니터링 (대시보드 쳐다보기): "디스크 용량이 90% 남았다"는 걸 감시합니다. 이건 우리가 '뭐가 고장 날지 이미 아는(Known-Unknowns)' 것들입니다. 하지만 복잡한 현대 클라우드는 우리가 '상상도 못한(Unknown-Unknowns)' 방식으로 고장 납니다.
  • 2단계: 관측 가능성 (질문할 수 있는 능력): 시스템이 뻗었을 때, "오늘 가입한 안드로이드 유저 중 특정 쿠폰을 쓴 사람들의 쿼리 응답 속도가 어때?"라고 **즉흥적인 질문(Query)**을 던질 수 있어야 합니다.
  • 3단계: 설계의 패러다임 전환: 관측 가능성은 툴(Datadog)을 돈 주고 산다고 얻어지는 게 아닙니다. 개발자가 코드를 짤 때 "이 로직이 실패하면 미래의 내가 무슨 데이터를 보고 싶을까?"를 고민하며 맥락(Context)을 듬뿍 담은 고품질의 텔레메트리 데이터를 뿜어내도록 설계(Design)하는 철학임을 해부합니다.
• Implement: 관측 가능성(Observability) 디버깅 한계 비교. Monitoring Only: [Alert: CPU 100%]. 개발자 $\rightarrow$ "서버 재시작합시다." (원인 미상, 내일 또 터짐). Observable System: [Alert: CPU 100%] $\rightarrow$ 대시보드 드릴다운(Drill-down) $\rightarrow$ [Metric] DB Connection Pool 소진 $\rightarrow$ [Trace] OrderService.pay()에서 5초 지연 $\rightarrow$ [Log] "Timeout waiting for PG" (PG사 네트워크 단절 확인 완료). 미지의 에러를 3단 콤보로 멱살 잡는 시각화.

Recommended

Core Topic 02: 진실을 추적하는 삼각 편대 (The Three Pillars)

• Why to Learn: 무지성으로 텍스트 로그(Log)만 산더미처럼 쌓아두고 "왜 버그 못 잡아!"라며 절규하는 낭비를 끝내고, 수치(Metric), 텍스트(Log), 여정(Trace)을 용도에 맞게 조합하는 레이더망을 짜기 위함입니다.
• What to Learn:
  • Concepts: Metrics (메트릭/시계열 수치), Logs (로그/이벤트 기록), Traces (트레이스/분산 추적), Cardinality (카디널리티).
  • Skills: "초당 요청 수(RPS)"는 숫자로 뭉뚱그려(Metric) 저장 비용을 아끼고, "DB 데드락 에러"는 상세 텍스트(Log)로 남기며, "A $\rightarrow$ B $\rightarrow$ C 서비스 호출 흐름"은 타임라인 그래프(Trace)로 그려내는 3본주 적재적소 분배하기.
• How to Learn:
  • 1단계: Metrics (숲을 보는 드론): "메모리 80%, 에러율 2%". 가벼운 숫자표(Time-series)입니다. 1달 치 데이터를 모아도 용량이 작습니다. 알람(Alert)을 울리는 방아쇠 역할을 합니다. 하지만 "어떤 유저가 에러 났지?"는 알 수 없습니다.
  • 2단계: Traces (경찰견의 코): 메트릭 알람이 울리면, 트레이스를 엽니다. "요청이 A 서버(1초) $\rightarrow$ B 서버(3초) $\rightarrow$ C 서버(터짐)로 흘러갔구나!" 병목이 발생한 **범인 서버(위치)**를 찾아냅니다.
  • 3단계: Logs (수술용 현미경): 범인 서버(C)를 찾았으니, 그 서버의 텍스트 로그만 집중적으로 깝니다. "유저 123번이 Null 포인터를 넣었네." 메트릭(알림) $\rightarrow$ 트레이스(위치 추적) $\rightarrow$ 로그(원인 분석)로 이어지는 물 흐르는 듯한 삼각 편대 디버깅 파이프라인을 뜯어봅니다.
• Implement: 3본주 비용-가치 트레이드오프 분석기. 상황: 모든 유저 클릭 이벤트를 텍스트 Log로 저장 $\rightarrow$ 하루 500GB, 검색 속도 극악. 최적화: 클릭 수량 증가는 숫자 카운터(Metric)로 분리 저장(하루 50MB). 에러가 난 클릭만 Context를 묶어 Log/Trace로 저장. 데이터 성격(Cardinality)에 맞춰 스토리지를 분리하여 관측 비용(Observability Cost)을 1/100로 압살하는 엔지니어링 렌더링.

Practical

Core Topic 03: 형광물질과 엑스레이 (Distributed Tracing)

• Why to Learn: 30개의 마이크로서비스가 거미줄처럼 얽힌 상황에서, 중간에 길을 잃고 터져버린 사용자의 요청을 찾기 위해 30대의 서버 로그를 일일이 까보는 미친 노가다를 단 한 줄의 그래프로 종결하기 위함입니다.
• What to Learn:
  • Concepts: Trace ID, Span ID, Context Propagation (문맥 전파), HTTP Headers (e.g., X-B3-TraceId), Gantt Chart.
  • Skills: 유저가 최초로 시스템에 진입할 때 부여된 Trace ID를, HTTP 통신을 타고 뒷단 서버, 그 뒷단 DB 쿼리까지 릴레이 바톤처럼 넘겨주며(Context Propagation) 하나의 긴 띠(Trace)로 엮어내기.
• How to Learn:
  • 1단계: 거미줄 속의 미아: 유저가 "주문하기"를 눌렀습니다. API Gateway $\rightarrow$ Order $\rightarrow$ Inventory $\rightarrow$ Payment 순으로 호출되다 죽었습니다. 어디서 죽었을까요?
  • 2단계: 형광물질 바르기 (Trace ID): API Gateway에 들어온 순간, 기계가 이 요청에 Trace-1234라는 고유 형광물질 표표(Header)를 바릅니다. Order가 Inventory를 호출할 때도 이 꼬리표를 같이 던져줍니다(Propagation).
  • 3단계: 엑스레이 촬영 (Gantt Chart): 툴(Jaeger, Zipkin)을 엽니다. Trace-1234를 검색합니다. [API Gateway: 5초] ----------------------------- ↳ [Order: 4.8초] --------------------------- ↳ [Inventory: 0.1초] - ↳ [Payment: 4.5초] ----------------------- (에러!) 시각화된 간트 차트 한 방에 "아, 결제 서버가 4.5초 동안 응답을 안 해서 전체가 5초 동안 멈춰 있었고 결국 터졌구나!"를 1초 만에 파악하는 분산 시스템 최고의 무기(Weapon)를 해부합니다.
• Implement: Context Propagation (문맥 전파) 단절 디버깅 모사. 버그 상황: 간트 차트가 Order 서비스에서 뚝 끊김. Payment 기록이 안 보임. 원인 분석: Order 개발자가 Payment로 HTTP API를 쏠 때, Header에 TraceID를 빼먹고 새로 요청을 쏨. (형광물질 단절). 해결: 글로벌 인터셉터(Interceptor) 패턴을 박아넣어 개발자가 의식하지 않아도 헤더가 자동 릴레이(Relay)되도록 인프라 레벨에서 강제하는 시각화.

Advanced

Core Topic 04: 비용의 공포, 오픈텔레메트리와 샘플링 (OpenTelemetry & Sampling Physics)

• Why to Learn: 특정 벤더(Datadog, New Relic)의 감시 툴에 코드가 종속되어 툴을 바꿀 때 코드를 싹 다 엎어야 하는 벤더 락인(Vendor Lock-in)을 막고, 쓸모없는 정상 로그 수집 비용으로 회사가 파산하는 것을 막기 위함입니다.
• What to Learn:
  • Concepts: OpenTelemetry (OTel), Vendor Lock-in, Instrumentation, Head-based Sampling, Tail-based Sampling.
  • Skills: 코드에는 중립적인 OTel 표준 API만 심어놓고, 뒤에서 텔레메트리 콜렉터(Collector)가 데이터를 모아 Datadog이나 오픈소스로 입맛에 맞게 뿌려주는 아키텍처 설계하기. 정상 요청은 10%만 수집하고, 에러난 요청은 100% 긁어모으는 지능형 샘플링 도입하기.
• How to Learn:
  • 1단계: 노예 계약 (Vendor Lock-in): 코드 여기저기에 datadog.trace()를 박아놨습니다. 내년에 경쟁사 툴이 3배 싸게 나왔는데 코드를 못 뜯어고쳐서 이사를 못 갑니다.
  • 2단계: 표준화의 구원 (OpenTelemetry): CNCF의 2인자 프로젝트입니다. 코드에는 otel.span()이라는 범용(Standard) 인터페이스만 씁니다. 데이터가 수집기(Collector)로 모이면, 수집기가 설정 파일 1줄만 바꿔서 "오늘부터 이 데이터를 AWS로 쏴라"고 라우팅해 줍니다. 벤더 독립성의 완성입니다.
  • 3단계: 파산 방어 (Sampling): 1초에 1만 번 들어오는 200 OK 정상 결제 로그를 다 저장하면 서버 비용보다 로그 저장 비용이 비싸집니다. 앞단에서 무작위 10%만 남기고 버리는 헤드 샘플링(Head Sampling)과, 끝까지 지켜보다가 에러(500 Fail)가 나거나 3초 이상 지연된 '비정상 요청'만 100% 건져 올리는 테일 샘플링(Tail Sampling)의 극강의 비용 통제 역학을 뜯어봅니다.
• Implement: OTel Collector 기반의 지능형 Tail-Sampling 룰 렌더링. Traffic: 초당 10,000건의 트랜잭션. (정상 9,990건, 500에러 10건). Sampling Rule (Collector): if (http.status_code == 500 or latency > 2s) { 100% 수집 } else { 1% 수집 }. Result: 하루 저장 비용 1,000만 원 $\rightarrow$ 20만 원으로 98% 압살. 가장 필요한 '버그 데이터'의 손실은 0%를 유지하는 데이터 엔지니어링 렌더링.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - Software Reliability (Observability and Monitoring)
• [P5] SFIA - IT Operations (ITOP) - System monitoring and Observability

Secondary

• [Distributed Systems Observability] Cindy Sridharan - The Three Pillars (Logs, Metrics, Traces)
• [Site Reliability Engineering (Google)] - Monitoring Distributed Systems

Industry

• [OpenTelemetry.io] - What is OpenTelemetry? (Standardizing telemetry data)
• [Datadog Blog / Honeycomb] - Observability vs Monitoring (Unknown-Unknowns)

9. Final Checklist

Primary

• 대시보드에 "CPU 사용률 100%" 알람이 떴지만 원인을 몰라 서버를 무작정 재시작(Monitoring 한계)하는 상황과 대비하여, 관측 가능성(Observability)이 갖춰진 시스템에서 쿼리 한 번으로 "특정 캐시 미스(Cache Miss) 패턴"을 잡아내는 추론 과정을 설명할 수 있는가?
• "총 접속자 수"처럼 가벼운 시계열 수치는 메트릭(Metric)으로, "A 서비스 $\rightarrow$ B 서비스 응답 지연"은 트레이스(Trace)로, "DB 데드락 에러 덤프"는 텍스트 로그(Log)로 적재적소에 데이터를 분류하여 스토리지 비용을 아낄 수 있는가?

Secondary

• 마이크로서비스 10개가 엮인 시스템에서, 유저의 요청이 API Gateway를 통과할 때 발급된 Trace ID가 HTTP 헤더(W3C Trace Context)를 통해 어떻게 끝단 DB 서버까지 전달(Context Propagation)되어 간트 차트를 완성하는지 증명할 수 있는가?
• 개발자들이 코드 내에 로그(logger.info())를 남길 때, "결제 성공" 같은 무의미한 텍스트 대신 {"userId": 123, "orderId": "A-1", "amount": 5000} 형태의 구조화된 로그(Structured Logging)를 남겨야 훗날 기계(ELK)가 쿼리 하기 쉬워진다는 사실을 논증할 수 있는가?

Industry

• Datadog이나 New Relic 같은 특정 상용 벤더의 라이브러리로 소스코드를 도배했을 때 발생하는 종속성(Lock-in) 리스크를, 오픈텔레메트리(OpenTelemetry) 표준 API와 콜렉터(Collector) 라우팅 아키텍처로 어떻게 끊어내는지 해부할 수 있는가?
• 하루 수십 억 건의 정상 요청(HTTP 200) 로그를 모두 저장하다가 수천만 원의 비용 폭탄을 맞은 조직에, 정상 응답은 1%만 수집하고 지연/에러가 발생한 요청(HTTP 500)은 100% 수집하는 '테일 기반 샘플링(Tail-based Sampling)' 엔지니어링을 도입할 수 있는가?