[Spring] 스프링이란?

개발자로 일을 하다보면 스프링이란 단어를 많이 듣게 된다.

"백엔드는 스프링 프레임워크, 프론트엔드는 앵귤러를 이용할 계획이야."

나는 처음 스프링 프레임워크 라는 단어를 들었을때

"스프링? 용수철? 스프링 프레임워크가 뭐지?" 라는 생각을 했던것으로 기억을 한다.

간단하게 스프링(Spring Framework)을 정의내린다면 아래와 같다.

자바 엔터프라이즈 애플리케이션 개발에 사용되는   오픈소스 경량급 애플리케이션 프레임워크

■ 엔터프라이즈 애플리케이션

→ 기업과 조직의 비즈니스를 처리해주는 시스템을 의미

■ 오픈소스

→ 소프트웨어 혹은 하드웨어 제작자의 권리를 지키면서 소스가 모두에게 공개되고 , 특별한 라이선스를 취득할 필요 없이 소스를 자유롭게 열람하고 목적에 맞게 수정후 배포도 가능하다.

■ 경량급

→ 라이브러리처럼 특정 기술만 포함하고 있어 무게가 가볍다는 뜻은 아니고 이전 EJB에서 개발환경을 구성하기위해 EJB 컨테이너를 가진 WAS를 준비해야 했던것에 비해 Tomcat 이나 Jetty와 같이 단순한 서버환경을 뜻하며 자연스럽게 서버환경을 구성하기 위한 코드들이 필요없어지면서 코드량 또한 줄면서 개발과정도 단순해졌음을 의미한다.

■ 프레임워크

→ 개발을 위한 설계의 기본이 되는 뼈대나 구조 / 환경

물론 위의 설명만으로는 스프링이 무엇인지 바로 감이 오지 않을것이다.

그렇다면 스프링 프레임워크란 무엇있고 무엇을 위해 사용을 하는것일까?

 스프링의 목적 

스프링의 목적은 자바 엔터프라이즈 애플리케이션 개발을 편하게 하기 위함이다.

어떤점이 불편했기에 스프링이 탄생하게 되었을까?

■ 엔터프라이즈 개발의 복잡함

→ 말 그대로 '엔터프라이즈 시스템 개발이 너무 복잡해졌다.'라는것이다.

크게 두가지로 보면 첫번째로 기술적인 제약조건과 요구사항이 늘었기 때문이고 두번째로 엔터프라이즈 애플리케이션이 구현해야 할 핵심기능인 비즈니스 로직의 복잡함이 증가했기 때문이다.

이는 엔터프라이즈 시스템을 이용해 기업의 핵심 업무를 처리하는 비율이 늘어나며 시스템에 대한 업무 의존도가 높아지고 기능 요구사항과 업무 정책등이 바뀜에 따라 시스템의 개발과 유지보수, 추가 개발 등의 작업에 대한 부담이 커지고 그에 따른 개발의 난이도가 증가했기 때문이다.

또 이러한 복잡함을 가중시키는 원인으로는 근본적인 비즈니스 로직과 엔터프라이즈 기술이라는 두 가지 복잡함이 한데 얽혀있기 때문이다.

이 두가지를 개발자가 동시에 모두 신경써서 개발해야한다는 과도한 부담감으로 인해 전체적인 복잡함이 증가되게 된것이다.

■ 복잡함을 해결하기 위한 도전

→ 위에서 언급한 엔터프라이즈 개발의 근본적인 복잡함의 원인은 제거할 대상은 아니며 복잡함을 효과적으로 상대할수 있는 전략과 기법이 필요했기 때문에 비즈니스 로직과 엔터프라이즈 기술을 분리하는것이 목표가 되었다.

이 문제를 해결하기 위해 EJB 가 등장하였고 복잡함의 일부분은 해결되었지만 다른 큰 단점을 가지고왔다. 이는 복잡함을 해결하기 위해 EJB의 구현체를 상속받아야만 했기때문에 JAVA 자체의 장점을 잃어버렸고 다형성 적용을 근본적으로 막아버렸다.

