아티팩트 저장소로 사용

저장소 소개

이번 장에 들어가기 앞서 몇 가지 용어를 정리해 보자.

아티팩트(artifact)

아티팩트는 소프트웨어 개발 프로젝트를 진행하면서 생성하는 다양한 산출물을 의미한다. 각종 설계 문서, 유즈 케이스, UML 다이어그램, 소스 코드, 소스를 빌드하여 생성된 라이브러리나 실행 파일도 모두 아티팩트에 속한다.

자바 프로젝트를 빌드할 때 많이 사용되는 메이븐(maven) 에서는 빌드로 생성되는 프로젝트의 결과물을 의미하며 아티팩트는 자바 프로젝트의 성격에 따라 다르지만 일반적으로는 .jar, .war, .ear 등의 확장자를 갖게 된다.

.jar 확장자를 갖는 자바 라이브러리는 아티팩트의 일종이므로 이번 장에서 라이브러리라고 할 경우 아티팩트와 동일한 의미로 이해하면 된다.

아티팩트 저장소(Artifact Repository)

아티팩트 저장소는 아티팩트와 메타 데이타를 저장하고 관리하는 장소를 의미한다.

spring 프레임워크이나 JDBC 구현물, 아파치 재단 산하의 오픈소스 프로젝트등 외부에서 개발된 라이브러리를 저장하기도 하지만 내부에서 개발되었거나 또는 개발하고 있는 라이브러리를 다른 개발자나 프로젝트와 공유하기 위한 배포 용도로도 사용한다.

서브버전이나 git 등의 버전 관리 시스템은 소스의 이력 및 공유 용도로 사용하지만 저장소는 아티팩트를 공유하기 위한 용도로 사용되는게 다른 점이다.

아티팩트 저장소(artifact repository) 는 간단하게 저장소라고 하며 이번 장에서 의미하는 저장소는 아티팩트 저장소이다.

저장소의 필요성

저장소가 없던 시절의 프로젝트를 생각해 보자. 프로젝트 빌드는 ant 를 사용하였고 ant 는 저장소 관련 기능이 없으므로 프로젝트에 필요한 라이브러리는 CVS나 서브버전에 라이브러리용 폴더(예: lib)를 만들고 커밋하여 관리를 했다.

일반적인 프로젝트의 디렉터리 구조는 다음과 같이 소스와 라이브러리를 모두 저장했다.

src
	com
	org
lib
	log4j.jar
	mylib.jar
build.xml

내부에서 만든 라이브러리가 추가/변경될 경우 버전 관리에 커밋하고 개발 단계일 경우 email 이나 파일 공유 서버를 통해 전달받아 테스트를 진행하였다.

이런 방식을 사용할 경우 다음과 같은 문제점들이 발생했다.

많은 용량 차지 - 아파치 재단의 라이브러리나 스프링 프레임워크등 공통적으로 사용되는 라이브러리들이 많이 있어도 프로젝트마다 버전 관리에 추가하여 사용하여 많은 용량이 필요하다.
특히 프로젝트 소스를 분기할 경우 라이브러리를 복사해야 하므로 분기 속도도 느려 진다.
느린 빌드 - 버전 관리 용량이 크다보니 빌드를 위해 체크 아웃 받을 경우 시간이 더 걸리고 빌드도 느려지게 된다.
프로젝트 라이브러리 버전 관리 어려움 - 사용하던 라이브러리를 다른 버전으로 변경한다고 가정해 보자. 새로운 라이브러리를 구한 후에 버전 관리에 커밋해야 한다.
만약 새로운 라이브러리가 문제가 있어서 예전 버전으로 돌아가야 할 경우 버전 관리에서 삭제하고 커밋을 거쳐야 하는등 프로젝트에서 사용하는 라이브러리의 버전 관리가 어렵다.
의존성 관리가 어려움 - 사용하는 라이브러리가 다른 라이브러리를 참고할 경우 개발자가 의존성을 알아서 파악해서 의존성 있는 라이브러리를 추가해 주어야 한다.
특히 버전이 갱신되어 의존성이 변경되거나 신규로 추가된 라이브러리일 경우 의존성 관리는 매우 번거로운 작업이다.

저장소는 위와 같은 문제점을 해결하기 위해 사용하며 다음과 같은 장점이 있다.

적은 용량 사용 - 저장소는 라이브러리를 보관하므로 프로젝트마다 필요한 라이브러리를 버전 관리에 추가할 필요가 없고 라이브러리에 대한 메타 데이타만 설정하면 빌드할 때 다운로드 받으므로 적은 용량을 사용한다.
빠른 프로젝트 체크아웃과 빌드 - 버전 관리 툴을 사용하여 프로젝트를 체크 아웃 받을 경우 용량이 적으므로 빨리 체크아웃 받을 수 있으며 빌드도 빨리 수행 가능하다.
라이브러리 버전 관리 용이 - 메타 데이타를 기반으로 라이브러리의 정보와 버전을 관리하므로 라이브러리 자체의 버전을 관리하기가 용이하다.
공유 및 협업 강화 - 저장소를 통해 컴포넌트를 공유할수 있으므로 개발자들끼리 손쉽게 산출물을 공유하고 협업할 수 있다.

