[북스터디] 스프링 부트 핵심 가이드(ch1~ch3)를 공부해 보았다.(2편)ch2~ch3

2편에 2, 3이 다 있는 이유.(ch3 빠르게 정리)

이제 다음 챕터의 내용을 기술한다. 하지만 아쉽게도 ch3는 별로 다룰 내용이 없다. 기초 개발 환경을 써둔 것이며, 이 역시 한줄로 하면 intellij ultimate을 쓰세요!
이런 느낌이기 때문이다.
이를 통해 얻을 수 있는 이점 같은 경우에는 확실히 제로베이스 9기 수강생들의 질문란에서도 강의(인텔리제이 얼티밋 사용)와 달리 웹 이동 환경이 안 나온다.(수강생의 경우 인텔리제이 커뮤니티 버전으로 했다고 합니다.)

이런 불편을 이야기 했었기에, 이해가 안 되는 건 아니지만 솔직히 많이 아쉬운 부분이었다. 모든 걸 알고 넘어가고 싶어하는 마음 때문에 그런 것도 있겠지만, 30일 try외에는 학생이 아닌 사람은 유료로 이용해야 하는 경우만 제공하는 것이 좀 흠처럼 느껴졌다.

이제 ch2를 이야기 해 보자.

ch2의 경우 정말 큰 도움이 되었다. 여지껏 좋은 소리를 많이 안 했던 것 같지만, 그건 필자의 성향 때문에 그런 것이기 떄문에 불편하셨다면 죄송을... 또 한편으로는 이 책의 가치를 꼼꼼히 따져 보고, 핵심 또는 자신들의 필요 요소들을 살펴 봐 주길 바란다!

ch2는 개발에 앞서 알면 좋은 기초 지식!이라는 내용으로 웹에 관한 CS지식을 몇 가지 다룬다.
이 내용들이 굉장히 영양가가 높아서 조금 글이 길어질 수 있을 것 같다.

최대한 본서의 내용 위주로 작성하지만, 내가 이해한 것들과 포괄적으로 작성했다. :)

1. 서버 간 통신.

-- 마이크로 아키텍처(MSA: Microservice Architecture)
서적에서는 현재 우리가 사용하는 다양한 웹애플리케이션들이 하나의 거대한 단일 파일이 아니라,
기능에 따라 나뉘어 있는 형태로 이루어져 있다고 이야기하며 마이크로 아키텍처를 이야기한다.

서적의 예를 이야기 해 보면, 웹애플리케이션이라 함은 우리가 현재 이용하고 있는 블로그를 예로 들 수 있다.
현재의 블로그에서 유저는 댓글쓰기 또는 앞으로 가기/뒤로 가기, 클릭, 공감 표시 등 다양한 기능들을 사용한다.
이러한 기능들이 하나의 거대한 파일에 저장된다면, 유지보수를 하거나 수정될 때,
일부를 수정하더라도 전체를 수정하는 것이 된다.

하지만 이러한 마이크로 아키텍처 구조를 이용하면 기능 별로 유지보수가 필요한 부분만 부분적으로 접근해 수정할 수 있게 된다.

다만, 여기서 첫 장의 서버 간 통신이라는 문제가 발생한다. 가령, 공감하기를 누르고 싶지만 이 경우에는
로그인이 선행되어야 한다. 즉, 로그인 정보가 존재하는지 안 하는지의 유효성을 확인해 줄 수 있어야 하고,

이 경우는 로그인 서비스를 담당하는 아키텍처와 공감하기 기능의 아키텍처의 상호 통신이 필요하다는 것이다.
서적에서는 이러한 통신을 요청하는 몇 가지 프로토콜이 있음을 이야기한다.(스터디 가이드라는 날개란에 총 4가지를 안내한다.)
하지만 그 중 대표격인 HTTP/HTTPS 방식을 기반으로 소개한다.

이때, 서버 간 통신을 하는 가장 기초적인 양태로 사용자(클라이언트)-서버의 형태로 소개를 진행한다.

2. 스프링 부트의 동작 방식.

위의 클라이언트-서버에 관한 스프링 부트의 동작 구조를 소개한다.

