SiliconValley_survivor

SiliconValley_survivor

Design SpaceX Telemetry, 화면에 숫자를 띄우는 일이 아니라 비행체의 상태를 지상에서 놓치지 않게 만드는 실시간 시스템

지상국 전환 구간에서 초당 1,400만 sample을 받으면서, 명령 중복 전송은 한 건도 허용하지 않는 지상 데이터 플랫폼

SiliconValley_survivor's avatar
SiliconValley_survivor
Jun 11, 2026
∙ Paid

Introduction & Requirements

발사 후 약 3분, booster와 2단이 분리되는 구간에서 지상국 handover가 일어났다고 해보겠습니다. 이전 지상국 경로에서 늦게 출발한 frame과 새 지상국 경로에서 먼저 도착한 frame이 몇 초 차이로 섞여 들어옵니다. 수신 서버가 도착 순서를 그대로 믿고 콘솔에 밀어 넣으면, propulsion 담당자는 압력 값이 잠깐 과거로 되돌아가는 화면을 보게 됩니다. 값 자체는 전부 정상인데 시간 순서가 어긋난 것입니다. 이 장면 하나가 원격 측정 플랫폼 설계에서 가장 먼저 다뤄야 할 문제를 보여줍니다. 센서 값을 받아 그래프에 띄우는 일이 아니라, 어떤 값이 지금 판단 가능한 값인지 구분하는 일이 이번 시스템 설계의 역할 입니다.

미리 분명히 해두겠습니다. 아래 설계는 공개된 발사체 사용자 가이드와 NASA의 공개 지상 시스템 자료를 참고해서 만든 면접용 설계 가정입니다. SpaceX 내부의 telemetry platform, command path, mission control 구현을 그대로 설명하는 글이 아니고, 본문에 나오는 컴포넌트 이름은 모두 이 글에서 정의한 것입니다.

공개 자료 기준으로 확인되는 사실은 이 정도입니다. Falcon의 avionics는 flight computer, GPS 수신기, 관성 측정 장치, S-band 송신기 등을 포함하고, S-band 송신기가 1단과 2단에서 지상으로 원격 측정과 영상을 전송합니다. 그리고 지상국은 telemetry, command, tracking을 서로 다른 서비스로 제공하며, 비행체에서 지상으로 내려오는 데이터 흐름은 downlink telemetry, 지상에서 비행체로 올라가는 흐름은 uplink command로 구분됩니다. 저궤도 비행체는 특정 지상국의 시야 안에 머무는 시간이 궤도의 일부에 그치고, relay 자산이 그 공백을 메웁니다.

이 서비스의 본질은 데이터 수집기가 아니라 판단 지원 시스템입니다. 발사, stage separation, 궤도 진입, docking, 재진입 같은 구간마다 flight controller가 화면의 값을 근거로 결정을 내립니다. 그래서 사용자가 보는 동선은 단순합니다. 콘솔을 열면 담당 subsystem의 최신 값, 경보, 추세, link 상태가 보이고, 필요하면 명령 요청을 올려 승인 절차를 거칩니다. 화면에서는 숫자 하나가 갱신되는 것처럼 보이지만, 그 뒤에서는 수신, 순서 보정, 중복 제거, 복호화, 우선순위 배포가 같이 돌아갑니다.

This post is for paid subscribers

Already a paid subscriber? Sign in
© 2026 실리콘밸리_생존자 · Privacy ∙ Terms ∙ Collection notice
Start your SubstackGet the app
Substack is the home for great culture