이때 나온것이 스프링인데, 스프링은 EJB의 실패를 교훈 삼아 등장했다.

스프링은 EJB 처럼 침투적인 기술이 아닌 비침투적인 기술이라는 전략을 택했고 기술적인 복잡함과 비즈니스 로직을 다루는 코드를 깔끔하게 분리할 수 있었다.

하지만 무엇보다도 비즈니스 로직의 복잡함을 상대하는 가장 중요한 전략은 자바라는 객체지향 기술 그 자체이며 스프링은 단지 객체지향 언어의 장점을 제대로 살리지 못하게 방해했던 요소를 제거하도록 도와주는 역할을 하는것이라고 볼 수 있다.

침투적 기술 

→ 어떤 기술을 적용했을때 그 기술과 관련되 코드나 규약 등이 코드에 등장한다.

비침투적 기술

→ 기술의 적용 사실이 코드에 직접 반영되지 않는다.

 핵심기술 

■ 스프링은 톰켓을 이용할 수 있으며 코드의 경량화 그리고 개발 중에 테스트가 쉽다는 특징이 있다.

■ 경량 컨테이너로서 자바 객체를 직접 관리한다. 각각의 객체 생성, 소멸과 같은 라이프 사이클을 관리하며 스프링으로부터 필요한 객체를 얻어올 수 있다.

■ 스프링은 MyBATIS나 Hibernate 등 이미 완성도가 높은 데이터베이스 처리 라이브러리와 연결할 수 있는 인터페이스를 제공한다.

■ 스프링은 확장성이 높다. 스프링 프레임워크에 통합하기 위해 간단하게 기존 라이브러리를 감싸는 정도로 스프링에서 사용이 가능하기 때문에 수많은 라이브러리가 이미 스프링에서 지원되고 있고 스프링에서 사용되는 라이브러리를 별도로 분리하기도 용이하다.

■ POJO

→ Plain Old Java Object

→ 객체지향 프로그래밍 기법과 언어가 주는 장점인 유연한 설계와 재사용성을 활용하여 비즈니스의 복잡성과 변화를 상대함

→ 객체지향 설계(OOD, Object Oriented Design) 및 객체지향 프로그래밍(OOP, Object Oriented Programming) 원칙을 참고할 것.

■ IoC / DI

□ 제어의 역전(IoC)

→ Inversion Of Control

→ 컴퓨터 프로그램의 사용자 지정 부분(프로그래머가 작성한 소스코드)이 프레임워크의 흐름제어를 받는 디자인 패턴(필요에 따라 프레임워크가 사용자의 코드 호출)

→ 프레임워크의 일반적인 속성

→ 헐리우드 법칙

□ 의존성 주입(DI)

→ Dependency Injection

→ IoC 구현을 통해 의존관계 해결을 위한 디자인 패턴(각각의 계층이나 서비스들 간에 의존성이 존재할 경우 프레임워크가 서로 연결시켜줌)

→ 테스트 하기 용이한 구조를 유도할 수 있음

→ 스프링은 xml 설정이나 이노테이션을 통해 의존성 주입을 쉽게 할 수 있는 방법을 제공

■ AOP

→ Aspect Oriented Programming

→ 모듈성을 높일 목적으로 서로 다른 관심사를 분리(separation of cross-cutting concerns) 하는 프로그래밍 패러다임

→ 성격이 다른 로직(업무 로직과 업무 로직 외 공통적인 부분) 이 함께 있는 경우 이를 분리 해서 처리해야 복잡성을 해결할 수 있음

→ 로깅, 보안, 트랜잭션 등이 있음

■ PSA

→ Potable Sevice Abstraction

→ 개발환경과 세부 기술의 변화에 관계없이 일관된 방식으로 기술에 접근하게 해주는 기능

→ 서비스 추상화를 통해서 로우 레벨의 기술 구현 부분과 기술을 사용하는 인터페이스를 분리하고, 환경과 세부 기술에 독립적인 접근 인터페이스를 제공하면 기술적인 복잡함을 줄일 수 있음