메모리 69KB, 8트랙 테이프로 48년째 작동 중인 보이저 1호 이야기

1977년에 떠난 컴퓨터가 아직 살아있다

지금 이 글을 읽고 있는 여러분의 스마트폰 RAM은 보통 8GB에서 16GB 정도 되죠. 그런데 지금 이 순간에도 지구에서 약 248억 km 떨어진 곳에서 묵묵히 데이터를 보내고 있는 컴퓨터가 있어요. 메모리가 고작 69KB인 컴퓨터가요. 바로 NASA의 보이저 1호인데요, 1977년에 발사된 이 탐사선이 2026년인 지금까지도 작동하고 있다는 건 정말 경이로운 일이에요.

69KB로 무엇을 할 수 있을까

69KB가 얼마나 작은지 감이 잘 안 올 수 있는데요. 요즘 웹 페이지 하나 로딩하면 평균적으로 수 MB의 JavaScript가 내려오잖아요. React로 "Hello World" 앱을 빌드해도 번들 사이즈가 수백 KB는 되거든요. 69KB로는 그 "Hello World"도 못 돌려요. 하지만 보이저 1호는 이 메모리로 항법 계산, 과학 데이터 수집, 지구와의 통신, 자세 제어까지 전부 해내고 있어요.

보이저의 컴퓨터 시스템은 세 개의 독립적인 컴퓨터로 구성돼 있어요. 명령 및 제어를 담당하는 CCS(Computer Command Subsystem), 자세 제어를 담당하는 AACS(Attitude and Articulation Control Subsystem), 그리고 비행 데이터를 처리하는 FDS(Flight Data Subsystem)인데요. 각각의 역할이 명확하게 분리돼 있어서 하나가 문제가 생겨도 나머지가 독립적으로 동작할 수 있는 구조예요. 요즘 말로 하면 마이크로서비스 아키텍처의 원조라고 할 수도 있겠네요.

데이터 저장은 디지털 8트랙 테이프 레코더(DTR)를 사용해요. 8트랙 테이프라고 하면 1960~70년대에 음악 듣던 카세트 같은 건데요, 보이저에서는 이걸 데이터 저장 매체로 쓰고 있어요. 용량은 약 536 메가비트, 대략 67MB 정도인데요. 요즘 기준으로는 사진 한 장 정도의 크기지만, 그 시절 기술로는 엄청난 용량이었어요.

48년간 작동하는 소프트웨어의 비밀

보이저의 소프트웨어가 48년간 멈추지 않고 돌아간다는 건 소프트웨어 엔지니어링 관점에서 정말 대단한 일이에요. 요즘은 서비스를 1년만 운영해도 "레거시"라고 부르면서 리팩토링하고 싶어하잖아요. 그런데 이 소프트웨어는 업데이트 한 번 하려면 신호가 지구에서 보이저까지 가는 데만 약 22시간이 걸려요. 응답을 받으려면 또 22시간. 한 번의 명령-응답 사이클이 거의 이틀이나 걸리는 거죠.

그래서 NASA 엔지니어들은 소프트웨어 업데이트를 정말 신중하게 해요. 지구에서 시뮬레이션을 수도 없이 돌리고, 검증에 검증을 거친 다음에야 명령을 보내거든요. 한 번 잘못 보내면 되돌릴 수 없으니까요. 이건 CI/CD 파이프라인에서 자동 배포하는 것과는 차원이 다른 이야기예요.

실제로 2023년에는 AACS 시스템에서 이상 데이터가 전송되는 문제가 발생했는데요, NASA 팀이 몇 달에 걸쳐 원인을 분석하고, 48년 된 코드를 수정하는 패치를 만들어서 원격으로 적용했어요. 이때 엔지니어들이 참고한 건 1970년대에 작성된 어셈블리 코드 문서였다고 해요.

제약이 만들어낸 엔지니어링의 정수

보이저 프로젝트에서 배울 수 있는 가장 큰 교훈은 "제약 조건이 최고의 엔지니어링을 만든다"는 거예요. 메모리가 69KB밖에 없으니 모든 바이트를 아껴 써야 했고, 한 번 배포하면 실질적으로 되돌리기 어려우니 코드 한 줄 한 줄에 극도의 주의를 기울여야 했어요.

요즘 개발 환경은 반대잖아요. 메모리는 넘치고, 배포는 하루에도 여러 번 할 수 있고, 문제가 생기면 롤백하면 되니까요. 그래서 node_modules 폴더가 수백 MB가 되는 것도, Electron 앱이 수 GB의 메모리를 잡아먹는 것도 당연하게 받아들이게 되는 것 같아요.

보이저의 프로세서는 클럭 속도가 약 250kHz예요. 요즘 스마트폰 프로세서가 3GHz대니까 만 배 이상 차이가 나는 거죠. 그런데 이 느린 프로세서로 항성 간 공간에서의 항법 계산을 해내고 있어요. 알고리즘의 효율성이 하드웨어 성능보다 얼마나 중요한지를 보여주는 극단적인 사례인 거죠.

한국 개발자에게 주는 시사점

물론 우리가 당장 69KB 메모리에서 돌아가는 코드를 짜야 할 일은 없어요. 하지만 임베디드 시스템이나 IoT 디바이스를 개발하는 분들이라면 리소스 제약 환경에서의 최적화가 여전히 중요한 역량이에요. 한국의 반도체·가전 기업들에서 임베디드 펌웨어 개발자를 꾸준히 채용하고 있는 것도 이런 맥락이거든요.

그리고 꼭 임베디드가 아니더라도, "리소스가 넘치는 환경에서도 효율적으로 쓰자"는 마인드셋은 좋은 개발 습관이에요. 프론트엔드에서 번들 사이즈를 줄이고, 백엔드에서 메모리 릭을 관리하고, 쿼리 최적화를 하는 건 다 같은 맥락이거든요.

보이저의 소프트웨어 아키텍처에서 얻을 수 있는 또 다른 교훈은 장애 격리(fault isolation)예요. 세 개의 독립적인 컴퓨터 시스템이 각자의 역할만 수행하면서도 전체 시스템이 조화롭게 동작하는 구조는, 지금의 분산 시스템 설계에서도 추구하는 이상적인 모습이거든요.