Go 코드를 GitHub에 결합하지 말자

상용 Go 개발팀이라면 내부 라이브러리와 패키지의 이름 공간에 자체 도메인을 써야 한다는 권고에서 Go라는 한정은 빼도 됨. 다른 기술 스택에도 똑같이 적용된다고 봄.
코드 주석에 넣은 GitHub 링크조차 장기적으로는 골칫거리가 됨. 호스팅을 이전하면 링크가 더 이상 유효하지 않을 수 있음.

이 글이 Go를 특정한 건 패키지 시스템의 작동 방식 때문이라고 봄.

다른 언어에서는 이런 실수를 하기가 이만큼 쉽지는 않음. Go는 폴더 기반 모듈 시스템 때문에 코드가 수백 줄만 되어도 파일을 여러 폴더로 나누게 되는 경우가 흔함.
그때 도구가 유도하는 가장 간단한 방식을 따르면 소스 코드에 GitHub URL이나 다른 Git 호스팅 사이트의 URL을 넣게 됨.

글과 이 댓글에서 URL 교체를 어렵게 취급하는 이유를 모르겠음. 그냥 검색·치환하면 안 되나?
대상은 대부분 GitHub.com을 가리킬 테고 다른 코드에 그 문자열이 들어갈 일도 드물어서, 오히려 아주 쉬운 사례로 보임. 주석은 이전하는 몇 시간 동안 낡은 링크가 남아 있어도 무언가 고장 나는 건 아니니 더 간단함.

GitLab으로 옮길 때도 go.mod에 replace github.com/example/example => gitlab.com/example/example 만 넣으면 계속 작동함. 별로 중요하지 않은 일에 대한 너무 이른 최적화로 보임.

저장소에 github.com을 넣는 건 실수라고 생각하지만, 심각성이 너무 과장된 듯함. 코드를 일괄 수정하거나 go.mod 로 처리하면 간단하고, 일단 go.mod로 대응한 뒤 코드를 고쳐도 됨.

그 코드를 사용하는 다른 개발자들은 어떻게 하나? 모두에게 코드도 수정하라고 요청할 건가?
상당수는 이전 사실을 모른 채 버그나 보안 문제조차 수정되지 않는 옛 버전에 머물게 될 수 있음.

도메인 설정이 번거롭다면 처음부터 replace 를 쓰면 안 되나?
처음에는 replace example => github.com/example/example로 설정하고, 이전할 때 replace example => gitlab.com/example/example 등으로 바꾸는 방식임. Go를 쓰지는 않지만 이게 가능하길 바라며, 불가능하다면 의아할 것 같음.

그러면 코드에 폐기한 인프라를 가리키는 참조를 영원히 남겨둘 건가?

도메인 등록과 유지를 보장할 수 있는 기업이나 개인이라면 아주 합리적인 방법임. GitHub가 사라지는 건 재앙이겠지만, 그런 일이 절대 없으리라는 보장도 없고 정책 변경 때문에 떠나야 할 수도 있음. Go에서는 GitHub에 묶인 패키지 이름을 코드에 넣는 일이 단순히 코드를 어디서 가져오느냐보다 훨씬 큰 의미를 가짐.
다만 예제 Nginx 설정의 301 리다이렉트는 걱정됨. 나중에 목적지 URL을 바꿔도 Chrome이나 Firefox는 기존 301을 영구적으로 캐시해서 예전 목적지로 보낼 수 있음. go ...나 curl에는 상관없지만 브라우저에서는 의도한 리다이렉트가 깨질 수 있으며, 실제로 얼마나 문제가 되는지는 모르겠음.

GitHub의 수명보다 자체 도메인 유지가 더 불확실함. 도메인은 비용 납부를 중단하면 사라지며, 오픈소스 개발자라면 GitHub가 사라지는 것보다 그럴 가능성이 더 큼.
언젠가는 모두 의존성 코드를 프로젝트에 직접 포함하는 벤더링으로 돌아갈 것 같음.

애초에 의존성 벤더링은 왜 그만둔 건가?

일반적인 소프트웨어 기업이라면 도메인이 사라질 정도일 때는 이미 그 코드에도 관심이 없을 가능성이 큼.

URL을 쓰는 것 자체가 잘못된 선택으로 보임. 이런 용도에는 URN이나 다른 형태의 URI가 딱 맞음.
DNS를 기반으로 이름을 해석하는 URN도 가능하겠지만, 그러면 URL과 크게 다르지 않음. 여러 해석 수단과 서명을 지원하는 더 추상적인 방식이 나아 보임.

아주 드물게 일어나는 호스팅 이전 뒤에 sed s///g를 실행하는 일이 왜 심각한 문제인지 모르겠음.
해결책 자체가 간단하니 좋은 권고이기는 하지만, 문제의 심각성에는 동의하기 어려움.

코드의 가져오기 위치를 이름 공간으로 쓰는 게 Go의 좋은 기능이라고 시작해 놓고, 나머지 글에서는 왜 실전에서 좋은 기능이 아닌지 설명하고 있음.
못 쓸 방식이라고 보지는 않음. 다만 Go가 다른 언어와 다르게 설계한 뒤, 팬들에게는 훌륭한 아이디어이고 다른 언어들이 잘못했다고 납득시킨 요소 중 하나임.
몇 가지 난관이 드러난 뒤에도 공식 패키지 이름의 장점을 인정하기보다는, GitHub에 올린 패키지를 위해 모두 자체 도메인과 Nginx 서버나 Go Vanity URLs 전달 서비스를 운영하라고 하고 있음.

이러면 도메인 관리라는 의존성이 새로 생기지 않나? 장점은 이해하지만, 개인 오픈소스 개발자에게 인프라 관리 계층을 추가하는 셈임. 장단점을 따져 선택할 일임.

Go를 쓰기 전에 의존할 패키지를 조사했는데 전부 GitHub에 호스팅되어 있다면, Go를 피할 이유가 될 듯함. 적어도 필요한 패키지를 로컬에 캐시해서 CI가 언제나 빌드에 쓸 코드를 확보하도록 계획해야겠음.
아니면 관리자가 선택한 Git 호스팅 서비스에 의존하지 않는 자동 미러를 직접 구축해서, 대체 공급 경로를 확보할 수는 없을까? https://news.ycombinator.com/item?id=49434625