우테코에서 주어진 첫번째 Level4 미션. WAS 구현하기.

고민했던 내용들을 정리해보도록 하겠습니다.

책임의 분리

가장 먼저 생각했던 건 WAS가 정확하게 무슨 일을 해주느냐? 였습니다.

1. Socket으로 부터 들어온 요청을 읽어 요청 객체를 생성한다.
2. 요청 객체와 사용자 코드를 바탕으로 적절한 Handler를 찾는다.
3. 요청 객체와 Handler를 바탕으로 적절하게 Parameter를 Binding 한다.
4. Handler와 Parameter를 바탕으로 Handler를 실행한다.
5. Handler 실행 결과를 통해 응답 객체를 생성한다.
6. 응답 객체를 바탕으로 적절한 View를 찾는다.
7. 응답 객체와 View를 바탕으로 Socket을 통해 응답을 반환한다.

가장 먼저 7가지 책임이 떠올랐고, 해당 책임을 RequestHandler에서 생성 및 수행하도록 리팩토링 해봤습니다.

1. Socket의 Reader로 읽은 정보를 통해 ServletRequest 생성
2. 해당 Request의 Path를 통해 View가 존재하면 Mapping 과정 생략 후 즉시 View Resolving
3. 사용자 Controller를 바탕으로 Handler Mapping
4. Handler와 MessageConverter를 통해 Handler 실행
5. ServletResponse를 Socket Output으로 전송

잘뜹니다.

하지만 객체지향의 설계원칙에 따라 부족한 부분에 대해서 생각해봅시다.

1. 객체 생성과 연관관계를 설정하는 책임과, 각 객체들을 실행하는 컨텍스트 책임, 둘 다 RequestHandler가 해주고 있습니다. 이 책임은 분리되어야 합니다.
2. 각 객체들이 클래스 의존관계를 가지고 있습니다. 상황에 따라 모두 변할 수 있으므로 해당 클래스들을 모두 인터페이스 의존관계를 통해 변경에 유연한 구조를 가져야 합니다.
3. view가 있는 요청과 없는 요청을 판단하고, 그에 따라 결과를 반환하는 로직이 RequestHandler에 있습니다. RequestHandler는 각 객체들을 실행하는 컨텍스트 역할을 해야합니다.

관심사 분리

시간이 지남에 따라 모든건 변한다. 개발자는 항상 미래에 대비해야 한다.

객체지향 기술이 변화에 효과적으로 대처할 수 있는 기술이다.

적은 변화와 변화에 대한 검증을 빠르게 하는 개발자.

분리와 확장을 고려한 설계가 필요하다

DB가 바뀌었을때, 웹 화면의 레이아웃이 바뀌었을때, 등등..

변화는 대체로 한 가지 관심에 대해 일어나지만 그에 따른 작업은 집중되지 않는 경우가 많다. → 변화에 대한 변경이 한 가지에 집중해서 일어나야 한다. 즉 관심이 같은 것 끼리는 모으고 관심이 다른 것은 분리해낸다.

관심사 분리

커넥션 만들기 추출

• DB Connection 가져오기 관심
• 사용자 등록 SQL 실행 관심
• Resource Close 하는 관심

변경사항에 대한 검증: 리팩토링과 테스트

두번째 실행부터 예외가 터진다. PK이기 때문에. → DB를 삭제해주고 다시실행하면 동작한다.

이런 과정을 리팩토링이라고 하고, 메소드 추출 기법이라고 한다.

N사와 D사가 서로 다른 DB를 사용한다면, DB커넥션을 가져오는 방법 또한 변경될 가능성이 있다. UserDao 소스코드를 제공하지 않는다면 어떻게 해야할까.

상속을 통한 확장

어떻게 데이터를 등록하고 가져올지에 대한 관심 → UserDao

어떻게 Connection을 가져올지에 대한 관심 → NUserDao, DUserDao

로 분리한다. 이는 변경이 용이하다 뿐만 아니라 손쉽게 확장된다라고 볼 수 있다.

이를 템플릿 메소드 패턴이라고 한다.

서브클래스에서 구체적인 오브젝트 생성 방법을 결정하게 하는것을 팩토리 메소드 패턴이라고 부르기도 한다.

상속을 사용했다는 단점. 이미 UserDao가 상속중이라면? 상속은 상하위 클래스의 관계가 너무 밀접하다.

슈퍼클래스의 변화가 서브클래스의 변화를 초래하게 됨. DB 커넥션 코드를 다른 곳에서 못쓰게됨 (서브클래스를 다른데서 못씀)

1.3 DAO의 확장

데이터 엑세스 로직 → DB 커넥션 분리

변화의 성격이 다르다면. 변경되면 안된다.

1. 메소드 분리를 통해 관심사를 분리했다
2. 상속을 통해 상하위 클래스로 분리했다
3. 아예 독립된 클래스로 만들어보자.

SimpleConnectionMaker방식의 문제점

직접 UserDao에서 생성해서 사용하므로 N사 D사에 따라 다른 클래스의 다른 메서드의 다른 타입을 사용할 수 없게 된다.

1. D사 ConnectionMaker에서는 메서드명이 openConnection()이라면?
2. UserDao가 SimpleConnectionMaker에 대한 정보를 알아야 한다는 점 → N사에서 다른 클래스를 쓰면 다시 고쳐야함

이런 문제는 Connection을 가져올때 너무 많이 알고있기 때문

인터페이스 도입

ConnectionMaker → NConnectionMaker, DConnectionMaker

UserDao에서 NConnectionMaker()를 생성해서 사용하는 방식 → 아직도 Connection에 대한 지식이 남아있다.

관계설정 책임의 분리

왜 UserDao가 인터페이스가 아닌 구현체를 알고있어야 하는가?

→ 아직도 어떤 ConnectionMaker를 사용할지를 결정하는 관계 설정의 대한 관심을 가지고 있다.

즉 UserDao와 ConnectionMaker 특정 구현체와의 관계를 설정해주는 것에 관한 관심이 남아있다.

클라이언트는 사용하는 오브젝트. 사용되는 오브젝트는 서비스. 클라이언트 오브젝트는 관계를 결정해주는 기능(책임)을 맡기 적절한 곳이다.

오브젝트 사이 관계는 런타임에 한 오브젝트가 다른 오브젝트의 레퍼런스를 갖는 방식으로 만들어진다.

외부에서 만들어 준 것을 가져오는 방식. 파라미터로 제공받은 오브젝트는 이용만 하면된다. 다른건 신경 x

클래스간 관계는 코드로 드러난다. 오브젝트간 관계는 런타임에 드러난다. 코드에서는 특정 클래스를 모르더라도 사런타임에 들어오므로 사용가능하다 → 다형성을 통해

UserDao 클라이언트는 ConnectionMaker 구현 클래스를 선택하고, 생성해서, 연결해준다. → Main 메소드

원칙과 패턴

SOLID

• 단일 책임 원칙 : 하나의 클래스는 단 한가지의 변경이유만을 가져야한다. → 응집도 (책임은 변경의 이유)
• 개방 폐쇄 원칙 : 클래스나 모듈은 확장에 열려있고 변경에는 닫혀 있어야 한다. → 변경을 예측하라. 첫번째 총알은 그냥맞고 그다음부터 적용한다.
• 리스코프 치환 원칙 : A를 B로 모두 치환 가능하면 A는 B의 하위타입이다. → 인터페이스의 관점으로 확대
• 인터페이스 분리 원칙: 클라이언트가 자신이 이용하지 않는 메서드에 대해 의존하지 않아야 한다는 원칙. 즉 메소드의 변경이 이 메소드를 사용하지 않는 클라이언트에 영향을 줄 때 인터페이스로 분리해야한다.
• 의존관계 역전 원칙 : 상위 수준 모듈은 하위수준 모듈에 의존하면 안된다. 둘 모두 추상화에 의존해야한다.

