Iain Cambridge는 자신의 블로그를 통해 Go 코드의 패키지 경로를 GitHub와 같은 특정 호스팅 서비스에 직접 연결하는 관행이 장기적으로 유지보수 비용을 증가시킨다고 지적했다. Go 언어는 패키지를 가져올 때 해당 코드가 위치한 URL을 그대로 import 문에 사용한다. 예를 들어 github.com/user/project 형식으로 적으면 Go 컴파일러가 그 주소에서 소스를 내려받는다.
이 방식은 오픈소스 라이브러리의 버그 리포팅이나 배포를 단순화한다는 장점이 있지만, 내부 프로젝트에는 치명적인 단점으로 작용할 수 있다. 만약 회사가 GitLab이나 Azure DevOps로 git 호스팅 서비스를 이전하게 되면, 모든 소스 코드의 import 경로를 일일이 수정해야 한다. 이는 상당한 공수를 요구하며 실수로 인해 구버전 코드를 참조할 위험도 있다.
실제로 한 기업은 이러한 마이그레이션 부담 때문에 세 개의 서로 다른 git 호스팅 플랫폼을 동시에 운영한 사례가 보고되었다. 코드 위치 변경 작업이 너무 복잡해지자 차라리 중복된 인프라 비용을 감수하고 여러 플랫폼을 병행하는 편이 낫다고 판단한 것이다. 이는 결과적으로 불필요한 지출을 발생시키는 원인이 되었다.
Cambridge는 이 문제를 피하기 위해 go.iain.rocks나 go.uber.org처럼 자체 도메인을 네임스페이스로 사용하는 것을 추천했다. 자체 도메인을 사용하면 실제 코드가 저장된 물리적 위치와 상관없이 논리적인 주소만 유지할 수 있다. 호스팅 서비스가 바뀌더라도 DNS 설정이나 서버 리다이렉트 규칙만 조정하면 되므로 소스 코드 수정이 필요 없다.
Hacker News의 토론에서는 이 접근법에 대한 다양한 의견이 오갔다. 일부 개발자는 go.mod 파일의 replace 지시어를 활용해 GitHub 주소를 다른 플랫폼으로 매핑하는 대안을 제시하기도 했다. 하지만 영구 리다이렉트를 사용할 경우 브라우저나 CLI 도구의 캐싱 문제로 인해 의도치 않게 이전 서비스로 접속될 수 있다는 우려도 제기되었다.
또한 VeriSign과 같은 도메인 관리 기관이 일방적으로 도메인을 삭제할 수 있는 리스크도 언급되었다. Neil Fraser의 블로그 글에서 인용된 바와 같이, 외부 요인으로 인해 도메인 자체가 사라지면 결국 처음부터 다시 시작해야 하는 상황이 올 수 있다. 따라서 도메인 선택 시 신뢰성과 안정성을 고려해야 한다.
Go 커뮤니티에서는 여전히 기본 제공되는 호스팅 URL을 사용하는 것이 관례처럼 여겨지고 있다. 하지만 대규모 상용 소프트웨어 팀이라면 초기 단계에서 자체 도메인을 도입하여 향후 발생할 수 있는 플랫폼 종속성 문제를 미리 차단하는 것이 합리적이다. 이는 단순한 기술적 취향을 넘어 조직의 유연성을 확보하기 위한 실무적 결정으로 볼 수 있다.
작성자 소개
