[Spring] 스프링이 무엇이고, MVC는 무엇일까, 그리고 왜 쓸까?

Spring

 '해당 포스트는 스프링에 대한 전반적인 흐름에 대해서 알고 싶어 작성한 글입니다. 스프링에 대해서 자세하게 알고 있거나 기초적인 지식 혹은 흐름에 대해서 알고 계신 분들에게는 도움이 크게 되지 않을 수 있습니다.'

 

 스프링이란 무엇인지에 대해서 그리고 무엇을 위한 것인지 또 이에 필요한 지식은 무엇인지 알아보려고 한다. 우선 스프링은 위키피디아에서 아래와 같이 정의되어 있다.

 

 

The Spring Framework is an application framework and inversion of control container for the Java platform.

The framework's core features can be used by any Java application, but there are extensions for building web applications on top of the Java EE (Enterprise Edition) platform.

 

https://en.wikipedia.org/wiki/Spring_Framework

Spring Framework - Wikipedia

 

 위에서 말하고자 하는 것을 풀이해보면, 스프링이라는 것 자체는 '프레임 워크'라는 것이다. 프레임 워크라고 하는 것은 어떠한 구축본 혹은 뼈대와 같은 의미로 순환 혹은 해석되어 사용할 수 있다. 따라서 위에서 정의하고자 하는 의미는 스프링은 프레임워크 즉 어떠한 자바 어플리케이션의 뼈대나 구축본을 제공해 주는 역할을 한다고 볼 수 있다. 그렇다면 어떤 어플리케이션의 뼈대를 제공해 주는 것일까? 그 뒷 문장을 해석해 보면 이해할 수 있다.

 

 

there are extensions for building web applications on top of the Java EE (Enterprise Edition) platform.

 

 

 JavaEE 플랫폼 위에서 '웹 어플리케이션'을 빌드하기 위한 확장성을 제공해 준다고 나와 있다. 웹 서비스를 제공하는 것을 목표로 하는 프로젝트 혹은 프로그램에 확장성을 제공해주는 것으로 해석이 될 수 있다. 그렇다는 건 웹 개발을 위한 도구 혹은 필요한 무언가를 제공해주고 있는 것으로 볼 수 있다. 따라서 어떠한 준비절차를 따로 거칠 필요 없이 프레임워크라는 것을 통해서 즉 웹 어플리케이션을 구축하기 위해 필요한 것들을 제공받아 사용하여 프로젝트의 목표에 도달하기 위한 시간이나 효율을 높일 수 있을 것임을 짐작할 수 있다. 조금 더 풀이해 보자면 아무것도 없는 상태에서 웹 개발을 시작하게 된다면 클라이언트와의 소통을 어떻게 정의할 것이고, 어떤 요청을 어디에서 처리를 해야 하며, 이러한 기능들이 동작을 하기 위해 어떤 과정이 이루 어질지에 대한 테스트 등의 여러 가지 문제점들을 마주할 것이다. 그렇기 때문에 이러한 문제를 정의하고자 하기 전에 이러한 문제를 하고자 하는 준비과정에서부터 시간 소요가 굉장할 것으로 판단된다. 이러한 과정에 부여되는 시간들을 온전히 웹 어플리케이션의 구축을 위해 투자하는 시간으로 바꿔줄 수 있는 역할 또한 가지고 있다고 생각한다.

 

 

Spring boot

 스프링 부트는 스프링 프레임워크를 이용하여 웹 어플리케이션을 구축할 때 도움을 주는 것으로 볼 수 있다.

 

 

Spring Boot Extension is Spring's convention-over-configuration solution for creating production-grade Spring applications with minimal amounts of configuration

 

 

 스프링은 웹 어플리케이션에 뼈대를 제공해 주는 역할을 해주기 때문에 웹 개발에 필요한 확장성들을 빠르게 이용할 수 있다. 이러한 스프링을 사용하기 전에 '스프링'이라는 것 자체를 이용하기 위해서 스프링에 최소한의 구성으로 프로덕션 급의 제품을 만들 수 있기 위한 설루션이다. 이해를 돕기 위해 약간의 생각을 더해보자면 이러한 스프링 부트는 스프링을 도와 웹 어플리케이션에 필요한 설정들을 간편하게 해 주고 필요한 확장성들을 사용할 수 있도록 도와주는 역할을 하고 있다고 생각한다. 그렇기 때문에 최소한의 구성을 활용하여 프로덕션 급의 제품을 만들기 위한 설루션이라고 정의해 놓았다고 생각한다.

 

 따라서 위에서 기술한 바와 같이 웹 어플리케이션 구축을 목표로 하는 프로젝트에서 많은 웹 관련 도움을 주는 확장성들을 프레임워크 형식으로 제공받아 사용하며, 이는 시간적, 기술적 지원을 받는 것을 의미할 수 있으며 이러한 지원을 통해서 프로젝트의 목표에 빠르고 효율적으로 도달할 수 있게 해주는 것이 스프링이고 이러한 이유들로 인해 스프링을 사용한다고 볼 수 있다. 그렇다면 이제 스프링을 왜 사용해야 하고 스프링을 사용하기 위해서는 어떠한 지식이 필요할까?

 

