자체 호스팅 소프트웨어든 Saa스 제품이든, 사용자는 결국 로그·트레이스·메트릭을 자기 관측성 스택으로 보내달라고 요구하게 된다. 규정 준수 때문일 수도 있고, 비용 관리나 모든 관측 데이터를 한곳에 모으려는 목적일 수도 있다. 이런 상황에서 제품이 내장 대시보드로만 데이터를 묶어두거나 특정 벤더로만 내보내기를 허용한다면 불필요한 마찰이 생긴다. OpenTelemetry(OTel) 진영은 최근 블로그에서, 어떤 OTel 호환 백엔드로든 내보낼 수 있게 제품을 설계하는 것이 벤더 중립적이고 미래 지향적인 관행이라고 강조했다. New Relic의 댄 고메스 블랑코가 기여한 이 글은 로그·트레이스·메트릭 세 가지 신호를 사용자가 원하는 곳으로 밀어 보낼 수 있도록 제품을 어떻게 구성할지 정리한다.
OpenTelemetry는 네 가지 신호 유형을 정의하며 모두 표준 프로토콜인 OTLP로 전달된다. 네 번째인 프로파일(Profiles)은 2026년 3월 26일 퍼블릭 알파에 진입해, 코드베이스 전반의 리소스 사용 패턴을 포착함으로써 운영 장애 대응을 돕는 신호로 자리 잡아 가고 있다. 다만 이 논의의 중심은 여전히 로그·트레이스·메트릭 세 가지다. 세 신호 모두 내보내기 방식은 동일하다. 사용자가 OTLP 엔드포인트를 설정하면 그쪽으로 텔레메트리를 밀어 보내는 구조다. 제품이 생성하는 데이터에 따라 한두 개만 지원할 수도 있지만, 처음부터 세 신호를 모두 염두에 두고 설계하면 나중에 뒤늦게 끼워 맞추는 수고를 피할 수 있다.
누가 텔레메트리를 만드느냐가 설계를 가른다
내보내기를 어떻게 붙일지는 텔레메트리를 생성하는 시스템을 누가 소유하느냐에 따라 달라진다. 첫째는 사용자가 자기 환경에 설치해 운영하는 소프트웨어다. 아이덴티티 서버, 서비스 메시, 데이터베이스처럼 고객의 데이터센터나 클라우드, 쿠버네티스 클러스터에서 도는 제품이 여기 해당한다. 이 경우 제품 자체를 OpenTelemetry로 계측해 두고, 고객이 환경 변수나 설정 파일로 엔드포인트를 지정하면 고객이 돌리는 프로세스에서 직접 텔레메트리가 나간다. 내보내기 주체도 목적지도 모두 고객이 통제한다. 키클록(Keycloak)과 쿠마(Kuma)가 대표적이다.
둘째는 고객의 워크로드가 사업자 인프라 위에서 도는 플랫폼이다. PaaS, 서버리스, API 게이트웨이가 이에 속한다. 이때는 '텔레메트리 드레인'이나 '관측성 목적지' 같은 플랫폼 기능을 추가해, 고객이 데이터를 어디로 보낼지 설정하게 한다. 플랫폼이 고객 워크로드와 자사 서비스(라우터 등)에서 텔레메트리를 수집해 고객의 OTLP 엔드포인트로 전달한다. 내보내기를 수행하는 것은 고객이 돌리는 애플리케이션 바이너리가 아니라 사업자 인프라다. 클라우드플레어(Cloudflare)와 헤로쿠(Heroku)가 그 예다.
네 가지 실제 사례가 보여주는 패턴
쿠마는 제어 평면과 데이터 평면을 쿠버네티스든 VM이든 어디에 올리더라도 로그·트레이스·메트릭을 OTel 백엔드로 보내도록 사전 구성돼 있고, 사용자는 메시 정책으로 내보내기를 설정한다. 키클록은 별도 사이드카나 플랫폼 기능 없이 시작 플래그로 컬렉터 엔드포인트만 가리키면 프로세스가 직접 내보내기를 처리하며, 단일 엔드포인트를 쓰되 신호별로 켜고 끄는 세밀한 플래그와 gRPC·HTTP 프로토콜 선택을 제공한다. 클라우드플레어는 대시보드에서 OTLP 엔드포인트를 설정하면 Workers의 트레이스와 로그를 자동으로 밀어 보내며, 핸들러 호출·바인딩·외부 fetch 호출까지 기록해 종단 간 가시성을 준다. 다만 메트릭은 아직 지원하지 않으며 샘플링 비율은 wrangler.toml에서 조정한다. 헤로쿠는 텔레메트리 드레인으로 엔드포인트·전송 프로토콜·헤더를 지정하고 어떤 신호를 내보낼지 명시적으로 고르게 해, 데이터 양과 수집 비용을 관리하려는 팀에 실용적인 선택지를 준다.
풀(pull)보다 푸시(push)가 기본이어야 하는 이유
근본적인 질문은 하나로 모인다. 사용자가 주기적으로 API를 폴링하게 만들 것인가, 아니면 사용자가 지정한 엔드포인트로 텔레메트리를 직접 배달할 것인가다. 전통적으로 플랫폼은 로그·메트릭 API를 열어두고 사용자가 일정 간격으로 폴링하며 페이지네이션을 처리하고 결과를 자기 백엔드로 적재하게 했다. 이미 성숙한 API가 있다면 확장이 쉬운 출발점이지만, 사용자가 응답을 표준 포맷으로 변환하는 맞춤 코드를 직접 짜야 하고 신호마다 상태 추적 로직이 필요하다. 프로메테우스처럼 더 표준화된 방식을 쓸 수 없을 때나 감내할 만한 모델이며, 새 설계의 기본값이 되어선 안 된다. 반면 OTLP 푸시는 HTTP나 gRPC로 사용자 엔드포인트에 로그·트레이스·메트릭을 능동적으로 내보내는 방식으로, 단일 표준 프로토콜 하나로 모든 신호를 처리하니 신호별 전달 로직을 다시 구현할 필요가 없다. 구조화된 데이터와 메타데이터를 일급으로 지원해 특정 로그 레코드를 부모 트레이스 ID와 연결하는 맥락도 자동으로 보존된다.
실무 설계에서 챙길 것
구현할 때는 최소한의 설정으로 최대한의 유연성을 노려야 한다. 먼저 사용자가 자신의 OTLP 엔드포인트와 인증 헤더(예: 수집 키)를 직접 넣게 하고, 헤로쿠처럼 어떤 신호를 내보낼지 명시적으로 토글하게 해 비용과 양을 통제할 수 있게 한다. 내부적으로는 서비스에 OpenTelemetry SDK를 직접 써서 데이터를 내보내거나, 내부 OTel 컬렉터를 돌려 시스템 텔레메트리를 모아 사용자 엔드포인트로 재전송하는 두 가지 선택지가 있다. OTEL_EXPORTER_OTLP_ENDPOINT 같은 표준 환경 변수를 지키면 내부 구조가 안정적이고 문서화하기 쉬워진다. 여기에 더해 모든 신호에 일관된 시맨틱을 유지하는 것이 중요하다. 시맨틱 컨벤션은 속성 이름과 스키마를 일관되게 짓고 로그·메트릭이 트레이스·스팬 ID와 어떻게 연결되는지를 정의하는 기준이며, 그 위에 선 위버(Weaver)로 자체 속성과 스키마를 코드·인프라 변화에 맞춰 관리할 수 있다. 설정 UI에서는 대다수 사용자를 위한 단일 엔드포인트 방식과, OTEL_EXPORTER_OTLP__ENDPOINT 패턴을 이용해 신호별로 다른 플랫폼에 보내려는 고급 사용자를 위한 신호별 라우팅을 함께 고려할 만하다. OTLP로 내보내기를 열어두면 벤더별 통합을 따로 만들 필요 없이, 사용자가 로그를 자기 백엔드와 S3 같은 객체 저장소로 동시에 보내 규정 준수 요건을 맞추는 식의 자유를 누리게 된다.