Maven, Artifact, GAV

#1 Module

• 공식 홈페이지
• GitHub

Java 프로젝트를 위한 종합 도구. Java 프로젝트의 라이브러리 관리, 소스 코드의 컴파일ㆍ빌드를 수행한다.
 

#2 Artifact

#2-1 What (정석적 정의)

Artifact란 쉽게 말해 Maven에서만 쓰는(Maven의 과거 인기로 인해, 현재는 Maven이랑 관련 없어도 그냥 보통 명사처럼 쓰인다) 라이브러리 단위다. 정확히 말하면 살짝 어려운데, 아래의 조건을 전부(교집합) 만족하는 파일 하나를 의미한다.
 

1. 파일의 형식(확장자)과 관계없이, 단 하나의 파일.
2. 해당 파일을, 'Maven Repository'(#3)에서 'GAV'(#4) 형식으로 요청할 수 있음.

대부분 Java 코드를 컴파일한 결과물인 .jar(안드로이드용 Artifact인 경우에는 .aar) 파일이다. 바꿔 말하면 Artifact는...

#2-2 취급 (또 다른 정의)

독립적으로 빌드ㆍ배포ㆍ의존성 관리될 수 있는 최소 단위

바꿔 말하면 Artifact는 '독립적으로 빌드·배포·의존 관리될 수 있는 최소 단위'로 취급된다. 왜냐하면 현대의 코딩은 객체지향 프로그래밍 패러다임 하에 있으므로, 기능적ㆍ가독성적으로 쪼갤 수 있는 Artifact를 굳이 여러 Artifact로 안 쪼개고 통째로 컴파일하지는 않을 테니까 말이다.
 
'최소'의 의미
그렇다고 가능한 한 전부 쪼개버리면 역으로 가독성이 하락할 것이다. Artifact 개발자들이 알아서(?) 잘, 적절한 단위로 쪼개놨을 것이다. '최소 단위'라는 말에 있는 '최소'가, 정말 사전 뜻 그대로의 '최소'는 아니라는 얘기다.
 

#3 Maven Repository

Artifact를 제공하는 다양한 서버들을 통칭해 Maven Repository라 부른다. 'Artifact를 제공'한다는 것에서 눈치챘겠지만, 이런 서버에는 GAV 형식으로 요청할 수 있다. (어찌 됐든 서버이므로 HTTP GET 요청을 하긴 하지만, 그 URL이 GAV 문자열의 조합이기에 클라이언트가 URL을 따로 알아둘 필요가 없다. #5-2 참고).
 
확장된 역할
Maven이 Java 관리 도구다 보니, 처음에는 Java 라이브러리 저장용으로 사용되었을 것이다. 그러나 이후 확장되어 다른 언어(JavaScript 등)나 플랫폼(Android 등)용 Artifact도 제공한다.
 
주의할 점
구글에 "Maven Repository"라고 치면 바로 나오는 Maven Repository라는 사이트는 Maven Repository가 아니다. 다양한 Maven Repository들의 인덱스/검색용 웹사이트다. 비유하자면 영화를 볼 수는 없어도 각종 관련 정보를 알 수 있는, '영화 리뷰 사이트' 같은 곳이다. 현존하는 주요 Maven Repository를 보고 싶다면 해당 사이트의 하위 URL인 여기에서 볼 수 있다.
 

#4 GAV

#4-1 What

"Artifact Coordinate"
= "GAV"
= "groupId : artifactId : version"
≈ "GAVCE"
(참조: 공식 설명)

Artifact의 (Maven Repository 상) 주민등록번호다. Artifact Coordinate라는 말이 더 격식(?)있는 표현이지만, 대부분의 사람은 GAV라 부른다. GAV는 3가지 요소의 앞 글자를 딴 축약어로, 각각에 대한 설명은 아래와 같다.
 

#4-2 groupId

'G'에 해당한다. 이름^Name으로 치면 성^{Last Name}에 해당한다. 이런 요소가 왜 존재하냐면 첫째로, 이름^{First Name}이 같은 경우 성^{Last Name}으로 구별할 수 있기 때문이다 (우리나라는 성의 종류가 이름의 종류보다 적기에, 우리나라 한정으로는 와닿는 비유가 아니긴 하다).

 
둘째로, '성'을 통해서 Artifact의 제작자(group)가 누군지 표시할 수 있기 때문이다. 따라서 하나의 Maven Repository에서 groupId는 유일(Unique)해야 한다.
 

#4-3 artifactId

'A'에 해당한다. 이름^Name으로 치면 이름^{First Name}에 해당한다. 주의할 점은 artifactId ≠ artifact라는 것이다. 'artifact'라는 단어만 공유할 뿐 둘은 다르다. 그냥 artifactId가 아니라 First Name이라고 생각하는 것이 편하다.

 
어쨌든, artifactId는 같은 groupId 내에서만 유일(Unique)하면 된다. 두 Artifact가 서로 다른 groupId여도 artifactId는 같을 수 있다. 이름이 같아도 성이 다르면 다른 사람인 것처럼 말이다. 반대로 성이 같다면 이름은 반드시 달라야 한다.
 

#4-4 version

'V'에 해당한다. 말 그대로 Artifact의 버전이다.
 

#4-5 GAVCE

"GAV"에 가끔 "CE"를 더해 Artifact Coordinate를 표현하기도 한다. 'C'는 Classifier(분류자)로, 같은 GAV이지만 변형(가령 테스트 전용 변형, 경량 버전 변형, 컴파일된 코드 대신 컴파일되기 전의 소스 코드가 들어 있는 변형 등)인 Artifact를 표시하기 위한 꼬리표다. 'E'는 Extension(확장자)이다. jar, aar, pom, zip 등.
 

#5 실습

#5-1 GAV 예시

androidx.hilt : hilt-navigation-compose : 1.2.0
(groupId : artifactId : version)

위와 같은 Artifact가 있다고 치자. 이를 다운로드 해보겠다. 이용할 Maven Repository의 Root URL은 (https://dl.google.com/dl/android/maven2/)다. 여담으로 해당 URL에 접속해 보면 404가 뜬다. 아마 저장소가 인덱스 파일도 없고, Directory Listing도 제공하지 않기에, 저장소 관리자가 Root URL 요청 시 404를 반환하게 설정해 놓았을 것이다.
 

#5-2 Artifact(GAV) URL

이 GAV(androidx.hilt : hilt-navigation-compose : 1.2.0)를 요청해 보겠다. 이 요청용 URL을 Artifact URL 또는 GAV URL이라 부른다. 공식 문서에 따라 Artifact URL을 유추하면 아래와 같다. 
 

https://dl.google.com/dl/android/maven2/androidx/hilt/hilt-navigation-compose/1.2.0/hilt-navigation-compose-1.2.0.aar

이 링크를 클릭하면 Artifact가 다운로드된다.
 

#5-3 실제 파일

hilt-navigation-compose-1.2

0.01MB

위 링크에서 다운로드한 파일이다. 이 파일의 확장자를 .zip으로 바꾸고 압축을 해제해 보면 컴파일된 코드(.class 확장자 파일)가 들어있음을 확인할 수 있다. 만약, Classifier가 소스 코드를 제공하는 변형이었다면 컴파일된 코드가 아니라, 컴파일되기 전의 소스 코드가 들어있었을 것이다.
 

#5-4 GAVCE 예시

만약, 위 Artifact에 변형이 존재하고 그 변형이 '테스트용 변형'이라 해보자. 테스트용 변형의 경우 Classifier로 "tests"를 주로 쓴다. 그리고 해당 Artifact의 확장자는 rar라 해보자. 그렇다면 GAVCE는 아래와 같을 것이다.
 

[GAV] androidx.hilt : hilt-navigation-compose : 1.2.0
[C] tests
[E] rar

이 GAVCE의 Artifact URL을 유추해 보겠다. 'C'는 파일 이름 옆에 붙이는 게 규칙이다. 따라서, Artifact URL은 (https://dl.google.com/dl/android/maven2/androidx/hilt/hilt-navigation-compose/1.2.0/hilt-navigation-compose-1.2.0-tests.rar)가 된다. 이 URL은 상상으로 만든 GAVCE에 기반하기에, 해당 URL 링크를 눌러봐도 404 에러만 뜰 것이다.
 

#5-5 Package와의 연관성

패키지(Package): 폴더 트리의 논리적 이름. Artifact 내부에서 .class 파일이 저장되는 실제 경로(폴더 구조)와 일치.
(* Artifact가 컴파일된 자바 코드를 보유하는 Artifact라는 조건 하의 설명)

여기서 갑자기 Package를 설명하는 이유는, Package의 값이 GAV의 값과 관습적으로 연관이 있기 때문이다. 위에서 설명한 Artifact(#5-2)를 예로 들어보겠다. 저 Artifact를 성공적으로 프로젝트에 넣었고 이제 사용할 일만 남은 상황이다. import 문만 쓰면 끝이다. 이 import 문을 어떻게 써야 할까? 아래와 같다.
 

import androidx.hilt.navigation.compose.hiltViewModel

묘하게 GAV 값과 닮았다. 마치 약속이라도 한 것처럼 말이다. Artifact를 뜯어서 확인해보자. #5-3에 있는 실제 예시 파일을 .zip 확장자로 변경하고 압축을 해제하면 아래와 같은 디렉토리 구조가 나온다.
 

androidx > hilt > navigation > compose 폴더를 거쳐 HiltViewModel 파일이 존재한다. 이런 구조로 Artifact를 구성해야 한다는 의무 사항은 없다. 그러나, Package를 GAV와 비슷하게 지음으로써 어느 Artifact에서 import 하는 것인지를 직관적(시각적)으로 보일 수 있다. 그러니 이런 관습이 생긴 것이다.