"Go 언어 패키지 경로에 깃허브 주소 그대로 박지 마세요" 개발자가 경고하는 이유

요약 Go 언어에서는 라이브러리를 가져올 때 패키지 경로 자체에 저장소 위치(예: github.com/사용자명/프로젝트명)를 직접 명시하는 방식을 사용합니다. 별도의 중앙 패키지 매니저 없이도 git을 통해 패키지를 쉽게 배포하고 버그 리포트 위치를 직관적으로 파악할 수 있다는 장점이 있지만, 치명적인 단점이 존재합니다. 바로 코드가 특정 깃 호스팅 서비스(GitHub 등)에 완전히 종속(커플링)된다는 점입니다. 만약 사내 정책이나 기타 이유로 호스팅 플랫폼을 GitLab이나 다른 서비스로 이전해야 할 경우, 모든 코드 내의 import 경로를 일일이 수정해야 합니다. 코드를 고치지 않으면 계속 옛날 버전을 바라보게 되기 때문입니다. 실제로 작성자가 겪은 한 기업의 사례에서는, 코드 내 경로 변경 작업이 너무 방대하고 시간 여유가 없다는 이유로 GitHub, GitLab, Azure DevOps 세 곳을 동시에 결제하며 운영하는 촌극이 벌어지기도 했습니다. 호스팅 종속성 문제 때문에 플랫폼을 하나로 통일하지 못하고 불필요한 비용을 계속 지출한 것입니다. 작성자는 이러한 문제를 방지하기 위해 우버(go.uber.org)나 몽고DB(go.mongodb.org)처럼 처음부터 자체 커스텀 도메인을 패키지 네임스페이스로 사용할 것을 권장합니다. 커스텀 도메인을 사용하면 실제 깃 저장소 위치가 어디로 바뀌든 도메인 설정(Nginx 리다이렉트 및 HTML 메타 태그)만 변경하면 되므로, 사용자나 내부 코드의 import 문을 일절 수정할 필요가 없기 때문입니다. 작성자는 상업용 소프트웨어를 개발하는 Go 팀이라면 불필요한 플랫폼 종속을 피하기 위해 반드시 커스텀 도메인을 구축해야 한다고 조언합니다.