높은 응집도와 낮은 결합도

• 응집도가 높다는 것. 변경에 대해 모듈에서 변화는 부분이 크다는 것. 여러 관심사와 책임이 얽혀있는 코드는 응집도가 낮다.
• 결합도가 낮다는 것. 책임과 관심사가 다른 오브젝트와는 느슨한 연결 형태를 유지한다는 것. 관계를 유지할땐 최소한의 방법으로 간접적으로. 결합도란 하나의 오브젝트의 변화가 일어날 때 관계를 맺고있는 오브젝트에게 변화를 요구하는 정도 라고 보면 된다.

전략 패턴

전략 패턴은 자신의 기능 맥락에서 필요에ㄷ 따라 변경이 필요한 알고리즘을 인터페이스를 통해 통째로 외부로 분리시키고 구현체를 필요에 따라 바꿔서 사용할 수 있게 하는 디자인 패턴.

public class UserDao {
    private ConnectionMaker connectionMaker;
    public UserDao(ConnectionMaker connectionMaker){
        this.connectionMaker = connectionMaker;
    }

    public User get(String id){
        Connection connection = connectionmaker.getConnection();
        ...
    }
}

DB연결 방식이라는 알고리즘을 ConnectionMaker 인터페이스로 정의하고 구현체를 바꿔가면서 사용할 수 있게 분리했다.

또한 메인메서드와 같은 클라이언트의 필요성 또한 설명해준다. 전략 패턴을 적용 시 클라이언트는 컨텍스트가 사용할 전략을 컨텍스트의 생성자 등을 통해 제공해준다.

1.4 제어의 역전(IoC)

Main 메서드는 어떤 ConnectionMaker 구현체를 사용할지를 결정하는 기능을 떠맡았다.

팩토리

객체의 생성 방법을 결정하고 그렇게 만들어진 오브젝트를 돌려주는 역할을 하는 클래스를 만들어보자. 이런 오브젝트를 흔히 팩토리라고 부른다.

컴포넌트의 구조와 관계를 정의한 설계도 같은 역할을 한다.

제어의 역전이라는 건 프로그램의 제어 흐름 구조가 뒤바뀌는 것.

일반적으로 메인 → 오브젝트 생성 → 메소드 호출 → 메소드 안에서 오브젝트 생성 → 메소드 안 메소드 호출

이런 흐름에서 각 오브젝트는 프로그램 흐름을 결정하거나 사용할 오브젝트를 구성하는 작업에 능동적으로 참여한다. 즉 모든 종류의 작업을 사용하는 쪽에서 제어하는 구조. 생성해서 사용

제어의 역전에서는 오브젝트가 자신이 사용할 오브젝트를 스스로 선택하지 않는다. 당연히 생성하지도 않는다. 모든 제어 권한을 다른 대상에게 위임한다. 모든 오브젝트는 위임받은 오브젝트에 의해 결정되고 만들어진다.

프레임워크는 라이브러리가 아니다. 프레임워크는 흐름을 주도하고 개발자가 만든 코드를 사용하는 방식으로 동작한다.

기존 ConnectionMaker 구현 클래스를 결정하고 만드는 제어권은 UserDao에 있었으나 DaoFactory로 옮겨갔다. 자신이 어떤 ConnectionMaker 구현 클래스를 사용할 지에 대한 권한을 DaoFactory에게 넘김으로써 UserDao는 수동적인 존재가 되었다.

제어의 역전에서는 컴포넌트의 생성과 관계설정, 사용, 생명주기 관리 등을 관장하는 존재가 필요하다. DaoFactory는 가장 단순한 IoC 컨테이너로 불릴 수 있다.

1.5 스프링의 IoC

스프링에서 빈의 생성과 관계설정 같은 제어를 담당하는 IoC 오브젝트를 빈 팩토리라고 부른다. (어플리케이션 컨텍스트라고도 한다.)

우리가 작성한 DaoFactory가 빈 팩토리의 설정 정보가 된다.

@Bean 메소드 이름은 빈 이름이 된다. 이름이 필요한 이유는 생성 방식이 다르게 될 수 있기 때문.

애플리케이션 컨텍스트 동작방식

DaoFactory가 Dao 오브젝트를 생성하고 관계를 맺어주는 녀석이였다면, 애플리케이션 컨텍스트는 IoC를 적용해서 관리할 모든 오브젝트에 대한 생성과 관계설정을 담당한다.

애플리케이션 컨텍스트는 @Configuration을 통해 설정정보를 등록해놓고 @Bean을 통해 메소드 이름을 가져와 빈 목록을 만들어 둔다.

애플리케이션 컨텍스트를 사용하는 이유

• 클라이언트가 구체적인 팩토리 클래스를 알 필요가 없다 → 좀 더 일관된 방법으로 빈을 가져올 수 있다.
• 종합 IoC 서비스를 제공해준다 → 오브젝트가 만들어지는 방식을 다양하게. 효과적으로 오브젝트를 활용
• 빈을 검색하는 기능 제공

스프링 용어 정리

• 빈: IoC방식으로 관리하는 오브젝트
• 빈 팩토리 : IoC 핵심 컨테이너. 빈 등록, 생성, 조회, 관리
• 애플리케이션 컨텍스트 : 빈 팩토리를 확장한 IoC 컨테이너. 스프링의 각종 부가 서비스를 제공한다
• 설정정보 설정 메타정보 : 애플리케이션 컨텍스트가 IoC를 적용하기 위해 사용하는 메타정보.
• 컨테이너 : 다 비슷
• 스프링

싱글톤 레지스트리와 오브젝트 스코프

애플리케이션 컨텍스트는 싱글톤을 저장하고 관리하는 싱글톤 레지스트리. 정상적인 자바 객체를 싱글톤으로 활용하게 해준다.

싱글톤과 오브젝트의 상태

멀티스레드 환경에선 상태관리에 주의를 기울여야 한다. 서비스 형태의 오브젝트로 사용되는 경우 무상태 방식으로 만들어져야 한다. 필드가 아닌 파라미터, 로컬변수, 리턴값 등을 활용해야한다.

물론 필드가 싱글톤이거나 읽기전용이라면 가능하다. 한번 초기화해주고 나면 수정되지 않기 때문.

빈의 스코프

스프링 빈의 기본 스코프는 싱글톤이다. 강제로 제거하지 않는 한 컨테이너가 존재하는 동안 계속 유지된다.

(프로토타입 스코프는 매번 새로 만들어준다) (Request Scope가 있다) (Session 스코프도 있다)

의존관계 주입(DI)

IoC는 일반적인 개념. 객체를 생성하고 관계를 맺어주는 등의 작업을 담당하는 기능을 일반화한것이 IoC 컨테이너

IoC는 너무 포괄적인 개념이라, 스프링은 IoC 방식의 핵심인 의존관계 주입 이라는 의도가 명확히 드러나는 이름을 사용하기 시작했다.

DI는 오브젝트를 외부로부터 주입받아 다이나믹한 의존 관계를 만드는게 핵심

의존관계

