programmer.cwchoiit

참고자료

JDBC 이해

애플리케이션을 개발할 때, 중요한 데이터는 대부분 데이터베이스에 보관한다.

클라이언트가 애플리케이션 서버를 통해 데이터를 저장하거나 조회하면, 애플리케이션 서버는 다음 과정을 통해서 데이터베이스를 사용한다.

• 커넥션 연결: 주로 TCP/IP를 통해 커넥션을 연결한다.
• SQL 전달: 애플리케이션 서버는 DB가 이해할 수 있는 SQL을 연결된 커넥션을 통해 DB에 전달한다.
• 결과 응답: DB는 전달된 SQL을 수행하고 그 결과를 응답한다. 애플리케이션 서버는 응답 결과를 활용한다.

문제는, 각각의 데이터베이스마다 커넥션을 연결하는 방법, SQL을 전달하는 방법, 그리고 결과를 응답 받는 방법이 모두 다르다는 점이다. 참고로 관계형 데이터베이스는 수십개가 있다. 여기에는 2가지 큰 문제가 있는데, 다음과 같다.

• 데이터베이스를 다른 종류의 데이터베이스로 변경하면 애플리케이션 서버에 개발된 데이터베이스 사용 코드도 함께 변경해야 한다.
• 개발자가 각각의 데이터베이스마다 커넥션 연결, SQL 전달, 그리고 그 결과를 응답 받는 방법을 새로 학습해야 한다.

이런 문제를 해결하기 위해 JDBC라는 자바 표준이 등장한다.

JDBC 표준 인터페이스

JDBC(Java Database Connectivity)는 자바에서 데이터베이스에 접속할 수 있도록 하는 자바 API다. JDBC는 데이터베이스에서 자료를 쿼리하거나 업데이트하는 방법을 제공한다.

대표적으로 다음 3가지 기능을 표준 인터페이스로 정의해서 제공한다.

• java.sql.Connection → 연결
• java.sql.Statement → SQL을 담은 내용
• java.sql.ResultSet → SQL 요청 응답

자바는 이렇게 표준 인터페이스를 정의해두었다. 이제부터 개발자는 이 표준 인터페이스만 사용해서 개발하면 된다. 그런데 인터페이스만 있다고해서 기능이 동작하지는 않는다. 이 JDBC 인터페이스를 각각의 DB 벤더(회사)에서 자신의 DB에 맞도록 구현해서 라이브러리로 제공하는데, 이것을 JDBC 드라이버라고 한다. 예를 들어, MySQL에 접근할 수 있는 것은 MySQL JDBC 드라이버라고 하고, OracleDB에 접근할 수 있는 것은 Oracle JDBC 드라이버라고 한다.

MySQL 드라이버 사용

Oracle 드라이버 사용

JDBC의 등장으로 다음 2가지 문제가 해결되었다.

• 데이터베이스를 다른 종류의 데이터베이스로 변경하면 애플리케이션 서버의 데이터베이스 사용 코드도 함께 변경해야 하는 문제를 애플리케이션 로직은 이제 JDBC 표준 인터페이스만 의존한다. 따라서 데이터베이스를 다른 종류의 데이터베이스로 변경하고 싶으면 JDBC 구현 라이브러리만 변경하면 된다. 즉, 드라이버만 변경하면 된다. 따라서 다른 종류의 데이터베이스로 변경해도 애플리케이션 서버의 사용 코드를 그대로 유지할 수 있다.
• 개발자가 각각의 데이터베이스마다 커넥션 연결, SQL 전달, 그리고 그 결과를 응답 받는 방법을 새로 학습해야 하는 문제를 JDBC 표준 인터페이스 사용법만 학습하면 된다. 한번 배워두면 수십개의 데이터베이스에 모두 동일하게 적용할 수 있다.

표준화의 한계도 있다. JDBC의 등장으로 많은 것이 편리해졌지만, 각각의 데이터베이스마다 SQL, 데이터타입 등의 일부 사용법이 다르다. 대표적으로 실무에서 기본으로 사용하는 페이징 SQL은 각각의 데이터베이스마다 사용법이 다르다. 결국 데이터베이스를 변경하면 JDBC 코드는 변경하지 않아도 되지만, SQL은 해당 데이터베이스에 맞도록 변경해야 한다. 

JDBC와 최신 데이터 접근 기술

JDBC는 1997년에 출시될 정도로 오래된 기술이고, 사용하는 방법도 복잡하다. 그래서 최근에는 JDBC를 직접 사용하기 보다는 JDBC를 편리하게 사용하는 다양한 기술들이 존재한다. 대표적으로 SQL Mapper와 ORM 기술로 나눌 수 있다.

• SQL Mapper
  • JDBC를 편리하게 사용하도록 도와준다.
  • SQL 응답 결과를 객체로 편리하게 변환해준다.
  • JDBC의 반복 코드를 제거해준다.
  • 개발자가 직접 SQL을 작성해야 한다.
  • 대표 기술로는 스프링 JdbcTemplate, MyBatis가 있다.

• ORM 기술
  • ORM은 객체를 관계형 데이터베이스 테이블과 매핑해주는 기술이다. 이 기술 덕분에 개발자는 반복적인 SQL을 직접 작성하지 않고, ORM 기술이 개발자 대신에 SQL을 동적으로 만들어 실행해준다. 추가로 각각의 데이터베이스마다 다른 SQL을 사용하는 문제도 중간에서 해결해준다. 
  • 대표 기술로는 JPA가 있다. 

SQL Mapper vs ORM 기술

둘 다 장단점이 있다. SQL Mapper는 SQL만 직접 작성하면 나머지 번거로운 일은 SQL Mapper가 대신 해결해준다. 그래서 SQL만 작성할 줄 알면 금방 배워서 사용할 수 있다. ORM 기술은 SQL 자체를 작성하지 않아도 되어서 개발 생산성이 매우 높아진다. 편리한 반면 쉬운 기술은 아니므로 실무에서 사용하려면 깊이있게 학습해야 한다. 

중요한 점은, 이런 기술들도 내부에서는 모두 JDBC를 사용한다. 따라서 JDBC를 직접 사용하지 않더라도, JDBC가 어떻게 동작하는지 기본원리를 알아야 한다. 그래야 해당 기술들을 더 깊이있게 이해할 수 있고, 무엇보다 문제가 발생했을 때 근본적인 문제를 찾아서 해결할 수 있다. JDBC는 자바 개발자라면 꼭 알아두어야 하는 필수 기본 기술이다.

데이터베이스 연결

애플리케이션과 데이터베이스를 연결해보자. 먼저, 데이터베이스는 H2 데이터베이스를 사용하기로 한다. 그러려면 H2 데이터베이스 라이브러리가 추가되어야 한다. 그리고 스프링 부트를 사용하여 테스트한다.

ConnectionConst

package cwchoiit.jdbc.connection;

public abstract class ConnectionConst {
    public static final String URL = "jdbc:h2:tcp://localhost/~/h2/db/jdbc";
    public static final String USERNAME = "sa";
    public static final String PASSWORD = "";
}

• 데이터베이스에 접속하는데 필요한 기본 정보를 편리하게 사용할 수 있도록 상수로 만들었다.
• 이제 JDBC를 사용해서 실제 데이터베이스에 연결하는 코드를 작성해보자.

package cwchoiit.jdbc.connection;

import lombok.extern.slf4j.Slf4j;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

import static cwchoiit.jdbc.connection.ConnectionConst.*;

@Slf4j
public class DBConnectionUtil {

    public static Connection getConnection() {
        try {
            Connection connection = DriverManager.getConnection(URL, USERNAME, PASSWORD);
            log.info("get connection = {}, class = {}", connection, connection.getClass());
            return connection;
        } catch (SQLException e) {
            throw new RuntimeException(e);
        }
    }
}

• 데이터베이스에 연결하려면, JDBC가 제공하는 DriverManager.getConnection(...)을 사용하면 된다. 이렇게 하면 라이브러리에 있는 데이터베이스 드라이버를 찾아서 해당 드라이버가 제공하는 커넥션을 반환해준다. 여기서는 H2 데이터베이스 드라이버가 작동해서 실제 데이터베이스와 커넥션을 맺고, 그 결과를 반환해 줄 것이다.

DBConnectionUtilTests

package cwchoiit.jdbc.connection;

import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;

import java.sql.Connection;

import static org.assertj.core.api.Assertions.assertThat;

@Slf4j
class DBConnectionUtilTests {

    @Test
    void connection() {
        Connection connection = DBConnectionUtil.getConnection();
        assertThat(connection).isNotNull();
    }
}

실행 결과

16:52:45.721 [Test worker] INFO cwchoiit.jdbc.connection.DBConnectionUtil -- get connection = conn0: url=jdbc:h2:tcp://localhost/~/h2/db/jdbc user=SA, class = class org.h2.jdbc.JdbcConnection

• 실행 결과를 보면 class=class org.h2.jdbc.JdbcConnection 부분을 확인할 수 있다. 이것이 바로 H2 데이터베이스 드라이버가 제공하는 H2 전용 커넥션이다. 물론 이 커넥션은 JDBC 표준 커넥션 인터페이스인 java.sql.Connection 인터페이스를 구현하고 있다.

JDBC DriverManager 연결 이해

지금까지 코드로 확인해 본 과정을 좀 더 자세히 들여다보자.

JDBC 커넥션 인터페이스와 구현

• JDBC는 java.sql.Connection 표준 커넥션 인터페이스를 정의한다.
• H2 데이터베이스 드라이버는 JDBC Connection 인터페이스를 구현한 org.h2.jdbc.JdbcConnection 구현체를 제공한다.

DriverManager 커넥션 요청 흐름

• JDBC가 제공하는 DriverManager는 라이브러리에 등록된 DB 드라이버들을 관리하고, 커넥션을 획득하는 기능을 제공한다.
• 애플리케이션 로직에서 커넥션이 필요하면 DriverManager.getConnection(...)을 호출한다.
• DriverManager는 라이브러리에 등록된 드라이버 목록을 자동으로 인식한다. 이 드라이버들에게 순서대로 다음 정보를 넘겨서 커넥션을 획득할 수 있는지 확인한다.
  • URL: jdbc:h2:tcp://localhost/~/h2/db/jdbc
  • 이름, 비밀번호 등 접속에 필요한 추가 정보
  • 여기서 각각의 드라이버는 URL 정보를 체크해서 본인이 처리할 수 있는 요청인지 확인한다. 예를 들어서 URL이 jdbc:h2로 시작하면 이것은 H2 데이터베이스에 접근하기 위한 규칙이다. 따라서 H2 드라이버는 본인이 처리할 수 있으므로 실제 데이터베이스에 연결해서 커넥션을 획득하고, 이 커넥션을 클라이언트에 반환한다. 반면에, URL이 jdbc:h2로 시작했는데 MySQL 드라이버가 먼저 실행되면 이 경우 본인이 처리할 수 없다는 결과를 반환하게 되고 다음 드라이버에게 순서가 넘어간다.
• 이렇게 찾은 커넥션 구현체가 클라이언트에 반환된다.

우리는 H2 데이터베이스 드라이버만 라이브러리에 등록했기 때문에, H2 드라이버가 제공하는 H2 커넥션을 제공받는다. 물론, 이 H2 커넥션은 JDBC가 제공하는 java.sql.Connection 인터페이스를 구현하고 있다.

참고: H2 데이터베이스 드라이버 라이브러리

runtimeOnly 'com.h2database:h2' //h2-x.x.xxx.jar

이번 포스팅에는 OSIV가 무엇인지, 이게 어떤 성능에 영향을 주는지 알아보는 시간을 가져보자!

OSIV(Open Session In View)라는 이 녀석은, 스프링을 사용하면 이런 설정값으로 표현된다.

spring.jpa.open-in-view

근데, 이 값이 기본으로 `true`이다. 즉, 아무것도 설정하지 않으면 이 설정이 켜져있는건데 이게 켜져있으면 데이터베이스 커넥션이 반납되는 시점이 크게 달라진다. 

자, 다음 코드를 보자.

package cwchoiit.shoppingmall.service;

import cwchoiit.shoppingmall.domain.Member;
import cwchoiit.shoppingmall.repository.MemberRepository;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import java.util.List;

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
public class MemberService {

    private final MemberRepository memberRepository;

    @Transactional
    public Long signup(Member member) {
        validateDuplicateMember(member);

        memberRepository.save(member);
        return member.getId();
    }
}

• 여기보면 signup() 이라는 메서드가 하나 있고, @Transactional 애노테이션이 달려있다.
• JPA는 @Transactional 애노테이션이 붙어있는 메서드가 실행하는 시점에 커넥션을 받아온다. 그리고 일반적으로 @Transactional 애노테이션이 달린 메서드가 끝나면 커넥션을 반납하게 된다.
• 그런데, 이 OSIV가 켜져있으면 메서드가 끝나는 시점에 커넥션을 반환하지 않는다. 
• 그럼 언제 반환하지? 자, 이 signup()을 호출한 컨트롤러로 넘어가보자.

@PostMapping("/members/new")
public String create(@Validated MemberForm memberForm, BindingResult bindingResult) {
    if (bindingResult.hasErrors()) {
        return "members/createMemberForm";
    }

    Address address = new Address(memberForm.getCity(), memberForm.getStreet(), memberForm.getZipCode());

    Member member = Member.builder()
            .name(memberForm.getName())
            .address(address)
            .build();

    memberService.signup(member);
    return "redirect:/";
}

• 이 컨트롤러에서 signup()을 호출하는데, 호출하고 다시 돌아오는 시점에도, 커넥션은 반환되지 않는다. 그리고 사용자에게 최종적으로 화면이 뿌려지고 완전히 응답이 끝나면! 그때 커넥션을 반납한다.
• 왜 그러냐면, 만약, 데이터베이스를 통해 데이터를 받아왔는데 이 데이터 중 프록시를 초기화해야 하는 데이터가 있을수도 있기 때문에 그때까지 영속성 컨텍스트를 살려두어야만 초기화가 가능하기 때문이다.
• 프록시 초기화는 반드시 영속성 컨텍스트가 관리하고 있는 엔티티여야만 가능하다!

그럼, 결국 OSIV가 켜져있으면, API라면 호출한 곳으로부터 응답이 완전히 다 나가고 나서 커넥션이 반납되고, API가 아니라 뷰를 반환하는 경우라면 템플릿이 완전히 다 만들어지고 사용자에게 화면이 뿌려지는 시점에 커넥션이 반납된다.

그러니까, OSIV는 장단점이 있다. 컨트롤러나 뷰 레이어에서도 지연로딩을 처리할 수도 있다는 장점이 있지만 단점은 커넥션을 너무 오랫동안 유지하고 있다는 점이다. 그래서 자칫 잘못하면 커넥션이 반납이 너무 느려져서 말라버릴 수도 있다. 그럼 도대체 이 옵션은 켜야하나 꺼야하나? 끄면 모든 지연로딩을 트랜잭션 안에서 처리해야 하는 단점이 있지만, 키면 커넥션을 너무 오랫동안 가지고 있다는 단점이 있다. 

내가 생각하는 좋은 방법은..

• OSIV 옵션을 끈다.
• 모든 지연로딩을 페치 조인이나, 중간 레이어를 두어서 컨트롤러나 뷰에서 처리할 필요가 없도록 데이터를 받아온다.

그래서, 커넥션을 너무 오랫동안 유지하고 있지 않도록 하는게 가장 좋은 방법인것 같다. 어차피 지연로딩을 초기화해야 하는 경우라면 페치 조인을 사용해서 처음부터 모든 데이터를 받아오도록 하면 될 것이고, 바로 지연로딩이 초기화가 필요한 게 아니라 특정 순간에만 필요한 경우 중간 레이어 하나를 만들어서 쿼리와 커맨드를 분리해서 한번 더 트랜잭션의 도움을 받으면 될 것 같다. 

근데 이게 뭐 딱 정해진 정답이 있는게 아니라 상황에 따라 잘 활용하면 될 것 같다. 예를 들어 이렇게 하는 것이다.

• 고객 서비스의 실시간 API는 OSIV를 꺼서 최대한 커넥션 반납을 빠르게 하고, ADMIN 화면과 같은 커넥션을 많이 사용하지 않는 곳에서는 OSIV를 키는 방식으로 유연하게 적용한다.

이번 포스팅에는 JPA를 통해 컬렉션을 조회할 때 최적화하는 방법을 설명한다. ToMany 관계에 있는 데이터를 가져올때 문제가 되는 부분들과 그 문제를 해결하는 방법을 설명한다.

우선, OneToMany 관계에 있는 Order와 OrderItems를 API로 반환해보자.

1. 모든 엔티티를 제거하고 DTO로 변환하라

@GetMapping("/api/v2/orders")
public List<OrderDto> ordersV2() {
    List<Order> orders = orderRepository.findAllByCriteria(new OrderSearch());
    return orders.stream().map(OrderDto::new).toList();
}

• 일단 @GetMapping으로 REST API 하나를 매핑시키고, 반환하는 데이터는 반드시 DTO로 변환하자.
• 아 물론, 반환 데이터는 응답 공통 객체로 감싸는게 더 좋다. 그래야 전체 개수나 페이지 수 같은 메타데이터도 포함시킬 수 있기 때문이다. 여기서는 단순화를 위해 데이터만 반환하도록 했다.

@Data
static class OrderDto {
    private Long orderId;
    private String name;
    private LocalDateTime orderDate;
    private OrderStatus orderStatus;
    private Address address;
    private List<OrderItemDto> orderItems;

    public OrderDto(Order order) {
        this.orderId = order.getId();
        this.name = order.getMember().getName();
        this.orderDate = order.getOrderDate();
        this.orderStatus = order.getStatus();
        this.address = order.getDelivery().getAddress();

        this.orderItems = order.getOrderItems().stream().map(OrderItemDto::new).toList();
    }
}

@Data
static class OrderItemDto {
    private String itemName;
    private int orderPrice;
    private int count;

    public OrderItemDto(OrderItem orderItem) {
        this.itemName = orderItem.getItem().getName();
        this.orderPrice = orderItem.getOrderPrice();
        this.count = orderItem.getCount();
    }
}

• 반환하려는 OrderDto는 이렇게 생겼다. 여기서 중요한 점은, OrderItems에 해당하는 데이터 역시 DTO로 변환해야 한다는 점이다. 엔티티를 DTO로 변환하라는 말은 껍데기만 DTO를 사용하라는 말이 아니라 모든 엔티티가 없어야 한다.
• 그래서, orderItems 타입도 역시 DTO로 만들기 위해 OrderItemDto도 존재한다.

이 상태에서 REST API를 호출해보자. 아래와 같은 결과가 나온다.

[
  {
    "orderId": 1,
    "name": "userA",
    "orderDate": "2024-11-17T13:40:39.935598",
    "orderStatus": "ORDER",
    "address": {
      "city": "서울",
      "street": "1",
      "zipCode": "1111"
    },
    "orderItems": [
      {
        "itemName": "JPA BOOK 1",
        "orderPrice": 10000,
        "count": 1
      },
      {
        "itemName": "JPA BOOK 2",
        "orderPrice": 20000,
        "count": 2
      }
    ]
  },
  {
    "orderId": 2,
    "name": "userB",
    "orderDate": "2024-11-17T13:40:39.940763",
    "orderStatus": "ORDER",
    "address": {
      "city": "경기",
      "street": "2",
      "zipCode": "2222"
    },
    "orderItems": [
      {
        "itemName": "SPRING BOOK 1",
        "orderPrice": 10000,
        "count": 1
      },
      {
        "itemName": "SPRING BOOK 2",
        "orderPrice": 20000,
        "count": 2
      }
    ]
  }
]

• 결과는 원하는대로 잘 나왔다

여기서 끝낼 수 없다. 우선, 엔티티는 모두가 다 지연로딩이기 때문에 이 API를 호출하는 순간, 정말 많은 쿼리가 나갈것이다. 왜냐하면 아직 페치 조인으로 쿼리 최적화를 한 상태가 아니기 때문에. 그래서 엔티티를 DTO로 변환하는 것까진 좋지만 이제 쿼리 최적화를 위해 페치 조인을 사용해보자.

2. 쿼리 최적화를 위해 페치 조인을 사용하라

이제 페치 조인을 사용해서, 조인을 함과 동시에 셀렉트 절에 필드에 값을 채워넣는 작업까지 한번의 쿼리로 끝내보자. JPA가 제공하는 막강한 기능이다.

OrderRepository 일부분

public List<Order> findAllWithItem() {
    return entityManager.createQuery(
            "SELECT o " +
                    "FROM Order o " +
                    "JOIN FETCH o.member m " +
                    "JOIN FETCH o.delivery d " +
                    "JOIN FETCH o.orderItems oi " +
                    "JOIN FETCH oi.item i", Order.class)
            .getResultList();
}

• 다음 코드와 같이 관련된 모든 엔티티에 대해 페치 조인을 사용했다. 이러면 SQL문으로 조인을 하는것까진 똑같은데 조인을 한 다음 실제 그 데이터를 메모리에 올려서 필드에 퍼올려주게 된다. 
• 그런데 여기서 문제는 바로, o.orderItems를 페치 조인하는 것이다. 이 녀석은 OneToMany 관계로 설정된 컬렉션이다. 컬렉션을 페치 조인하게 되면 데이터가 뻥튀기가 된다. 결과를 보자.

OrderController 일부분

@GetMapping("/api/v3/orders")
public List<OrderDto> ordersV3() {
    return orderRepository.findAllWithItem().stream().map(OrderDto::new).toList();
}

• 페치 조인을 사용하는 메서드를 호출한다. 이 녀석을 API로 호출해보자. 호출을 해보면 실제로 쿼리가 어떻게 나가는지 볼 수 있는데, 다음과 같이 나간다.

select
        o1_0.order_id,
        d1_0.delivery_id,
        d1_0.city,
        d1_0.street,
        d1_0.zip_code,
        d1_0.status,
        m1_0.member_id,
        m1_0.city,
        m1_0.street,
        m1_0.zip_code,
        m1_0.name,
        o1_0.order_date,
        oi1_0.order_id,
        oi1_0.order_item_id,
        oi1_0.count,
        i1_0.item_id,
        case 
            when i1_1.item_id is not null 
                then 1 
            when i1_2.item_id is not null 
                then 2 
            when i1_3.item_id is not null 
                then 3 
        end,
        i1_0.name,
        i1_0.price,
        i1_0.stock_quantity,
        i1_1.artist,
        i1_1.etc,
        i1_2.author,
        i1_2.isbn,
        i1_3.actor,
        i1_3.director,
        oi1_0.order_price,
        o1_0.status 
    from
        orders o1_0 
    join
        member m1_0 
            on m1_0.member_id=o1_0.member_id 
    join
        delivery d1_0 
            on d1_0.delivery_id=o1_0.delivery_id 
    join
        order_item oi1_0 
            on o1_0.order_id=oi1_0.order_id 
    join
        (item i1_0 
    left join
        album i1_1 
            on i1_0.item_id=i1_1.item_id 
    left join
        book i1_2 
            on i1_0.item_id=i1_2.item_id 
    left join
        movie i1_3 
            on i1_0.item_id=i1_3.item_id) 
        on i1_0.item_id=oi1_0.item_id

• 쿼리는 매우 행복하게 딱 한개만 나간다. 이게 페치 조인의 힘이다. 근데 이 쿼리를 실제로 데이터베이스에서 날려보면 어떻게 될까? 결과는 다음과 같다.

• 보다시피 Order 레코드는 ID가 1, 2로 2개뿐이지만, OneToMany 관계에 있는 OrderItems와 조인을 해버리니까 데이터가 4개로 뻥튀기 됐다. 왜냐하면 1번 주문이 가지고 있는 OrderItem이 2개다 보니까 1번 주문의 레코드가 2개가 나올수밖에 없다. 2번도 마찬가지 이유다.

이게 바로 OneToMany 관계에 있는 엔티티와 조인할 때 즉, 컬렉션을 조인할때 생기는 데이터 뻥튀기 현상이다. 이걸 가지고 페이징 처리를 한다면? 뭔가 문제가 생길 수 밖에 없다. 그래서 이를 해결하기 위해 JPA에서 무엇을 제공하냐? `DISTINCT` 라는 키워드를 제공한다.

"어? 데이터베이스에서 그냥 제공하는 키워드 아닌가요?" → 맞다. 맞는데, JPA가 추가적인 기능을 제공한다. 일단 사용을 해보자.

public List<Order> findAllWithItem() {
    return entityManager.createQuery(
            "SELECT DISTINCT o " +
                    "FROM Order o " +
                    "JOIN FETCH o.member m " +
                    "JOIN FETCH o.delivery d " +
                    "JOIN FETCH o.orderItems oi " +
                    "JOIN FETCH oi.item i", Order.class)
            .getResultList();
}

• 다음과 같이 JPQL에 DISTINCT만 추가했다.
• 실행한 다음 나간 쿼리를 한번 보자. 

select
        distinct o1_0.order_id,
        d1_0.delivery_id,
        d1_0.city,
        d1_0.street,
        d1_0.zip_code,
        d1_0.status,
        m1_0.member_id,
        m1_0.city,
        m1_0.street,
        m1_0.zip_code,
        m1_0.name,
        o1_0.order_date,
        oi1_0.order_id,
        oi1_0.order_item_id,
        oi1_0.count,
        i1_0.item_id,
        case 
            when i1_1.item_id is not null 
                then 1 
            when i1_2.item_id is not null 
                then 2 
            when i1_3.item_id is not null 
                then 3 
        end,
        i1_0.name,
        i1_0.price,
        i1_0.stock_quantity,
        i1_1.artist,
        i1_1.etc,
        i1_2.author,
        i1_2.isbn,
        i1_3.actor,
        i1_3.director,
        oi1_0.order_price,
        o1_0.status 
    from
        orders o1_0 
    join
        member m1_0 
            on m1_0.member_id=o1_0.member_id 
    join
        delivery d1_0 
            on d1_0.delivery_id=o1_0.delivery_id 
    join
        order_item oi1_0 
            on o1_0.order_id=oi1_0.order_id 
    join
        (item i1_0 
    left join
        album i1_1 
            on i1_0.item_id=i1_1.item_id 
    left join
        book i1_2 
            on i1_0.item_id=i1_2.item_id 
    left join
        movie i1_3 
            on i1_0.item_id=i1_3.item_id) 
        on i1_0.item_id=oi1_0.item_id

• 이 나간 쿼리에도 DISTINCT가 붙어있다. 근데 이 쿼리 그대로 복사해서 데이터베이스에 실제로 날려보면 결과 어떻게 나올까? 안타깝게도 전혀 달라지지 않는다.

• 이런 현상의 이유는 데이터베이스의 DISTINCT는 정말 레코드의 모든 값이 다 똑같아야 중복으로 판단하고 제거해준다. 그런데 위 결과를 보면, 1번 주문의 2개의 레코드는 Order 관련 데이터만 동일하고, 나머지 값은 다르다. OrderItem이 다르니까.

그런데 API 날리고 받은 응답을 보면, 데이터는 두개만 보여진다.

[
  {
    "orderId": 1,
    "name": "userA",
    "orderDate": "2024-11-17T14:24:10.567046",
    "orderStatus": "ORDER",
    "address": {
      "city": "서울",
      "street": "1",
      "zipCode": "1111"
    },
    "orderItems": [
      {
        "itemName": "JPA BOOK 1",
        "orderPrice": 10000,
        "count": 1
      },
      {
        "itemName": "JPA BOOK 2",
        "orderPrice": 20000,
        "count": 2
      }
    ]
  },
  {
    "orderId": 2,
    "name": "userB",
    "orderDate": "2024-11-17T14:24:10.571629",
    "orderStatus": "ORDER",
    "address": {
      "city": "경기",
      "street": "2",
      "zipCode": "2222"
    },
    "orderItems": [
      {
        "itemName": "SPRING BOOK 1",
        "orderPrice": 10000,
        "count": 1
      },
      {
        "itemName": "SPRING BOOK 2",
        "orderPrice": 20000,
        "count": 2
      }
    ]
  }
]

• 이게 JPA가 추가적으로 해주는 기능이다. JPA는 DISTINCT를 사용하면, 우선 SQL에도 그 키워드를 붙여준다. 그래서 만약, 레코드의 모든 값이 동일한 레코드가 있다면 하나만 보여주게 해준다.
• 두번째로는, JPA가 추가적으로 제공하는 기능인데 가져온 데이터를 메모리에 퍼 올릴때, 반환 엔티티에 대한 ID가 동일하다면 (여기서는 Order) 그 값은 중복된 것으로 판단하고 메모리에 올리지 않는다. 이게 JPA가 해주는 추가적인 기능이다.

그래서 결론적으로 깔끔하게 DTO와 페치조인을 사용해서 일대다 조인을 사용할때도 깔끔하게 데이터를 가져올 수 있게 됐다. 그런데, 이때 정말 치명적인 문제가 하나 발생한다. 일대다 페치 조인을 하는 순간 페이징 처리가 불가능하다. 

2-1. 일대다 페치 조인을 할 때 페이징이 불가능한 문제

바로 위에서 일대다 페치 조인을 할 때 치명적인 문제를 말했다. 즉, 페이징 처리가 불가능해진다. 바로 코드로 보자.

페이징 처리라는 게 별게 아니라 다음과 같이 사용하면 된다.

public List<Order> findAllWithItem() {
    return entityManager.createQuery(
            "SELECT DISTINCT o " +
                    "FROM Order o " +
                    "JOIN FETCH o.member m " +
                    "JOIN FETCH o.delivery d " +
                    "JOIN FETCH o.orderItems oi " +
                    "JOIN FETCH oi.item i", Order.class)
            .setFirstResult(1)
            .setMaxResults(1000)
            .getResultList();
}

• setFirstResult(1), setMaxResults(1000) 을 사용해서 0번은 건너뛰고 1번부터 1000개를 가져오는 쿼리를 작성했다. 그러면 여기서 드는 생각은, 아 지금 현재 데이터는 2개니까 앞에꺼 하나를 건너뛰고 뒤에꺼 한 개만 가져오겠군?! 이라고 생각이 든다.

근데 이거 실제로 실행해보자. 실행해보면, 날라가는 쿼리가 다음과 같다.

select
        distinct o1_0.order_id,
        d1_0.delivery_id,
        d1_0.city,
        d1_0.street,
        d1_0.zip_code,
        d1_0.status,
        m1_0.member_id,
        m1_0.city,
        m1_0.street,
        m1_0.zip_code,
        m1_0.name,
        o1_0.order_date,
        oi1_0.order_id,
        oi1_0.order_item_id,
        oi1_0.count,
        i1_0.item_id,
        case 
            when i1_1.item_id is not null 
                then 1 
            when i1_2.item_id is not null 
                then 2 
            when i1_3.item_id is not null 
                then 3 
        end,
        i1_0.name,
        i1_0.price,
        i1_0.stock_quantity,
        i1_1.artist,
        i1_1.etc,
        i1_2.author,
        i1_2.isbn,
        i1_3.actor,
        i1_3.director,
        oi1_0.order_price,
        o1_0.status 
    from
        orders o1_0 
    join
        member m1_0 
            on m1_0.member_id=o1_0.member_id 
    join
        delivery d1_0 
            on d1_0.delivery_id=o1_0.delivery_id 
    join
        order_item oi1_0 
            on o1_0.order_id=oi1_0.order_id 
    join
        (item i1_0 
    left join
        album i1_1 
            on i1_0.item_id=i1_1.item_id 
    left join
        book i1_2 
            on i1_0.item_id=i1_2.item_id 
    left join
        movie i1_3 
            on i1_0.item_id=i1_3.item_id) 
        on i1_0.item_id=oi1_0.item_id

• ..? limit, offset은 어디있는거지? 

페이징을 추가했는데 날라가는 쿼리에는 페이징 처리를 위한 limit, offset이 없다. 굉장히 심각한거다. 그리고 로그를 보면 이러한 로그가 보인다. 컬렉션 페치조인과 같이 firstResult, maxResults가 사용됐다고 말해주고, 이 데이터를 메모리에 올려서 페이징 처리를 하겠다는 무시무시한 로그가 찍힌다.

2024-11-17T14:34:19.126+09:00  WARN 42800 --- [ShoppingMall] [nio-8080-exec-1] org.hibernate.orm.query                  : HHH90003004: firstResult/maxResults specified with collection fetch; applying in memory

• 이 로그가 왜 무시무시하냐? 데이터가 만개면? 십만개면? 메모리에 올리는 순간 OOM이 터질 수 있다. 실제 운영중인 서비스라면..? 끔찍하다.
• 아니 그럼 도대체 왜..? 메모리에 올려서 페이징 처리를 하지..? 왜 Hibernate는 이런 극단적인 선택을 했을까?

2-2. 일대다 페치 조인일 때 페이징 시도 시 Hibernate가 극단적 선택을 한 이유

일대다 페치 조인을 했을 때, 왜 도대체 메모리에 올려서 페이징을 할까? 

