스프링(Spring)이란?

 

 

스프링 프레임워크(Spring framework)

---

스프링(Spring)이란?

한마디로 정의하면 "엔터프라이즈용 Java 애플리케이션 개발을 편하게 해주는 오픈 소스 경량급 애플리케이션 프레임워크"라고 할 수 있다. 주로 기업에서 동적인 웹 서비스를 운영하기 위해 사용된다.

 

스프링이 등장하기 이전 Java 애플리케이션애플리케이션 개발을 EJB(Enterprise Java Bean)가 담당하였다. 비즈니스 로직을 구현하기 위해 기술 자체에 대한 선수 지식이 필요했으며 구현하는 기술 자체가 복잡하고 어려웠었다. 그러나, 스프링이 탄생함으로써 이러한 문제를 해결하였고 개발 초기 기본적인 설정과 적용시킬 기술들만 잘 선택한다면 기술보다 애플리케이션 로직 자체에 집중하며 비즈니스 로직을 구현할 수 있게 된다.

 

오픈소스 & 경량급

스프링(Spring)은 오픈소스 프레임워크로 어떤 개인 및 기업도 스프링을 사용하여 웹 애플리케이션을 개발할 수 있으며, 필요하다면 스프링의 코드를 일부 수정하여 사용할 수 있다. 이로 인해 여러 사람이 프로젝트의 코드를 사용해 봄으로써 다양한 검증 과정을 거칠 수 있게 되고, 스프링의 소스 코드를 수정하거나 개선하는 일에는 스프링소스(SpringSource)라는 IT 기업에서 직접 관리하기 때문에 오픈소스의 장점 및 안정적인 개발과 개선이 보장된다. 

 

스프링은 수십개의 세부 모듈과 수십만 줄의 방대한 코드로 이뤄진 프레임워크이면서 경량급이라는 수식어가 붙는다. 이러한 이유는 스프링 이전 대신 사용하던 기술들과 비교하여, 개발자가 작성해야 할 코드가 상대적으로 단순하다는 것을 표현하기 위함이다.

💡 EJB(Enterprise Java Bean)란? 기업 환경의 시스템을 구현하기 위한 서버 측 컴포넌트 모델이다. 즉 EJB는 어플리케이션의 업무 로직을 가지고 있는 서버 애플리케이션이라고 이해하면 된다. 과거 EJB를 사용하면서 화면 로직은 JSP를 업무(비즈니스) 로직은 EJB가 담당하였다.

EJB(Enterprise Java Bean)에서 Java Bean이란 Java객체를 재사용할 수 있도록 컴포넌트화 시킨 코딩 방침을 말한다. 즉 EJB는 컴포넌트들을 관리하는 컨테이너라고 생각하면 된다.

엔터프라이즈 자바빈즈 - 위키백과, 우리 모두의 백과사전

 

---

 

EJB(Enterprise Java Bean)는 무엇이 문제였을까?

---

EJB(Enterprise Java Bean)는 보안, 트랜잭션, 분산 컴퓨팅 등 여러 기능을 제공하였으나, 이를 사용하기 위해 EJB 고유의 스펙을 지켜야 했으며, 실제 구현하는 비즈니스 로직보다 EJB 컨테이너를 사용하기 위한 코드가 많아 배보다 배꼽이 더 큰 문제를 가졌다. 이러한 원인은 비즈니스 로직에 특정 기슬이 컨테이너 안에 종속되어 있는 객체 구조를 가졌기 때문이다. 객체 지향 언어 Java를 사용함에도 불구하고 EJB를 사용하면 객체 지향을 지킬 수 없는 문제가 발생한다.

 

이러한 문제로 스프링의 창시자 로드 존슨은 EJB를 사용하지 않고도 객체 간 의존성 해결이 가능한 컨테이너를 개발하였고 이것이 스프링의 시작이자 현재 사실상 표준 기술이다. 즉 특정 기술에 종속되지 않고 객체를 관리할 수 있는 컨테이너를 제공하는 것이 스프링의 철학이다.

 