A가 B에 의존한다면, B가 변하면 A에 영향을 미친다. A가 변해도 B는 영향을 받지 않는다.

UserDao는 ConnectionMaker에 의존한다. ConnectionMaker 인터페이스가 변경된다면 UserDao는 영향을 받을것이다. 그러나 ConnectionMaker는 인터페이스임. 추상클래스 NConnectionMaker가 변경되더라도 UserDao엔 직접적인 영향을 미치지 않는다. → 인터페이스에 대해서만 의존관계를 만든다면, 실제 구현클래스와의 관계는 느슨해지고, 변화에영향을 덜받게 된다. 결합도가 낮아진다.

런타임 시에 의존관계를 맺는 대상을 의존 오브젝트라고 말한다.

의존관계 주입이란

• 클래스나 코드에서 런타임 시 의존관계가 드러나지 않는다. 인터페이스에만 의존하고 있는다.
• 런타임 시 의존관계는 컨테이너나 팩토리같은 제 3자가 결정한다.
• 외부로부터 의존 오브젝트를 주입받음으로써 의존관계가 만들어진다.

DI의 핵심은 관계를 맺도록 도와주는 제 3자가 있다는점. → 관계설정 책임을 분리해낸 오브젝트. DaoFactory나 IoC 컨테이너등.

DaFactory는 런타임 의존관계 설정해주는 역할, IoC 방식의 오브젝트 생성 초기화 제공.

→ DI를 담당하는 컨테이너. DaoFactory는 일종의 IoC/DI 컨테이너

DI는 자신이 사용할 오브젝트에 대한 선택, 생성제어를 외부로 넘기고 자신은 수동적으로 주입받은 오브젝트를 사용한다. IoC의 개념과 거의 동일하다.

의존관계 검색

자신이 필요한 의존 오브젝트를 능동적으로 찾는다. 어떤 클래스가 아닌.

getBean을 통해 의존관계를 검색하여 가져온다.

의존관계 검색은 차이점이 주입받는 녀석이 빈일 필요는 없다.

부가기능 추가

Proxy처럼 사용

메소드를 이용한 DI

Spring Rest Docs의 특징

Spring Rest Docs로 작성된 문서

Spring Rest docs는 Test 기반으로 동작합니다. 테스트 코드에 추가함으로써 문서가 작성돼요. 따라서 Production 코드에 영향을 미치지 않는다는게 큰 장점입니다. 테스트 기반이기 때문에 테스트가 수행되지 않으면 문서 또한 작성되지 않아요. 따라서 문제가 있는 경우엔 문서또한 작성되지 않는다는 장점(?)이 있죠. (물론 테스트가 수행되지 않는 서비스에 대해서도 문서를 보고싶은 사람도 있겠지만요.) 또한 문서 본연의 기능에 충실합니다.

하지만 테스트 기반으로 설계된 서비스가 아니라면, 사용이 불가능합니다. 또한 추가적인 설정들을 적용하기가 쉽지 않다는 단점을 가지고 있어요. 또한 사진에서 보시는 것 처럼 문서가 그렇게 이쁘지 않아요😅

마지막으로 엔드 포인트마다 수많은 코드를 추가해줘야 한다는 단점이 있습니다. 반복성 작업을 해야해서 굉장히 힘들었습니다😭 중복을 제거하려면 좀 더 고민을 해봐야겠어요.

Swagger의 특징

Swagger로 작성된 페이지

Spring Rest Docs와 반대로 Open Api로 작성된 문서는 Swagger UI를 통해 알록달록 굉장히 이쁩니다. 또한 의존성만 추가해도 이런 인터페이스를 한번에 제공하죠. 그리고 실제 API를 테스트하는 기능 또한 제공해요. 만약 Admin Page가 없다면, 이런 기능을 유용하게 사용할 수 있을 것 같아요!

API 테스트 해보기

심지어 작성된 객체의 필드도 보여준다..!

하지만 지금까지의 Swagger는 문서화 도구보단 API 테스터에 가까워요. 원하는 엔드포인트나 필요한 리소스들에 대한 설명은 어떻게 추가해줘야 할까요?

@Operation(summary = "Get a book by its id")
@ApiResponses(value = { 
  @ApiResponse(responseCode = "200", description = "Found the book", 
    content = { @Content(mediaType = "application/json", 
      schema = @Schema(implementation = Book.class)) }),
  @ApiResponse(responseCode = "400", description = "Invalid id supplied", 
    content = @Content), 
  @ApiResponse(responseCode = "404", description = "Book not found", 
    content = @Content) })
@GetMapping("/{id}")
public Book findById(@Parameter(description = "id of book to be searched") 
  @PathVariable long id) {
    return repository.findById(id).orElseThrow(() -> new BookNotFoundException());
}

프로덕션 코드에 직접 어노테이션을 추가하는 방식으로 문서화를 구현할 수 있어요. 결과는 다음과 같죠.

보시다시피 프로덕션 코드에 문서화와 관련된 코드가 추가된다는 점이 OpenApi의 단점이 아닐까 싶어요. 예제 코드만 보더라도 가독성이 굉장이 떨어지고, 실제 컨트롤러는 어디서부터 시작되는지 조차 파악하기 어렵죠. 또한 객체 지향의 관점에서도 컨트롤러에 문서화라는 역할이 추가되는 느낌이에요.

또한 테스트가 정상적으로 동작하지 않아도 문서가 작성된다는 문제점등이 있을 것 같아요.

정리

정리해보자면 각 장단점은 이렇게 될 것 같아요. 본인의 서비스에 맞게 선택하셔서 사용하는게 가장 좋을 것 같습니다!

Spring Rest Docs

Swagger

출처

우아한 형제들 기술블로그 Baeldung Swagger

Spring Data JPA는 Java ORM 표준 JPA와 Hibernate로 만들어진 프레임워크입니다. 대부분의 Java 개발자들은 JPA를 공부하고 사용합니다.

구글 트렌드에서 본 대한민국의 Data JPA와 Data JDBC 검색량

하지만 Spring에는 새로운 ORM인 Spring Data JDBC 또한 존재합니다. 이미 광범위하게 사용하는 JPA와 어떤 차이점이 있을까요?

JPA는 복잡하다

보통 JPA를 학습하기 전에 러닝 커브(learning curve)가 높다고들 이야기 합니다. 다음에 나와 있는 JPA의 특징들이 복잡하기 때문이죠.

• Lazy Loading
• Dirty Checking
• Session / 1st Level Cache
• Proxy
• M to x Mapping

Lazy Loading (Exception)

코드만 보고 파악하기 힘든 Exception입니다. 코드가 복잡해질수록 지연 로딩으로 가져오는 객체가 어느 시점에 초기화되는지 알기 힘듭니다. 또한 코드만으로 다음에 어떤 SQL 문이 발생할지 예상하기 힘들다는 문제도 있죠.

Dirty Checking

Entity Manager에 save를 하는데, 원치 않은 save가 발생할 수 있습니다. 그냥 테스트를 위해 객체를 조작하고 싶어도, 저장까지 되는 문제가 발생합니다. 특정 객체만을 제외하고 저장하고 싶은 경우에도 복잡한 원리를 이해해야만 합니다.

Session / 1st Level Cache

영속성 컨텍스트로 인해 항상 같은 객체만을 사용합니다. DB로부터 불러온 데이터와 조작한 객체를 가지고 비교하는 연산 등을 힘들게 합니다.

Proxy

