[우테코 레벨2] 미션1, 방탈출 예약 관리 회고

레벨 1이 끝나고 레벨 2가 시작됐다. 스프링을 처음 배우는 사람들을 위한 과정이라고 하니 나를 위한 과정이다~

방탈출 예약 관리

STEP1

[1-3단계] PR 링크

 

페어로 포스티, 다로가 되었다. 레벨마다 3인 페어를 한번씩 걸리는 것 같다. 주변에서 3시간만 투자해도 미션을 구현할만큼 간단하다고 해서 학습 테스트를 하는데 시간을 많이 썼다. 그리고 개인적으로 궁금한 키워드들에 대해서도 학습하는 시간을 가질 수 있었다. 아쉬운 점은 쉬운 미션이고 기간이 짧은만큼 빠르게 merge 되었다는 점이다.

나는 뭘 배웠을까?

- `@RequestBody` vs `@ModelAttribute`

미션 중 클라이언트 요청 시 Body에 포함된 Json 데이터를 객체로 바로 받으려고 할 때, 파라미터에 적용한 두 어노테이션 `@RequestBody`, `@ModelAttribute` 모두 객체로 변환하여 파라미터로 받을 수 있었다. 재밌는 점은 `@ModelAttribute`로 받을 경우 객체의 모든 필드가 null이라는 점이다. 이는 서로 다른 목적으로 사용되기에 그렇다.

1. @RequestBody
RequestBody는 HTTP 요청 본문(Json, XML, etc...)을 Java 객체로 변환한다.
HTTP 요청 본문 데이터는 `HttpMessageConverter`를 통해 타입에 맞는 객체로 변환된다.

public class RequestBodyDto {

    private String name;
    private long age;
    private String password;
    private String email;

    public RequestBodyDto() { // 기본 생성자
    }

    // Getter 추가 및 Setter 삭제
}

신기하게도 필드를 초기화하는 생성자, setter가 없어도 `@RequestBody`는 정상적으로 매핑한다. 그 비밀은 `MappingJackson2HttpMessageConverter`이다. 직렬화를 위한 기본 생성자가 필수이다. 또한 데이터 바인딩을 위한 필드명을 알아야해서 getter, setter 둘 중 하난 있어야 한다!

2. @ModelAttribute
HTTP 파라미터들을 특정 자바 객체에 매핑하는 것이다. `/hello?name=req&age=1`, `form-data/name=req&age=1`와 같은 요청에 대한 form 데이터를 처리해준다. 생성자로 매핑하지만, 없으면 setter로 매핑한다.

 

 

- `@Component` vs `@Controller`

@Component는 클래스에 선언하여 Bean으로 관리하도록 하는 어노테이션이다.
@Controller도 그 관점에서는 똑같다. 내부에 @Component가 있다.

그럼 뭐가 다른가?
컴포넌트 스캔 단계에서 조금 차이를 보이는데 스프링은 `RequestMappingHandlerMapping` 클래스를 빈으로 만들고, 초기화 메서드를 시작한다. 그리고 `@Controller` 어노테이션이 붙은 빈을 가져온다. 이때, 내부적으로 `isHandler` 메서드를 호출하여 가져온 빈의 어노테이션을 확인하고, `@Controller` 어노테이션이면 핸들러 메서드를 찾는다.

그리고, 해당 메서드를 key(URL): value(메서드 및 클래스)의 형태로 매핑한다. 즉, `@Controller`를 붙이면 해당 정보에 매핑되어 URL에 대한 처리를 할 수 있도록 만들어진다.

만들어진 매핑 정보는 `RequestMappingHandlerAdapter`에서 해당 컨트롤러를 호출하는데 이용된다!

스프링 부트 2.x 버전에서는 `@RequestMapping` 어노테이션이 붙은 클래스도 매핑 대상에 포함되었으나, 3.x 버전부터는 `@Controller` 어노테이션만 매핑 대상에 포함된다. 결론은 해당 클래스가 컨트롤러임을 스프링에게 알려주려면 @Controller로 명시해야 한다.

 

- 웹 요청 흐름

1. localhost -> 헤더에 /admin/reservation을 담아 자신의 컴퓨터 ip로 GET 요청
2. 톰캣이 해당 요청을 받아서 HttpServeletRequest 객체로 변환
3. 변환된 객체를 스프링의 DispatcherServlet에 전달함
4. 이 객체에서 요청 URL을 확인
5. RequestMappingHandlerAdapter가 RequestMappingHandlerMapping이 등록한 key(url: /admin/reservation): value(개발자가 작성한 컨트롤러 메서드)를 보고 컨트롤러 호출
6. spring에서 http body에 html 파일을 담아 응답함.
7. http를 받은 브라우저는 렌더링을 하면서 필요한 css, js 파일을 다시 요청
8. 받고나서, 렌더링을 진행하다가 js 파일을 받으면 해당 js 코드를 실행함
9. js 코드 안에서 json 데이터 요청
10. 받아서 페이지 렌더링

 

 

