도입
코드만 짜던 개발자가 어느 날 자기 손으로 망원경을 깎기 시작한다면 어떨까요? 'Wallace'라는 이름의 6인치 f/2.8 망원경 제작기가 딱 그런 이야기예요. 단순히 망원경을 사서 쓰는 게 아니라, 직접 설계하고 만들어서 그걸 배낭에 넣고 산에 올라 별을 보는 여정이거든요. 소프트웨어 하는 사람이 광학, 기계 설계, 제작까지 넘나드는 이 프로젝트가 왜 흥미로운지 짚어볼게요.
f/2.8 6인치가 뭐가 대단하냐면요
망원경 스펙에서 “6인치(약 150mm)”는 거울(주경)의 지름이에요. 빛을 얼마나 모으는지를 결정하죠. “f/2.8”은 초점비라고 하는데, 초점거리를 지름으로 나눈 값이에요. f/2.8이면 초점거리가 약 420mm로 굉장히 짧아요. 이게 왜 대단하냐면, 초점비가 작을수록(빠를수록) 망원경이 짧고 가벼워지지만, 그만큼 거울을 정밀하게 깎기가 어마어마하게 어려워지거든요.
쉽게 비유하면, 완만한 곡면은 대충 갈아도 빛이 얼추 모이는데, f/2.8처럼 깊고 가파른 곡면(포물면)은 아주 미세한 오차만 있어도 별이 점이 아니라 번진 얼룩으로 보여요. 게다가 빠른 망원경은 코마(별이 혜성처럼 꼬리를 다는 수차)에 민감하고, 광축 정렬(콜리메이션)이 조금만 틀어져도 상이 망가져요. 그래서 f/2.8 6인치를 직접 만든다는 건 광학적으로 상당한 도전이에요. 그걸 또 산에 들고 갈 만큼 가볍게 만든다는 건 기계 설계의 도전이고요. 무게를 줄이려고 구조를 깎으면서도, 휴대성과 강성(흔들리지 않는 단단함) 사이에서 줄타기를 해야 하니까요.
개발자의 접근법
이 프로젝트가 특히 개발자에게 와닿는 건, 문제를 푸는 방식이 우리가 코드 짤 때랑 닮았기 때문이에요. 망원경 광학은 사실 빛이 거울과 렌즈를 어떻게 튕겨 다니는지를 계산하는 일이라, 광선 추적(ray tracing) 같은 시뮬레이션으로 만들기 전에 설계를 검증할 수 있어요. 같은 저자는 광학계를 코드로 시뮬레이션하는 작업을 해왔고요. “만들기 전에 모델로 검증하고, 만들면서 측정하고, 측정값으로 다시 보정한다”는 이 반복 루프는 테스트 주도 개발이랑 똑같은 사고방식이에요. 거울을 깎고(연마), 곡면이 맞는지 측정하고, 틀어진 만큼 다시 깎는 과정이 그야말로 디버깅이죠.
업계, 아니 취미 맥락
망원경 자작은 생각보다 깊은 전통이 있어요. 아마추어 천문 동호인들이 직접 거울을 갈아 만드는 ATM(Amateur Telescope Making) 문화는 100년 넘게 이어져 왔고, 요즘은 3D 프린팅과 오픈소스 설계 덕분에 진입 장벽이 확 낮아졌어요. 가벼운 트래블 도브소니안, 접이식 망원경처럼 “들고 다니는 천문” 흐름도 커지고 있고요. Wallace는 그 흐름 속에서 “내가 원하는 스펙을 시장에서 안 팔면 직접 만든다”는 메이커 정신의 좋은 예예요. 시판 제품엔 f/2.8 6인치 같은 극단적 조합이 잘 없거든요.
한국 개발자에게
직접적인 업무 연관은 없을 수 있어요. 하지만 이런 크로스 도메인 프로젝트가 주는 가치가 분명히 있어요. 평소 추상적인 코드만 다루다가 물리적인 물건을 만들면, 오차·공차·측정처럼 소프트웨어에선 추상화돼 안 보이던 현실의 제약을 몸으로 배우게 돼요. 시뮬레이션으로 설계를 검증하고 실측으로 보정하는 경험은 그대로 엔지니어링 감각이 되고요. 무엇보다 “사고 싶은 게 없으면 만든다”는 자세, 그리고 그 결과물을 들고 산에 올라 직접 즐기는 모습은, 번아웃 오기 쉬운 개발자에게 좋은 자극이 돼요. 주말 사이드 프로젝트의 스펙트럼을 넓혀주는 이야기죠.
마무리
한 줄 정리: Wallace는 “개발자의 문제 해결 방식이 코드 밖 물리 세계에서도 통한다”는 걸 보여주는 자작 망원경 프로젝트예요. 여러분은 코딩 말고 손으로 뭔가를 만드는 취미가 있나요? 그 경험이 개발에 도움이 된 적 있으세요?
🔗 출처: Hacker News