엔티티 간 비교 시 프록시인지 아닌지를 확인해야만 하는 경우가 생깁니다. 이 경우 어떤 객체가 프록시이고 아닌지 판단하기 어렵죠.

M to x Mapping

M 대 N 연관관계는 다양한 문제를 야기하고 예측할 수 없습니다.

Simple is King

Complexity의 반대는 뭘까요? Simple입니다. Spring Data JDBC의 특징은 단순함입니다.

• No lazy loading
• No Session(Caching)
• No Proxies
• No Flushing : save와 동시에 Query (쓰기 지연 저장소가 없음)
• No Many to x Relation

Spring Data JDBC는 Domain Driven Design을 기반으로 합니다. 따라서 모든 Repository는 Aggregate Root 기준으로 존재합니다. 라이프사이클 또한 Aggregate Root와 하위 속성들이 동일합니다. 서로 다른 Aggregate 간 참조는 Id를 통해 수행합니다. 이러한 개념이 코드를 통해 알기 쉽게 설계되어있습니다.

Spring Data JDBC는 지연 로딩이 없고 항상 즉시 로딩 전략을 사용합니다. Aggregate는 항상 완전한 상태라는 걸 보장받을 수 있죠. Lazy Loading Exception 또한 고민할 필요가 없습니다. 하지만 불필요한 데이터까지 함께 가져오는 단점이 있습니다. 이 부분에 대한 자세한 설명이 없지만, 발표에서는 JPA에서도 fetch type을 Eager로 설정하면 발생하는 버그니까 대수롭지 않다는 듯이 넘어가더군요..😂

JPA에서 굉장히 효율적이라고 생각했던 기능인 Flushing도 없습니다. 소스 코드만으로 Flushing에서 생성될 Query문은 예측하기 매우 까다롭습니다. 이런 부분에서 Spring Data JDBC는 직관적으로 다가옵니다.

마지막으로 대망의 연관관계입니다. Spring Data JDBC는 일대다 혹은 일대일 단방향 관계만을 추구합니다. 사실, 테이블 설계 과정에서 M to X 연관 관계는 피하려 해도 피할 수 없는 녀석이죠. Spring Data JDBC는 이러한 부분을 ID 참조로 피해갑니다.

게시판의 회원, 게시글, 댓글을 기준으로 고려해보면, Article과 Account는 M to 1 연관 관계입니다. 보시는 것처럼 accountId로 단순한 Long 값만을 가지고 있는 걸 보실 수 있습니다.

반대로 Article과 Comment는 1 to M 관계입니다. 기본적으로 Set을 사용하여 연관 관계를 표현하죠. 하지만 서로 다른 Aggregate Root인 경우 ID 참조를 통해 연관 관계를 표현해야 하므로 Ref 테이블이 생기죠. DDD의 개념을 코드에서 그대로 드러나게 됩니다.

결론

Spring Data JDBC는 아직 완성되지 않은, 지속적으로 개선되어가는 프레임워크입니다. Derived Query나 Soring & Paging도 얼마전 2.0.0버전부터 지원하게 되었죠. 성능적으로 JPA에 비해 비효율적인 부분이 많지만, 직관적인 Spring Data JDBC가 굉장히 매력적인 ORM이라고 생각합니다. Naver의 Spring Data JDBC Plus 프레임워크에 대해서도 설명해 드리고자 했으나 내용이 너무 길어질 것 같아서 다음 글에서 다뤄보도록 하겠습니다.

해당 내용은 Pivotal 사의 발표1, 발표2를 바탕으로 작성했습니다.

시작

시작은 중학교 2학년 때.. 아버지께서 가져오신 삼성 노트북이 내 꿈을 결정했다. 당시 웹하드(온디스크, 파일노리..)가 유행이었는데 '메이플 프리서버 만드는 방법'이라는 파일을 보고 바로 다운로드했다. 밤을 새워 메이플 스토리란 게임의 프리(가짜) 서버를 만들었다. 같은 반 친구들이 하나둘씩 접속하기 시작한다. 그 당시 유행하던 네이트온, 웹 디스크, 네이버 카페 등등.. 친구들이 친구들을 불러모으고 그 친구들이 형, 동생들을 불러모은다. 어느새 수백, 수천 명의 사람들이 내가 만든 게임을 이용한다. 피드백이 들어오면 밤새도록 알지도 못하는 js파일을 메모장으로 수정해 나간다. 카페에 회원들이 고맙다고 글을 올려준다.

이 순간 난생처음 성취감이란걸 느꼈다.

방황.. 그리고 깨달음

초등학생 때 공부를 꽤 잘하는 편에 속했다. 중학교 1학년 때도 마찬가지였고. 그러나 부모님은 그보다 더 잘하길 원했고, 1등이 아니면 인정해주지 않으셨다. 중학교 1학년 때 꽤 좋은 성적이 나와서 부모님께 자랑했다가 오히려 혼난 적이 있었다. 그 사건 이후 공부를 해야 할 동기를 얻지 못했다. 학교도 안 가며 방황하기 시작했다. 그러던 시점에 만나게 된 게 프로그래밍이었다.

프리서버를 만들고 나서 내 삶의 목표 의식이 생겼다. 성취감을 추구하며 살자. 사람은 성취감을 얻기 위해 살아가는구나. 이 생각은 27살인 지금도 마찬가지이다. 프로그래밍을 공부하기 위해선 대학을 가야 한다는 생각에 학교 공부도 다시 시작했다. 재수까지 해서 컴퓨터 공학과에 진학했다.

또 다른 방황.. 똑같은 깨달음

사실 컴퓨터공학과는 내가 상상한 곳은 아니었다. 개발보단 공학을 배우는 곳이었다. 만들고 싶은 걸 만드는 곳이 아니라, 이미 만들어진 걸 똑같이 만들 수 있는지 테스트하는 곳이었다. 다시 절망을 느끼고 방황하기 시작했다. 우아한 테크코스를 만나고, 개발에 대한 열정을 다시 확인할 수 있었다.

백엔드라는 단어가 무슨 뜻인지도 모른 채로 우아한 테크코스에 들어갔다. 사실 자바도 들어가기전 학교에서 수업으로 들었던 것뿐, 아는 게 없었다. 하지만 우테코에서 진정한 개발에 대해 배웠다. 원하는 걸 만들기 위해 배워야 하는 것들을 배웠다. 필요한 걸 얻기위해 공부하는 법을 배웠다. 매 순간의 배움의 연속이었다.

Peloton 이라는 서비스를 결과물로 얻었다. 사실 아쉬운 점도 많고 부족한 점도 많다. 하지만 대학 생활 전체를 다 합쳐도 얻지 못할 성취감을 얻게 되었다. 개발이 더 좋아졌다. 중학교 2학년의 얻은 깨달음이 틀리지 않았다는 걸 증명해냈다. 성취감이 나를 성장시킨다는 사실을.

나는

성취감을 위해 발버둥 치는 개발자, 성취감을 위해 어떤 공부도 가리지 않는 개발자 그리고 항상 성취해내는 개발자가 되고 싶다.

Spring Data Jdbc의 Save 방식

Spring Data Jdbc의 Save는 기본적으로 ID가 있는 Entity 객체에 대해선 Update를 수행하고 ID가 없는 Entity에 대해선 INSERT를 수행합니다. 이게 어떻게 동작하는 걸까요?

위 메서드는 CrudRepository가 사용하는 JdbcAggregateTemplate 입니다. MappingContext에서 Save요청으로 들어온 인스턴스를 꺼내, isNew항목에 따라 체크하여 create또는 update를 수행합니다.

