텔레메트리

텔레메트리는 떨어져 있는 기계가 자기 상태를 스스로 재서 지켜보는 쪽으로 보내 주는 일입니다. 가 보지 않고도 그 기계에서 무슨 일이 나는지 알게 됩니다. 원래는 로켓이나 산꼭대기 관측 장비처럼 사람이 붙어 있을 수 없는 기계에서 쓰던 말입니다. 소프트웨어에서는 돌아가는 프로그램이 스스로 내보내는 관찰 기록을 통틀어 이렇게 부릅니다.

쉽고 빠른 이해

텔레메트리는 시스템이 자기 사정을 스스로 적어 밖으로 보내는 일입니다. 웹 서버가 요청 하나를 처리할 때마다 걸린 시간을 재서 감시 서버로 보내는 것이 그런 예입니다.

이것이 없으면 서버에 직접 들어가 로그 파일을 열어 봐야 합니다. 서버가 수백 대이거나 손님 손에 들어간 기기라면 그 방법이 막힙니다.

어떻게 도는가:

코드에 신호를 내보내는 부분을 심어 둡니다
프로그램이 돌면서 그 부분에서 기록이 나옵니다
기록을 모아 네트워크로 받는 쪽에 보냅니다
받은 쪽이 저장해 두고 화면과 알림으로 보여 줍니다

대가도 있습니다. 신호를 만들고 보내는 만큼 프로그램이 할 일이 늘고, 쌓인 데이터를 보관하는 비용이 듭니다. 심어 두지 않은 것은 나중에 아무리 뒤져도 안 나옵니다.

상세

산꼭대기 기상 관측소를 떠올려 봅시다. 사람이 머물지 않아도 온도계와 풍속계가 값을 재서 산 아래 사무실로 무선으로 보냅니다.

텔레메트리는 재는 곳과 보는 곳이 떨어져 있을 때, 재는 쪽이 스스로 값을 만들어 보는 쪽으로 보내는 일입니다. 그렇게 보내진 데이터 자체를 가리키기도 합니다. 두 뜻이 섞이는 것이 싫으면 데이터 쪽을 「텔레메트리 데이터」라고 길게 부릅니다.

이름은 멀다는 뜻의 말과 잰다는 뜻의 말을 이어 붙인 것입니다. 로켓이나 기상 관측 장비처럼 사람이 옆에 붙어 있을 수 없는 기계에서 먼저 쓰였습니다. 소프트웨어는 그 말을 가져와 프로그램이 내보내는 기록에 붙였습니다.

서버가 한 대라면 접속해서 로그 파일을 열어 보면 됩니다. 서버가 수백 대로 늘고 손님 손에 들어간 기기까지 끼면 그 방법이 막힙니다. 텔레메트리는 보러 가는 대신 기계 쪽이 먼저 말하게 하는 방법입니다.

밖으로 나온 것만 보고 안을 얼마나 알아낼 수 있는가 하는 성질을 관측성이라고 부릅니다. 텔레메트리는 그 성질을 얻으려고 내보내는 재료입니다. 내보낸 적 없는 사실은 어떤 도구로도 되짚을 수 없습니다.

데이터가 거치는 네 단계

신호가 만들어져 사람 눈에 닿기까지 네 단계를 지납니다. 어느 한 단계가 끊기면 뒤 단계는 아무것도 못 봅니다.

flowchart TD
    A["돌아가는 프로그램"] -->|계측| B["신호를 만든다"]
    B --> C["모으고 다듬는다"]
    C --> D["정해진 모양으로 내보낸다"]
    D --> E["받아서 저장한다"]
    E --> F["화면과 알림"]

첫 단계는 계측입니다. 신호를 내보내도록 코드에 심어 두는 일입니다. 심어 둔 곳에서만 신호가 나오므로, 여기서 안 심은 것은 뒤 단계에서 만들어 낼 수 없습니다.

둘째는 모으고 다듬는 단계입니다. 신호가 날 때마다 곧바로 내보내면 네트워크 호출이 요청 수만큼 늘어납니다. 그래서 잠시 쌓아 두었다가 묶어 보내고, 보내기 전에 필요 없는 항목을 덜어 냅니다.

셋째는 내보내는 단계입니다. 신호를 정해진 모양으로 바꿔 받는 쪽으로 보냅니다. 보내는 쪽과 받는 쪽을 서로 다른 회사 제품으로 맞춰도 되도록 데이터 모양을 표준으로 정해 두기도 합니다. OpenTelemetry가 그런 표준을 만드는 프로젝트입니다.

