[Spring boot] Spring Boot 라이브러리(Library) 개념 및 만들기(1)

 

Spring Boot 라이브러리(Library) 개념 및 만들기(1)

web, application 을 개발하다보면 라이브러리(Library) 라는 말을 자주 듣게 되고, 거의 필수적으로 사용하게 된다.

필자는 여러가지 모듈들에 반복적이고 공통적으로 들어가는 기능을 대체하기 위해 라이브러리를 만들기 위해 공부했던 내용들을

해당 글에 담았다. 

그럼 라이브러리가 어떤 개념인지, 어떤방법으로 만들고 적용 할 수 있는지에 대해서 아래에 설명하겠다.

 

 

1. 라이브러리(Library) 란?

라이브러리(Library) 는 공통적인 기능을 재사용하기 위해 별도로 분리된 코드 모음(모듈)이다.

여러개의 프로젝트, 모듈에서 공통적으로 쓰이는 코드를 반복적으로 작성하지 않고, 공통 모듈로 만들어서 필요한 모듈에서 의존성 형태로 가져와 사용하는 방식이다.

이 모듈은 Java 기준 Class, Interface 같은 것들이 존재하며 일반적으로 .jar 확장자로 사용하게 된다.

ClassPath 즉 jar 파일의 경로를 추가하여 사용한다.

 

기업들에서는 자주 사용되는 모듈들에 대해서 공통화, 코드 컨벤션 일치, 동일한 기능 보장, 보안 문제등으로 인해 자체 라이브러리를 개발, 관리하는 경우가 있을 수 있고, 오픈소스로 공개하는 경우도 존재한다(Spring Cloud Netflix ....)

 

라이브러리 형태로 만들어서 사용하게 된다면 코드관리가 단순해진다, 또한 확장성이 높아지며 개발에 대한 편의성이 올라가는 장점이 있다.

즉 장점들에 대해서 나열하자면 아래와 같다.

 

라이브러리의 장점 및 만드는이유

• 코드 재사용성: 공통적으로 사용하는 로직을 여러 프로젝트에서 재사용 가능
• 코드 간소화: 반복적인 코드를 제거하고, 필요한 코드들만 작성 및 관리
• 관리 및 유지보수: 라이브러리 저장소(Maven, Nexus) 를 통해 통합적인 관리가 가능하다(버전 업데이트 등)

 

2. Library 구성 방식

라이브러리를 만드려고 할때, 초기 구성을 어떻게 해야하는지 헷갈릴 수가 있다.

프로젝트 구성을 어떻게 해야하는지, 라이브러리 구성에 필요한 의존성은 어떻게 해야하는지, 관리는 어떻게 해야하는지와 같은 것을 의미한다.

 

2-1. 관리 적인 측면

관리부분을 먼저 이야기 하자면, 일반적으로 많이 쓰는 Maven Repository 에 배포 하는 방법과

사설 repository 라고 할 수 있는 Nexus Repository 가 존재한다. 

라이브러리를 해당 저장소에 배포를 하고, 다운로드 및 의존성 추가로 사용 할 수 있으며 버전별로 관리가 가능하다는 장점이 존재한다.

Nexus Repository

일반적으로 Nexus 저장소의 경우 기업별로 private 하게 관리해야 할때, 내부망에서만 인터넷 접근이 가능할때 사용된다.

 

2-2. 만드는 2가지 방법(Spring Boot 기준)

Spring boot 에서 사용할 수 있는 라이브러리를 만드는 방식에는 크게 2가지가 존재한다.

1. 일반적인 공통 라이브러리
   1. 단순히 코드를 모듈화 하여 JAR 파일로 Export
   2. 이 경우 타겟 프로젝트에서 필요한 설정이나 의존성을 직접 추가해야함.
2. Spring boot 기반 자동 구성 라이브러리
   1. Spring boot 의 자동 설정 기능(@Configuration, spring.factories ...) 를 활용하는 방법
   2. Spring 에 존재하는 의존성들을 사용 할 수 있음(Annotation, Spring bean ,,,)
   3. 설정없이 의존성 추가만으로 라이브러리의 기능을 사용할 수 있게 제공.

또한 라이브러리를 생성할때는 빌드 도구인 Maven, Gradle 을 활용하게 된다. 배포 및 관리를 용이하게 하기 위해서이다.

(라이브러리 버전, 의존성들, 패키지 경로 설정 등등)

해당 글에서는 Gradle 기반의 2번 Spring boot 기반 라이브러리 구성을 알아보도록 할것이다.

 

3. 간단한 Spring Boot 자동 구성 라이브러리 구성

Spring boot 기반으로 동작하게 하는 라이브러리를 구성할것이기 때문에

Spring boot 모듈을 하나 만들어주자. 

 

Package 경로의 경우 아무렇게나 해도 상관 없다. 

패키지 경로는 아래의 예시 사진처럼, import 시 설정한 패키지 경로가 표시 된다.

Package 경로가 미치는 영향

---

3-1. 다른 모듈에서 사용할 기능 정의

라이브러리를 만드는 가장 큰 이유인, 기능 정의 부터 해보도록 하겠다. 우선 크게 2가지의 샘플 기능을 넣을것이다.

1. Request 가 있을때 마다 log를 출력하는 Filter Class
2. 연산 기능을 수행하는 계산기(Calculator) Util Class

