방송대 방통대 Java프로그래밍 15강 - 라이브러리와 모듈 - 요약 노트 시험족보 예상문제 - 올에이클래스

Java프로그래밍 15강 - 라이브러리와 모듈

여러 프로그램에서 재사용하는 Java 라이브러리를 JAR 파일로 만들고 프로젝트에 연결하는 과정을 학습한다. 이어서 Java 9에 도입된 모듈 시스템의 목적과 module-info.java, exports·requires·requires transitive, Java 표준 모듈의 사용법을 정리한다.

제1장 Java 라이브러리의 개념

1. 재사용 가능한 클래스와 인터페이스

라이브러리는 여러 프로그램에서 공통으로 사용할 수 있는 클래스와 인터페이스의 모음이다. 같은 기능을 프로젝트마다 다시 작성하지 않고 검증된 코드를 가져다 쓸 수 있으므로 개발 시간과 중복을 줄이고 유지보수성을 높인다.

Java 라이브러리는 일반적으로 여러 .class 파일을 하나로 묶어 압축한 .jar 파일 형태로 배포한다. 의미나 역할이 비슷한 클래스와 인터페이스는 패키지로 구성하고, 여러 패키지와 관련 메타데이터를 하나의 JAR에 담는다.

구조: 클래스와 인터페이스는 패키지로 묶이고, 여러 패키지의 컴파일 결과는 JAR 파일로 배포될 수 있다.

2. 라이브러리와 애플리케이션의 분리

라이브러리 프로젝트는 재사용할 기능을 제공하고, 애플리케이션 프로젝트는 그 기능을 외부 의존성으로 추가하여 사용한다. 라이브러리의 public 클래스와 public 멤버는 사용하는 프로젝트에서 import하여 접근할 수 있다. 일반적인 JAR 라이브러리는 Java 9 모듈 기술자를 반드시 포함할 필요는 없다.

제2장 JAR 라이브러리 만들기

1. 라이브러리 프로젝트 구성

강의 예제에서는 my_lib라는 Java 프로젝트를 만들고 module-info.java를 생성하지 않는다. pack_a 패키지에는 Member 클래스, pack_b 패키지에는 Student 클래스를 작성한다. 패키지를 나누면 클래스의 역할을 구분하고 이름 충돌을 피할 수 있다.

2. JAR 파일 내보내기

프로젝트 안에 결과물을 둘 dist 폴더를 만든 뒤 IDE의 Export 메뉴에서 JAR file을 선택한다. 내보낼 때 컴파일된 .class 파일을 포함하고, 결과 파일을 my_lib/dist/my_lib.jar처럼 지정한다.

JAR 파일은 소스 자체보다 컴파일된 클래스와 자원을 배포하기 위한 단위이다. 외부 프로젝트가 사용할 public API와 패키지 구조를 안정적으로 설계해야 한다.

3. 라이브러리 제작 흐름

1. 재사용할 기능을 별도 Java 프로젝트에 작성한다.
2. 관련 클래스와 인터페이스를 의미 있는 패키지로 나눈다.
3. 컴파일된 클래스가 포함되도록 JAR로 내보낸다.
4. 배포할 JAR 파일의 경로와 버전을 관리한다.

제3장 JAR 라이브러리 사용하기

1. Classpath에 라이브러리 추가

라이브러리를 사용할 애플리케이션 프로젝트를 만들고, 강의 예제에서는 UseMyLibExample이라는 이름을 사용한다. 이 프로젝트 역시 전통적인 JAR 사용 예이므로 module-info.java를 만들지 않는다.

프로젝트의 Build Path 설정에서 Libraries의 Classpath에 외부 JAR를 추가한다. 작업공간 밖에 있는 JAR는 Add External JARs, 같은 작업공간 안의 JAR는 Add JARs를 사용한다. 앞에서 만든 my_lib.jar를 선택하고 설정을 적용하면 애플리케이션의 클래스 경로에 라이브러리가 포함된다.

2. public 클래스 가져오기

Classpath 설정이 끝나면 import pack_a.Member;, import pack_b.Student;처럼 라이브러리가 제공하는 public 클래스를 가져와 객체를 생성하고 메서드를 호출할 수 있다. JAR를 등록했더라도 클래스나 멤버의 접근 수준이 외부 사용을 허용하지 않으면 접근할 수 없다.