---

 

POJO(Plain Old Java Object)

---

스프링은 POJO 프로그래밍을 지향한다. POJO란? Plain Old Java Object로 순수 Java 만을 통해서 생성한 객체를 의미한다. 즉 Java 및 Java의 스펙에 정의된 기술 만을 사용한다는 의미이며, 어떠한 외부 라이브러나 외부 모듈을 사용하지 않는다.

 

POJO

 

만약 순수 Java 객체가 아닌 외부 라이브러리를 통해 생성된 객체가 있다고 가정해보자 이때 더욱 개선된 기존 기술의 등장과 관련된 코드를 변경해야 하는 상황이 발생된다면 해당 외부 라이브러리를 사용하고 있는 모든 객체들의 코드를 전부 바꿔주어야만 한다. 이는 해당 객체가 외부 라이브러리에 의존하고 있기 때문에 발생되는 문제이다.

 

반면 POJO는 순수 Java만을 사용하기 때문에 특정 기술이나 환경에 종속적이지 않다는 장점을 가진다. 덕분에 외부 기술과 규약의 변화에 얽매이지 않아 어느 상황에도 유연한 변화와 대처를 할 수 있게 된다. 또한 POJO를 사용함으로써 객체 지향 설계를 제한 없이 적용할 수 있으며, 코드가 단순해져 디버깅 또한 쉬워진다. 이처럼 순수 Java를 활용하는 프로그래밍을 POJO 프로그래밍이라고 한다.

💡 프레임워크 vs 라이브러리 차이
내가 작성한 코드가 직접 제어하냐 안 하냐의 차이로 볼 수 있으며, 나를 대신해서 제어하고, 실행하면 프레임워크이다. 반면 내가 작성한 코드가 직접 제어한다면 그것은 프레임워크가 아니라 라이브러리이다.

 

---

 

DI(Dependency Injection) 의존관계 주입 & IoC(Inversion of Control) 제어의 역전

---

DI(Dependency Injection)이란 스프링이 다른 프레임워크와 차별화되는 의존관계 주입 기능이다. 객체를 구체화시켜 직접 생성하는 것이 아닌 추상화를 통해 외부에서 주입시켜주는 방식으로 DI를 통해 모듈 간의 결합도(coupling)가 느슨해지고 유연성이 높아진다는 장점이 있다.

 

IoC(Inversion of Control)란 메서드나 객체의 호출 작업을 개발자가 결정하는 것이 아니라 외부에서 결정되는 것을 의미한다. 객체의 의존성을 역전시켜 객체 간의 결합도(coupling)을 줄이고 유연한 코드를 작성할 수 있게 하여 가독성 및 코드 중복, 유지보수를 편하게 할 수 있게 한다.

 

 

이해를 위해 다음과 같은 주문 서비스가 있으며, 정액 할인 정책(FixDiscountPolicy)이 적용되어 있다고 하자.

public class FixDiscountPolicy {
    ...
}

public class OrderService {
    private final FixDiscountPolicy discountPolicy = new FixDiscountPolicy();
    
    public void businessMehtod() {
    	...
    }
}

그러나 기획에서 추가 요구사항이 발생되었고 정액 할인 정책(FixDiscountPolicy) 대신 정률% 할인 정책(RateDiscountPolicy)으로 변경해야 한다. 기존에 정액 할인 정책에서 정률% 할인 정책으로 바꿔야 한다면 다음과 같을 것이다.

public class RateDiscountPolicy {
    ...
}

public class OrderService {
    // 기존 FixDiscountPolicy를 제거 후, RateDiscountPolicy로 변경
    // private final FixDiscountPolicy discountPolicy = new FixDiscountPolicy();
    private final RateDiscountPolicy discountPolicy = new RateDiscountPolicy();
}