MVC

 MVC는 Model, View, Controller들의 앞 대문자들을 따온 줄임 표현이며 개발을 위한 방법론 혹은 패턴이라고 표현한다.

 

 

The Spring Web model-view-controller (MVC) framework is designed around a DispatcherServlet

 

 

 스프링 프레임워크 공식 사이트에서 기술되어진 바, 이 스프링 프레임워크는 DispatcherServelt 중심으로 디자인되었다고 한다. 근본적인 MVC 패턴을 알아보기 위한 용도로 가져온 것이기에 디스패처가 무엇이고 Spring이 어떤 동작원리로 진행되는지는 기술하지 않고 위는 이러한 구성으로 디자인되었구나 정도로 알고 넘어가 보려 한다.

다시 본론으로 넘어와 MVC라는 건 Model, View, Controller 이 세가지 역할을 하게 되는 목적성과 책임을 지닌 패턴 혹은 방법론이다. 이는 개발을 위해서 Spring에서는 MVC를 이용하는 형식으로 동작하게 된다. 이러한 역할은 다음과 같은 특징과 책임을 지니고 있다.

 

 

Controller

컨트롤러라고 하며 이는 클라이언트라고 하는 (웹 브라우저, 앱)등과 같이 사용자의 '요청'을 처리하는 역할을 하게 된다.

또한 이러한 '요청'에 대한 '처리'를 수행하는 역할을 지니고 있는 곳에 책임을 전가시키는 행위까지 컨트롤러의 특징이다.

 

View

사용자에게 보여지는 UI(User Interface)라고 하며 어떠한 특정 목적을 지닌 페이지가 될 수 있고 크게 바라볼 때 특정 목적이 담긴 화면이라고 표현을 해본다면 클라이언트 여기서는 이용자라고 표현해서 이러한 이용자가 특정 행위를 위해 요청을 보내기 위한 수단 정도로 볼 수 있다. 간단하게 특정 목적을 위해서 사용자에게 보일 수 있는 것이라고 볼 수 있다.

 

Model

모델은 View에 대한 요청을 Controller - Service 등을 거쳐 가공이 되어진 상태에서 DB와의 소통을 통해 사용자가 원하는 데이터를 추출하는 역할을 가지고 있다고 볼 수 있다.

 

 

 크게 바라보는 관점에서 결국 클라이언트는 어떠한 요청을 하기 위해 Controller를 통해 요청을 처리해달라고 하게 되며 이러한 요청을 처리하기 위해서 Service와 같은 비즈니스 로직을 처리하는 곳을 통해 데이터를 가공하며 이렇게 가공된 요청사항을 Model에서 처리하게 되고 요청을 받은 Controller는 이렇게 가공된 데이터를 다시 전달받아 클라이언트에게 반환해 주는 흐름으로 볼 수 있다.

 

 

