스프링 부트 (Spring Boot) 란?

스프링 부트 소개: 스프링 부트 (Spring Boot) 란?

• 스프링 기반 앱을 독립실행형(standalone)으로 빠르게 개발할 수 있도록 도와주는 미리 구성된(pre-configured) 환경이다.

스프링 프레임워크의 대체재로 오해하면 안 된다.

스프링 부트가 탄생하게 된 이유

• 스프링 프레임워크의 버전이 계속 업데이트되며 환경을 구성하는 일이 점점 어려워졌기 때문이다.
• 프레임워크가 발전하며 여러가지 문제들을 마주하게 되었고 마주한 문제들을 해결하려 모듈을 추가하다보니 프로젝트를 잘 구성하는 것조차 어려운 일이 되어버렸다.
  • 너무 많은 선택지가 생겨버렸다.
• 많은 선택지는 문제에 대한 다양한 해결 방법을 제공했지만, 한편으로는 높은 진입장벽을 만드는 원인도 되었다.
• 이에 대한 해결책으로 몇몇 기업에서는 자신들이 미리 세팅한 프로젝트 구조를 만들어놓고 계속 쓰는 방식으로 문제를 해결했다.
• 결국 Improved support for 'containerless' web application architectures SPR-9888 이라는 이슈가 올라오게 된다.
  • 이 이슈에 대해 오피셜하게 논의되고 릴리즈된 새로운 프로젝트가 스프링 부트라고 보면 된다.
• 더 많은 스프링 사용 개발자를 끌어올 수 있게 되고, 개발자는 더 개발 자체에 집중할 수 있게 되었다.

스프링 부트의 핵심 목적

논의된 'containerless' web application architectures 즉, standalone application 을 제공하는 것이다.

• Opinionated framework: 베스트 프랙티스 조합을 미리 구성하여 좋은 개발 경험과 고품질 앱 생산 지원
  • 스프링 프레임워크가 선택할 수 있는 많은 옵션 중 'Best Practice' 라고 여겨지는 옵션들을 미리 선택해둔다.
  • 이렇게 좋다고 여겨지는 한쪽으로 치우쳐진 옵션을 미리 선택해두는 것을 Opinionated 라고 한다.
• Optimized for building modern app: 개발자가 코드 외적으로 신경써야 할 프로젝트에서 요구되는 환경설정을 제공한다.
  • Auto-configuration: 필요한 컴포넌트들이 자동으로 로드된다.
  • Dependency management: 특정 목적의 앱 개발을 위한 의존성을 뭉쳐두었다.
  • Embedded server: '독립실행형'으로 실행될 수 있게 한다.
  • Metrics and health checks: 헬스체크 모니터링과 같은 부분을 빌트인으로 지원한다.

Container 와 Containerless 란?

• Container 란, 보통 스프링 웹 앱에서는 Servlet Container 와 Spring Container 를 말한다.
• Containerless 란?
  • Serverless 와 비슷한 개념이다.
  • 컨테이너란 것이 사라진 게 아니라 추상 수준이 한 단계 더 높아져서 더이상 물리적 컨테이너에 신경쓸 필요가 없어진 것이다.

Container 란?

• 스프링에서 볼 수 있는 Container 는 대표적으로 Servlet Container 역할을 하는 Tomcat 이 있다.
• Servlet Container 는 단어의 의미처럼 Servlet 을 가지고 있는 컨테이너이다.
• 스프링은 또한 독립적으로 Spring Container 를 가지고 있다.
• 스프링은 저 Servlet Container 에 Dispatcher Servlet 이라는 서블릿을 올려 사용한다.
• 스프링으로 만들어진 서버에서 웹 클라이언트 요청을 처리할 때는 보통 아래와 같다.
  • 웹 클라이언트로부터 요청(Request) 이 들어온다.
  • 서블릿 컨테이너(Servlet Container) 를 거친다.
  • 서블릿 컨테이너는 스프링 컨테이너(Spring Container) 혹은 Application Context 라 불리는 것에 웹 요청을 전달한다.
  • 디스패처 서블릿(Dispatcher Servlet) 에 도달한다.
  • 디스패처 서블릿은 요청을 처리할 적절한 핸들러 매핑(Handler Mapping) 을 찾는다.
  • 컨트롤러(Controller) 라 불리는 핸들러(Handler) 가 나온다.
  • 컨트롤러는 이에 대한 응답(Response) 을 만들기 위한 로직을 수행한다.
  • 만들어진 응답을 웹 클라이언트에 전달한다.

Containerless 환경이 아닐 때 불편한 점

• web.xml 세팅을 직접 해주어야 한다.
  • 안에는 수많은 설정 정보가 있다.
• war 파일을 매번 생성해서 톰캣 경로로 옮겨주어야 한다.
• 클래스 로더를 설정해주어야 한다.
• 로깅은 어디에 저장될지 설정해주어야 한다.
• 서블릿 컨테이너 는 Tomcat 만 있는 게 아니라 다양한 종류가 있어서 바뀌면 매번 새로 배워야 한다.

Containerless 여서 좋은 점

• 프로젝트를 시작할 때 위에 나열한 것들을 전혀 신경쓸 필요 없다.
• 다만 나중에 필요에 의해 필요한 설정을 바꾸면 된다.

Opinionated 란

• 'Best Practice'로 여겨지는 한쪽으로 치우쳐진 옵션을 미리 선택해두는 것을 Opinionated 라고 한다.
• 스프링 프레임워크의 설계 철학 때문에 생기는 단점을 보완해주는 특성이다.

스프링 프레임워크의 설계 철학

• 극단적으로 유연하고, 많은 관점을 수용하고, 선택지를 많이 열어두는 것이 원래의 철학이다.
• 선택지가 많아 오히려 스프링에 입문하는 개발자들이 많은 혼란을 겪게 된다.

스프링 부트의 설계 철학

• 일단 정해주는대로 만들고, 필요에 의해서 개발자가 원하는 부분만 직접 바꾸는 것이 스프링 부트의 설계 철학이다.

스프링 부트가 정해주는 것

• 기술을 선택하면 의존성, 의존관계, 사용 버전까지 다 정해준다.
• 기술에 구성정보(Configuration)가 필요하다면 기본 구성정보까지 제공해준다.

스프링 부트가 위배하지 않는 것

• 커스터마이징을 금지하지 않는다.
• 아주 유연하게 커스터마이징을 지원한다.
• 어떻게 이런 유연함을 제공하는지만 알면, 스프링 부트의 기존 설계에 이어 부드럽게 우리의 설정을 이어나갈 수 있다.
• 나만의 스프링부트 모듈을 만드는 것도 가능하다.

스프링 부트가 해결해주지 못하는 것

• 스프링 내부에 기술적인 문제가 생겼을 때 자동으로 해결해주지 않는다.
• 많은 기술적인 부분을 숨겨둔다.

스프링 부트의 한계를 넘어서려면

• 스프링 자체의 기술을 알아야 한다.
• 스프링 부트의 기본 설정들을 이해해야 한다.
• 스프링 부트의 구성을 변경, 확장할 수 있어야 한다.
  • 확장 포인트들을 이해해야 한다.
• 커스터마이즈된 스프링 부트 모듈을 만들어 활용할 수 있어야 한다.

레퍼런스

https://www.inflearn.com/course/%ED%86%A0%EB%B9%84-%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-%EC%9D%B4%ED%95%B4%EC%99%80%EC%9B%90%EB%A6%AC/dashboard