아까 일대다 페치 조인을 했을 때 날라가는 쿼리를 직접 데이터베이스에서 실행해봤을 때 이런 결과를 얻었다.

• 실제 데이터베이스에 있는 주문 데이터는 딱 2개다. ID가 (1, 2)
• 그렇지만, 그 주문 데이터는 주문 아이템 데이터를 두개씩 가지고 있기 때문에 위 결과처럼 데이터가 뻥튀기 된다.
• 이 상태에서 limit, offset을 적용하면 정확한 데이터가 나올까? 아니다. 실제로는 주문은 2개뿐인데, 지금 상태에서 offset 1 limit 1000을 쿼리에 붙여 실행하면 위 결과에서 ORDER_ID 컬럼 기준으로 맨 위에 데이터를 제외하고 (1, 2, 2) 세 개의 데이터가 나올 것이다. 그 말은 잘못된 페이징 처리가 된다는 뜻이다.
• 그런데, JPA가 어떤 도움을 주냐? 이 상태의 데이터를 메모리에 올릴때 같은 아이디는 제거해버린다. 그래서 메모리에 올라간 시점은 뻥튀기 데이터가 사라진 상태가 된다. 그렇기 때문에 메모리에 올린 상태에서 페이징 처리를 꾸역꾸역 해주는 것이다.

이러한 이유때문에 결국 일대다 페치 조인을 사용할때 페이징 처리를 하면 메모리에 올려서 페이징 처리를 할 수 밖에 없게 되는 것이다.

그리고 또 한가지 주의할 점이 있다. 일대다 페치 조인은 딱 한개만 사용해야 한다. 그러니까 위 예시에서는 Order입장에서 일대다 관계가 OrderItems였는데, 여기에 만약에 추가적으로 일대다 관계가 있는 녀석(A)이 있다고 가정하면, 페치 조인 시 OrderItems, A 이 두개를 같이 페치조인하면 안된다는 뜻이다. 이유는 위에서 이미 다 봤다. 데이터가 뻥튀기가 되는데, 이건 배로 뻥튀기가 된다. 데이터 정합성의 문제가 생길 소지가 너무 많고, 이렇게 굳이 하지 않아도 충분히 원하는 데이터를 뽑아낼 수 있는데 리스크는 크고 리턴은 적다. 

3. 일대다 페치조인 시 페이징과 한계 돌파

일대다 페치조인시 생기는 페이징 처리의 문제를 해결하는 방법을 소개한다. 결론부터 말하면 페이징이 필요한 쿼리에서 일대다 관계에 있는 녀석들은 다 지워버리면 된다. 그럼 페이징에 아무런 문제가 발생하지 않는다. 그럼 여기서 남은 문제는 페치 조인을 하지 않으면 일대다 관계에 있는 녀석들도 API 응답을 반환할때 반환 데이터로 이 컬렉션이 필요한 경우엔 프록시 초기화를 해야하니까 쿼리가 여러번 나갈텐데 이걸 어떻게 해결할까?

큰 그림으로 이렇게 정리할 수 있겠다. 다음 단계를 따르면 된다.

1. ToMany 관계에 있는, 즉, 컬렉션은 모두 페치 조인에서 제거한다.
2. ToOne 관계에 있는 엔티티들만 몇개가 됐든 상관없이 모두 페치조인한다.
3. `default_batch_fetch_size` 옵션을 적절하게 부여해서 한번에 이 속성에 적용한 개수만큼 데이터를 가져오게 한다.

@GetMapping("/api/v3.1/orders")
public List<OrderDto> ordersV3_1(@RequestParam(value = "offset", defaultValue = "0") int offset,
                                 @RequestParam(value = "limit", defaultValue = "100") int limit) {
    return orderRepository.findAllWithMemberDelivery(offset, limit).stream()
            .map(OrderDto::new)
            .toList();
}

• ToOne 관계에 있는 엔티티는 몇개가 됐든 페치 조인을 해도 상관없고 페이징도 아주 잘 작동한다. 데이터 뻥튀기란 존재할 수 없기 때문에 그렇다. 
• 그렇기 때문에 위 코드처럼 offset, limit을 쿼리 파라미터로 받아서 페이징을 처리할수 있는 메서드를 하나 만들자.

public List<Order> findAllWithMemberDelivery(int offset, int limit) {
    return entityManager.createQuery(
                    "SELECT o " +
                            "FROM Order o " +
                            "JOIN FETCH o.member m " +
                            "JOIN FETCH o.delivery d", Order.class)
            .setFirstResult(offset)
            .setMaxResults(limit)
            .getResultList();
}

• 위에서 말한대로, ToOne 관계에 있는 엔티티들(Member, Delivery)는 모두 페치 조인을 했고 컬렉션 관계에 있는 엔티티(OrderItems)는 페치 조인에서 제거했다.
• 이 상태로 실행해보자. 결과는 다음과 같다.

[
    {
        "orderId": 2,
        "name": "userB",
        "orderDate": "2024-11-17T15:26:12.224888",
        "orderStatus": "ORDER",
        "address": {
            "city": "경기",
            "street": "2",
            "zipCode": "2222"
        },
        "orderItems": [
            {
                "itemName": "SPRING BOOK 1",
                "orderPrice": 10000,
                "count": 1
            },
            {
                "itemName": "SPRING BOOK 2",
                "orderPrice": 20000,
                "count": 2
            }
        ]
    }
]

• 아주 깔끔하게 딱 페이징이 된 모습이다.
• 그런데 이걸 실행했을 때 날라가는 쿼리를 보면 굉장히 많이 나갈 수 밖에 없다. 왜냐하면 OrderItems는 지연로딩이고 이 값을 초기화하기 위한 쿼리가 모두 나가야하기 때문이다.

그럼 여기서 일대다 관계에 있는 데이터인 OrderItems는 페치 조인으로 적용하지 않았기 때문에 반환값으로 이 데이터를 보여주려면 프록시 초기화가 진행된다. 초기화하기 위해 추가적으로 날라가는 많은 쿼리들을 어떻게 최적화하면 될까? 다음과 같이 적용하면 된다.

application.yaml

...
  jpa:
    properties:
      hibernate:
        default_batch_fetch_size: 100
...

• jpa.properties.hibernate 하위에 다음과 같은 프로퍼티가 있다: `default_batch_fetch_size`.
• 이 값을 적절하게 넣어주면 프록시 초기화를 할 때, 한번에 저 개수만큼 초기화하는 쿼리가 날라간다. 
• 바로 쿼리로 확인해보자.

우선, 가장 먼저 Order와 Member, Delivery를 조인하는 쿼리가 나간다. 

    select
        o1_0.order_id,
        d1_0.delivery_id,
        d1_0.city,
        d1_0.street,
        d1_0.zip_code,
        d1_0.status,
        m1_0.member_id,
        m1_0.city,
        m1_0.street,
        m1_0.zip_code,
        m1_0.name,
        o1_0.order_date,
        o1_0.status 
    from
        orders o1_0 
    join
        member m1_0 
            on m1_0.member_id=o1_0.member_id 
    join
        delivery d1_0 
            on d1_0.delivery_id=o1_0.delivery_id 
    offset
        ? rows 
    fetch
        first ? rows only

그 다음은, OrderItems의 값을 가져와야 하므로 프록시 초기화를 하고 초기화 하기 위해 쿼리를 날리는데, 이렇게 날라간다.

    select
        oi1_0.order_id,
        oi1_0.order_item_id,
        oi1_0.count,
        oi1_0.item_id,
        oi1_0.order_price 
    from
        order_item oi1_0 
    where
        oi1_0.order_id=?

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

    select
        i1_0.item_id,
        case 
            when i1_1.item_id is not null 
                then 1 
            when i1_2.item_id is not null 
                then 2 
            when i1_3.item_id is not null 
                then 3 
        end,
        i1_0.name,
        i1_0.price,
        i1_0.stock_quantity,
        i1_1.artist,
        i1_1.etc,
        i1_2.author,
        i1_2.isbn,
        i1_3.actor,
        i1_3.director 
    from
        item i1_0 
    left join
        album i1_1 
            on i1_0.item_id=i1_1.item_id 
    left join
        book i1_2 
            on i1_0.item_id=i1_2.item_id 
    left join
        movie i1_3 
            on i1_0.item_id=i1_3.item_id 
    where
        i1_0.item_id in (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)

• 참고로, 나는 Item과 Album, Book, Movie를 조인 전략을 사용해서 상속 관계 매핑을 정의했기 때문에 OrderItem을 가져오고 OrderItem에 있는 Item의 실제 데이터를 가져오기 위해 Album, Book, Movie와 조인하는 쿼리 한번이 더 나간다. 만약, Item과 Album, Book, Movie를 싱글 테이블 전략을 사용했다면 조인하는 쿼리가 나가지 않을 것이다. 이건 테이블 매핑 전략을 어떻게 사용하느냐에 따라 달라진다.
• 그래서, OrderItem을 가져오는 쿼리를 한번 날린다. 근데 OrderItem에는 Item이 있고 이 Item은 Album, Book, Movie 중 하나이기 때문에 조인 쿼리를 하나 더 날리는데 그때, IN 키워드로 100개의 ID가 한번에 날라간다.
• 이게 바로 default_batch_fetch_size가 적용된 결과다. 만약, 이 값이 적용되지 않았다면, OrderItem에 있는 Item 마다마다 그 값을 가져오기 위한 쿼리가 나갔을 것이다.

일대다 페치조인의 한계돌파 결론

결론적으로, 이 일대다 관계를 가지고 있는 엔티티(OrderItems)가 있는 엔티티(Order)를 페치 조인으로 페이징 할 때는 1. 일대다 관계의 엔티티를 페치 조인에서 전부다 제거하고, 2. ToOne 관계에 있는 모든 엔티티는 페치조인을 사용해서 최대한 여러번의 쿼리가 나가는 것을 방지한 다음, 페이징을 처리해서 원하는 데이터를 원하는 수만큼 가져온다. 그런데 여기서 반환해야 하는 데이터에 컬렉션 데이터가 필요한 경우 그 값들을 채우기 위해 프록시 초기화가 발생하기에 추가적으로 나가는 쿼리를 최대한 최적화하기 위해, 3. default_batch_fetch_size 옵션을 설정해서 한번에 설정한 값만큼 데이터를 가져오도록 최적화한다. 

그리고 이 default_batch_fetch_size 옵션은 글로벌 옵션이다. 그래서 전체에 적용이 되는데, 만약에 특정 부분만 적용하고 싶은 경우 이렇게 하면 된다.

Order 엔티티 일부분

package cwchoiit.shoppingmall.domain;

import jakarta.persistence.*;
import lombok.AccessLevel;
import lombok.Getter;
import lombok.NoArgsConstructor;
import org.hibernate.annotations.BatchSize;

import java.time.LocalDateTime;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

@Entity
@Getter
@Table(name = "orders")
@NoArgsConstructor(access = AccessLevel.PROTECTED) // 생성 메서드를 만들었으면 그 메서드로만 인스턴스를 생성할 수 있도록 막아야 함
public class Order {
    ...

    @BatchSize(size = 100)
    @OneToMany(mappedBy = "order", fetch = FetchType.LAZY, cascade = CascadeType.ALL)
    private List<OrderItem> orderItems = new ArrayList<>();
    
    ...
}

• 이런식으로 필드에 @BatchSize 애노테이션을 붙여주면 된다. 근데 이건 컬렉션 필드에는 이렇게 적용하면 되는데 ToOne에는 이렇게 적용하면 안되고 다음과 같이 적용해야 한다.

OrderItem 일부분

package cwchoiit.shoppingmall.domain;

import com.fasterxml.jackson.annotation.JsonIgnore;
import jakarta.persistence.*;
import lombok.AccessLevel;
import lombok.Getter;
import lombok.NoArgsConstructor;
import org.hibernate.annotations.BatchSize;

@BatchSize(size = 100)
@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class OrderItem {

    ...

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "order_id")
    private Order order;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "item_id")
    private Item item;

    ...
}

• 이렇게 OrderItem에 ToOne 관계로 Order, Item이 있는데 이 녀석들에도 배치 사이즈를 부여하고 싶으면 클래스 레벨에 @BatchSize를 붙여주면 된다.

근데 보통은 그냥, 글로벌로 적용해두면 좋다. 그냥 기본으로 깔고 간다고 생각하면 좋다.

참고로, 이 default_batch_fetch_size값의 최대값은 1000이다.

자, 이렇게 일대다 페치 조인의 한계까지 해결해보고 지연로딩도 어떻게 해결해야 하는지 Part.1부터 걸쳐서 알아봤다. 여기까지 완벽히 이해하면 JPA로 성능 문제의 90%는 해결할 수 있다. 

번외: 컬렉션도 DTO로 바로 조회하기

이 컬렉션을 데이터베이스에서 가져와야 할 때도 SELECT절에 DTO로 직접 조회가 가능하다. 한번 이 부분도 다뤄보자. 

Part.1 에서 만들었었던 OrderQueryRepository를 기억하는가? 어떤 특정 화면에 종속적인 그러니까 순수한 Repository가 아니라 어딘가에 핏하게 종속되는데 사용되는 쿼리만 따로 모아두는 레포지토리를 만들었었다. 여기서 DTO로 직접 받아서 딱 필요한 필드들만 메모리에 올리게끔 최적화를 해본 적이 있는데 이걸 그대로 사용해보자.

우선, DTO부터 만들어야 한다.

package cwchoiit.shoppingmall.repository.order;

import cwchoiit.shoppingmall.domain.Address;
import cwchoiit.shoppingmall.domain.OrderStatus;
import lombok.Data;

import java.time.LocalDateTime;
import java.util.List;

@Data
public class OrderQueryDto {
    private Long orderId;
    private String name;
    private LocalDateTime orderDate;
    private OrderStatus orderStatus;
    private Address address;
    private List<OrderItemQueryDto> orderItems;

    public OrderQueryDto(Long orderId, String name, LocalDateTime orderDate, OrderStatus orderStatus, Address address) {
        this.orderId = orderId;
        this.name = name;
        this.orderDate = orderDate;
        this.orderStatus = orderStatus;
        this.address = address;
    }
}

package cwchoiit.shoppingmall.repository.order;

import lombok.Data;

@Data
public class OrderItemQueryDto {

    private Long orderId;
    private String itemName;
    private int orderPrice;
    private int count;

    public OrderItemQueryDto(Long orderId, String itemName, int orderPrice, int count) {
        this.orderId = orderId;
        this.itemName = itemName;
        this.orderPrice = orderPrice;
        this.count = count;
    }
}

• DTO를 두개 만들었다. 왜냐하면 Order를 위한 DTO와 OrderItems를 위한 DTO.

OrderQueryRepository

package cwchoiit.shoppingmall.repository.order;

import cwchoiit.shoppingmall.dto.SimpleOrderQuery;
import jakarta.persistence.EntityManager;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;

import java.util.List;

@Repository
@RequiredArgsConstructor
public class OrderQueryRepository {

    private final EntityManager entityManager;

    public List<SimpleOrderQuery> findOrderByDTO() {
        return entityManager.createQuery(
                        "SELECT new cwchoiit.shoppingmall.dto.SimpleOrderQuery(o.id, m.name, o.orderDate, o.status, d.address) " +
                                "FROM Order o " +
                                "JOIN o.member m " +
                                "JOIN o.delivery d", SimpleOrderQuery.class)
                .getResultList();
    }

    public List<OrderQueryDto> findOrderQueries() {
        List<OrderQueryDto> results = entityManager.createQuery(
                        "SELECT new cwchoiit.shoppingmall.repository.order.OrderQueryDto(o.id, m.name, o.orderDate, o.status, o.delivery.address) " +
                                "FROM Order o " +
                                "JOIN o.member m " +
                                "JOIN o.delivery d", OrderQueryDto.class)
                .getResultList();

        results.forEach(r -> {
            List<OrderItemQueryDto> orderItems =  findOrderItems(r.getOrderId());
            r.setOrderItems(orderItems);
        });

        return results;
    }

    private List<OrderItemQueryDto> findOrderItems(Long orderId) {
        return entityManager.createQuery(
                "SELECT new cwchoiit.shoppingmall.repository.order.OrderItemQueryDto(oi.order.id, i.name, oi.orderPrice, oi.count) " +
                        "FROM OrderItem oi " +
                        "JOIN oi.item i " +
                        "WHERE oi.order.id = :orderId", OrderItemQueryDto.class)
                .setParameter("orderId", orderId)
                .getResultList();
    }
}

• 지금 추가한 부분은 딱 두 부분이다. 하나씩 살펴보자.

public List<OrderQueryDto> findOrderQueries() {
    List<OrderQueryDto> results = entityManager.createQuery(
                    "SELECT new cwchoiit.shoppingmall.repository.order.OrderQueryDto(o.id, m.name, o.orderDate, o.status, o.delivery.address) " +
                            "FROM Order o " +
                            "JOIN o.member m " +
                            "JOIN o.delivery d", OrderQueryDto.class)
            .getResultList();

    results.forEach(r -> {
        List<OrderItemQueryDto> orderItems =  findOrderItems(r.getOrderId());
        r.setOrderItems(orderItems);
    });

    return results;
}

• 먼저, DTO로 직접 필요한 필드들만 받기 위해 SELECT절에 new 키워드를 사용해서 DTO로 직접 받고 있다. 그리고 이때도 마찬가지로 컬렉션 데이터는 조인해서 가져오지 않는다. 애시당초에 DTO로 조회를 할 때 컬렉션 데이터는 데이터베이스에서 바로 붙일수도 없다. 이건 위에서 말한 일대다 페치 조인을 할 때 페이징에 대한 한계를 돌파하는 방법이랑은 또 다른 얘기다. 그냥 DTO로 받아올때 필드에 컬렉션이 있으면 그 컬렉션에 데이터베이스에서 값을 한번에 넣어줄 수가 없다.
• 그래서, 우선 컬렉션을 제외하고 DTO로 데이터를 다 받아오면 이 데이터를 가지고 루프를 돌아야 한다. 그 부분이 바로 다음 results.forEach(...) 이 부분이다.

private List<OrderItemQueryDto> findOrderItems(Long orderId) {
    return entityManager.createQuery(
            "SELECT new cwchoiit.shoppingmall.repository.order.OrderItemQueryDto(oi.order.id, i.name, oi.orderPrice, oi.count) " +
                    "FROM OrderItem oi " +
                    "JOIN oi.item i " +
                    "WHERE oi.order.id = :orderId", OrderItemQueryDto.class)
            .setParameter("orderId", orderId)
            .getResultList();
}

• 그래서 이제 순회하면서 Order 레코드 하나하나가 이 메서드를 하나씩 실행한다. 이 메서드는 OrderItem으로부터 데이터를 받아오는데 이 역시 DTO로 직접 받아 온다.
• 그런데, WHERE절에서 특정 Order의 ID 조건을 넣어서 해당하는 데이터만 가져온다.
• 그래서 아래 코드를 보면, 순회하면서 실행한 후 이렇게 받아온 데이터를 r.setOrderItems(...)를 호출해서 넣어준다. 조금 귀찮지만 DTO로 직접 받아올때 컬렉션 데이터를 받을 수 있는 유일한 방법이다.

results.forEach(r -> {
    List<OrderItemQueryDto> orderItems =  findOrderItems(r.getOrderId());
    r.setOrderItems(orderItems);
});

그리고 컨트롤러에서 이 메서드를 이제 실행한다.

OrderController 일부분

@GetMapping("/api/v4/orders")
public List<OrderQueryDto> ordersV4() {
    return orderQueryRepository.findOrderQueries();
}

실행 결과는 다음과 같다. 결과는 똑같이 나오겠지만 쿼리를 보자.

    select
        o1_0.order_id,
        m1_0.name,
        o1_0.order_date,
        o1_0.status,
        d1_0.city,
        d1_0.street,
        d1_0.zip_code 
    from
        orders o1_0 
    join
        member m1_0 
            on m1_0.member_id=o1_0.member_id 
    join
        delivery d1_0 
            on d1_0.delivery_id=o1_0.delivery_id
            
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

    select
        oi1_0.order_id,
        i1_0.name,
        oi1_0.order_price,
        oi1_0.count 
    from
        order_item oi1_0 
    join
        item i1_0 
            on i1_0.item_id=oi1_0.item_id 
    where
        oi1_0.order_id=?
        
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

    select
        oi1_0.order_id,
        i1_0.name,
        oi1_0.order_price,
        oi1_0.count 
    from
        order_item oi1_0 
    join
        item i1_0 
            on i1_0.item_id=oi1_0.item_id 
    where
        oi1_0.order_id=?

• 최초에 Order를 가져오는 쿼리는 당연히 나간다.
• 그런데, 그 Order의 Item들을 가져오는 쿼리가 개수만큼 나가고 있다. 어찌보면 당연한게 가져온 Order 데이터들로 순회하면서 OrderItem을 DTO로 받아오기 위해 호출하는 메서드가 있기 때문에 당연한건데 이것 역시 N + 1 문제이다.
• 이 부분을 해결해야 한다.

다음 코드는 N + 1 문제를 해결하는 방법이다. 하나씩 보면서 살펴보자.

public List<OrderQueryDto> findOrderQueries2() {
    List<OrderQueryDto> results = entityManager.createQuery(
                    "SELECT new cwchoiit.shoppingmall.repository.order.OrderQueryDto(o.id, m.name, o.orderDate, o.status, o.delivery.address) " +
                            "FROM Order o " +
                            "JOIN o.member m " +
                            "JOIN o.delivery d", OrderQueryDto.class)
            .getResultList();

    List<Long> orderIds = results.stream().map(OrderQueryDto::getOrderId).toList();

    List<OrderItemQueryDto> orderItems = entityManager.createQuery(
                    "SELECT new cwchoiit.shoppingmall.repository.order.OrderItemQueryDto(oi.order.id, i.name, oi.orderPrice, oi.count) " +
                            "FROM OrderItem oi " +
                            "JOIN oi.item i " +
                            "WHERE oi.order.id IN :orderIds", OrderItemQueryDto.class)
            .setParameter("orderIds", orderIds)
            .getResultList();

    /**
     * orderItem: OrderItemQueryDto(orderId=1, itemName=JPA BOOK 1, orderPrice=10000, count=1)
     * orderItem: OrderItemQueryDto(orderId=1, itemName=JPA BOOK 2, orderPrice=20000, count=2)
     * orderItem: OrderItemQueryDto(orderId=2, itemName=SPRING BOOK 1, orderPrice=10000, count=1)
     * orderItem: OrderItemQueryDto(orderId=2, itemName=SPRING BOOK 2, orderPrice=20000, count=2)
     *
     * 이렇게 orderItems 가 있으면, 이걸 orderId 로 groupingBy를 하면
     * <1, [OrderItemQueryDto(orderId=1, itemName=JPA BOOK 1, orderPrice=10000, count=1), OrderItemQueryDto(orderId=1, itemName=JPA BOOK 2, orderPrice=20000, count=2)]>
     * <2, [OrderItemQueryDto(orderId=2, itemName=SPRING BOOK 1, orderPrice=10000, count=1), OrderItemQueryDto(orderId=2, itemName=SPRING BOOK 2, orderPrice=20000, count=2)]>
     * 이렇게 된다.
     */
    Map<Long, List<OrderItemQueryDto>> orderItemMap = orderItems.stream()
            .collect(Collectors.groupingBy(OrderItemQueryDto::getOrderId));

    results.forEach(r -> r.setOrderItems(orderItemMap.get(r.getOrderId())));

    return results;
}

List<OrderQueryDto> results = entityManager.createQuery(
            "SELECT new cwchoiit.shoppingmall.repository.order.OrderQueryDto(o.id, m.name, o.orderDate, o.status, o.delivery.address) " +
                    "FROM Order o " +
                    "JOIN o.member m " +
                    "JOIN o.delivery d", OrderQueryDto.class)
    .getResultList();

• 우선, findOrderQueries()와 동일하게 처음은 Order 관련 데이터를 DTO로 바로 받아온다. 이때, Member, Delivery와 같은 ToOne 관계만 조인하는 것 역시 동일하다.

List<Long> orderIds = results.stream().map(OrderQueryDto::getOrderId).toList();

List<OrderItemQueryDto> orderItems = entityManager.createQuery(
                "SELECT new cwchoiit.shoppingmall.repository.order.OrderItemQueryDto(oi.order.id, i.name, oi.orderPrice, oi.count) " +
                        "FROM OrderItem oi " +
                        "JOIN oi.item i " +
                        "WHERE oi.order.id IN :orderIds", OrderItemQueryDto.class)
        .setParameter("orderIds", orderIds)
        .getResultList();

• 이제 여기가 변하는 지점인데, 기존에는 가져온 Order 데이터들로 순회하면서 본인의 OrderItems를 하나씩 DTO로 받아왔다. 그러다보니 N + 1 문제가 발생한 것인데, 여기서는 그 부분을 해결하기 위해 가져온 Order 데이터들의 ID값을 모두 추출한 후 WHERE절에 IN 키워드로 한번에 모두 해당하는 데이터를 가져온다. 이렇게 N + 1 문제를 해결할 수 있다.

Map<Long, List<OrderItemQueryDto>> orderItemMap = orderItems.stream()
                .collect(Collectors.groupingBy(OrderItemQueryDto::getOrderId));

results.forEach(r -> r.setOrderItems(orderItemMap.get(r.getOrderId())));

• 이제 OrderItems를 모두 받아왔으면, OrderQueryDto에 OrderItems에 값을 넣어줘야 한다. 이때, 자기의 OrderItems을 컬렉션으로 넣어주기 위해 가져온 orderItems를 가지고 Collectors.groupingBy(OrderItemQueryDto::getOrderId)를 사용한다. 이건뭐냐면, 리스트를 맵으로 변경하는데 이때 그룹핑을 할 수가 있다. 각 리스트의 요소인 orderId로.
• 이 부분의 자세한 동작은 주석으로 설명을 추가해놨다. 다시 한번 주석을 보여주면 이렇게 생각하면 된다.

/**
 * orderItem: OrderItemQueryDto(orderId=1, itemName=JPA BOOK 1, orderPrice=10000, count=1)
 * orderItem: OrderItemQueryDto(orderId=1, itemName=JPA BOOK 2, orderPrice=20000, count=2)
 * orderItem: OrderItemQueryDto(orderId=2, itemName=SPRING BOOK 1, orderPrice=10000, count=1)
 * orderItem: OrderItemQueryDto(orderId=2, itemName=SPRING BOOK 2, orderPrice=20000, count=2)
 *
 * 이렇게 orderItems 가 있으면, 이걸 orderId 로 groupingBy를 하면
 * <1, [OrderItemQueryDto(orderId=1, itemName=JPA BOOK 1, orderPrice=10000, count=1), OrderItemQueryDto(orderId=1, itemName=JPA BOOK 2, orderPrice=20000, count=2)]>
 * <2, [OrderItemQueryDto(orderId=2, itemName=SPRING BOOK 1, orderPrice=10000, count=1), OrderItemQueryDto(orderId=2, itemName=SPRING BOOK 2, orderPrice=20000, count=2)]>
 * 이렇게 된다.
 */

이러면, 이제 OrderItems가 몇개가 됐건, 딱 2번의 쿼리(Order 데이터를 가져오는 쿼리, 각 Order에 있는 OrderItems를 한번에 다 가져오는 쿼리)만 나가게 된다. 이렇게 컬렉션도 DTO로 직접 조회를 할 수 있고 N + 1 문제도 해결할 수 있게 된 것이다.

근데 지금 보면 SELECT절에 DTO로 직접 받아오는게 생각보다 만만치 않다. 귀찮기도 하고, 무엇보다 그냥 페치 조인을 사용해서 전체 필드에 값을 다 박을때보다 코드양이 너무 길어진다. 그래서 SELECT절에 DTO로 딱 필요한 것만 받아오면 아무래도 모든 데이터를 퍼올리는 페치 조인보다는 성능적인 부분에서 장점이 있지만, 코드의 가시성이나 더 많은 코드를 수행하는 부분에서는 성능적인 단점이 또 있다. 즉, 트레이드 오프가 있다는 말이다.

정리를 하자면

컬렉션이 있는 엔티티를 조회할 때 여러 난관이 있다. 대표적으로 페치 조인을 할 때 페이징이 불가능하다는 점이다. 그리고 이 문제를 해결하기 위해 페치 조인에서 컬렉션은 페치 조인에서 제외한 후 페이징을 하고 컬렉션 데이터를 초기화할 때 N + 1 문제를 BatchSize로 해결했다. 이게 가장 최적의 방법이고 사실 이 방법을 제외하고 방법도 없다. 

그리고, 마지막에는 DTO로 바로 조회하는 방법도 알아봤다. 이제 조회에 대해서는 다 배운것이다.

그럼 권장하는 방식을 정리해보면,

• SELECT절에 엔티티 조회? DTO 직접 조회? → 엔티티 조회로 우선 접근
• 컬렉션 최적화
  • 페이징 필요 → 컬렉션 데이터를 페치 조인에서 제외하고, default_batch_fetch_size를 사용해서 최적화
  • 페이징 필요 X → 페치 조인 사용
• SELECT절에 엔티티로 조회하는 방식으로 해결이 안되면 DTO 조회 방식을 사용
• 이도 저도 안되면 NativeSQL을 사용

컨트롤러에서 엔티티를 직접 반환하지 마라! 이유는 너무 많다.

• 엔티티를 반환하는 설계를 하면 엔티티의 변경이 생기면 API 스펙이 변경된다.
  • Member 엔티티의 name 필드를 username 필드로 변경하면, API 스펙 자체가 변경된다. 가져다가 사용하는 쪽은 매우 화가 난다.
• 엔티티에 양방향 연관관계가 있는 경우, 무한 재호출로 인한 무응답 현상이 일어난다.
  • 이후에 코드로 직접 살펴보자. 
• 엔티티에는 민감한 데이터가 있기도 하고, 굳이 외부로 노출시키지 않아도 되는 데이터가 있는데 그런 데이터까지 노출된다.
  • @JsonIgnore 애노테이션으로 막으면 되잖아요? → 다른 곳에서는 그 필드가 필요한 경우엔 어떡할래?
• 지연로딩으로 설정한 연관 엔티티를 처리하기가 매우 귀찮아진다. 

컨트롤러에서 엔티티를 직접 반환하면 생기는 문제들

이런 여러 문제가 있고 엔티티를 직접 노출하지 않는 코드를 작성해서 더 우아하게 JPA를 사용하자. 다음 코드를 보자.

@RestController
@RequiredArgsConstructor
public class OrderSimpleApiController {

    private final OrderRepository orderRepository;

    @GetMapping("/api/v1/simple-orders")
    public List<Order> ordersV1() {
        return orderRepository.findAllByCriteria(new OrderSearch());
    }
}

• Order 라는 엔티티를 직접 반환하고 있다. 일단 이걸 실행해보자.
• 아래와 같은 에러가 발생하고 뭔가 제대로 동작하지 않는다.

Ignoring exception, response committed already: org.springframework.http.converter.HttpMessageNotWritableException: Could not write JSON: Document nesting depth (1001) exceeds the maximum allowed (1000, from `StreamWriteConstraints.getMaxNestingDepth()`)

이게 무슨 일이냐면, Order로 들어가보자.

@Entity
@Getter
@Table(name = "orders")
@NoArgsConstructor(access = AccessLevel.PROTECTED) // 생성 메서드를 만들었으면 그 메서드로만 인스턴스를 생성할 수 있도록 막아야 함
public class Order {

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

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "member_id")
    private Member member;

    @OneToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL)
    @JoinColumn(name = "delivery_id")
    private Delivery delivery;

    @OneToMany(mappedBy = "order", fetch = FetchType.LAZY, cascade = CascadeType.ALL)
    private List<OrderItem> orderItems = new ArrayList<>();

    private LocalDateTime orderDate;

    @Enumerated(EnumType.STRING)
    private OrderStatus status;

    ....
}

• Order는 Member를 가지고 있다. Member로 들어가보자.

@Entity
@Getter
@Builder
@AllArgsConstructor
@NoArgsConstructor
@Table(
        indexes = {
                @Index(name = "idx_name", columnList = "name"),
                @Index(name = "idx_name_address", columnList = "name, city")
        }
)
public class Member {

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

    private String name;

    @Embedded
    private Address address;

    @OneToMany(mappedBy = "member", fetch = FetchType.LAZY)
    @Builder.Default
    private List<Order> orders = new ArrayList<>();


    public void change(String name) {
        this.name = name;
    }
}

• Member는 Order를 가지고 있다. 자꾸 서로가 서로를 호출하다가 더 이상 못하겠다! 라고 말하는 중이다.
• 이게 맨 위에서 설명한 무한 재호출이다.

그럼 이제, 이걸 해결하기 위해 혹시라도 @JsonIgnore 애노테이션을 사용했다고 해보자. 다음과 같이 말이다.

Order 일부분

@JsonIgnore
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "member_id")
private Member member;

...

이번에는 응답은 받았는데 뭔가 또 문제가 생겼다.

어떤 문제일까? 에러 내용은 다음과 같다.

