OpenTelemetry — 관측성 표준, 벤더 종속을 끝내다

모니터링 도구를 갈아탈 때마다 계측 코드를 통째로 다시 짜야 했던 시절이 있었다. OpenTelemetry(줄여서 OTel)는 그 반복을 끝내려는 프로젝트다. 한마디로, 로그·메트릭·트레이스라는 텔레메트리 데이터를 벤더에 상관없이 같은 방식으로 수집·전송하는 오픈 표준이다.

나는 관측성(observability) 도구를 두 번 바꿔봤는데, 매번 가장 고통스러웠던 건 데이터가 아니라 계측이었다. 특정 벤더의 SDK로 코드 곳곳을 물들여놓으면, 그 벤더를 떠나는 순간 그 흔적을 전부 걷어내야 했다. OTel은 이 종속을 끊는 데서 출발한다.

관측성이 왜 어려웠나

분산 시스템은 요청 하나가 여러 서비스를 넘나든다. 문제가 터졌을 때 "어디서 느려졌나"를 알려면, 서비스마다 흩어진 데이터를 하나의 흐름으로 엮어야 한다. 그런데 각 벤더가 자기 포맷과 SDK를 고집하니, 여러 도구를 섞어 쓰면 데이터가 서로 말이 통하지 않았다.

OTel은 이 지점을 표준으로 눌렀다. 트레이스를 어떻게 표현할지, 메트릭에 어떤 속성을 붙일지, 데이터를 어떤 프로토콜(OTLP)로 흘려보낼지를 공통 규격으로 못 박았다. 그래서 애플리케이션은 OTel 방식으로 한 번만 계측하면 된다.

여기서 특히 중요한 개념이 컨텍스트 전파(context propagation)다. 요청이 서비스 A에서 B로, 다시 C로 넘어갈 때 같은 트레이스 식별자를 함께 실어 보낸다. 그래야 흩어진 조각들이 하나의 요청 흐름으로 이어진다. OTel은 이 전파 방식까지 표준화해, 서로 다른 언어와 프레임워크로 짠 서비스들이 같은 트레이스를 공유할 수 있게 만들었다. 마이크로서비스가 많아질수록 이 표준화의 가치는 커진다.

구성요소를 뜯어보면

계측(instrumentation)

코드에 SDK를 붙여 직접 계측할 수도 있고, 언어에 따라서는 자동 계측으로 손을 거의 안 대고 시작할 수도 있다. HTTP 요청, DB 쿼리 같은 흔한 지점은 자동으로 잡히는 경우가 많다.

컬렉터(collector)

OTel의 진짜 실용적인 부분이라고 본다. 애플리케이션과 백엔드 사이에 컬렉터를 두면, 데이터를 받아 가공하고 여러 백엔드로 나눠 보낼 수 있다. 민감 정보를 걸러내거나 샘플링 비율을 조정하는 것도 여기서 한다. 애플리케이션은 컬렉터 하나만 바라보면 되니 구성이 단순해진다.

표준이 되면 무엇이 바뀌나

가장 큰 변화는 협상력이다. 계측이 표준화되면 백엔드는 언제든 갈아탈 수 있는 상품이 된다. 가격이 오르거나 서비스가 마음에 안 들면 데이터 목적지만 바꾸면 되니까. 여러 도구를 조합해 강점만 취하는 것도 가능해진다. 이 "잠금 해제"가 OTel이 빠르게 사실상의 표준으로 굳어진 이유다.

물론 완성형은 아니다. 세 신호(로그·메트릭·트레이스)의 성숙도가 조금씩 다르고, 언어별 지원 편차도 있다. 자동 계측이 잘 되는 언어가 있는가 하면 손이 더 가는 언어도 있다. 그래도 방향은 분명하다. 관측성의 바닥이 특정 벤더에서 공용 표준으로 옮겨가는 흐름은 되돌리기 어려워 보인다.

자주 묻는 질문

OpenTelemetry가 모니터링 도구를 대체하나요?

아니다. OTel은 데이터를 수집·전송하는 표준이지, 저장하고 시각화하고 알림을 주는 백엔드가 아니다. 수집은 OTel로 하되, 그 데이터를 받아 분석하는 관측성 플랫폼은 따로 필요하다.

기존 모니터링을 쓰고 있어도 도입할 수 있나요?

가능하다. 상당수 관측성 플랫폼이 OTLP 수신을 지원하므로, 계측만 OTel로 바꾸고 데이터는 지금 쓰는 백엔드로 보낼 수 있다. 점진적 전환이 자연스럽다.

세 가지 신호를 다 도입해야 하나요?

그럴 필요는 없다. 보통 트레이스나 메트릭 중 급한 것부터 시작해 범위를 넓힌다. 신호마다 성숙도가 다르니, 조직의 상황에 맞춰 우선순위를 정하는 편이 현실적이다.

컬렉터는 꼭 있어야 하나요?

필수는 아니지만 권장된다. 애플리케이션에서 백엔드로 바로 보낼 수도 있으나, 컬렉터를 두면 데이터 가공·라우팅·재시도를 한곳에서 다룰 수 있어 운영이 훨씬 편해진다.