import pack_a.Member;
import pack_b.Student;

public class Main {
    public static void main(String[] args) {
        Member member = new Member();
        Student student = new Student();
    }
}

상황	IDE 명령	등록 위치
작업공간 밖 JAR	Add External JARs	Classpath
작업공간 안 JAR	Add JARs	Classpath
Java 모듈 프로젝트	Projects - Modulepath - Add	Modulepath

제4장 Java 모듈 시스템

1. 모듈의 등장 배경

Java 모듈 시스템은 Java 9부터 도입되었으며, Java 라이브러리를 한 단계 구조화한 방식이다. 패키지가 클래스의 묶음이라면 모듈은 패키지의 묶음이다. 모듈은 특정 기능을 담당하는 프로그램 단위로 관련 패키지를 포함한다.

모듈은 자신이 다른 어떤 모듈에 의존하는지 명시하고, 외부에 제공할 패키지를 선택적으로 공개할 수 있다. 기본적으로 모듈 내부의 패키지는 다른 모듈에 공개되지 않는다. 이 경계 덕분에 내부 구현을 숨기고 공개 API만 노출할 수 있으며, 필요한 모듈 사이의 의존 관계를 명확하게 관리할 수 있다.

모듈의 핵심: 패키지의 묶음, 명시적 의존성, 선택적 패키지 공개, 강한 캡슐화를 제공한다.

2. 일반 JAR와 모듈의 차이

구분	일반 JAR 라이브러리	Java 모듈
등록 경로	Classpath	Modulepath
기술자	필수 아님	module-info.java
외부 공개	public 클래스 중심	exports한 패키지만 공개
의존성	경로에 포함해 사용	requires로 명시
캡슐화	패키지 접근 수준	모듈 경계까지 포함한 강한 캡슐화

제5장 module-info.java와 모듈 정의

1. 모듈 기술자

module-info.java는 모듈의 이름과 모듈 사이의 관계를 기술하는 파일이다. Java 모듈 프로젝트의 src 폴더에 위치하며, 빌드 결과에서는 JAR의 루트에 포함된다. 파일 안에는 module 모듈이름 { ... } 형식으로 모듈을 선언한다.

모듈 기술자에는 모듈 이름, 의존하는 다른 모듈, 외부에 공개하는 패키지를 명시한다. 프로젝트 이름과 모듈 이름을 같게 두면 구조를 이해하기 쉽지만 모듈 이름은 기술자에서 명시적으로 정해진다.

module my_mod_a {
    requires my_mod_b;
}

module my_mod_b {
    exports package_a;
    exports package_b;
}

2. exports 지시어

exports 패키지명;은 해당 패키지를 다른 모듈에서 사용할 수 있도록 외부에 제공한다는 뜻이다. 패키지 안 클래스가 public이어도 모듈이 그 패키지를 exports하지 않으면 다른 모듈에서 접근할 수 없다. 즉 public 접근 수준과 모듈 공개가 모두 충족되어야 한다.

3. requires 지시어

requires 모듈이름;은 현재 모듈이 다른 모듈에 의존하며 그 모듈이 공개한 패키지를 사용하겠다는 뜻이다. 사용하는 모듈의 module-info.java에 올바른 requires 선언이 있어야 해당 패키지를 import할 수 있다.

exports는 제공자 관점의 공개 선언이고 requires는 사용자 관점의 의존 선언이다. 두 지시어는 서로 다른 역할을 한다.

제6장 모듈 프로젝트 구성과 사용

1. 모듈을 제공하는 프로젝트

강의 예제에서는 my_mod_a 프로젝트가 pack_a의 Member와 pack_b의 Student를 제공하고, my_mod_b 프로젝트가 pack_c의 Triangle과 pack_d의 Circle을 제공한다. 각 프로젝트 생성 시 module-info.java를 만들고 외부에 제공할 패키지를 exports한다.

module my_mod_a {
    exports pack_a;
    exports pack_b;
}

module my_mod_b {
    exports pack_c;
    exports pack_d;
}

