https://www.popit.kr/고-모듈을-사용하여-패키지-구성-방법-개선하기/
회사에서 API 서버를 주로 고 언어로 개발하고 있습니다. 사용해본지 2년 정도 지났는데 간단한 API 서버를 만드는 데에 큰 불편함은 없습니다. 한가지 아쉬운 점이라면 외부 패키지를 사용할 때 발생할 수 있는 몇 가지 문제들이 있다는 점입니다.
외부 패키지 버전 일관성 문제 빌드 서버에서 매 빌드마다 외부 패키지들을 새로 다운로드 받을 경우 로컬에서 개발을 할 때 사용하던 외부 패키지들과 빌드 서버에서 빌드를 할 때 사용하는 외부 패키지들의 버전이 불일치 할 수 있습니다. 결국 빌드가 실패하거나 배포가 되더라도 API 기능에 예상치 못한 문제가 발생할 수 있습니다.
외부 패키지 다운로드 불가 문제 네트워크 사정에 따라 외부 패키지를 다운로드 받지 못하는 경우가 생길 수 있습니다.
[1]
그러던 중 고 언어 1.11 버전에서 고 모듈이 옵션 기능으로 등장하였고 1.13 버전에서 보다 본격적으로 지원하게 되었습니다. 고 모듈을 사용하면 위 두 가지 문제를 간단하게 해결할 수 있습니다.
이번 글에서는 고 모듈 이전 이러한 문제들을 어떻게 해결했는지 먼저 살펴보고 고 모듈을 사용하여 보다 쉽게 해결하는 방법을 소개하겠습니다.
vendor 디렉토리에 특정 버전의 외부 패키지들을 저장 시킨 뒤 빌드에 참여시킴으로써 버전 일관성 문제를 해결 할 수 있습니다. 기본적으로 다운로드 불가한 외부 패키지를 어떻게든 한번만 구할 수만 있다면 다운로드 불가 문제도 회피 가능합니다.
도커 이미지 상 GOPATH에 해당되는 경로에 미리 외부 패키지들을 저장시키면 벤더링 효과를 보면서 외부 패키지들의 버전을 도커 이미지 한 곳에서 관리할 수 있습니다.
하지만 두 방법 모두 궁극적으로 다운로드 불가 문제를 해결한 것은 아니라는 점과 패키지 구성에 다소 손이 많이 간다는 점이 아쉬웠습니다. 특히 도커 이미지를 활용하는 방법의 경우 로컬 개발 때 사용하는 외부 패키지들과 도커 이미지에 들어있는 외부 패키지들의 버전이 다르다면 버전 일관성 문제는 여전히 발생할 수 있습니다.
이 글에서는 고 언어 1.13 버전을 기준으로 설명합니다.
공식 사이트에서 모듈을 다음과 같이 정의하고 있습니다.
A module is a collection of Go packages stored in a file tree with a go.mod file at its root.
간단히 말해 모듈은 go.mod 파일과 하위 패키지들을 포함하는 디렉토리라 볼 수 있습니다. 최상위 디렉토리에 go.mod 파일을 만들면 모듈이 됩니다.
모듈은 go.mod 파일이 없는 패키지와도 호환됩니다. 앞으로 지칭되는 '모듈'은 '패키지'도 내포합니다.