시스템의 속마음을 읽는 기술: o11y(관측 가능성) 완벽 가이드

안녕하세요! 오늘은 현대 IT 시스템 운영의 필수 개념인 o11y(Observability, 관측 가능성)에 대해 깊이 있게 다뤄보려고 합니다.

0. o11y가 도대체 뭐야?

먼저 용어부터 정리해 보죠. o11y는 Observability라는 단어의 'O'와 'y' 사이에 11글자가 있다는 의미에서 온 줄임말입니다. (Accessibility를 a11y라고 부르는 것과 같은 이치죠!)

단순한 모니터링이 "서버가 죽었니?"라고 묻는 것이라면, o11y는 "서버가 왜 느려졌고, 내부에서 어떤 일이 벌어지고 있니?"라는 질문에 답할 수 있는 상태를 만드는 것을 의미합니다.

---

1. 데이터의 원자: 이벤트(Event)와 카운터(Counter)

모든 관측 데이터는 가장 밑바닥의 두 원자 단위에서 시작됩니다.

• 이벤트 (Event): 시스템 내부의 개별적인 사건입니다. (예: "결제 버튼 클릭", "DB 쿼리 전송")
• 성격: '점(Dot)'의 개념입니다. 발생한 시점의 모든 상세 맥락을 담고 있습니다.

• 카운터 (Counter): 이벤트를 숫자로 치환해 계속 누적한 값입니다. (예: "누적 에러 발생 7,400건")
• 성격: '합(Sum)'의 개념입니다. 숫자로만 관리되기에 저장 효율이 압도적입니다.

---

2. o11y를 지탱하는 3개의 기둥 (Metrics, Logs, Traces)

이 원자 데이터들을 어떻게 가공하느냐에 따라 우리가 흔히 말하는 '3요소'가 결정됩니다.

구분	기반 데이터	특징	핵심 질문
메트릭 (Metrics)	카운터	수치, 시계열, 저용량	"얼마나 많이(How many)?"
로깅 (Logging)	이벤트	텍스트, 상세 맥락, 고용량	"무슨 일이(Why)?"
트레이싱 (Tracing)	이벤트	인과관계, 경로, 전체 여정	"어디서 지연이(Where)?"

---

3. 로깅과 로그 레벨: 기록의 문턱 설정하기

로깅은 이벤트를 기록하는 행위입니다. 하지만 모든 것을 기록하면 시스템에 과부하가 걸리죠. 이때 로그 레벨이라는 문턱을 사용합니다.

• 작동 원리: 내가 설정한 레벨보다 심각도가 같거나 높은 로그만 기록됩니다.
• 레벨 순서: TRACE < DEBUG < INFO < WARN < ERROR < FATAL
• 실무 팁: * 운영 환경: 평소엔 INFO로 유지하여 노이즈를 줄입니다.
• 장애 분석: 일시적으로 DEBUG로 레벨을 낮춰 시스템의 잡담까지 모두 기록하며 원인을 찾습니다.

---

4. 트레이싱의 심장: 스팬(Span)의 이해

트레이싱을 이해하려면 스팬(Span)을 알아야 합니다. 전체 요청(Trace)이 하나의 드라마라면, 스팬은 그 드라마 속의 '한 장면'입니다.

• 스팬의 기준: 보통 네트워크 경계(서비스 A가 B를 호출)나 논리적 경계(DB 쿼리 실행)를 기준으로 나뉩니다.
• 같은 계층(Sibling) 스팬의 의미:

1. 병렬 실행: 시간축에서 스팬들이 겹쳐 보인다면 동시에 일을 하고 있다는 뜻입니다.
2. 순차 실행: 계단식으로 이어져 있다면 앞 작업이 끝나야 뒤 작업이 시작되는 의존 관계임을 의미합니다.

---

5. 마무리: 어떻게 시작할까? (OpenTelemetry)

이 모든 데이터를 어떻게 수집할지 고민이라면 OpenTelemetry(OTel)를 주목하세요. 메트릭, 로그, 트레이스를 수집하는 글로벌 표준 규격으로, 어떤 툴(Datadog, Grafana 등)을 쓰더라도 OTel을 통해 데이터를 일관되게 뽑아낼 수 있습니다.

요약하자면:

1. 계측(Instrumentation)으로 센서를 달고,
2. 상태는 메트릭으로 보고,
3. 흐름은 트레이싱으로 추적하며,
4. 상세 원인은 로그로 파헤치는 것!

이것이 바로 완벽한 o11y의 흐름입니다.