위와 같이 discountPolicy는 구체 클래스를 의존하고 있으며, 요구사항이 바뀌면 매번 코드를 변경해야 하는 문제가 발생된다. 만약 하나의 서비스에만 변경한다면 큰 문제없이 변경할 수 있겠으나, 실무에서의 비즈니스 로직은 단순하지 않기 때문에 무수히 많은 코드를 변경해야하는 문제가 초래할 수 있다.

 

이러한 문제를 DI & IoC를 통해 어떻게 해결하는지 보자.

DiscountPolicy를 인터페이스로 만들어, 구체 클래스 FixDiscountPolicy, RateDiscountPolicy 상속하여 다형성을 적용한 후, 애플리케이션 동작 방식을 구성하기 위한 설정을 위해 AppConfig 객체를 따로 생성한다.

public interface DiscountPolicy {
    ...
}

public class FixDiscountPolicy implements DiscountPolicy {}
public class RateDiscountPolicy implements DiscountPolicy {}

public class OrderService {
    private final DiscountPolicy discountPolicy;
    
    public OrderService(DiscountPolicy discountPolicy) {
        this.discountPolicy = discountPolicy;
    }
}

public class AppConfig {
    public OrderService orderService() {
        return new OrderService(new RateDiscountPolicy());
    }
    ...
}

AppConfig를 통해 구체 클래스를 얻음으로써 인터페이스에만 의존할 수 있게 되었다. 덕분에 할인 정책을 변경하든 또 다른 할인 정책이 추가되어도 DiscountPolicy의 인터페이스를 상속 받은 구체 클래스를 만들어 AppConfig에 넣어주면 된다. 결과적으로 OrderService는 변경하지 않고도 할인 정책을 유연하게 변경할 수 있게되었다.

 

이제 위의 코드를 실행하는 코드를 간략히 구현해 보자.

public class OrderApp {
    public static void main(String[] args) {
        // AppConfig 생성
        AppConfig appConfig = new AppConfig();
        OrderService orderService = appConfig.orderService();
        
        // OrderService 비즈니스 로직 실행
        orderService.businessMehtod();
    }
}

기존 프로그램은 구현 객체가 스스로 필요한 객체를 직접 생성하고, 연결하고, 실행했다. 즉 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 반면 AppConfig가 등장한 이후 프로그램의 제어 흐름은 AppConfig가 가져가게 되었고, 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. 

 

OrderService는 필요한 할인 정책(DiscountPolicy)을 호출하지만 어떤 구현 객체가 실행될지 모른다. 프로그램에 대한 제어 흐름에 권한은 모두 AppConfig가 가지고 있으며 심지어 OrderService 또한 AppConfig가 생성한다. OrderService는 이러한 사실조차 모른 채 묵묵히 자신의 로직을 실행할 뿐이다.

 

이렇듯 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 의존 관계를 맺어주는 것을 제어의 역전(Ioc)이라 하며, 그 과정에서 DiscountPolicy를 AppConfig를 통해 주입해 주는 것을 의존관계 주입(DI)라고 한다.

 

---

 

AOP(Ascpect Oriented Programming) 관심 지향 프로그래밍

---

AOP(Ascpect Oriented Programming)란 어떤 로직을 기준으로 핵심 관심 사항과 공통 관심 사항을 나눠 그 관점을 각각 모듈화 하는 것을 의미한다.

 

예를 들어 핵심 관심 사항은 애플리케이션의 핵심 기능과 관련된 사항으로, 쇼핑몰로 예를 들면 주문하기, 장바구니 담기, 배송지 설정하기 등등이 있을 것이다.

 

반면, 공통 관심 사항은 모든 핵심 관심 사항에서 공통적으로 적용되는 관심 사항들을 의미한다. 주문하기, 장바구니 담기, 배송지 설정하기 등 모든 핵심 관심 사항에는 로깅이나 데이터 저장 등등이 공통적으로 적용되어야만 한다. 즉 핵심 관심 사항과 공통 관심 사항 코드는 필연적으로 공통 관심 사항과 관련된 코드가 중복될 수밖에 없다.

 