- 누가 `JdbcTemplate`을 주입해줄까?

이 궁금증은 JdbcTemplate과 @Autowired를 사용하면서 생긴 궁금증이다. 나름대로 조사를 통해 정체를 알아냈다. 결론부터 말하면 주입해주는 주인공은 바로 스프링 컨테이너.

 

스프링 컨테이너는 스프링 IoC Container라고 부르며, 이 컨테이너는 스프링 빈으로 등록된 객체들을 관리해준다. `org.springframework.context.ApplicationContext` 인터페이스로 나타나며, configuration metadata를 읽어 컴포넌트들을 어떻게 인스턴스화하고 조합하고 설정할지 알아낸다.

 

configuration metadata는 무엇일까?

이는 xml과 같은 문법으로 어떤 객체를 빈으로 등록할지 적어놓은 파일이다. `<bean>` 태그와 함께 객체의 필드 등이 작성된 파일을 본 적 있을텐데 이게 configuration metadata에 해당한다. 또는 가장 쉽게 볼 수 있는 `@Bean`, `@Component` 등과 같은 어노테이션 방식이 있다.

 

다시 돌아와서 정리하면 스프링 어플리케이션을 실행하면 `ApplicationContext`가 생성되고 configuration metadata, @Bean, @Component로 등록된 클래스를 스캔하면서 스프링 빈으로 만든다. 이때 두 방식에서 차이가 생긴다.

 

- xml 파일로 정의한 경우

1. xml 파일 속 bean을 모두 스캔하고 생성 순서를 먼저 파악한다.  

2. 다른 빈을 의존하면, 의존되는 빈을 먼저 생성한다.

3. xml 파일에 정의된 생성자 인자에 따라 주입하며 빈을 차례로 생성한다.

 

- @Bean, @Component

@Bean의 경우 직접 메서드를 호출하며 의존 관계를 설정하기에 이를 토대로 스프링에서 메서드 호출을 가로채 빈을 생성하고 주입한다.

 

@Component의 경우 xml과 비슷하게 필요한 빈을 먼저 생성하며 주입한다.

 

 

 

STEP2

[4-9단계] PR 링크

 

step2부터 데이터베이스가 들어가고, 새로운 도메인 객체가 생기고 계층 구조가 생겼다. 이쯤부터는 혼자 진행하기도 했고, 당장 구현이 어렵다고 느끼지 않아서 내 학습 방법을 이용해 학습했다. 그래서 여러 크루들과 대화를 나누는 시간이 더 많았고, 자연스레 스프링의 사용 방법보다는 설계나 철학에 대한 고민을 더 많이 한 것 같다.

 

나는 뭘 배웠을까?

- DDD

도메인 객체에 `id`가 들어가는 것에 대하여

[블로그] 객체가 DB의 id를 필드로 가지는 것에 대하여

레벨 1부터 계속 객체지향을 배우다 DB의 필드가 들어가는 것이 불편했기에 이런 고민을 했다. 그리고, 관점을 달리하며 이를 해소했다.

 

`DAO` vs `Repository`

데이터를 다루기 위해 DB에 집중하게 된다면 DB 테이블과 1:1 매핑되는 코드를 작성하게 된다. 그리고 이렇게 되면 DB와 객체 사이의 패러다임을 맞추기 위해 객체의 필드를 변경한다. 장기 미션때도 그랬다. DB에 집중하여 코드를 작성하다보니 객체지향이 아닌 데이터베이스 중심적인 코드를 작성하게 됐고, 객체의 구조를 바꾸게 되는 경험을 했었다. 이런 경험을 했기에 이제는 DB가 아닌 객체에 집중하고 싶었다.

그래서 관점을 바꿔보았다. DB가 아닌 도메인 객체의 문제를 해결하기 위한 요구사항을 먼저 생각하고 요구사항에서 데이터를 다루는 기능들을 먼저 생각한다면 이러한 기능들의 목록을 뽑아 추상화를 할 수 있다. 이렇게 추상화하면 해당 기능들의 집합은 DB 테이블과 1:1 대응되는 것이 아닌 마치 도메인 객체에 대한 컬렉션처럼 보인다.

두 경우의 차이가 이해가 되는가? 첫 번째 경우는 `DAO`고, 두 번째 경우가 바로 `Repository`이다. 

 

엔티티, 도메인, VO

[블로그] 엔티티, VO...

