[Spring] Spring이란?

koline·2023년 12월 18일

Spring

목록 보기

1/15

Spring

Spring은 Java의 대표적인 경량급 애플리케이션 프레임워크이다. 스프링 이전에 주로 사용되던EJB(Enterprise Java Bean)라는 Java EE의 API의 여러 문제점(비용, 개발의 복잡함, 느린 속도)을 해결하고자 개발되었다.

국내에서 Java의 강세를 생각하면 개발자라고 하면 대부분 스프링을 사용해봤을 확률이 높다. 하지만 스프링이라는 프레임워크 자체가 워낙 방대하고 애플리케이션의 전역을 커버하는 기능이 많다보니 막상 스프링으로 개발을 하더라도 '스프링이 무엇인가'라는 질문에 답하기가 쉽지 않을 수 있다.

경량급 애플리케이션 프레임워크

스프링의 소개를 보면 두 단어가 가장 눈에 띈다.

1. 애플리케이션 프레임워크

웹 계층을 MVC 구조로 손쉽게 만들 수 있는 기능, 포맷과 출력장치를 유연하게 변경할 수 있는 로그 기능, 간단한 설정만으로 관계형 DB와 자바오브젝트를 매핑해주는 ORM 기술 등 애플리케이션의 특정 계층이나 한가지 기술에 집중하는 라이브러리나 프레임워크와 달리 애플리케이션 계층 전역의 개발을 더 간편하고 효율적이게 개발할 수 있도록 해준다.

즉, 스프링은 API 개발, Spring MVC를 이용한 애플리케이션 개발, DB 연결 등 개발의 특정 부분을 위한 프레임워크가 아닌 이 모든 것을 더 쉽고 편하게 할 수 있도록 해주는 프레임워크로써 각 개발 단계를 위한 라이브러리나 기능 등을 제공한다.

2. 경량급 프레임워크

또한 눈에 띄는 단어중 하나는 '경량급'이라는 것인데, 스프링을 사용해보면 알 수 있듯이, 결코 프레임워크 자체는 가볍지 않고 오히려 무거운편이라는 것을 알 수 있다. 그럼에도 불구하고 스프링을 소개할 때 '경량급' 이라는 단어를 쓰는 이유는 스프링 이전에 사용하던 EJB에 비해 훨씬 가볍기 때문이다.

EJB는 기술에 대한 과도한 욕심으로 인해 개발환경과 운용서버, 개발과 빌드, 테스트 과정, 작성된 코드 모두를 매우 무겁고 복잡하게 만들었고, EJB가 동작하려면 고가의 느리고 무거운 자바 서버(WAS)가 필요했다. 또한 툴의 도움 없이는 다루기 힘든 난해한 설정파일 구조와 까다로운 패키징, 불편한 서버 배치(deploy) 등으로 인한 부담 때문에 고가의 제품으로 구성된 제대로 된 개발환경을 갖추지 않고는 개발하기가 힘들었다.

그에 반해 그에 반해 스프링은 가장 단순한 서버환경인 톰캣(Tomcat)이나 제티(Jetty)에서도 완벽하게 동작한다. 단순한 개발툴과 기본적인 개발환경으로도 엔터프라이즈 개발에서 필요로 하는 주요한 기능을 갖춘 애플리케이션을 개발하기에 충분하다.

즉, EJB에 비해 훨씬 간소화된 설정과 환경만으로도 비슷한 수준의 개발환경과 기술을 사용할 수 있기 때문에 품질과 생산성 향상에 도움이 된다.

스프링의 3대 요소

1. DI (Dependency Injection, 의존성 주입)

스프링은 IoC/DI 프레임워크라고 불릴 정도로, 의존성 주입은 스프링에서 정말 매우 중요한 개념이다. 여기서 말하는 IoC란 Inversion of Control의 줄임말로 제어의 역전이라는 뜻이다. 객체지향 프로그래밍 언어인 Java에서 객체간의 의존성을 어떻게 설정해주는 지는 프로그래밍에서 매우 중요한 부분이다. 아래의 코드를 보자.

public class Snack {
}

public class Store {
	private Snack snack;
    
    public Store() {
    	this.snack = new Snack();
    }
}

Store (상점) 객체는 Snack (과자) 객체를 사용하고 있다. 이러한 상황을 '상점 객체가 과자 객체에게 의존한다/의존성이있다'라고 말한다. 위 코드의 문제는 무엇일까? 바로 객체간의 의존관계가 아닌 클래스간의 의존관계가 맺어졌다는 것이다.

