Go 언어의 특징 중 하나는 코드를 가져올 위치가 곧 코드의 네임스페이스가 된다는 점이다. 예를 들어 코드를 github.com/thetrueares/boneclone에 두면 그대로 그 문자열을 임포트 경로로 쓰고, Go 도구는 git을 통해 해당 위치에서 코드를 내려받는다. 중앙집중식 패키지 저장소 없이도 라이브러리를 배포하고 가져올 수 있고, 버그를 어디에 신고해야 하는지도 경로만 보면 알 수 있다. 편리하지만 대다수 개발자에게 이 경로는 사실상 git 호스팅 주소 그 자체가 되어 버린다. 원문 저자 Iain Cambridge는 바로 이 지점에서 문제가 생긴다고 지적한다.
호스팅 업체에 코드가 묶이는 구조
임포트 경로가 호스팅 주소와 같다는 것은, 코드가 특정 호스팅 제공자에 결합(coupling)된다는 뜻이다. GitHub에서 GitLab으로 옮기면 임포트 경로 자체를 바꿔야 하고, 그러지 않으면 사용자는 계속 옛 위치에서 옛 버전을 받게 된다. 언뜻 사소해 보이지만, 라이브러리가 널리 쓰일수록 경로 변경은 이를 참조하는 모든 코드베이스에 파급된다. 그래서 이전 비용이 눈덩이처럼 불어나고, 결국 호스팅 업체를 바꾸고 싶어도 바꾸지 못하는 잠금(lock-in) 상태에 빠진다. 코드가 GitHub에 종속된다는 표현이 과장처럼 들리지만, 저자는 이것이 Go 커뮤니티의 사실상 기본값이 되어 있다고 말한다.
저자가 든 사례는 이 결합이 실제 비용으로 이어진 경우다. 어떤 회사는 GitLab, GitHub, Azure DevOps를 동시에 사용하고 있었는데, 코드 위치를 옮기는 작업이 워낙 커서 "그럴 시간이 없다"는 이유로 세 플랫폼을 그대로 병행 운영하는 편을 택했다. 결국 세 곳의 호스팅 비용을 동시에 지불하게 되었다는 것이다. 저자는 여러 git 호스팅 플랫폼에 걸쳐 스켈레톤 코드를 동시에 복제·관리하기 위해 Boneclone이라는 도구를 만들었다고 밝힌다.
해법은 자기 도메인을 한 겹 두는 것
저자가 제시하는 해법은 단순하다. 호스팅 주소 대신 자신이 소유한 커스텀 도메인을 네임스페이스로 쓰는 것이다. go.iain.rocks, go.uber.org, go.mongodb.org 같은 형태가 그 예다. 예컨대 go.iain.rocks/boneclone이 실제로는 github.com/thetrueares/boneclone을 가리키도록 해 두면, 나중에 GitLab으로 옮기더라도 그 도메인이 가리키는 곳만 바꾸면 된다. 최종 사용자 입장에서 설치 명령은 그대로이고, 코드 어디도 손댈 필요가 없다. 결합의 원인이었던 "호스팅 주소 = 임포트 경로" 등식을 도메인이라는 한 단계 간접층으로 끊어 내는 셈이다.
이 방식이 작동하는 배경에는 Go의 이른바 배니티 임포트 경로(vanity import path) 메커니즘이 있다. Go 도구가 임의의 도메인 경로를 만나면 해당 URL에 접근해 응답 문서에 담긴 메타 정보를 읽고, 거기에 명시된 실제 저장소 위치로 리다이렉트해 코드를 가져온다. 즉 도메인은 이름표 역할만 하고 실제 소스는 그 뒤에서 자유롭게 바꿀 수 있다. 원문은 이 설정을 자신의 프로젝트에도 적용할 수 있도록 설정 파일 사본을 함께 공개한다.
실무 관점의 의미와 한계
실무적으로 이 조언의 핵심은 인프라 선택을 코드에서 분리하라는 것이다. 특히 사내 라이브러리와 패키지를 여러 서비스에서 공유하는 상업 개발팀이라면, 도메인 한 겹을 두는 초기 비용이 훗날 호스팅 이전이나 다중 플랫폼 운영에서 발생할 비용에 비하면 미미하다. 저자는 Go를 쓰는 모든 상업 개발팀이 내부 라이브러리 네임스페이싱에 커스텀 도메인을 써야 한다고 단언한다. 조직 표준으로 처음부터 도메인 경로를 강제해 두면, 나중에 수백 곳의 임포트 경로를 일괄 수정하는 고통을 애초에 겪지 않는다.
다만 원문은 개인 블로그의 주장인 만큼 몇 가지를 스스로 판단해 받아들일 필요가 있다. 커스텀 도메인 방식은 그 도메인을 서비스하는 엔드포인트가 하나의 의존 지점이 되므로, 도메인과 리다이렉트 응답을 안정적으로 유지·운영하는 책임이 새로 생긴다. 또한 공개 오픈소스에서는 경로만 보고 곧장 저장소로 이동하기 어려워질 수 있어, 기여자 편의와 유연성 사이의 균형도 고려해야 한다. 그럼에도 "코드를 특정 업체에 불필요하게 묶지 말라"는 원칙 자체는, 호스팅 환경이 수시로 재편되는 요즘 팀들이 새 Go 프로젝트를 시작할 때 한 번쯤 짚고 넘어갈 만한 지점이다.