[Spring] 스프링 프레임워크의 정의/특징/동작원리

이번에는 웹 개발에 있어 Legacy하지만 널리 쓰이고 있는 Spring Framework에 대하여 알아보았다.

0. Framework VS Library

• Framework란?
  프레임워크란 소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 일련의 협업화된 형태로 클래스들을 제공하는 것을 말한다.
• Library란?
  라이브러리란 자주 사용되는 로직을 재사용하기 편리하도록 잘 정리한 일련의 코드들의 집합을 의미한다. (참고: 생활코딩)
• 둘의 차이점은?
  라이브러리는 개발자가 모든 개발의 흐름을 제어한다. 개발자가 주가 되어 필요한 기능을 호출하고 능동적으로 사용하는 데에 반해 프레임워크는 개발자가 아닌 프로그램이 흐름을 제어한다는 데에 있다. 한마디로 프로그램의 주도성이 누구에게 있는가의 차이이다.

1. Spring Framework란?

자바 플랫폼을 위한 오픈소스 어플리케이션 프레임워크로서 엔터프라이즈급 어플리케이션을 개발하기 위한 모든 기능을 종합적으로 제공하는 경량화된 솔루션이다.

엔터프라이즈급 개발이란 뜻대로만 풀이하면 기업을 대상으로 하는 개발이라는 뜻이다. 즉, 대규모 데이터 처리와 트랜잭션이 동시에 여러 사용자로 부터 행해지는 매우 큰 규모의 환경을 엔터프라이즈 환경을 뜻한다.

2. Spring Framework의 특징

아래에는 Spring Framework의 여러가지 특징을 대략적으로 소개했다. 각 특징의 자세한 내용은 추가적인 포스팅을 통해 집중적으로 다룰 계획이다.

• IoC ( Inversion of Control ) : 제어의 역행
  제어의 주체가 개발자가 아닌 프레임워크라는 뜻으로 때에 따라 프레임워크가 작성된 코드를 호출하는 기술. 객체의 생명주기의 관리까지 모든 객체에 대한 제어권을 프레임워크가 가진다.

• DI ( Dependency Injection ) : 의존성 주입
  의존성 객체를 개발자가 생성하지 않고 클래스를 Bean으로 등록해놓으면 Bean으로 등록된 객체를 프레임워크가 찾아서 알아서 주입해주는 기술이다. 이를 통해 모듈간의 결합도를 낮출 수 있다.

• AOP ( Aspect Oriented Programming ) : 관점 지향 프로그래밍
  각 코드마다 공통된 관심사를 분리하여 모듈화하는 프로그래밍 기법.
  객체지향적으로 프로그래밍을 했음에도 로그, 트랜잭션, 성능확인 등 공통적인 관심사가 중복되는 문제점을 해결하기 위해 프록시 패턴을 사용하여 코드를 분리하여 관리하는 기술dlek.

• PSA ( Portable Service Abstraction ) : 추상화를 통해 코드가 간결해진다.
  POJO 프로그래밍을 지원하기 위해 다양하게 구현되어있는 인터페이스를 같은 방식으로 사용하도록 중간에 인터페이스 어댑터 역할을 해주는 레이어를 추가하는 방법이다. 실제로 일일이 구현을 해줘야 되는 것들을 스프링이 다 구현해놓고 어노테이션으로 만들어 놓아 어노테이션만 선언하면 내부적으로 다 동작이 되도록 추상화 한 것이다.

• POJO : Plane Old Java Object (순수 자바 객체)
  EJB 등에서 사용되는 Java Bean이 아닌 멤버 변수와 Getter와 Setter로 구성된 가장 순수한 형태의 기본 클래스이다.
  "POJO는 getter 와 setter를 가진 단순한 자바 오브젝트"가 아니라 "getter와 setter를 가진 가장 단순한 자바 오브젝트는 POJO"다.

3. MVC 디자인 패턴

MVC는 Model, View, Controller의 약자로, 클라이언트와 상호작용하는 소프트웨어를 설계함에 있어 세가지 요소로 나누어 설계하는 것을 말한다.

3.1) Model
Model은 애플리케이션의 정보, 데이터의 가공을 책임지며 데이터베이스와 상호작용하여 비즈니스 로직을 처리하는 모듈. 즉, 컴포넌트를 말한다.
Model은 아래와 같은 규칙을 가지고 있다.

• 사용자가 이용하려는 모든 데이터를 가지고 있어야 한다.
• View(뷰) 또는 Controller(컨트롤러)에 대해 어떤 정보도 알 수 없어야 한다.
• 변경이 일어났을 때 처리 방법을 구현해야 한다.
• 모델은 재사용이 가능해야 하며 다른 인터페이스에서도 변하지 않아야 한다.

