Go 모듈 경로를 github.com으로 시작하지 말라는 주장

Iain Cambridge가 9월 27일 개인 블로그에 쓴 글입니다. Go 커뮤니티에서 오래된 논의인데 Hacker News에서 다시 크게 돌았습니다.

문제

Go는 import 경로가 곧 코드의 위치입니다.

import "github.com/username/repo/pkg"

이게 표준 관행입니다. 그런데 이러면 코드가 호스팅 업체에 종속됩니다. GitHub에서 GitLab로 옮기는 순간, 이 모듈을 쓰는 모든 코드의 import 경로가 깨집니다. 모듈 이름 자체가 바뀌는 것이라 go.mod의 module 선언, 의존하는 쪽의 import, 내부 패키지 참조까지 전부 바꿔야 합니다.

대안 — vanity import path

자기 도메인을 모듈 경로로 씁니다.

import "go.iain.rocks/boneclone"

그리고 그 도메인의 웹서버가 go-import 메타태그로 실제 저장소 위치를 알려줍니다. Go 도구는 그 태그를 읽어 GitHub든 GitLab든 가서 받습니다. 저장소를 옮기면 메타태그 한 줄만 바꾸면 됩니다. 글은 nginx로 이 태그를 서빙하는 방법을 설명합니다.

그의 주장은 강합니다 — "Go를 쓰는 모든 상업 개발팀은 네임스페이스에 커스텀 도메인을 써야 한다." 동기는 자기 회사가 GitHub, GitLab, Azure DevOps를 동시에 운영하며 겪은 비용입니다.

글에 없는 것

반론이 없습니다. vanity 경로의 비용은 분명합니다 — 도메인과 그 메타태그를 서빙하는 서버를 모듈이 살아 있는 한 영구히 유지해야 합니다. 도메인 갱신을 놓치거나 서버가 죽으면 그 모듈을 쓰는 모든 빌드가 깨집니다. GitHub가 죽을 확률과 내 도메인·서버가 죽을 확률 중 어느 쪽이 높은지는 팀마다 다릅니다. 글은 이 저울질을 하지 않습니다.

실무에서 할 일

이미 공개한 라이브러리의 경로를 바꾸는 건 사용자 전부를 깨뜨리는 일이라 신중해야 합니다. 새로 시작하는 사내 모듈이라면 고려할 만합니다 — 특히 저장소 플랫폼 이전 가능성이 있는 조직이라면요. 그 경우 메타태그 서빙을 기존 사내 웹 인프라에 얹어 "서버 하나 더"가 되지 않게 하는 것이 요령입니다. 공개 오픈소스는 그냥 github.com 경로가 무난합니다.