com.fasterxml.jackson.databind.exc.InvalidDefinitionException: No serializer found for class org.hibernate.proxy.pojo.bytebuddy.ByteBuddyInterceptor and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationFeature.FAIL_ON_EMPTY_BEANS) (through reference chain: java.util.ArrayList[0]->cwchoiit.shoppingmall.domain.Order["member"]->cwchoiit.shoppingmall.domain.Member$HibernateProxy$UdxcWMDQ["hibernateLazyInitializer"])
...

• 결론부터 말하면 지연로딩으로 처리한 연관관계 엔티티를 반환하려 할 때 나 지연로딩이라 데이터를 돌려줄 수 없어! 라고 말하는 것이다.
• 이렇듯, 엔티티를 직접 노출하면 지연 로딩을 원하든 원치않든 무조건 다뤄야 한다는 또 하나의 단점이 있다.

그럼 이제 이 여러 문제를 어떻게 해결하면 될까? 

1. 엔티티를 DTO로 변환

우선, 가장 먼저 엔티티를 전부 제거해버려라. 그리고 엔티티를 반환하지 말고 DTO로 변환해서 반환해라. 다음 코드를 보자.

@GetMapping("/api/v2/simple-orders")
public List<SimpleOrderDTO> ordersV2() {
    return orderService.findOrders(new OrderSearch()).stream()
            .map(SimpleOrderDTO::new)
            .toList();
}

• OrderController에서 주문 데이터들을 반환하는데 반환값이 List<SimpleOrderDTO>이다. 즉, 이젠 엔티티를 반환하지 않고 DTO로 반환한다. (물론, 이 데이터를 응답 공통 객체로 감싸서 count, page, maxResults 등 추가 정보를 같이 넘기는게 일반적이다)
• 그리고 DTO는 어떻게 생겼냐면, 별게 없다. 

@Data
static class SimpleOrderDTO {
    private Long orderId;
    private String name;
    private LocalDateTime orderDate;
    private OrderStatus orderStatus;
    private Address address;

    public SimpleOrderDTO(Order order) {
        this.orderId = order.getId();
        this.name = order.getMember().getName();
        this.orderDate = order.getOrderDate();
        this.orderStatus = order.getStatus();
        this.address = order.getMember().getAddress();
    }
}

• 이너 클래스로 간단하게 만들어봤다. 다른 방식으로 해도 좋다. 
• 이 DTO는 곧 API 스펙이 되면 된다. 이제 API 스펙은 데이터를 orderId, name, orderDate, orderStatus, address 외 다른것은 넘기지 않게 서로 협의를 하면 끝이다. 이러면 Order 엔티티에 변경이 생겨도 이 API 스펙만 유지해줄 수 있다면 아무런 문제도 발생하지 않게 된다.

그럼 실제로 결과를 보자. 아래와 같이 데이터가 잘 나간다. 

그럼 이대로 괜찮을까? 아니다. 왜냐? 지연 로딩에 대한 문제가 여전히 남아있다. 나간 쿼리를 로그로 확인해보자.

• 우선, 첫번째로 Order에 대해 조회를 하기 때문에 당연히 Order 관련 쿼리가 처음으로 나간다. 그리고 그 쿼리엔 Member와 조인하는 것도 있기 때문에 멤버를 조인한다.
• 그런데 이게 조인을 한다고 해서 바로 지연로딩으로 설정한 연관관계들의 데이터를 다 가져오는 게 아니라, 지연로딩으로 설정한 녀석들은 프록시로 만들어 돌려준다. 이게 JPA의 규칙이다. (페치 조인과 헷갈리면 안된다. 애시당초에 데이터베이스에는 페치 조인이라는 개념 자체가 없다. 이 페치 조인은 JPA에서 사용하는 것이다)
• 그리고 실제로 이 프록시를 초기화할때, 그러니까 위 코드에서는 엔티티를 DTO로 변환할 때 생성자에서 order.getMember().getName()과 같은 메서드를 실행하는 순간, JPA는 "어? 멤버가 필요하구나? 초기화 해야겠다!"라고 판단하고 해당 데이터를 가져오기 위해 쿼리를 날린다.
• 그럼 결론적으로 Order에 대한 조회를 했고 데이터가 2개가 나왔다. 그 각각의 레코드에는 멤버 관련 데이터도 있어야 하지만 우선은 지연로딩이기 때문에 바로 데이터를 가져오는게 아니라 프록시로 만들어둔다. 그리고 이후에 해당 프록시를 초기화하는 순간, 그 데이터를 뽑아오기 위해 쿼리를 날리게 된다. 그 얘기는 Order가 10개고 각각의 주문이 모두 다 다른 유저라면 1 + 10개의 쿼리가 나가는 것이다. 이게 바로 N + 1 문제이고. 만약, 지연 로딩으로 설정한 연관관계가 더 많고 그 연관관계의 엔티티를 모두 프록시 초기화를 한다면 10개보다 더 나갈것이다.

결론은, 엔티티를 DTO로 변환하는 것으로 API 스펙이 바뀌는 문제를 해결하고 불필요한 데이터를 외부로 노출하지 않게 됐지만 여기서 끝내면 안된다는 것이다!

2. 페치조인을 사용해 N +1 문제 해결 

이제 정말 JPA에서 정말 중요한 페치 조인을 사용해서 딱 한번의 쿼리로 원하는 데이터를 다 가져와보자!

아래와 같이 GET 매핑을 하나 더 만들자.

@GetMapping("/api/v3/simple-orders")
public List<SimpleOrderDTO> ordersV3() {
    return orderRepository.findAllWithMemberDelivery().stream()
            .map(SimpleOrderDTO::new)
            .toList();
}

그리고, OrderRepository에서 다음과 같은 메서드를 하나 만든다.

public List<Order> findAllWithMemberDelivery() {
    return entityManager
            .createQuery(
                    "SELECT o " +
                            "FROM Order o " +
                            "JOIN FETCH o.member m " +
                            "JOIN FETCH o.delivery d", Order.class)
            .getResultList();
}

• JPQL 부분을 보면, JOIN FETCH 라는 키워드가 있다. 그냥 JOIN이 아니다! 
• JOIN FETCH는 JPA에서 제공해주는 기능인데 조인을 한 후 데이터를 모두 넣어서 한번에 돌려준다.
• 그래서 지연로딩의 프록시 데이터도 프록시 초기화를 할 필요가 없어진다. 

나가는 쿼리를 한번 확인해보자! 아래와 같이 딱 한번의 쿼리로 모든 데이터를 다 받아왔고, 더 이상 쿼리가 나가지 않는다.

V2와 달랐던 점은, JOIN을 한다고 해도 그 엔티티가 지연로딩이면 바로 데이터를 넣어주는 게 아니라 프록시로 만들어서 실제로 필요한 시점에 메서드를 호출하면 그때 비로소 프록시가 초기화 되면서 그 값을 가져오기 위해 쿼리를 추가적으로 날렸는데 지금은 아예 처음부터 데이터를 다 가져와버린다. 이렇게 해서 N+1 문제를 해결할 수 있다. 

그런데, 한가지만 더 최적화해보자. 지금은 모든 필드가 SELECT절에 다 걸린다. 막상 필요한 데이터만 있을 수도 있는데 이건 다 걸려있기 때문에 이 부분마저 최적화해보자.

3. SELECT 절을 DTO로 받기

일단 위에서 사용한 페치 조인과 컨트롤러에서 엔티티를 직접 반환하는 게 아니라 DTO로 변환하여 반환하는 이 두가지 기법을 사용하면 거의 모든 대부분의 성능 문제? API 스펙 문제? 해결 된다. 근데, 위 쿼리를 보면 알겠지만 모든 필드를 다 SELECT절에서 받기 때문에 아무렴 DB에서 데이터를 메모리에 많이 퍼올리게 된다. 

만약, 어떤 유저가 주문한 [주문 내역]이라는 화면에 들어갔을때 보여져야 할 필드들이 주문번호, 주문자명, 배달위치, 주문일시, 주문상태 이렇게 딱 5개만 필요하다고 해보자. 그럼 저 나머지 필드들은 의미없이 메모리에 데이터를 퍼올리는 셈이 된다. 

그래서, 이 경우에 SELECT절 자체를 DTO로 받아볼 수 있다. 다음 코드를 보자.

OrderRepository 일부분

public List<SimpleOrderQuery> findOrderByDTO() {
    return entityManager.createQuery(
            "SELECT new cwchoiit.shoppingmall.dto.SimpleOrderQuery(o.id, m.name, o.orderDate, o.status, d.address) " +
                    "FROM Order o " +
                    "JOIN o.member m " +
                    "JOIN o.delivery d", SimpleOrderQuery.class)
            .getResultList();
}

• 지금 보면, SELECT 절에 new로 DTO 클래스를 사용하고 있다. 그래서 딱 원하는 데이터만 넣어주고 있다. 
• 이렇게 해서 반환 자체를 저 DTO의 리스트로 반환하면 된다.

SimpleOrderQuery

package cwchoiit.shoppingmall.dto;

import cwchoiit.shoppingmall.domain.Address;
import cwchoiit.shoppingmall.domain.OrderStatus;
import lombok.Data;

import java.time.LocalDateTime;

@Data
public class SimpleOrderQuery {

    private Long orderId;
    private String name;
    private LocalDateTime orderDate;
    private OrderStatus orderStatus;
    private Address address;

    public SimpleOrderQuery(Long orderId, String name, LocalDateTime orderDate, OrderStatus orderStatus, Address address) {
        this.orderId = orderId;
        this.name = name;
        this.orderDate = orderDate;
        this.orderStatus = orderStatus;
        this.address = address;
    }
}

• 이렇게 DTO를 만들었다.

OrderController 일부분

@GetMapping("/api/v4/simple-orders")
public List<SimpleOrderQuery> ordersV4() {
    return orderRepository.findOrderByDTO();
}

• 컨트롤러는 단지 위임만 하고 있다.

이렇게 하고 실행해보면, 다음과 같이 딱 우리가 필요한 필드들만 SELECT절에서 받아오고 있음을 확인할 수 있다. 그리고 더이상의 쿼리는 나가지 않는다. "어? 페치 조인이 아닌데 왜 지연로딩을 초기화하는 쿼리가 안나가요?" → DTO로 SELECT절을 받을때, 생성자로 넘겨주는 값 자체를 넘겼으니 그때 그 값을 가져와야 하므로 이미 쿼리를 날릴때 필요한 필드들을 모두 메모리에 퍼 올리게 된다.

이러면, 정말 극한의 최적화가 완성이 되는데.. 이 방법은 트레이드 오프가 있다.

• SELECT절이 지저분해진다. 아래와 같이 패키지 명까지 모두 작성을 해줘야하는 번거로움이 있다.

• Repository의 순수함이 사라진다.
  • 이 말은 무슨말이냐면, Repository는 결국 엔티티에 의존해야 한다. 그 외 어떤것에도 의존하지 않는게 가장 좋은 방법이다. 그런데 지금 같은 경우, 좁게 보면 DTO(SimpleOrderQuery)에 의존하고 있으며 넓게 보면 화면 하나에 의존하고 있다.
  • 화면 하나에 의존한다는 말은 우리가 [주문 내역]이라는 화면에서 필요한 데이터만을 위해 지금 이 쿼리를 만들었단 뜻이다. 
  • 다음 전체 코드를 보자. 이 메서드가 만들어지기 전까지 이 레포지토리는 오로지 Order 라는 엔티티에만 의존하고 있었다.

OrderRepository

package cwchoiit.shoppingmall.repository;

import cwchoiit.shoppingmall.domain.Order;
import cwchoiit.shoppingmall.dto.OrderSearch;
import cwchoiit.shoppingmall.dto.SimpleOrderQuery;
import jakarta.persistence.EntityManager;
import jakarta.persistence.criteria.*;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;
import org.springframework.util.StringUtils;

import java.util.ArrayList;
import java.util.List;

@Repository
@RequiredArgsConstructor
public class OrderRepository {

    private final EntityManager entityManager;

    public void save(Order order) {
        entityManager.persist(order);
    }

    public Order findById(Long id) {
        return entityManager.find(Order.class, id);
    }

    public List<Order> findAllByCriteria(OrderSearch orderSearch) {
        CriteriaBuilder cb = entityManager.getCriteriaBuilder();
        CriteriaQuery<Order> cq = cb.createQuery(Order.class);

        Root<Order> o = cq.from(Order.class);
        Join<Object, Object> m = o.join("member", JoinType.INNER);

        List<Predicate> predicates = new ArrayList<>();

        if (orderSearch.getOrderStatus() != null) {
            Predicate status = cb.equal(o.get("status"), orderSearch.getOrderStatus());
            predicates.add(status);
        }

        if (StringUtils.hasText(orderSearch.getMemberName())) {
            Predicate name = cb.like(m.get("name"), "%" + orderSearch.getMemberName() + "%");
            predicates.add(name);
        }

        cq.where(cb.and(predicates.toArray(new Predicate[0])));

        return entityManager
                .createQuery(cq)
                .setMaxResults(1000)
                .getResultList();
    }

    public List<Order> findAllWithMemberDelivery() {
        return entityManager.createQuery(
                        "SELECT o " +
                                "FROM Order o " +
                                "JOIN FETCH o.member m " +
                                "JOIN FETCH o.delivery d", Order.class)
                .getResultList();
    }

    public List<SimpleOrderQuery> findOrderByDTO() {
        return entityManager.createQuery(
                        "SELECT new cwchoiit.shoppingmall.dto.SimpleOrderQuery(o.id, m.name, o.orderDate, o.status, d.address) " +
                                "FROM Order o " +
                                "JOIN o.member m " +
                                "JOIN o.delivery d", SimpleOrderQuery.class)
                .getResultList();
    }
}

• 전부 다 반환값으로 Order 엔티티를 반환하고 있고, 사실 이게 가장 모범적인 방식이다. 마지막 findOrderByDTO()는 오로지 하나의 화면을 위해서 만들어진 메서드이지 범용적으로 사용할 수 없다.
• 그럼 방안은 없을까?

방안

그래서, 이런 경우 방안이 있는데, 이렇게 가장 기본이 되는 Repository는 순수한 Repository로 남겨두고 저런 특정 화면에 필요한 최적화된 쿼리들을 모아두는 Repository를 하나 더 만드는 것이다.

OrderQueryRepository

package cwchoiit.shoppingmall.repository.order;

import cwchoiit.shoppingmall.dto.SimpleOrderQuery;
import jakarta.persistence.EntityManager;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;

import java.util.List;

@Repository
@RequiredArgsConstructor
public class OrderQueryRepository {

    private final EntityManager entityManager;

    public List<SimpleOrderQuery> findOrderByDTO() {
        return entityManager.createQuery(
                        "SELECT new cwchoiit.shoppingmall.dto.SimpleOrderQuery(o.id, m.name, o.orderDate, o.status, d.address) " +
                                "FROM Order o " +
                                "JOIN o.member m " +
                                "JOIN o.delivery d", SimpleOrderQuery.class)
                .getResultList();
    }
}

• 이제 OrderQueryRepository를 따로 만들어서, 특정 화면이나 어떤 딱 필요한 부분에만 사용되는 쿼리들을 따로 모아두고 관리하는 것이다. 
• 이러면 두가지 장점이 생기는데 첫번째는 유지보수성이 좋아진다. 순수한 OrderRepository는 다시 오로지 엔티티에만 의존하고 있기 때문에 결합력이 약해진다. 두번째는 분리된 Repository로 인해 개발하는 개발자도 이 쿼리는 어딘가에 특정된 쿼리구나를 인식할 수 있게 한다. 

그리고 가져다가 사용하는 쪽도, 이렇게 변경해주면 된다. 

@GetMapping("/api/v4/simple-orders")
public List<SimpleOrderQuery> ordersV4() {
    return orderQueryRepository.findOrderByDTO();
}

• 물론 컨트롤러가 의존성이 더 추가됐지만, 컨트롤러는 얼마든지 그럴 수 있다.

결론

결론을 얘기하면 다음 순서를 따르자!

1. 무조건 컨트롤러는 엔티티 말고 DTO를 반환한다.
2. 필요하면 페치 조인으로 성능을 최적화한다. 대부분은 이걸로 성능 이슈가 해결된다.
3. 그래도 더욱 더욱 최적화 하고 싶다면 SELECT절을 DTO로 받아서 정말 딱 필요한 데이터만 메모리에 퍼올리자.
4. 아예 이것도 저것도 안되면, JPA가 제공하는 네이티브 SQL이나 스프링 JDBCTemplate을 사용해서 SQL을 직접 날린다.

자, 엔티티를 만들고 인덱스를 걸어보자. 그 전에 인덱스를 사용하는 이유가 무엇인지부터 좀 이해해보자.

아래 내가 작성한 링크에 인덱스를 사용하는 이유와 인덱스를 만들때 사용되는 구조에 대한 간략한 글을 작성했었다.

자, 이제 인덱스를 왜 만들고 인덱스가 왜 필요하고 어떻게 만들어지는지 어느정도 감을 잡았다면 JPA와 인덱스를 같이 사용해보자.

다음 코드를 보자. 매우 간단한 엔티티이다.

@Entity
@Table(name = "members", indexes = {
    @Index(name = "idx_username", columnList = "username")
})
public class Member {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false, unique = true)
    private String username;

    @Column(nullable = false)
    private String password;

    @Column(nullable = false)
    private String email;

}

• 지금 Member엔티티는 username 필드를 인덱스로 설정했다.
• 이제 검색 조건에 username이 들어가고, 그 빈도수가 잦다면, 인덱스를 통해 검색 최적화를 기대해 볼 수 있다.

그런데, 이런 상황도 있을 수 있다. "어? 저는 username, email 이 두개를 검색 조건으로 같이 사용하는 쿼리가 훨씬 많아요!" 그런 경우엔 복합 인덱스를 사용해서 조금 더 최적화를 기대해볼 수 있다. 다음 코드를 보자.

@Entity
@Table(name = "members", indexes = {
    @Index(name = "idx_username_email", columnList = "username, email")
})
public class Member {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false, unique = true)
    private String username;

    @Column(nullable = false, unique = true)
    private String email;

    @Column(nullable = false)
    private String password;

    // Getters and setters omitted for brevity
}

• 이번에는 username, email 이 두가지를 사용해서 복합 인덱스를 만들었다.
• 이 경우, 검색 조건으로 username, email 둘 다 사용될 때 가장 최적의 성능을 발휘한다.
• username만 검색 조건에 들어가는 경우엔 이 복합 인덱스를 사용할 순 있지만 username만 가지고 인덱스를 만든 단일 인덱스보단 성능이 덜 나올 수 있다. 여기서 인덱스 순서와 성능에 대한 이야기를 해볼 수 있다.
• 그리고 이 경우, 검색 조건에 email 만 사용되는 경우 이 인덱스를 사용할 수 없다. 인덱스가 username을 먼저 기준으로 하기 때문이다.

복합 인덱스를 사용할 때 인덱스 컬럼 순서

지금처럼 username, email 순으로 username을 먼저 인덱스 순서로 지정하면, 인덱스는 username을 먼저 기준으로 정렬하고, 그 다음으로 email을 정렬하는 구조가 된다. 그래서 실제 사용 패턴에 따른 인덱스를 설계할 땐 다음과 같이 고려해볼 수 있다.

• username을 더 자주 검색하는 경우: username, email 순으로 설정하는 것이 효율적이다. 
• email을 더 자주 검색하는 경우: email, username 순으로 설정하는 것이 효율적이다.

누군가는 이런 오해를 한다. 필드 선언 순서가 중요하다!? 큰일날 소리다! 배울 때 잘 배웠으면 좋겠다. 😮‍💨 그러니까 그 누군가가 말하는건 아래와 같은 내용이다. 

@Column(nullable = false, unique = true)
private String username;

@Column(nullable = false, unique = true)
private String email;

@Column(nullable = false, unique = true)
private String email;

@Column(nullable = false, unique = true)
private String username;

• 이렇게 필드를 선언하는 순서에 따라 인덱스의 성능이 달라진다고 오해를 하더라! 아니다! 이거 때문에 이 포스팅 만들었다.

중간 정리를 하자면

그래서 복합 인덱스는 첫 컬럼이 가장 중요한 역할을 하며, 두 번째 컬럼은 첫 번째 컬럼 조건이 있을 경우에만 추가로 최적화가 된다. 

두 컬럼을 동시에 사용한다는게 어떤건가요?

1. 두 컬럼을 모두 조건으로 사용하는 경우

SELECT * FROM members
WHERE username = 'john_doe' AND email = 'john@example.com';

그래서, 이런 경우에 저 복합 인덱스는 최적의 성능을 발휘할 수 있다. 

복합 인덱스를 만들어 두었는데 하나의 컬럼만 검색조건으로 사용하는 경우에는 그냥 사용할까요?

거의 대부분 두가지 컬럼 모두 조건으로 사용하는데 아주 가끔 하나만 사용하는 경우엔 그 녀석을 인덱스의 첫번째 순서로 설정하고 복합 인덱스를 사용하면 될 것 같다. 근데 빈번하게 각각의 컬럼 조건으로 검색을 할 때는 단일 인덱스를 따로 만들어 두는게 더 효율적이다. 

Dirty Checking과 Merge에 대한 제대로 된 이해를 위해 블로그를 작성하려고 한다. JPA를 사용할 때 엔티티를 어떻게 업데이트할까?에 대한 내용인데 결론부터 말하면 Merge를 사용하면 난 안된다고 생각한다. Merge를 사용하는건 변경감지가 아니라 Merge를 사용하는 확실한 이유가 있어야 한다고 본다. 

우선, 다음 코드를 보자. 예시 코드를 위해 최대한 간단하게 작성했다. 

@PostMapping("/items/edit")
public String updateItem(@ModelAttribute("form") BookForm form) {

    Book book = Book.builder()
            .id(form.getId())
            .name(form.getName())
            .price(form.getPrice())
            .stockQuantity(form.getStockQuantity())
            .author(form.getAuthor())
            .isbn(form.getIsbn())
            .build();

    itemService.saveItem(book);
    return "redirect:/";
}

• form으로 입력한 데이터를 전송받아, 엔티티 객체를 만들고 저장하는 메서드를 호출한다.
• 업데이트한다는 것은 이미 그 데이터가 데이터베이스에 있다는 소리고 그 말은 ID값을 이미 가지고 있기 때문에 form에서 해당 ID값을 전달받을 수도 있다는 말이다.

그리고 호출하는 ItemService.saveItem() 코드를 보자.

ItemService의 일부분

@Transactional
public void saveItem(Item item) {
    itemRepository.save(item);
}

ItemRepository의 일부분

public void save(Item item) {
    if (item.getId() == null) {
        entityManager.persist(item);
    } else {
        entityManager.merge(item);
    }
}

• ItemService는 그저 ItemRepository를 호출하는 위임 클래스 역할을 할 뿐이고, ItemRepository에서 ID값이 있는지 확인해서 ID값이 없다면 persist()를, 있다면 merge()를 호출한다.

이렇게 코드를 작성하면 문제없이 코드가 잘 동작할 것이다. 지금 이 코드는 병합을 통해 엔티티를 업데이트 한 것이다. 근데 이게 왜 문제가 될 수 있고 잘못된 것인지 알아야 한다. 

자, 병합은 사실 이런 행위를 한다.

merge(Item item) {
    Item findItem = itemRepository.findById(item.getId());

    findItem.setName(item.getName());
    findItem.setPrice(item.getPrice());
    findItem.setStockQuantity(item.getStockQuantity());
    
    그 외 모든 필드들 값 세팅...
}

• 우선, 넘겨받은 엔티티의 기본키를 통해 데이터베이스에서 해당 기본키를 가지고 있는 엔티티를 찾는다.
• 그 찾아온 엔티티의 정말 모든 필드를 넘겨받은 엔티티의 값으로 교체한다.
• 그리고 Dirty Checking을 통해 데이터를 업데이트한다.

이 코드의 문제가 뭘까? 실무에서의 업데이트는 전체 데이터를 모두 업데이트하는 경우보다 일부분을 업데이트하는 경우가 대부분일 것이다. 일단 실세계에서 생각해봐도 나만 해도 그렇다. 어떤 계정 정보를 업데이트할 때 계정 정보를 전체 다 업데이트한 적은 없다. 딱 필요한 몇 부분만 수정하곤 하지. 그 말은, 넘긴 데이터도 수정할 데이터만 일부 채워졌을 확률이 있다는 얘기고 나머지 필드에는 값이 안 채워져 있을 수도 있다는 얘기다. 근데 그 값을 그대로 병합해버리면? 기존에 있는 값을 null로 변경해버릴 것이다. 그러니까 이 말을 코드로 보면 아래와 같은 상황도 있을 수 있단 얘기다.

@PostMapping("/items/edit")
public String updateItem(@ModelAttribute("form") BookForm form) {

    Book book = Book.builder()
            .id(form.getId())
            .name(form.getName())
            //.price(form.getPrice())
            //.stockQuantity(form.getStockQuantity())
            //.author(form.getAuthor())
            //.isbn(form.getIsbn())
            .build();

    itemService.saveItem(book);
    return "redirect:/";
}

• 내가 수정하고자 하는 값은 책의 이름뿐이었기에 다른 값은 채우지 않았다. 그리고 업데이트한다.
• 이렇게 되면 저 Book이라는 객체의 나머지 필드들은 다 null이다.
• 병합을 하는 순간 기존에 있는 멀쩡한 데이터에 null이 채워질 것이다.

물론, 간단하고 제약이 잘 갖춰져 있고 딱 수정하고자 하는 값만 수정한다면 병합 시 문제를 해결할 수 있을지도 모른다. 근데 굳이 리스크를 스스로 끌어 안을 필요가 있을까? 그럼 Dirty Checking으로 어떻게 데이터를 변경하면 될까?

Dirty Checking을 통한 업데이트

가장 핵심은 이 변경감지는 영속성 컨텍스트가 관리하고 있는 엔티티여야 한다. 즉, 영속 상태의 엔티티만 변경 감지가 제대로 수행된다.

여기서 많은 실수가 일어나는데, 다음 코드를 보자.

예시를 위해 최대한 단순히 만들었다. 

@PostMapping("/items/edit")
public String updateItem(@ModelAttribute("form") BookForm form) {

    Book book = new Book();

    book.setId(form.getId());
    book.setName(form.getName());

    return "redirect:/";
}

• Book은 엔티티이다. 이 코드가 의도한건 엔티티의 일부 값을 변경했으니 변경감지가 일어나겠지?! 이다.
• 그러나 아무런 일도 일어나지 않을 것이다.

왜냐하면, 지금 이 Book은 영속성 컨텍스트가 관리하고 있는 대상이 아니기 때문이다. 그래서 준영속 엔티티나 영속되지 않은 엔티티에 변경감지를 기대하고 실수하는 경우가 자주 있다. 그럼 어떻게 해야하지?

1. 먼저 영속성 컨텍스트가 해당 엔티티를 영속한다.

@PostMapping("/items/{itemId}/edit")
public String updateItem(@PathVariable("itemId") Long itemId, @ModelAttribute("form") BookForm form) {

    itemService.updateItem(itemId, form);

    return "redirect:/";
}

• 컨트롤러에서 애매하게 엔티티를 만들고 지지고 볶는게 아니라, 서비스 레이어에 데이터를 넘겨준다.

@Transactional
public void updateItem(Long itemId, BookForm form) {
    Item findItem = itemRepository.findById(itemId);
    findItem.change(form);
}

• 그리고 엔티티의 기본키를 통해 엔티티를 찾아와 영속시키면 된다. 영속 시킨 후 데이터를 변경하면 된다.
• 여기서는 의미있는 이름의 메서드를 만들어 추적이 쉽게 만들어주자. 위에서는 예제를 단순히 하기 위해 세터를 사용했지만 세터도 사용하지 않는다. 좋아하지도 않고. 

2. 값을 변경한다.

public void change(BookForm form) {
    name = form.getName();
    price = form.getPrice();
    stockQuantity = form.getStockQuantity();
}

• 그리고 이 변경 메서드에서 변경하고자 하는 값만 넣어주면 된다.
• 아이템에서 변경 가능한 데이터는 Name, Price, StockQuantity 이 세개뿐이라고 비즈니스 규칙으로 정해놓으면 이 코드에 문제는 아무것도 없다. 어차피 여기서는 form안에 데이터는 null일수도, null이 아니어도 상관없다. 이 form은 기존에 데이터베이스에 저장된 해당 값을 불러서 화면에 뿌려주고 사용자가 입력한 데이터를 그대로 가져온 것이기 때문이다.
• 그리고 이렇게 값을 변경해주고 save() 같은 메서드는 호출하지 않아도 된다.
• 왜냐? 영속성 컨텍스트가 관리하는 엔티티의 값을 변경했고, 트랜잭션이 끝나는 순간 변경감지를 통해 데이터가 바뀔테니까. 즉, updateItem 메서드가 끝나는 순간, 데이터베이스에 업데이트 쿼리가 나갈것이다.

병합이 아닌 변경감지를 사용하면 어떤점에서 좋은가?

• 예상하지 못한 오류를 방지할 수 있다. (사람은 언제나 실수를 한다. 실수 안하기를 기대하는 코드를 작성하는 사람보다 실수조차 하지 못하게 제약을 두는 코드가 더 좋은 코드라고 생각한다.)
• save() 메서드는 결국 엔티티를 넘겨야 한다. 엔티티를 넘긴다는건 수정한 엔티티를 넘겨야 하고, 엔티티를 수정하기 위해 Setter를 사용하던 뭘 하던 해야 할텐데, 데이터베이스에서 값을 가져와서 Setter를 통해 값을 변경해 save()를 호출하나, 엔티티를 직접 만들고 ID를 데이터베이스에 기존에 있는 동일한 기본키로 적용한 후 값을 수정해 save()를 호출하나 일을 두번하는 것이다. 그냥, 의미 있는 메서드를 하나 만들어두면 이 메서드만 추적하면 값을 어디서 변경하는지 바로 캐치할 수 있고, 세터와 같은 나쁜놈들을 사용하지 않아도 된다. 

결론은,

값을 변경할땐 변경감지를 사용하자! 

이번 포스팅에서는 도메인 모델 패턴과 트랜잭션 스크립트 패턴이 무엇인지 알아보고, 어떤 장단점이 있고, 무엇이 언제 더 좋은가?에 대해 고민해보는 포스팅이다. 

도메인 모델 패턴

도메인 모델 패턴은, 애플리케이션의 비즈니스 로직을 객체 중심으로 구성하는 패턴이다. 이 패턴에서는 실세계의 개념을 반영한 객체(엔티티)를 만들어 각 객체가 비즈니스 로직과 상태를 자체적으로 관리하도록 한다. 예를 들어, 다음 코드를 보자.

Order

package cwchoiit.shoppingmall.domain;

import jakarta.persistence.*;
import lombok.AccessLevel;
import lombok.Getter;
import lombok.NoArgsConstructor;

import java.time.LocalDateTime;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

@Entity
@Getter
@Table(name = "orders")
@NoArgsConstructor(access = AccessLevel.PROTECTED) // 생성 메서드를 만들었으면 그 메서드로만 인스턴스를 생성할 수 있도록 막아야 함
public class Order {

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

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "member_id")
    private Member member;

    @OneToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL)
    @JoinColumn(name = "delivery_id")
    private Delivery delivery;

    @OneToMany(mappedBy = "order", fetch = FetchType.LAZY, cascade = CascadeType.ALL)
    private List<OrderItem> orderItems = new ArrayList<>();

    private LocalDateTime orderDate;

    @Enumerated(EnumType.STRING)
    private OrderStatus status;

    // ################################################################# //
    // ######################## 연관관계 편의 메서드 ######################## //
    // ################################################################# //
    public void addRelationshipMember(Member member) {
        this.member = member;
        member.getOrders().add(this);
    }

    public void addRelationshipDelivery(Delivery delivery) {
        this.delivery = delivery;
        delivery.addRelationshipOrder(this);
    }

    public void addRelationshipOrderItem(OrderItem orderItem) {
        this.orderItems.add(orderItem);
        orderItem.addRelationshipOrder(this);
    }

    // ################################################################# //
    // ######################## 생성 메서드 ############################### //
    // ################################################################# //
    public static Order createOrder(Member member, Delivery delivery, OrderItem... orderItems) {
        Order order = new Order();
        order.status = OrderStatus.ORDER;
        order.orderDate = LocalDateTime.now();

        order.addRelationshipMember(member);
        order.addRelationshipDelivery(delivery);
        Arrays.stream(orderItems).forEach(order::addRelationshipOrderItem);

        return order;
    }

    public void cancel() {
        if (delivery.getStatus() == DeliveryStatus.COMP) {
            throw new IllegalStateException("이미 배송완료된 상품은 취소가 불가능합니다.");
        }

        status = OrderStatus.CANCEL;
        for (OrderItem orderItem : orderItems) {
            orderItem.cancel();
        }
    }

    // ################################################################# //
    // ######################## 조회 메서드 ############################### //
    // ################################################################# //
    public int getTotalPrice() {
        return orderItems.stream()
                .mapToInt(OrderItem::getTotalPrice)
                .sum();
    }
}

