Observability

서비스가 여러 개로 나뉘고 큐와 이벤트가 섞이면, 장애가 났을 때 어디서부터 보기 시작해야 할지 모르는 순간이 생깁니다. 에러 로그는 있는데 그 에러가 어느 요청에서 시작된 것인지, 어느 서비스를 거쳐온 것인지 알 수 없습니다. 특정 API가 느리다는 알림은 오는데, 데이터베이스 쿼리인지 외부 API 호출인지 메시지 처리 지연인지 구분이 안 됩니다. 장애 복구에 걸리는 시간보다 '지금 어디를 봐야 하는지' 파악하는 시간이 더 길어지기도 합니다. 이 보이지 않음 자체가 운영의 병목이 됩니다.

단일 애플리케이션 시절에는 프로세스 하나의 로그와 서버 메트릭만 봐도 문제의 위치를 어느 정도 좁힐 수 있었습니다. 서비스가 수십 개로 나뉘고 각자 독립 배포되기 시작하면서, 하나의 사용자 요청이 수십 개 서비스를 거치게 됐고 로그는 각 서비스에 흩어졌습니다. 인프라도 컨테이너와 서버리스 환경으로 옮겨가면서 특정 인스턴스를 직접 들여다보는 방식은 통하지 않게 됐습니다. 이 환경에서 에러율, 응답 지연, 요청 경로를 한 곳에서 연결해 볼 수 없으면 운영이 사실상 추측에 가까워졌고, 관측 가능성을 시스템 설계 단계에서 함께 다루어야 한다는 인식이 확산됐습니다.

세 가지 신호가 각자 다른 질문에 답합니다. 로그(Log)는 특정 시점에 어떤 사건이 일어났는지 기록하고, 메트릭(Metric)은 시간에 따른 수치 변화를 요약해 이상 징후를 감지하게 합니다. 트레이스(Trace)는 하나의 요청이 여러 서비스와 컴포넌트를 거치는 경로를 연결해 보여줘서, 어느 구간에서 시간이 가장 많이 걸렸는지 추적할 수 있게 합니다. 이 세 신호를 함께 수집하고 연결할 수 있을 때, '지금 무슨 일이 일어나고 있는가'에서 '왜 이 요청만 느린가'까지 질문의 층위를 올릴 수 있습니다.

Observability와 Circuit Breaker는 모두 운영 안정성과 맞닿아 있지만 역할이 다릅니다. Observability는 시스템 내부를 들여다볼 수 있게 해 원인을 추적하는 진단 기반이고, Circuit Breaker는 실패가 더 넓게 퍼지지 않게 호출을 차단하는 보호 장치입니다. 하나는 무슨 일이 있었는지 보는 능력이고, 다른 하나는 일이 커지지 않게 막는 능력입니다. 단순 모니터링과의 차이도 있습니다. 모니터링은 미리 정해진 지표가 임계치를 넘으면 알리는 방식이라 사전에 예측하지 못한 문제에는 취약합니다. Observability는 질문을 먼저 정하지 않고도 시스템이 남긴 신호로 새로운 질문에 답할 수 있는 구조를 목표로 합니다.

마이크로서비스, 이벤트 기반 파이프라인, 메시지 큐 처리, 외부 API 의존성이 많은 시스템일수록 Observability는 필수에 가깝습니다. '배포 후 에러율이 올라갔는데 어느 서비스가 원인인지 바로 알 수 없다'거나 '특정 요청이 가끔 느린데 재현이 안 된다'는 상황이 신호입니다. 신호를 많이 쌓는다고 자동으로 관측이 되는 건 아닙니다. 트레이스 ID가 서비스 간에 전파되어 요청 경로를 연결할 수 있어야 하고, 메트릭은 비즈니스 의미 있는 단위로 집계되어야 합니다. 인프라 계층만 보는 신호로는 서비스 내부의 느린 구간을 찾기 어렵습니다.