해당 그림만으로는 내용을 이해하기가 무리가 있는데, 한 번 차근차근 이야기 해 보자.

1. 서블릿.
   이것만 해도 굉장히 큰 개념이지만 서적에 나와 있는 수준으로만 이야기 하자면,
   클라이언트의 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술이다.
   또한 서블릿은 그림에 나와 있는 '서블릿 컨테이너'에서 관리하며,

이 서블릿 컨테이너는 서블릿 인스턴스를 생성하고 관리하는 역할을 수행한다.

자바로 웹프로그래밍을 하면 톰캣이라는 것을 만나게 되는데, 이 톰캣이 was의 역할(웹 애플레케이션 서브시)와
서블릿 컨테이너의 역할을 수행하며, 이 톰캣은 스프링에 내장 되어 있다.

--> 서블릿 컨테이너의 특징 3가지.

• 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리
• 서블릿 객체는 싱글톤 패턴으로 관리
• 멀티 스레딩을 지원

스프링 프레임워크의 경우에는 Dispactcher Servlet이 서블릿의 역할을 수행하고 여기에 톰캣을 임베드(embed)에 사용하며,
이때, 서블릿 컨테이너(임베드 된 톰캣)와 DispatcherServlet은 web.xml이라는 설정값을 공유합니다.
*web.xml은 웹 애플레이케이션을 만들 때 설정을 하는 곳으로 보통 webapp(webcontent) 하위의 web-inf의 lib 폴더에 존재합니다.

이러한 Dispatcher Servlet의 동작을 서적에서는 간략히 소개하고 있는데(간략히가 맞지만 간단하게 이해가 되지는 않는...)
그림에서 나와 있는 내용을 그대로 이야기 해주는 방식입니다.

• 클라이언트가 HttpServletRequest를 요청하고 이를 DispatcherServlet이 그림에 나와 있는 핸들러 매핑(Handler MApping)을 통해 요청 URI에 매핑된 핸들러를 탐색, 여기서 핸들러는 컨트롤러를 의미한다고 합니다.
  (일단 처음 보고 핸들러 매핑이고, 핸들러고 컨트롤러고 뭐가 뭔지 처음에 이해가 안 되셔도 정상입니다...)

• 핸들러 어댑터(Handler Adapter)로 컨트롤러를 호출
  (이건 그림 내용을 쉽게 따라 갈 수 있는데... 문제는 위의 말이겠죠? 여기서 말하는 컨트롤러랑 위에서 말하는 컨트롤러는 같은 건가 다른 건가?! 결론만 말하면 같은 겁니다.)

• 핸들러 어댑터에 컨트롤러의 응답이 돌아오면 ModelAndView로 응답을 가공해 반환
  (ModelAndView는 뭔데...아무런 설명 없이 이야기하는데
  스프링에서 직접 객체를 선언해 줘야 하는 별도의 객체를 의미하며,
  스프링에서 제공하는 하나의 기능이라고 보시면 됩니다...)

• 뷰 형식으로 리턴하는 컨트롤러를 사용할 때는 뷰 리졸버(View Resolver)를 통해 View를 받아 리턴.

위와 같은 불친절한 설명 등은 지면의 한계로 어쩔 수 없는 부분이 있었으리라 생각하지만, 꼼꼼히 찾아 보게도 되고, 여러가지를 찾아 볼 수 있게 해주었던 것 같습니다.

이하로 책에서는 핸들러 매핑에 대한 설명과 뷰 리졸버 등의 설명을 하지만,

이 책은 뷰가 없는 REST 형식을 사용하기 때문에 해당 내용은 서적을 통해 보심이 좋을 것 같습니다.
(여기서 처음에 REST가 뭔가 했습니다.
자주 나오는데 솔직히 뭔지 몰랐기에...
뒤에서 나오니까 해당 부분을 먼저 읽고 오시는 것도 좋을 것 같습니다.)

위의 그림이 서적에서 소개하는 방식이다.
MessageConverter가 요청과 응답에 대해 Json*의 Body 값을 변환하는 역할을 수행한다.
Json이란 맵의 일종으로 데이터를 {키 : 바디} 의 형태로 저장하는 방식을 말한다.