• 이 코드의 하단부를 보면, 여러 메서드가 있지만 그 중 대표적인 예시로 getTotalPrice()로 설명을 해보겠다. 이 메서드는 주문 가격을 반환하는 메서드이고 주문 가격은 주문 수량 * 주문 상품의 개수의 결과값을 다 합친것이다. OrderItem 이라는 또 하나의 객체가 있지만 그 안에 있는 메서드가 그런 작업을 한다.
• 여튼, 이런 코드는 서비스 레이어에 주문 메서드에서 한 줄 한 줄 로직을 작성할 수도 있지만, 이렇게 객체 자체적으로 그 메서드를 가지고 있을 수도 있다. 즉, 객체 자체에 주문 생성과 관련된 로직이 포함되어 있다는 말이다.
• 또 하나의 예로, createOrder()와 같은 메서드도 서비스 레이어에 주문 관련 메서드안에 한 줄 한 줄 비즈니스 로직을 작성할 수도 있지만 이렇게 객체 자체적으로 그 기능을 가지고 있을 수도 있다.  
• 이게 바로 도메인 모델 패턴이다. 즉, 관련 메서드는 해당 객체가 가지고 있는 것을 말한다.

또 다른 예시로는 다음 코드를 보자.

Mp3

package cwchoiit.shoppingmall.domain;

public class Mp3 {
    private int volume;
    private String name;

    public Mp3(int volume, String name) {
        this.volume = volume;
        this.name = name;
    }
    
    public void play() {
        System.out.println(name + " - " + volume + "dB");
    }
    
    public void volumeUp() {
        volume++;
        System.out.println("Volume up to " + volume + "dB");
    }
    
    public void volumeDown() {
        volume--;
        System.out.println("Volume down to " + volume + "dB");
    }
}

• Mp3 라는 객체가 있고 이 객체 안에는 name, volume 이라는 두 개의 필드가 있다. 
• 이 객체의 볼륨을 줄이고 키우는 작업은 이 서비스 레이어에서 인스턴스를 만들고 세터를 사용해서 볼륨을 줄이고 키울수도 있겠지만 이렇게 객체 자체적으로 volumeUp(), volumeDown() 메서드를 제공해서 비즈니스 로직 자체를 객체 안에 포함시킬수도 있다.
• 이게 도메인 모델 패턴이다. 
• 그리고 이렇게 하면 실세계와 가장 밀접한 객체 지향적 설계가 된다고 본다. Mp3를 사용하는 사용자가 볼륨을 줄이는 행위는 Mp3가 제공하는거지 사용자가 새로이 만들어내는 기술이 아니잖아.

도메인 모델 패턴의 장단점

장점

• 재사용성과 확장성: 객체 간의 관계와 상태가 명확하게 정의되어 있어, 새로운 비즈니스 요구사항이 추가될 때 확장이 쉽다.
• 유지보수성: 비즈니스 로직이 객체에 분산되어 있어서, 특정 기능을 수정해도 전체 애플리케이션에 미치는 영향이 적다.
• 객체 지향적: 실세계의 개념을 반영하여 객체를 통해 로직을 처리하므로 이해하기 쉽고, 자바 같은 객체 지향 언어에 적합하다.

단점

• 복잡성 증가: 복잡한 비즈니스 로직을 가진 대규모 애플리케이션에서는 객체 간의 관계와 상호작용이 복잡해질 수 있다.
• 초기 개발 비용: 모델을 설계하고 객체를 정의하는 데 시간이 상대적으로 많이 걸린다.

트랜잭션 스크립트 패턴

트랜잭션 스크립트 패턴은 비즈니스 로직을 절차적으로 처리하는 코드로 구성하는 방식이다. 이 패턴은 비즈니스 로직을 하나의 스크립트로 정의하여 각 요청에 대해 해당 스크립트를 실행하는 구조를 가진다. 예를 들어 OrderService와 같은 서비스 클래스에 메서드 형태로 비즈니스 로직을 구현하는 것이 일반적이다.

예를 들어 아래 코드를 보자.

Mp3

package cwchoiit.shoppingmall.domain;

public class Mp3 {
    private int volume;
    private String name;

    public Mp3(int volume, String name) {
        this.volume = volume;
        this.name = name;
    }

    public int getVolume() {
        return volume;
    }

    public void setVolume(int volume) {
        this.volume = volume;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

• Mp3 클래스가 있다. 이 클래스는 volume, name 필드를 가지고 있고 Getter, Setter를 가지고 있다.

Mp3Service

package cwchoiit.shoppingmall.service;

import cwchoiit.shoppingmall.domain.Mp3;

public class Mp3Service {
    
    public void mp3() {
        Mp3 mp3 = new Mp3(0, "ipod");
        
        // 볼륨 증가
        mp3.setVolume(1);
        
        // 볼륨 증가 후 로직 처리
        // ...
        
        // 볼륨 감소
        mp3.setVolume(0);
        
        // ...
    }
}

• Mp3Service는 서비스 클래스이다. 이 클래스의 특정 메서드 안에서 Mp3 인스턴스를 만들고 그 인스턴스의 볼륨을 줄이고 키우고 그 사이에 어떤 비즈니스 로직들이 쭉 스크립트 작성하듯 절차적으로 진행된다.
• 이게 트랜잭션 스크립트 패턴이다.

트랜잭션 스크립트 패턴의 장단점

장점

• 간단하고 직관적: 코드가 직관적이고 간단해서 빠르게 개발하고 한눈에 코드를 알아보기 쉽다.

단점

• 재사용성 부족: 비즈니스 로직이 중복될 가능성이 높고, 코드 재사용이 불가능하다.
• 확장성 부족: 비즈니스 로직이 절차적으로 구성되어 있어 새로운 요구사항이 추가되면 코드가 복잡해지고 유지보수성이 떨어진다.
• 비즈니스 로직 분리 어려움: 코드가 길어지고 복잡해지면, 로직이 여기저기 흩어져 가독성이 떨어진다.

어떤 패턴이 더 좋은가요?

굳이 말하자면, 애플리케이션의 복잡도와 요구사항에 따라 달라진다고 본다. 더 좋고 나쁜 것은 없다고 생각한다.

• 복잡한 도메인 로직이 있는 경우: 도메인 모델 패턴이 더 적합하다. 객체 지향적인 구조와 비즈니스 로직이 함께 동작하기 때문에 확장성이 높고 유지보수도 쉽기 때문이다.
• 단순한 애플리케이션이나 빠른 개발이 필요한 경우: 트랜잭션 스크립트 패턴이 더 효율적일 수 있다. 절차적인 코드 구조로 인해 간단한 작업에는 빠르고 효율적이다.

내 개인적인 의견으로는, 도메인 모델 패턴이 자바의 장점도 살리면서 객체 지향적이고 장기적으로 볼 때 유지보수성과 확장성, 재사용성을 고려해 더 좋은 선택인 것 같다. 그런데 만약, 클래스 파일도 몇 개 없고 정말 간단한 애플리케이션이라면, 트랜잭션 스크립트 패턴을 사용해도 누가 뭐라고 하진 않을 것 같다. 

참고자료

이 포스팅은 바로 이전 포스팅인 리플렉션과 굉장히 밀접한 관계가 있다. 그래서 이전 포스팅을 먼저 정독하고 이 포스팅을 보아야 한다.

2024.10.21 - [JAVA의 가장 기본이 되는 내용] - 리플렉션

애노테이션이 필요한 이유

이전 포스팅에서 리플렉션을 활용해서 HTTP 서버를 훨씬 더 사용하기 편하고 합리적으로 변경했다. 그럼에도 불구하고 남은 문제점이 있었다. 

• 리플렉션 서블릿은 요청 URL과 메서드 이름이 같다면 해당 메서드를 동적으로 호출할 수 있다. 하지만, 요청 이름과 메서드 이름을 다르게 하고 싶다면 어떻게 해야 할까?
• 예를 들어, `/site1`이라고 와도 page1()과 같은 메서드를 호출하고 싶다면 어떻게 해야 할까? 메서드 이름은 더 자세히 적고 싶을 수도 있잖아?
• 앞서 `/`와 같은 자바 메서드 이름으로 처리하기 어려운 URL은 어떻게 해결할 수 있을까?
• URL은 주로 `-`를 구분자로 활용한다. `/add-member`와 같은 URL은 어떻게 해결할까?

이런 문제들은, 메서드 이름을 동적으로 활용하는 리플렉션만으로는 어렵다. 추가 정보를 어딘가에 적어두고 읽을 수 있어야 한다.

다음 코드를 보자.

public class Controller {
    // "/site1"
    public void page1(HttpRequest request, HttpResponse response) {
    }

    // "/"
    public void home(HttpRequest request, HttpResponse response) {
      response.writeBody("<h1>site2</h1>");
    }
    
    // "/add-member"
    public void addMember(HttpRequest request, HttpResponse response) {...}
   
}

만약, 리플렉션 같은 기술로 메서드 이름뿐만 아니라, 주석까지 읽어서 처리할 수 있다면 좋지 않을까? 그러면 해당 메서드에 있는 주석을 읽어서 URL 경로와 비교하면 된다. 그런데 주석은 코드가 아니다. 따라서 컴파일 시점에 모두 제거된다. 만약, 프로그램 실행 중에 읽어서 사용할 수 있는 주석이 있다면 어떨까? 그게 바로 애노테이션이다.

애노테이션 예제

애노테이션에 대해서 본격적으로 알아보기 전에, 간단한 예제를 통해 실제 우리가 고민한 문제를 애노테이션으로 어떻게 해결하는지 알아보자. 애노테이션에 대한 자세한 내용은 예제 이후에 설명하겠다.

SimpleMapping

package cwchoiit.annotation.mapping;

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;

@Retention(RetentionPolicy.RUNTIME)
public @interface SimpleMapping {
    String value();
}

• 애노테이션은 @interface 키워드를 사용해서 만든다.
• @SimpleMapping이라는 애노테이션 하나를 만든다. 내부에는 String value라는 속성을 하나 가진다.
• @Retention은 뒤에서 설명한다. 지금은 필수로 사용해야 하는 값 정도로 생각하자.

TestController

package cwchoiit.annotation.mapping;

public class TestController {

    @SimpleMapping(value = "/")
    public void home() {
        System.out.println("TestController.home");
    }

    @SimpleMapping(value = "/site1")
    public void page1() {
        System.out.println("TestController.page1");
    }
}

• 애노테이션을 사용할 때는 `@`기호로 시작한다.
• home()에는 @SimpleMapping(value = "/") 애노테이션을 붙였다.
• page1()에는 @SimpleMapping(value = "/site1") 애노테이션을 붙였다.

참고로, 애노테이션은 프로그램 코드가 아니다. 예제에서 애노테이션이 붙어있는 home(), page1() 같은 코드를 호출해도 프로그램에는 아무런 영향을 주지 않는다. 마치 주석과 비슷하다고 이해하면 된다. 다만, 일반적인 주석이 아니라, 리플렉션 같은 기술로 실행 시점에 읽어서 활용할 수 있는 특별한 주석이다.

TestControllerMain

package cwchoiit.annotation.mapping;

import java.lang.reflect.Method;

public class TestControllerMain {

    public static void main(String[] args) {
        TestController testController = new TestController();

        Class<? extends TestController> aClass = testController.getClass();
        Method[] methods = aClass.getDeclaredMethods();
        for (Method method : methods) {
            System.out.println("method = " + method);
            SimpleMapping simpleMapping = method.getAnnotation(SimpleMapping.class);
            if (simpleMapping != null) {
                System.out.println("[" + simpleMapping.value() + "] -> " + method);
            }
        }
    }
}

• TestController 클래스의 선언된 메서드를 찾는다.
• 리플렉션이 제공하는 getAnnotation() 메서드를 사용하면, 붙어있는 애노테이션을 찾을 수 있다.
  • Class, Method, Field, Constructor 클래스는 자신에게 붙은 애노테이션을 찾을 수 있는 getAnnotation()를 제공한다.
  • 여기서는 Method.getAnnotation(SimpleMapping.class)을 사용했으므로, 해당 메서드에 붙은 @SimpleMapping 애노테이션을 찾을 수 있다. 
• simpleMapping.value()를 사용해서 찾은 애노테이션에 지정된 값을 조회할 수 있다.

실행 결과

method = public void cwchoiit.annotation.mapping.TestController.home()
[/] -> public void cwchoiit.annotation.mapping.TestController.home()
method = public void cwchoiit.annotation.mapping.TestController.page1()
[/site1] -> public void cwchoiit.annotation.mapping.TestController.page1()

이 예제를 통해 리플렉션 서블릿에서 해결하지 못했던 문제들을 어떻게 해결해야 하는지 바로 이해가 될 것이다. 바로, 애노테이션의 속성값을 사용해서 그 값이 URL 경로와 같으면 현재 조회된 이 메서드를 사용하는 방식으로 진행하면 될 것 같다!

참고로, 애노테이션이라는 단어는, 자바 애노테이션의 영어 단어 "Annotation"은 일반적으로 "주석" 또는 "메모"를 의미한다. 애노테이션은 코드에 추가적인 정보를 주석처럼 제공한다. 하지만 일반 주석과 달리, 애노테이션은 컴파일러나 런타임에서 해석될 수 있는 메타데이터를 제공한다. 즉, 애노테이션은 코드에 메모를 달아놓는 것처럼 특정 정보나 지시를 추가하는 도구로, 코드에 대한 메타데이터를 표현하는 방법이다. 따라서, "애노테이션"이라는 이름은 코드에 대한 추가적인 정보를 주석처럼 달아놓는다는 뜻이다.

애노테이션 정의

앞서 만들었던, HTTP 서버 관련해서 애노테이션과 리플렉션을 활용한 코드로 리팩토링하기 전에 애노테이션의 정의와 사용방법에 대해 좀 더 진득하게 알아보자.

AnnoElement

package cwchoiit.annotation.basic;

import cwchoiit.util.MyLogger;

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;

@Retention(RetentionPolicy.RUNTIME)
public @interface AnnoElement {
    String value();
    int count() default 0;
    String[] tags() default {};

    // MyLogger data(); // 다른 타입은 적용 X

    Class<? extends MyLogger> annoData() default MyLogger.class;

}

• 애노테이션은 @interface 키워드로 정의한다.
• 애노테이션은 속성을 가질 수 있는데, 인터페이스와 비슷하게 정의한다.

애노테이션 정의 규칙

데이터 타입

• 기본 타입 (int, float, boolean 등)
• String
• Class (메타데이터) 또는 인터페이스
• enum
• 다른 애노테이션 타입
• 위의 타입들의 배열
• 앞서 설명한 타입 외에는 정의할 수 없다. 쉽게 이야기해서 직접 만든 일반적인 클래스를 사용할 수 없다.
  • 예) Member, User, Team, MyLogger, ...

default 값

• 요소에 default 값을 지정할 수 있다.
• 예) String value() default "기본 값을 적용합니다.";

요소 이름

• 메서드 형태로 정의된다.
• 괄호를 포함하되 매개변수는 없어야 한다.

반환 값

• void를 반환 타입으로 사용할 수 없다.

예외

• 예외를 선언할 수 없다.

특별한 요소 이름

• value 라는 이름의 요소를 하나만 가질 경우, 애노테이션 사용 시 요소 이름을 생략할 수 있다. 이건 뒤에 코드를 보면서 더 자세히 설명해보겠다.

애노테이션 사용

ElementData1

package cwchoiit.annotation.basic;

@AnnoElement(value = "data", count = 10, tags = {"t1", "t2"})
public class ElementData1 {
}

• 애노테이션은 이렇게 클래스에도 사용할 수 있고, 메서드나 필드에도 사용할 수 있다.

ElementDataMain

package cwchoiit.annotation.basic;

import java.util.Arrays;

public class ElementDataMain {

    public static void main(String[] args) {
        Class<ElementData1> elementData1Class = ElementData1.class;
        AnnoElement annotation = elementData1Class.getAnnotation(AnnoElement.class);

        String value = annotation.value();
        System.out.println("value = " + value);

        int count = annotation.count();
        System.out.println("count = " + count);

        String[] tags = annotation.tags();
        System.out.println("tags = " + Arrays.toString(tags));
    }
}

실행 결과

value = data
count = 10
tags = [t1, t2]

ElementData2

package cwchoiit.annotation.basic;

@AnnoElement(value = "data", tags = "t1")
public class ElementData2 {
}

• default 항목은 생략 가능하다. (count를 생략한 모습이다.)
• 배열의 항목이 하나라면 `{}` 생략 가능하다.

ElementData3

package cwchoiit.annotation.basic;

@AnnoElement("data")
public class ElementData3 {
}

• 입력 요소가 하나인 경우, value 키워드 생략 가능하다.
• value = "data"와 동일한 모습이다.

메타 애노테이션

애노테이션을 정의하는데 사용하는 특별한 애노테이션을 메타 애노테이션이라고 한다. 다음과 같은 메타 애노테이션이 있다. 하나씩 알아보자. 

• @Retention
  • RetentionPolicy.SOURCE
  • RetentionPolicy.CLASS
  • RetentionPolicy.RUNTIME
• @Target
• @Documented
• @Inherited

@Retention

애노테이션의 생존 기간을 지정한다.

package cwchoiit.annotation.basic;

import cwchoiit.util.MyLogger;

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;

@Retention(RetentionPolicy.RUNTIME)
public @interface AnnoElement {
    String value();

    int count() default 0;

    String[] tags() default {};

    // MyLogger data(); // 다른 타입은 적용 X

    Class<? extends MyLogger> annoData() default MyLogger.class;

}

• 보통은 대부분 우리가 만든것처럼 RUNTIME을 사용한다.

public enum RetentionPolicy {
    SOURCE,
    CLASS,
    RUNTIME
}

• RetentionPolicy.SOURCE: 소스 코드에만 남아있다. 컴파일 시점에 제거된다.
• RetentionPolicy.CLASS: 컴파일 후 class 파일까지는 남아있지만, 자바 실행 시점에 제거된다 (기본값)
• RetentionPolicy.RUNTIME: 자바 실행 중에도 남아있다. 대부분 이 설정을 사용한다.

실제로, 이 @Rentention을 CLASS 또는 SOURCE로 적용하고 실행하면 읽지 못하는 모습을 볼 수 있다.

@Retention(RetentionPolicy.SOURCE)
public @interface AnnoElement {...}

package cwchoiit.annotation.basic;

import java.util.Arrays;

public class ElementDataMain {

    public static void main(String[] args) {
        Class<ElementData1> elementData1Class = ElementData1.class;
        AnnoElement annotation = elementData1Class.getAnnotation(AnnoElement.class);

        String value = annotation.value();
        System.out.println("value = " + value);

        int count = annotation.count();
        System.out.println("count = " + count);

        String[] tags = annotation.tags();
        System.out.println("tags = " + Arrays.toString(tags));
    }
}

@Target

애노테이션을 적용할 수 있는 위치를 지정한다.

package cwchoiit.annotation.basic;

import java.lang.annotation.*;

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD, ElementType.TYPE})
@Documented
public @interface AnnoMeta {
}

• 여러개를 사용할 수 있게 배열로 되어 있다. 주로 TYPE, FIELD, METHOD를 사용한다. 
• TYPE은 클래스, 인터페이스 레벨에 붙일 수 있고, FIELD는 필드에 붙일 수 있고, METHOD는 메서드에 붙일 수 있게 허용하는 것이다.

public enum ElementType {
    TYPE,
    FIELD,
    METHOD,
    PARAMETER,
    CONSTRUCTOR,
    LOCAL_VARIABLE,
    ANNOTATION_TYPE,
    PACKAGE,
    TYPE_PARAMETER,
    TYPE_USE,
    MODULE,
    RECORD_COMPONENT;
}

@Documented

자바 API 문서를 만들 때, 해당 애노테이션이 함께 포함되는지 지정한다. 보통 함께 사용한다.

@Inherited

자식 클래스가 애노테이션을 상속 받을 수 있다. 이 애노테이션은 뒤에서 더 자세히 알아보자!

적용 예시

package cwchoiit.annotation.basic;

import java.lang.annotation.*;

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD, ElementType.TYPE})
@Documented
public @interface AnnoMeta {
}

• @Retention: RUNTIME  → 자바 실행 중에도 애노테이션 정보가 남아있다. 따라서, 런타임에 리플렉션을 통해서 읽을 수 있다. 만약 다른 설정을 적용한다면 자바 실행 시점에 애노테이션이 사라지므로 리플렉션을 통해서 읽을 수 없다.
• @Target: ElementType.METHOD, ElementType.TYPE → 메서드와 타입(클래스, 인터페이스, enum 등)에 @AnnoMeta 애노테이션을 달 수 있다. 다른 곳에 적용하면 컴파일 오류가 발생한다.
• @Documented: 자바 API 문서를 만들 때 해당 애노테이션이 포함된다.

적용한 모습

package cwchoiit.annotation.basic;

@AnnoMeta
public class MetaData {

    // @AnnoMeta // 필드에 적용하면 컴파일 오류
    private String id;

    @AnnoMeta
    public void call() {

    }

    public static void main(String[] args) throws NoSuchMethodException {
        AnnoMeta annotation = MetaData.class.getAnnotation(AnnoMeta.class);
        System.out.println("annotation = " + annotation);

        AnnoMeta methodAnnotation = MetaData.class.getMethod("call").getAnnotation(AnnoMeta.class);
        System.out.println("methodAnnotation = " + methodAnnotation);
    }
}

• 타입과 메서드에 해당 애노테이션을 적용할 수 있다.
• 필드에 적용하면 컴파일 오류가 발생한다. 자바 언어는 컴파일 시점에 @Target 메타 애노테이션을 읽어서 지정한 위치가 맞는지 체크한다.

실행 결과

annotation = @cwchoiit.annotation.basic.AnnoMeta()
methodAnnotation = @cwchoiit.annotation.basic.AnnoMeta()

애노테이션과 상속

모든 애노테이션은 java.lang.annotation.Annotation 인터페이스를 묵시적으로 상속 받는다.

package java.lang.annotation;

public interface Annotation {
  boolean equals(Object obj);
  int hashCode();
  String toString();
  Class<? extends Annotation> annotationType();
}

• java.lang.annotation.Annotation 인터페이스는 개발자가 직접 구현하거나, 확장할 수 있는 것이 아니라, 자바 언어 자체에서 애노테이션을 위한 기반으로 사용된다. 이 인터페이스는 다음과 같은 메서드를 제공한다.
  • boolean equals(Object obj): 두 애노테이션의 동일성을 비교한다.
  • int hashCode(): 애노테이션의 해시코드를 반환한다.
  • String toString(): 애노테이션의 문자열 표현을 반환한다.
  • Class<? extends Annotation> annotationType(): 애노테이션의 타입을 반환한다.

모든 애노테이션은 기본적으로, Annotation 인터페이스를 확장하며, 이로 인해 자바에서 애노테이션은 특별한 형태의 인터페이스로 간주된다. 하지만 자바에서 애노테이션을 정의할 때, 개발자가 명시적으로 Annotation 인터페이스를 상속하거나 구현할 필요는 없다. 애노테이션을 @interface 키워드를 통해 정의하면, 자바 컴파일러가 자동으로 Annotation 인터페이스를 확장하도록 처리해준다.

애노테이션 정의

public @interface MyCustomAnnotation {}

자바가 자동으로 처리

public interface MyCustomAnnotation extends java.lang.annotation.Annotation {}

애노테이션과 상속

• 애노테이션은 다른 애노테이션이나 인터페이스를 직접 상속할 수 없다.
• 오직 java.lang.annotation.Annotation 인터페이스만 상속한다.
• 따라서, 애노테이션 사이에는 상속이라는 개념이 존재하지 않는다.

@Inherited

애노테이션을 정의할 때 @Inherited 메타 애노테이션을 붙이면, 애노테이션을 적용한 클래스의 자식 클래스도 해당 애노테이션을 부여 받을 수 있다. 단, 주의할 점은! 이 기능은 클래스 상속에서만 작동하고, 인터페이스의 구현체에는 적용되지 않는다.

예제로 알아보자.

InheritedAnnotation

package cwchoiit.annotation.basic.inherited;

import java.lang.annotation.Inherited;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;

@Inherited
@Retention(RetentionPolicy.RUNTIME)
public @interface InheritedAnnotation {
}

• InheritedAnnotation은 @Inherited 애노테이션을 가진다.

NoInheritedAnnotation

package cwchoiit.annotation.basic.inherited;

import java.lang.annotation.Inherited;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;

@Retention(RetentionPolicy.RUNTIME)
public @interface NoInheritedAnnotation {
}

• NoInheritedAnnotation은 @Inherited를 가지지 않는다.

Parent

package cwchoiit.annotation.basic.inherited;

@InheritedAnnotation
@NoInheritedAnnotation
public class Parent {
}

• Parent에는 @InheritedAnnotation, @NoInheritedAnnotation 모두 붙어있다.

Child

package cwchoiit.annotation.basic.inherited;

public class Child extends Parent {
}

• Child는 @InheritedAnnotation 애노테이션을 상속 받는다.
  • @Inherited 메타 애노테이션이 붙어있다.
• @NoInhertiedAnnotation은 상속받지 못한다.
  • @Inherited 메타 애노테이션이 붙어있지 않다.

TestInterface

package cwchoiit.annotation.basic.inherited;

@InheritedAnnotation
@NoInheritedAnnotation
public interface TestInterface {
}

• TestInterface에는 @InheritedAnnotation, @NoInheritedAnnotation 모두 붙어있다.

TestInterfaceImpl

package cwchoiit.annotation.basic.inherited;

public class TestInterfaceImpl implements TestInterface {
}

• 인터페이스의 구현에서는 애노테이션을 상속받을 수 없다. 
• 참고로, 인터페이스 부모와 인터페이스 자식의 관계에서도 애노테이션을 상속 받을 수 없다.

InheritedMain

package cwchoiit.annotation.basic.inherited;

import java.lang.annotation.Annotation;

public class InheritedMain {

    public static void main(String[] args) {
        print(Parent.class);
        print(Child.class);
        print(TestInterface.class);
        print(TestInterfaceImpl.class);
    }

    private static void print(Class<?> clazz) {
        System.out.println("class: " + clazz);
        Annotation[] annotations = clazz.getAnnotations();
        for (Annotation annotation : annotations) {
            System.out.println(" - " + annotation.annotationType().getSimpleName());
        }
        System.out.println();
    }
}

실행 결과

class: class cwchoiit.annotation.basic.inherited.Parent
 - InheritedAnnotation
 - NoInheritedAnnotation

class: class cwchoiit.annotation.basic.inherited.Child
 - InheritedAnnotation

class: interface cwchoiit.annotation.basic.inherited.TestInterface
 - InheritedAnnotation
 - NoInheritedAnnotation

class: class cwchoiit.annotation.basic.inherited.TestInterfaceImpl

• Child: InheritedAnnotation 상속
• TestInterfaceImpl: 애노테이션을 상속받을 수 없음

@Inherited가 클래스 상속에만 적용되는 이유

1. 클래스 상속과 인터페이스 구현의 차이

• 클래스 상속은 자식 클래스가 부모 클래스의 속성과 메서드를 상속받는 개념이다. 즉, 자식 클래스는 부모 클래스의 특성을 이어받으므로, 부모 클래스에 정의된 애노테이션을 자식 클래스가 자동으로 상속받을 수 있는 논리적 기반이 있다.
• 인터페이스는 메서드의 시그니처만을 정의할 뿐, 상태나 행위를 가지지 않기 때문에, 인터페이스의 구현체가 애노테이션을 상속한다는 개념이 잘 맞지 않는다.

2. 인터페이스와 다중 구현, 다이아몬드 문제

• 인터페이스는 다중 구현이 가능하다. 만약, 인터페이스의 애노테이션을 구현 클래스에서 상속하게 되면, 여러 인터페이스의 애노테이션 간의 충돌이나 모호한 상황이 발생할 수 있다. 그 중에 하나가 Circular Dependency 일 수도 있고.

애노테이션 활용 - 검증기

이제 이 애노테이션을 어떤식으로 활용할 수 있는지 알아보기 위해 각종 클래스의 정보들을 검증하는 기능을 만들어보자.

Team

package cwchoiit.annotation.validator;

public class Team {

    private String name;

    private int memberCount;

    public Team(String name, int memberCount) {
        this.name = name;
        this.memberCount = memberCount;
    }

    public String getName() {
        return name;
    }

    public int getMemberCount() {
        return memberCount;
    }
}

User

package cwchoiit.annotation.validator;

public class User {

    private String name;

    private int age;

    public User(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }
}

이렇게 두 객체(팀과 유저)가 있다고 해보자. 이제 이것들을 가지고 사용하는 쪽에서 이 객체에 들어가있는 값이 적절한지를 확인하고 싶을때 아래와 같은 코드를 작성할 수 있을것이다.

ValidatorV1Main

package cwchoiit.annotation.validator;

import static cwchoiit.util.MyLogger.log;

public class ValidatorV1Main {
    public static void main(String[] args) {
        User user = new User("user1", 0);
        Team team = new Team("", 0);

        try {
            log("=== user 검증 ===");
            validateUser(user);
        } catch (Exception e) {
            log(e);
        }

        try {
            log("=== team 검증 ===");
            validateTeam(team);
        } catch (Exception e) {
            log(e);
        }
    }

    private static void validateUser(User user) {
        if (user.getName() == null || user.getName().isEmpty()) {
            throw new RuntimeException("이름이 비었다.");
        }
        if (user.getAge() < 1 || user.getAge() > 100) {
            throw new RuntimeException("나이가 1~100 사이가 아니다.");
        }
    }

    private static void validateTeam(Team team) {
        if (team.getName() == null || team.getName().isEmpty()) {
            throw new RuntimeException("이름이 비었다.");
        }
        if (team.getMemberCount() < 1 || team.getMemberCount() > 999) {
            throw new RuntimeException("회원 수가 1~999 사이가 아니다.");
        }
    }
}

• validateUser() → 유저의 이름과 나이를 검증하는 메서드
• validateTeam() → 팀의 이름과 회원수를 검증하는 메서드

실행 결과

13:58:01.418 [     main] === user 검증 ===
13:58:01.422 [     main] java.lang.RuntimeException: 나이가 1~100 사이가 아니다.
13:58:01.422 [     main] === team 검증 ===
13:58:01.422 [     main] java.lang.RuntimeException: 이름이 비었다.

여기서는 값이 비었는지 검증하는 부분과 숫자의 범위를 검증하는 2가지 부분이 있다. 코드를 잘 보면 뭔가 비슷한 것 같으면서도 User, Team이 서로 완전히 다른 클래스이기 때문에 재사용이 어렵다. 그리고 각각의 필드 이름도 서로 다르고, 오류 메시지도 다르다. 그리고 검증해야 할 값의 범위도 다르다. 심지어, 객체가 이렇게 평생 2개만 있는것도 아니고 점점 늘어날텐데 그때마다 이런 중복적인 코드를 작성해야 한다. 이런 문제를 애노테이션으로 깔끔하게 해결할 수 있다.

애노테이션 기반 검증기

@NotEmpty - 빈 값을 검증하는데 사용

package cwchoiit.annotation.validator;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface NotEmpty {
    String message() default "The value is empty";
}

• message → 검증에 실패한 경우 보여줄 메시지

@Range - 숫자의 범위를 검증하는데 사용

package cwchoiit.annotation.validator;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface Range {
    int min();
    int max();
    String message() default "Out of range";
}

• min → 최소 값
• max → 최대 값
• message → 검증에 실패한 경우 출력할 오류 메시지

이렇게 애노테이션을 만들고, 이 애노테이션을 각 필드에 원하는대로 추가하는 것이다.

User - 검증 애노테이션을 추가

package cwchoiit.annotation.validator;

public class User {

    @NotEmpty(message = "이름이 비었습니다.")
    private String name;

    @Range(min = 1, max = 100, message = "나이는 1과 100 사이어야 합니다.")
    private int age;

    public User(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }
}

Team - 검증 애노테이션을 추가

package cwchoiit.annotation.validator;

public class Team {

    @NotEmpty(message = "이름이 비었습니다.")
    private String name;

    @Range(min = 1, max = 999, message = "회원 수는 1과 999사이어야 합니다.")
    private int memberCount;

    public Team(String name, int memberCount) {
        this.name = name;
        this.memberCount = memberCount;
    }

    public String getName() {
        return name;
    }

    public int getMemberCount() {
        return memberCount;
    }
}

이제 이렇게 만들어 둔 후, 검증기를 리플렉션을 활용해서 만들면 끝난다.

Validator

package cwchoiit.annotation.validator;

import java.lang.reflect.Field;

public class Validator {