용어에 대한 기준이 필요하다고 생각해서 여러 크루들과 이야기를 나누며 나의 생각을 전파하고 다른 이들의 생각을 흡수하며 용어에 대해 어느정도 정리를 해보았다. 하지만, 아직 DDD를 학습하기엔 이른 것 같아서 따로 학습하진 않을 예정이다. 아마 지금처럼 크루들과의 얘기를 통해 DDD 지식을 흡수할듯하다! 레벨 2는 스프링의 사용 방법에 목적을 두고있음을 항상 잊지 않고 나아갈 생각이다.

 

 

- `@Autowired`

1. 생성자 주입
2. setter 주입
3. 필드 주입

이외에도 여러 기능들이 있다.

public class MovieRecommender {

	@Autowired
	private MovieCatalog[] movieCatalogs;
	// private Set<MovieCatalog> movieCatalogs;

	// ...
}

이렇게 코드를 작성하면, `movieCatalogs` 배열에 `MovieCatalog`로 만들어진 모든 빈을 담아준다. 컬렉션도 예외는 없다. 게다가 `@Order`, `@Priority`로 순서를 정할 수 있다.

Map으로 받는다면 `Map<String, MovieCatalog>`처럼 key로 빈 이름, value로 해당 빈을 가져올 수도 있다.

`required` 옵션은 빈이 꼭 채워지지 않아도 된다는 옵션이다. 기본적으로 true이기에 주입할 빈이 없으면 런타임 에러가 발생한다. 하지만, required 옵션을 false로 준다면 빈이 없어도 에러가 발생하지 않고 null로 채운다.

또, 재밌는 점은 인터페이스와 같이 여러 빈이 들어올 수 있는 경우는 필드명을 보고 빈을 주입해준다.

 

- 레이어드 아키텍처

레이어드 아키텍처의 핵심은 관심사의 분리라고 생각한다. 해당 미션에서 step1까지는 컨트롤러와 서비스의 계층을 나눠야 하는 이유를 찾지 못했었다. 서비스가 가져야 할 책임의 무게가 너무 작아보였기 때문이다. 하지만, 레이어드 아키텍처 관점에서 본다면 이는 잘못된 구조이다. 관심사의 분리에 집중하면 컨트롤러에서 비즈니스 로직을 처리하는 것이 잘못되었으며, 서비스가 가지는 책임의 무게가 작더라도 해당 책임을 분리하는 것이 맞다.

그래서 step2에서는 의도적으로 컨트롤러와 서비스의 계층을 구분하였다. 이러한 설계가 의도적으로 들어가야 관심사의 분리를 이뤄낼 수 있으며, 추후에 사소한 책임이라도 분리해낼 수 있다고 생각한다.

 

 

 

마지막

이번 미션 뿐만 아니라 항상 페어 프로그래밍을 하면서 의문이 드는 것이 있다. step1에서는 구현이 바빠 깊게 고민하지 못하고 키워드만 가져가게 되고, step2에서 해당 키워드에 대한 의문을 해소하고 여러 방면에서 깊은 고민에 빠지게 된다. 이런 사이클이 정말 좋은 것일까? 페어 프로그래밍에서도 step2만큼 얻어갈 순 없을까?

페어 프로그래밍에서 얻어갈 것은 무엇이며, step2를 진행하며 얻어가는 것의 차이는 뭘까? 나는 아직 페어 프로그래밍의 장점을 크게 못 가져가는 것 같다고 생각했다. 분명 레벨 1 회고에서 우테코의 환경을 통해 성장한다고 했지만 페어 프로그래밍에서는 성장할만큼 깊은 고민을 할 시간이 주어지지 않기 때문이다. 그렇기에 성장한다고 느끼지 못했다.

하지만, 이번에 회고를 하면서 이런 사이클도 괜찮은 사이클이 아닌가 하는 생각이 들었다. step2가 되면 여러 크루들과 대화를 나누고, 생각할 시간들을 가지면서 스스로 성장한다. step1을 진행하며 나름의 의도를 담으려고 고민하고 생각했기에 배움에 대한 키워드를 뽑아낼 수 있었던 것이고, 이를 step2에서 고민하고 생각하며 해소할 수 있었던 것이다. 나는 이미 페어 프로그래밍에서 얻을 수 있는 것을 잘 얻어내고 있었다. 

페어가 아니었다면 생각하지 못했을 키워드도 있었고, 스스로 생각한 키워드도 있었다. 그리고 이런 키워드들이 방향성을 잡아준다. 그러면서 자연스레 step2에서 이런 고민들을 해소하고 크루들과 얘기를 나누며 나만의 철학을 만들어간다.

충분히 잘 하고 있었다.