[Spring] Spring의 기본적인 구조는 어떻게 생겼을까?

Intro

Spring boot를 통해서 프로젝트를 진행하고 공부하는 사람들 중에는 나처럼 일단 해보고 생각하자! 하면서 @Controller... @Entity.. 이렇게 코드부터 작성을 하는 사람들이 많을 것이다. 강의를 통하든, 인터넷 게시글 등을 통하든 대략적인 정보를 파악하고 코드를 쓰다 보면 에러가 발생하는 경우가 많은데, 이 에러들이 내가 평소에 알던 에러의 이름들이 아니다.

Servlet이 어쩌고 저쩌고... Bean이 어쩌고 저쩌고.. 하면서 알지 못하던 부분들이 많게 되서 그때마다 구글링을 통해서 누락된 부분을 추가하거나 수정하는 식으로 공부를 하였다.

그러던 와중 대체 이 Spring Boot가 어떻게 동작하길래 저런 에러들이 존재하는걸까? 하는 의문을 가지게 되었고 한 번 알아보기로 하였다.

다른 고수분들의 기술 블로그처럼, 원본 코드를 찾아서 하나하나 분석하기에는 내 실력이 아직 부족다고 생각하기 때문에 전체적인 흐름만 잡아보려고 한다.

---

Spring Framework의 철학

Spring docs를 읽다보니 Spring Framework의 디자인 철학이 쓰여 있는 것을 보게 되었다. 모든 관점에서 해석하기에는 아직 무리가 있지만 뭔가 알아두면 좋지 않을까 해서 적어본다. 파란색 글씨는 제 개인적인 의견을 적어보았습니다. 틀린 부분이 있으면 언제든 댓글 달아주신다면 수정하도록 하겠습니다.

• Provide choice at every level. (모든 레벨에서 선택을 제공한다)
  • 디자인 결정에 대해 가능한 늦게 결정을 할 수 있게 한다는 의미라고 한다. 설명에 따르자면, 코드를 변경하지 않고도 persistence provider을 변경할 수 있다고 한다. (아직 persistence provider을 변경하는 것이 어떠한 의미인지는 모르겟지만 코드를 최대한 수정하지 않고 유연하게 다른 무언가로 변경할 수 있게 하는 내용인가 라는 생각을 했다.)
• Accommodate diverse perspectives. (다양한 관점을 수용한다)
  
  • 다양한 애플리케이션 요구사항을 지원한다는 것을 의미한다. (어떠한 방식으로 설계를 하고 코드를 작성해라! 와 같이 강제성을 부여하지 않고 다양한 코드의 디자인 설계를 수용한다는 의미인 것 같다.)
• Maintain strong backward compatibility. (강력한 하위 호환성을 유지한다)
  • Spring의 버전이 업그레이드 되더라도 기존 코드를 최소한 변경하여 호환성을 유지하고자 한다고 함
• Care about API design. (API 디자인에 중요성을 둔다)
  • Spring 유저가 API를 사용함 있어서 직관적으로 사용할 수 있도록 많은 고민을 한다. 또한 이러한 Spring이 제공하는 API가 오랜 기간 유지되고 변하지 않는 것에 중점을 둔다.
• Set high standards for code quality. (코드 품질에 대해 높은 기준을 설정한다)

이러한 철학적인 부분이 프로젝트에 있어서 가야할 방향성 같은 것을 제공한다고 생각한다. 이러한 Spring의 디자인 철학이 나에게 어떠한 큰 도움을 줄 수 있을지는 모르겠지만, 알아두면 좋을 것이라 생각한다.

---

Spring IoC 컨테이너와 Bean

이전에 Spring Frameword에 대해 알아볼 때에, 특징 중에 IoC가 있다고 하였다. 즉, 객체를 사용자가 아닌 프레임워크가 관리해주는 제어의 역전이 특징인데, 그렇다면 어떻게 이러한 객체를 관리하는 걸까?

docs에 따르면 빈(Bean)이라는 것을 통해서 관리한다고 한다. xml설정 파일을 통해서 등록을 하거나 혹은 흔히 알고 있는 @ComponentScan을 통해서 빈을 등록하게 된다. 이 @ComponentScan의 경우 @Component 애노테이션을 찾게 된다.

Main문에 쓰이는 @SpringBootApplication 내부를 확인해보면 @ComponentScan이 있는것을 알 수 있다.

또한, @Service 애노테이션을 타고 들어가보면 내부에 @Component가 있는 것을 확인할 수 있다.

(@Component와 @Bean 두 애노테이션 사이에 차이가 있다고 하는데, 이 부분은 공부를 해보면 좋을 것 같다)

이렇게 빈을 등록하고 나면 스프링 컨테이너가 인식하게 되고, 필요한 순간에 스프링 컨테이너에서 빈을 생성, 소멸하는 등의 작업이 이루어진다고 한다.

빈의 경우 싱글톤 패턴을 사용하게 되며, 싱글톤 패턴의 경우 처음 컨테이너가 실행 시 생성되고, 애플리케이션이 종료될 때까지 남아있는다고 한다. 만약 다른 곳에서 A라는 빈을 필요로 한다면, DI(의존성 주입)을 통해서 가져올 수 있다.

---

Spring MVC패턴

출처: https://kchs94.tistory.com/201

그림을 보면, 클라이언에서 요청이 온다고해서 바로 내가 작성한 Controller로 오지 않는다.

맨 처음 요청은 DispatcherServlet이라는 곳으로 향하게 된다. DispatcherServlet은 Front Controller 패턴을 가지는 객체이기 때문에, Front Controller라고 불리기도 한다. DispatcherServlet은 서블릿 컨테이너로 오는 모든 요청을 전달받고, 공통적인 동작은 수행한 후에 매칭되는 Controller에게 이후 동작을 위임한다고 한다(보통 우리가 @Controller로 작성하는 컨트롤러들..!)

• 최초 요청이 들어오면 DispathcherServlet에 도달
• HandlerMapping을 통해서 요청에 알맞은 컨트롤러를 찾아냄
• HandlerAdapter을 통해서 해당 컨트롤러 메소드 실행
• 컨트롤러는 요청을 처리한 뒤 HandlerAdapter을 통해서 결과를 리턴
• 전달받은 결과를 토대로 DispatcherServlet은 ViewResolver을 통해서 View 파일을 찾는다.

---

Outro

사실 이 외에도, 내가 생각하기에 스프링을 다루기 위해서 영속성 컨텍스트, JPA 등 아직 많은 내용들을 정리하고 공부를 해야할 것 같지만 오늘은 간단한 구조와 동작원리만을 보기 위한 포스팅이다보니 여기서 멈추려고 한다.

프론트 구현하지 않는 단순히 RESTful API를 개발하다 보면 Servlet에러와 ViewResolver관련해서 에러가 많이 발생하는 경우가 있었는데, 이후에 이러한 스프링 에러들을 모아서 포스팅을 하면 좋을 것 같다(현재 정확히 기억이 나지 않음..)

Reference

---

https://docs.spring.io/spring-framework/reference/overview.html

Spring Framework Overview :: Spring Framework

https://velog.io/@jkijki12/Spring-%EC%8A%A4%ED%94%84%EB%A7%81-Bean-IoC-Container-DI%EA%B0%80-%EB%AD%94%EB%8D%B0

[Spring] 스프링 Bean, IoC Container, DI가 뭔데!!

https://kchs94.tistory.com/201

[스프링] Spring MVC 동작 방식과 구성요소

https://mozzi-devlog.tistory.com/8

[Spring] 디스패처 서블릿이란? (Dispatcher Servlet)