1인 서비스의 OpenTelemetry Collector export topology

OpenTelemetry를 처음 붙일 때 애플리케이션에서 로그·메트릭·트레이스를 원하는 백엔드로 바로 보내면 간단해 보입니다. 하지만 백엔드를 바꾸거나 샘플링·필터링을 조정할 때 애플리케이션을 다시 배포해야 합니다.

혼자 운영하는 서비스에서도 Collector를 둘 가치가 있는지 판단하기 위해서는 멋진 다이어그램보다 데이터가 어디에서 사라질 수 있는지를 먼저 봐야 합니다. 이번 글에서는 최소 구성의 책임 경계를 정리합니다.

세 신호는 서로 다른 질문에 답합니다

트레이스는 한 요청이 어디를 지나갔는지 알려 주고, 메트릭은 시스템이 얼마나 바쁜지 보여 주며, 로그는 특정 사건의 맥락을 설명합니다. 셋을 모두 수집한다고 자동으로 장애 원인을 찾을 수 있는 것은 아닙니다.

저는 알림에는 메트릭을, 원인 추적에는 트레이스를, 상세한 조건 확인에는 로그를 사용합니다. 같은 내용을 세 번 저장하지 않도록 각 신호의 역할을 문서에 적습니다.

신호질문과한 수집의 위험

트레이스	어느 구간이 느리거나 실패했나	카디널리티·보존 비용
메트릭	얼마나 자주·많이 발생하나	의미 없는 차원 증가
로그	무슨 조건에서 발생했나	민감정보·노이즈

Collector는 배포 경계와 운영 경계를 분리합니다

애플리케이션이 OTLP로 Collector에 보내면 백엔드를 바꿀 때 앱을 수정하지 않고 Collector 설정을 조정할 수 있습니다. 샘플링과 배치, 재시도, 필터링도 한 곳에서 관리할 수 있습니다.

대신 Collector 자체가 또 하나의 운영 대상이 됩니다. 메모리 제한, 큐가 가득 찼을 때의 손실, 네트워크 장애 시 재시도 정책을 확인해야 합니다.

• 애플리케이션: 의미 있는 속성과 기본 신호를 생성합니다.
• Collector: 배치·샘플링·필터링·export를 담당합니다.
• 백엔드: 검색·대시보드·알림·보존을 제공합니다.

샘플링은 비용과 장애 가시성 사이의 선택입니다

모든 트레이스를 보관하면 비용이 늘고, 너무 많이 버리면 실패 원인을 놓칩니다. 정상 요청은 낮은 비율로 샘플링하고 오류·긴 지연 요청은 남기는 방식처럼 목적에 따라 정책을 나눌 수 있습니다.

메트릭은 집계 차원을 작게 유지하고, 로그에는 사용자 입력이나 토큰을 넣지 않습니다. 관측성을 높이려다 개인정보와 비용을 함께 키우지 않도록 합니다.

• 정상 트래픽: 대표적인 흐름을 볼 수 있을 정도로 샘플링합니다.
• 오류: 원인 분석에 필요한 속성을 남깁니다.
• 긴 지연: 임계값을 넘은 트레이스를 우선 보존합니다.

관측 데이터가 없을 때의 공백을 기록합니다

Collector나 백엔드가 장애 나면 애플리케이션이 정상이어도 관측 데이터가 끊길 수 있습니다. 그래서 저는 데이터가 들어오지 않는 상황을 별도의 알림으로 봅니다. ‘오류가 없다’와 ‘데이터가 없다’를 구분해야 합니다.

최소 구성으로 시작할 때는 앱·Collector·백엔드 세 곳의 상태와 마지막 수신 시각을 확인합니다. 나중에 규모가 커지면 보존 기간과 벤더 비용을 기준으로 확장합니다.

실험 결과를 운영 판단으로 바꾸는 순서

