# 시스템을 관찰한다는 것: 모니터링에서 가시성으로의 전환

# 시스템을 관찰한다는 것: 모니터링에서 가시성으로의 전환  시스템 모니터링은 단순한 지표 수집이 아니다. 관찰 가능성(Observability)은 시스템 내부 상태를 외부에서 추론할 수 있는 능력을 의미하며, 메트릭, 로그, 트레이스라는 세 축을 통해 구현된다. 현대 분산 시스템의 복잡성은 전통적 모니터링의 한계를 드러냈고, 우리는 이제 시스템을 '관찰'하는 새로운 방법론을 필요로 한다. ## 모니터링의 한계  시스템을 감시한다는 것은 오래된 과제다. 그러나 감시와 이해는 다르다. 전통적 모니터링은 미리 정의된 지표를 추적하는 행위였다. CPU 사용률, 메모리 점유율, 디스크 I/O는 시스템의 건강 상태를 나타내는 신호였지만, 동시에 제한적인 창이기도 했다. 우리는 알고 있는 것만 측정할 수 있었고, 측정하지 않은 것은 보이지 않았다. 분산 시스템 시대는 이 접근법의 한계를 명확히 드러냈다. 수십, 수백 개의 마이크로서비스가 복잡하게 얽힌 환경에서 단일 장애 지점을 찾는 일은 미로를 헤매는 것과 같다. 요청 하나가 여러 서비스를 거치며 변형되고, 각 구간에서 발생하는 지연과 오류는 전체 시스템의 어디에서 비롯되었는지 추적하기 어렵다. 이때 필요한 것은 더 많은 대시보드가 아니라, 시스템 내부를 들여다볼 수 있는 근본적인 능력이다. 관찰 가능성은 이 간극을 메우기 위해 등장한 개념이다. 제어 이론에서 유래한 이 용어는 시스템의 외부 출력만으로 내부 상태를 추론할 수 있는 정도를 의미한다. 단순히 "무엇이 잘못되었는가"를 아는 것을 넘어, "왜 잘못되었는가"를 질문할 수 있는 구조를 만드는 것이다. 사후 대응에서 사전 이해로의 패러다임 전환이 여기서 시작된다. ## 세 개의 기둥: 메트릭, 로그, 트레이스  관찰 가능성은 세 가지 핵심 요소로 구성된다. 각각은 시스템을 바라보는 서로 다른 렌즈이며, 이들이 조합될 때 비로소 전체 그림이 드러난다. 메트릭(Metrics)은 시간에 따른 수치적 표현이다. 요청 처리량, 응답 시간의 백분위수, 에러율은 시스템의 건강 상태를 정량화한다. 메트릭의 강점은 집계와 압축에 있다. 수백만 건의 요청을 초당 평균값이나 P99 지연시간으로 요약할 수 있으며, 이는 장기 추세를 파악하고 임계값 기반 알림을 구성하는 데 효율적이다. 그러나 메트릭만으로는 개별 사용자의 경험이나 특정 요청이 실패한 이유를 알 수 없다. 이는 숲을 보는 도구지, 나무를 보는 도구가 아니다. 로그(Logs)는 시스템이 남기는 이산적 기록이다. 각 이벤트는 타임스탬프와 함께 구조화되거나 비구조화된 메시지로 저장된다. 로그의 가치는 맥락에 있다. 특정 트랜잭션이 어떤 경로를 거쳤고, 어떤 예외가 발생했으며, 어떤 변수 값이 문제를 일으켰는지는 모두 로그에 담긴다. 문제는 규모다. 대규모 시스템은 초당 수만 줄의 로그를 생성하며, 이 속에서 의미 있는 신호를 찾는 것은 그 자체로 도전이다. 구조화된 로그(JSON, structured logging)는 이 문제를 완화하지만, 근본적으로 로그는 사후 분석을 위한 도구다. 트레이스(Traces)는 분산 시스템에서 단일 요청의 전체 생애주기를 추적한다. 하나의 사용자 요청이 프론트엔드에서 시작해 여러 백엔드 서비스를 거쳐 데이터베이스에 도달하고 다시 돌아오는 과정을 하나의 연결된 흐름으로 시각화한다. 각 구간(span)은 시작 시간과 종료 시간, 그리고 메타데이터를 포함한다. 트레이스의 핵심은 인과관계의 복원이다. 전체 지연 시간 중 어느 구간이 병목인지, 어느 서비스에서 오류가 발생했는지를 명확히 드러낸다. OpenTelemetry와 같은 표준화 노력은 트레이스를 구현하는 복잡성을 줄이고 있다. 이 세 요소는 독립적이지 않다. 메트릭이 이상을 감지하면 로그에서 세부사항을 확인하고, 트레이스로 전체 흐름을 재구성한다. 이 통합된 시선이 관찰 가능성의 본질이다. ## 설계 원칙: 관찰 가능성을 내재화하기  관찰 가능성은 사후에 추가할 수 있는 속성이 아니다. 시스템 설계 단계부터 고려되어야 하는 아키텍처적 특성이다. 첫째, 계측(Instrumentation)은 코드의 일부다. 애플리케이션은 자신의 상태를 외부로 드러내도록 설계되어야 한다. 이는 단순히 로그 문장을 추가하는 것 이상을 의미한다. 모든 주요 함수 호출, 외부 의존성 접근, 비즈니스 로직의 분기점에서 의미 있는 데이터를 기록해야 한다. 현대적 계측 라이브러리는 이 과정을 자동화하지만, 무엇을 관찰할 것인가에 대한 판단은 여전히 인간의 몫이다. 둘째, 컨텍스트의 전파는 필수적이다. 분산 환경에서 요청 ID나 트레이스 ID는 모든 서비스 경계를 넘어 전달되어야 한다. 이 식별자가 없다면 개별 로그는 고립된 섬이 되며, 전체 흐름을 재구성하는 것은 불가능하다. W3C Trace Context와 같은 표준은 이 전파 메커니즘을 정의한다. 셋째, 카디널리티를 관리하라. 메트릭이나 트레이스에 무한히 많은 고유 값을 가진 레이블(예: 사용자 ID, 세션 ID)을 추가하면 저장소는 폭발하고 쿼리는 느려진다. 높은 카디널리티 데이터는 로그로 남기고, 메트릭은 집계 가능한 차원으로 제한해야 한다. 이는 기술적 제약이자 설계 원칙이다. 넷째, 샘플링과 집계를 전략적으로 사용하라. 모든 요청을 트레이스하는 것은 비현실적이다. 에러가 발생한 요청, 느린 요청, 그리고 무작위 샘플을 조합하면 전체 시스템의 행동을 충분히 파악할 수 있다. 적응형 샘플링(adaptive sampling)은 이 균형을 자동화한다. ## 도구와 생태계  이론은 명확하지만, 실제 구현은 도구 선택에서 시작한다. 관찰 가능성 스택은 크게 세 계층으로 나뉜다. 수집 계층은 애플리케이션에서 데이터를 추출한다. Prometheus는 메트릭 수집의 사실상 표준이 되었고, Fluentd와 Vector는 로그 수집과 전처리를 담당한다. OpenTelemetry는 메트릭, 로그, 트레이스를 통합하는 단일 계측 프레임워크로 자리 잡고 있다. 이 계층의 핵심은 애플리케이션에 미치는 성능 영향을 최소화하면서도 충분한 데이터를 확보하는 것이다. 저장 계층은 수집된 데이터를 보관하고 쿼리 가능하게 만든다. 시계열 데이터베이스(Prometheus, VictoriaMetrics, Thanos)는 메트릭을 효율적으로 저장한다. 로그는 Elasticsearch, Loki, ClickHouse와 같은 시스템에 저장되며, 각각은 저장 효율성과 쿼리 성능 사이의 다른 절충을 제공한다. 트레이스는 Jaeger, Tempo, Zipkin이 처리하며, 최근에는 Tempo처럼 객체 스토리지 기반의 경제적인 솔루션이 주목받는다. 분석 계층은 데이터를 의미 있는 통찰로 변환한다. Grafana는 시각화의 표준이 되었고, Kibana는 로그 탐색에 특화되어 있다. 최근의 관찰 가능성 플랫폼(Datadog, New Relic, Honeycomb)은 메트릭, 로그, 트레이스를 단일 인터페이스에서 상관 분석할 수 있게 한다. 이들은 이상 탐지, 자동 알림, 심지어 근본 원인 분석까지 제공하며, 관찰에서 행동으로의 간격을 줄인다. 도구의 선택은 조직의 규모, 예산, 기술 스택에 따라 달라진다. 중요한 것은 완벽한 도구가 아니라 일관된 전략이다. 모든 팀이 동일한 계측 방식을 따르고, 데이터가 중앙에서 접근 가능하며, 문제 발생 시 누구나 같은 도구로 조사할 수 있어야 한다. ## 조직적 함의: 관찰 가능성 문화 기술 스택을 구축하는 것은 시작에 불과하다. 관찰 가능성의 진정한 가치는 조직 문화에서 실현된다. 장애 대응은 탐정 작업이 된다. 과거에는 알림이 발생하면 미리 작성된 플레이북을 따랐다. 그러나 현대 시스템의 장애는 예측 불가능하다. 엔지니어는 증상에서 시작해 가설을 세우고, 데이터를 탐색하며, 원인을 좁혀간다. 이 과정은 창의적이고 반복적이다. 관찰 가능성은 이 탐정 작업을 가능하게 하는 도구다. 포스트모템(사후 분석)은 학습의 장이 된다. 장애가 해결된 후 팀은 타임라인을 재구성하고, 무엇이 보였고 무엇이 보이지 않았는지 검토한다. "이 신호가 있었다면 더 빨리 찾을 수 있었을까?" 이 질문은 시스템 개선으로 이어진다. 관찰 가능성은 정적인 상태가 아니라 지속적으로 진화하는 능력이다. 책임은 분산된다. 과거에는 운영팀이 모니터링을 담당했다. 그러나 관찰 가능성은 코드를 작성하는 순간부터 시작된다. 개발자는 자신의 코드가 어떻게 관찰될지 고려해야 하며, 프로덕션에서 발생하는 문제를 직접 조사할 수 있어야 한다. 이는 DevOps와 SRE 문화의 자연스러운 연장이다. ## 미래의 방향: 지능적 관찰 관찰 가능성의 다음 단계는 자동화와 지능화다. 인간이 모든 메트릭을 감시하고 모든 로그를 읽는 것은 불가능하다. 시스템 자체가 이상을 감지하고, 패턴을 학습하며, 문제를 예측해야 한다. 이상 탐지(Anomaly Detection)는 기계 학습을 활용해 정상 행동의 기준선을 설정하고 이탈을 자동으로 감지한다. 정적 임계값은 환경 변화에 취약하지만, 학습 기반 모델은 적응한다. 예를 들어 특정 시간대의 트래픽 증가가 정상인지 이상인지를 컨텍스트에 따라 판단한다. 자동 상관 분석(Auto-correlation)은 메트릭, 로그, 트레이스 간의 관계를 자동으로 발견한다. "이 에러 로그가 증가할 때 항상 이 메트릭도 상승한다"는 패턴을 인간이 수동으로 찾는 것은 비효율적이다. 시스템이 이를 학습하고 제안하면, 엔지니어는 더 높은 수준의 판단에 집중할 수 있다. 예측적 알림(Predictive Alerting)은 문제가 발생하기 전에 경고한다. 디스크 사용량의 증가 추세를 분석해 "3일 후 디스크가 가득 찰 것"이라고 알리거나, 응답 시간의 미세한 증가 패턴을 보고 "부하가 임계점에 근접 중"이라고 경고한다. 이는 사후 대응에서 사전 예방으로의 전환이다. 그러나 이 모든 자동화의 중심에는 여전히 인간의 판단이 있다. 시스템은 신호를 제공하지만, 의미를 해석하고 행동을 결정하는 것은 엔지니어의 역할이다. 관찰 가능성은 인간의 이해를 대체하는 것이 아니라 확장하는 것이다. --- 시스템을 관찰한다는 것은 단순히 데이터를 수집하는 행위가 아니다. 이는 복잡성과 대면하는 방식이며, 불확실성 속에서 이해를 구축하는 과정이다. 메트릭은 추세를 보여주고, 로그는 세부사항을 담으며, 트레이스는 인과관계를 드러낸다. 이 세 가지가 조화를 이룰 때 우리는 시스템의 외부에서 내부를 추론할 수 있다. 관찰 가능성은 기술적 도구를 넘어 사고방식의 전환을 요구한다. 미리 알 수 없는 문제에 대비하고, 시스템이 스스로를 설명하도록 설계하며, 장애를 학습의 기회로 삼는 문화가 관찰 가능한 시스템이 추구하는 궁극적 목표다. 결국 우리가 관찰하는 것은 시스템이 아니라, 시스템을 통해 드러나는 우리 자신의 이해의 한계다. 그 한계를 인정하는 순간, 비로소 진정한 가시성이 시작된다.