    public static void validate(Object object) throws Exception {
        Field[] declaredFields = object.getClass().getDeclaredFields();

        for (Field field : declaredFields) {
            field.setAccessible(true);

            if (field.isAnnotationPresent(NotEmpty.class)) {
                String value = (String) field.get(object);
                NotEmpty notEmpty = field.getAnnotation(NotEmpty.class);

                if (value == null || value.isEmpty()) {
                    throw new RuntimeException(notEmpty.message());
                }
            }

            if (field.isAnnotationPresent(Range.class)) {
                long value = field.getLong(object);
                Range range = field.getAnnotation(Range.class);
                if (value < range.min() || value > range.max()) {
                    throw new RuntimeException(range.message());
                }
            }
        }
    }
}

• 전달된 객체에 선언된 필드를 모두 찾고, isAnnotationPresent()를 활용해서 @NotEmpty, @Range 애노테이션이 붙어있는지 확인한다.
• 애노테이션이 있는 경우, 각 애노테이션의 속성을 기반으로 검증 로직을 수행한다. 만약, 검증에 실패하면 애노테이션에 적용한 메시지를 예외에 담아서 던진다.

ValidatorV2Main

package cwchoiit.annotation.validator;

import static cwchoiit.util.MyLogger.log;

public class ValidatorV2Main {
    public static void main(String[] args) {
        User user = new User("user1", 0);
        Team team = new Team("team1", 10);

        try {
            log("=== user 검증 ===");
            Validator.validate(user);
        } catch (Exception e) {
            log(e);
        }

        try {
            log("=== team 검증 ===");
            Validator.validate(team);
        } catch (Exception e) {
            log(e);
        }
    }
}

실행 결과

14:04:48.593 [     main] === user 검증 ===
14:04:48.609 [     main] java.lang.RuntimeException: 나이는 1과 100 사이어야 합니다.
14:04:48.609 [     main] === team 검증 ===

검증용 애노테이션과 검증기를 사용한 덕분에, 어떤 객체든지 애노테이션으로 간단하게 검증할 수 있게 됐다. 앞으로 객체를 몇개를 더 새로 만들고 검증을 하던 이 애노테이션과 검증기만 사용한다면 중복 코드를 작성하지 않아도 된다!

• 예를 들어, @NotEmpty 애노테이션을 사용하면 필드가 비었는지 여부를 편리하게 검증할 수 있고, @Range(min=1, max=100)와 같은 애노테이션을 통해 숫자의 범위를 쉽게 제한할 수 있다. 이러한 애노테이션 기반 검증 방식은 중복되는 코드 작성 없이도 유연한 검증 로직을 적용할 수 있어 유지보수성을 높여준다. 
• User 클래스와 Team 클래스에 각각의 필드 이름이나 메시지들이 다르더라도, 애노테이션의 속성 값을 통해 필드 이름을 지정하고, 오류 메시지도 일관되게 정의할 수 있다. 예를 들어, @NotEmpty(message = "이름은 비어 있을 수 없습니다") 처럼 명시적인 메시지를 작성할 수 있으며, 이를 통해 다양한 클래스에서 공통된 검증 로직을 재사용할 수 있게 됐다.
• 또한, 새로 추가되는 클래스나 필드에 대해서도 복잡한 로직을 별도로 구현할 필요 없이 적절한 애노테이션을 추가하는 것만으로도 검증 로직을 쉽게 확장할 수 있다. 이처럼 애노테이션 기반 검증을 도입하면 코드의 가독성과 확장성이 크게 향상되며, 일관된 규칙을 유지할 수 있어 전체적인 품질 관리에도 도움이 된다.
• 이제 클래스들이 서로 다르더라도, 일관되고 재사용 가능한 검증 방식을 사용할 수 있게 되었다.

참고로, 자바 진영에서는 애노테이션 기반 검증 기능을 Jakarta(Java) Bean Validation 이라는 이름으로 표준화했다. 다양한 검증 애노테이션과 기능이 있고, 스프링 프레임워크, JPA같은 기술들과도 함께 사용된다. 

자바의 기본 애노테이션

@Override, @Deprecated, @SuppressWarnings와 같이 자바 언어가 기본으로 제공하는 애노테이션도 있다. 참고로 앞서 설명한 @Retention, @Target도 자바 언어가 기본으로 제공하는 애노테이션이지만, 이것은 애노테이션 자체를 정의하기 위한 메타 애노테이션이고, 지금 설명한 내용은 코드에 직접 사용하는 애노테이션이다.

@Override

package java.lang;

import java.lang.annotation.*;

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.SOURCE)
public @interface Override {
}

• 메서드 재정의가 정확하게 잘 되었는지 컴파일러가 체크하는데 사용한다.

OverrideMain

package cwchoiit.annotation.java;

public class OverrideMain {

    static class A {
        public void call() {
            System.out.println("A.call");
        }
    }

    static class B extends A {
        public void calll() {
            System.out.println("B.calll");
        }
    }

    public static void main(String[] args) {
        A a = new B();
        a.call();
    }
}

• B 클래스는 A 클래스를 상속받았다.
• A.call() 메서드를 B 클래스가 재정의하려고 시도한다. 이때, 실수로 오타가 발생해서 재정의가 아니라 자식 클래스에 calll()이라는 새로운 메서드를 정의해버렸다.
• 개발자의 의도는 A.call() 메서드의 재정의였지만, 자바 언어는 이것을 알 길이 없다. 자바 문법상 그냥 B에 calll()이라는 새로운 메서드가 하나 만들어졌을 뿐이다.

실행 결과

A.call

이럴 때, @Override 애노테이션을 사용한다. 이 애노테이션을 붙이면 자바 컴파일러가 메서드 재정의 여부를 체크해준다. 만약, 문제가 있다면 컴파일을 통과하지 않는다! 개발자의 실수를 자바 컴파일러가 잡아주는 좋은 애노테이션이기 때문에, 사용을 강하게 권장한다.

@Override의 @Retention(RetentionPolicy.SOURCE) 부분을 보자.

• RetentionPolicy.SOURCE로 설정하면, 컴파일 이후에 @Override 애노테이션은 제거된다.
• @Override는 컴파일 시점에만 사용하는 애노테이션이다. 런타임에는 필요하지 않으므로 이렇게 설정되어 있다.

@Deprecated

@Deprecated는 더 이상 사용되지 않는다는 뜻이다. 이 애노테이션이 적용된 기능은 사용을 권장하지 않는다. 예를 들면 다음과 같은 이유이다. 

• 해당 요소를 사용하면, 오류가 발생할 가능성이 있다.
• 호환되지 않게 변경되거나, 향후 버전에서 제거될 수 있다.
• 더 나은 최신 대체 요소로 대체되었다.
• 더 이상 사용되지 않는 기능이다.

package java.lang;

import java.lang.annotation.*;
import static java.lang.annotation.ElementType.*;


@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target(value={CONSTRUCTOR, FIELD, LOCAL_VARIABLE, METHOD, PACKAGE, MODULE, PARAMETER, TYPE})
public @interface Deprecated {
    String since() default "";

    boolean forRemoval() default false;
}

DeprecatedClass

package cwchoiit.annotation.java;

public class DeprecatedClass {

    public void call1() {
        System.out.println("DeprecatedClass.call1");
    }

    @Deprecated
    public void call2() {
        System.out.println("DeprecatedClass.call2");
    }

    @Deprecated(since = "2.4", forRemoval = true)
    public void call3() {
        System.out.println("DeprecatedClass.call3");
    }
}

• @Deprecated: 더는 사용을 권장하지 않는 요소이다.
  • since: 더 이상 사용하지 않게된 버전 정보
  • forRemoval: 미래 버전에 코드가 제거될 예정인지에 대한 여부

• @Deprecated만 있는 코드를 사용할 경우, IDE에서 경고를 나타낸다.
• @Deprecated + forRemoval이 있는 경우 IDE는 빨간색으로 심각한 경고를 나타낸다.

실행 결과

DeprecatedMain.main
DeprecatedClass.call1
DeprecatedClass.call2
DeprecatedClass.call3

@Deprecated는 컴파일 시점에 경고를 나타내지만, 프로그램은 작동한다.

@SuppressWarnings

이름 그대로, 경고를 억제하는 애노테이션이다. 자바 컴파일러가 문제를 경고하지만, 개발자가 해당 문제를 잘 알고 있기 때문에, 더는 경고하지 말라고 지시하는 애노테이션이다.

package java.lang;

import java.lang.annotation.*;
import static java.lang.annotation.ElementType.*;

@Retention(RetentionPolicy.SOURCE)
public @interface SuppressWarnings {
    String[] value();
}

SuppressWarningCase

package cwchoiit.annotation.java;

import java.util.ArrayList;
import java.util.Date;
import java.util.List;

public class SuppressWarningCase {

    @SuppressWarnings("unused")
    public void unusedWarning() {
        // 사용되지 않는 변수 경고 억제
        int unusedVariable = 10;
    }

    @SuppressWarnings("deprecation")
    public void deprecatedMethod() {
        Date date = new Date();
        // deprecated method 경고 억제
        int date1 = date.getDate();
    }

    @SuppressWarnings({"rawtypes", "unchecked"})
    public void uncheckedCast() {
        // 제네릭 타입 캐스팅 경고 억제, raw type 사용 경고
        List list = new ArrayList();

        // unchecked 경고
        List<String> stringList = (List<String>) list;
    }

    @SuppressWarnings("all")
    public void suppressAllWarning() {
        Date date = new Date();
        // deprecated method 경고 억제
        int date1 = date.getDate();

        // 제네릭 타입 캐스팅 경고 억제, raw type 사용 경고
        List list = new ArrayList();

        // unchecked 경고
        List<String> stringList = (List<String>) list;
    }
}

@SuppressWarnings에 사용하는 대표적인 값들은 다음과 같다.

• all → 모든 경고를 억제
• deprecation → 사용이 권장되지 않는 (deprecated) 코드를 사용할 때 발생하는 경고를 억제
• unchecked → 제네릭 타입과 관련된 unchecked 경고를 억제
• serial → Serializable 인터페이스를 구현할 때, serialVersionUID 필드를 선언하지 않은 경우 발생하는 경고를 억제
• rawtypes → 제네릭 타입이 명시되지 않은(raw) 타입을 사용할 때 발생하는 경고를 억제
• unused → 사용되지 않는 변수, 메서드, 필드 등을 선언했을 때 발생하는 경고를 억제

정리를 하자면...

자바 백엔드 개발자가 되려면, 스프링, JPA 같은 기술은 필수로 배워야한다. 그런데 처음 스프링이나 JPA 같은 기술을 배우면 기존에 자바 문법으로는 잘 이해가 안가는 마법같은 일들이 벌어진다. 

이러한 프레임워크들이 리플렉션과 애노테이션을 잘 활용해서 다음과 같은 마법 같은 기능들을 제공하기 때문이다.

1. 의존성 주입 (DI): 스프링은 리플렉션을 사용하여, 객체의 필드나 생성자에 자동으로 의존성을 주입한다. 개발자는 단순히 @Autowired 애노테이션만 붙이면 된다.
2. ORM: JPA는 애노테이션을 사용하여, 자바 객체와 데이터베이스 테이블 간의 매핑을 정의한다. 예를 들어, @Entity, @Table, @Column 등의 애노테이션으로 객체 - 테이블 관계를 설정한다. 
3. AOP: 스프링은 리플렉션을 사용하여, 런타임에 코드를 동적으로 주입하고, @Aspect, @Before, @After 등의 애노테이션으로 관점 지향 프로그래밍을 구현한다.
4. 설정의 자동화: @Configuration, @Bean 등의 애노테이션을 사용하여 다양한 설정을 편리하게 적용한다.
5. 트랜잭션 관리: @Transactional 애노테이션만으로 메서드 레벨의 DB 트랜잭션 처리가 가능해진다.

이러한 기능들은, 개발자가 비즈니스 로직에 집중할 수 있게 해주며, 보일러플레이트 코드를 크게 줄여준다. 하지만 이 "마법"의 이면에는 리플렉션과 애노테이션을 활용한 복잡한 메타프로그래밍이 숨어 있다. 프레임워크의 동작 원리를 깊이 이해하기 위해서는 리플렉션과 애노테이션에 대한 이해가 필수다. 이를 통해 프레임워크가 제공하는 편의성과 그 이면의 복잡성 사이의 균형을 잡을 수 있으며, 필요에 따라 프레임워크를 효과적으로 커스터마이징하거나 최적화할 수 있게 된다.

스프링이나 JPA 같은 프레임워크들은 이번에 학습한 리플렉션과 애노테이션을 극대화해서 사용한다. 리플렉션과 애노테이션을 배운 덕분에 이런 기술이 마법이 아니라, 리플렉션과 애노테이션을 활용한 고급 프로그래밍 기법이라는 것을 이해할 수 있을 것이다. 그리고 이러한 이해를 바탕으로, 프레임워크의 동작 원리를 더 깊이 파악하고 효과적으로 활용할 수 있게 될 것이다. 

이제 애노테이션과 리플렉션도 전부 배워봤다. 그럼 이전에 만들었던 HTTP 서버를 이 애노테이션을 활용해서 화룡점정을 찍어보자.

HTTP 서버7 - 애노테이션 서블릿1

지금까지 학습한 애노테이션 내용을 바탕으로 애노테이션 기반의 컨트롤러와 서블릿을 만들어보자.

예를 들어, 다음과 같은 컨트롤러를 만들 예정이다.

package cwchoiit.was.v7;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.servlet.annotation.RequestMapping;

public class SiteControllerV7 {

    @RequestMapping("/site1")
    public void site1(HttpRequest request, HttpResponse response) {
        response.writeBody("<h1>Site1</h1>");
    }

    @RequestMapping("/site2")
    public void site2(HttpRequest request, HttpResponse response) {
        response.writeBody("<h1>Site2</h1>");
    }
}

애노테이션부터 만들어보자.

RequestMapping

package cwchoiit.was.httpserver.servlet.annotation;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface RequestMapping {
    String value();
}

AnnotationServlet

package cwchoiit.was.httpserver.servlet.annotation;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.HttpServlet;
import cwchoiit.was.httpserver.PageNotFoundException;

import java.io.IOException;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.List;

public class AnnotationServlet implements HttpServlet {

    private final List<Object> controllers;

    public AnnotationServlet(List<Object> controllers) {
        this.controllers = controllers;
    }

    @Override
    public void service(HttpRequest request, HttpResponse response) throws IOException {
        String path = request.getPath();

        for (Object controller : controllers) {
            Class<?> aClass = controller.getClass();

            Method[] methods = aClass.getDeclaredMethods();
            for (Method method : methods) {
                boolean isRequestMapping = method.isAnnotationPresent(RequestMapping.class);
                if (!isRequestMapping) {
                    continue;
                }

                RequestMapping requestMapping = method.getAnnotation(RequestMapping.class);
                if (path.equals(requestMapping.value())) {
                    invoke(request, response, controller, method);
                    return;
                }
            }
        }

        throw new PageNotFoundException("No mapping found for path = " + path);
    }

    private static void invoke(HttpRequest request,
                               HttpResponse response,
                               Object controller,
                               Method method){
        try {
            method.invoke(controller, request, response);
        } catch (IllegalAccessException | InvocationTargetException e) {
            throw new RuntimeException(e);
        }
    }
}

• 리플렉션에서 사용한 코드와 비슷하다. 차이가 있다면 호출할 메서드를 찾을 때, 메서드의 이름을 비교하는 대신에 메서드에서 @RequestMapping 애노테이션을 찾고, 그곳의 value 값으로 비교한다는 점이다.
• 패키지 위치에 주의하자. 다른 프로젝트에서도 사용할 수 있다.

컨트롤러들을 만들어보자.

SearchControllerV7

package cwchoiit.was.v7;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.servlet.annotation.RequestMapping;

public class SearchControllerV7 {

    @RequestMapping("/search")
    public void search(HttpRequest request, HttpResponse response) {
        String query = request.getParameter("q");

        response.writeBody("<h1>Search</h1>");
        response.writeBody("<ul>");
        response.writeBody("<li>query = " + query + "</li>");
        response.writeBody("</ul>");
    }
}

SiteControllerV7

package cwchoiit.was.v7;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.servlet.annotation.RequestMapping;

public class SiteControllerV7 {

    @RequestMapping("/site1")
    public void site1(HttpRequest request, HttpResponse response) {
        response.writeBody("<h1>Site1</h1>");
    }

    @RequestMapping("/site2")
    public void site2(HttpRequest request, HttpResponse response) {
        response.writeBody("<h1>Site2</h1>");
    }
}

EtcControllerV7

package cwchoiit.was.v7;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.servlet.annotation.RequestMapping;

public class EtcControllerV7 {

    @RequestMapping("/")
    public void search(HttpRequest request, HttpResponse response) {
        response.writeBody("<h1>Home</h1>");
        response.writeBody("<ul>");
        response.writeBody("<li><a href='/site1'>site1</a></li>");
        response.writeBody("<li><a href='/site2'>site2</a></li>");
        response.writeBody("<li><a href='/search?q=hello'>search</a></li>");
        response.writeBody("</ul>");
    }

    @RequestMapping("/favicon.ico")
    public void discardPath(HttpRequest request, HttpResponse response) {
        // NOTHING
    }
}

ServerMainV7

package cwchoiit.was.v7;

import cwchoiit.was.httpserver.HttpServer;
import cwchoiit.was.httpserver.ServletManager;
import cwchoiit.was.httpserver.servlet.annotation.AnnotationServlet;

import java.io.IOException;
import java.util.List;

public class ServerMainV7 {

    private static final int PORT = 12345;

    public static void main(String[] args) throws IOException {
        List<Object> controllers = List.of(new SiteControllerV7(), new SearchControllerV7(), new EtcControllerV7());

        AnnotationServlet annotationServlet = new AnnotationServlet(controllers);

        ServletManager servletManager = new ServletManager();
        servletManager.setDefaultServlet(annotationServlet);

        new HttpServer(PORT, servletManager).start();
    }
}

실행 결과

• 기존과 같다.

정리

애노테이션을 사용한 덕분에 매우 편리하고, 또 실용적으로 웹 애플리케이션을 만들 수 있게됐다. 현대의 웹 프레임워크들은 대부분 애노테이션을 사용해서 편리하게 호출 메서드를 찾을 수 있는 지금과 같은 방식을 제공한다. 자바 백엔드의 사실상 표준 기술인 스프링 프레임워크도 스프링 MVC를 통해 이런 방식의 기능을 제공한다.

HTTP 서버8 - 애노테이션 서블릿2 - 동적 바인딩

만든 애노테이션 기반 컨트롤러에서 아쉬운 부분이 있다. 예를 들어, 다음 site1(), site2()의 경우엔 HttpRequest request가 전혀 필요하지 않다. HttpResponse response만 있으면 된다.

SiteControllerV7

package cwchoiit.was.v7;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.servlet.annotation.RequestMapping;

public class SiteControllerV7 {

    @RequestMapping("/site1")
    public void site1(HttpRequest request, HttpResponse response) {
        response.writeBody("<h1>Site1</h1>");
    }

    @RequestMapping("/site2")
    public void site2(HttpRequest request, HttpResponse response) {
        response.writeBody("<h1>Site2</h1>");
    }
}

컨트롤러의 메서드를 만들 때, HttpRequest request, HttpResponse response 중에 딱 필요한 메서드만 유연하게 받을 수 있도록 AnnotationServlet의 기능을 개선해보자.

AnnotationServletV2

package cwchoiit.was.httpserver.servlet.annotation;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.HttpServlet;
import cwchoiit.was.httpserver.PageNotFoundException;

import java.io.IOException;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.List;

public class AnnotationServletV2 implements HttpServlet {

    private final List<Object> controllers;

    public AnnotationServletV2(List<Object> controllers) {
        this.controllers = controllers;
    }

    @Override
    public void service(HttpRequest request, HttpResponse response) throws IOException {
        String path = request.getPath();

        for (Object controller : controllers) {
            Class<?> aClass = controller.getClass();

            Method[] methods = aClass.getDeclaredMethods();
            for (Method method : methods) {
                boolean isRequestMapping = method.isAnnotationPresent(RequestMapping.class);
                if (!isRequestMapping) {
                    continue;
                }

                RequestMapping requestMapping = method.getAnnotation(RequestMapping.class);
                if (path.equals(requestMapping.value())) {
                    invoke(request, response, controller, method);
                    return;
                }
            }
        }

        throw new PageNotFoundException("No mapping found for path = " + path);
    }

    private static void invoke(HttpRequest request,
                               HttpResponse response,
                               Object controller,
                               Method method){
        try {
            Class<?>[] parameterTypes = method.getParameterTypes();
            Object[] args = new Object[parameterTypes.length];

            for (int i = 0; i < parameterTypes.length; i++) {
                if (parameterTypes[i] == HttpRequest.class) {
                    args[i] = request;
                } else if (parameterTypes[i] == HttpResponse.class) {
                    args[i] = response;
                } else {
                    throw new IllegalArgumentException("Invalid parameter type: " + parameterTypes[i]);
                }
            }

            method.invoke(controller, args);
        } catch (IllegalAccessException | InvocationTargetException e) {
            throw new RuntimeException(e);
        }
    }
}

• invoke() 부분을 보자.
• 메서드의 파라미터 타입을 확인한 후에, 각 타입에 맞는 값을 args[]에 담아서 메서드를 호출한다.
• Method.invoke()는 두번째 인자로 이 메서드를 실행하기 위한 파라미터로 `...args`를 받기 때문에 배열을 그대로 넣을수가 있다.

이제, 각 컨트롤러에서 필요한 파라미터만 받아서 사용하도록 컨트롤러를 바꿔보자.

EtcControllerV8

package cwchoiit.was.v8;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.servlet.annotation.RequestMapping;

public class EtcControllerV8 {

    @RequestMapping("/")
    public void search(HttpResponse response) {
        response.writeBody("<h1>Home</h1>");
        response.writeBody("<ul>");
        response.writeBody("<li><a href='/site1'>site1</a></li>");
        response.writeBody("<li><a href='/site2'>site2</a></li>");
        response.writeBody("<li><a href='/search?q=hello'>search</a></li>");
        response.writeBody("</ul>");
    }

    @RequestMapping("/favicon.ico")
    public void discardPath() {
        // NOTHING
    }
}

SearchControllerV8

package cwchoiit.was.v8;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.servlet.annotation.RequestMapping;

public class SearchControllerV8 {

    @RequestMapping("/search")
    public void search(HttpRequest request, HttpResponse response) {
        String query = request.getParameter("q");

        response.writeBody("<h1>Search</h1>");
        response.writeBody("<ul>");
        response.writeBody("<li>query = " + query + "</li>");
        response.writeBody("</ul>");
    }
}

SiteControllerV8

package cwchoiit.was.v8;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.servlet.annotation.RequestMapping;

public class SiteControllerV8 {

    @RequestMapping("/site1")
    public void site1(HttpResponse response) {
        response.writeBody("<h1>Site1</h1>");
    }

    @RequestMapping("/site2")
    public void site2(HttpResponse response) {
        response.writeBody("<h1>Site2</h1>");
    }
}

이제 실행해보면 실행 결과는 똑같지만, 동적 바인딩을 통해 파라미터는 딱 필요한 녀석들만 받을 수 있게 변경했다.

ServerMainV8

package cwchoiit.was.v8;

import cwchoiit.was.httpserver.HttpServer;
import cwchoiit.was.httpserver.ServletManager;
import cwchoiit.was.httpserver.servlet.annotation.AnnotationServletV2;

import java.io.IOException;
import java.util.List;

public class ServerMainV8 {

    private static final int PORT = 12345;

    public static void main(String[] args) throws IOException {
        List<Object> controllers = List.of(new SiteControllerV8(), new SearchControllerV8(), new EtcControllerV8());

        AnnotationServletV2 annotationServlet = new AnnotationServletV2(controllers);

        ServletManager servletManager = new ServletManager();
        servletManager.setDefaultServlet(annotationServlet);

        new HttpServer(PORT, servletManager).start();
    }
}

정리

AnnotationServletV2에서 호출할 컨트롤러 메서드의 매개변수를 먼저 확인한 다음, 매개변수에 필요한 값을 동적으로 만들어서 전달했다. 덕분에 컨트롤러의 메서드는 자신에게 필요한 값만 선언하고, 전달 받을 수 있다. 이런 기능을 확장하면 HttpRequest, HttpResponse뿐만 아니라 다양한 객체들도 전달할 수 있다. 참고로 스프링 MVC도 이런 방식으로 다양한 매개변수의 값을 동적으로 전달한다. 

HTTP 서버9 - 애노테이션 서블릿3 - 성능 최적화

지금까지 만든 AnnotationServletV2는 2가지 아쉬운 점이 있다.

• 성능 최적화
• 중복 매핑 문제

문제1 - 성능 최적화

AnnotationServletV2 - 일부분

@Override
public void service(HttpRequest request, HttpResponse response) throws IOException {
    String path = request.getPath();

    for (Object controller : controllers) {
        Class<?> aClass = controller.getClass();

        Method[] methods = aClass.getDeclaredMethods();
        for (Method method : methods) {
            boolean isRequestMapping = method.isAnnotationPresent(RequestMapping.class);
            if (!isRequestMapping) {
                continue;
            }

            RequestMapping requestMapping = method.getAnnotation(RequestMapping.class);
            if (path.equals(requestMapping.value())) {
                invoke(request, response, controller, method);
                return;
            }
        }
    }

    throw new PageNotFoundException("No mapping found for path = " + path);
}

• 모든 컨트롤러의 메서드를 하나하나 순서대로 찾는다. 이것은 결과적으로 O(n)의 성능을 보인다.
• 만약, 모든 컨트롤러의 메서드가 합쳐서 100개라면 최악의 경우 100번은 찾아야 한다.
• 저게 문제가 아니라 진짜 문제는, 고객의 요청때마다 이 로직이 호출된다는 점이다. 동시에 100명의 고객이 요청하면 최악의 경우, 100 * 100번 해당 로직이 호출될 수 있다.
• 이 부분의 성능을 O(n) → O(1)으로 변경하려면 어떻게 해야할까?

문제2 - 중복 매핑 문제

package cwchoiit.was.v8;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.servlet.annotation.RequestMapping;

public class SiteControllerV8 {

    @RequestMapping("/site1")
    public void site1(HttpResponse response) {
        response.writeBody("<h1>Site1</h1>");
    }

    @RequestMapping("/site2")
    public void site2(HttpResponse response) {
        response.writeBody("<h1>Site2</h1>");
    }

    @RequestMapping("/site2")
    public void page2(HttpResponse response) {
        response.writeBody("<h1>Site2</h1>");
    }
}

• 개발자가 실수로 @RequestMapping에 같은`/site2`를 2개 정의하면 어떻게 될까?

이 경우, 현재 로직에서는 아무런 문제도 일으키지 않은 채 그냥 먼저 찾은 메서드가 호출된다. 개발에서 가장 나쁜 것은 모호한 것이다! 모호한 문제는 반드시 제거해야 한다! 그렇지 않으면 나중에 큰 재앙으로 다가온다.

최적화 구현

AnnotationServletV3

package cwchoiit.was.httpserver.servlet.annotation;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.HttpServlet;
import cwchoiit.was.httpserver.PageNotFoundException;

import java.io.IOException;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

public class AnnotationServletV3 implements HttpServlet {

    private final Map<String, ControllerMethod> pathMap;

    public AnnotationServletV3(List<Object> controllers) {
        this.pathMap = new HashMap<>();
        initializePathMap(controllers);
    }

    private void initializePathMap(List<Object> controllers) {
        for (Object controller : controllers) {
            Method[] methods = controller.getClass().getDeclaredMethods();
            for (Method method : methods) {
                if (method.isAnnotationPresent(RequestMapping.class)) {
                    String path = method.getAnnotation(RequestMapping.class).value();

                    if (pathMap.containsKey(path)) {
                        ControllerMethod controllerMethod = pathMap.get(path);
                        throw new IllegalArgumentException("경로 중복 등록, path = " + path + ", method = " + method + ", 이미 등록된 메서드 = " + controllerMethod.method);
                    }
                    pathMap.put(path, new ControllerMethod(controller, method));
                }
            }
        }
    }

    @Override
    public void service(HttpRequest request, HttpResponse response) throws IOException {
        String path = request.getPath();

        ControllerMethod controllerMethod = pathMap.get(path);
        if (controllerMethod == null) {
            throw new PageNotFoundException("No mapping found for path = " + path);
        }
        controllerMethod.invoke(request, response);
    }

    private static class ControllerMethod {
        private final Object controller;
        private final Method method;

        public ControllerMethod(Object controller, Method method) {
            this.controller = controller;
            this.method = method;
        }

        public void invoke(HttpRequest request, HttpResponse response) {
            try {
                Class<?>[] parameterTypes = method.getParameterTypes();
                Object[] args = new Object[parameterTypes.length];

                for (int i = 0; i < parameterTypes.length; i++) {
                    if (parameterTypes[i] == HttpRequest.class) {
                        args[i] = request;
                    } else if (parameterTypes[i] == HttpResponse.class) {
                        args[i] = response;
                    } else {
                        throw new IllegalArgumentException("Invalid parameter type: " + parameterTypes[i]);
                    }
                }

                method.invoke(controller, args);
            } catch (IllegalAccessException | InvocationTargetException e) {
                throw new RuntimeException(e);
            }
        }
    }
}

초기화

• AnnotationServletV3을 생성하는 시점에 @RequestMapping을 사용하는 컨트롤러의 메서드를 모두 찾아서 pathMap에 보관한다. 
• 초기화가 끝나면 pathMap이 완성된다.
• ControllerMethod: @RequestMapping의 대상 메서드와 메서드가 있는 컨트롤러 객체를 캡슐화했다. 이렇게 하면 ControllerMethod 객체를 사용해서 편리하게 실제 메서드를 호출할 수 있다. 

실행

• ControllerMethod controllerMethod = pathMap.get(path)를 사용해서, URL 경로에 매핑된 컨트롤러의 메서드를 찾아온다. 이 과정은 HashMap을 사용하므로 일반적으로 O(1)의 매우 빠른 성능을 제공한다. 
• 그러니까 결과적으로 최초에 딱 한번만 O(n)의 시간복잡도를 가지는 행위를 하면, 그 이후부터는 O(1)의 성능으로 매우 빠르게 요청에 대한 응답을 줄 수가 있는 것이다. 

중복 경로 체크

if (pathMap.containsKey(path)) {
    ControllerMethod controllerMethod = pathMap.get(path);
    throw new IllegalArgumentException("경로 중복 등록, path = " + path + ", method = " + method + ", 이미 등록된 메서드 = " + controllerMethod.method);
}

• pathMap에 이미 등록된 경로가 있다면 중복 경로이다. 이 경우 예외를 던져서 개발자에게 중복된 경로가 있음을 인지하게 한다.

ServerMainV8

package cwchoiit.was.v8;

import cwchoiit.was.httpserver.HttpServer;
import cwchoiit.was.httpserver.HttpServlet;
import cwchoiit.was.httpserver.ServletManager;
import cwchoiit.was.httpserver.servlet.annotation.AnnotationServletV2;
import cwchoiit.was.httpserver.servlet.annotation.AnnotationServletV3;

import java.io.IOException;
import java.util.List;

public class ServerMainV8 {

    private static final int PORT = 12345;

    public static void main(String[] args) throws IOException {
        List<Object> controllers = List.of(new SiteControllerV8(), new SearchControllerV8(), new EtcControllerV8());

        //AnnotationServletV2 annotationServlet = new AnnotationServletV2(controllers);
        HttpServlet annotationServlet = new AnnotationServletV3(controllers);

        ServletManager servletManager = new ServletManager();
        servletManager.setDefaultServlet(annotationServlet);

        new HttpServer(PORT, servletManager).start();
    }
}

• V8을 그대로 사용하되, 일부만 수정하자. AnnotationServletV2 → AnnotationServletV3을 사용하도록 변경하자.
• 다른 코드는 변경할 부분이 없다.

실행 결과

• 기존과 같다.

중복 체크를 하기 위해 같은 @RequestMapping을 추가해보자.

package cwchoiit.was.v8;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.servlet.annotation.RequestMapping;

public class SiteControllerV8 {

    @RequestMapping("/site1")
    public void site1(HttpResponse response) {
        response.writeBody("<h1>Site1</h1>");
    }

    @RequestMapping("/site2")
    public void site2(HttpResponse response) {
        response.writeBody("<h1>Site2</h1>");
    }

    @RequestMapping("/site2")
    public void page2(HttpResponse response) {
        response.writeBody("<h1>Site2</h1>");
    }
}

실행 결과

Exception in thread "main" java.lang.IllegalArgumentException: 경로 중복 등록, path = /site2, method = public void cwchoiit.was.v8.SiteControllerV8.page2(cwchoiit.was.httpserver.HttpResponse), 이미 등록된 메서드 = public void cwchoiit.was.v8.SiteControllerV8.site2(cwchoiit.was.httpserver.HttpResponse)
	at cwchoiit.was.httpserver.servlet.annotation.AnnotationServletV3.initializePathMap(AnnotationServletV3.java:33)
	at cwchoiit.was.httpserver.servlet.annotation.AnnotationServletV3.<init>(AnnotationServletV3.java:21)
	at cwchoiit.was.v8.ServerMainV8.main(ServerMainV8.java:20)

