이제껏 개발자로 살아오면서 Spring을 주력 프레임워크로 사용하고 있다.
그런데 문득 나는 Spring에 대해서 얼마나 알고 있는 걸까? 라는 생각이 들어서 나름대로 점검을 해보았는데 처참했다.
Spring은 무엇인지, 왜 만들어졌는지, 어떤 기능을 제공하는지, 동작 원리는 어떻게 되는지와 같은 기본적인 질문들에 제대로 된 답변을 할 수 없었다.
그래서 Spring을 사용하는 개발자가 갖추어야할 기본 지식들을 배우고 고민한 내용을 기록하는 시간을 가지려고 한다.
무엇을 학습할지 정리해보니 다음과 같은 주제를 생각해낼 수 있었다.
정의: Spring이란 무엇인가?
배경: Spring은 어떻게 탄생했을까?
필요성: Spring은 어떤 기능을 제공할까?
핵심 요소: Spring에서 DI나 AOP와 같은 핵심 요소는 무엇이 있을까?
동작 원리: Spring은 어떻게 동작하는 걸까?
이제 위 주제대로 공부하고 고민한 내용을 공유할 것이다. 이번 글에서는 Spring의 정의 및 탄생 배경, 필요성에 대해서 이야기하려 한다.
Spring 공식인 spring.io에서 Spring에 대해서 살펴보았다.
해당 페이지에서 아래와 같은 문구가 한 눈에 띄었다.
🍃 Why Spring?
Spring makes programming Java quicker, easier, and safer for everybody. Spring’s focus on speed, simplicity, and productivity has made it the world's most popular Java framework.
Spring은 누구나 더 빠르고, 쉽고, 안전하게 Java로 프로그래밍할 수 있도록 돕는다. 또한, Spring은 속도, 단순성, 생산성에 중점을 두어 전 세계적으로 가장 대중적인 Java Framework이다.
이 문구를 번역해보면 Spring은 Java 진영에서 대중적인 프레임워크 중 하나임을 알 수 있다.
기본적으로 Framework(프레임워크)란 어떠한 목적을 달성하기 위해 복잡하게 얽혀있는 문제를 해결하기 위한 구조를 의미한다.
그렇다면 Spring을 사용한다는 것은 Spring Framework를 사용한다는 것과 동일한 걸까? 관련된 내용을 위키백과에서 찾을 수 있었다.
스프링 프레임워크(Spring Framework)는 자바 플랫폼을 위한 오픈 소스 애플리케이션 프레임워크로서 간단히 스프링(Spring)이라고도 한다.
결국 Spring Framework를 줄여서 Spring으로 부른다는 것이기에 Spring(스프링)과 Spring Framework(스프링 프레임워크)는 같은 의미라고 볼 수 있다.
Spring에 대해서 많이 알려지고 흔하게 접할 수 있는 정의는 다음과 같다.
Java 엔터프라이즈 개발을 편하게 할 수 있도록 도와주는 오픈소스 경량급 애플리케이션 프레임워크
이러한 스프링의 정의를 보고 궁금한 점들이 생겼다.
궁금증을 해결하기 위해 스프링의 정의를 하나씩 구체적으로 들여다보자.
Java 진영에서 Spring 뿐만 아니라 다양한 프레임워크들이 있었을 텐데 그들이 제공하는 개발 방식과 Spring이 제안하는 개발 방식에 어떤 차이가 있길래 Spring이 Java 엔터프라이즈 개발을 편하게 해준다고 당당하게 말할 수 있었을까?
Spring은 엔터프라이즈 개발의 복잡성을 걷어내고 보다 편하게 개발할 수 있는 본질적인 솔루션을 제공한다. 이 것이 기존 기술이나 프레임워크와 차별성을 두는 Spring의 개발 접근 방법이 된다.
그래서 Spring은 이전 기술에 비해 상대적으로 덜 복잡하기에 도입할 기술에 신경쓰기보다 애플리케이션의 비즈니스 로직 자체에 집중할 수 있게 해준다.
무엇보다 Spring이 위와 같이 말하는 이유 중 큰 이유는 다양한 필수 요구사항을 만족시켜줌과 동시에 개발하는 데 어렵고 복잡한 부분을 덜어준다는 점이다.
Spring이 어떻게 개발을 편하게 도와주는지는 뒤에서 이야기 하도록 하겠다.
오픈소스란 소스코드를 모두가 확인할 수 있고, 특별한 정책 및 허가 없이 자유롭게 사용해도 무방하다는 의미이다.
Spring Framwork 프로젝트에서 확인할 수 있듯이 Spring은 오픈소스 프로젝트 방식으로 개발되어 왔음을 알 수 있다. 이로 인해, Spring은 개인이나 기업 모두가 무료로 Spring을 통해 웹 애플리케이션 개발을 할 수 있도록 해주며, 필요할 경우 Spring의 일부를 변경해서 사용해도 무방하다고 한다.
또한 경량급이라고 함은, 작은 규모의 소스코드로 이루어졌다는 의미인데 Spring은 결코 그렇지 않다. 오히려 대략 20개 정도의 모듈로 이루어진 방대한 규모의 프레임워크이다.
그럼에도 Spring이 경량급, 가볍다고 하는 이유가 무엇일까?
필자는 필요에 의해서 복잡하고 방대한 규모의 코드가 개발된 것이기에 불필요하게 무겁지 않다는 뜻으로 이해하였다. 여기서의 경량급이라는 표현은 Spring이 처음 등장하던 시절의 EJB에 대항하기 위해 자주 사용되던 표현이라고 한다.
결국 Spring이 오픈소스 경량급 프레임워크로써 현재까지 대중적인 위치를 사수할 수 있었던 가장 큰 이유가 소스 코드의 규모를 따지지 않고 보다 빠르고 편하게 개발할 수 있는 환경을 제공하기에 생산성 면에서 유리한 이점을 챙기게 되어 경량급이라는 표현을 사용할 수 있는 것이라고 느꼈다.
애플리케이션 프레임워크를 알아보기 앞서, 프레임워크가 무엇인지 보자. 나무위키를 보면 다음과 같은 내용을 볼 수 있다.
프레임워크는 어떠한 목적을 달성하기 위해 복잡하게 얽혀있는 문제를 해결하기 위한 구조이며, 소프트웨어 개발에 있어 하나의 뼈대 역할을 한다.
일반적으로 라이브러리나 프레임워크는 어떠한 목표나 문제를 해결하기 위해서 만들어지게 되는데, 그 중 프레임워크는 애플리케이션에서 주로 동작하는 핵심 분야에 집중하여 특정 목적을 달성할 수 있도록 관련된 표준이나 뼈대의 역할을 수행하는 의미를 지닌다.
그런데 애플리케이션 프레임워크는 애플리케이션에서 특정한 하나의 핵심 분야에 집중하기보다, 애플리케이션의 전 영역을 포함할 수 있는 프레임워크를 말한다. 그래서 애플리케이션 프레임워크의 정의를 위키백과에서 찾아보았다.
애플리케이션 프레임워크(Application Framework)는 소프트웨어 개발자가 응용 소프트웨어의 표준 구조를 구현하기 위해 사용하는 소프트웨어 프레임워크로 구성된다.
여기서 말하는 표준 구조
는 결국 애플리케이션의 특정 계층을 구현하는 데 초점을 두기보다 전반적인 애플리케이션의 전 계층을 아우르는 구조로 구현하기 위함을 알 수 있었다. 그리고 애플리케이션 프레임워크는 애플리케이션 개발에 전체 과정을 빠르고 편하게 진행하는 것에 집중하는 구조의 프레임워크라는 것을 이해할 수 있었다.
그래서 Spring은 애플리케이션 프레임워크의 한 종류로써, Java 진영에서 엔터프라이즈 개발을 담당하는 애플리케이션 프레임워크로 사용되어지고 있다.
Spring이 Java 진영에서 엔터프라이즈 개발을 담당하는 애플리케이션 프레임워크가 된 이유는 Spring이 등장한 배경과 관련이 있다고 한다고 하는데, 이후 Spring의 탄생 배경에서 이야기 하겠다.
이렇게 Spring의 정의를 통해 Spring이 Java 엔터프라이즈 개발을 보다 쉽게 할 수 있도록 해주며, 오픈소스 경량급 프로젝트로 제공되기에 복잡하기 않고 쉽게 접근할 수 있으며, 애플리케이션 프레임워크의 구조로 개발할 수 있다는 사실을 배우고 알 수 있었다.
앞에서 Spring의 정의에 대해서 살펴보았다. 그렇다면 Spring은 어떻게 개발되어졌고, 왜 만들어졌는지를 알아볼 시간이다.
Spring이 등장하기 전에는 애플리케이션의 업무 로직을 담당하는 EJB(Enterprise Java Beans)가 Java의 표준 기술이었다. 여기서 말하는 EJB란 무엇일까?
엔터프라이즈 자바빈즈(Enterprise JavaBeans, EJB)란 기업환경의 시스템을 구현하기 위한 서버측 컴포넌트 모델이다. 즉, EJB는 애플리케이션의 업무 로직을 가지고 있는 서버 애플리케이션이다. EJB 사양은 Java EE의 자바 API 중 하나로, 주로 웹 시스템에서 JSP는 화면 로직을 처리하고, EJB는 업무 로직을 처리하는 역할을 한다.
앞에서 Spring의 정의를 보았다면 Spring은 Java 엔터프라이즈 개발을 보다 편하게
도와주는 프레임워크라는 것을 기억할 수 있을 것이다. 그렇다면 EJB는 Java 엔터프라이즈 개발이 편하지 않고 어렵다는 걸까?
EJB는 인스턴스 풀링, 트랜잭션 관리, 컴포넌트 생명주기 등의 특징이 있어 기술적으로 복잡한 로직을 핵심 로직에서 분리하는데 성공은 했지만, 이를 위해서 오로지 EJB만을 위한 환경과 사양을 맞추어야 하는 상황이 발생하여 개발자에게 더 큰 부담을 안겨주게 되었다. 특히 Java 언어를 사용함에도 객체지향적이지 않다.
위와 같이 EJB는 기술의 복잡함을 덜어주려다 되려 무거워졌다. EJB의 요구사항을 강제하게 되어 Java의 큰 특장점인 객체지향적 특성을 지킬 수 없게 되었다
는 것이 가장 큰 리스크라고 생각한다.
결국 많은 종류의 프레임워크가 등장했고, 그 중 Java 진영에서는 대표적인 표준 기술로써 EJB가 등장했지만, 개발하기 복잡하고 무겁다는 단점 때문에 경량급 프레임워크인 Spring이 등장하게 되었다.
Spring이 EJB를 대체하기 위해 등장했다는 간단한 사실을 배우게 되었다.
그렇다면 Spring이 얼마나 강력하길래 EJB를 넘어서서 대중적인 프레임워크로 자리잡은걸까? EJB의 큰 단점인 객체지향적 특성을 잘 지킬 수 있어서일까? Spring의 POJO를 보면 그 해답을 얻을 수 있다.
많은 사람들은 Spring의 핵심으로 POJO 프로그래밍를 말하고 있다. 이는 스프링 삼각형이라는 위 사진으로 잘 알 수 있다.
이 삼각형에서 알 수 있는 Spring의 기본 구조는 다음과 같다.
- IoC와 DI(Inversion of Control & Dependency Injection)
- AOP(Aspect Oriented Programming)
- PSA(Portable Service Abstractions)
Spring은 IoC와 DI, AOP와 PSA라는 주요 기술을 통해 애플리케이션을 POJO로 개발할 수 있게 해준다.
POJO는 무엇을 뜻하는 걸까? 위키백과에서 찾아보았다.
POJO(Plain Old Java Object)는 오래된 방식의 간단한 자바 오브젝트라는 말로서 Java EE 등의 중량 프레임워크들을 사용하게 되면서 해당 프레임워크에 종속된
무거운
객체를 만들게 된 것에 반발해서 사용되게 된 용어이다. POJO는 2000년 9월에 마틴 파울러, 레베카 파슨, 조쉬 맥킨지 등이 사용하기 시작한 용어이다.
위 말을 보면, POJO는 순수 Java만을 통해 생성한 객체를 뜻한다고 볼 수 있다. 즉, 다른 기술을 사용하지 않고 Java로만 이루어진, Java의 스펙에 정의된 기술만을 사용하여 만든 객체라는 것이라는 것을 알 수 있다.
POJO로 만들어진 예시 코드를 보자.
public class 햄버거 {
private String bread; // 빵
private String patty; // 패티
// getter
public long getBread() {
return bread;
}
public String getPatty() {
return patty;
}
// setter
public void setBread(String bread) {
this.bread = bread;
}
public void setPatty(String patty) {
this.patty = patty;
}
}
위 햄버거 클래스
는 bread와 patty 필드와 getter, setter로만 이루어져 있고, 다른 라이브러리나 프레임워크의 종속된 부분이 존재하지 않기 때문에 POJO의 조건을 충족하는 클래스임을 쉽게 알 수 있다.
😀 POJO 용어의 유래
POJO라는 용어의 유래는 생각보다 재미있다.
마틴 파울러는 당시 인기를 끌고 있던 EJB처럼 복잡하고 제한이 많은 기술을 사용하는 것보다 Java의 단순한오브젝트를 이용해 애플리케이션의 비즈니스 로직을 구현하고 싶어했다. 그런데 그 시절의 개발자들은 단순 오브젝트 사용을 기피했는데, 그 이유는 EJB와 같이 지어진 이름이 없기 때문이었다. 그래서 Java의 단순 오브젝트를 통해 명명한 이름이 바로 POJO이다. 평범한 자바 오브젝트에 멋진 이름을 붙여줬던 시도는 기대 이상으로 성공적이었다. 심지어 EJB조차 기존의 문제점을 반성하고 POJO 프로그래밍의 장점을 적극 도입하려고 했다고 한다.
여기서 POJO와 EJB의 관계를 생각해보지 않을 수가 없다. POJO 프로그래밍을 통해서 EJB의 단점을 어떻게 상쇄시킬 수 있는 걸까?
POJO는 순수한 Java만을 사용해 생성한 객체이기 때문에 특정 기술이나 환경에 종속되면 안된다는 조건이 있다. 이는 외부기술이나 규약의 변경점이 발생할 때 보다 쉽고 유연하게 대응할 수 있게 해준다.
- EJB의 제약사항에 구애받지 않으므로 필요에 따라 다른 기술과의 통합이 가능해진다.
- POJO 프로그래밍을 통해 비즈니스 로직을 구현할 경우
EJB에서는 어려웠던 Java의 객체지향적 특성을 살려 설계를 진행
할 수 있다.- POJO는 단순한 Java 오브젝트이기에 EJB 컨테이너 없이도 객체를 생성하고 단위 테스트를 수행하기 좋다.
결국 Spring에서 POJO 프로그래밍을 강조하는 이유는 위와 같이 EJB의 단점을 해결해주기 때문임을 단 번에 알 수 있었다.
이번 글에서는 Spring이 무엇인지, 어떻게 등장했는지, 왜 대중적인 프레임워크로 자리매김 하였는지 학습하고, 이해하는 시간을 가졌다. 또한, 이번 학습을 통해서 Spring을 주력으로 다루는 개발자이지만, 여태 Spring에 대해서 막연한 지식을 가지고 있던 모습을 반성하게 되었다.
아직도 Spring에 대해서 배울 것은 많고, 모르는 것 투성이다. 그럼에도 기초부터 하나씩 꾸준히 배워나가는 과정 속에서 주니어 개발자가 가져야할 기초 전문성을 갖출 수 있도록 노력할 것이다.
다음 글에서는 Spring의 핵심 요소 POJO 프로그래밍을 기반으로 IoC와 DI, AOP, PSA가 무엇인지 제대로 알아볼 것이다.
본 글은 학습하며 작성한 글이기에 틀리거나 잘못된 내용이 기록될 수 있습니다.
잘못된 내용이 있다면 언제든지 지적해주십시오. 다시 학습하여 정정하도록 하겠습니다.
참고자료 출처