OpenTelemetry로 마이크로서비스 관측성 통합하기 2026 실전 분산 트레이싱

마이크로서비스로 시스템을 쪼개면 유연성은 얻지만 관측성은 어려워진다. 하나의 사용자 요청이 열 개가 넘는 서비스를 거치는데, 어디서 지연이 생겼는지 각 서비스의 로그를 따로 뒤져서는 알기 어렵다. 오픈텔레메트리(OpenTelemetry)는 이 문제를 해결하기 위해 등장한 벤더 중립 표준이다. CNCF의 핵심 프로젝트로서 로그, 메트릭, 트레이스라는 세 가지 신호를 하나의 통일된 규격과 SDK로 수집한다. 2026년 현재 사실상 모든 주요 관측성 백엔드가 오픈텔레메트리를 지원하며, 특정 벤더에 종속되지 않는 계측이 상식이 됐다.

관측성의 세 기둥과 표준화의 가치

관측성은 흔히 세 기둥으로 설명된다. 로그는 개별 사건의 상세 기록이고, 메트릭은 시간에 따라 집계된 수치이며, 트레이스는 하나의 요청이 시스템을 통과하는 전체 경로다. 과거에는 각 신호마다 서로 다른 에이전트와 라이브러리를 써야 했다. 로그는 이 도구, 메트릭은 저 도구, 트레이스는 또 다른 도구를 쓰다 보니 계측 코드가 중복되고 벤더를 바꾸려면 모든 코드를 손봐야 했다.

오픈텔레메트리는 이 파편화를 끝낸다. 애플리케이션은 표준 SDK로 한 번만 계측하면 되고, 데이터를 어디로 보낼지는 설정으로 결정한다. 오늘은 예거로 트레이스를 보내다가 내일 다른 백엔드로 바꿔도 계측 코드는 그대로다. 이 분리가 주는 자유가 표준화의 가장 큰 가치다. 특히 여러 언어로 작성된 서비스들이 섞인 환경에서, 언어마다 일관된 방식으로 신호를 수집할 수 있다는 점이 강력하다.

자동 계측과 컨텍스트 전파

가장 반가운 소식은 많은 경우 코드를 거의 건드리지 않고도 계측이 된다는 점이다. 오픈텔레메트리는 널리 쓰이는 웹 프레임워크, HTTP 클라이언트, 데이터베이스 드라이버에 대한 자동 계측을 제공한다. 예를 들어 노드 환경에서는 SDK를 초기화하는 코드 몇 줄만 추가하면 들어오고 나가는 모든 HTTP 요청이 자동으로 스팬으로 기록된다.

const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-http');

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({ url: 'http://collector:4318/v1/traces' }),
  instrumentations: [getNodeAutoInstrumentations()],
});
sdk.start();

분산 트레이싱의 핵심은 컨텍스트 전파다. 서비스 A가 서비스 B를 호출할 때, 요청의 트레이스 ID와 스팬 ID를 HTTP 헤더에 실어 함께 전달한다. B는 이 정보를 받아 자기 스팬을 같은 트레이스에 이어 붙인다. 이 전파는 W3C Trace Context라는 표준 헤더 규격을 따르므로, 서로 다른 언어와 프레임워크로 만든 서비스들도 하나의 연속된 트레이스로 이어진다. 요청이 열 개 서비스를 거쳐도 전체 경로가 하나의 폭포수 그래프로 재구성되고, 어느 구간에서 시간을 잡아먹었는지 즉시 드러난다.

컬렉터를 활용한 수집 파이프라인

애플리케이션이 신호를 백엔드로 직접 보내는 대신, 오픈텔레메트리 컬렉터를 중간에 두는 것이 프로덕션의 권장 구조다. 컬렉터는 여러 서비스가 보낸 데이터를 한곳에서 받아 가공하고 여러 목적지로 나눠 보내는 중계소 역할을 한다. 리시버로 데이터를 받고, 프로세서로 가공하고, 익스포터로 내보내는 파이프라인 구조다.

컬렉터를 두면 여러 이점이 생긴다. 민감한 개인정보가 담긴 속성을 백엔드로 나가기 전에 지우거나 마스킹할 수 있고, 트래픽이 많을 때 샘플링으로 데이터 양을 조절해 저장 비용을 관리할 수 있다. 애플리케이션은 가까운 컬렉터로 빠르게 데이터를 넘기고 자기 일에 집중하며, 백엔드 전송의 재시도와 버퍼링은 컬렉터가 책임진다. 백엔드를 교체하거나 추가할 때도 애플리케이션은 그대로 두고 컬렉터 설정만 바꾸면 된다. 실무에서는 각 노드에 에이전트 컬렉터를 두고 그 위에 게이트웨이 컬렉터를 계층으로 배치해 확장성과 안정성을 함께 확보한다. 이렇게 표준 계측과 컬렉터 파이프라인을 갖추면, 장애가 터졌을 때 원인을 추적하는 시간이 몇 시간에서 몇 분으로 줄어든다. 관측성은 사후 대응이 아니라 시스템 설계의 일부로 처음부터 녹여야 하는 요소다.

샘플링과 비용 관리 전략

트레이스를 모두 수집하면 데이터 양이 폭발적으로 늘어 저장 비용과 처리 부하가 감당하기 어려워진다. 그래서 샘플링이 필수다. 샘플링에는 크게 두 가지 방식이 있다. 헤드 기반 샘플링은 트레이스가 시작되는 시점에 이 요청을 기록할지 말지 결정한다. 구현이 간단하고 부하가 낮지만, 정작 문제가 된 느린 요청이나 오류 요청이 샘플링에서 빠질 위험이 있다. 반대로 테일 기반 샘플링은 트레이스가 완료된 뒤 전체를 보고 기록 여부를 결정한다. 오류가 있거나 지연이 큰 트레이스는 반드시 남기고 정상 트레이스는 일부만 남기는 식으로, 가치 있는 데이터를 선별할 수 있다.

테일 기반 샘플링은 컬렉터 계층에서 수행하는 것이 일반적이다. 하나의 트레이스에 속한 모든 스팬이 같은 컬렉터로 모여야 전체를 보고 판단할 수 있으므로, 트레이스 ID 기준으로 라우팅하는 로드 밸런싱이 필요하다. 이 구조는 다소 복잡하지만, 저장 비용을 크게 줄이면서도 디버깅에 정말 필요한 트레이스는 놓치지 않는다는 실질적 이점이 있다.

메트릭과 로그도 함께 다뤄야 진정한 통합 관측성이 완성된다. 오픈텔레메트리는 세 신호에 공통된 리소스 속성과 트레이스 컨텍스트를 부여하므로, 하나의 오류 로그에서 그 요청의 전체 트레이스로, 다시 관련 메트릭으로 자연스럽게 넘나들 수 있다. 이 상관관계가 디버깅의 속도를 근본적으로 바꾼다. 지표에서 이상 징후를 발견하고, 관련 트레이스로 좁혀 원인 서비스를 찾고, 그 시점의 로그로 세부 사항을 확인하는 흐름이 하나의 도구 안에서 매끄럽게 이어진다. 계측을 처음 설계할 때부터 이 세 신호를 함께 고려하면, 장애 대응은 물론 성능 최적화와 용량 계획까지 데이터에 기반해 내릴 수 있는 성숙한 운영 체계를 갖추게 된다.