• 서버를 실행하는 시점에 바로 오류가 발생하고, 서버 실행이 중단된다. 이렇게 서버 실행 시점에 발견할 수 있는 오류는 아주 좋은 오류이다. 만약, 이런 오류를 체크하지 않고, `/site2`가 2개 유지된 채로 작동한다면, 고객은 기대한 화면과 다른 화면을 보고 있을 수 있다.

3가지 오류

• 컴파일 오류: 가장 좋은 오류이다. 프로그램 실행 전에 개발자가 가장 빠르게 문제를 확인할 수 있다.
• 런타임 오류 - 시작 오류: 자바 프로그램이나 서버를 시작하는 시점에 발견할 수 있는 오류이다. 문제를 아주 빠르게 발견할 수 있기 때문에 좋은 오류이다. 고객이 문제를 인지하기 전에 수정하고 해결할 수 있다.
• 런타임 오류 - 작동 중 오류: 고객이 특정 기능을 작동할 때 발생하는 오류이다. 원인 파악과 문제 해결에 가장 많은 시간이 걸리고 가장 큰 피해를 주는 오류이다.

정리

드디어 성능, 유연성, 오류 체크 기능까지 강화한 쓸만한 AnnotationServletV3를 만들어냈다.

참고자료

리플렉션이 필요한 이유

이전 포스팅에서 배운 HTTP 서버를 만들면서, 커맨드 패턴을 도입하고 사용해봤던 서블릿은 아주 유용하지만, 몇가지 단점이 있다.

• 하나의 클래스에 하나의 기능만 만들 수 있다.
• 새로 만든 클래스를 URL 경로와 항상 매핑해야 한다.

단점1 - 하나의 클래스에 하나의 기능만 만들 수 있다.

기능 하나를 만들때마다 각각 별도의 클래스를 만들고, 구현해야 한다. 이것은 복잡한 기능에서는 효과적이지만, 간단한 기능을 만들 때는 클래스가 너무 많이 만들어지기 때문에 부담스럽다.

HomeServlet

package cwchoiit.was.v5.servlet;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.HttpServlet;

import java.io.IOException;

public class HomeServlet implements HttpServlet {
    @Override
    public void service(HttpRequest request, HttpResponse response) throws IOException {
        response.writeBody("<h1>Home</h1>");
        response.writeBody("<ul>");
        response.writeBody("<li><a href='/site1'>site1</a></li>");
        response.writeBody("<li><a href='/site2'>site2</a></li>");
        response.writeBody("<li><a href='/search?q=hello'>search</a></li>");
        response.writeBody("</ul>");
    }
}

Site1Servlet

package cwchoiit.was.v5.servlet;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.HttpServlet;

import java.io.IOException;

public class Site1Servlet implements HttpServlet {
    @Override
    public void service(HttpRequest request, HttpResponse response) throws IOException {
        response.writeBody("<h1>Site1</h1>");
    }
}

Site2Servlet

package cwchoiit.was.v5.servlet;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.HttpServlet;

import java.io.IOException;

public class Site2Servlet implements HttpServlet {
    @Override
    public void service(HttpRequest request, HttpResponse response) throws IOException {
        response.writeBody("<h1>Site2</h1>");
    }
}

이런식으로 거의 같은 기능을 하는데도 클래스를 하나씩 만들어줘야 한다. 이런 문제를 해결할 방법이 없을까?

바로 아래 코드처럼 하나의 클래스 안에서 다양한 기능을 처리하는 것이다.

public class ReflectController {
      
      public void site1(HttpRequest request, HttpResponse response) {
          response.writeBody("<h1>site1</h1>");
      }
      
      public void site2(HttpRequest request, HttpResponse response) {
          response.writeBody("<h1>site2</h1>");
      }
      
      public void search(HttpRequest request, HttpResponse response) {
          String query = request.getParameter("q");
          response.writeBody("<h1>Search</h1>");
          response.writeBody("<ul>");
          response.writeBody("<li>query: " + query + "</li>");
          response.writeBody("</ul>");
      } 
}

물론, 필요하면 클래스를 나눌 수 있게 해도 된다. 예를 들어, 이렇게 말이다.

• SiteController
• SearchController

이렇게 하면 비슷한 기능을 한 곳에 모을 수 있는 장점도 있고, 작은 기능 하나를 추가할 때마다 클래스를 계속 만들지 않아도 된다.

단점2 - 새로 만든 클래스를 URL 경로와 항상 매핑해야 한다.

  servletManager.add("/site1", new Site1Servlet());
  servletManager.add("/site2", new Site2Servlet());
  servletManager.add("/search", new SearchServlet());

• 새로운 기능을 하나 추가할 때마다 이런 매핑 작업도 함께 추가해야 한다.

그런데 여기서 앞서 본 ReflectController 예시를 보자. URL 경로의 이름과 메서드 이름이 같다.

• `/site1` → site1()
• `/site2` → site2()
• `/search` → search()

만약, URL 경로의 이름과 같은 이름의 메서드를 찾아서 호출할 수 있다면? 예를 들어, `/site1`이 입력되면 site1()이라는 메서드를 이름으로 찾아서 호출하는 것이다. 클래스에 있는 메서드의 이름을 찾아서 이렇게 호출할 수 있다면, 번거로운 매핑 작업을 제거할 수 있을 것이다. 자바 프로그램 실행 중에 이름으로 메서드를 찾고, 또 찾은 메서드를 호출하려면 자바의 리플렉션 기능을 먼저 알아야 한다. 리플렉션 기능을 먼저 학슴하고, 또 학습한 내용을 기반으로 ReflectController 같은 기능을 만들어서 적용해보자.

클래스와 메타데이터

클래스가 제공하는 다양한 정보를 동적으로 분석하고 사용하는 기능을 리플렉션(Reflection)이라고 한다. 리플렉션을 통해 프로그램 실행 중에 클래스, 메서드, 필드 등에 대한 정보를 얻거나, 새로운 객체를 생성하고 메서드를 호출하며, 필드의 값을 읽고 쓸 수 있다. 

리플렉션을 통해 얻을 수 있는 정보는 다음과 같다.

• 클래스의 메타데이터: 클래스 이름, 접근 제어자, 부모 클래스, 구현된 인터페이스 등
• 필드 정보: 필드의 이름, 타입, 접근 제어자를 확인하고, 해당 필드의 값을 읽거나 수정할 수 있다.
• 메서드 정보: 메서드 이름, 반환 타입, 매개변수 정보를 확인하고, 실행 중에 동적으로 메서드를 호출할 수 있다.
• 생성자 정보: 생성자의 매개변수 타입과 개수를 확인하고, 동적으로 객체를 생성할 수 있다.

참고로, 리플렉션(Reflection)이라는 용어는 영어 단어 'reflect'에서 유래된 것으로, "반사하다" 또는 "되돌아보다"라는 의미를 가지고 있다. 리플렉션은 프로그램이 실행 중에 자기 자신의 구조를 들여다보고, 그 구조를 변경하거나 조작할 수 있는 기능을 의미한다. 쉽게 말해, 리플렉션을 통해 클래스, 메서드, 필드 등의 메타데이터를 런타임에 동적으로 조사하고 사용할 수 있다. 이는 마치 거울에 비친 자신을 보는 것과 같이, 프로그램이 자기 자신의 내부를 반사(reflect)하여 들여다본다는 의미이다.

리플렉션으로 클래스 메타데이터 조회 

package cwchoiit.reflection.data;

public class BasicData {

    public String publicField;
    private int privateField;

    public BasicData() {
        System.out.println("BasicData.BasicData");
    }

    private BasicData(String data) {
        System.out.println("BasicData.BasicData:" + data);
    }

    public void call() {
        System.out.println("BasicData.call");
    }

    public String hello(String string) {
        System.out.println("BasicData.hello");
        return string + " hello";
    }

    private void privateMethod() {
        System.out.println("BasicData.privateMethod");
    }

    void defaultMethod() {
        System.out.println("BasicData.defaultMethod");
    }

    protected void protectedMethod() {
        System.out.println("BasicData.protectedMethod");
    }
}

• 예제를 위한 기본 클래스이다.

BasicV1

package cwchoiit.reflection;

import cwchoiit.reflection.data.BasicData;

public class BasicV1 {

    public static void main(String[] args) throws ClassNotFoundException {
        // 클래스 메타데이터 조회 방법 3가지

        // 1. 클래스에서 찾기
        Class<BasicData> basicDataClass1 = BasicData.class;
        System.out.println("basicDataClass1 = " + basicDataClass1);

        // 2. 인스턴스에서 찾기
        BasicData basicInstance = new BasicData();
        Class<? extends BasicData> basicDataClass2 = basicInstance.getClass();
        System.out.println("basicDataClass2 = " + basicDataClass2);

        // 3. 문자로 찾기
        String className = "cwchoiit.reflection.data.BasicData"; // 패키지 명 주의
        Class<?> basicDataClass3 = Class.forName(className);
        System.out.println("basicDataClass3 = " + basicDataClass3);
    }
}

• 클래스의 메타데이터는 Class라는 클래스로 표현된다.
• 그리고 이 Class라는 클래스를 획득하는 방법에는 3가지가 있다. 
  • 클래스에서 찾기
  • 인스턴스에서 찾기
  • 문자로 찾기

클래스에서 찾기

Class<BasicData> basicDataClass1 = BasicData.class

클래스명에 .class를 사용하면 획득할 수 있다.

인스턴스에서 찾기

  BasicData helloInstance = new BasicData();
  Class<? extends BasicData> basicDataClass2 = helloInstance.getClass();

인스턴스에서 .getClass() 메서드를 호출하면 획득할 수 있다. 반환 타입을 보면 Class<? extends BasicData>로 표현되는데, 실제 인스턴스가 BasicData 타입일 수도 있지만, 그 자식 타입일수도 있기 때문이다. 

이해를 돕기 위해 다음 예를 보자.

  Parent parent = new Child();
  Class<? extends Parent> parentClass = parent.getClass();

Parent 타입을 통해 getClass()를 호출했지만, 실제 인스턴스는 Child이다. 따라서 제네릭에서 자식 타입도 허용할 수 있도록 ? extends Parent를 사용한다.

문자로 찾기

String className = "reflection.data.BasicData"; // 패키지명 주의
Class<?> basicData3 = Class.forName(className);

이 부분이 가장 흥미로운데, 단순히 문자로 클래스의 메타데이터를 조회할 수 있다. 예를 들어서 콘솔에서 사용자 입력으로 원하는 클래스를 동적으로 찾을 수 있다는 뜻이다. 

기본 정보 탐색

이렇게 찾은 클래스 메타데이터로 어떤 일들을 할 수 있는지 알아보자.

BasicV2

package cwchoiit.reflection;

import cwchoiit.reflection.data.BasicData;

import java.lang.reflect.Modifier;
import java.util.Arrays;

public class BasicV2 {

    public static void main(String[] args) {
        Class<BasicData> basicDataClass = BasicData.class;

        System.out.println("basicDataClass.getName() = " + basicDataClass.getName());
        System.out.println("basicDataClass.getSimpleName() = " + basicDataClass.getSimpleName());
        System.out.println("basicDataClass.getPackage() = " + basicDataClass.getPackage());

        System.out.println("basicDataClass.getSuperclass() = " + basicDataClass.getSuperclass());
        System.out.println("basicDataClass.getInterfaces() = " + Arrays.toString(basicDataClass.getInterfaces()));

        System.out.println("basicDataClass.isInterface() = " + basicDataClass.isInterface());
        System.out.println("basicDataClass.isEnum() = " + basicDataClass.isEnum());
        System.out.println("basicDataClass.isAnnotation() = " + basicDataClass.isAnnotation());

        int modifiers = basicDataClass.getModifiers();
        System.out.println("basicData.getModifiers() = " + modifiers);
        System.out.println("isPublic = " + Modifier.isPublic(modifiers));
        System.out.println("Modifier.toString() = " + Modifier.toString(modifiers));
    }
}

실행 결과

basicDataClass.getName() = cwchoiit.reflection.data.BasicData
basicDataClass.getSimpleName() = BasicData
basicDataClass.getPackage() = package cwchoiit.reflection.data
basicDataClass.getSuperclass() = class java.lang.Object
basicDataClass.getInterfaces() = []
basicDataClass.isInterface() = false
basicDataClass.isEnum() = false
basicDataClass.isAnnotation() = false
basicData.getModifiers() = 1
isPublic = true
Modifier.toString() = public

• 클래스 이름, 패키지, 부모 클래스, 구현한 인터페이스, 수정자 정보 등 다양한 정보를 획득할 수 있다.

참고로 수정자는 접근 제어자와 비 접근 제어자(기타 수정자)로 나눌 수 있다.

• 접근 제어자: public, protected, default, private
• 비 접근 제어자: static, final, abstract, synchronized, volatile 등

getModifiers()를 통해 수정자가 조합된 숫자를 얻고, Modifier를 사용해서 실제 수정자 정보를 확인할 수 있다.

조금만 더 자세히 얘기를 해보자면, 다음 코드를 보자.

int modifiers = basicDataClass.getModifiers();
System.out.println("basicData.getModifiers() = " + modifiers);

이것의 결과로 1이 찍힌것이다. 1은 Modifier.PUBLIC을 의미하고 이 상수값이 1로 정의되어 있다. 그리고 해당 클래스의 수정자가 1이라는 것은 이 클래스는 public으로 선언된 클래스라는 것을 말하는 것이다. 

그럼, 메서드들의 수정자도 한번 찍어보자.

Method[] methods = basicDataClass.getDeclaredMethods();
for (Method method : methods) {
    System.out.println(method.getModifiers());
}

실행 결과

1
1
2
0
4

이 클래스가 가지고 있는 모든 declaredMethod를 순회하면서 수정자를 찍어보니 이렇게 나왔다. 이후에 메서드에 대한 얘기도 할테니 가볍게만 이야기 하자면, declaredMethods는 해당 클래스에서 선언된 모든 메서드들을 가져온다.

1은 public, 2는 private, 0은 default, 4는 protected이다. 그리고 실제로 그런지 보자.

public void call() {
    System.out.println("BasicData.call");
}

public String hello(String string) {
    System.out.println("BasicData.hello");
    return string + " hello";
}

private void privateMethod() {
    System.out.println("BasicData.privateMethod");
}

void defaultMethod() {
    System.out.println("BasicData.defaultMethod");
}

protected void protectedMethod() {
    System.out.println("BasicData.protectedMethod");
}

이렇게 수정자는 이런 내용을 알려주는 것이다. 그리고 수정자는 접근 제어자와 비 접근 제어자 둘 다 다룬다고 했는데 만약, final 키워드를 public 메서드에 붙이면 어떻게 나올까?

public final void call() {
    System.out.println("BasicData.call");
}

이렇게 하고 다시 돌려보면 17이라는 숫자가 나온다. 1(public) + 16(final) = 17이 나온것이다. 이런것이 getModifiers()다.

메서드 탐색과 동적 호출

클래스 메타데이터를 통해 클래스가 제공하는 메서드의 정보를 확인해보자.

MethodV1

package cwchoiit.reflection;

import cwchoiit.reflection.data.BasicData;

import java.lang.reflect.Method;

public class MethodV1 {
    public static void main(String[] args) {
        Class<BasicData> basicDataClass = BasicData.class;

        // 해당 클래스와 상위 클래스에 있는 public 메서드들
        System.out.println("======= methods() ========");
        Method[] methods = basicDataClass.getMethods();
        for (Method method : methods) {
            System.out.println("method = " + method);
        }

        // 해당 클래스에서 선언한 모든 메서드들
        System.out.println("======= declaredMethods() ========");
        Method[] declaredMethods = basicDataClass.getDeclaredMethods();
        for (Method declaredMethod : declaredMethods) {
            System.out.println("declaredMethod = " + declaredMethod);
        }
    }
}

• Class.getMethods() 또는 Class.getDeclaredMethods()를 호출하면, Method라는 타입으로 메서드의 메타데이터를 얻을 수 있다. 이 클래스는 메서드의 모든 정보를 가지고 있다.

getMethods() vs getDeclaredMethods()

• getMethods(): 해당 클래스와 상위 클래스에서 상속된 모든 public 메서드를 반환
• getDeclaredMethods(): 해당 클래스에서 선언된 모든 메서드를 반환하며, 접근 제어자에 관계없이 반환. 상속된 메서드는 포함되지 않음.

실행 결과

======= methods() ========
method = public void cwchoiit.reflection.data.BasicData.call()
method = public final native java.lang.Class java.lang.Object.getClass()
method = public final void java.lang.Object.wait() throws java.lang.InterruptedException
method = public final void java.lang.Object.wait(long) throws java.lang.InterruptedException
method = public final void java.lang.Object.wait(long,int) throws java.lang.InterruptedException
method = public int java.lang.Object.hashCode()
method = public boolean java.lang.Object.equals(java.lang.Object)
method = public final native void java.lang.Object.notifyAll()
method = public java.lang.String java.lang.Object.toString()
method = public java.lang.String cwchoiit.reflection.data.BasicData.hello(java.lang.String)
method = public final native void java.lang.Object.notify()
======= declaredMethods() ========
declaredMethod = public void cwchoiit.reflection.data.BasicData.call()
declaredMethod = public java.lang.String cwchoiit.reflection.data.BasicData.hello(java.lang.String)
declaredMethod = private void cwchoiit.reflection.data.BasicData.privateMethod()
declaredMethod = void cwchoiit.reflection.data.BasicData.defaultMethod()
declaredMethod = protected void cwchoiit.reflection.data.BasicData.protectedMethod()

메서드 동적 호출

Method 객체를 사용하면 메서드를 직접 호출할 수도 있다.

MethodV2

package cwchoiit.reflection;

import cwchoiit.reflection.data.BasicData;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

public class MethodV2 {
    public static void main(String[] args) throws NoSuchMethodException, InvocationTargetException, IllegalAccessException {

        // 정적 메서드 호출 - 일반적인 메서드 호출
        BasicData basicData = new BasicData();
        basicData.call();

        // 동적 메서드 호출 - 리플렉션 사용
        Class<? extends BasicData> basicDataClass = basicData.getClass();
        String methodName = "hello";

        // 메서드 이름을 변수로 변경할 수 있다.
        Method method1 = basicDataClass.getDeclaredMethod(methodName, String.class);
        Object returnValue = method1.invoke(basicData, "hi");
        System.out.println("returnValue = " + returnValue);
    }
}

• 리플렉션을 사용하면 매우 다양한 체크 예외가 발생한다.

실행 결과

BasicData.BasicData
BasicData.call
BasicData.hello
returnValue = hi hello

일반적인 메서드 호출 - 정적

인스턴스 참조를 통해 메서드를 호출하는 방식이 일반적인 메서드 호출 방식이다. 이 방식은 코드를 변경하지 않는 이상 다른 메서드로 변경하는 것이 불가능하다.

// 정적 메서드 호출 - 일반적인 메서드 호출
BasicData basicData = new BasicData();
basicData.call();

이렇게 되어 있는 코드에서 call() 메서드를 바꾸지 않는 이상 call()가 호출되는것을 바꾸는 것은 불가능하다는 말이다.

메서드 동적 호출 - 리플렉션 사용

// 동적 메서드 호출 - 리플렉션 사용
Class<? extends BasicData> basicDataClass = basicData.getClass();
String methodName = "hello";

// 메서드 이름을 변수로 변경할 수 있다.
Method method1 = basicDataClass.getDeclaredMethod(methodName, String.class);
Object returnValue = method1.invoke(basicData, "hi");
System.out.println("returnValue = " + returnValue);

위 코드처럼, 리플렉션을 사용하면 동적으로 메서드를 호출할 수 있다.

• 클래스 메타데이터가 제공하는 getMethod() 또는 getDeclaredMethod()에 메서드 이름과, 사용하는 매개변수의 타입을 전달하면 원하는 메서드를 찾을 수 있다. 
• 이 예제에선 'hello' 라는 메서드 이름에, String 매개변수가 있는 메서드를 찾는다.

Object returnValue = method1.invoke(basicData, "hi");

• Method.invoke() 메서드에 실행할 인스턴스와 인자를 전달하면, 해당 인스턴스에 있는 메서드를 전달받은 인자를 사용해 실행할 수 있다.
• 여기서는 BasicData basicData = new BasicData() 인스턴스에 있는 hello(String) 메서드를 호출한다. 그러니까 아래 메서드.

public String hello(String string) {
    System.out.println("BasicData.hello");
    return string + " hello";
}

여기서 메서드를 찾을 때, basicDataClass.getDeclaredMethod(methodName, String.class) 에서 methodName 부분이 String 변수로 되어 있는 것을 확인할 수 있다. methodName은 변수이므로 예를 들어, 사용자 콘솔 입력을 통해서 얼마든지 호출할 methodName을 변경할 수 있다. 따라서, 여기서 호출할 메서드 대상은 정적으로 딱 코드에 의해 정해진 것이 아니라, 언제든지 동적으로 변경할 수 있다. 그래서 동적 메서드 호출이라 한다. 

메서드 동적 호출 - 예시

package cwchoiit.reflection.data;

public class Calculator {

    public int add(int a, int b) {
        return a + b;
    }

    public int subtract(int a, int b) {
        return a - b;
    }
}

MethodV3

package cwchoiit.reflection;

import cwchoiit.reflection.data.Calculator;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.Scanner;

public class MethodV3 {
    public static void main(String[] args) throws NoSuchMethodException, InvocationTargetException, IllegalAccessException {

        Scanner scanner = new Scanner(System.in);
        System.out.println("호출 메서드: ");
        String methodName = scanner.nextLine();

        System.out.println("숫자1: ");
        int num1 = scanner.nextInt();
        System.out.println("숫자2: ");
        int num2 = scanner.nextInt();

        Calculator calculator = new Calculator();
        Class<? extends Calculator> calculatorClass = calculator.getClass();

        Method method = calculatorClass.getMethod(methodName, int.class, int.class);

        Object returnValue = method.invoke(calculator, num1, num2);
        System.out.println("returnValue = " + returnValue);

    }
}

실행 결과 1

호출 메서드: 
add
숫자1: 
3
숫자2: 
2
returnValue = 5

실행 결과 2

호출 메서드: 
subtract
숫자1: 
2
숫자2: 
4
returnValue = -2

물론, 시그니쳐가 잘못된 경우 에러가 발생하는건 당연하다.

실행 결과 3 - 잘못된 메서드명을 입력

필드 탐색과 값 변경

리플렉션을 활용해서, 필드를 탐색하고 또 필드의 값을 변경하도록 활용해보자.

FieldV1

package cwchoiit.reflection;

import cwchoiit.reflection.data.BasicData;

import java.lang.reflect.Field;

public class FieldV1 {
    public static void main(String[] args) {
        Class<BasicData> basicDataClass = BasicData.class;

        System.out.println("========= fields() =========");
        Field[] fields = basicDataClass.getFields();
        for (Field field : fields) {
            System.out.println("field = " + field);
        }

        System.out.println("========= declaredFields() =========");
        Field[] declaredFields = basicDataClass.getDeclaredFields();
        for (Field declaredField : declaredFields) {
            System.out.println("declaredField = " + declaredField);
        }
    }
}

실행 결과

========= fields() =========
field = public java.lang.String cwchoiit.reflection.data.BasicData.publicField
========= declaredFields() =========
declaredField = public java.lang.String cwchoiit.reflection.data.BasicData.publicField
declaredField = private int cwchoiit.reflection.data.BasicData.privateField

fields() vs declaredFields()

앞서 설명한 getMethods() vs getDeclaredMethods()와 같다. 

• fields(): 해당 클래스와 상위 클래스에서 상속된 모든 public 필드를 반환
• declaredFields(): 해당 클래스에서 선언된 모든 필드를 반환하며, 접근 제어자에 관계없이 반환. 상속된 필드는 포함하지 않음.

필드 값 변경

필드 값 변경 예제를 위해 간단한 사용자 데이터를 만들어보자.

User

package cwchoiit.reflection.data;

public class User {

    private String id;
    private String name;
    private Integer age;

    public User() {
    }

    public User(String id, String name, Integer age) {
        this.id = id;
        this.name = name;
        this.age = age;
    }

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public Integer getAge() {
        return age;
    }

    public void setAge(Integer age) {
        this.age = age;
    }

    @Override
    public String toString() {
        return "User{" +
                "id='" + id + '\'' +
                ", name='" + name + '\'' +
                ", age=" + age +
                '}';
    }
}

• 여기서 모든 필드가 private 접근 제어자라는 점을 주의해서 살펴보자.

FieldV2

package cwchoiit.reflection;

import cwchoiit.reflection.data.User;

import java.lang.reflect.Field;

public class FieldV2 {
    public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException {

        User user = new User("id1", "userA", 20);

        System.out.println("기존 이름 = " + user.getName());

        Class<? extends User> aClass = user.getClass();
        Field nameField = aClass.getDeclaredField("name");

        nameField.set(user, "userB");
        System.out.println("변경된 이름 = " + user.getName());
    }
}

• 사용자의 이름이 userA인데, 리플렉션을 사용해서 name 필드에 직접 접근한 다음에 userB로 이름을 변경해보자.

Field nameField = aClass.getDeclaredField("name");

• name 이라는 필드를 조회한다.
• 그런데, name 필드는 private 접근 제어자를 사용한다. 따라서 직접 접근해서 값을 변경하는 것이 불가능하다.

그런데, 리플렉션은 private 필드에 접근할 수 있는 특별한 기능을 제공한다. 

nameField.setAccessible(true);

• 이렇게 setAccessible(true) 설정해버리면, private 필드에 그냥 접근이 가능해진다. 
• 참고로, 이 setAccessible(true)는, Method도 제공한다. 따라서 private 메서드를 호출할 수도 있다.

// private 필드에 접근 허용, 메서드도 또한 마찬가지
nameField.setAccessible(true);
nameField.set(user, "userB");
System.out.println("변경된 이름 = " + user.getName());

그래서 이렇게 해서 실행해버리면 변경이 가능해진다.

실행 결과

기존 이름 = userA
변경된 이름 = userB

리플렉션과 주의사항

본 것처럼, 리플렉션을 활용하면 private 접근 제어자에도 직접 접근해서 값을 변경할 수 있다. 하지만, 이는 객체 지향 프로그래밍의 원칙을 위반하는 행위로 간주될 수 있다. private 접근 제어자는 클래스 내부에서만 데이터를 보호하고,  외부에서의 직접적인 접근을 방지하기 위해 사용된다. 리플렉션을 통해 이러한 접근 제한을 무시하는 것은 캡슐화 및 유지보수성에 악영향을 미칠 수 있다. 예를 들어, 클래스의 내부 구조나 구현 세부 사항이 변경될 경우 리플렉션을 사용한 코드는 쉽게 깨질수 있으며, 이는 예상치 못한 버그를 초래할 수 있다. 따라서, 리플렉션을 사용할 때는 반드시 신중하게 접근해야 하며, 가능한 경우 접근 메서드(예: Getter, Setter)를 사용하는 것이 바람직하다. 리플렉션은 주로 테스트나 라이브러리 개발 같은 특별한 상황에서 유용하게 사용되지만, 일반적인 애플리케이션 코드에서는 권장되지 않는다. 이를 무분별하게 사용하면 코드의 가독성과 안정성을 크게 저하시킬 수 있다. 

그럼 어떤 경우에 사용하면 좋은걸까?

리플렉션 - 활용 예제

프로젝트에서 데이터를 저장해야 하는데, 저장할 때는 반드시 null을 사용하면 안된다고 가정해보자. 이 경우, null 값을 다른 기본 값으로 모두 변경해야 한다. 

• String이 null이면 ""(빈 문자)로 변경한다.
• Integer가 null이면 0으로 변경한다.

활용 예시를 위해 Team 클래스를 하나 만들자.

Team

package cwchoiit.reflection.data;

public class Team {
    private String id;
    private String name;

    public Team() {
    }

    public Team(String id, String name) {
        this.id = id;
        this.name = name;
    }

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    @Override
    public String toString() {
        return "Team{" +
                "id='" + id + '\'' +
                ", name='" + name + '\'' +
                '}';
    }
}

FieldV3

package cwchoiit.reflection;

import cwchoiit.reflection.data.Team;
import cwchoiit.reflection.data.User;

public class FieldV3 {
    public static void main(String[] args) {
        User user = new User("id1", null, null);
        Team team = new Team("team1", null);

        System.out.println("==== before ====");
        System.out.println("user = " + user);
        System.out.println("team = " + team);

        if (user.getId() == null) {
            user.setId("");
        }

        if (user.getName() == null) {
            user.setName("");
        }

        if (user.getAge() == null) {
            user.setAge(0);
        }

        if (team.getId() == null) {
            team.setId("");
        }

        if (team.getName() == null) {
            team.setName("");
        }

        System.out.println("==== after ====");
        System.out.println("user = " + user);
        System.out.println("team = " + team);
    }
}

실행 결과

==== before ====
user = User{id='id1', name='null', age=null}
team = Team{id='team1', name='null'}
==== after ====
user = User{id='id1', name='', age=0}
team = Team{id='team1', name=''}

• User, Team 객체에 입력된 정보 중에 null 데이터를 모두 기본 값으로 변경해야 한다고 가정해보자.
• String이 null이면 ""(빈 문자)로 변경한다.
• Integer가 null이면 0으로 변경한다. 

이 문제를 해결하려면 위 코드처럼 각각의 객체에 들어있는 데이터를 직접 다 찾아서 값을 입력해야 한다. 만약, User, Team 뿐만 아니라 Order, Cart, Delivery 등등 수 많은 객체에 해당 기능을 적용해야 한다면 매우 많은 번거로운 코드를 작성해야 할 것이다.

이번에는 이 무식한 코드를 리플렉션을 활용해서 깔끔하게 해결해보자.

FieldUtil

package cwchoiit.reflection;

import java.lang.reflect.Field;

public class FieldUtil {

    public static void nullFieldToDefault(Object target) throws IllegalAccessException {
        Class<?> aClass = target.getClass();

        Field[] declaredFields = aClass.getDeclaredFields();
        for (Field declaredField : declaredFields) {
            declaredField.setAccessible(true);
            if (declaredField.get(target) != null) {
                continue;
            }

            if (declaredField.getType() == String.class) {
                declaredField.set(target, "");
            } else if (declaredField.getType() == Integer.class) {
                declaredField.set(target, 0);
            }
        }
    }
}

• 어떤 객체든 받아서 기본 값을 적용하는 유틸리티 클래스를 만들어보자.

이 유틸리티 필드의 값을 조사한 다음에 null이면 기본 값을 적용한다.

• String이 null이면 ""(빈 문자)로 변경한다.
• Integer가 null이면 0으로 변경한다. 

FieldV4

package cwchoiit.reflection;

import cwchoiit.reflection.data.Team;
import cwchoiit.reflection.data.User;

public class FieldV4 {
    public static void main(String[] args) throws IllegalAccessException {

        User user = new User("id1", null, null);
        Team team = new Team("team1", null);

        System.out.println("==== before ====");
        System.out.println("user = " + user);
        System.out.println("team = " + team);

        FieldUtil.nullFieldToDefault(user);
        FieldUtil.nullFieldToDefault(team);
        System.out.println("==== after ====");
        System.out.println("user = " + user);
        System.out.println("team = " + team);
    }
}

실행 결과

==== before ====
user = User{id='id1', name='null', age=null}
team = Team{id='team1', name='null'}
==== after ====
user = User{id='id1', name='', age=0}
team = Team{id='team1', name=''}

리플렉션을 사용한 덕분에 User, Team 뿐만 아니라 Order, Cart, Delivery 등등 수 많은 객체에 매우 편리하게 기본 값을 적용할 수 있게 되었다. 이처럼 리플렉션을 활용하면 기존 코드로 해결하기 어려운 공통 문제를 손쉽게 처리할 수도 있다. 

생성자 탐색과 객체 생성

리플렉션을 활용하면 생성자를 탐색하고, 또 탐색한 생성자를 사용해서 객체를 생성할 수 있다.

생성자 탐색

ConstructV1

package cwchoiit.reflection;

import java.lang.reflect.Constructor;

public class ConstructV1 {
    public static void main(String[] args) throws ClassNotFoundException {
        Class<?> aClass = Class.forName("cwchoiit.reflection.data.BasicData");

        System.out.println("==== constructors() ====");
        Constructor<?>[] constructors = aClass.getConstructors();
        for (Constructor<?> constructor : constructors) {
            System.out.println("constructor = " + constructor);
        }

        System.out.println("==== declaredConstructors() ====");
        Constructor<?>[] declaredConstructors = aClass.getDeclaredConstructors();
        for (Constructor<?> declaredConstructor : declaredConstructors) {
            System.out.println("declaredConstructor = " + declaredConstructor);
        }
    }
}

실행 결과

