모듈이라는 이름만으로 보장되는 것은 없습니다
패키지는 이름과 접근 범위를, Gradle 하위 프로젝트는 빌드 구성을, JPMS의 명명 모듈은 명시적인 의존과 공개 패키지를 표현합니다. 서비스의 배포 경계는 이들과 별도 결정입니다. 한 JAR을 만들었다는 사실만으로 네 경계가 모두 생기지 않습니다.
- 코드 접근패키지 접근 수준과 JPMS 공개 범위
- 빌드와 배포물하위 프로젝트·의존성·실행 구성
- 실행과 운영독립 배포·확장·장애 처리
JAR 간 참조와 JPMS 의존 규칙을 구분합니다
원문의 단방향 모듈 참조 설명에는 적용 대상을 붙여야 합니다. Java 21에서는 서로를 참조하는 public 클래스를 두 패키지에 함께 컴파일한 뒤 일반 JAR 두 개로 나누고 클래스 경로에 올려도 실행됐습니다. 이 검사는 두 Gradle 프로젝트를 각각 빌드할 수 있다는 증거는 아닙니다.
반대로 명명 모듈 alpha와 beta가 requires로 서로를 요구하면 javac가 순환 의존을 거절했습니다. 클래스 참조, 빌드 작업 의존, JPMS requires, 실행 중 호출은 서로 다른 그래프입니다. 제한이 필요한 그래프와 검사 도구를 구체적으로 적습니다.
접근 제어와 의존성 노출은 다릅니다
Java 패키지에도 접근 제어가 있습니다. package-private 타입을 다른 패키지에서 사용한 검사는 컴파일에 실패했습니다. JPMS에서는 public 타입이라도 읽을 수 있는 모듈의 공개 패키지에 있어야 다른 모듈에서 정상 접근할 수 있습니다. 공개 API 사용은 성공했고, 공개하지 않은 패키지 접근은 거절됐습니다.
Gradle java-library의 api와 implementation은 소비자에게 전이 의존성을 어떻게 노출할지 정합니다. implementation은 소비자의 컴파일 클래스 경로에서 내부 의존성을 제외하지만, 그 라이브러리 자체의 public 클래스를 private으로 바꾸는 기능은 아닙니다. 런타임 의존성도 별도로 확인합니다.
라이브러리 JAR과 실행 가능한 구성을 구분합니다
| 검사 구성 | 관측 결과 |
|---|---|
| 양방향 public 참조를 가진 일반 JAR 두 개 | 클래스 경로 실행 성공 |
| requires 순환을 가진 명명 모듈 | 컴파일 거절 |
| Main-Class가 없는 JAR을 java -jar로 실행 | 진입점 정보 부족으로 실행 거절 |
| 진입점은 있지만 필요한 클래스가 빠진 JAR | NoClassDefFoundError |
| 진입점과 필요한 클래스를 포함한 JAR | java -jar 실행 성공 |
JAR은 클래스와 자원을 담는 형식입니다. java -jar에는 Main-Class 진입점과 실행에 필요한 클래스가 필요합니다. 이번 검사에서는 필요한 클래스를 함께 담거나, -cp 방식으로 두 JAR을 공급한 경우에 실행됐습니다. 배포 방식을 정할 때 라이브러리, 실행 진입점, 외부 의존성의 공급 방법을 함께 기록합니다.
모듈 수만으로 배포물 크기나 기동 시간을 예측하지 않습니다. 포함한 클래스·자원·프레임워크와 실제 기동 작업이 결과를 바꿉니다. 이 검사는 동작 확인용이며, 원문의 1초 이내 기동 경험이나 용량 절감 폭을 측정·재현하지 않았습니다.
모듈별 선언과 최종 선택 버전을 대조합니다
Gradle 하위 프로젝트마다 플러그인과 의존성을 선언할 수 있습니다. 다만 하나의 의존성 그래프에서 같은 라이브러리의 서로 다른 버전을 요구하면 충돌 해소가 적용됩니다. Gradle 9.1.0의 기본 동작은 요청된 버전 중 높은 버전 선택이며, 제약·규칙으로 달라질 수 있습니다. 선언을 분리했다고 실행 시 모든 버전이 독립 유지되는 것은 아닙니다.
재사용할 라이브러리는 공개 계약과 필요한 전이 의존성을 정하고 소비자와 함께 검증합니다. 빌드 단위가 작아져도 API나 공유 의존성을 바꾸면 소비자 검사가 필요할 수 있습니다. 영향 범위는 디렉터리 개수보다 실제 의존 관계로 판단합니다.
책임자 지정과 수정 권한은 별도 선택입니다
담당자를 두는 방식이 반드시 다른 사람의 수정을 금지한다는 뜻은 아닙니다. Fowler는 강한 소유권, 약한 소유권, 공동 소유권을 구분하며, 담당자만 수정하는 방식의 대기 비용도 설명합니다. 원문의 담당자 경유 방식은 팀 운영 선택으로 읽고 모든 멀티 모듈 프로젝트의 필수 조건으로 일반화하지 않습니다.
별도 서버의 효과는 운영 계약으로 확인합니다
독립 배포와 확장이 필요한지, 실패한 의존 서비스를 호출 측이 어떻게 처리할지 확인합니다. Microsoft의 설명도 장애 격리를 호출 측의 올바른 실패 처리와 함께 다룹니다. 프로세스를 나눴다는 사실만으로 연쇄 장애가 차단되는 것은 아닙니다.
네트워크 지연, 데이터 일관성, 배포 버전 호환성과 관측 비용도 함께 평가합니다. 빌드 모듈 하나를 서버 하나로 대응시키는 규칙부터 정하기보다, 실제 변경·배포·복구 요구로 경계를 선택합니다. 이 문서의 Java 검사로 분산 시스템의 정확성을 보장할 수는 없습니다.
검수 범위
2026-10-12에 직접 받은 원문은 2026-08-05 갱신 표시를 가지며 본문 코드와 도해는 없었습니다. 검색 도구의 오래된 사본에는 추가 문단과 도해가 있어 최신 본문과 섞지 않았습니다. 공식·원저자 자료 8개를 대조하고 Java 21 검사 10개를 수행했습니다.
검사는 성공 동작 5개, 예상 컴파일 거절 3개, 예상 실행 거절 2개입니다. 원문 프로젝트, Gradle 빌드 실행, 성능, 실제 배포와 팀 운영 효과는 검증하지 않았습니다. 예제 소스와 명령·결과는 별도 검수 기록에 보존했습니다.