Go 코드를 GitHub에 묶지 말고 커스텀 도메인으로 네임스페이스하라

도메인 관리 부담이 새로 생기는 건 아닌가. 오픈소스 개발자 개인에게 인프라 관리 계층을 하나 더 떠넘기는 셈인데, 장단점 저울질해서 고르면 되는 거지.

GitHub는 거의 영원함. 커스텀 도메인은 청구서를 안 내면 사라지는데, 오픈소스 개발자일수록 그럴 확률이 GitHub가 망할 확률보다 높음. 언젠가 다들 vendoring으로 돌아갈 거임.

go mod vendor 쓰면 됨. 표준 라이브러리가 강하고 하위 호환을 지키는 Go 생태계엔 그게 맞음. proxy.golang.org도 있음.

Hugo 템플릿으로 vanity import path 만드는 방법도 있음. 이걸 GitHub에 올린 아이러니는 알지만, 자체 도메인 의존은 감수하기로 했음.

"go"를 빼야 한다고 봄. 다른 스택도 똑같음. 코드 주석에 박은 GitHub 링크도 나중에 마이그레이션하면 아무 데도 안 가리키게 됨.

왜 검색과 치환으로 안 되나? 전부 github.com을 가리킬 텐데, 마이그레이션 중 몇 시간 낡아도 아무것도 안 깨짐.

근데 다른 언어는 이런 실수를 하기 쉽지 않음. Go는 폴더 기반 모듈이라 몇백 줄만 넘어도 도구가 GitHub URL을 소스에 박으라고 유도함.

회사가 contoso.com에서 xtools.cn으로 도메인을 옮기면 VPN 밖에서는 해석도 안 되는데, 다른 팀들이 /etc/hosts와 .gitconfig 만지작거리며 마이그레이션을 질질 끄는 게 진짜 문제임.

URL을 쓰는 게 애초에 오류 같음. DNS를 백엔드로 쓰는 URN이나, 여러 리졸버와 서명을 가진 더 추상적인 식별자가 낫지 않나.

그 대안은 결국 콘텐츠 주소 지정 방식뿐임. 가변 레지스트리 조회에 의존하는 URN은 사실 URL임.

설득이 안 됨. 사라지지 않게 그냥 GitHub에 두는 게 낫지 않나. 우선순위가 바뀌는 회사라면 특히.

사람들은 GitHub에서 프로젝트를 지울 수 있음. 우선순위가 바뀐 회사는 지원 문의를 받기 싫어서, 또는 방치한 프로젝트의 보안 취약점을 책임지기 싫어서 그냥 내림. 어디에 있든 내일도 있을 거라 가정하지 말고 항상 의존성을 vendor 해야 함.

replace github.com/example/example => gitlab.com/example/example 를 go.mod에 쓰면 그대로 작동함. 별로 중요하지 않은 일에 대한 성급한 최적화임.

그러면 버려진 인프라 참조를 코드에 영원히 남기나? 그리고 이 코드를 쓰는 다른 사람들은 다 고치라고 하나? 모르고 있다가 보안 수정도 못 받고 옛 버전에 갇힘.

아티팩트 레지스트리를 가리키게 하는 게 더 나은 이유임. 컨테이너만 돌아가면 어디든 설치해서 프록시 모드로 시작하고, 나중에 버전 고정이나 체크섬 검증, SSO를 붙이면 됨. 시작 단계에 SBOM 같은 건 필요 없음.

Go를 안 써봐서 묻는데, 단순 검색과 치환으로 안 되는 이유가 뭔가? 코딩 에이전트가 빠르게 처리해 주지 않나?

완전 정규화된 도메인을 쓰면 안 되고 상대 경로를 쓰면 됨. 형제 저장소에 둔 git 서브모듈처럼.

Go는 상대 경로 import를 허용하지 않음.

braid가 외부 의존성 관리에 좋았음. 서브모듈보다 훨씬 깔끔함.

좋은 해결책임. 우리가 간 대안은 그냥 전부 직접 빌드해서 쓰는 거였음.