"가끔 서비스가 느려져요." 고객센터를 통해 이런 막연한 불만이 접수됩니다. 개발팀은 즉시 대시보드를 확인하지만, CPU, 메모리, 네트워크 사용량은 모두 평온합니다. 에러 로그에는 아무것도 찍히지 않았습니다. 원인은 미궁 속에 빠지고, 팀은 "알 수 없는 문제"라는 최악의 상황에 직면합니다. 🤯
이처럼 시스템이 복잡해질수록, 우리가 미리 예측하고 설정해 둔 지표만으로는 원인을 찾을 수 없는 '알려지지 않은 미지(Unknown unknowns)'의 문제들이 발생합니다. 바로 이 문제를 해결하기 위해 등장한 개념이 관측 가능성(Observability) 입니다.
모니터링 vs. 관측 가능성 (의사 진료 비유)
많은 사람들이 '모니터링'과 '관측 가능성'을 혼용하지만, 둘은 목표가 다릅니다.
- 모니터링 (Monitoring) 🩺: 환자의 활력 징후를 체크하는 것과 같습니다. 체온, 심박수, 혈압 등 미리 정해둔 핵심 지표들을 계속 주시하다가, 수치가 정해진 범위를 넘어서면 경고(Alert)를 보냅니다. "체온이 38.5도 이상입니다!"처럼, 시스템에 문제가 생겼다는 사실을 알려주는 역할을 합니다. 우리가 '알고 있는' 문제들을 감시하는 것이죠.
- 관측 가능성 (Observability) 👨⚕️: 미스터리한 질병을 진단하는 명의와 같습니다. 활력 징후는 정상이지만 환자는 계속 아프다고 합니다. 의사는 환자에게 "언제부터, 어디가, 어떻게 아팠나요?"라고 질문하고, MRI 촬영이나 혈액 검사 등 다양한 검사를 통해 데이터를 종합하여 근본 원인을 찾아냅니다. 즉, 시스템의 외부 출력(데이터)을 보고, 그 내부 상태를 얼마나 잘 추론할 수 있는지를 의미합니다. 예상치 못했던 '알려지지 않은' 문제의 원인을 파고들 수 있는 능력입니다.
관측 가능성의 세 기둥 (The Three Pillars)
관측 가능성은 단순히 "로그를 잘 보자"는 구호가 아닙니다. 시스템의 상태를 입체적으로 이해하기 위한 세 가지 핵심 데이터, 즉 '세 개의 기둥' 이 필요합니다.
- 로그 (Logs) 📜
- 무엇인가? 시스템에서 발생한 개별 이벤트에 대한 상세한 기록입니다. 마치 배의 항해 일지처럼, 특정 시간에 어떤 일이 일어났는지 타임스탬프와 함께 기록된 텍스트 데이터입니다.
- 언제 유용한가? 특정 에러의 원인을 깊게 파고들거나, 특정 사용자의 행동을 순서대로 추적할 때 강력합니다. "5분 전 user-123의 결제 실패 직전, 어떤 SQL 쿼리가 실행됐지?" 와 같은 구체적인 질문에 답을 줍니다.
- 메트릭 (Metrics) 📈
- 무엇인가? 일정 시간 동안 수집된 데이터를 요약한 숫자 값입니다. CPU 사용률, 메모리 사용량, 1분당 요청 수(RPS) 등이 해당됩니다.
- 언제 유용한가? 시스템의 전반적인 건강 상태를 한눈에 파악하고, 시간의 흐름에 따른 추세(Trend)를 분석하는 데 탁월합니다. 대시보드를 구성하고, "지난 1시간 동안 API 평균 응답 시간이 서서히 증가하고 있어!"와 같은 이상 징후를 포착하는 데 사용됩니다.
- 트레이스 (Traces) 🗺️
- 무엇인가? 가장 중요한 기둥 중 하나로, 사용자 요청이 시스템에 들어와서 나갈 때까지, 그 여정 전체를 보여주는 데이터입니다. 요청이 여러 마이크로서비스를 거칠 때, 각 서비스에서 얼마나 머물렀고 어떤 순서로 호출되었는지 한눈에 보여줍니다.
- 언제 유용한가? "주문 API가 느린데, 수많은 내부 서비스 중 정확히 어떤 놈이 범인이지?" 라는 질문에 답을 줍니다. 전체 요청의 흐름을 시각화하여 병목 지점을 정확히 찾아내는 데 필수적입니다.
관측 가능성의 진정한 힘은 이 세 기둥을 유기적으로 연결할 때 나옵니다. 메트릭 대시보드에서 이상한 스파이크를 발견하고 → 클릭해서 해당 시간대의 느린 요청들의 트레이스를 살펴본 뒤 → 가장 느린 구간을 담당한 서비스의 상세 로그를 열어보는 식으로, 문제의 근원을 향해 좁혀 들어갈 수 있는 것이죠.
마치며
과거의 단일 서버(Monolith) 환경에서는 로그와 몇 가지 메트릭만으로도 충분했을지 모릅니다. 하지만 수십, 수백 개의 마이크로서비스가 거미줄처럼 얽혀 돌아가는 현대의 시스템에서, 관측 가능성은 더 이상 선택이 아닌 필수 생존 기술입니다.
그것은 단순히 더 많은 데이터를 수집하는 것을 넘어, 시스템을 이해하고 개선하기 위해 올바른 질문을 던질 수 있는 능력을 갖추는 것입니다. 관측 가능성은 복잡성에 길을 잃은 개발팀에게 시스템의 내부를 환히 비춰주는 등대와 같습니다. 🔦