Go 코드에 박힌 GitHub 주소, 저장소를 옮길 때도 따라올까요?

핵심 요약

• Go의 모듈 경로는 소스를 찾는 단서이자 의존성을 구분하는 이름입니다.
• GitHub 저장소를 옮기는 일과 코드에 쓰인 모듈 경로를 바꾸는 일은 서로 다릅니다.
• 자체 도메인을 쓰면 저장소 위치와 공개된 모듈 이름을 분리할 수 있습니다.
• 자체 도메인도 계속 관리해야 하므로 라이브러리를 얼마나 오래, 어디까지 쓸지 함께 따져야 합니다.

라이브러리를 처음 공개할 때는 GitHub 주소를 그대로 쓰는 편이 간단합니다. 그런데 조직 이름을 바꾸거나 저장소를 다른 서비스로 옮기려면, 다른 사람의 코드에 들어간 주소까지 신경 써야 합니다. Go에서 패키지 주소를 정할 때는 나중에 경로를 바꾸는 비용을 누가 부담할지도 생각해야 합니다.

1. 주소처럼 생겼지만, 의존성의 이름입니다

Go의 모듈은 여러 패키지를 묶어 버전별로 관리하는 단위입니다. 모듈 경로는 go.mod 파일의 module 선언에 적습니다.

가령 모듈 경로가 github.com/example/kit이라면, 그 안의 parser 패키지는 보통 다음처럼 가져옵니다.

import "github.com/example/kit/parser"

이 문자열을 보면 저장소가 어디 있는지 짐작할 수 있습니다. Go는 이 문자열로 패키지도 구분합니다. 그래서 웹페이지의 링크처럼 연결할 곳만 바꾸면 끝나는 주소는 아닙니다.

처음에는 이 방식이 편합니다. 별도 도메인을 준비하지 않아도 되고, 코드를 읽는 사람도 저장소 위치를 쉽게 짐작할 수 있습니다.

대신 GitHub라는 호스팅 서비스와 계정 이름이 공개된 모듈 이름에 들어갑니다. 함수 이름을 정할 때 오래 쓸 수 있을지 고민하듯, 이 경로도 계속 유지할 수 있는 이름인지 따져 봐야 합니다.

2. 저장소 이사와 모듈 이름 변경은 다릅니다

코드에 GitHub 주소가 있다고 해서 빌드할 때마다 반드시 GitHub에 직접 접속하지는 않습니다. Go는 설정과 캐시 상태에 따라 모듈 프록시나 로컬 캐시에서 의존성을 가져올 수 있습니다.

그러니 여기서 말하는 종속은 어느 서버에서 다운로드하느냐에만 달린 문제가 아닙니다. 다운로드 방식이 달라져도 이름에 대한 종속은 더 오래 남습니다.

저장소를 옮겨도 기존 경로로 소스를 계속 찾을 수 있다면 이용자가 당장 import를 바꿀 필요는 없을 수 있습니다. 다만 여전히 예전 주소와 그 주소를 처리하는 서비스에 의존합니다. 저장소 페이지에서 새 위치로 연결해 준다고 해서 모듈 이름까지 바뀌지는 않습니다.

반대로 모듈 경로 자체를 새 주소로 바꾸면 이용자도 코드와 의존성 선언을 고쳐야 합니다. 기존 경로와 새 경로가 의존성 관계 안에 함께 남으면, 같은 소스에서 출발한 패키지라도 Go가 서로 다른 패키지로 구분할 수 있습니다. 공개한 타입을 주고받는 코드에서는 이 차이 때문에 문제가 생기기도 합니다.

앱 개발자는 replace 지시문을 써서 특정 의존성을 다른 소스에서 가져오도록 우회할 수 있습니다. 다만 라이브러리 작성자가 자신의 go.mod에 적은 replace가 그 라이브러리를 쓰는 모든 프로젝트에 적용되지는 않습니다. 개별 프로젝트에서 문제를 해결하는 일과 생태계 전체에서 경로를 바꾸는 일은 규모가 다릅니다.

3. 자체 도메인은 이름과 보관 장소를 분리합니다

자체 도메인을 경로에 쓰면 이런 문제를 줄일 수 있습니다. 흔히 vanity import path라고 부릅니다. 패키지에 자신이 직접 관리하는 주소를 붙이는 방식입니다.

앞선 예시를 다음과 같이 공개할 수 있습니다.

import "go.example.com/kit/parser"

이 도메인에서 Go 도구가 읽을 수 있는 저장소 안내 정보를 제공하고, 실제 코드는 GitHub에 둘 수 있습니다. 이렇게 하면 이용자에게 공개한 이름과 소스를 보관하는 장소가 분리됩니다.

나중에 저장소를 옮겨도 도메인 쪽 안내를 바꾸면 공개 경로를 그대로 쓸 수 있습니다. 물론 옮긴 저장소의 모듈 선언도 기존 경로와 맞아야 합니다. 이용자가 의존성을 안정적으로 가져오려면 이전 버전과 해당 소스도 계속 제공해야 합니다.

이때 달라지는 것은 이름을 관리할 권한입니다. 호스팅 서비스를 바꾸더라도 운영자가 자신의 도메인 아래에서 이전을 처리할 수 있다면, 이용자는 코드를 수정할 필요가 없습니다.

이미 널리 쓰이는 GitHub 경로를 자체 도메인으로 바꾸려면 여전히 전환 비용이 듭니다. 처음 공개할 때부터 자체 도메인을 선택해야 이 이점을 누리기 쉽습니다.

4. 주소를 소유하면 유지 책임도 생깁니다

자체 도메인에도 비용과 수고가 듭니다. 도메인을 갱신하고 DNS와 저장소 안내 서비스를 관리해야 합니다. HTTPS로 제공한다면 인증서도 관리해야 합니다.

도메인 갱신을 놓치거나 안내 서비스가 멈추면 새로 의존성을 받는 환경에 문제가 생길 수 있습니다. 프록시나 캐시에 남은 사본 덕분에 일부 상황에서는 문제가 없을 수도 있지만, 그렇다고 도메인 관리를 소홀히 할 수는 없습니다.

어느 쪽을 택할지는 프로젝트 사정에 따라 달라집니다.

• 작은 실험용 도구라면 GitHub 경로를 간편하게 쓰는 편이 나을 수 있습니다.
• 여러 팀이나 외부 제품이 오래 쓸 라이브러리라면 경로를 직접 관리할 가치가 커집니다.
• 자체 도메인을 쓴다면 최초 작성자가 떠난 뒤에도 누가 갱신하고 운영할지 정해 두어야 합니다.

제 생각에는 이용자가 늘수록 저장소를 옮기는 작업보다 각 프로젝트의 코드를 고치는 비용이 더 부담스러워집니다. 주소를 정할 때도 저장소 하나를 옮기는 수고에 그치지 않고, 그 주소를 가져다 쓸 프로젝트들이 감당할 일까지 생각해야 합니다.

Go 코드에 GitHub 주소를 쓰면 편하게 시작할 수 있습니다. 하지만 이용자가 생긴 뒤에는 그 주소도 오래 유지해야 할 이름이 됩니다. 다음 라이브러리의 경로를 정할 때는 저장소 위치가 바뀌어도 다른 사람의 코드에 적힌 이름을 그대로 유지할 수 있을지 함께 따져 보려 합니다.