내 서버가 왜 느린지 1초 만에 찾는 법: OpenTelemetry + Grafana 관측성 가이드

Reliability & Monitoring

"범인은 이 안에 있어!"
OpenTelemetry로 구축하는 무적의 관측성

 

안녕하세요, code-resting입니다. 서비스 규모가 커질수록 "갑자기 API가 왜 느려졌지?"라는 질문에 답하기가 점점 어려워집니다. 여러 마이크로서비스를 거치는 요청 중 어디서 병목이 생겼는지, 어떤 DB 쿼리가 문제인지 일일이 로그를 뒤지는 시대는 끝났습니다. 오늘은 2026년 표준으로 자리 잡은 OpenTelemetry를 활용해 시스템의 모든 흐름을 시각화하는 법을 공유합니다.

1. 모니터링을 넘어 관측성(Observability)으로

기존의 모니터링이 "문제가 생겼다"를 알려준다면, 관측성은 "왜 문제가 생겼는가"를 설명해 줍니다. 이를 위해 3가지 핵심 데이터(MELT)가 필요합니다.

• 📊 Metrics: 시스템의 건강 상태 (CPU 사용률, 초당 요청 수)
• 🔗 Tracing: 하나의 요청이 여러 서비스를 통과하는 전체 경로 (Span)
• 📝 Logging: 특정 시점에 발생한 상세 기록

2. Spring Boot 3.5+ 연동하기

과거에는 Zipkin이나 Jaeger 전용 라이브러리를 썼지만, 이제는 OpenTelemetry 하나로 통합되었습니다. Micrometer Tracing을 활용하면 코드를 거의 수정하지 않고도 적용이 가능합니다.

// build.gradle
dependencies {
    implementation 'io.micrometer:micrometer-tracing-bridge-otel'
    implementation 'io.opentelemetry:opentelemetry-exporter-otlp'
    implementation 'io.github.openfeign:feign-micrometer' // Feign 클라이언트 추적
}

이후 application.yml에서 샘플링 비율을 설정합니다. (실무에선 10~20% 권장, 테스트 시엔 1.0)

management:
  tracing:
    sampling:
      probability: 1.0 # 모든 요청 추적
  otlp:
    tracing:
      endpoint: http://otel-collector:4318/v1/traces

3. Grafana Tempo로 지연 시간 분석하기

수집된 트레이스(Trace) 데이터는 Grafana를 통해 시각화됩니다. 아래와 같이 특정 API 요청에서 어느 메서드가 몇 ms를 점유했는지 타임라인 형태로 확인할 수 있습니다.

🚀 장애 조치 시나리오

1. 알람 발생 (Prometheus)
2. 대시보드에서 지연 시간 급증 확인 (Grafana)
3. 지연된 요청의 Trace ID를 클릭하여 상세 경로 추적
4. 외부 API 호출에서 타임아웃 발생 지점 즉시 발견!

💡 마치며: 개발자의 숙면을 위하여

관측성이 없는 시스템은 '캄캄한 방에서 물건 찾기'와 같습니다. OpenTelemetry를 통해 시스템에 '불'을 켜세요. 장애 원인을 찾는 시간이 줄어들수록, 여러분의 코드 퀄리티와 삶의 질은 올라갑니다.

© 2026 code-resting. All rights reserved.