다른 기능들로 테스트 해보고 싶다면, 기능이 정의된 별도의 클래스를 작성하도록 하자.

FIlter Class

요청이 존재 할 때 마다 해당 log 를 출력하는 Filter Class 이다. 

계산기(Calculator) Class

해당 Class 는 간단하게 더하기 기능만 존재하는 Util 클래스이고, Spring Bean 으로 등록하여 사용할것이기에 

@Component 어노테이션을 붙여주었다. 객체를 생성해서 add() 를 호출하는 경우에는 어노테이션을 안붙여도 상관없다.

---

 

3-2. 라이브러리를 자동구성 가능하게 설정

일반적으로 객체를 생성해서 라이브러리 내의 기능을 사용 하는 경우도 있지만, Spring Boot 의 많은 라이브러리들은 간단한 설정클래스만 작성하여 사용하는 경우나, 바로 사용(적용)할 수 있는 경우가 많다.

이런 경우 생각할 수 있는건 static 한 class 이거나, Bean 으로 등록되어 Spring Container 에서 관리되고 있어

타겟 프로젝트에서 설정 하지 않아도 기능이 적용되어 있는 경우일 것이다. 

 

위에 예제 기능 Class 에서도 Bean 으로 등록하게 했으니. 타겟 프로젝트에서 인식할 수 있게 해줘야 한다.

왜냐면 2개의 Class 를 Bean 으로 만들긴 했지만,  Component scan 대상이 아니기 때문이다. 

라이브러리를 Component scan 대상으로 만들어서 Auto Configuration 대상으로 만들어 주는 작업을 하자.

 

3-2-1. Auto Configuration 클래스 생성

Auto Configuration Class

해당 클래스는 타겟 프로젝트에서 Library 내의 @Bean, @Component 객체들을 자동으로 구성하게 해준다.

이어서 해당 Configuration 클래스의 경로를 알려주기 위한 설정을 추가 하자. 

 

3-2-2. Auto Configuration 클래스 경로 설정

 

resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

해당 경로에 파일을 생성해준다.

 

생성한 파일 내부에 AutoConfiguration 경로를 적는다.

해당 경로를 못찾거나, 틀린경우 구성이 제대로 되지 않으니 다시 한번 확인하자.

 

해당 Auto Configuration 의 경우 Spring io 의 공식문서를 확인해보면 좋을것 같다.

해당 방법 말고, 다른 Auto Configuration 구성 방법이 존재하기 때문.

spring io docs

---

3-3. build.gradle 설정

 

이제 기능이 정의된 라이브러리를 올바르게 동작하기 위해 빌드도구를 이용하여 올바르게 패키징 되도록 할것이다.

build.gradle

맨 윗줄부터 확인을 해본다면, springframework.boot 버전옆에 apply false 라는 옵션이 추가 되었다. 

우리는 타겟 프로젝트의 Spring boot Plugin 을 사용하여 구성될 예정이기 때문에 해당 라이브러리에서 spring 플러그인을 적용하지 않겠다는 의미이다.  즉 실 사용할 프로젝트 모듈의 Spring Plugin 을 사용하기 위함이다.

 

중간의 dependecyManagement 항목은 Spring boot 의 BOM(Bill of Materials) 파일을 가져와 프로젝트의 의존성 버전을 관리하기 위함이다. 이는 의존성 추가시 버전을 명시 하지 않아도 되고, 각 의존성끼리 버전이 호환되지 않아 발생하는 문제를 방지한다.

 

최종 패키지 구조는 아래이미지와 같다.

라이브러리 프로젝트 구조

 

---

 

3-4. JAR 파일 생성하기.

 

라이브러리를 만들었으니 적용하기 위해 JAR 파일을 생성 해보도록 하자.

프로젝트를 build 하게 되면, build/libs/ 아래에 jar 파일이 생성되게 된다.

 

CLI 를 사용 한다면 아래와 같이, 프로젝트 경로에서 진행하면 된다.

 

빌드가 완료되면 해당 경로에 있는 jar 파일을 사용하면된다.

 

 

4. 라이브러리 적용 및 테스트

우선 라이브러리를 적용할 수 있는 Sample 프로젝트를 구성해준다. 

그리고 해당 프로젝트의 최상위 경로에 jar 파일을 추가해준다. 하지만 일반적으로는 libs 디렉토리를 추가하여

해당 폴더안에 jar 파일을 넣어서 사용한다. 

타겟 프로젝트

 

이후 타겟 프로젝트의 build.gradle 에서 해당 jar 를 의존성으로 추가해줘야 한다.

implemetation files(jar 파일 경로) 로 추가할 수 있다.

추가 이후 gradle reload 를 꼭 해주자, 의존성 인식을 시켜줘야 하기 때문이다

 

 

이제 테스트할 수 있는 Controller 생성 후 테스트를 진행 해보도록 하겠다.

Test Rest Controller

 

Request Filter Test

Calculator Test

Console log

우리가 동작하길 바랬던 대로, 라이브러리들의 기능들이 정상 작동하는것을 확인 할 수 있다.

 

다음 포스팅에서는 라이브러리 구성때 좀 더 고급 기능들을 포스팅할 예정입니다.

spring 팀, 다른 major 라이브러리들의 소스(깃헙)에서 먼저 보고 공부해보는것도 좋은 방법인듯 합니다.