이처럼 중복되어 있는 경우 공통 관심 사항을 수행하는 로직이 변경된다면 모든 공통 관심 사항 코드를 일일이 변경해 줄 수밖에 없을 것이다.

class ShoppingApp {
    public void 주문하기() {
        // 공통 관심 사항
        로깅 코드 
        보안 코드

        // 핵심 관심 사항
        주문 코드
    }

    public void 장바구니_담기() {
        // 공통 관심 사항
        로깅 코드 
        보안 코드

        // 핵심 관심 사항
        장바구니 담기 코드
    }

    public void 배송지_설정() {
        // 공통 관심 사항
        로깅 코드 
        보안 코드

        // 핵심 관심 사항
        배송지 설정 코드
    }
}

위 코드처럼 코드의 중복이라는 문제를 해결하기 위해 공통 관심 사항과 관련된 기능들을 객체로 분리해 낸 다음, 분리가 된 객체의 메서드를 통해 공통 관심 사항을 구현한 코드를 실행시켜야 한다.

 

AOP

 

이처럼 애플리케이션 전반에 걸쳐 적용되는 고통 기능을 비즈니스 로직으로 분리한 것을 AOP(Aspect Oriented Programing)이라고 한다. 스프링의 AOP 개념은 다음 포스팅에서 구체적으로 다루고자 한다. 지금까지는 이러한 개념이 있다고만 이해하기로 하자.

 

---

 

PSA(Portable Service Abstaction) 일관된 서비스 추상화

---

스프링은 Java 백엔드 개발에 있어 핵심적인 역할을 수행하는 프레임워크로, 백엔드 개발에서 데이터베이스는 떼어놓을 수 없을 만큼 중요하다. 웹 애플리케이션 서버는 데이터베이스와 소통하며 웹 클라이언트의 요청을 처리하기 때문이다.

 

데이터베이스의 종류는 다양하며 MySQL, Oracle, Maria DB, Mongo DB 등등이 있다. 또한 각각의 데이터베이스는 자기 만의 고유의 명령어를 가지고 있기 때문에 서로 사용하는 방법이 조금씩 다르다. 

 

만약 IT 서비스 회사에서 데이터베이스를 MySQL로 사용하다 데이터를 저장하는 양이 많아져 Oracle로 데이터베이스를 변경해야 하는 상황이 발생한다면 어떻게 될까? 앞서 말한 것처럼 데이터베이스마다 사용하는 방법이 다르기 때문에 일일이 모든 코드를 수정해야 하는 상황이 생긴다면 개발자 입장에선 최악의 시나리오일 것이다. 

 

그러나 스프링은 이를 위해 데이터베이스 서비스를 추상화한 인터페이스를 제공한다. 스프링은 데이터베이스에 접근하는 방법을 인터페이스를 통해 통일시켰으며, 이를 JDBC(Java DataBase Connectivity)라고 한다. 

 

각 데이터베이스를 만든 회사들은 자신의 데이터베이스에 접근하는 드라이버를 Java 코드의 형태로 배포하는데, 이 드라이버에 해당하는 Java 코드의 클래스를 JDBC가 구현한다. 덕분에 JDBC를 기반으로 데이터베이스가 바뀌어도 코드를 변경할 필요 없이 데이터베이스에 접근하여 사용할 수 있다.

JDBC

이러한 JDBC처럼 특정 기술과 관련된 서비스를 추상화하여 일관된 방식으로 사용될 수 있도록 한 것을 PSA(Portable Service Abstaction)이라고 한다.

---

스프링 핵심 원리 - 기본편 강의 - 인프런

[Spring] DI, IoC 정리

[JDBC] JDBC란?

[Spring] POJO란 무엇인가?

AOP란? 관점 지향 프로그래밍의 원리