Id가 있는 Entity 저장

저는 ID가 있는 경우에도 Save를 하기 위해 Insert 인터페이스를 만들어서 사용하기로 했습니다.

제가 Insert하고 싶었던 엔티티는 대략 다음과 같습니다.

해당 엔티티 객체에 아이디를 넣고 생성하려던 찰나, 다음과 같은 에러가 터지더군요.

CREATED_AT 칼럼은 분명히 Auditing을 통해 자동 주입 될텐데 어째서 null이 나오는 걸까요? 해당 문제의 범인을 찾기위해 열심히 Call Stack을 뒤져보던 찰나 이런 녀석을 발견했습니다.

entity의 isNew 값이 true가 아니면 Created라고 판단하지 않아 createdAt 값이 Auditing되지 않은 것이 였습니다. 그렇다면 이 isNew 값은 어떻게 설정되는 걸까요?

PersistentEntityIsNewStrategy 클래스에서 이 값을 설정하는 전략을 선택하는데, 간단히 요약하자면, 엔티티 필드에 @Version 값 또는 @Id 값을 확인하여, 그 값이 0 또는 null이면 isNew가 true로 나오는 방식입니다.

따라서 id가 null이 아니라면, isNew는 항상 false가 나와, save를 해도 update가 수행되고, @createdDate auditing도 정상적으로 이루어지지 않는 것입니다.

해당 문제를 해결하기 위해, WithInsert가 아닌, Persistable을 implement하는 방식으로 다시 구현을 해보았습니다.

Persistable을 통해 isNew를 직접 Setting 해준다면, 원하는 아이디로 저장이 가능합니다. Auditing 또한 정상적으로 동작하죠. 하지만, 저장 이후에 isNew를 false로 초기화 해주기 위해선 라이프사이클 이벤트나 콜백을 통해 제어해주어야 되는 번거로움이 있겠네요.

이 방법 이외에 라이프사이클 이벤트를 통해 원하는 아이디를 주입해주는 방법과 @Version을 사용하는 방법도 있습니다. 다음 글에선 라이프사이클 이벤트를 다뤄보고 싶네요

마치며

Spring Data Jdbc는 공부할수록 매력적인 프레임 워크인 것 같아요. 단순하고 직관적이죠. 하지만 항상 이렇게 생각하고 쉽게 접근하려다가 딜레마에 빠진 경우가 많은 것 같아요. 아직도 Spring Data Jdbc에 적응하진 못했나 봅니다 😭 공부를 충분히 하고나서 훗날 많은 성장을 이룬다면, Data JPA와 Data JDBC를 비교해보는 글을 써보고 싶네요.
긴 글 읽어주셔서 감사합니다😊

log4j2.xml

이전 글에서 log4j 2 설정파일을 보여드렸는데요, 각각의 요소가 뭘 의미하는지 알아보도록 할게요

Configuration

<Configuration status="INFO">

Configuration은 로그 설정의 최상위 요소입니다. 일반적으로 Configuration은 Properties, Appenders, Loggers요소를 자식으로 가집니다. status 속성은 log4j의 내부 이벤트에 대한 로그 레벨을 의미합니다. 또한 Configuration의 추가 속성은 링크에서 확인하실 수 있습니다.!

Properties

<Properties>
    <Property name="logNm">Spring Log4j2 Test</Property>
    <Property name="layoutPattern">%style{%d{yyyy/MM/dd HH:mm:ss,SSS}}{cyan} %highlight{[%-5p]}{FATAL=bg_red, ERROR=red,
            INFO=green, DEBUG=blue}  [%C] %style{[%t]}{yellow}- %m%n -</Property>
</Properties>

Properties는 해당 Configuration 파일에서 사용할 프로퍼티를 의미합니다. 변수라고 생각하시면 편해요😊. 저는 logNm으로 로그 이름을 설정했고, layoutPattern으로 로그의 패턴을 설정해 놓았습니다. name 속성의 값이 key, 태그 내의 값이 value가 됩니다.

Layout

Appender는 로그 이벤트를 Layout을 통해 포매팅합니다. Appender가 받은 로그 이벤트를 Layout에게 전달하면, byte 배열을 반환합니다. Charset을 지정해주면 확실한 값을 얻을 수 있습니다.

PatternLayout

%style{%d{yyyy/MM/dd HH:mm:ss,SSS}}{cyan} %highlight{[%-5p]}{FATAL=bg_red, ERROR=red,
            INFO=green, DEBUG=blue}  [%C] %style{[%t]}{yellow}- %m%n -

설정파일에 주어진 패턴대로 로그를 출력한 결과입니다. 날짜 포맷, 색깔, 출력 요소 등을 결정할 수 있죠. C언어의 printf 문 처럼 PatternLayout은 Format문자를 사용합니다. 각 의미는 다음과 같습니다.

• %c, %logger : 해당 로그를 쓰는 로거의 이름.
• %C, %class : 해당 로그를 요청한 클래스 이름
• %d, %date : 해당 로그가 발생한 시간
• %enc, %encode : 특정 언어에서의 출력을 위한 문자 인코딩
• %ex, %exception, %throwable : 예외 로그. 길이를 설정할 수 있음.
• %F, %file : 해당 로그가 발생한 클래스 파일명
• %l, %location : 해당 로그가 발생한 클래스명.메소드명(파일:라인)
• %L, %line : 해당 로그가 발생한 라인 번호
• %m, %msg, %message : 로그문에 전달된 메시지
• %n : 줄바꿈
• %p, %level : 로그 레벨
• %r, %relative : 로그 처리시간
• %t, %thread : 해당 로그가 발생한 스레드명
• %style{pattern}{ANSI style} : ANSI를 사용해 특정 패턴을 스타일링함
• %highlight{pattern}{style} : 로그 레벨명을 ANSI 색깔로 하이라이트

정말 많지만..😭 한 번쯤 공부해봐야 깔끔한 로그를 작성하실 수 있을거에요. 필요한게 생길때마다 링크에 들려서 익숙해지시면 될 거에요! 그 밖에 HTML Layout과 JSON Layout 등 여러 레이아웃이 있지만 우선 PatternLayout만 알고 넘어가도 됩니다! 궁금하시다면 위 링크에서 찾아보실 수 있을거에요!

Appenders

Appender는 log 메세지를 특정 위치에 전달해주는 역할을 하는 녀석입니다. Appender는 layout을 통해 로그를 formatting 하고, 어떤 방식으로 로그를 제공할지 결정합니다. Appender에는 여러 종류가 있습니다.

• ConsoleAppender
• RollingFileAppender
• AsyncAppender
• FileAppender
• JDBCAppender
• SMTP
• ...

저는 여기서 ConsoleAppender와 RollingFileAppender에 대해 설명드리겠습니다.

ConsoleAppender

<Console name="Console_Appender" target="SYSTEM_OUT">
    <PatternLayout pattern="${layoutPattern}"/>
</Console>

Console Appender는 말 그대로 Console에 system.out 으로 로그를 출력하는 Appender입니다. 로그 출력 포매팅은 PatternLayout 방식으로 위에서 제가 설정한 Pattern 대로 로그를 출력합니다. ConsoleAppender가 갖는 속성은 다음과 같습니다.

• layout : 출력 레이아웃 양식
• name : Appender 이름
• target : 출력 방식. 기본값은 SYSTEM_OUT, SYSTEM_ERR로 출력가능