2. 모듈을 사용하는 프로젝트

사용자 프로젝트 MyProject도 module-info.java를 가진 모듈 프로젝트로 만든다. IDE의 Build Path 설정에서 제공자 프로젝트를 Classpath가 아닌 Modulepath에 추가한다. 그런 다음 사용자 모듈의 기술자에 필요한 모듈을 requires한다.

module MyProject {
    requires my_mod_a;
    requires my_mod_b;
}

모듈 경로와 기술자 설정이 완료되면 main 메서드에서 외부 모듈이 exports한 패키지의 public 클래스를 import하여 사용할 수 있다.

3. 사용 조건의 결합

다른 모듈의 클래스를 사용하려면 세 조건이 맞아야 한다. 제공자 모듈이 해당 패키지를 exports해야 하고, 사용자 모듈이 제공자 모듈을 requires해야 하며, 사용할 클래스와 멤버가 Java 접근 제어 규칙상 외부 접근이 가능해야 한다.

제7장 모듈 간 의존 관계

1. requires와 직접 의존성

모듈 A의 기술자에 requires B;를 선언하면 A가 B 모듈에 의존하고 B가 exports한 패키지를 사용할 수 있다는 뜻이다. 이 직접 의존성은 A 내부의 코드가 B를 사용하는 데 필요한 관계를 표현한다.

module A {
    requires B;
}

2. requires transitive

requires transitive B;는 A가 B에 의존한다는 사실을 A를 사용하는 다른 모듈에도 전달한다. 즉 A를 requires한 모듈은 B에 대한 의존 관계를 자동으로 얻게 된다. 의존성이 외부 API의 일부로 노출되어 A의 사용자가 B의 공개 자료형도 함께 사용해야 할 때 유용하다.

module A {
    requires transitive B;
}

강의 예제에서 사용자 프로젝트가 my_mod_a를 requires하고, my_mod_a가 requires transitive my_mod_b로 선언하면 사용자 프로젝트는 my_mod_b의 공개 패키지도 사용할 수 있다.

차이: requires는 현재 모듈의 직접 의존성이고, requires transitive는 그 의존성을 현재 모듈의 사용자에게 전파한다.

제8장 Java 표준 모듈

1. 표준 라이브러리의 모듈화

Java 9부터 모듈 개념이 도입되면서 Java 표준 라이브러리도 여러 표준 모듈로 나뉘었다. java.xxx 형태의 모듈을 표준 모듈 또는 플랫폼 모듈이라 한다.

2. java.base 모듈

java.base는 Java 플랫폼의 가장 기본이 되는 모듈이다. 모든 모듈이 이 모듈에 의존하지만, requires java.base;는 자동으로 적용되므로 기술자에 직접 작성하지 않아도 된다.

java.base에는 java.lang, java.math, java.net, java.io, java.nio, java.util 등의 주요 패키지가 포함된다. 그중 java.lang은 모듈 규칙과 별개로 소스 코드에서 import를 생략할 수 있는 기본 패키지이다.

3. java.sql 모듈 사용

java.base에 포함되지 않은 표준 모듈의 패키지를 사용하려면 사용자 모듈의 module-info.java에 requires 선언을 추가해야 한다. JDBC 관련 java.sql 패키지를 사용하려면 requires java.sql;을 작성한다. java.sql 모듈은 해당 패키지를 exports하고 있으므로 의존 선언 후 코드를 import할 수 있다.

module com.example.app {
    requires java.sql;
}

표준 모듈	특징	requires 작성
java.base	플랫폼의 기본 모듈, 모든 모듈이 의존	생략
java.sql	JDBC와 SQL 관련 API 제공	모듈 프로젝트에서 명시

핵심 개념 정리