==== constructors() ====
constructor = public cwchoiit.reflection.data.BasicData()
==== declaredConstructors() ====
declaredConstructor = public cwchoiit.reflection.data.BasicData()
declaredConstructor = private cwchoiit.reflection.data.BasicData(java.lang.String)

생성자 활용

ConstructV2

package cwchoiit.reflection;

import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

public class ConstructV2 {

    public static void main(String[] args) throws ClassNotFoundException, NoSuchMethodException, InvocationTargetException, InstantiationException, IllegalAccessException {

        Class<?> aClass = Class.forName("cwchoiit.reflection.data.BasicData");

        Constructor<?> declaredConstructors = aClass.getDeclaredConstructor(String.class);
        declaredConstructors.setAccessible(true);
        Object instance = declaredConstructors.newInstance("hello");
        System.out.println("instance = " + instance);

        Method method = aClass.getDeclaredMethod("call");
        method.invoke(instance);
    }
}

실행 결과

BasicData.BasicData:hello
instance = cwchoiit.reflection.data.BasicData@b360e9ca
BasicData.call

Class.forName("cwchoiit.reflection.data.BasicData")를 사용해서 클래스 정보를 동적으로 조회했다.

getDeclaredConstructor(String.class): 생성자를 조회한다.

• 여기서는 매개변수로 String을 사용하는 생성자를 조회한다.
• 근데 그 생성자는 private 접근 제어자다! 그럼에도 불구하고 사용할 수가 있다.

declaredConstructors.setAccessible(true)를 사용해서 private 생성자를 접근 가능하게 만들었다.

다시봐도 이 String 매개변수를 가지는 생성자는 private이다.

private BasicData(String data) {
    System.out.println("BasicData.BasicData:" + data);
}

Object instance = declaredConstructors.newInstance("hello");

찾은 생성자를 사용해서 객체를 생성까지 한다. 여기서는 "hello"라는 인자를 넘겨준다.

Method method = aClass.getDeclaredMethod("call");
method.invoke(instance);

앞서 생성한 인스턴스에 call 이라는 이름의 메서드를 동적으로 찾아서 호출한다.

이번 예제를 잘 보면, 클래스를 동적으로 찾아서 인스턴스를 생성하고, 메서드도 동적으로 호출했다. 코드 어디에도 BasicData의 타입이나 call() 메서드를 직접 호출하는 부분을 코딩하지 않았다. 클래스를 찾고 생성하는 방법도, 그리고 생성한 클래스의 메서드를 호출하는 방법도 모두 동적으로 처리한 것이다. 

참고로, 스프링 프레임워크나 다른 프레임워크 기술들을 사용해보면, 내가 만든 클래스를 프레임워크가 대신 생성해줄 때가 있다. 그때가 되면 방금 학습한 리플렉션과 동적 객체 생성 방법들이 떠오를 것이다.

HTTP 서버6 - 리플렉션 서블릿

이전 포스팅에서 커맨드 패턴으로 만든 서블릿은 아주 유용하지만, 몇가지 단점이 있다.

• 하나의 클래스에 하나의 기능만 만들 수 있다.
• 새로 만든 클래스를 URL 경로와 항상 매핑해야 한다.

이제 리플렉션의 기본 기능을 학습했으니, 처음에 설명한 리플렉션을 활용한 서블릿 기능을 만들어보자. 개발자는 다음과 같이 간단한 기능만 만들면 된다.

  public class ReflectController {
      public void site1(HttpRequest request, HttpResponse response) {
          response.writeBody("<h1>site1</h1>");
      }
      public void site2(HttpRequest request, HttpResponse response) {
          response.writeBody("<h1>site2</h1>");
      }
      public void search(HttpRequest request, HttpResponse response) {
          String query = request.getParameter("q");
          response.writeBody("<h1>Search</h1>");
          response.writeBody("<ul>");
          response.writeBody("<li>query: " + query + "</li>");
          response.writeBody("</ul>");
      } 
}

• 개발자는 이런 Xxx컨트롤러라는 기능만 개발하면 된다.
• 이러한 컨트롤러의 메서드를 리플렉션으로 읽고 호출할 것이다.

참고로, 컨트롤러라는 용어는, 애플리케이션의 제어 흐름을 제어(control)한다. 요청을 받아 적절한 비즈니스 로직을 호출하고, 그 결과를 뷰에 전달하는 등의 작업을 수행한다.

URL 경로의 이름과 메서드의 이름이 같다.

• /site1 → site1()
• /site2 → site2()
• /search → search()

리플렉션을 활용하면 메서드 이름을 알 수 있다. 예를 들어, /site1이 입력되면, site1() 이라는 메서드를 이름으로 찾아서 호출하는 것이다. 이렇게 하면 번거로운 매핑 작업을 제거할 수 있다. 

물론 필요하면 서로 관련된 기능은 하나의 클래스로 모으도록, 클래스를 나눌 수 있게 해도 된다. 

• SiteController
  • site1()
  • site2()
• SearchController
  • search()

리플렉션을 처리하는 서블릿 구현

앞서 설명했듯, 서블릿은 자바 진영에서 이미 표준으로 사용하는 기술이다. 따라서 서블릿은 그대로 사용하면서 새로운 기능을 구현해보자. 앞서 만든 HTTP 서버에서 was.httpserver 패키지는 다른 곳에서 제공하는 변경할 수 없는 라이브러리라고 가정하자. 우리는 was.httpserver의 코드를 전혀 변경하지 않고 그대로 재사용하면서 기능을 추가하겠다. 

v5 코드

• HTTP 서버와 관련된 부분 - was.httpserver 패키지
  • HttpServer, HttpRequestHandler, HttpRequest, HttpResponse
  • HttpServlet, HttpServletManager
  • InternalErrorServlet, NotFoundServlet (was.httpserver.servlet 패키지)
• 서비스 개발을 위한 로직 - v5.servlet 패키지
  • HomeServlet
  • Site1Servlet
  • Site2Servlet
  • SearchServlet

컨트롤러

SearchControllerV6

package cwchoiit.was.v6;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;

public class SearchControllerV6 {

    public void search(HttpRequest request, HttpResponse response) {
        String query = request.getParameter("q");

        response.writeBody("<h1>Search</h1>");
        response.writeBody("<ul>");
        response.writeBody("<li>query = " + query + "</li>");
        response.writeBody("</ul>");
    }
}

• `/search`를 처리한다.

SiteControllerV6

package cwchoiit.was.v6;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;

public class SiteControllerV6 {

    public void site1(HttpRequest request, HttpResponse response) {
        response.writeBody("<h1>Site1</h1>");
    }

    public void site2(HttpRequest request, HttpResponse response) {
        response.writeBody("<h1>Site2</h1>");
    }
}

• `/site1`, `/site2`를 처리한다.

참고로, XxxController에서 호출 대상이 되는 메서드는 반드시 HttpRequest, HttpResponse를 인자로 받아야 한다. 이 부분은 뒤에서 설명한다. 기존 코드에서 이런 컨트롤러들을 어떻게 호출하도록 만들 수 있을까? 

리플렉션 서블릿

ReflectionServlet

package cwchoiit.was.httpserver.servlet.reflection;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.HttpServlet;
import cwchoiit.was.httpserver.PageNotFoundException;

import java.io.IOException;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.List;

public class ReflectionServlet implements HttpServlet {

    private final List<Object> controllers;

    public ReflectionServlet(List<Object> controllers) {
        this.controllers = controllers;
    }

    @Override
    public void service(HttpRequest request, HttpResponse response) throws IOException {
        String path = request.getPath();

        for (Object controller : controllers) {
            Class<?> aClass = controller.getClass();
            Method[] methods = aClass.getDeclaredMethods();

            for (Method method : methods) {
                String name = method.getName();
                if (path.equals("/" + name)) {
                    invoke(request, response, controller, method);
                    return;
                }
            }
        }
        throw new PageNotFoundException("path = " + path);
    }

    private void invoke(HttpRequest request, HttpResponse response, Object controller, Method method) {
        try {
            method.invoke(controller, request, response);
        } catch (IllegalAccessException | InvocationTargetException e) {
            throw new RuntimeException(e);
        }
    }
}

• was.httpserver.servlet.reflection 패키지 위치를 주의하자. 다른 프로젝트에서도 필요하면 사용할 수 있다.
• List<Object> controllers: 생성자를 통해 여러 컨트롤러들을 보관할 수 있다.

이 서블릿은 요청이 오면 모든 컨트롤러를 순회한다. 그리고 선언된 메서드 정보를 통해, URL의 요청 경로와 메서드 이름이 맞는지 확인한다. 만약, 메서드 이름이 맞다면 invoke()를 통해 해당 메서드를 동적으로 호출한다. 이때, HttpRequest, HttpResponse 정보도 함께 넘겨준다. 따라서 대상 메서드는 반드시 HttpRequest, HttpResponse를 인자로 받아야 한다. 

이미 앞서 리플렉션에서 학습한 내용들이라 이해하기 어렵지는 않을 것이다.

ServerMainV6

package cwchoiit.was.v6;

import cwchoiit.was.httpserver.HttpServer;
import cwchoiit.was.httpserver.ServletManager;
import cwchoiit.was.httpserver.servlet.DiscardServlet;
import cwchoiit.was.httpserver.servlet.reflection.ReflectionServlet;
import cwchoiit.was.v5.servlet.HomeServlet;

import java.io.IOException;
import java.util.List;

public class ServerMainV6 {

    private static final int PORT = 12345;

    public static void main(String[] args) throws IOException {
        List<Object> controllers = List.of(new SiteControllerV6(), new SearchControllerV6());

        ReflectionServlet reflectionServlet = new ReflectionServlet(controllers);

        ServletManager servletManager = new ServletManager();
        servletManager.setDefaultServlet(reflectionServlet);

        servletManager.add("/", new HomeServlet());
        servletManager.add("/favicon.ico", new DiscardServlet());

        new HttpServer(PORT, servletManager).start();
    }
}

실행 결과

• 실행 결과는 기존과 같다.

• 만든 컨트롤러(SiteController, SearchController)들을 리스트로 담고, ReflectionServlet의 생성자로 넘겨준다.
• ServletManager의 defaultServlet을 위에서 만든 ReflectionServlet으로 지정한다. 이 부분이 중요하다. 리플렉션 서블릿을 기본 서블릿으로 등록하는 것이다. 이렇게 되면 다른 서블릿에서 경로를 찾지 못할 때 우리가 만든 리플렉션 서블릿이 항상 호출된다. 그리고 다른 서블릿은 등록하지 않는다. 따라서 항상 리플렉션 서블릿이 호출된다. 
  
  • 아쉽게도 HomeServlet을 처리하는 `/` 경로와 `/favicon.ico` 경로를 처리하는 DiscardServlet()은 등록해줘야 한다. 이 두 경로는 메서드명을 `/()`로 할 수 없고 `favicon.ico()` 이렇게 못만드니까.

기존에는 어떻게 서블릿을 URL 매핑을 했나? 바로 이렇게 했다.

servletManager.add("/", new HomeServlet());
servletManager.add("/site1", new Site1Servlet());
servletManager.add("/site2", new Site2Servlet());
servletManager.add("/search", new SearchServlet());
servletManager.add("/favicon.ico", new DiscardServlet());

이렇게 각 URL 별로 서블릿 하나씩을 다 만들어서 ServletManager에 등록하고 이 ServletManager가 아래 메서드를 호출하면서, 서블릿을 실행했다.

public void execute(HttpRequest request, HttpResponse response) throws IOException {
    try {

        HttpServlet servlet = servletMap.getOrDefault(request.getPath(), defaultServlet);
        if (servlet == null) {
            throw new PageNotFoundException("Page not found: " + request.getPath());
        }

        servlet.service(request, response);

    } catch (PageNotFoundException e) {
        e.printStackTrace();
        notFoundErrorServlet.service(request, response);
    } catch (Exception e) {
        e.printStackTrace();
        internalErrorServlet.service(request, response);
    }
}

그런데, 여기서 이제는 defaultServlet을 제외하고 아무런 서블릿도 등록하지 않았으니 저 ReflectionServlet만 실행되도록 한 것이다.

정리

기존 HTTP 서버의 코드를 전혀 변경하지 않고, 서블릿만 잘 구현해서 완전히 새로운 기능을 도입했다. 덕분에 앞서 커맨드 패턴으로 만든 서블릿의 단점을 해결할 수 있었다. 이렇게 리플렉션을 활용해서, 요청 URL과 동일한 메서드명을 통해 서블릿을 호출할 수 있게 된다.

남은 문제점

• 리플렉션 서블릿은 요청 URL과 메서드 이름이 같다면 해당 메서드를 동적으로 호출할 수 있다. 하지만 요청 이름과 메서드 이름을 다르게 하고 싶다면 어떻게 해야할까?
• 예를 들어, `/site1` 이라고 와도 page1()과 같은 다른 이름의 메서드를 호출하고 싶다면 어떻게 해야 할까? 예를 들어서 메서드 이름은 더 자세히 적고 싶을 수도 있잖아? 
• 또한, 홈 경로인 `/`와, `/favicon.ico`와 같은 아이콘 처리 경로는 자바 메서드 이름으로 처리할 수 없었다. 이건 어떻게 해결 할까?
• URL은 주로 `-`를 사용해서 문장을 이어간다. 예를 들면 `/add-member` 이렇게 말이다. 이런 URL은 어떻게 해결 할까?

이 문제들을 해결하는 방법은 애노테이션을 사용하는 것이다! 다음 포스팅은 애노테이션이다.

참고자료

HTTP 서버1 - 시작

HTTP 서버를 직접 만들어보자. 웹 브라우저에서 우리 서버에 접속하면, 다음과 같은 HTML을 응답하는 것이다.

<h1>Hello World</h1>

그러면 웹 브라우저가 "Hello World"를 크게 보여줄 것이다.

참고로, HTML은 <html>, <head>, <body>와 같은 기본 태그를 가진다. 원래는 이런 태그도 함께 포함해서 전달해야 하지만, 예제를 단순하게 만들기 위해 최소한의 태그만 사용하겠다.

HttpServerV1

package cwchoiit.was.v1;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.ServerSocket;
import java.net.Socket;

import static cwchoiit.util.MyLogger.log;
import static java.nio.charset.StandardCharsets.*;

public class HttpServerV1 {

    private final int port;

    public HttpServerV1(int port) {
        this.port = port;
    }

    public void start() throws IOException {
        ServerSocket serverSocket = new ServerSocket(port);
        log("서버 시작 port: " + port);

        while (true) {
            Socket socket = serverSocket.accept();
            process(socket);
        }
    }

    private void process(Socket socket) throws IOException {
        try (socket;
             BufferedReader reader = new BufferedReader(new InputStreamReader(socket.getInputStream(), UTF_8));
             PrintWriter writer = new PrintWriter(socket.getOutputStream(), false, UTF_8)) {

            String requestString = requestToString(reader);

            if (requestString.contains("/favicon.ico")) {
                log("favicon 요청");
                return;
            }

            log("HTTP 요청 정보 출력:");
            System.out.println(requestString);

            log("HTTP 응답 생성 중...");
            sleep(5000);
            responseToClient(writer);
        }
    }

    private static void sleep(int millis) {
        try {
            Thread.sleep(millis);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
    }

    private void responseToClient(PrintWriter writer) {
        String body = "<h1>Hello World</h1>";
        int length = body.getBytes(UTF_8).length;

        StringBuilder sb = new StringBuilder();
        sb.append("HTTP/1.1 200 OK\r\n");
        sb.append("Content-Type: text/html\r\n");
        sb.append("Content-Length: ").append(length).append("\r\n");
        sb.append("\r\n");
        sb.append(body);

        log("HTTP 응답 정보 출력");
        System.out.println(sb);

        writer.println(sb);
        writer.flush();
    }

    private String requestToString(BufferedReader reader) throws IOException {
        StringBuilder sb = new StringBuilder();
        String line;
        while ((line = reader.readLine()) != null) {
            if (line.isEmpty()) {
                break;
            }
            sb.append(line).append("\n");
        }

        return sb.toString();
    }
}

• HTTP 메시지의 주요 내용들은 문자로 읽고 쓰게 된다.
• 따라서, 여기서는 BufferedReader, PrintWriter를 사용했다.
• Stream을 Reader, Writer로 변경할 때는 항상 인코딩을 확인하자.

AutoFlush

• new PrintWriter(socket.getOutputStream(), false, UTF_8)
• PrintWriter의 두번째 인자는 autoFlush 여부이다.
• 이 값을 true로 설정하면 println()으로 출력할 때마다 자동으로 플러시된다.
• 그러면 첫 내용을 빠르게 전송할 수 있지만, 네트워크 전송이 자주 발생된다.
• 이 값을 false로 설정하면, flush()를 직접 호출해주어야 데이터를 전송한다.
• 데이터를 모아서 전송하므로, 네트워크 전송 횟수를 효과적으로 줄일 수 있다. 한 패킷에 많은 양의 데이터를 담아서 전송할 수 있다.
• 여기서는 false로 설정했으므로, 마지막에 꼭 writer.flush()를 호출해야 한다.

requestToString()

• HTTP 요청을 읽어서 String으로 반환한다.
• HTTP 요청의 시작 라인, 헤더까지 읽는다.
• line.isEmpty()이면, HTTP 메시지 헤더의 마지막으로 인식하고 메시지 읽기를 종료한다.
• HTTP 메시지 헤더의 끝은 빈 라인으로 구분할 수 있다. 빈 라인 이후에는 메시지 바디가 나온다.
• 참고로 여기서는 메시지 바디를 전달하지 않으므로, 메시지 바디의 정보는 읽지 않는다.

/favicon.ico

• 웹 브라우저에서 해당 사이트의 작은 아이콘을 추가로 요청할 수 있다. 여기서는 사용하지 않으므로 무시한다.

sleep(5000); // 서버 처리 시간

• 예제가 단순해서 응답이 너무 빠르다. 서버에서 요청을 처리하는데 약 5초의 시간이 걸린다고 가정하는 코드이다.

responseToClient()

• HTTP 응답 메시지를 생성해서 클라이언트에 전달한다.
• 시작라인, 헤더, HTTP 메시지 바디를 전달한다.
• HTTP 공식 스펙에서 다음 라인은 \r\n(캐리지 리턴 + 라인 피드)로 표현한다. 참고로 \n만 사용해도 대부분의 웹 브라우저는 문제없이 작동한다. (캐리지 리턴은 커서가 현재 문장에 가장 앞으로 가는 이스케이프 문자)
• 마지막에 writer.flush()를 호출해서 데이터를 전송한다.

ServerMain

package cwchoiit.was.v1;

import java.io.IOException;

public class ServerMain {

    private static final int PORT = 12345;

    public static void main(String[] args) throws IOException {
        HttpServerV1 server = new HttpServerV1(PORT);
        server.start();
    }
}

• 웹 브라우저를 실행하고 다음 사이트에 접속해보자. 5초간 기다려야 한다. 
  • http://localhost:12345 
  • http://127.0.0.1:12345

이러한 문장이 5초 뒤에 딱 나왔다.

실행 결과

17:57:48.634 [     main] 서버 시작 port: 12345
17:57:57.123 [     main] HTTP 요청 정보 출력:
GET / HTTP/1.1
Host: localhost:12345
Connection: keep-alive
sec-ch-ua: "Brave";v="129", "Not=A?Brand";v="8", "Chromium";v="129"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "macOS"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8
Sec-GPC: 1
Accept-Language: en-US,en
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br, zstd
Cookie: sr-selectedScriptRoot=/Users/choichiwon/Atlassian/scriptrunner-skeleton/jira/target/jira/home/scripts; screenResolution=2560x1440; wordpress_test_cookie=WP%20Cookie%20check; wp-settings-time-1=1723983516

17:57:57.124 [     main] HTTP 응답 생성 중...
17:58:02.127 [     main] HTTP 응답 정보 출력
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 20

<h1>Hello World</h1>
17:58:02.185 [     main] favicon 요청

요청 부분

HTTP 요청 메시지

GET / HTTP/1.1
Host: localhost:12345
Connection: keep-alive
sec-ch-ua: "Brave";v="129", "Not=A?Brand";v="8", "Chromium";v="129"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "macOS"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8
Sec-GPC: 1
Accept-Language: en-US,en
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br, zstd
Cookie: sr-selectedScriptRoot=/Users/choichiwon/Atlassian/scriptrunner-skeleton/jira/target/jira/home/scripts; screenResolution=2560x1440; wordpress_test_cookie=WP%20Cookie%20check; wp-settings-time-1=1723983516

• http://localhost:12345를 요청하면, 웹 브라우저가 HTTP 요청 메시지를 만들어서 서버에 전달한다.

시작 라인

• GET: GET 메서드
• /: 요청 경로, 별도의 요청 경로가 없으면 /를 사용한다.
• HTTP/1.1: HTTP 버전

헤더

• Host: 접속하는 서버 정보
• User-Agent: 웹 브라우저의 정보
• Accept: 웹 브라우저가 전달 받을 수 있는 HTTP 응답 메시지 바디 형태
• Accept-Encoding: 웹 브라우저가 전달 받을 수 있는 인코딩 형태
• Accept-Language: 웹 브라우저가 전달 받을 수 있는 언어 형태

응답 부분

HTTP 응답 메시지

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 20

<h1>Hello World</h1>

시작 라인

• HTTP/1.1: HTTP 버전
• 200: HTTP 상태 코드(성공)
• OK: 200에 대한 설명

헤더

• Content-Type: HTTP 메시지 바디의 데이터 형태, 여기서는 HTML을 사용
• Content-Length: HTTP 메시지 바디의 데이터 길이

바디

<h1>Hello World</h1>

솔직히, 신기하다. 스프링으로만 웹 서버를 개발하느라 단 한번도 이렇게 서버를 띄워본 적이 없었는데.. 이런 기조가 깔려있었구나.

지금 우리 서버의 문제는..

서버는 동시에 수 많은 사용자의 요청을 처리할 수 있어야 한다. 현재 서버는 한 번에 하나의 요청만 처리할 수 있다는 문제가 있다. 다른 웹 브라우저를 2개를 동시에 열어서 사이트를 실행해보자. 첫번째 요청이 모두 처리되고 나서 두번째 요청이 처리되는것을 알 수 있다. 당연히 코드 상에 이렇게 되어 있으니까.

while (true) {
    Socket socket = serverSocket.accept();
    process(socket);
}

• accept()는 웹 브라우저에서 요청이 들어오면 그때 소켓을 반환하고 process(socket)을 실행한다. 이 상태에서 아무리 요청을 해도 process(socket)이 끝나야 다시 accept()로 돌아갈 수 있다.

HTTP 서버2 - 동시 요청

스레드를 사용해서 동시에 여러 요청을 처리할 수 있도록 서버를 개선해보자.

HttpRequestHandler

package cwchoiit.was;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.Socket;

import static cwchoiit.util.MyLogger.log;
import static java.nio.charset.StandardCharsets.UTF_8;

public class HttpRequestHandler implements Runnable {

    private final Socket socket;

    public HttpRequestHandler(Socket socket) throws IOException {
        this.socket = socket;
    }

