지구상에서 가장 긴 가시거리(Line of Sight)를 찾는 알고리즘: 530km의 뷰와 엔지니어링의 한계
Hacker News의 1면을 장식하는 프로젝트들을 보면, 종종 “이걸 왜 만들었지?” 싶으면서도 그 기술적 집요함에 감탄하게 되는 경우가 있습니다. 오늘 소개할 All The Views 프로젝트가 딱 그렇습니다.
“지구상에서 A지점과 B지점 사이의 장애물 없이 볼 수 있는 가장 긴 직선 거리는 어디일까?”
단순한 지리 덕후의 호기심 같지만, 엔지니어링 관점에서 보면 이건 꽤나 골치 아픈 Computational Geometry 문제입니다. 지구는 완벽한 구(Sphere)가 아닌 타원체(Ellipsoid)이고, 수십억 개의 데이터 포인트를 가진 DEM(Digital Elevation Model) 위에서 $O(N^2)$에 가까운 가시성 체크를 수행해야 하기 때문입니다.
이 프로젝트는 CacheTVS 라는 커스텀 알고리즘을 사용해 전 세계 45억 개의 뷰를 전수 조사했다고 주장합니다. 그리고 그 결과로 530km짜리 뷰(Hindu Kush에서 Pik Dankova까지)를 찾아냈죠.
하지만 진짜 재미있는 부분은 기술적 성취 그 자체보다, 댓글란에서 벌어진 설계의 트레이드오프(Trade-off)와 데이터 정합성 에 관한 논쟁입니다. 시니어 엔지니어로서 이 프로젝트가 주는 기술적 교훈을 뜯어보겠습니다.
1. 알고리즘의 확장성 vs 정밀도
이 프로젝트의 핵심 주장은 “전수 조사(Exhaustively checked)“입니다. 하지만 지구 전체의 고도 데이터를 1:1로 매칭하여 가시성을 체크하는 건 컴퓨팅 파워 측면에서 엄청난 비용이 듭니다.
작성자(Ryan)의 댓글에 따르면, 이들은 비용 절감을 위해 근사치(Approximation) 접근법을 택했습니다. DEM 데이터를 관찰자 중심으로 회전시키는 대신, 시야각(Band of sight)을 보간(Interpolate)하는 방식을 쓴 것으로 보입니다. 이는 대규모 데이터를 처리할 때 흔히 발생하는 Scale vs Precision 의 트레이드오프입니다.
2. “좌표가 계곡에 있는데요?” - 결정적인 버그 리포트
제가 항상 주니어들에게 하는 말이 있습니다. “엣지 케이스(Edge Case)는 항상 경계값에서 터진다.”
Hacker News 댓글란의 Marc라는 유저(이 분야의 고인물로 추정됨)가 등판해서 이 프로젝트의 치명적인 결함을 지적했습니다. Marc는 경쟁 알고리즘을 돌려본 결과, 해당 뷰가 530.8km가 아니라 538.1km라고 주장했습니다. 더 중요한 건, All The Views가 제시한 좌표가 산 정상이 아니라 계곡(Valley) 에 찍혀 있다는 것입니다.
“Clearly the error is on your side… the coordinates you give land in a valley with the south view completely blocked.”
이것은 전형적인 Sampling Error 거나 좌표계 변환 과정에서의 정밀도 손실로 보입니다. 전 지구를 대상으로 하는 알고리즘을 짤 때, 3 arc-second(약 90m) 해상도의 DEM 데이터를 쓰다 보면 좌표가 조금만 튀어도 관찰자가 산봉우리가 아닌 산비탈이나 골짜기에 위치하게 됩니다. 가시성 알고리즘에서 관찰자의 높이(Z값)는 생명인데, XY 좌표의 미세한 오차가 Z값을 망가뜨리고, 결과적으로 Line of Sight 전체를 무효화시킨 케이스입니다.
3. 대기 굴절(Refraction)이라는 변수
순수 알고리즘 문제에서 물리 엔진 문제로 넘어가는 지점입니다. 이론상 530km가 보인다고 해도, 실제로는 대기가 가만히 있지 않습니다. 댓글에서는 대기 굴절 계수(Refraction Coefficient) 에 대한 논의가 활발합니다. 보통 0.13 정도를 상수로 두지만, 500km가 넘는 거리에서는 이 계수의 미세한 차이가 시야각을 완전히 바꿔버립니다.
특히 뮌헨에서 알프스를 볼 때 발생하는 푄 현상(Föhn effect) 처럼, 대기가 렌즈 역할을 하여 실제보다 사물을 크고 가깝게 보이게 만드는 경우도 있습니다. 소프트웨어로 치면 ‘하드웨어 가속’이나 다름없는 자연 현상인데, 이것까지 시뮬레이션에 포함하지 않으면 “이론상 최장 거리”는 그저 null 포인터 같은 허상일 뿐입니다.
4. UX: 데이터는 보여주는 방식이 절반이다
기술적으로 아무리 훌륭한 백엔드 로직을 짰어도, 프론트엔드에서 사용자에게 감동을 주지 못하면 실패한 프로젝트입니다. 한 유저는 이렇게 불평했습니다.
“It feels like the site is setting you up for the big suspense… and then it’s just a line on a 2D map.”
맞는 말입니다. 530km의 웅장한 뷰를 찾았다고 해놓고 2D 지도 위에 빨간 선 하나 그어주는 건, 4K 동영상을 텍스트로 설명하는 것과 같습니다. 구글 어스(Google Earth) API를 연동하거나, 최소한 3D 지형 렌더링을 통해 그 ‘높이감’을 전달했어야 합니다.
결론: 훌륭한 MVP, 하지만 프로덕션 레벨은 아니다
이 프로젝트는 엔지니어링 적으로 매우 흥미로운 시도입니다. 전 지구적 규모의 데이터를 처리하려는 대담함은 높이 평가합니다. 하지만 Marc의 지적처럼, 데이터의 정합성(Integrity) 검증 단계에서 아쉬움이 남습니다. 특히 ‘세계 기록’을 주장하려면 근사치 알고리즘보다는, 후보군을 추린 뒤 정밀 알고리즘으로 2차 검증(Double Verification)을 수행하는 파이프라인을 구축했어야 합니다.
Key Takeaways:
- Scale: 전수 조사를 할 때는 근사치를 쓰되, 최종 결과물에 대해서는 정밀 검증을 거쳐라.
- Debug: 도메인 전문가(여기서는 지리학 덕후들)의 피드백은 최고의 QA다.
- UX: 데이터 시각화 프로젝트에서 ‘시각화’를 게을리하지 마라.
그래도 오랜만에 “지구 반대편 뚫기(Antipoles)” 같은 낭만적인 기술 토론을 볼 수 있어 즐거웠습니다. 다음엔 대기 굴절까지 레이 트레이싱(Ray Tracing)으로 구현한 프로젝트가 나오길 기대해 봅니다.