• 라이브러리는 여러 프로그램에서 공통으로 재사용하는 클래스와 인터페이스의 모음이다.
• Java 라이브러리는 여러 컴파일된 클래스와 패키지를 JAR 파일로 묶어 배포할 수 있다.
• 일반 JAR는 Classpath에 추가하고 public 클래스를 import하여 사용한다.
• Java 9 모듈은 패키지의 묶음이며 명시적 의존성과 선택적 패키지 공개를 제공한다.
• module-info.java는 모듈 이름, 필요한 모듈, 공개할 패키지를 기술한다.
• exports는 제공 패키지를 공개하고 requires는 다른 모듈에 대한 의존성을 선언한다.
• requires transitive는 현재 모듈의 의존성을 그 모듈의 사용자에게 전달한다.
• java.base는 모든 모듈이 자동으로 의존하며, java.sql처럼 별도 표준 모듈은 필요한 경우 requires한다.

라이브러리와 모듈은 모두 코드 재사용을 위한 단위지만 관리 범위가 다르다. JAR 라이브러리는 클래스 경로에 추가하여 기능을 재사용하고, 모듈은 패키지를 묶어 공개 API와 의존 관계를 기술한다. 모듈 코드를 사용할 때는 Modulepath 등록, 제공자의 exports, 사용자의 requires, 클래스의 접근 수준을 함께 확인해야 한다.

예상문제 20선

1. Java 라이브러리에 대한 설명으로 옳은 것은?

① 하나의 main 메서드만 모은 파일이다.② 운영체제 명령만 저장하는 설정이다.③ 여러 프로그램에서 재사용할 수 있는 클래스와 인터페이스의 모음이다.④ 반드시 하나의 패키지만 포함해야 한다.

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ③
라이브러리는 공통 기능을 재사용할 수 있도록 관련 클래스와 인터페이스를 모아 둔 것이다.

2. Java 라이브러리 배포에 주로 사용하는 파일 형식은?

① .txt② .jar③ .html④ .sql

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ②
JAR는 여러 컴파일된 클래스와 패키지 자원을 하나로 묶는 Java 배포 형식이다.

3. 작업공간 밖의 JAR 라이브러리를 Eclipse 프로젝트에 등록할 때 사용하는 명령은?

① Add Source Folder② Add Module Info③ Add Projects④ Add External JARs

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ④
외부 경로의 JAR는 Classpath의 Add External JARs로 등록하며 작업공간 안의 JAR는 Add JARs를 사용한다.

4. Java 모듈 시스템이 도입된 버전은?

① Java 9② Java 1③ Java 5④ Java 8

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ①
Java 9부터 표준 라이브러리와 사용자 프로젝트에 모듈 시스템이 도입되었다.

5. 클래스와 패키지, 모듈의 포함 관계로 옳은 것은?

① 클래스가 여러 모듈을 포함한다.② 모듈이 패키지 안에만 존재한다.③ 세 개념은 서로 포함 관계가 없다.④ 패키지는 클래스의 묶음이고 모듈은 패키지의 묶음이다.

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ④
관련 클래스가 패키지를 이루고 관련 패키지들이 하나의 기능 단위인 모듈을 구성한다.

6. 모듈의 정보를 기술하는 파일은?

① package-info.class② manifest.java③ module-info.java④ classpath.txt

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ③
module-info.java는 모듈 이름, 의존 모듈과 외부 공개 패키지를 선언하는 모듈 기술자이다.

7. 모듈 내부 패키지의 기본 공개 상태는?

① 다른 모듈에 공개되지 않는다.② 모든 모듈에 자동 공개된다.③ java.base에만 자동 공개된다.④ Classpath의 모든 JAR에만 공개된다.

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ①
모듈은 기본적으로 내부 패키지를 감추며 외부 제공이 필요한 패키지만 exports한다.

8. 모듈에서 패키지를 다른 모듈에 공개하는 지시어는?

① requires② exports③ imports④ transitive

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ②
exports pack_a;는 pack_a 패키지를 모듈 외부에서 사용할 수 있도록 공개한다.

9. 현재 모듈이 다른 모듈에 의존함을 선언하는 지시어는?

① requires② exports③ provides④ package

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ①
requires my_mod_a;는 현재 모듈이 my_mod_a가 공개한 패키지를 사용함을 선언한다.

10. 다른 모듈의 public 클래스를 사용하기 위한 조건으로 옳지 않은 것은?

