빌드 도구는 컴파일부터 패키징까지 정해진 순서, 즉 생명주기(lifecycle)를 실행합니다. javac 를 직접 부르면 이 순서를 스크립트로 손수 짜야 하지만, Maven·Gradle 은 미리 정의된 단계를 제공합니다.
생명주기 단계는 보통 compile(컴파일) → test(테스트) → package(패키징) 순입니다. 도구가 달라도 이 순서 자체는 비슷합니다.
| 항목 | javac 직접 | Maven | Gradle |
|---|---|---|---|
| 설정 파일 | 없음(스크립트) | pom.xml(XML) |
build.gradle(Groovy·Kotlin) |
| 의존성 관리 | 수동으로 jar 준비 | 중앙 저장소에서 자동 | 중앙 저장소에서 자동 |
| 생명주기 | 직접 순서 작성 | mvn package 등 고정 명령 |
태스크 그래프로 커스텀 |
| 학습 난이도 | 낮음(순수 JDK) | 중간 | 중간~높음 |
| 대표 명령 | javac, jar |
mvn package |
gradle build |
이 레슨의 데모는 순수 javac·jar 로 진행합니다. Maven·Gradle 을 쓰는 실무 예제는 4.1~4.2 에서 텍스트로 다룹니다.
jar(Java ARchive)는 클래스 파일을 압축해 묶은 파일입니다. 안에 META-INF/MANIFEST.MF 라는 설정 파일을 넣고 Main-Class 속성을 지정하면 java -jar app.jar 로 바로 실행할 수 있습니다.
Main-Class 가 없으면 java -jar 실행 시 "메인 매니페스트 속성 없음" 오류가 납니다. 클래스패스(-cp)로 직접 지정해 실행하는 방법도 있지만, 배포용 산출물은 실행 가능 jar 로 만드는 편이 다룰 파일이 하나뿐이라 편합니다.
매니페스트는 키: 값 형식의 텍스트 파일입니다. 자주 쓰는 속성은 다음과 같습니다.
| 속성 | 의미 |
|---|---|
| Main-Class | java -jar 실행 시 호출할 클래스 |
| Implementation-Version | 산출물의 버전 문자열 |
| Implementation-Title | 산출물 이름 |
| Created-By | 빌드에 쓰인 JDK 정보(jar 도구가 자동 기록) |
jar --create 명령의 --main-class 옵션과 --manifest=파일 옵션을 함께 쓰면, 지정한 매니페스트 파일에 Main-Class 속성이 자동으로 합쳐집니다.
버전을 소스 코드 안에 흩어 두면 빌드마다 여러 곳을 고쳐야 합니다. 한 곳에서 관리하는 방법이 두 가지 있습니다.
1.2.0 같은 문자열만 담은 파일을 두고, 빌드 스크립트가 읽어서 매니페스트에 씁니다.git describe: 가장 가까운 태그를 기준으로 v1.2.0-3-gabc1234 처럼 태그 뒤 커밋 수까지 자동 생성합니다. 태그로 버전을 관리하는 06 레슨과 이어집니다.이 레슨의 데모는 인터넷·git 저장소 없이도 돌아가야 하므로 VERSION 파일 방식을 씁니다. 실무에서는 두 방식을 함께 쓰기도 합니다(태그가 없으면 VERSION 파일이 기본값).
재현 가능한 빌드(reproducible build)는 같은 소스로 몇 번을 다시 빌드해도 바이트 단위로 같은 산출물이 나오는 빌드입니다. 산출물의 체크섬만 비교해도 "정말 이 소스에서 나온 결과인지" 검증할 수 있습니다.
가장 흔한 방해 요인은 빌드 시각입니다. 압축 파일 포맷은 보통 각 항목에 수정 시각을 저장하는데, 이 값이 빌드할 때마다 "지금 시각"으로 채워지면 소스가 같아도 산출물은 매번 달라집니다.
JDK 의 jar --create 명령은 --date=<시각> 옵션으로 모든 항목의 타임스탬프를 고정된 값으로 채울 수 있습니다. ISO-8601 형식(2026-01-05T09:00:00+09:00)을 씁니다.
이 옵션 없이 빌드하면 파일 시스템의 항목 시각이 그대로 들어가 매번 해시가 달라집니다. --date 를 CI 스크립트에 고정해 두면 같은 커밋에서 나온 산출물은 항상 같은 해시를 갖습니다.
체크섬은 파일 내용을 짧은 문자열로 요약한 값입니다. 파일이 1바이트만 바뀌어도 전혀 다른 값이 나오므로 전송·저장 중 손상 여부를 확인하는 데 씁니다.
sha256sum 명령은 SHA-256 알고리즘으로 64자리 16진수 문자열을 만듭니다. 같은 파일이면 언제 어디서 계산해도 같은 값이 나옵니다.
sha256sum 파일 > 파일.sha256 으로 체크섬 파일을 만들고, sha256sum -c 파일.sha256 으로 검증합니다. 검증은 .sha256 파일 안의 값과 실제 파일을 다시 계산한 값을 비교합니다.
값이 같으면 OK, 다르면 FAILED 를 출력합니다. 산출물을 배포할 때 체크섬 파일도 함께 올려 두면, 받는 쪽에서 전송 중 손상이나 변조를 바로 알 수 있습니다.
산출물 이름에 버전을 넣지 않으면 새 빌드가 이전 파일을 덮어써 어떤 버전이 배포됐는지 알 수 없습니다. 흔한 규칙은 <이름>-<버전>.jar 형태입니다.
| 예시 | 의미 |
|---|---|
app-1.2.0.jar |
app 프로젝트의 1.2.0 릴리스 |
app-1.2.0-SNAPSHOT.jar |
개발 중인 미완성 버전 |
app-1.2.0.jar.sha256 |
체크섬 파일(짝을 이룸) |
버전 번호 체계(유의적 버전, SemVer) 자체는 06 레슨에서 자세히 다룹니다. 이번 레슨은 버전을 파일 이름과 매니페스트에 "넣는 방법"에 집중합니다.
산출물을 서버마다 손으로 복사하면 어떤 서버에 어떤 버전이 있는지 추적하기 어렵습니다. 아티팩트 저장소(artifact repository)는 산출물을 버전별로 보관하고 내려받을 수 있게 해 주는 서버입니다.
| 저장소 | 특징 |
|---|---|
| Nexus | 사내 설치형, 폐쇄망에서 가장 흔히 씀 |
| GitHub Packages | GitHub 저장소에 딸린 저장소, 인터넷 필요 |
| Artifactory | 상용, 다양한 포맷 지원 |
폐쇄망 환경에서는 사내에 설치한 Nexus 에 산출물을 올리고, 배포 스크립트가 그 주소에서 내려받는 구조를 씁니다. 이 레슨의 데모는 저장소 업로드 없이 로컬 dist/ 폴더까지만 재현합니다.
소스 + VERSION 파일
→ javac 컴파일 (out/)
→ jar --create --main-class --manifest --date (dist/app-버전.jar)
→ sha256sum 으로 체크섬 생성
→ (아티팩트 저장소에 업로드, 폐쇄망은 사내 Nexus)
→ 다음 레슨: 서버에 배포버전과 체크섬은 산출물에 붙는 "신분증"이고, --date 고정은 그 신분증이 매번 같은 얼굴을 가리키게 만드는 장치입니다.