RollingFileAppender

<RollingFile name="File_Appender" fileName="logs/${logNm}.log" filePattern="logs/${logNm}_%d{yyyy-MM-dd}_%i.log.gz">
    <PatternLayout pattern="${layoutPattern}"/>
    <Policies>
         <SizeBasedTriggeringPolicy size="200KB"/>
         <TimeBasedTriggeringPolicy interval="1"/>
    </Policies>
    <DefaultRolloverStrategy max="10" fileIndex="min"/>
</RollingFile>

로그가 한 파일에 계속 저장된다면, 파일이 너무 커져서 실행이 불가능해질 수도 있고, 파일에 문제가 생기면 로그 전부를 날려버릴 수도 있습니다. RollingFileAppender는 이런 문제를 해결해 줍니다. 파일에 로그를 기록하고, 특정 기준에 따라 압축하여 저장하는 방식의 Appender입니다. Console Appender와 대표적으로 다른 부분은 File과 관련된 속성, Policy와 관련된 속성, Strategy와 관련된 속성 입니다.

1. Policy

policy는 File Rolling Up 기준입니다. 하나의 RollingFileAppender에는 여러 Policy를 적용할 수 있습니다.

• OnStartupTriggeringPolicy : jvm start시 trigger
• TimeBasedTriggeringPolicy : time에 따른 trigger
• SizeBasedTriggeringPolicy : file size에 따른 trigger
• CronTriggeringPolicy : Cron Expression(시간에 관한 표현)에 따른 trigger

이름처럼 각각의 policy들은 특정 조건에 따라 trigger됩니다. 주어진 예제는 로그파일이 200KB가 되는 시점과 하루 마다 logs/${logNm}%d{yyyy-MM-dd}%i.log.gz 패턴으로 압축되어 저장됩니다. 여기서 재밌는 점은 TimeBasedTriggeringPolicy의 interval은 파일 패턴의 날짜 단위의 최소값으로 계산된다는 점입니다. 만약 파일패턴의 날짜 포맷이 초단위까지 있다면, interval을 1로하면 1초에 한번씩 압축이 되는 셈입니다.

2. DefaultRolloverStrategy

DefaultRolloverStrategy는 datetime 패턴과 파일패턴의 int값을 받아서 결정됩니다. datetime은 현재 시간으로 대체되고, 파일 패턴 숫자는 db의 autoincrement처럼 rollover 마다 1씩 증가합니다. 예제의 filePattern을 보시면 %d{yyyy-MM-dd} 가 날짜 패턴, %i가 파일패턴의 int입니다. 각각 rollover 이후에는 다음과 같이 저장됩니다.

해당 Strategy에는 다음 속성을 부여할 수 있습니다.

• fileIndex : max로 설정 시 높은 index가 더 최신 파일이 됩니다. min으로 설정 시 작은 index가 최신 파일이 됩니다. 기존의 파일들을 rename하는 방식으로 동작합니다.

• min : counter 최소값. 기본값은 1입니다.

• max : counter 최대값. 만약 최대값에 도달하면 오래된 파일을 삭제합니다. 기본값은 7입니다.

• compressionLevel : 0~9까지 정수값. 0은 압축하지 않고, 1은 최고 속도, 9는 최고 압축입니다. ZIP파일만 가능합니다.

• tempCompressedFilePattern : 압축하는 동안의 파일 이름 패턴.

  사실 다른 전략도 있으니, 궁금하시다면 한 번 찾아보세요!

Logger

<Logger name="com.fucct.springlog4j2.loggertest" level="TRACE" additivity="false">
    <AppenderRef ref="Console_Appender" />
</Logger>

로거는 로깅을 직접 하는 요소입니다. 로거는 패키지 별로 설정할 수 있습니다. Root패키지의 로거는 필수적이고, 추가적인 로거는 Logger로 설정할 수 있습니다. 해당 로거는 loggertest 패키지에 해당하는 파일들에 대해서 TRACE이상의 로그를 Console에 남기는 로거입니다. 만약 RollingFileAppender를 추가하고 싶다면 다음과 같이 설정해주면 됩니다.

<Logger name="com.fucct.springlog4j2.loggertest" level="TRACE" additivity="false">
    <AppenderRef ref="Console_Appender" />
    <AppenderRef ref="File_Appneder" />
</Logger>

Additivity값은 중복된 로그를 남길 지에 대한 속성입니다. 로거 계층 구조를 아신다면 logger가 어떻게 할당하는 지 알 수 있습니다. 링크를 참고해주시면 로거에 대한 좀 더 깊은 이해를 하실 수 있습니다.

마치며

전달할 내용은 많은데, 재미가 없는 부분이 많아서 어떻게 전달할 지 고민이 되는 글이었네요. 어느 정도 내용까지 전달할 지 고민하다가, 우선 전 글의 예제에 대한 설명이 가능할 정도의 내용을 전달해 드렸습니다. 부족하다 싶은 부분은 공식 문서를 통해 보충하신다면, 로깅에 대해 완벽히 학습하실 수 있을 것 같아요! 글에 오류가 있다면 지속적으로 수정하겠습니다. 긴 글 읽어주셔서 감사합니다.

보통 개발 과정에서 실행 시 에러가 나면, 콘솔의 에러 로그를 찾아서 디버깅하고 다시 실행하기 마련이죠. 하지만 배포 환경이라면 어떨까요? 만약 배포 환경에서 에러가 난다면 콘솔의 로그를 찾는 것 만으로는 한계가 있을 거에요. 이처럼, 배포 환경에서의 로그는 개발 환경과는 다른 방식으로 처리되어야 하겠죠. 이번 글에서는 이러한 로깅을 도와주는 Log4j2를 다뤄보려고 합니다.

사용법

의존성

plugins {
    id 'org.springframework.boot' version '2.3.1.RELEASE'
    id 'io.spring.dependency-management' version '1.0.9.RELEASE'
    id 'java'
}

group = 'com.fucct'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '1.8'

configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-mail'
    implementation 'org.springframework.boot:spring-boot-starter-log4j2'
    testImplementation 'org.springframework.boot:spring-boot-starter-log4j2'
    implementation 'org.apache.logging.log4j:log4j-web:2.12.1'
    implementation 'com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.11.1'
    implementation 'com.lmax:disruptor:3.4.2'
    compileOnly 'org.projectlombok:lombok'
    runtimeOnly 'com.h2database:h2'
    developmentOnly 'org.springframework.boot:spring-boot-devtools'
    annotationProcessor 'org.projectlombok:lombok'
    testImplementation('org.springframework.boot:spring-boot-starter-test') {
        exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'
    }
}

configurations {
    all {
        exclude group: 'org.springframework.boot', module: 'spring-boot-starter-logging'
    }
}

test {
    useJUnitPlatform()
}

build.gradle

기본적으로 Spring은 Slf4j라는 로깅 프레임워크를 사용합니다. 구현체를 손쉽게 교체할 수 있도록 도와주는 프레임 워크입니다. Slf4j는 인터페이스고 내부 구현체로 logback을 가지고 있는데, 저는 Log4j 2를 사용하기 위해 exclude 했습니다.

