Nix 전용 CI '가닉스(Garnix)'가 문을 닫습니다 — 틈새 개발자 서비스의 숙명

Nix 전용 CI 하나가 문을 닫습니다

Nix 생태계에서 CI 서비스를 제공하던 가닉스(Garnix)가 서비스 종료를 발표했어요. 여기서 CI(Continuous Integration, 지속적 통합)란, 개발자가 코드를 올릴 때마다 자동으로 빌드하고 테스트를 돌려서 '이거 망가진 데 없나?'를 기계가 대신 확인해 주는 시스템을 말해요. 깃허브 액션스(GitHub Actions)나 젠킨스(Jenkins) 같은 게 대표적이죠. 가닉스는 그중에서도 'Nix'라는 특정 도구에 특화된 서비스였는데, 이번 종료 소식은 니치(틈새) 개발자 서비스가 어떤 어려움을 겪는지 잘 보여주는 사례라 짚어볼 만해요.

Nix가 뭐냐면

먼저 Nix부터 풀어볼게요. Nix는 패키지 관리자이자 빌드 시스템인데, 가장 큰 특징은 '재현 가능한 빌드(reproducible build)'예요. 이게 뭐냐면, 똑같은 입력을 넣으면 언제, 어떤 컴퓨터에서 빌드하든 항상 똑같은 결과물이 나오도록 만드는 거예요. 개발하다 보면 '내 컴퓨터에선 분명 됐는데 서버에선 안 돼요'라는 상황 많이 겪잖아요. Nix는 빌드에 쓰이는 모든 의존성을 해시(고유한 지문 같은 값)로 엄격하게 묶어버려서, 이 '환경이 달라서 생기는 문제'를 근본부터 없애려는 도구거든요.

가닉스가 특별했던 이유

Nix의 이런 성질은 CI와 궁합이 아주 좋아요. 빌드 결과가 해시로 관리되니까, 바뀌지 않은 부분은 이미 만들어 둔 결과물을 그대로 재사용할 수 있거든요. 이걸 '바이너리 캐시(binary cache)'라고 하는데, 덕분에 매번 처음부터 다 빌드하지 않고 바뀐 부분만 새로 빌드하면 돼서 CI가 훨씬 빨라져요. 가닉스는 바로 이 점을 살려서, Nix 프로젝트를 쓰는 팀이 별다른 설정 고생 없이 빠른 CI를 쓸 수 있게 해주던 서비스였어요.

왜 이런 서비스는 살아남기 어려울까

문제는 '시장 크기'예요. Nix는 강력하지만 아직 배우기 어렵기로 악명이 높아서, 사용자층이 넓지는 않거든요. 그 안에서도 '유료 CI에 돈을 낼 만한 팀'은 더 적고요. 반면 CI 인프라는 빌드용 서버를 계속 돌려야 하니 비용이 꾸준히 나가요. 사용자는 적은데 고정비는 만만찮은 구조라, 작은 팀이 운영하는 니치 서비스가 지속 가능한 수익을 내기가 정말 빠듯한 거죠. 거대 플랫폼인 깃허브 액션스가 무료 사용량을 넉넉히 풀어버리면, 전문 서비스의 입지는 더 좁아지고요.

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

두 가지를 말씀드리고 싶어요. 첫째, 개발 도구를 고를 때는 '이 서비스가 사라지면 어떻게 되지?'를 한 번쯤 생각해보면 좋아요. 특정 외부 서비스에 깊이 묶이면(이걸 벤더 종속, vendor lock-in이라고 해요) 그 서비스가 문 닫을 때 이사 비용이 크거든요. 다행히 Nix는 그 자체가 오픈소스 표준이라, 가닉스가 사라져도 같은 빌드를 다른 곳이나 셀프 호스팅으로 옮기기가 상대적으로 수월해요. 재현 가능한 빌드의 또 다른 장점인 셈이죠.

둘째, Nix라는 기술 자체는 여전히 배워둘 가치가 충분해요. 'CI 서비스 하나가 닫혔다'는 것과 'Nix가 한물갔다'는 건 전혀 다른 이야기거든요. 환경 차이로 인한 빌드 문제에 자주 시달린다면, Nix의 사고방식만 익혀둬도 도움이 될 거예요. 여러분의 프로젝트는 외부 서비스에 얼마나 의존하고 있나요? 만약 그게 내일 사라진다면, 옮겨갈 계획이 있으신가요?