    @Override
    public void run() {
        try (socket;
             BufferedReader reader = new BufferedReader(new InputStreamReader(socket.getInputStream(), UTF_8));
             PrintWriter writer = new PrintWriter(socket.getOutputStream(), false, UTF_8)) {

            String requestString = requestToString(reader);
            if (requestString.contains("/favicon.ico")) {
                log("favicon 요청");
                return;
            }

            log("HTTP 요청 정보 출력:");
            System.out.println(requestString);

            log("HTTP 응답 생성 중...");
            sleep(5000);
            responseToClient(writer);
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }

    private void sleep(int millis) {
        try {
            Thread.sleep(millis);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
    }

    private void responseToClient(PrintWriter writer) {
        String body = "<h1>Hello World</h1>";
        int length = body.getBytes(UTF_8).length;

        StringBuilder sb = new StringBuilder();
        sb.append("HTTP/1.1 200 OK\r\n");
        sb.append("Content-Type: text/html\r\n");
        sb.append("Content-Length: ").append(length).append("\r\n");
        sb.append("\r\n");
        sb.append(body);

        log("HTTP 응답 정보 출력");
        System.out.println(sb);

        writer.println(sb);
        writer.flush();
    }

    private String requestToString(BufferedReader reader) throws IOException {
        StringBuilder sb = new StringBuilder();
        String line;
        while ((line = reader.readLine()) != null) {
            if (line.isEmpty()) {
                break;
            }
            sb.append(line).append("\n");
        }

        return sb.toString();
    }
}

• 클라이언트의 HttpRequestHandler는 이름 그대로 클라이언트가 전달한 HTTP 요청을 처리한다.
• 동시에 요청한 수만큼 별도의 스레드에서 HttpRequestHandler가 수행된다.

HttpServerV2

package cwchoiit.was.v2;

import cwchoiit.was.HttpRequestHandler;

import java.io.IOException;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

import static cwchoiit.util.MyLogger.log;

public class HttpServerV2 {
    private final ExecutorService es = Executors.newFixedThreadPool(10);
    private final int port;

    public HttpServerV2(int port) {
        this.port = port;
    }

    public void start() throws IOException {
        ServerSocket serverSocket = new ServerSocket(port);
        log("Starting HttpServerV2 server on port " + port);

        while (true) {
            Socket socket = serverSocket.accept();
            es.submit(new HttpRequestHandler(socket));
        }
    }
}

• ExecutorService: 스레드 풀을 사용한다. 여기서는 newFixedThreadPool(10)을 사용해서 최대 동시에 10개의 스레드를 사용할 수 있도록 했다. 결과적으로 10개의 요청을 동시에 처리할 수 있는것이다.
• 참고로 실무에서는 상황에 따라 다르겠지만, 보통 수백개 정도의 스레드를 사용한다.
• es.submit(new HttpRequestHandler(socket)): 스레드 풀에 HttpRequestHandler 작업을 요청한다.
• 스레드 풀에 있는 스레드가 HttpRequestHandler의 run()을 수행한다. 

HttpServerMainV2

package cwchoiit.was.v2;

import java.io.IOException;

public class HttpServerMainV2 {

    private static final int PORT = 12345;

    public static void main(String[] args) throws IOException {
        new HttpServerV2(PORT).start();
    }
}

HTTP 서버3 - 기능 추가

HTTP 서버가 어떻게 작동하는지 이해했다면, 이제 기능을 추가해보자.

HTTP 서버들은 URL 경로를 사용해서 각각의 기능을 제공한다. 이제 URL에 따른 다양한 기능을 제공해보자.

다음 사진은 `http://localhost:12345`로 진입했을 때 보여지는 화면이다.

• home: `/` 첫 화면
• site1: `/site1` 페이지 화면1
• site2: `/site2` 페이지 화면2
• search: `/search` 기능 검색 화면, 클라이언트에서 서버로 검색어를 전달할 수 있다.
• notFound: 잘못된 URL을 호출했을 때 전달하는 화면

HttpRequestHandlerV3 

package cwchoiit.was.v3;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.Socket;
import java.net.URLDecoder;
import java.nio.charset.StandardCharsets;

import static cwchoiit.util.MyLogger.log;
import static java.nio.charset.StandardCharsets.UTF_8;

public class HttpRequestHandlerV3 implements Runnable {

    private final Socket socket;

    public HttpRequestHandlerV3(Socket socket) throws IOException {
        this.socket = socket;
    }

    @Override
    public void run() {
        try (socket;
             BufferedReader reader = new BufferedReader(new InputStreamReader(socket.getInputStream(), UTF_8));
             PrintWriter writer = new PrintWriter(socket.getOutputStream(), false, UTF_8)) {

            String requestString = requestToString(reader);
            if (requestString.contains("/favicon.ico")) {
                log("favicon 요청");
                return;
            }

            log("HTTP 요청 정보 출력:");
            System.out.println(requestString);

            log("HTTP 응답 생성 중...");
            if (requestString.startsWith("GET /site1")) {
                site1(writer);
            } else if (requestString.startsWith("GET /site2")) {
                site2(writer);
            } else if (requestString.startsWith("GET /search")) {
                search(writer, requestString);
            } else if (requestString.startsWith("GET / ")) {
                home(writer);
            } else {
                notFound(writer);
            }
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }

    private void site1(PrintWriter writer) {
        writer.println("HTTP/1.1 200 OK");
        writer.println("Content-Type: text/html; charset=UTF-8");
        writer.println();

        writer.println("<h1>Site1</h1>");
        writer.flush();
    }

    private void site2(PrintWriter writer) {
        writer.println("HTTP/1.1 200 OK");
        writer.println("Content-Type: text/html; charset=UTF-8");
        writer.println();

        writer.println("<h1>Site2</h1>");
        writer.flush();
    }

    private void search(PrintWriter writer, String requestString) {
        int startIndex = requestString.indexOf("q=");
        int endIndex = requestString.indexOf(" ", startIndex + 2);

        String query = requestString.substring(startIndex + 2, endIndex);

        String decode = URLDecoder.decode(query, UTF_8);

        writer.println("HTTP/1.1 200 OK");
        writer.println("Content-Type: text/html; charset=UTF-8");
        writer.println();

        writer.println("<h1>Search</h1>");
        writer.println("<ul>");
        writer.println("<li>query = " + query + "</li>");
        writer.println("<li>decode = " + decode + "</li>");
        writer.println("</ul>");
        writer.flush();
    }

    private void home(PrintWriter writer) {
        writer.println("HTTP/1.1 200 OK");
        writer.println("Content-Type: text/html; charset=UTF-8");
        writer.println();

        writer.println("<h1>Home</h1>");
        writer.println("<ul>");
        writer.println("<li><a href='/site1'>site1</a></li>");
        writer.println("<li><a href='/site2'>site2</a></li>");
        writer.println("<li><a href='/search?q=hello'>search</a></li>");
        writer.println("</ul>");

        writer.flush();
    }

    private void notFound(PrintWriter writer) {
        writer.println("HTTP/1.1 404 Not Found");
        writer.println("Content-Type: text/html; charset=UTF-8");
        writer.println();

        writer.println("<h1>404 페이지를 찾을 수 없습니다.</h1>");
        writer.flush();
    }

    private String requestToString(BufferedReader reader) throws IOException {
        StringBuilder sb = new StringBuilder();
        String line;
        while ((line = reader.readLine()) != null) {
            if (line.isEmpty()) {
                break;
            }
            sb.append(line).append("\n");
        }

        return sb.toString();
    }
}

• HTTP 요청 메시지의 시작 라인을 파싱하고, 요청 URL에 맞추어 응답을 전달한다.
  • GET / → home() 호출
  • GET /site1 → site1() 호출
• 응답 시 원칙적으로 헤더에 메시지 바디의 크기를 계산해서 Content-Length를 전달해야 하지만, 예제를 단순화하기 위해 생략했다.

검색 시 다음과 같은 형식으로 요청이 온다.

• GET /search?q=hello
• URL에서 `?` 이후의 부분에 key1=value1&key2=value2 포맷으로 서버에 데이터를 전달할 수 있다.
• 이 부분을 파싱하면 요청하는 검색어를 알 수 있다.
• 예제에서는 실제로 검색을 하는 것은 아니고, 요청하는 검색어를 간단히 출력한다.
• URLDecoder는 바로 뒤에서 설명한다.

HttpServerV3

package cwchoiit.was.v3;

import java.io.IOException;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

import static cwchoiit.util.MyLogger.log;

public class HttpServerV3 {
    private final ExecutorService es = Executors.newFixedThreadPool(10);
    private final int port;

    public HttpServerV3(int port) {
        this.port = port;
    }

    public void start() throws IOException {
        ServerSocket serverSocket = new ServerSocket(port);
        log("Starting HttpServerV2 server on port " + port);

        while (true) {
            Socket socket = serverSocket.accept();
            es.submit(new HttpRequestHandlerV3(socket));
        }
    }
}

HttpServerMainV3

package cwchoiit.was.v3;

import java.io.IOException;

public class HttpServerMainV3 {

    private static final int PORT = 12345;

    public static void main(String[] args) throws IOException {
        new HttpServerV3(PORT).start();
    }
}

실행 결과

그럼 뒤에서 설명하겠다고 한 URLDecoder를 알아보자.

URL 인코딩

URL은 ASCII 문자집합을 사용한다.

URL이 ASCII를 사용하는 이유?

HTTP 메시지에서 시작 라인(URL을 포함)과 HTTP 헤더의 이름은 항상 ASCII를 사용해야 한다. HTTP 메시지 바디는 UTF-8과 같은 다른 인코딩을 사용할 수 있다. 지금처럼 UTF-8이 표준화된 시대에 왜 URL은 ASCII만 사용할 수 있을까? 

• 인터넷이 처음 설계되던 시기(1980 - 1990년대)에 대부분의 컴퓨터 시스템은 ASCII 문자 집합을 사용했다. 
• 전 세계에서 사용하는 다양한 컴퓨터 시스템과 네트워크 장비 간의 호환성을 보장하기 위해, URL은 단일한 문자 인코딩 체계를 사용해야 했다. 그 당시 모든 시스템이 비 ASCII 문자를 처리할 수 없었기 때문에, ASCII는 가장 보편적이고 일관된 선택이었다.
• HTTP URL이 ASCII만을 지원하는 이유는 초기 인터넷의 기술적 제약과 전 세계적인 호환성을 유지하기 위한 선택이다.
• 순수한 UTF-8로 URL을 표현하려면, 전 세계 모든 네트워크 장비, 서버, 클라이언트 소프트웨어가 이를 지원해야 한다. 그러나, 여전히 많은 시스템에서 ASCII 기반 표준에 의존하고 있기 때문에 순수한 UTF-8 URL을 사용하면 호환성 문제가 발생할 수 있다. 
• HTTP 스펙은 매우 보수적이고, 호환성을 가장 우선시한다.

그렇다면 검색어로 사용하는 `/search?q=hello`를 사용할 때 `q=가나다` 같이 URL에 한글을 전달하려면 어떻게 해야할까?

우선 웹 브라우저 URL 입력창에 다음 내용을 입력해보자.

`http://localhost:12345/search?q=가나다`

Search
• query: %EA%B0%80%EB%82%98%EB%8B%A4
• decode: 가나다

퍼센트(%) 인코딩

한글을 UTF-8 인코딩으로 표현하려면 한 글자에 3byte의 데이터를 사용한다. 가, 나, 다를 UTF-8 인코딩의 16진수로 표현하면 다음과 같다. 

• 가: EA, B0, 80 (3byte)
• 나: EB, 82, 98 (3byte)
• 다: EB, 8B, A4 (3byte)

참고로, 2진수는 (0, 1), 10진수는 (0-9), 16진수는(0-9, A, B, C, D, E, F) 로 표현한다.

URL은 ASCII 문자만 표현할 수 있으므로, UTF-8 문자를 표현할 수 없다. 그래서 한글 '가'를 예로 들면, '가'를 UTF-8의 16진수로 표현한 각각의 바이트 문자 앞에 %(퍼센트)를 붙이는 것이다. 

• q=가
• q=%EA%B0%80

이렇게 하면 약간 억지스럽긴 하지만, ASCII 문자를 사용해서 16진수로 표현된 UTF-8을 표현할 수 있다. 그리고 %EA%B0%80은 모두 ASCII에 포함되는 문자이다. 이렇게 각각의 16진수 byte를 문자로 표현하고, 해당 문자 앞에 %를 붙이는 것을 퍼센트(%) 인코딩이라고 한다. 

% 인코딩 후에 클라이언트에서 서버로 데이터를 전달하면, 서버는 각각의 %를 제거하고 EA, B0, 80이라는 각 문자를 얻는다. 그리고 이렇게 얻은 3개의 byte를 모아서 UTF-8로 디코딩하면 "가"라는 글자를 얻을 수 있다.

% 인코딩, 디코딩 진행 과정

1. 클라이언트: '가' 전송 희망
2. 클라이언트 % 인코딩: %EA%B0%80
   1. '가'를 UTF-8로 인코딩
   2. 'EA', 'B0', '80' (3byte) 획득
   3. 각 byte를 16진수 문자로 표현하고 각각의 앞에 %를 붙임
3. 클라이언트 → 서버 전송 q=%EA%B0%80
4. 서버: %EA%B0%80 ASCII 문자를 전달 받음
   1. %가 붙은 경우 디코딩해야 하는 문자로 인식
   2. EA, B0, 80을 byte로 변환, 3byte 획득
   3. EA, B0, 80을 UTF-8로 디코딩 → 문자 '가' 획득

자바가 제공하는 % 인코딩

자바가 제공하는 URLEncoder.encode(), URLDecoder.decode()를 사용하면, % 인코딩, 디코딩을 처리할 수 있다.

PercentEncodingMain

package cwchoiit.was.v3;

import java.net.URLDecoder;
import java.net.URLEncoder;
import java.nio.charset.StandardCharsets;

public class PercentEncodingMain {
    public static void main(String[] args) {

        String encode = URLEncoder.encode("가", StandardCharsets.UTF_8);
        System.out.println("encode = " + encode);

        String decode = URLDecoder.decode(encode, StandardCharsets.UTF_8);
        System.out.println("decode = " + decode);
    }
}

실행 결과

encode = %EA%B0%80
decode = 가

% 인코딩 정리

• % 인코딩은 데이터 크기에서 보면 효율이 떨어진다. 문자 '가'는 단지 3byte만 필요하다. 그런데 % 인코딩을 사용하면 %EA%B0%80 무려 9byte가 사용된다. 
• 그럼에도 불구하고, HTTP는 매우 보수적이다. 호환성을 최우선으로 한다. 그렇기에 이 방식을 여전히 사용중이다.

HTTP 서버4 - 요청, 응답

HTTP 요청 메시지와 응답 메시지는 각각 정해진 규칙이 있다.

• GET, POST 같은 메서드
• URL
• 헤더
• HTTP 버전, Content-Type, Content-Length

HTTP 요청 매시지와 응답 메시지는 규칙이 있으므로, 각 규칙에 맞추어 객체로 만들면, 단순히 String 문자로 다루는 것보다 훨씬 더 구조적이고 객체지향적인 편리한 코드를 만들 수 있다. HTTP 요청 메시지와 응답 메시지를 객체로 만들고, 이전에 작성한 코드도 리팩토링 해보자.

HttpRequest (HTTP 요청 메시지)

package cwchoiit.was.httpserver;

import java.io.BufferedReader;
import java.io.IOException;
import java.net.URLDecoder;
import java.util.HashMap;
import java.util.Map;

import static cwchoiit.util.MyLogger.log;
import static java.nio.charset.StandardCharsets.UTF_8;

public class HttpRequest {

    private String method;
    private String path;

    private final Map<String, String> queryParameters = new HashMap<>();
    private final Map<String, String> headers = new HashMap<>();

    public HttpRequest(BufferedReader reader) throws IOException {
        parseRequestLine(reader);
        parseHeaders(reader);
        parseBody(reader);
    }

    // GET /search?q=hello HTTP/1.1
    private void parseRequestLine(BufferedReader reader) throws IOException {
        String requestLine = reader.readLine();
        if (requestLine == null) {
            throw new IOException("EOF: No request line received");
        }
        String[] parts = requestLine.split(" ");
        if (parts.length != 3) {
            throw new IOException("Invalid request line format: " + requestLine);
        }

        method = parts[0].toUpperCase();
        String[] pathParts = parts[1].split("\\?");
        path = pathParts[0];

        if (pathParts.length > 1) {
            parseQueryParameters(pathParts[1]);
        }
    }

    // q=hello
    // key1=value1&key2=value2&key3=value3
    private void parseQueryParameters(String queryString) {
        for (String param : queryString.split("&")) {
            String[] keyValue = param.split("=");

            String key = URLDecoder.decode(keyValue[0], UTF_8);
            String value = keyValue.length > 1 ? URLDecoder.decode(keyValue[1], UTF_8) : "";

            queryParameters.put(key, value);
        }
    }
    private void parseHeaders(BufferedReader reader) throws IOException {
        String line;
        while (!(line = reader.readLine()).isEmpty()) {
            String[] headerParts = line.split(":");
            headers.put(headerParts[0].trim(), headerParts[1].trim());
        }
    }

    private void parseBody(BufferedReader reader) throws IOException {
        if (!headers.containsKey("Content-Length")) {
            return;
        }

        int contentLength = Integer.parseInt(headers.get("Content-Length"));
        char[] bodyChars = new char[contentLength];

        int read = reader.read(bodyChars);
        if (read != contentLength) {
            throw new IOException("Failed to read entire body. Expected " + contentLength + " bytes, but got " + read);
        }
        String body = new String(bodyChars);
        log("HTTP Message Body: " + body);

        String contentType = headers.get("Content-Type");
        if ("application/x-www-form-urlencoded".equals(contentType)) {
            parseQueryParameters(body);
        }
    }

    public String getMethod() {
        return method;
    }

    public String getPath() {
        return path;
    }

    public String getParameter(String name) {
        return queryParameters.get(name);
    }

    public String getHeader(String name) {
        return headers.get(name);
    }

    @Override
    public String toString() {
        return "HttpRequest{" +
                "method='" + method + '\'' +
                ", path='" + path + '\'' +
                ", queryParameters=" + queryParameters +
                ", headers=" + headers +
                '}';
    }
}

• reader.readLine() → 클라이언트가 연결만 하고, 데이터 전송 없이 연결을 종료하는 경우 null이 반환된다. 이 경우 간단히 throw new IOException("EOF") 예외를 던지자.
  • 일부 브라우저의 경우 성능 최적화를 위해 TCP 연결을 추가로 하나 더 하는 경우가 있다.
  • 이때, 추가 연결을 사용하지 않고, 그대로 종료하면 TCP 연결은 하지만 데이터는 전송하지 않고, 연결을 끊게 된다. (참고만 하자)

HTTP 요청 메시지는 다음과 같다.

  GET /search?q=hello HTTP/1.1
  Host: localhost:12345

시작 라인을 통해 method, path, queryParameters를 구할 수 있다.

• method: GET
• path: /search
• queryParameters: [q=hello]

queryString, header의 경우, key=value 형식이기 때문에, Map을 사용하면 이후에 편리하게 데이터를 조회할 수 있다.

만약, 다음과 같은 내용이 있다면 queryParameters의 Map에 저장되는 내용은 다음과 같다.

• /search?q=hello&type=text
• queryParameters: [q=hello, type=text]

(%)퍼센트 디코딩도 URLDecoder.decode()를 사용해서 처리한 다음에 Map에 보관한다. 따라서 HttpRequest 객체를 사용하는 쪽에서는 퍼센트 디코딩을 고민하지 않아도 된다. 

• /search?q=%EA%B0%80
• queryParameters: [q=가]

HTTP 명세에서 헤더가 끝나는 부분은 빈 라인으로 구분한다.

• while (!(line = reader.readLine()).isEmpty())

이렇게 하면 시작 라인의 다양한 정보와 헤더를 객체로 구조화할 수 있다. 참고로 메시지 바디 부분은 아직 파싱하지 않았는데 뒤에서 설명한다. 그건 그렇고 이거 어디서 많이 본거 같다. 맞다. HttpServletRequest가 이런식으로 만들어진 것이다.

HttpResponse (HTTP 응답 메시지)

package cwchoiit.was.httpserver;

import java.io.PrintWriter;
import java.nio.charset.StandardCharsets;

import static java.nio.charset.StandardCharsets.*;

public class HttpResponse {
    private final PrintWriter writer;
    private int statusCode;
    private final StringBuilder bodyBuilder = new StringBuilder();
    private String contentType = "text/html; charset=UTF-8";

    public HttpResponse(PrintWriter writer) {
        this.writer = writer;
    }

    public void setStatusCode(int statusCode) {
        this.statusCode = statusCode;
    }

    public void setContentType(String contentType) {
        this.contentType = contentType;
    }

    public void writeBody(String body) {
        bodyBuilder.append(body);
    }

    public void flush() {
        int contentLength = bodyBuilder.toString().getBytes(UTF_8).length;
        writer.println("HTTP/1.1 " + statusCode + " " + getReasonPhrase(statusCode));
        writer.println("Content-Type: " + contentType);
        writer.println("Content-Length: " + contentLength);
        writer.println();

        writer.println(bodyBuilder);
        writer.flush();
    }

    private String getReasonPhrase(int statusCode) {
        return switch (statusCode) {
            case 200 -> "OK";
            case 404 -> "Not Found";
            case 500 -> "Internal Server Error";
            default -> "Unknown";
        };
    }
}

HTTP 응답 메시지는 다음과 같다.

  HTTP/1.1 200 OK
  Content-Type: text/html
  Content-Length: 20
  
  <h1>Hello World</h1>

시작 라인

• HTTP 버전: HTTP/1.1
• 응답 코드: 200
• 응답 코드의 간단한 설명: OK

응답 헤더

• Content-Type: HTTP 메시지 바디에 들어있는 내용의 종류
• Content-Length: HTTP 메시지 바디의 길이

HTTP 응답을 객체로 만들면 시작 라인, 응답 헤더를 구성하는 내용을 반복하지 않고 편리하게 사용할 수 있다.

HttpRequestHandlerV4

package cwchoiit.was.v4;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.Socket;

import static cwchoiit.util.MyLogger.log;
import static java.nio.charset.StandardCharsets.UTF_8;

public class HttpRequestHandlerV4 implements Runnable {

    private final Socket socket;

    public HttpRequestHandlerV4(Socket socket) throws IOException {
        this.socket = socket;
    }

    @Override
    public void run() {
        try (socket;
             BufferedReader reader = new BufferedReader(new InputStreamReader(socket.getInputStream(), UTF_8));
             PrintWriter writer = new PrintWriter(socket.getOutputStream(), false, UTF_8)) {

            HttpRequest httpRequest = new HttpRequest(reader);
            HttpResponse httpResponse = new HttpResponse(writer);

            if (httpRequest.getPath().equals("/favicon.ico")) {
                log("favicon 요청");
                return;
            }

            log("HTTP 요청 정보 출력:");
            System.out.println(httpRequest);

            log("HTTP 응답 생성 중...");
            if (httpRequest.getPath().equals("/site1")) {
                site1(httpResponse);
            } else if (httpRequest.getPath().equals("/site2")) {
                site2(httpResponse);
            } else if (httpRequest.getPath().equals("/search")) {
                search(httpRequest, httpResponse);
            } else if (httpRequest.getPath().equals("/")) {
                home(httpResponse);
            } else {
                notFound(httpResponse);
            }

            httpResponse.flush();
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }

    private void site1(HttpResponse response) {
        response.writeBody("<h1>Site1</h1>");
    }

    private void site2(HttpResponse response) {
        response.writeBody("<h1>Site2</h1>");
    }

    private void search(HttpRequest request, HttpResponse response) {
        String query = request.getParameter("q");

        response.writeBody("<h1>Search</h1>");
        response.writeBody("<ul>");
        response.writeBody("<li>query = " + query + "</li>");
        response.writeBody("</ul>");
    }

    private void home(HttpResponse response) {
        response.writeBody("<h1>Home</h1>");
        response.writeBody("<ul>");
        response.writeBody("<li><a href='/site1'>site1</a></li>");
        response.writeBody("<li><a href='/site2'>site2</a></li>");
        response.writeBody("<li><a href='/search?q=hello'>search</a></li>");
        response.writeBody("</ul>");
    }

    private void notFound(HttpResponse response) {
        response.setStatusCode(404);
        response.writeBody("<h1>404 페이지를 찾을 수 없습니다.</h1>");
    }
}

• 클라이언트의 요청이 들어오면 요청 정보를 기반으로 HttpRequest 객체를 만들어둔다. 이때, HttpResponse도 함께 만든다.
• HttpRequest를 통해서 필요한 정보를 편리하게 찾을 수 있다.
• /search의 경우, 퍼센트 디코딩을 고민하지 않아도 된다. 이미 HttpRequest에서 다 처리해두었다.
• 응답의 경우 HttpResponse를 사용하고, HTTP 메시지 바디에 출력할 부분만 적어주면 된다. 나머지는 HttpResponse 객체가 알아서 대신 처리해준다.
• response.flush()는 꼭 호출해줘야 한다. 그래야 실제 응답이 클라이언트에 전달된다.

HttpServerV4

package cwchoiit.was.v4;

import java.io.IOException;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

import static cwchoiit.util.MyLogger.log;

public class HttpServerV4 {
    private final ExecutorService es = Executors.newFixedThreadPool(10);
    private final int port;

    public HttpServerV4(int port) {
        this.port = port;
    }

    public void start() throws IOException {
        ServerSocket serverSocket = new ServerSocket(port);
        log("Starting HttpServerV2 server on port " + port);

        while (true) {
            Socket socket = serverSocket.accept();
            es.submit(new HttpRequestHandlerV4(socket));
        }
    }
}

HttpServerMainV4

package cwchoiit.was.v4;

import java.io.IOException;

public class HttpServerMainV4 {

    private static final int PORT = 12345;

    public static void main(String[] args) throws IOException {
        new HttpServerV4(PORT).start();
    }
}

실행 결과

• 실행 결과는 기존과 동일하다.

정리

HttpRequest, HttpResponse 객체가 HTTP 요청과 응답을 구조화한 덕분에 많은 중복을 제거하고 또 코드도 매우 효과적으로 리팩토링 할 수 있었다. 지금까지 학습한 내용을 잘 생각해보면, 전체적인 코드가 크게 2가지로 분류되는 것을 확인할 수 있다. 

• HTTP 서버와 관련된 부분
  • HttpServer, HttpRequestHandler, HttpRequest, HttpResponse
• 서비스 개발을 위한 로직 
  • home(), site1(), site2(), search(), notFound()

만약, 웹을 통한 회원 관리 프로그램 같은 서비스를 새로 만들어야 한다면, 기존 코드에서 HTTP 서버와 관련된 부분은 거의 재사용하고 서비스 개발을 위한 로직만 추가하면 될 것 같다. 그리고 HTTP 서버와 관련된 부분을 정말 잘 만든다면 HTTP 서버와 관련된 부분은 다른 개발자들이 사용할 수 있도록 오픈소스로 만들거나 따로 판매를 해도 될 것이다.

HTTP 서버5 - 커맨드 패턴 ⭐️

난 이 부분을 보고, 머리가 얼얼했다. 이렇게 만들어진 거구나.. 싶었기 때문이다.

우선, 이전까지 ServerSocket을 활용해서 HTTP 서버를 열심히 만들어봤다. 열심히 만들고 나니, HTTP 서버와 관련된 부분을 본격적으로 구조화하고 싶어진다. 그래서 서비스 개발을 위한 로직과 명확하게 분리해보자. 여기서 핵심은 HTTP 서버와 관련된 부분은 코드 변경없이 재사용 가능해야 한다는 점이다. HTTP 서버와 관련된 부분은 was.httpserver 패키지에 넣어두자. 이 패키지에는 현재 HttpRequest, HttpResponse가 들어가 있다. 이후에 HttpServer, HttpRequestHandler도 잘 정리해서 추가해보자.

커맨드 패턴 도입

앞에서 다음 코드를 보고, 아마도 커맨드 패턴을 도입하면 좋을 것이라 생각했을 것이다.

  if (request.getPath().equals("/site1")) {
      site1(response);
  } else if (request.getPath().equals("/site2")) {
      site2(response);
  } else if (request.getPath().equals("/search")) {
      search(request, response);
  } else if (request.getPath().equals("/")){
      home(response);
  } else {
      notFound(response);
  }

커맨드 패턴을 사용하면 확장성이라는 장점도 있지만, HTTP 서버와 관련된 부분과 서비스 개발을 위한 로직을 분리하는데 도움이 된다.

커맨드 패턴을 도입해보자.

HttpServlet

package cwchoiit.was.httpserver;

import java.io.IOException;

public interface HttpServlet {
    void service(HttpRequest request, HttpResponse response) throws IOException;
}

• HttpServlet 이라는 이름의 인터페이스를 만들었다.
  • HTTP, Server, Applet의 줄임말이다. (HTTP 서버에서 실행되는 작은 자바 프로그램 (애플릿))
  • 이 인터페이스의 service() 메서드가 있는데, 여기에 서비스 개발과 관련된 부분을 구현하면 된다.
  • 매개변수로 HttpRequest, HttpResponse가 전달된다.
  • HttpRequest를 통해서 HTTP 요청 정보를 꺼내고, HttpResponse를 통해서 필요한 응답을 할 수 있기 때문에 이 정도면 충분하다. 

HttpServlet을 구현해서 서비스의 각 기능을 구현해보자.

서비스 서블릿들

HomeServlet

package cwchoiit.was.v5.servlet;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.HttpServlet;

import java.io.IOException;

public class HomeServlet implements HttpServlet {
    @Override
    public void service(HttpRequest request, HttpResponse response) throws IOException {
        response.writeBody("<h1>Home</h1>");
        response.writeBody("<ul>");
        response.writeBody("<li><a href='/site1'>site1</a></li>");
        response.writeBody("<li><a href='/site2'>site2</a></li>");
        response.writeBody("<li><a href='/search?q=hello'>search</a></li>");
        response.writeBody("</ul>");
    }
}

Site1Servlet

package cwchoiit.was.v5.servlet;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.HttpServlet;

import java.io.IOException;

public class Site1Servlet implements HttpServlet {
    @Override
    public void service(HttpRequest request, HttpResponse response) throws IOException {
        response.writeBody("<h1>Site1</h1>");
    }
}

Site2Servlet

package cwchoiit.was.v5.servlet;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.HttpServlet;

import java.io.IOException;

public class Site2Servlet implements HttpServlet {
    @Override
    public void service(HttpRequest request, HttpResponse response) throws IOException {
        response.writeBody("<h1>Site2</h1>");
    }
}

SearchServlet

package cwchoiit.was.v5.servlet;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.HttpServlet;

import java.io.IOException;

public class SearchServlet implements HttpServlet {
    @Override
    public void service(HttpRequest request, HttpResponse response) throws IOException {
        String query = request.getParameter("q");

        response.writeBody("<h1>Search</h1>");
        response.writeBody("<ul>");
        response.writeBody("<li>query = " + query + "</li>");
        response.writeBody("</ul>");
    }
}

• HomeServlet, Site1Servlet, Site2Servlet, SearchServlet은 현재 프로젝트에서만 사용하는 개별 서비스를 위한 로직이다. 따라서 was.v5.servlet 패키지를 사용했다.

공용 서블릿들

NotFoundServlet

package cwchoiit.was.httpserver.servlet;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.HttpServlet;

import java.io.IOException;

public class NotFoundServlet implements HttpServlet {
    @Override
    public void service(HttpRequest request, HttpResponse response) throws IOException {
        response.setStatusCode(404);
        response.writeBody("<h1>404 페이지를 찾을 수 없습니다.</h1>");
    }
}

InternalErrorServlet

package cwchoiit.was.httpserver.servlet;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.HttpServlet;

import java.io.IOException;

public class InternalErrorServlet implements HttpServlet {

    @Override
    public void service(HttpRequest request, HttpResponse response) throws IOException {
        response.setStatusCode(500);
        response.writeBody("<h1>Internal Error</h1>");
    }
}

DiscardServlet

package cwchoiit.was.httpserver.servlet;

import cwchoiit.was.httpserver.HttpRequest;
import cwchoiit.was.httpserver.HttpResponse;
import cwchoiit.was.httpserver.HttpServlet;

import java.io.IOException;

public class DiscardServlet implements HttpServlet {
    @Override
    public void service(HttpRequest request, HttpResponse response) throws IOException {
        // empty
    }
}

• NotFoundServlet, InternalErrorServlet, DiscardServlet은 여러 프로젝트에서 공용으로 사용하는 서블릿이다. 따라서, was.httpserver.servlet 패키지를 사용했다.
• NotFoundServlet은 페이지를 찾을 수 없을 때 사용하는 서블릿이다.
• InternalErrorServlet은 서버 내부에 오류가 있을 때, 500 응답을 보여주기 위한 서블릿이다.
• DiscardServlet은 `/favicon.ico`와 같은 요청을 무시할 때 사용하는 서블릿이다.

이제 HttpServlet을 관리하고 실행시키는 ServletManager 클래스를 만들어보자.

그 전에 페이지를 찾지 못했을 때 터뜨리는 예외 클래스 하나를 만들어주자.

PageNotFoundException

package cwchoiit.was.httpserver;

public class PageNotFoundException extends RuntimeException {
    public PageNotFoundException(String message) {
        super(message);
    }
}

ServletManager

package cwchoiit.was.httpserver;

import cwchoiit.was.httpserver.servlet.InternalErrorServlet;
import cwchoiit.was.httpserver.servlet.NotFoundServlet;

import java.io.IOException;
import java.util.HashMap;
import java.util.Map;

public class ServletManager {
    private final Map<String, HttpServlet> servletMap = new HashMap<>();
    private HttpServlet defaultServlet;
    private HttpServlet notFoundErrorServlet = new NotFoundServlet();
    private HttpServlet internalErrorServlet = new InternalErrorServlet();

    public ServletManager() {
    }

    public void add(String path, HttpServlet servlet) {
        servletMap.put(path, servlet);
    }

    public void setDefaultServlet(HttpServlet defaultServlet) {
        this.defaultServlet = defaultServlet;
    }

    public void setNotFoundErrorServlet(HttpServlet notFoundErrorServlet) {
        this.notFoundErrorServlet = notFoundErrorServlet;
    }

    public void setInternalErrorServlet(HttpServlet internalErrorServlet) {
        this.internalErrorServlet = internalErrorServlet;
    }

    public void execute(HttpRequest request, HttpResponse response) throws IOException {
        try {

            HttpServlet servlet = servletMap.getOrDefault(request.getPath(), defaultServlet);
            if (servlet == null) {
                throw new PageNotFoundException("Page not found: " + request.getPath());
            }

            servlet.service(request, response);

        } catch (PageNotFoundException e) {
            e.printStackTrace();
            notFoundErrorServlet.service(request, response);
        } catch (Exception e) {
            e.printStackTrace();
            internalErrorServlet.service(request, response);
        }
    }
}

• ServletManager는 설정을 쉽게 변경할 수 있도록, 유연하게 설계되어 있다.
• was.httpserver 패키지에서 공용으로 사용한다.
• servletMap 
  • ["/" = HomeServlet, "/site1" = Site1Servlet, ...]과 같이 key/value 형식으로 구성되어 있다. URL의 요청 경로가 Key이다.
• defaultServlet: HttpServlet을 찾지 못할 때 기본으로 실행된다.
• notFoundErrorServlet: PageNotFoundException이 발생할 때 실행한다.  URL 요청 경로를 servletMap에서 찾을 수 없고, defaultServlet도 없는 경우 PageNotFoundException을 던진다.
• InternalErrorServlet: 처리할 수 없는 예외가 발생하는 경우 실행된다.

HttpRequestHandler

package cwchoiit.was.httpserver;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.Socket;

import static cwchoiit.util.MyLogger.log;
import static java.nio.charset.StandardCharsets.UTF_8;

public class HttpRequestHandler implements Runnable {

    private final Socket socket;
    private final ServletManager servletManager;

    public HttpRequestHandler(Socket socket, ServletManager servletManager) throws IOException {
        this.socket = socket;
        this.servletManager = servletManager;
    }

    @Override
    public void run() {
        try (socket;
             BufferedReader reader = new BufferedReader(new InputStreamReader(socket.getInputStream(), UTF_8));
             PrintWriter writer = new PrintWriter(socket.getOutputStream(), false, UTF_8)) {

            HttpRequest httpRequest = new HttpRequest(reader);
            HttpResponse httpResponse = new HttpResponse(writer);

            log("HTTP 요청: " + httpRequest);
            servletManager.execute(httpRequest, httpResponse);
            httpResponse.flush();
            log("HTTP 응답 완료");
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }
}

• was.httpserver 패키지에서 공용으로 사용한다.
• HttpRequestHandler의 역할이 단순해졌다.
• HttpRequest, HttpResponse를 만들고, servletManager에 전달하면 된다.

HttpServer

package cwchoiit.was.httpserver;

import java.io.IOException;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

import static cwchoiit.util.MyLogger.log;

public class HttpServer {
    private final ExecutorService es = Executors.newFixedThreadPool(10);
    private final int port;
    private final ServletManager servletManager;

    public HttpServer(int port, ServletManager servletManager) {
        this.port = port;
        this.servletManager = servletManager;
    }

    public void start() throws IOException {
        ServerSocket serverSocket = new ServerSocket(port);
        log("Starting HttpServer on listening port " + port);

        while (true) {
            Socket socket = serverSocket.accept();
            es.submit(new HttpRequestHandler(socket, servletManager));
        }
    }
}

• was.httpserver 패키지에서 공용으로 사용한다.
• 기존과 거의 같지만, HttpRequestHandler가 이제 생성자로 ServletManager를 받기 때문에 그 부분만 추가됐다.

ServerMainV5

package cwchoiit.was.v5;

import cwchoiit.was.httpserver.HttpServer;
import cwchoiit.was.httpserver.ServletManager;
import cwchoiit.was.httpserver.servlet.DiscardServlet;
import cwchoiit.was.v5.servlet.HomeServlet;
import cwchoiit.was.v5.servlet.SearchServlet;
import cwchoiit.was.v5.servlet.Site1Servlet;
import cwchoiit.was.v5.servlet.Site2Servlet;

import java.io.IOException;

public class ServerMainV5 {

    private static final int PORT = 12345;

    public static void main(String[] args) throws IOException {

        ServletManager servletManager = new ServletManager();

        servletManager.add("/", new HomeServlet());
        servletManager.add("/site1", new Site1Servlet());
        servletManager.add("/site2", new Site2Servlet());
        servletManager.add("/search", new SearchServlet());
        servletManager.add("/favicon.ico", new DiscardServlet());

        new HttpServer(PORT, servletManager).start();
    }
}

• 먼저 필요한 서블릿(HttpServlet)들을 서블릿 매니저에 등록하자. 이 부분이 바로 서비스 개발을 위한 로직들이다. 그리고 HttpServer를 생성하면서, 서블릿 매니저를 전달하면 된다.
• `/favicon.ico`의 경우 아무일도 하지 않고 요청을 무시하는 DiscardServlet을 사용했다.

실행 결과

• 기존과 실행 결과는 같다.

정리

이제 HTTP 서버와 서비스 개발을 위한 로직이 명확하게 분리되어 있다.

HTTP 서버와 관련된 부분 - was.httpserver 패키지

• HttpServer, HttpRequestHandler, HttpRequest, HttpResponse
• HttpServlet, ServletManager
• was.httpserver.servlet 패키지 (공통으로 사용되는 서블릿들)
  • InternalErrorServlet, NotFoundServlet, DiscardServlet

서비스 개발을 위한 로직 - v5.servlet 패키지

• HomeServlet
• Site1Servlet
• Site2Servlet
• SearchServlet

이후, 다른 HTTP 기반의 프로젝트를 시작해야 한다면, HTTP 서버와 관련된 was.httpserver 패키지의 코드를 그대로 재사용하면 된다. 그리고 해당 서비스에 필요한 서블릿을 구현하고, 서블릿 매니저에 등록한 다음에 서버를 실행하면 된다. 여기서 중요한 부분은 새로운 HTTP 서비스(프로젝트)를 만들어도, was.httpserver 부분의 코드를 그대로 재사용할 수 있고 또 전혀 변경하지 않아도 된다는 점이다.

이 부분을 공부하고 얼얼했던 이유는, Servlet, HttpServletRequest, HttpServletResponse가 이런 구조로 만들어졌구나를 깨달았기 때문이다. 아마 위 코드에서 서블릿 매니저에 서블릿을 등록하는 것은 애노테이션으로 Path를 넣어주면 그 애노테이션을 쭉 훑으면서 저 부분을 채워줄 것으로 예상한다. 너무 신기하고 재밌다. 

웹 애플리케이션 서버의 역사

만든 was.httpserver 패키지를 사용하면 누구나 손쉽게 HTTP 서비스를 개발할 수 있다. 복잡한 네트워크, 멀티스레드, HTTP 메시지 파싱에 대한 부분을 모두 여기서 해결해준다. was.httpserver 패키지를 사용하는 개발자들은 단순히 HttpServlet의 구현체만 만들면, 필요한 기능을 손쉽게 구현할 수 있다.

was.httpserver 패키지의 코드를 다른 사람들이 사용할 수 있게 오픈소스로 공개한다면, 많은 사람들이 HTTP 기반의 프로젝트를 손쉽게 개발할 수 있을 것이다. HTTP 서버와 관련된 코드를 정말 잘 만들어서, 이 부분을 상업용으로 판매할 수도 있을것이다. 그리고 이런 패키지가 바로 우리가 잘 알고 있는 Servlet이다.

서블릿과 웹 애플리케이션 서버

서블릿은 Servlet, HttpServlet, ServletRequest, ServletResponse를 포함한 많은 표준을 제공한다. 지금까지 was.httpserver 패키지에서 만든 것들과 다 유사한 기능을 가지는 것들이다. 서블릿을 제공하는 주요 자바 웹 애플리케이션 서버(WAS)는 다음과 같다.

• 오픈소스
  • Apache Tomcat
  • Jetty
  • Undertow
• 상용
  • IBM WebSphere
  • Oracle WebLogic

참고로, 보통 자바 진영에서 웹 애플리케이션 서버라고 하면 서블릿 기능을 포함하는 서버를 뜻한다.

표준화의 장점

HTTP 서버를 만드는 회사들이 서블릿을 기반으로 기능을 제공한 덕분에, 개발자는 jakarta.servlet.Servlet 인터페이스를 구현하면 된다. 그리고 Apache Tomcat 같은 애플리케이션 서버에서 작성한 Servlet 구현체를 실행할 수 있다. 그러다가 만약, 성능이나 부가 기능이 더 필요해서 상용 WAS로 변경하거나, 또는 다른 오픈소스로 WAS를 변경해도 기능 변경없이 구현한 서블릿들을 그대로 사용할 수 있다.