레이어드 아키텍처

스프링의 동작방식이 조금 길어진 느낌이 있지만 이것도 많이 줄인 것이기에...양해를 부탁드리며.
레이어드 아키텍처를 살펴 보자!
단어만 보면 되게 쉽게 다가갈 수 있게 생겼지만 막상 또 열어보니 그렇게 쉽지만도 않았다.

책에서는 유사 관심사라는 단어를 사용하는데 왜 이런 단어를 썼는지 이해는 되었다. 서비스 군집을 무어라
부를까 고민한 끝에 그런 것으로 보인다.

나 역시 이를 정확히 뭐라 짧은 단어로 불러야 할지 모르겠기에 풀어서 쓰자면, 책에서는 3단계 layer를 소개하고 있으며
1.프레젠테이션 계층 : 실제 클라이언트가 사용하게 되는 서비스로 웹애플리케이션의 HTML 부분이라고 생각하면 도리 것이다.

2. 비즈니스 계층 : 비즈니스의 핵심 로직이 짜이는 구간으로 수많은 상호작용에 대해 어떤 응답을 줄지의 프로그래밍이 되어 있는 구간.

3. 데이터 접근 계층 : DB에 접근하는 작업을 이야기한다고 보면 될 것 같다. 클라이언트의 응답과 반응에 따라 내놓아야 하는 결과값이 재각각이기 때문에 이를 수행할 DB부분이고 이는 별도로 분리해서 관리하는 것이다.

이를 보고 느낀 건 MVC 같은데도 있었고 실제로 이를 바탕으로 스프링 부트도 레이어를 가진다고 소개한다.

그림 도식이 조금 복잡해 보이지만 옆을 보면 3단계의 구조에 기반해서 만들어져 있다는 것을 알 수 있다.
(3단계가 맞긴 한데...왜 저렇게 많이 나뉘느냐는 실제로 프로그래밍을 해 보면 알 수 있지만 실제 로직들은 매우 복잡하고 방대하기 때문에 이러한 개념을 가지고 각각의 기능을 나누어 놔야지 문제가 생기거나 추후 유지 보수를 할 때의 편의성을 가질 수 있기 때문이다.)

디자인 패턴.

이번 ch2의 중요한 점은 굉장히 이론적이지만 이러한 이론을 알고 이러한 이론에 기반을 두고 프로그래밍을 하기 위한 기본을 갈고 닦고, 또한 이러한 구조가 아닐 때 이러한 구조로 프로그래밍을 리팩토링 하자라는 이야기를 할 수 있는 기반이 되기 때문에 굉장히 주요하다고 생각했다.
디자인 패턴의 경우에는 GoF(Gang of Four) 패턴으로 분류한 것을 소개한다.

서적에서는 이러한 상위 의미와 하위 의미를 각각 설명해 간단하게 한줄로 소개해 두었는데 이를 바탕으로 해당 개념들을 구체적으로 학습해 나가면 좋을 것 같다. 나는 간단하게 3가지의 상위 개념만을 소개한다.

• 생성 패턴: 객체 생성에 사용되는 패턴. 객체를 수정해도 호출부가 영향을 받지 않게 한다.

• 구조 패턴: 객체를 조합해서 더 큰 구조를 만드는 패턴

• 행위 패턴: 객체 간의 알고리즘이나 책임 분배에 관한 패턴으로 객체 하나로는 할 수 없는 작업을 여러 객체를 이용해 작업을 분배. 단, 이때의 결합을 최소화하는 방식을 고려할 필요가 있다.(의존성을 낮추기 위해서)

추가적인 학습은 해당 개념을 찾아보면서 하는 게 더 효율적인데 혹여 한 번에 보고 싶은 분들을 위해 한 줄 정리 되어 있는 것도 같이 담아 두겠다.

GoF디자인 패턴