① 제공자 모듈이 패키지를 exports해야 한다.② 사용자 모듈이 제공자 모듈을 requires해야 한다.③ 제공자 패키지는 반드시 java.base 안에 있어야 한다.④ 클래스 접근 수준이 외부 접근을 허용해야 한다.

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ③
사용자 정의 모듈의 패키지도 exports와 requires, public 조건을 만족하면 사용할 수 있으며 java.base 소속일 필요는 없다.

11. 모듈 프로젝트를 Eclipse에서 의존성으로 추가할 위치는?

① Sourcepath② Modulepath③ Output Buffer④ WatchService

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ②
일반 JAR는 Classpath에, 이름 있는 Java 모듈 프로젝트는 Modulepath에 추가한다.

12. requires transitive B;의 의미는?

① B의 모든 패키지를 자동으로 삭제한다.② A와 B의 모듈 이름을 합친다.③ B를 Classpath로 이동한다.④ B에 대한 의존성을 현재 모듈을 사용하는 다른 모듈에도 전달한다.

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ④
transitive 의존성은 A의 사용자가 B의 공개 API도 읽을 수 있도록 의존 관계를 전파한다.

13. 모든 Java 모듈이 자동으로 의존하는 기본 표준 모듈은?

① java.sql② java.base③ java.desktop④ my_mod_a

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ②
java.base는 플랫폼의 기본 모듈이며 명시적인 requires 없이 모든 모듈이 의존한다.

14. java.base 모듈의 의존 선언에 대한 설명은?

① 자동 적용되므로 requires java.base를 생략할 수 있다.② 반드시 exports java.base로 작성한다.③ Classpath에서만 사용할 수 있다.④ 사용자 정의 모듈에서는 사용할 수 없다.

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ①
모든 이름 있는 모듈은 java.base를 암묵적으로 requires하므로 기술자에 반복하지 않는다.

15. java.base에 포함된 패키지가 아닌 것은?

① java.lang② java.util③ java.sql④ java.nio

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ③
java.sql 패키지는 별도의 java.sql 모듈에서 제공되며 나머지 예시는 java.base에 포함된다.

16. 모듈 프로젝트에서 JDBC의 java.sql 패키지를 사용할 때 필요한 선언은?

① exports java.sql;② import module java.sql;③ requires java.base.sql;④ requires java.sql;

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ④
java.sql은 java.base 밖의 별도 표준 모듈이므로 사용 모듈의 기술자에 requires해야 한다.

17. public 클래스가 있는 패키지를 exports하지 않았을 때 다른 모듈의 접근 결과는?

① public이므로 언제나 접근할 수 있다.② 자동으로 Classpath에 복사된다.③ java.base를 통해 우회 접근한다.④ 모듈 경계에서 공개되지 않아 접근할 수 없다.

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ④
모듈 시스템에서는 클래스의 public 여부와 별개로 제공자 모듈의 exports 선언이 필요하다.

18. 일반 JAR 라이브러리와 모듈의 등록 위치를 바르게 연결한 것은?

① 둘 다 반드시 Sourcepath② 일반 JAR는 Classpath, 모듈은 Modulepath③ 일반 JAR는 Modulepath, 모듈은 Classpath④ 둘 다 WatchService

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ②
전통적인 JAR 의존성은 Classpath에, module-info.java를 가진 모듈 의존성은 Modulepath에 둔다.

19. java.lang 패키지에 대한 설명으로 옳은 것은?

① java.base에 포함되며 소스에서 import를 생략할 수 있다.② java.sql 모듈에만 포함된다.③ 반드시 requires java.lang으로 선언한다.④ 사용자 정의 모듈에서 접근할 수 없다.

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ①
java.lang은 java.base의 핵심 패키지이며 Java 언어 규칙에 따라 자동 import된다.

20. exports와 requires의 역할을 바르게 설명한 것은?

① 둘 다 모듈의 이름을 변경한다.② exports는 의존 모듈, requires는 공개 패키지를 선언한다.③ exports는 제공 패키지를 공개하고 requires는 사용할 모듈에 대한 의존성을 선언한다.④ 둘 다 일반 JAR의 압축 해제 명령이다.

정답입니다.

오답입니다. 답안을 다시 선택해 보세요.

정답 및 해설 보기

정답: ③
제공자는 exports로 API 패키지를 공개하고 사용자는 requires로 필요한 모듈을 읽겠다고 선언한다.