빌드는 어떻게 짜이고, 의존성은 어떻게 정렬될까?

빌드 도구가 하는 일은 결국 소스 컴파일 → 의존성 해석 → 테스트 → 패키징(JAR)의 자동화예요. 자바 진영의 양대 산맥인 Maven과 Gradle은 같은 목표를 정반대의 철학으로 풉니다.

라이브러리 하나를 추가하면 그 라이브러리가 쓰는 라이브러리, 또 그게 쓰는 라이브러리가 줄줄이 딸려와요. 이걸 전이 의존성(transitive dependency)이라고 합니다. 빌드 도구가 이 그래프를 자동으로 해석해 클래스패스를 구성해줘요.

<!-- Maven: BOM을 dependencyManagement로 import → 버전 정렬 -->
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-dependencies</artifactId>
      <version>3.3.0</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>
<!-- 이제 개별 의존성은 version 생략 가능 → BOM이 정한 버전 사용 -->

scope(Maven) / configuration(Gradle)은 "이 의존성이 언제 필요한가"를 정해요. 컴파일에만 필요한지, 런타임에만 필요한지, 테스트에만 필요한지에 따라 최종 산출물에 포함 여부가 달라집니다.

전이 의존성을 따라가다 보면 같은 라이브러리의 서로 다른 버전이 그래프 곳곳에서 나타나요. 최종적으로는 하나만 선택돼야 하는데(자바 클래스패스에는 같은 클래스가 하나만 존재), 이때 충돌 해결 규칙이 도구마다 다릅니다.

시맨틱 버저닝(SemVer)은 버전을 MAJOR.MINOR.PATCH 세 자리로 나눠 변경의 성격을 전달하는 규약이에요. 예: 3.4.1.

JPMS(Java Platform Module System, Project Jigsaw, Java 9)는 module-info.java로 모듈의 경계·의존·공개 범위를 명시하게 해요. public이면 어디서든 접근되던 기존 캡슐화의 한계를, 모듈 수준의 강한 캡슐화로 보강합니다.

// module-info.java
module com.example.order {
    requires com.example.common;   // 이 모듈이 의존하는 모듈
    requires java.sql;             // 플랫폼 모듈도 명시

    exports com.example.order.api; // 외부에 공개할 패키지
    // exports 안 한 패키지는 public 클래스라도 모듈 밖에서 접근 불가(강한 캡슐화)
}

재현 가능 빌드(reproducible build)는 "같은 소스·같은 의존성이면 바이트 단위로 동일한 산출물이 나온다"를 목표로 해요. 타임스탬프·파일 순서 같은 비결정 요소를 제거하고, 락파일로 의존성 버전을 고정하며, 빌드 캐시로 동일 입력의 결과를 재사용합니다. 이게 되면 "내 PC에선 되는데" 문제와 공급망 검증이 훨씬 쉬워져요.