생성 패턴.
추상 팩토리: 구체적인 클래스를 지정하지 않고 상황에 맞는 객체를 생성하기 위한 인터페이스를 제공하는 패턴
빌더: 객체의 생성과 표현을 분리해 객체를 생성하는 패턴
팩토리 메서드: 객체 생성을 서브 클래스로 분리해서 위임하는 패턴
프로토타입: 원본 객체를 복사해 객체를 생성하는 패턴
싱글톤: 한 클래스마다 인스턴스를 하나만 생성해서 인스턴스가 하나임을 보장하고 어느 곳에서도 접근할 수 있게 제공하는 패턴.

구조 패턴.
어댑터: 클래스의 인터페이스를 의도하는 인터페이스로 변환하는 패턴
브리지: 추상화와 구현을 분리해서 각각 독립적으로 변형케 하는 패턴
컴포지트: 여러 객체로 구성된 복합 객체와 단일 객체를 클라이언트에서 구별 없이 다루는 패턴
퍼사드: 서브시스템의 인터페이스 집하들에 하나의 통합된 인터페이스를 제공하는 패턴
플라이웨이트: 특정 클래스의 인스턴스 한 개를 가지고 여러 개의 ‘가상 인스턴스’를 제공할 때 사용하는 패턴
프락시: 특정 객체를 직접 참조하지 않고 해당 객체를 대행(프락시) 하는 객체를 통해 접근 하는 패턴

행위 패턴
책임 연쇄: 요청 처리 객체를 집합으로 만들어 결합을 느슨하게 만드는 패턴
커맨드: 실행될 기능을 캡슐화해서 주어진 여러 기능을 실행하도록 클래스를 설계하는 패턴
인터프리터: 주어진 언어의 문법을 위한 표현 수단을 정의하고 해당 언어로 구성된 문장을 해석하는 패턴
이터레이터: 내부 구조를 노출하지 않으면서 해당 객체의 집합 원소에 순차적으로 접근하는 방법을 제공하는 패턴
미디에이터: 한 집합에 속한 객체들의 상호작용을 캡슐화하는 객체를 정의한 패턴
메멘토: 객체의 상태 정보를 저장하고 필요에 따라 상태를 복원하는 패턴
옵저버: 객체의 상태 변화를 관찰하는 관찰자들, 즉 옵저버 목록을 객체에 등록해 상태가 변할 때마다 메서드 등을 통해 객체가 직접 옵저버에게 통지하게 하는 디자인 패턴
스테이트: 상태에 따라 객체가 행동을 변경하게 하는 패턴
스트래티지: 행동을 클래스로 캡슐화해서 동저긍로 행동을 바꿀 수 있게 하는 패턴
탬플릿 메서드: 일정 작업을 처리하는 부분을 서브클래스로 캢휼화해서 전체 수행 구조는 바꾸지 않으면서 특정 단계만 변경해서 수행하는 패턴
비지터: 실제 로직을 가지고 있는 객체(visiort)가 로직을 적용할 객체(element)를 방문하며 실행하는 패턴

한 23가지의 개념이었는데 이것도 피상적인 부분이고 전체의 이해는 아니기에 꼭 추가적인 학습이 필요할 것으로 보인다. :) 위를 기반으로 살펴 보자 :)

REST API

드디어 REST가 뭔지를 알게 되었다. 가장 많이 쓰는 애플리케이션 인터페이스라고 하는데
이 인터페이스(자바 인터페이스 X)를 통해 클라이언트는 서버에 접근해 자원을 조작할 수 있다.

REST(Representational State Transfer)의 약자인데 나 같은 경우에는 WWW(World Wide Web)과 같은 하이퍼미디어 분산 시스템 아키텍처의 한 형태라는 점에서 조금 이해가 되었다.
(물론 하이퍼 미디어 분산 시스템이 뭔지는 정확히 모르지만 WWW랑 비슷한 거야! 이 부분이 '아하'의 포인트였다.)

Resource에 이름을 규정(/무어무어) 이를 URI(ur'L'아님)에 명시해 HTTP 메서드인(GET,POST,PUT,DELETE)를 통해 해당 자원의 상태를 주고 받는 것을 의미하는 것이 REST이다.