저장소를 제대로 사용하기 위해서는 저장소를 지원하는 빌드 툴을 사용해야 한다.

메이븐(maven)이나 아이비(ivy) 등의 빌드 툴은 메타 데이타를 기반으로 저장소에서 라이브러리를 검색하고 다운로드 받는다.

저장소의 주소가 명시되지 않을 경우 메이븐 중앙 저장소에 연결하게 되며 이 저장소는 외국에 위치하고 있어서 속도가 느리므로 저장소를 사용해도 빌드가 느린 원인이 된다.

또 JDBC나 기타 라이브러리는 메이븐 중앙 저장소와 별도의 저장소를 제공하는 경우가 있으므로 따로 저장소를 지정하지 않으면 빌드가 실패하는 원인이 되기도 한다.

저장소 구조

저장소에 추가된 아티팩트는 디렉터리나 자바의 패키지처럼 계층적인 구조로 접근할 수 있다. 이 계층적 구조를 GAV(Group, Artifact, Version) 구조라고 하며 메이븐에서 의존성을 찾을 때 참고하는 구조이기도 하다.

Group Identifier(groupId)

그룹 ID는 아티팩트를 논리적인 그룹으로 묶기 위한 단위이다. 보통 개발하는 회사나 기관명뒤에 만드는 소프트웨어 컴포넌트명을 붙여서 짓는다. 예로 아파치 재단 산하의 메이븐 프로젝트의 그룹 ID 는 org.apache.maven 이다.

Artifact Identifier(artifactId)

아티팩트 ID 는 프로젝트의 결과물인 어플리케이션이나 라이브러리의 이름을 위미한다. 만약 개발하고 있는 프로젝트가 "example webapp" 라면 아티팩트 ID는 example-webapp 로 짓는다. 그룹 ID와 아티팩트 ID 를 합친 문자열은 유일한 식별자이어야 하며 다른 프로젝트일 경우 아티팩트 ID 를 달리해야 한다.

Version(version)

버전은 아티팩트의 버전이며 일반적으로 메이저, 마이너, 포인트로 나눠서 짓는다. example-webapp 의 메이저 버전이 1 이고 마이너가 2, 포인트 버전이 4일 경우 최종 버전은 1.2.4 가 된다. 버전에는 구분을 용이하게 하기 위해 문자열을 사용할 수 있다. 다음과 같은 버전도 유효한 버전명이다.

1.2.4-BETA3

2.0.0-RC5

Packaging(packaging)

메이븐을 빌드 도구로 사용할 경우 기본 패키지 형식은 JAR 파일이지만 저장소에 아티팩트 등록시 명시적으로 패키지 형식을 알려주어야 한다. 사용 가능한 패키지 형식은 JAR, ZIP, WAR, WAR, SWC 등이다.

릴리스와 스냅샷 저장소(Release and Snapshot Repositories)

프로젝트에서 공통으로 사용되는 라이브러리를 개발하는 별도의 프로젝트가 있다고 가정해 보자.

개발 단계의 라이브러리는 수시로 변경되며 자주 테스트 되어야 하지만 안정화 될 때까지는 이 라이브러리를 참조하는 프로젝트에서는 사용하지 않는게 좋을 경우가 많다.

이를 위해 안정 버전의 라이브러리와 개발 단계 라이브러리를 구분하여 저장소를 나누어 관리하면 유용할 것이다.

이를 위해 개발 단계에서는 스냅샷 저장소를 통해 배포하고 테스트가 끝나고 안정화된 라이브러리는 릴리스 저장소에 저장하여 배포한다.

보통 스냅샷 아티팩트는 구분을 위해 my-artifact-1.2.3-20140506.162341-1.jar 처럼 타입스탬프가 파일명에 추가된다.

저장소 관리자(Repository Manager)

저장소 관리자는 저장소의 기능 및 관리자 기능을 제공하는 소프트웨어를 의미하며 아티팩트를 저장/관리하고 컴포넌트의 생명주기를 관리하기 위한 용도로 사용된다.

주요 제품으로는 아파치 재단의 아카이바(archiva), JFrog 사의 아티팩토리(Artifactory), 소나타입사의 넥서스(nexus) 가 있다.

이 책에서는 가장 많이 사용하는 넥서스 저장소 관리자에 대해서 다룰 것이다.