설정 파일

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="INFO">
 <!--    해당 설정파일에서 사용하는 프로퍼티-->
    <Properties>
        <Property name="logNm">Spring Log4j2 Test</Property>
        <Property name="layoutPattern">%style{%d{yyyy/MM/dd HH:mm:ss,SSS}}{cyan} %highlight{[%-5p]}{FATAL=bg_red, ERROR=red,
            INFO=green, DEBUG=blue}  [%C] %style{[%t]}{yellow}- %m%n -</Property>
    </Properties>
  <!--    LogEvent를 전달해주는 Appender-->
    <Appenders>
        <Console name="Console_Appender" target="SYSTEM_OUT">
            <PatternLayout pattern="${layoutPattern}"/>
        </Console>
        <RollingFile name="File_Appender" fileName="logs/${logNm}.log" filePattern="logs/${logNm}_%d{yyyy-MM-dd}_%i.log.gz">
            <PatternLayout pattern="${layoutPattern}"/>
            <Policies>
                <SizeBasedTriggeringPolicy size="200KB"/>
                <TimeBasedTriggeringPolicy interval="1"/>
            </Policies>
            <DefaultRolloverStrategy max="10" fileIndex="min"/>
        </RollingFile>
    </Appenders>
  <!--    실제 Logger-->
    <Loggers>
        <Root level="INFO" additivity="false">
            <AppenderRef ref="Console_Appender"/>
            <AppenderRef ref="File_Appender"/>
        </Root>
        <Logger name="org.springframework" level="DEBUG"
                additivity="false">
            <AppenderRef ref="Console_Appender" />
            <AppenderRef ref="File_Appender"/>
        </Logger>
        <Logger name="com.fucct" level="INFO" additivity="false">
            <AppenderRef ref="Console_Appender" />
            <AppenderRef ref="File_Appender"/>
        </Logger>
        <Logger name="com.fucct.springlog4j2.loggertest" level="TRACE" additivity="false">
            <AppenderRef ref="Console_Appender" />
        </Logger>
    </Loggers>
</Configuration>

log4j2.xml

Log4j 2에선 설정파일을 Json, xml, yml등 다양한 방식으로 사용할 수 있습니다. 저는 jackson 의존성을 추가하고 싶지 않아서 xml을 사용했습니다. 해당 설정파일에 대해 알지 못해도 괜찮습니다. 다음 글에서 충분히 설명해드릴게요!😎 해당 설정을 log4j2.xml 로 지정하고, resources 패키지에 저장하시고, application.yml 파일에 해당 프로퍼티를 추가하시면 됩니다.

logging:
  config: classpath:log4j2.xml

application.yml

해당 설정을 완료하시면 로거를 자유롭게 사용하실 수 있습니다. 다만 설정을 어떻게 하는지는 다음 글에서 다뤄보도록 하겠습니다. 너무 많은 내용을 한 글에 담으면 지루하더라구요 😭

실제 사용

@RestController
@RequestMapping("/api/samples")
@RequiredArgsConstructor
@Slf4j
public class SampleController {
    private static final Logger logger = LogManager.getLogger(SampleController.class);

    @GetMapping
    public ResponseEntity<String> create(@RequestParam("name") String request) {
        logger.info("Hello. This is LogManager's logger");
        log.info("Hello. This is Lombok's logger");
        System.out.println(logger.equals(log));
        return ResponseEntity.ok(request);
    }
}

SampleController.java (과연 출력문의 결과는 어떻게 될까요?)

해당 로깅의 결과는 다음과 같습니다.

컨트롤러의 첫 로거(logger)는 필드에 존재하는 로거입니다. 두 번째 로거(log)는 Lombok의 @Slf4j를 통해 받아온 로거입니다. 사실 같은 구현체를 쓰기 때문에 차이는 없습니다. 실제 Lombok이 컴파일된 코드는 다음과 같습니다.

테스트

참고로 테스트 코드에선 Lombok의존성과 Log4j2의존성을 테스트 스코프로 설정하지 않으면 사용할 수 없습니다. 물론 의존성을 추가하는 것도 좋지만 해당 방식으로 로거를 구해올 수 있습니다.

@SpringBootTest
public class LoggerTest {
    private static Logger logger = null;

    @BeforeEach
    public void setLogger() {
        System.setProperty("log4j.configurationFile", "log4j2.yml");
        logger = LogManager.getLogger();
    }

    @RepeatedTest(2)
    void givenLoggerWithDefaultConfig_whenLogToConsole_thanOK() {
        Exception e = new RuntimeException("Hello World!");

        logger.info("THIS IS INFO LEVEL LOG");
        logger.debug("THIS IS DEBUG LEVEL LOG");
        logger.error("THIS IS ERROR LEVEL LOG.", e);
        logger.fatal("THIS IS FATAL LEVEL LOG.");
    }
}

물론 단순한 테스트에도 SpringBootTest를 해야한다는 단점이 있어, 더 좋은 방법이 있다면 공유해드리도록 하겠습니다.

마치며

이렇게 간단한 Log4j2 설정방법과 사용법에 대해 공유해봤습니다. 물론 구체적인 내용을 말씀드리진 않았지만, 설정이 안되면 코딩을 하면서 공부하기가 어렵더라구요 🤔 코딩 하면서 공부하는 걸 좋아하는 저로썬, 설정 먼저 해서 직접 쳐보고, 그 내용을 바탕으로 확장시켜 나가는게 좋다고 생각합니다. 여기서 글을 마무리 하고, 다음 글에선 설정 파일의 의미를 설명드리고, 커스텀하는 방법에 대해 이야기 해볼게요. 긴 글 읽어주셔서 감사합니다😊

Intellij의 Spring Initializer를 사용 시 처음 마주치는 화면입니다. Developer Tools. 참으로 멋있는 이름입니다.. 무언가 생산성을 극대화해줄 것만 같은 그 이름. 매 프로젝트를 생성할 때마다 해당 패키지를 포함하지만, 정작 제대로 알고 써본 적은 없는 Spring Boot DevTools에 관해 알아볼게요.

제공하는 기능

Spring Boot DevTools가 제공하는 기능은 크게 5가지입니다.

• Property Defaults
• Automatic Restart
• Live Reload
• Global Settings
• Remote Applications

이번 글에선 가장 주로 쓰이는 세 가지 기능에 대해 알아보고 설정 방법에 대해 알려드릴게요.

Property Defaults

Spring에서 제공하는 thymeleaf는 기본적으로 캐싱 기능을 사용합니다. 하지만 개발과정에서 캐싱이 되어있다면, 우리가 thymeleaf 파일을 수정하더라도, 반영되지 않을 거에요. Application cache 설정값을 false로 수정해야 하죠. 이러한 작업을 Spring Boot DevTools에서 제공합니다. 개발 시점과 배포 시점에 다른 설정을 기본적으로 개발 단계에 맞춰 설정해줍니다. 예를 들어 템플릿 엔진의 캐싱 기능을 개발 단계에서 자동으로 꺼주는 역할을 하죠. 따라서 개발자는 설정 파일을 건드리지 않아도 된답니다.

Automatic Restart

Spring Boot Application을 개발하다 보면 애플리케이션을 재시작해야 하는 경우가 많더라구요. 심지어 클래스의 필드 하나를 고쳐도 Ctrl + R 단축키를 누르는 수고스러움을 감수해야 하죠. Spring Boot DevTools는 이 기능을 자동으로 제공합니다. 파일 수정 후 저장을 하면, Classpath에 존재하는 파일의 변경을 감지하고, 자동으로 서버를 restart 해줍니다. 설정을 통해 원하는 디렉터리만을 트리거로 설정할 수도 있어요!

Live Reload