위의 설명만 보면 이해가 안 될 수 있지만 REST란 http가 가지는 4가지 형태에 정보를 주고 받는 형식의 상호작용을 할 수 있는 방식이라고 이해를 했다.

이 부분도 어느 정도 Spring을 사용하니까, 아 get, post...이런게 REST고, /~~~이런 게 resource구나를 이해한 부분이 있지만, 해당 내용은 개념 보다는 실제적인 이해가 필요한 부분이라 생각되니, 꼭 웹 개발을 해 보며 이해해 보도록 하자.
(우리가 www쓰면서 하이퍼 미디어 분산 시스템을 이해하는 건 아니니까)

REST의 특징과 설계 규칙

REST의 특징에는 5가지가 있다. 유니폼 인터페이스, 무상태성, 캐시 가능성, 레이어 시스템, 클라이언트-서버 아키텍처.

그리고 몇 가지 URL을 만드는 표준 규칙을 소개하고 이번 글을 끝마치겠다 :)

– 유니폼 인터페이스 : ‘일관된 인터페이스’를 의미. 즉 REST 서버는 HTTP 표준 전송 규약을 따르기 때문에 어떤 프로그래밍 언어로 만들어 졌느냐와 상관없이 플랫폼 및 기술에 종속되지 않고 타 언어, 플랫폼, 기술 등과 호한해 사용할 수 있다는 것을 의미.

– 무상태성 : REST는 ‘무상태성(stateless)’이라는 특징을 가진다. 무상태성이란 서버에 상태 정보를 따로 보관하거나 관리하지 않는다는 의미. 서버는 클라이언트가 보낸 요청에 대해 세션이나 쿠키 정보를 별도 보관하지 않음. 그렇기 때문에 한 클라이언트가 여러 요청을 보내든 여러 클라이언트가 각각 각각 하나의 요청을 보내든 개별적으로 처리. 이렇게 구성된 서비스는 서버가 불필요한 정보를 관리하지 않으므로 비즈니스 로직의 자유도가 높고 설계가 단순.

– 캐시 가능성 : REST는 HTTP 표준ㄴ을 그대로 사용하므로 HTTP의 캐싱 기능을 적용 가능. 이 기능을 이용하기 위해서는 응답과 요청이 모두 캐싱 가능한지(Cacheable) 명시가 필요하며, 캐싱이 가능한 경우 클라이언트에서 캐시에 저장해두고 같은 요청에 대해서는 해당 데이터를 가져다 사용. 이 기능을 사용하면 서버의 트랜잭션 부하가 줄어 효율적이며 사용자 입장에서 성능이 개선됨.

– 레이어 시스템 : REST 서버는 네트워크 상의 여러 계층으로 구성. (Layered System) 그러나 서버의 복잡도와 관계없이 클라이언트는 서버와 연결되는 포인트만 알면 됨.

–클라이언트 - 서버 아키텍처: REST 서버는 API를 제공하고 클라이언트는 사용자 정보를 관리하는 구조로 분리해 설계. 이 구성은 서로에 대한 의존성을 낮추는 기능.

-- REST의 URI 설계 규칙

URL 규칙

• URI의 마지막에는 ‘/’를 포함X.
• 단어 간의 연결을 언더바(_)를 사용하지 않고 하이픈(-)을 사용.
• URL에는 행위(동사)가 아닌 결과(명사)를 포함.
• URI는 소문자로 작성.
• URI 리소스 경로에는 대문자 사용을 피할 것.
  (일부 웹 서버의 운영체제는 리소스 경로 부분의 대소문자를 다른 문자로 인식하기 때문. 이러한 이유로 RFC3986은 URI 문법 형식을 정의하고 있는데, 호스트의 구성요소를 제외하고 URI의 대소문자를 구분해서 정의)
• 파일의 확장자는 URI에 포함X.
• HTTP에서 제공하는 Accept 헤더를 사용하는 것이 좋음.

이상으로 요번 한 주간 학습한 스프링 부트 핵심 가이드의 내용을 알아 보았다. 다음 주에도 더 많은 양을 학습하고 더 효율적으로 정리가 될 수 있으면 좋겠다!

2편 끝