Controller, Service, Repository, Domain

 앞서 Controller는 사용자의 요청을 처리해주는 역할로 보이고 있다. 그리고 '요청에 대한 처리'는 Service에게 전담하게 되는데 Service가 바로 '비즈니스 로직을 처리' 하는 역할을 맡고 있다. Controller의 역할은 클라이언트의 요청을 분기하고 어떤 요청이 들어왔는지에 대해서 클라이언트와 소통을 해주는 역할로 충분하다. 따라서 이는 컨트롤러가 요청에 대한 세부적인 처리까지 담당할 필요는 없다는 것이다. 세부적인 처리를 담당하기 위한 존재가 바로 Service이며 Service에서 직접적인 사용자 요청에 대한 세부적인 처리를 담당하게 되는 것이다. 그렇다면 Service에서 비즈니스 로직을 처리하게 될 때 어떤 방식으로 이루어질지 고민해 볼 수 있다. 

 

 Service는 비즈니스 로직을 처리한다고 하였는데 비즈니스 로직을 처리한다라는게 무엇일까? 이는 이렇게 정의해 볼 수 있을 것 같다. 비즈니스 로직을 처리한다는 건 어떤 요청에 대해서 어떠한 행위를 하기 위해 정의를 내리고 행위를 이행하는 것으로 볼 수 있을 것 같다. 예를 들어 회원가입을 위한 요청을 한다고 해보자. 큰 흐름대로 살펴본다면 먼저 Controller에서 회원가입을 하고 싶다는 요청을 받게 될 것이고 이러한 요청을 처리하기 위해서 Service에게 '회원가입에 대한 요청을 처리해 주세요'라는 책임을 부여하게 된다. 그러면 Service는 이러한 요청 사항에 대해 회원가입을 어떻게 할 것인지 우선 정의하고 처리를 하게 될 텐데 이러한 과정 속에서 DTO라는 개념이 사용될 수 있다. DTO라는 것은 Data Transfer Object라고 하여 데이터 전송 객체이다. 이 데이터 전송객체의 목적은 처음 클라이언트가 Controller에게 요청을 해달라고 하면 그때 회원의 정보를 가지고 있을 '무언가'가 필요하다. 회원의 정보를 텍스트 형식으로 그냥 가지고 있는 것보다 객체지향적인 방식으로 '회원에 대한 정보'를 담고 있는 객체를 생성하여 해당 회원에 대한 정보를 일관된 규칙에 따라 정의하고 Service에게 보내거나 반환할 때 필요로 되는 일관된 데이터 집합이라고 볼 수 있다. 결국 DTO라는 것은 일관된 규칙을 정의하여 전송 간에 오해나 일반화되지 않은 규칙들의 간섭을 막기 위한 용도라고 볼 수 있을 것 같다.

 

 Repository는 DB와의 연결을 위해서 수단과 방법등을 정의해 놓은 것이라고 볼 수 있다. 이렇게 작성한 이유는 위 예제를 다시 빌려 설명해 보자면 회원의 대한 정보를 이제부터 DB에 저장을 해야 된다고 했을 때 DB에 접근하는 방법이 필요로 된다. 수동적으로 회원 정보를 받을 때마다 사람이 회원정보 객체를 보고 직접 데이터베이스에 입력하지는 않지 않은가? 그렇기 때문에 자바는 API 형식으로 DB에 접근할 수 있는 형태의 인터페이스를 제공해 주며 이를 활용하여 DB를 제어하기 위한 SQL문을 작성하며 DB에 접근하기 위해 정의된 언어를 이용하여 회원에 대한 정보를 저장하게 된다. 그럼 이때 DB를 제어하기 위한 SQL문을 작성한다는 것은 CRUD를 의미하게 되며 이러한 CRUD를 내부적으로 구현하게 만들어둔 것이 바로 Repository라고 볼 수 있다. 따라서 Repository의 역할 자체는 DB와의 연결을 위한 수단과 방법 등이 모여져 있는 것이라고 생각해 볼 수 있다. 

 

 Domain은 이러한 일관된 객체들이 모여 있는 폴더로 구성되어져 있는데 StackOverflow에서 쉽게 설명해 준 글이 있어 인용해서 작성해보려 한다.

 

 

"Usually a domain folder contains POJOs (Plain Old Java Objects). This folder basically stores classes that might or might not be entities, but follow a common structure:"

https://stackoverflow.com/questions/56964445/what-does-domain-folder-do-in-a-spring-boot-project-and-what-classes-should-be-s#:~:text=Usually%20a%20domain%20folder%20contains,getters%20and%20setters

What does domain folder do in a spring boot project and what classes should be stored there?

 

 엔티티들 혹은 엔티티가 아닌 클래스화 되어 있는 객체들을 저장하는 데 사용되는 구조 개념이라고 볼 수 있다. 엔티티에 대해서 설명을 작성하지는 않았지만 DTO와 비슷한 데이터베이스에 접근하게 되는 실질적인 객체라고 볼 수 있고 이는 해당 포스트에서는 따로 언급하지 않을 것이다. 왜냐하면 흐름에 대한 관점을 작성하는 게 목적이기 때문에 세부사항들을 최대한 다른 포스트에서 작성하려 한다.

앞서 회원을 정의하는 객체들이 바로 Domain 영역에 저장이 되어 사용된다고 볼 수 있다. 계속해서 언급을 해왔듯 일관된 규칙적인 객체들을 저장하여 회원이면 회원에 대한 일관적인 객체, 상품이면 상품에 대한 일관적인 객체 등이 바로 이러한 도메인 영역에 해당된다고 볼 수 있으며 이러한 도메인 영역들을 활용하여 비즈니스 로직을 처리를 한다고 볼 수 있을 것 같다. 

 

 

틀린 내용이 있거나 부가적인 설명이 필요로 되거나 피드백을 줄 수 있다면 적극 반영 하겠습니다 :)