[스프링 부트 핵심 가이드] 02. 개발에 앞서 알면 좋은 기초 지식

(본 포스팅은 해당 도서의 정리 및 개인 공부의 목적 포스팅임을 밝힙니다.)

장정우, 『스프링 부트 핵심 가이드 : 스프링 부트를 활용한 애플리케이션 개발 실무』, 위키북스, 2022

 

 

 

02. 개발에 앞서 알면 좋은 기초 지식

애플리케이션의 동작 방식과, 왜 그렇게 구성 되는지에 대해 설명한다.

 

 

 

2.1 서버 간 통신

MSA는 Micro Service Architecture의 약자로, 근래의 웹기반 분산 시스템 디자인에 많이 반영 되고 있는 아키텍쳐이다.

단일 아키텍쳐가 개별 서비스에 각각의 중첩되는 모든 기능을 구현하여 일괄적으로 프로젝트를 개발하는 아키텍쳐라면,

MSA는 기능별로 묶어 서로 다른 서버로 관리하는 아키텍쳐이다.

일반적으로 단일 아키텍쳐는 내부의 호출로 다른 서비스의 데이터를 쉽게 가져 올 수 있으나 유지보수와 확장이 어렵고

MSA는 유지보수와 확장이 용이하지만 다른 서비스의 데이터를 요청하려면 서버 간 통신이 필수가 된다.

이때 서버 간 통신이란 두 서버가 통신하는 방식이며, 요청 측이 클라이언트, 응답 측이 서버의 입장이 되고 일반적으로 HTTP 프로토콜을 사용한다.

 

 

 

2.2 스프링 부트의 동작 방식

스프링 부트의 spring-boot-starter-web 모듈은 기본적으로 톰캣(Tomcat)을 사용하는 MVC 구조를 활용한다.

(MVC는 간단히 Model, View, Controller의 약자로 Model에 데이터를 담아 Controller의 중재로 View하여 보여주는 구조)

서블릿(Servlet)은 클라이언트의 요청을 처리하고 반환하는 자바의 웹 프로그래밍 기술이며, 서블릿 컨테이너는 이러한 서블릿을 싱글톤 패턴의 서블릿 객체로 생성, 초기화, 호출, 종료하는 생명주기를 관리한다. (톰캣은 WAS와 서블릿 컨테이너의 역할을 담당한다.)

 

스프링에서는 'DispatcherServlet'이 서블릿의 역할을 수행한다. DispatcherServlet의 동작 과정은 다음과 같다.

 

1. DispatcherServlet으로 HttpServletRequest(요청)이 들어오면 핸들러 매핑(Handler Mapping. handler = controller)을 통해 요청 URI에 매핑된 핸들러를 탐색.
2. 핸들러 어댑터(Handler Adapter)를 통해 컨트롤러를 호출하고, 해당 컨트롤러의 응답을 ModelAndView로 가공, 반환.
3. View 형식이라면 View Resolver를 호출하고, JSON 형식이라면 MessageConverter를 호출하여 응답.

여기서의 핸들러 매핑은 어떤 컨트롤러를 사용할지 선정하는 인터페이스로, 대표적인 구현체는 다음과 같다.

BeanNameUrlHandlerMapping	@Bean("/practice")   public class PracticeController   {}..
ControllerClassNameHandlerMapping	@Component   public class PracticeController                // 자동으로 Controller 앞의 클래스명을 매핑   {}..   <beans:property name:"urlPrifix" / "urlSuffix" value="/web/"></beans:property>
SimpleUrlHandlerMapping	<beans:prop key="practice">practice</beans:prop>   <beasn:bean id="practice" class="MyProject.Practice"></beans:bean>
DefaultAnnotationHandlerMapping	@RequestMapping("/practice")   public String mappingFunction(     @RequestParam("id") String id, ModelMap modelMap)   {}..

 

참고 사이트

https://springsource.tistory.com/3

https://www.whitestar.kr/m/327

https://nkcnow.tistory.com/239

 

 

 

2.3 레이어드 아키텍쳐

Layered Architecture.

컴포넌트를 유사 관사를 기준으로 층별로 묶은 수평적 구조.

보통 3계층으로 구성되며, 인프라(데이터 베이스) 레이어의 추가 유무로 4계층으로 구성된다.

이렇게 층으로 구성하는 이유는, 특정 레이어의 교체 및 수정과 확장에서 다른 레이어는 영향을 끼치지 않아 재사용과 유지보수성을 보장하며 가독성과 기능 구현에 유리하다.

각 층은 아랫층의 의존성을 주입받는다.

 