이런 의존관계의 문제점은 예를 들어 과자 클래스의 코드에 변경이 생겼다고 가정해보자. 그렇다면 상점 클래스의 코드의 변경도 불가피할 것이다. 상점클래스에 의존하는 다른 클래스 또한 변경되어야 할 것이고, 연쇄적으로 하나의 변경이 매우 큰 범위의 변경으로 번질 것이다. 이러한 코드를 결합도가 높다라고 한다.

그 뿐만이 아니라 상점이 과자가 아닌 다른 제품을 판매하게 된다면 그 때에 맞춰서 코드를 매번 변경해야 할 것이다.

그렇다면 코드를 어떻게 변경하면 좋을까?

public class Food {
}

public class Snack extends Food {
}

public class Drink extends Food {
}

public class Store {
	private Food food;
    
    public Store(Food food) {
    	this.food = food;
    }
}

이 코드에서는 Store (상점) 클래스는 더이상 특정 클래스에 의존하지 않는다. 그리고 생성자를 통해 의존성을 주입받게 되므로 어떤 객체와 의존관계를 맺을 지가 클래스 외부에서 결정되게 된다. 이렇게 되면 실행 중에 동적으로 필요한 객체와 동적으로 할당되어 더 간결하고 유연한 코드를 작성할 수 있다.

그렇다면 저 Store 객체는 Food를 상속받는 어떤 객체에 의존하게 될까? 그것은 스프링 내의 IoC 컨테이너가 결정하고 동적으로 할당하게 된다. 즉 제어권이 프로그래머에서 프레임워크로 넘어가는 제어의 역전이 발생한다.

더 간단하게 말하자면, 스프링이 실행될 때 스프링은 애플리케이션 내의 클래스들을 Bean의 형태로 DI 컨테이너에 저장해둔다. 그리고 위의 Store객체의 생성자에 어노테이션을 달아 놓으면(DI 방식이나 어노테이션의 종류는 다양하다) 필요한 객체를 꺼내서 동적으로 할당해 주는 것이다. 그러므로 개발자는 프로그램 작성 시, 객체의 생성이 아니라 실행 로직만 작성하게 되고 객체의 할당에 대한 제어는 스프링이 담당하게 된다.

동시에 개발자는 훨씬 유연하고, 재사용성이 높고, 유지보수 및 테스트가 용이하고 결합도가 낮은 코드를 작성할 수 있게된다.

2. AOP (Aspect Oriented Programming, 관점 지향 프로그래밍)

관점지향 프로그래밍이란 코드를 특정 관점에서 보는 방식으로 프로그래밍하는 것을 말한다. 예를 들면, HTTP 요청이 들어와서 해당 URI와 맵핑된 컨트롤러 메소드의 처리가 이뤄지기 전에 해당 기록을 로그로 남기려고 한다고 가정해보자. 모든 컨트롤러의 메소드마다 로그를 남기는 로직을 작성해야 할 것이다. 스프링의 AOP는 이 관점(Point)을 잘라서(Cut) 해당 시점에 처리될 로직을 작성할 수 있다.

AOP를 사용하면 개발자는 애플리케이션의 각 부분에 공통적으로 들어가는 내용을 독립적으로 모듈화하여 책임을 분리하고 코드를 깔끔하게 유지할 수 있게 해준다.

3. PSA (Portable Service Abstraction, 서비스의 추상화)

스프링을 사용해본 개발자라면 서비스를 추상화하여 인터페이스로 소통을하는게 당연하게 받아들여질 것이다.

서비스를 추상화하는 이유는 추상화 계층을 통해 서버 또는 개발환경에 종속되지 않도록하고, 내부에 비즈니스 로직을 숨겨 개발자에게 편의성을 제공하기 위함이다. 이것은 SOLID 개발 원칙중 OCP (개방 폐쇄 원칙)에 해당한다.

예를 들어, 컨트롤러 메소드를 HTTP 요청과 맵핑시키기 위해 어노테이션(@GetMapping, @PostMapping 등)을 사용하거나 서비스 계층에서 트랜잭션 관리를 위해 흔히 사용하는 @Transactional 어노테이션의 처리 로직 또한 추상화를 통해 내부 처리 로직의 복잡함을 감춰져 있기 때문에 간편하게 어노테이션으로만 사용할 수 있는 것이다.