빌드 산출물과 버전
5. 자주 하는 실수 (Tip)
❌ 실수 1. 빌드 시각을 jar 에 그대로 남겨 매번 해시가 달라짐
jar --create 에 --date 를 안 넣으면 파일 시스템의 현재 시각이 그대로 들어갑니다. 같은 소스라도 빌드할 때마다 해시가 달라져 재현 여부를 확인할 수 없습니다.
❌ 실수 2. Main-Class 를 빠뜨려 java -jar 실행이 안 됨
매니페스트에 Main-Class 가 없으면 "메인 매니페스트 속성이 없습니다" 오류가 납니다. --main-class 옵션이나 매니페스트 파일 양쪽 다 빠지지 않았는지 확인합니다.
❌ 실수 3. 버전을 소스 코드 여러 곳에 하드코딩
버전 문자열을 클래스 안에도 적고 파일 이름에도 따로 적으면 하나만 바꾸고 잊기 쉽습니다. VERSION 파일이나 빌드 도구의 버전 변수 한 곳만 고치도록 통일합니다.
❌ 실수 4. 체크섬 파일을 산출물과 따로 배포
jar 만 옮기고 .sha256 파일을 빠뜨리면 받는 쪽에서 검증할 방법이 없습니다. 항상 산출물과 체크섬 파일을 짝으로 함께 배포합니다.
❌ 실수 5. 체크섬 검증 없이 손상된 파일을 그대로 실행
전송 실패로 일부만 받아진 jar 를 그냥 실행하면 알 수 없는 오류가 납니다. 배포 스크립트에 sha256sum -c 검증 단계를 넣어 실행 전에 걸러냅니다.
❌ 실수 6. 테스트 클래스를 그대로 배포 산출물에 포함
*Test.class 까지 jar 에 넣으면 산출물 크기만 커지고 실서비스와 무관한 코드가 섞입니다. 패키징 단계에서는 테스트 클래스를 뺀 out/ 만 -C 로 지정합니다.
❌ 실수 7. 산출물 이름에 버전을 안 넣어 이전 파일을 덮어씀
app.jar 로만 배포하면 새 빌드가 이전 파일을 그대로 덮어써 어떤 버전이 서버에 있는지 알 수 없습니다. app-1.2.0.jar 처럼 이름에 버전을 반드시 넣습니다.
❌ 실수 8. SNAPSHOT 버전을 프로덕션에 그대로 배포
-SNAPSHOT 이름의 산출물은 계속 덮어써지는 개발 중 버전이라는 표시입니다. 운영 서버에는 태그로 확정한 정식 버전만 올립니다.
❌ 실수 9. 클래스 파일은 안 보고 jar 해시만 믿음
--date 없이 빌드했으면서 jar 해시가 우연히 같다고 재현 가능하다고 판단하면 잘못된 결론입니다. 항상 --date 를 고정한 뒤 해시를 비교해야 의미가 있습니다.
❌ 실수 10. 아티팩트 저장소 없이 산출물을 서버마다 수동 복사
scp 로 서버마다 따로 옮기면 어느 서버가 최신인지, 이전 버전이 어디 남아 있는지 알기 어렵습니다. 사내 Nexus 같은 저장소를 두고 배포 스크립트가 그곳에서 내려받게 합니다.