[스프링 부트] 02장. 개발에 앞서 알면 좋은 기초 지식

이 글은 '스프링 부트 핵심 가이드 - 스프링 부트를 활용한 애플리케이션 개발 실무' 책을 통해 학습한 내용을 정리한 글입니다.

스프링 프레임워크(Spring Framework)에는 약 20개의 모듈이 들어있다. 근데 기능이 많은 만큼 개발자가 신경써야 할 것이 많아지고 주요 업무인 비즈니스 로직 설계에 집중 할 수 없게 된다. 이를 해결하기 위해 나온 것이 스프링 부트(Spring Boot)이다. 

특징

1. 자동 설정(Auto-configuration)

스프링 부트는 다양한 기본 설정을 제공하여 개발자가 별도의 설정 없이도 어플리케이션을 실행할 수 있게 한다. 예를 들어, 스플이 데이터 JPA를 사용하기 위해 필요한 설정이 있다면, 스프링 부트는 자동으로 해당 설정을 수행한다. 이때, 개발자는 필요한 설정을 추가하거나 재정의 할 수도 있다.
@SpringBootApplication 어노테이션이 이에 해당한다.

2. WAS(Web Application Server)

스프링 부트에는 WAS가 내장되어 있다. 웹 어플리케이션을 만들 때 ‘spring-boot-start-web’이라는 의존성을 기본적으로 사용하는데, 이것을 통해 ‘tomcat’을 사용할 수 있다. tomcat이 아니라 다른 웹 서버로 교체하여 사용할 수도 있다.

3. 스타터 의존성(Starter dependencies)

스프링 부트는 의존성 관리는 간소화하기 위해 스타터 의존성이라는 개념을 도입했다. 스타터 의존성(spring-boot-starter)은 특정 기능이나 라이브러리를 사용하기 위해 필요한 모든 의존성을 포함하고 있다. 개발자는 필요한 스타터 의존성을 프로젝트에 추가함으로써 해당 기능을 쉽게 사용할 수 있다.

4. Actuator

스프링 부트는 어플리케이션의 상태를 모니터링하고 고나리하기 위한 Actuator기능을 제공한다. Actuator는 어플리케이션의 운영 환경에서 유용한 정보를 제공하며 어플리케이션의 메모리 사용량, 스레드 상태 등의 정보를 확인할 수 있다.
 

스프링 부트의 동작 원리

스프링 부트에서 spring-boot-starter-web 을 사용하여 개발한다면 기본적으로 Tomcat 을 사용하는 스프링 MVC 구조를 기반으로 동작한다.
1. 의존성 설정
스프링 부트 프로젝트를 생성할 때, ‘spring-boot-start-web’ 의존성을 추가하면 내장된 Tomcat 서버가 자동으로 설정된다.
2. DispatcherServlet 등록
스프링 부트는 웹 어플리케이션을 처리하기 위해 DispatcherServlet을 자동으로 등록한다. DispatcherServlet은 클라이언트의 모든 요청을 받아들이고, 알맞은 핸들러(컨트롤러)에게 요청을 전달한다.
3. URL 매핑
컨트롤러에는 요청을 처리할 수 있는 메서드들이 정의되어 있는데 이러한 메서드는 어노테이션 기반으로 URL 매핑을 설정한다. 스프링 부트는 어플리케이션의 ClassPath 에서 컨트롤러를 자동으로 스캔하여 매핑 정보를 수집한다.
4. 요청 처리
클라이언트의 요청이 들어오면, DispatcherServlet은 요청을 받아들이고, URL 매핑 정보를 바탕으로 알맞은 컨트롤러의 메서드를 호출한다. 컨트롤러는 요청을 처리하고 필요한 비즈니스 로직을 수행한다.
5. 모델 및 뷰 반환
컨트롤러는 요청을 처리한 결과를 모델에 담아서 반홚나다. 모델은 어플리케이션의 상태나 데이터를 담고 있는 객체이다. 컨트롤러는 뷰를 선택하고 모델과 함께 반환한다.
단, 뷰를 사용하지 않고 JSON만 내려주는 형태라면 뷰 리졸버를 호출하지 않는다.
6. 뷰 렌더링
DispatcherServlet은 컨트롤러가 반환한 뷰를 실제로 렌더링하여 클라이언트에게 응답으로 보낸다. 뷰는 동적인 HTML, JSON 등을 생성한다.
7. 응답 전송
DispatcherServlet은 최종적으로 뷰에서 생성된 응답을 클라이언트에게 전송한다. 이 응답은 HTTP 프로토콜을 따르며, 클라이언트는 이를 받아서 사용자에게 보여준다.
 

레이어드 아키텍처(Layered Architecture)

레이어드 아키텍처는 소프트웨어를 여러 개의 레이어로 구성하여 각 레이어가 독립적으로 영할과 책임을 가지고 동작하는 소프트웨어 아키텍처 패턴이다. 각 레이어는 특정한 기능과 역할을 수행하며, 각 레이어는 다른 레이어와의 인터페이스를 통해 상호작용한다.
1. 프레젠테이션 계충

• 사용자와의 상호작용을 처리하는 계층
• UI나 API를 제공
• 별도의 비즈니스 로직을 포함하지 않고, 비즈니스 레이어로 요청을 위임하고 받은 결과를 응답하는 역할만 수행
• 주로 웹 어플리케이션에서는 컨트롤러(Controller)와 뷰(View)로 구성

2. 비즈니스 계층

• 비즈니스 로직을 처리하는 계층
• 주로 서비스(Service)와 도메인(Domain) 객체로 구성

3. 데이터 접근 계층

• 데이터베이스나 외부 시스템과의 상호작용을 처리하는 계층
• 데이터의 영구 저장 및 검색을 담당
• 주로 레포지토리(Repository)나 DAO(Data Access Object)로 구성

 

REST API

REST는 웹 기반 시스템에서 리소스를 고유한 식별자(URI)를 통해 표현하고, HTTP 메서드를 사용하여 리소스에 대한 작업을 수행하는 아키텍처 스타일이다. REST API는 이러한 REST 원칙을 따르는 API를 말한다.

REST 의 특징

• 유니폼 인터페이스 : 플랫폼 및 기술, 언어에 종속되지 않고 호환해 사용할 수 있다.
• 무상태성 : 서버에 상태 정보를 따로 보관하거나 관리하지 않는다.
• 캐시 가능성 : HTTP의 캐싱 기능을 적용할 수 있으며, 이 기능을 사용하면 서버의 트랜잭션 부하가 줄어 효율적이며 성능을 개선할 수 있다.
• 레이어 시스템 : TEST 서버는 레이어드 계층으로 구성될 수 있다.
• 클라이언트-서버 아키텍처 : REST 서버는 API를 제공하고, 클라이언트는 사용자 정보를 관리하는 구조로 분리해 설계한다.

REST의 URI 설계 규칙

• URI 마지막에는 ‘/’를 포함하지 않는다.
• 언더바(_)는 사용하지 않고, 하이픈(-)을 사용한다.
• URL에는 행위(동사)가 아닌 결과(명사)를 포함한다.
• URI는 소문자로 작성해야 한다.
• 파일의 확장자는 URI에 포함하지 않는다.

 
03장. 개발 환경 구성

• 개발 환경
• 인텔리제이(IntelliJ) Ultimate
• JDK 11(1.8 버전 이상)
• 스프링 부트 2.5.6~2.5.8
• MariaDB 10.6.5
• Maven