[Spring] Spring 이란? Spring 특징 (IOC/DI/AOP/PSA)

Spring

스프링과 같은 프레임워크를 사용하기 전에는 왜 이 프레임워크를 사용하는지, 유사한 프레임워크와 확연하게 구분되는 특징이 무엇이 있는지 프레임워크의 개발 철학을 바탕으로 파악할 필요가 있다

스프링이란?

기본적으로 자바 플랫폼(JVM) 에서 구동되는 프레임워크이고, 보통 웹 애플리케이션을 개발하기 위해서 사용되는데 최근에는 API 서버로써 다양한 플랫폼과 연동하여 사용되는 것으로 보인다.

 

자바 위에서 작동하는 만큼 객체 지향 설계에 굉장히 용이한 구조를 갖추고 있고, 이와 더불어 개발자가 서비스 하고자 하는 애플리케이션 개발에만 집중할 수 있도록 다양한 인터페이스와 사전 정의된 객체를 제공한다.

 

Spring Container 는 Spring 만의 ApplicationContext 를 가지며, Spring 이 관리하는 객체인 Bean 의 생명주기를 결정한다.

 

Bean 의 생명주기를 결정한다?

 - Bean 으로 등록된 객체의 생성/소멸 시기를 결정한다

 - 개발자가 직접 객체를 생성하지 않고, Spring 이 결정(IOC) 하고 주입(DI) 한다

 

또한 Spring MVC 는 기존 모든 요청에 대해서 Servlet 을 생성해야하는 불편함을 덜어준다.

 

이 외에도 다양한 특징이 있으니 하나씩 알아보자

 

IOC

일반적인 자바 언어로 개발하는 환경을 생각해보면, 개발자가 작성한 객체가 언제 생성되고 소멸되는지 개발자 본인이 결정 하고, 예측가능하다. 그러나 Spring 을 사용하기 위해서는 개발자가 Spring 에게 Bean 으로 등록할 객체를 명시(선언)해주기만 하면 된다.

 

그러면 Spring 이 해당 객체가 필요한 시점에 생성해주고, 필요하지 않다면 소멸 시키는데 이와같은 일련의 활동이 개발자 입장에서는 제어권이 Spring 에게 넘어갔다고 생각하여 IOC(Inversion Of Control, 제어의 역전) 이라고 한다

 

DI

IOC 와 항상 같이 붙어나오는 개념인 DI 는 의존성 주입 이라는 처음보면 바로 와닿진 않는 의미를 가진다.

Class Diagram 을 작성할 때 객체간의 집약관계 와 합성관계를 나타낸 적이 있는데 그 중에서도 집약관계를 생각해보면 이해하기 쉽다.

 

집약관계의 특징은 A 클래스에서 사용하는 B 객체의 라이프사이클은 A 객체와 독립적이라는 것인데, 이를 통해서 클래스(또는 모듈) 와 객체간의 결합도를 느슨하게 유지한다는 장점이 있다.

 

Spring 에서는 IOC 에서 언급한 것 처럼 Spring 이 객체의 생성과 소멸을 결정하고, 개발자가 직접 클래스 내부에서 객체를 생성하지 않는 는다.

 

한 클래스가 다른 객체를 요구하는 경우에는 Spring 이 생성한 Bean 을 제공하는 방식으로 진행되는데, 이와 같은 과정을 DI(Dependency Injection, 의존성 주입) 이라고 한다

 

AOP

관점 지향 프로그래밍을 의미하는 AOP(Aspect Oriendted Programming) 는 로직을 바라 볼 때도 책임과 관심사에 따라서 코드를 분리하는 방식의 프로그래밍을 의미한다.

 

예를들어 비즈니스 로직을 구현하는 코드에 Transaction 을 관리하는 코드가 같이 존재한다면, 코드 자체가 굉장히 복잡해질 것이고 하나의 모듈이 여러가지 책임을 가진다는 것인데, 이는 개발자로 하여금 하나의 모듈을 구현하는데 복잡함을 증가시킨다는 단점이 있다.

 

실제로 Spring 을 이용해 코드를 작성하다 보면 갖가지 Annotation 을 사용하곤 하는데, Annotation 을 추가하기만 해도 개발자가 따로 코드를 작성하지 않아도 필요한 로직이 적용된다는 것을 알 수 있다.

 

Spring 은 AOP 를 위해서 Proxy Pattern 을 사용하는데, 필요한 메소드를 직접적으로 호출하지 않고 Proxy 객체를 거쳐 호출함으로써 중복되는 로직을 최소화하고, 모듈사이의 책임, 관심사 분리를 실현할 수 있다

 

위와 같은 전략을 통해서 스프링이 궁극적으로 달성하고자 하는 목표가 무엇일까?

 

PSA

Spring 탄생 이전에 보편적으로 사용하던 프레임워크인 EJB(Enterprize Java Bean) 는 애플리케이션에서 사용되는 기술을 추상화하고, 외부에서 결정, 주입하는 방식이 아닌 프레임워크에 종속된 클래스를 생성함으로써 개발자가 프레임워크에 강하게 의존하는 문제가 있었다.

 

개발자가 프레임워크와의 결합이 강하다는 것은 프레임워크에서 명시한 기술 외에는 적용하기가 매우 까다롭다는 것을 의미하고, 프레임워크 자체가 굉장히 무겁기 때문에 실 서비스 환경에서도 불리하게 작용할 수 있는 부분이 있다는 것이다.

 

반면, Spring 은 하나의 추상화 아키텍쳐를 제시하는데, 각 계층별로 수행되어야할 책임과 관심사를 표방하는 인터페이스를 제공함으로써 개발자는 특정 기술에 종속되지 않는 PSA(Portable Service Architecture, 유연한 서비스를 위한 추상화) 를 실천할 수 있다.

 

추상화 계층 아키텍쳐

Presentation Layer : Spring MVC 에서는 Controller 의 영역을 의미하고, 클라이언트의 요청을 받고 응답을 돌려주는 책임을 가지는 계층이다

 

Service Layer : 비즈니스 로직을 처리하는 영역을 의미하고, 서비스 정책에 맞춰서 검증과 연산의 책임이 있는 영역이다.

 

Data Access Layer : 실제 물리 계층(DB) 에 접근을 수행하는 책임을 가진 영역이다.

 

위와 같은 구조에서 각 영역에 종속되는 객체가 존재하고, 이를 분명히 알고 있어야지만 계층 간 독립적인 프로그래밍이 가능하다는 것을 항상 인지하고 있어야한다.

 

 

도메인 주도 설계 : 최근에 도메인 주도설계, 즉 도메인의 대표가 되는 엔티티(Aggreate Root) 간의 메세징을 지향하고 있기 때문에 서비스계층에 포함된 로직이 도메인 계층으로 옮겨가는 추세라고 한다.

 

잘못된 정보가 있다면 댓글로 알려주시면 감사하겠습니다!!