- 프레젠테이션 계층 // 클라이언트의 요청 해석 및 응답. (UI/API) - Controller, View, DispatcherServlet, Handler..

- 비즈니스(서비스) 계층 // 핵심 비즈니스 로직에 대한 구현. - Model

- 데이터 접근(영속) 계층 // 데이터 베이스에 접근하는 기능. (DAO/Repository) - Model

 

참고 사이트

https://stdbc.tistory.com/20

 

 

 

2.4 디자인 패턴

Design Pattern.

소프트웨어 설계 시에 반복되는 문제를 해결하기 위한 일종의 지침서.

개발자는 상황에 맞게 패턴을 선택하여 설계해야 한다.

 

 

2.4.1 디자인 패턴의 종류

디자인 패턴에는 분류한 4명의 인물을 의미하는 이름을 따서 명명한 'GoF 디자인 패턴'이 대표적이다.

크게 생성 패턴, 구조 패턴, 행위 패턴으로 나뉜다.

 

참고 사이트

https://4z7l.github.io/2020/12/25/design_pattern_GoF.html#%ED%96%89%EC%9C%84-%ED%8C%A8%ED%84%B4

 

 

2.4.2 생성 패턴

객체 생성에 사용되는 패턴. 객체의 생성 과정을 감추어 캡슐화하여 객체의 생성 및 변경에도 프로그램 구조에 영향을 끼치지 않게 하는 방법.

추상 팩토리, 빌더, 팩토리 메서드, 프로토타입, 싱글톤이 있다.

 

(생성 패턴 예시 : 팩토리 메서드)

 

 

2.4.3 구조 패턴

객체를 조합하여 더 큰 구조로 만들 수 있게 해주는 패턴.

어댑터, 브릿지, 컴포지트, 데코레이터, 퍼사드, 플라이웨이트, 프락시가 있다.

 

(구조 패턴 예시 : 데코레이터 패턴)

 

 

2.4.4 행위 패턴

객체 간의 알고리즘, 혹은 책임 분배에 관한 패턴으로, 하나의 작업을 여러 객체를 통해 작업 분배.

책임 연쇄, 커맨드, 인터프리터, 이터레이터, 미디에이터, 메멘토, 옵저버, 스테이트, 스트레티지, 템플릿 메서드, 비지터가 있다.

 

(행위 패턴 예시 : 이터레이터)

 

 

 

2.5 REST API

가장 대중적인 애플리케이션 인터페이스로, 클라이언트는 서버에 접근하고 자원 조작 가능.

 

 

 

2.5.1 REST란?

REpresentational State Transfer. 

www와 같은 분산 하이퍼미디어 시스템 아키텍쳐의 일종.

주고받는 자원(resource)에 이름을 규정하고 URI에 명시하여 HTTP 메서드(GET, POST, PUT, DELETE)로 자원의 상태를 주고 받는 것을 의미.

 

 

2.5.2 REST API란?

REpresentational State Transfer Application Programming Interface.

서버 또는 프로그램 사이를 연결할 수 있는, REST 아키텍쳐를 따르는 인터페이스.

REST 아키텍쳐를 구현하는 웹 서비스를 'RESTful 하다'고 한다.

 

 

2.5.3 REST의 특징

유니폼 인터페이스	REST 서버는 HTTP 표준 전송 규약을 따르므로 플랫폼, 프로그래밍 언어, 기술에 종속되지 않고 다른 기술과 호환하여 사용할 수 있는 일관된 인터페이스.
무상태성	stateless. 클라이언트가 보낸 요청의 세션이나 쿠키 정보 등의 상태 정보를 별도로 보관하지 않으므로, 불필요한 정보를 관리하지 않는 자유로운 로직과 단순한 설계.
캐시 가능성	응답, 요청이 모두 캐싱 가능하다면 (Cacheable) HTTP의 캐싱 기능을 활용하여 클라이언트에서 같은 요청은 캐시에 저장하고 해당 데이터를 사용. 서버의 트랜잭션 부하 감소.
레이어 시스템	네트워크 상의 여러 계층으로 구성될 수 있음.
클라이언트-서버 아키텍쳐	REST 서버는 API를 제공하고, 클라이언트는 사용자 정보를 관리하는 구조로 분리. 서로의 의존성이 감소.

 

 

2.5.4 REST의 URI 설계 규칙

URI의 마지막에는 '/' 미포함	http://website.com/web/
언더바(_) 대신 하이픈(-)	http://website.com/web/my_web_site
URL에는 행위(동사) 대신 결과(명사)	http://website.com/web/delete_web_site
URI는 소문자	http://website.com/web/WEBSITE
URI에는 파일의 확장자 미포함	http://website.com/web/my_web_site.html