브라우저에서 별이 흐른다, 로컬 우선 천문관 'Zenith' 만든 이야기

밤하늘을 좋아하는 개발자라면 한 번쯤 별자리 앱을 깔아보셨을 거예요. Stellarium 같은 데스크탑 프로그램은 거의 학술 도구 수준으로 정교한데, 설치가 무거워서 "지금 당장 잠깐 별 보고 싶다"는 충동에는 잘 안 맞죠. 반대로 웹 기반 별 보기 사이트는 가볍긴 한데 데이터가 단순하거나 인터넷이 끊기면 무용지물이고요. 그 사이의 빈자리를 노린 게 이번에 소개할 Zenith라는 프로젝트예요. 만든 분이 직접 "라이브, 로컬 퍼스트, 고정 뷰포트 천문관"이라고 소개하고 있는데, 세 단어 하나하나가 다 디자인 결정이라 재밌습니다.

로컬 퍼스트가 뭔데요

"로컬 퍼스트(Local-first)"라는 말이 좀 낯설 수 있는데요, 쉽게 말하면 데이터의 본진을 사용자 기기에 두자는 철학이에요. 요즘 대부분의 웹 앱은 서버에 데이터가 있고, 브라우저는 그걸 잠깐 빌려와서 보여주는 식이거든요. 인터넷이 끊기면 아무것도 못 하죠. 로컬 퍼스트는 반대로 모든 데이터를 브라우저(IndexedDB 같은 저장소)에 먼저 두고, 서버는 그저 동기화 역할만 합니다. 비행기 안이든 산속이든, 일단 한 번 열어봤으면 그 다음부터는 오프라인에서도 잘 돌아가요.

별자리 앱에 이게 왜 어울리냐면, 별을 보려고 외진 곳으로 갈수록 인터넷이 안 터지잖아요. 강원도 산골에 가서 "별 보러 왔는데 LTE가 안 잡혀서 앱이 안 켜져요" 같은 상황이 생기면 본말이 전도된 거죠. Zenith는 별 카탈로그 데이터를 한 번 받아두면 그 다음부터는 완전히 오프라인에서 동작합니다.

고정 뷰포트와 라이브

"고정 뷰포트(Fixed Viewport)"는 화면을 자유롭게 돌려보는 일반 천문관과 달리, 정해진 시야 안에서만 별을 보여준다는 뜻이에요. 처음 들으면 좀 답답할 것 같은데, 의도가 있어요. 사용자의 현재 위치에서 머리 위(천정, Zenith)에 보이는 하늘만 그려주는 거예요. 그래서 이름도 Zenith고요. 이렇게 제약을 두면 UI가 단순해지고, 렌더링도 가벼워지고, 무엇보다 "지금 내 머리 위에 진짜 뭐가 있나"를 즉답해주는 도구가 됩니다.

"라이브"는 시간이 흐르면 별도 흘러간다는 의미예요. 지구가 자전하니까 별의 위치도 1초마다 미세하게 움직이는데, Zenith는 이걸 실시간으로 다시 계산해서 캔버스에 다시 그립니다. 천체 위치 계산은 의외로 수학이 깊은 분야인데, 적위/적경(별의 좌표계) 같은 개념을 사용자의 위도/경도와 시간에 맞춰 변환해야 하거든요. 보통 Hipparcos나 Tycho 카탈로그 데이터를 베이스로 쓰고, 좌표 변환은 J2000 같은 표준 기준점을 이용해서 합니다.

비슷한 프로젝트들과 어떻게 다를까

웹 천문관 분야에는 Stellarium Web, In-The-Sky.org, NASA Eyes 같은 선배들이 있어요. 다들 훌륭한데 대부분 서버 의존적이거나, 사용자가 마우스로 빙빙 돌려보는 "인터랙티브 우주관" 컨셉이에요. Zenith는 "내가 지금 누워서 하늘 보면 정확히 뭐가 있나"를 한 화면에 박제해주는 것에 집중하니까, 용도가 명확히 갈립니다.

로컬 퍼스트 운동 자체도 흥미로워요. 잉크앤스위치(Ink & Switch) 연구소가 2019년에 매니페스토를 발표한 이후로, Linear, Obsidian, Figma 같은 제품들이 비슷한 철학을 받아들이고 있거든요. CRDT(충돌 없는 복제 데이터 타입) 같은 기술이 핵심인데, 협업 편집을 오프라인에서도 가능하게 해주는 마법 같은 자료구조예요.

한국 개발자에게 주는 영감

사이드 프로젝트로 뭘 만들지 고민이라면, "로컬 퍼스트 + 좁은 도메인" 조합은 정말 매력적인 출발점이에요. Zenith처럼 한정된 기능을 깊이 파면 사용자 경험이 단단해지고, 인프라 비용도 거의 안 들어요(서버가 작아도 되니까). PWA, IndexedDB, Service Worker 같은 기술을 익히는 좋은 핑계이기도 하고요.

천문 데이터에 관심 있다면 한국천문연구원이 공개하는 천체력 데이터나 NASA JPL의 Horizons API도 활용할 만합니다. 별자리 앱이 아니어도 비슷한 패턴—"한 화면에 라이브 데이터, 오프라인 동작"—은 운동 기록, 명상, 일기 같은 도메인에서도 잘 통해요.

마무리

Zenith는 화려한 기능 자랑이 아니라, 제약을 잘 고른 디자인이 결과적으로 더 좋은 도구를 만든다는 걸 보여주는 좋은 예예요. "모든 걸 할 수 있는 앱"보다 "이 하나는 확실히 잘하는 앱"이 사용자에겐 더 사랑받죠.

여러분은 사이드 프로젝트를 만들 때 기능을 늘리는 편인가요, 줄이는 편인가요? 로컬 퍼스트 앱을 만들어본 경험이 있다면 어떤 점이 가장 어려웠는지도 궁금하네요.