Page Comparison

...

...

들어가며

패키지 관리자(Package Manager) 란

소프트웨어가 점점 복잡해지고 외부 라이브러리를 사용하는 경우가 많아지면서 외부 라이브러리를 설치하고 관리하는 문제과  의존성 지옥(dependency hell)소프트웨어 저장소(Software Repository) 는 이라는 골치 아픈 문제가 발생했습니다.

먼저 라이브러리의 버전 갱신시 호환성 보장을 위해 버전을 기술하는 표준 명명법인 유의적 버전(Semantic Versioning) 이라는 버전 기술 방법도 제안되었습니다.

그리고 이를 기반으로 언어나 프레임워크의 사용자 커뮤니티에서는 유의적 버전에 기반하여 의존성 있는 라이브러리의 설치/갱신/삭제를 처리하는 패키지 관리자(Package Manager) 가 의존성 있는 패키지를 다운로드할수 있는 공간을 의미하며 일반적으로 온라인으로 서비스를 제공한다.

용어 정리

아티팩트(artifact)또는 의존성 관리자(Dependency Manager) 라고 부르는 전용 프로그램을 만들었고 사용자의 많은 호응을 받아서 지속적으로 발전해 가고 있습니다.

패키지 관리자는 해결하고자 하는 문제는 동일하므로 개념을 이해하면 언어나 프레임워크가 변경되어도 크게 어렵지 않게 적응할 수 있으며 유명한 패키지 관리자는 아래와 같습니다.

artifact, Package, Library, Component

언어나 프레임워크마다 package, library, component 를 비슷한 의미로 사용하는 경우가 많으며 일반적으로는 라이브러리라고 이해하면 됩니다. 

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

자바 프로젝트를 빌드할 때 많이 사용되는 주로 자바 진영에서 사용하는 용어로 라이브러리나 패키지보다 더 큰 개념이라고 볼 수 있으며 자바에서 많이 사용하는 메이븐(maven) 에서는 빌드로 생성되는 프로젝트의 결과물을 의미하며, 아티팩트는 자바 프로젝트의 성격에 따라 다르지만 일반적으로는 .jar, .war, .ear 등의 확장자를 갖게 된다됩니다.

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

아티팩트 저장소(Artifact Repository)

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

...

저장소(Repository) 란?

저장소는 아티팩트와 메타 데이타, 라이브러리, 패키지를 저장하고 관리하는 장소를 의미하며 패키지 관리자가 패키지를 다운로드받고 업로드할 수 있는 기능을 제공합니다.

패키지 관리자를 제공하는 언어들은 각자의 중앙 저장소(Central Repository)가 있으며 자바의 경우 https://repo1.maven.org/maven2, 파이썬의 경우 https://pypi.python.org, PHP 의 경우 http://packagist.org/ 등의 저장소가 있습니다. 

이외에도 상용 라이브러리이거나 내부에서 개발한 라이브러리를 사내의 다른 개발자나 프로젝트와 공유하기 위한 배포 용도로도 사용한다.

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

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

저장소의 필요성

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

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

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

내부에서 만든 라이브러리가 추가/변경될 경우 버전 관리에 커밋하고 개발 단계일 경우 email 이나 파일 공유 서버를 통해 전달받아 테스트를 진행하였다. 용도로 사용하는 사설 저장소(Private Repository)도 있습니다.

저장소 관리자(Repository Manager)

저장소 관리자는 저장소의 기능을 제공하고 관리자 기능을 제공하는 소프트웨어를 의미하며 라이브러리를 등록/삭제/배포하고 컴포넌트의 생명주기를 관리하기 위한 용도로 사용됩니다.

Private Repository 회사나 개발팀에서

추가로 중요한 기능중 하나는 중앙 저장소를 미러링(Mirroring) 및 캐싱하여 빠른 속도로 빌드를 하게 해주며 중앙 저장소가 장애가 있어도 빌드 업무가 중단되지 않게 합니다.

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

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

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

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

...

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

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

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

메이븐(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

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

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

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

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

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

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

저장소 관리자(Repository Manager)

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

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

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

...

하위 페이지

...