넷째는 받아서 저장하고 보여 주는 단계입니다. 이 서버를 관측성 백엔드라고 부릅니다. 쌓아 둔 값으로 대시보드를 그리고, 값이 정해둔 조건을 벗어나면 알림을 냅니다.

내보내는 신호의 갈래

무엇을 내보내는지는 크게 셋으로 갈립니다. 셋은 같은 시스템을 보되 답하는 질문이 다릅니다.

신호	무엇을 남기나	답하는 질문
로그	그때 일어난 일 한 건	그 순간 무슨 일이 있었나
메트릭	시간에 따라 모은 숫자	전체적으로 얼마나 자주, 얼마나 오래 걸리나
트레이스	요청 하나가 거친 길	이 요청은 어디를 지나 어디서 막혔나

셋을 함께 쓰면 범위를 좁혀 들어갈 수 있습니다. 메트릭으로 언제부터 응답이 늦어졌는지 찾고, 그때의 트레이스로 어느 구간이 늦었는지 찾고, 그 구간의 로그로 무슨 일이 있었는지 읽습니다.

넷째로 프로파일을 함께 세는 경우도 있습니다. 프로그램이 시간을 어느 함수에서 썼는지를 남긴 것입니다.

신호 한 건에는 대개 넷이 붙어 다닙니다. 잰 시각, 무엇을 잰 것인지 가리키는 이름, 값, 그리고 그 값이 무엇에 대한 것인지 갈라 주는 꼬리표입니다. 아래는 설명을 위해 지어낸 한 건입니다.

잰 시각   2026-03-11 14:02:37
이름     주문 조회 응답 시간
값       128 밀리초
꼬리표    서비스=주문, 경로=/orders, 응답 코드=200

꼬리표를 잘게 나눌수록 갈라 볼 수 있는 것이 늘어납니다. 대신 꼬리표 값의 가짓수만큼 따로 쌓이는 줄이 늘어납니다. 이 가짓수를 카디널리티라고 부릅니다.

나르는 방식 두 가지

재는 쪽과 받는 쪽 가운데 누가 먼저 움직이느냐로 갈립니다. 앞의 것을 푸시, 뒤의 것을 풀이라고 부릅니다.

푸시는 재는 쪽이 먼저 움직입니다. 프로그램이 신호를 만들 때마다 받는 쪽으로 보냅니다. 받는 쪽 주소를 프로그램이 알고 있어야 합니다. 잠깐 떴다 사라지는 작업처럼 밖에서 찾아가기 어려운 것에 맞습니다.

풀은 받는 쪽이 먼저 움직입니다. 감시 서버가 주기마다 프로그램에 물어보러 갑니다. 프로그램은 지금 값을 내주는 주소 하나만 열어 두면 됩니다. 대신 감시 서버가 어느 주소들을 돌아야 하는지 알고 있어야 합니다. Prometheus가 이렇게 걷어 가는 쪽입니다.

다 내보내지 않는 까닭

요청이 늘면 신호도 같이 늘어납니다. 전부 내보내면 네트워크와 저장 비용이 요청 수에 비례해 불어납니다. 그래서 줄이는 방법을 함께 씁니다.

한 가지는 일부만 골라 남기는 것입니다. 이것을 샘플링이라고 부릅니다. 고르는 방법에 따라 나중에 보고 싶은 실패 건이 안 남아 있을 수 있습니다.

다른 한 가지는 여러 건을 하나로 접는 것입니다. 이것을 집계라고 부릅니다. 한 시간 동안 들어온 요청을 세어 한 줄로 접으면 보관할 양이 줄어듭니다. 대신 접는 순간 그 안에서 무슨 일이 있었는지는 사라집니다.

제품이 사용자 기기에서 걷어 가는 텔레메트리

같은 말이 다른 쪽에서도 쓰입니다. 편집기나 브라우저나 모바일 앱이 사용자 기기에서 사용 기록을 만들어 만든 쪽으로 보내는 것도 텔레메트리라고 부릅니다. 어떤 기능을 얼마나 쓰는지, 어디서 프로그램이 죽었는지 같은 것입니다.

보내는 얼개는 앞에서 본 것과 같습니다. 다른 점은 데이터가 남의 기기에서 나온다는 것입니다. 그래서 무엇을 보내는지 밝히고 끌 수 있게 하는 일이 따라붙습니다. 처음에 꺼져 있고 사용자가 켜는 방식과, 켜져 있고 사용자가 끄는 방식이 갈립니다.

이 갈래에서는 개인을 알아볼 수 있는 값이 섞이지 않게 거르는 일이 커집니다. 파일 경로나 사용자가 입력한 내용이 오류 보고에 묻어 나가는 일이 생기기 때문입니다.