Vendor
요즘은 대부분 모듈 기반으로 의존성을 관리하기 때문에 잘 보이지 않지만, 만들어진지 오래된 모듈이거나 혹은 비즈니스 환경의 Go 언어 프로젝트는 소스 코드 디렉토리 내에서 vendor 라는 이름의 디렉토리가 존재하는 것을 볼 수도 있습니다.
Vendor 는 도대체 무엇이고 왜 존재했던 걸까요?
Vendor 디렉토리의 역사와 변화
Vendor에 대해서 이해하려면 Go의 의존성 관리 방법이 시간이 지남에 따라 어떻게 발전 했는지를 알아야 합니다.
GOPATH 시대 (Go 1.5 이전)
초기 Go는 GOPATH에 모든 의존성 패키지를 저장하는 단순한 방식을 사용했습니다.
이 방법은 프로젝트 규모가 작거나 한 두가지 프로젝트를 진행할 땐 문제가 되지 않았으나, 점점 규모가 커지고 하는 일이 많아질수록 서로 다른 프로젝트의 의존성 패키지가 서로 충돌하는 문제가 빈번하게 발생했습니다.
이 때문에 모듈 버전 관리가 어렵고 프로젝트별로 의존성을 관리 하는 것이 불가능했습니다.
Vendor 도입 (Go 1.5)
Vendor는 프로젝트의 의존성 패키지들을 프로젝트 내부의 vendor 디렉토리에 직접 복사하여 저장하는 방식입니다.
이를 통해 각 프로젝트는 자신만의 독립된 의존성을 가질 수 있게 되었습니다.
Vendor 도입 이력
•
Go 1.5에서 vendor 디렉토리가 실험적 기능으로 도입되었습니다.
•
Go 1.6부터 vendor가 기본적으로 활성화되었습니다.
•
이 시기에는 dep, glide 등의 외부 의존성 관리 도구들이 널리 사용되었습니다.
Go 모듈의 등장 (Go 1.11)
Go 1.11에서 모듈이 도입되면서 의존성 관리 방식이 크게 변화했습니다. (모듈에 대한 설명은 이전 강의를 참고해주세요.)
•
Go 1.11~1.12
◦
모듈이 실험적 기능으로 도입
•
Go 1.13
◦
모듈이 기본 기능으로 채택
•
Go 1.16~지금
◦
모듈 모드가 기본값이 되었습니다.
현재 상황 (Go 1.21+)
현재는 Go 모듈이 표준 의존성 관리 방식이지만, vendor 디렉토리도 여전히 지원됩니다.
•
대부분의 새로운 프로젝트는 Go 모듈을 사용합니다.
•
vendor는 특수한 상황(예: 폐쇄망 환경)에서 여전히 유용하게 사용됩니다.
•
일부 레거시 프로젝트에서는 여전히 vendor를 사용하고 있습니다.
Vendor 디렉토리
Go 모듈에서는 vendor 디렉토리를 통해 프로젝트의 의존성을 로컬에서 관리할 수 있습니다. vendor 디렉토리는 프로젝트에서 사용하는 모든 외부 패키지의 복사본을 저장하는 공간입니다.
Vendor 디렉토리 생성
# vendor 디렉토리 생성 및 의존성 복사
go mod vendor
Bash
복사
Vendor 특징
•
프로젝트의 의존성을 로컬에서 완벽하게 제어할 수 있습니다.
•
외부 저장소의 가용성에 영향을 받지 않고 빌드할 수 있습니다.
•
의존성 패키지의 버전을 명확하게 고정할 수 있습니다.
잘 와닿지 않나요?
예를 들어, github 에 존재했던 의존성 패키지가 사라져서 소스 코드를 빌드할 수 없게 된다면 얼마나 끔찍할 지 상상해보세요.
Vendor 사용하기
vendor 디렉토리를 사용하여 빌드하려면 -mod=vendor 플래그를 사용합니다:
# vendor 디렉토리를 사용하여 빌드
go build -mod=vendor
Bash
복사
결론
현재는 Go 모듈이 표준 의존성 관리 방식이지만, vendor는 폐쇄망 환경이나 레거시 프로젝트에서 여전히 유용하게 사용되고 있습니다.
특히 외부 저장소의 가용성에 영향을 받지 않고 안정적인 빌드가 필요한 상황에서 큰 장점을 가집니다.
따라서 여러분들도 안정적인 빌드가 필요한 상황에서 vendor를 사용하여 의존성 패키지를 관리해보세요.
강의 목록