개발 문서에서 가장 재사용하기 어려운 문장은 ‘잘 됩니다’입니다. 어떤 버전과 데이터, 부하에서 잘 되었는지 모르면 독자는 자신의 환경에서 다시 확인할 수 없습니다. 저는 새로운 기능을 검토할 때 SDK·런타임·패키지·데이터베이스 버전을 먼저 고정하고, 기존 구현을 기준선으로 보관합니다. 변경 전후의 코드와 측정 명령도 함께 기록합니다.

측정값이 좋아도 운영에 바로 도입하지 않습니다. 오류 추적, 로그의 의미, 배포와 롤백, 팀이 이해할 수 있는지까지 확인합니다. 프리뷰나 변경 중인 문서는 정식 기능과 구분하고, 문서에 확인 날짜와 테스트 범위를 적습니다. 독자가 복사해 사용해도 위험하지 않도록 적용하지 말아야 하는 조건도 함께 적는 것이 기술 글의 중요한 부분입니다.

• 버전 잠금: 실험한 SDK·런타임·패키지·브라우저 버전을 기록합니다.
• 기준선: 변경 전 기능·성능·오류 결과를 같은 입력으로 보관합니다.
• 경계 사례: 빈 값·중복·실패·큰 입력에서 결과를 확인합니다.
• 배포 판단: 적용·보류·롤백 중 하나를 고르고 근거를 남깁니다.

다음 작업에서 다시 확인할 항목

한 번 적용한 방법이 언제나 같은 결과를 내는 것은 아닙니다. 사람과 서비스와 원고의 조건이 바뀌면 같은 원칙도 다른 판단을 요구합니다. 그래서 저는 글을 작성한 뒤 결론만 보관하지 않고, 결론이 성립한 조건과 다시 확인해야 할 조건을 함께 적습니다. 이 기록이 있으면 몇 달 뒤 글을 업데이트할 때 당시의 경험을 현재의 사실처럼 착각하지 않을 수 있습니다.

특히 버전·정책·가격·플랫폼 기능처럼 외부에서 바뀌는 내용은 조사한 날짜와 공식 문서의 주소를 남깁니다. 발행 시점에 문서가 달라졌다면 본문에 변경 사실을 표시하고, 직접 확인하지 못한 부분은 독자가 알 수 있도록 범위를 제한합니다. 경험을 공유하는 글도 다른 사람의 환경에 그대로 적용될 수 있으므로, 성공 사례보다 실패 조건을 함께 쓰는 편이 안전합니다.

마지막으로 이 글을 읽은 분이 바로 할 수 있는 행동은 하나로 줄입니다. 모든 항목을 한꺼번에 바꾸기보다 현재 상태를 기록하고, 작은 실험을 한 번 실행하고, 결과를 다시 적는 순서입니다. 그렇게 쌓인 기록이 다음 글의 소재가 되고, 처음의 판단을 더 정확하게 고쳐 쓰는 근거가 됩니다.

• 범위 표시: 이 글의 결론이 적용되는 환경과 적용되지 않는 환경을 구분합니다.
• 날짜 기록: 버전·정책·가격·문서를 확인한 날짜를 남깁니다.
• 실패 조건: 어떤 상황에서는 이 방법을 쓰지 말아야 하는지 적습니다.
• 작은 실행: 독자가 오늘 시도할 수 있는 가장 작은 행동을 고릅니다.
• 후속 기록: 실행 결과와 다음에 바꿀 조건을 별도 메모로 남깁니다.

이 기록을 나중에 다시 읽을 때는 결과만 보지 않고 당시의 조건도 함께 확인합니다. 조건이 달라졌다면 결론을 그대로 복사하지 말고 현재의 입력과 제약을 다시 적습니다. 그 과정을 거쳐야 이 글이 단순한 경험담이 아니라 다음 판단을 돕는 작업 기록으로 남습니다.

마치며

OpenTelemetry Collector의 장점은 데이터를 더 많이 모으는 데 있지 않고, 생성·전송·보관의 책임을 분리하는 데 있습니다. 서비스에서 가장 중요한 요청 하나를 골라 세 신호의 역할과 데이터가 끊겼을 때 확인할 곳을 먼저 정리해 보시기 바랍니다.

참고한 문서: OpenTelemetry .NET · OpenTelemetry Exporters