React에 대한 경험이 있으시다면, Hot reload를 아실 겁니다. JS 파일을 수정하기만 해도 자동으로 브라우저가 새로 고침 되는 기능이죠. DevTools 또한 이 기능을 제공합니다(물론 리액트만큼 훌륭하진 않더라고요 😭). 내부적으로 live reload 서버를 두고, 브라우저 확장프로그램과 통신하는 방식으로 동작하죠. LiveReload 링크를 통해 크롬 확장프로그램을 받고, enable을 하면 됩니다.

해당 버튼으로 활성화를 하는데, 이게 켜졌는지 안 켜졌는지 제대로 보이지 않아서, 마우스를 올려놓은 채 위 그림처럼 메시지가 뜨면 실행이 된 상태라고 보시면 됩니다. 뷰 페이지를 업데이트하면, 브라우저가 자동으로 업데이트되는 모습을 볼 수 있습니다!

설정방법

1. 우선 Gradle에 의존성 추가합니다.

   // build.gradle
   configurations {
    developmentOnly
    runtimeClasspath {
        extendsFrom developmentOnly
    }
   }
   dependencies {
    developmentOnly("org.springframework.boot:spring-boot-devtools")
   }

2. Intellij 화면에서 Cmd + Shift + A 를 입력하여 Registry... 으로 들어가 compiler.automake.allow.when.app.running 을 체크하고 close 합니다.

3. Preference 의 Build, Execution, Deployment -> Compiler -> Build project automatically 를 체크하고 apply 합니다.

4. 만약 Live Reload가 정상적으로 수행이 안된다면, Intellij 우측 상단에 있는 APPLICATION 버튼을 누르면 Edit Configuration 버튼이 나옵니다. 클릭하고, Spring Boot의 application 에서 On 'Update' action 과 On frame deactivation 값을 모두 Update resources 로 설정합니다. (저는 이걸 몰라서 엄청 헤맸네요 😭)

이렇게 하시면 Spring Devtools 설정이 끝납니다!

결론

Spring Devtools에서 제공하는 기능이 완벽하다고 보긴 어렵지만, 개발 과정에서 번거로움을 어느 정도 덜어주는 것 같아요! 또한 live reload 확장프로그램을 받지 않아도, 수정한 resource file을 recompile 하면 서버 재시작 없이 변화를 반영할 수 있답니다. 적절하게 활용한다면 개발 시간을 조금이나마 단축할 수 있을 것 같네요! 긴 글 읽어주셔서 감사합니다!

JPA에서 테이블 간 연관 관계는 객체의 참조를 통해 이뤄집니다. 서비스가 커질수록, 참조하는 객체가 많아지고, 객체가 가지는 데이터의 양이 많아집니다. 이렇게 객체가 커질수록, DB로부터 참조하는 객체들의 데이터까지 한꺼번에 가져오는 행동은 부담이 커집니다. 따라서 JPA는 참조하는 객체들의 데이터를 가져오는 시점을 정할 수 있는데, 이것을 Fetch Type이라고 합니다.

Fetch Type

Fetch Type에는 두 가지가 있습니다.

• EAGER
• LAZY

EAGER는 성실한, 열심인 이라는 뜻을 가지고 있습니다. 말 그대로 데이터를 가져오는데 성실하죠. 하나의 객체를 DB로부터 읽어올 때 참조 객체들의 데이터까지 전부 읽어오는 방식을 뜻합니다. 반대로 LAZY 타입은 게을러서, 참조 객체들의 데이터들은 무시하고 해당 엔티티의 데이터만을 가져옵니다. 그렇다면 언제 어떤 방식을 써야 할까요?

EAGER의 장점?

EAGER는 언제나 한 번의 쿼리로 모든 정보를 가져옵니다. 반대로 LAZY는 참조객체의 데이터를 사용하기 위해서 여러 번의 쿼리를 사용할 수 있습니다. 따라서 참조 객체와 항상 함께 로드되어야 하는 조건을 가진 엔티티에 대해선 LAZY 방식보단 EAGER 방식이 더 좋습니다.

예를 들어 게시판의 글과 저자를 생각해봅시다.

Article.java

@NoArgsConstructor
@Getter @Setter
@Entity
public class Article {

    @Id @GeneratedValue
    @Column(name = "ARTICLE_ID")
    private Long id;

    private String content;

    @ManyToOne
    @JoinColumn(name = "AUTHOR_ID")
    private Author author;
}

Author.java

@NoArgsConstructor
@Getter @Setter
@Entity
public class Author {

    @Id @GeneratedValue
    @Column(name = "AUTHOR_ID")
    private Long id;

    private String name;

    @OneToMany(mappedBy = "author", cascade = ALL)
    private List<Article> articles = new ArrayList<>();

    public void addArticle(Article article) {
        articles.add(article);
        article.setAuthor(this);
    }
}

(예제를 위한 Setter이므로 양해 부탁드립니다 😭)

게시글과 저자는 ManyToOne 양방향 연관 관계를 가지고 있습니다. 게시글을 불러올 때, 항상 저자의 이름과 함께 로드되어야 한다면, 서비스는 다음과 같은 순서로 수행될 것입니다.

Article findArticle = em.find(Article.class, article1.getId());
System.out.println("Author Name : " + findArticle.getAuthor().getName());
System.out.println("Article Content : " + findArticle.getContent());

쿼리문 결과는 다음과 같습니다.

• EAGER의 경우

• LAZY의 경우

EAGER의 경우 쿼리문이 한 번만 실행되지만, LAZY의 경우 2번의 쿼리문이 실행되므로 성능이 떨어진다고 볼 수 있습니다.

이래도 LAZY입니까?

사실 이러한 장점에도 불구하고 Fetch type은 항상 LAZY를 써야 하는 게 맞습니다. 다음 두 경우를 살펴봅시다.

참조가 많아지는 경우

Article의 참조가 많아진다면 어떻게 될까요?

JPQL의 사용

만약 JPQL을 통해 Article을 전부 가져온다면 어떻게 될까요?

Article article1 = new Article();
article1.setContent("집사! 빵이 먹고싶어요.");

Article article2 = new Article();
article2.setContent("집산가요? 냠냠이는 어디있죠?");

Article article3 = new Article();
article3.setContent("이보게. 엉덩이좀 두들겨주게나");

Author author1 = new Author();
author1.setName("디디");

Author author2 = new Author();
author2.setName("루루");

Author author3 = new Author();
author3.setName("모모");

위 처럼 3개의 저자가 각자 한 개의 글을 썼다고 가정해봅시다.

List findArticles = em.createQuery("select a from Article a")
                .getResultList();

위 JPQL 실행 시 발생하는 쿼리문은 다음과 같습니다.

하나의 JPQL 문에 대해 총 쿼리문이 4개나 실행됐습니다. 이를 N+1 Select Problem이라고 하죠. 하나의 Select 요청에 대한 Select문이 n개나 추가되는 현상을 의미합니다. 왜 이런 일이 발생할까요? 이는 Fetch Type이 EAGER인 경우, Article 내의 Author 참조에 대한 데이터를 모두 가져와야 하기 때문입니다. 그 결과 단순한 조회 쿼리 하나가 지나치게 많은 쿼리문을 수행하게 되어 성능 저하를 유발할 수 있습니다.

결론

아무리 단순한 구조의 설계라도, 시간이 지나면 변화되고 추가되기 마련입니다. 개발 과정에서 임시로 사용하는 게 아니라면, 항상 지연 로딩을 사용함으로써 성능 이슈가 발생할 가능성을 줄여주는 것이 좋습니다.