3.2) View
View는 클라이언트 단에서 보여지는 결과화면을 반환하는 모듈. 즉, 사용자 인터페이스 요소를 말하며 아래와 같은 규칙들을 가지고 있다.

• Model(모델)이 가지고 있는 데이터를 저장하면 안된다.
  - Model(모델)이나 Controller(컨트롤러)에 대한 정보를 알면 안된다.
• 데이터를 받아 단순히 화면에 표시해주는 역할만 가진다.
• 재사용이 가능하게끔 설계를 해야 하며 다른 정보들을 표현할 때 쉽게 설계해야 한다.

3.3) Controller
Controller는 client로부터 request가 들어왔을 때 그 입력을 처리하고 어떤 로직을 실행시킬 것인지 Model(모델)과 View(뷰)를 연결해주며 제어하는 모듈을 말한다. Controller는 아래와 같은 규칙들을 가지고 있다.

• Model(모델) 또는 View(뷰)에 대한 정보를 알아야 한다.
• Model(모델) 또는 View(뷰)의 변경을 인지하여 대처를 해야한다.
• 모델이나 뷰의 변경 통지를 받으면 이를 해석해서 각각의 구성 요소에게 통지를 해야 한다.
• 애플리케이션의 메인 로직을 담당한다.

MVC는 크게 MVC1, MVC2 두 가지로 나눌 수 있는데 둘의 가장 큰 차이는 클라이언트의 요청 사항을 모듈화되지 않은 하나의 파일로 처리할 것이냐, 아니면 각각의 기능을 담당하는 모듈들이 역할을 분담해서 처리할 것이냐로 결정된다.

• MVC1 Pattern
  
  MVC1 구조는 위 그림과 같이 클라이언트의 요청 사항을 하나의 모듈이 담당한다. JSP가 Controller와 View의 기능을 동시에 맡아서 하며 JSP 페이지에 비지니스 로직을 처리하기 위한 코드와 웹 브라우저에 결과를 보여주기 위한 출력 관리 코드가 뒤섞여 있는 구조이다.

• MVC2 Pattern
  
  MVC2는 MVC1의 단점을 보완하기 위해 나온 디자인 패턴이다. 위 그림과 같이 기존에 뷰와 컨트롤러의 역할을 모두 수행하던 JSP는 뷰의 역할만 하게 하고, 대신 컨트롤러 역할을 Servlet이 수행한다. MVC1에서는 JSP가 클라이언트의 요청을 받아줬는데 MVC2에서는 컨트롤러 역할을 수행하는 Servlet이 클라이언트의 요청을 받아준다. Servlet이 비즈니스 로직을 수행하며 모델을 호출하여 데이터를 요청하며, 최종적으로 뷰 역할인 JSP 페이지로 포워딩하여 화면에 출력한다.

4. Spring Framework의 동작 원리

1. DispatcherServlet
애플리케이션으로 들어오는 모든 Request를 받는 부분. Request를 실제로 처리할 Controller에게 전달하고 그 결과값을 받아서 View에 전달하여 적절한 응답을 생성할 수 있도록 흐름을 제어한다.

2. HandlerMapping
Request URL에 따라 각각 어떤 Controller가 실제로 처리할 것인지 찾아주는 역할을 한다.

3. Controller
Request를 직접 처리한 후 그 결과를 다시 DispatcherServelt에 돌려준다.

4. ModelAndView
Controller가 처리한 결과와 그 결과를 보여줄 View에 관한 정보를 담고 있는 객체이다.

5. ViewResolver
View 관련 정보를 갖고 클라이언트에게 포워딩할 실제 View 파일을 찾아주는 역할을 한다.

6. View
Controller가 처리한 결과값을 보여줄 View를 생성한다.

Spring Framework의 동작원리는 위와 같이 기본적으로 MVC2의 구조를 따른다. 하지만 이러한 동작 원리 및 흐름에 대해 몰라도 Spring Framework에서 제공하는 기본적인 어노테이션 사용법만 익혀서 사용하면 서버를 구현하는데 어려움이 없고, 대부분의 기능은 수년간 이미 다 구현되고 확장되었기에 스프링에 기능자체가 없어서 직접 구현할일은 거의 없다.

하지만, 이런 내부 로직과 흐름에 대해 이해하는 것은 프로젝트에 문제가 생겼을 때 디버깅을 하는 과정에서 상당한 도움이 되므로 매우 중요하다.