프로그래밍 언어 활용/SPRING

[SPRING] 1. 스프링의 시작

프린이8549 2024. 8. 30. 13:50

본 글은 김영한님의 <스프링 핵심 원리 -기본편> 강의를 수강 후 강의 내용을 편집/정리하여 작성한 것입니다.

 

0.들어가기에 앞서

스프링(SPRING)이란?

 

"스프링"은 문맥에 따라 다르게 사용된다.

 

1. 스프링 DI 컨테이너 기술

2. 스프링 프레임워크

3. 스프링 부트, 스프링 프레임워크 등을 아우르는 스프링 생태계

 

그렇다면 왜 "SPRING"인가?

 

이를 알기 위해서는 스프링 탄생 이전으로 거슬러 올라갈 필요가 있다.

 

본 고에서는 스프링을 본격적으로 이해하기에 앞서 스프링의 탄생 과정과 스프링 생태계에 대해서 소개해보고자 한다.

 

1. 스프링의 등장 배경

 

servlet, jsp 의 등장 이후 시스템의 대규모화에 따른 대량의 트래픽을 처리하기 위해 여러 대의 서버와 DB로 데이터를 주고 받으면서 시스템의 복잡성이 증가했다. 자연스레 이를 해결하기 위한 기술들도 복잡해짐에 따라 개발자들은 비즈니스 로직 외의 요구사항을 해결하기 위해 많은 리소스를 소모해야했다.

 

이때 등장한 것이 바로 스프링을 탄생시킨 일등 공신인 EJB이다.  EJB는 상기한 문제 즉, 로우 레벨의 기술에 대한 문제를 신경쓸 필요 없이 비즈니스 로직에만 집중할 수 있게 하기 위해 독립적으로 개발한 컴포넌트를 배포하고, 서로 연동해 사용하는 컴포넌트 기반의 개발 모델을 제시했다. 

 

그리고 이 컴포넌트를 기존 Java Beans와 다른 Enterprise Java  Beans 라고 구별지으며 EJB라고 칭하게 되었다.

 

그러나 EJB에는 치명적인 약점들이 있었으니, 

첫째, EJB는 너무 복잡하고 느렸으며,

둘째, 다루기에 난이도가 높았고,

셋째, 대 당 가격이 수천만원에 육박할 정도로 비쌌다는 것이다.

 

일례로, EJB에는 엔티티빈이 있어서 ORM 방식을 지원했으나 그것은 JOIN이 포함될 시 제대로 작동하지 않는 등 매우 기초적인 수준이었다.

 

이렇듯 EJB라는 지옥불에서 신음하던 개발자들이 POJO(Plain Old Java Object)라는 용어를 만들어내며 EJB에 종속되어 무거운 객체들을 만드는 것에 반기를 들고 일어나, 오래된 방식의 간단한 자바 오브젝트를 사용하자는 움직임이 등장한다.

일종의 복고주의적 움직임이라고 할 수 있지 않을까?

 

이러한 파동에 힘입어 EJB 지옥에서 신음하던 개발자 중 한 명이었던 로드 존슨(Rod Johnson)이 <<Expert One-on-One J2EE Design and Development(2002)>>를 출판하며 이탈리아 르네상스의 서막을 알린 단테의 <<신곡>>과 같이 스프링 르네상스의 본격적인 시작을 알렸다.

 

<<Expert One-on-One J2EE Design and Development(2002)>>

 

해당 저서는 EJB의 문제점을 지적하며 30,000 라인 이상의 기반 기술을 예제 코드를 통해 EJB 없이도 고품질의 확장 가능한 애플리케이션을 개발할 수 있음을 보여주었다. 예컨대 BeanFactory, ApplicationContext, POJO, 제어의 역전(IoC), 의존관계 주입(DI) 등 현 스프링의 핵심 개념과 기반 코드가 들어있으며, 당대 개발자들이 본인들의 프로젝트에 해당 예제 코드를 사용함으로써 상당한 영향을 미쳤다.

 

출간 직후 유겐 휠러(Juergen Hoeller), 얀 카로프(Yann Caroff)가 로드 존슨에게  오픈 소스 프로젝트를 제안함에 따라 현재의 스프링이 탄생했다. JAVA EE(EJB)라는 겨울을 넘어 새로운 시작이라는 의미로 SPRING 이라고 명명하였으며(얀 카로프의 아이디어라고 함), 현재 스프링의 핵심 코드의 상당수는 유겐 휠러가 개발했으며 개발 중에 있다.

 

그리하여 스프링은 EJB 컨테이너를 대체하는데 성공하여 이른바 "단순함의 승리"를 거뒀으며 현재 사실상 표준 기술의 위치를 차지하고 있다고 할 수 있다.

 

추가적으로 개빈 킹(Gavin King)이 EJB의 엔티티빈 기술을 대체하고자 Hibernate를 창시하여 각광받자 자바 진영에서 역으로 개빈 킹을 스카우트하여 Hibernate에 기반한 JPA(Java Persistence API)를 만들었다. 이는 자바 ORM 기술에 대한 표준 명세로써 새로운 표준을 정의함에 따라 마침내  EJB의 지옥불 시대는 막을 내리고 SPRING의 시대가 도래했다고 할 수 있다.

개빈 킹의 <<하이버네이트 완벽 가이드(2010)>>

 

2. 스프링의 생태계

출처 : 김영한 <스프링 핵심 원리 -기본편> 강의 자료

 

SPRING은 스프링 프레임워크를 필두로 스프링 부트, 스프링 시큐리티, 스프링 데이터 등 수많은 기술들로 구성되어 있다.

 

이 중 현재 SPRING이라고 한다면 십중팔구는 스프링 프레임워크 혹은 스프링 부트를 지칭하는 것이라고 할 수 있다. 그렇다면 스프링 프레임워크와 스프링 부트는 무엇인가?

 

2.1. SRPING FRAMEWORK

 

스프링 프레임워크는 그 자체로 수 많은 기술들의 결정체라고 할 수 있다.

 

스프링 프레임워크를 구성하는 대표적인 기술들은 아래와 같다.

 

  • 핵심 기술
    • 스프링 DI 컨테이너, AOP, 이벤트, 기타
  • 웹 기술
    • 스프링 MVC, 스프링 WebFlux
  • 데이터 접근 기술
    • 트랜잭션, JDBC, ORM 지원, XML 지원
  • 기술 통합
    • 캐시, 이메일, 원격접근, 스케쥴링
  • 테스트
    • 스프링 기반 테스트 지원
  • 언어
    • 코틀린, 그루비

상기한 기술들은 개발자들에게 편의성을 제공해주었다. 그러나 많은 기술들의 집합체인 만큼 해당 기술들을 원활하게 사용하기 위한 설정 작업에 많은 자원이 소모되었다.

 

그리고 마침내 스프링 부트가 탄생함에 따라 그나마 남아있던 스프링 프레임워크에 대한 진입장벽도 허물어버렸으니, 스프링부트의 주요 기능은 아래와 같다.

 

2.2. SRPING BOOT

  • 스프링을 편리하게 사용할 수 있도록 지원
  • 단독으로 실행 가능한 스프링 애플리케이션을 쉽게 생성
  • 웹 서버(ex.Tomcat)를 내장함으로써 별도의 웹 서버 설치할 필요 없음
  • 쉬운 빌드 구성을 위한 starter 종속성 제공
  • 스프링과 써드 파티(외부) 라이브러리 자동 구성
  • 메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공
  • 관례에 의한 간결한 설정

스프링 설정에 무수히 많은 시간을 소모해야했던 개발자들에게 스프링부트가 제공하는 편의성은 마치 가뭄의 단비와 같았기 때문에 최근에는 스프링 부트가 기본적으로 사용되고 있다고 할 수 있다.

 

3. 맺으며 : 스프링은 왜 만들었는가?

지금까지 스프링의 탄생 배경과 스프링 생태계에 대해서 짧게 알아보았다.

 

그러나 스프링을 본격적으로 이해하기 위해서 우리는 "스프링을 왜 만들었는가"에 대해서 탐구해볼 필요가 있다.

 

상기한 스프링의 핵심 기능들을 살펴봤을 때,  스프링이 등장하게 된 시대적 요구(EJB의 불편함 등)를 떠나서 다소 원론적인 이야기를 해보자면, 스프링을 왜 만들었다고 할 수 있을까?

 

스프링을 왜 만들었는가?에 답하기 위해서는 스프링의 핵심 컨셉/기술에 대한 이해가 선행되어야 한다.

 

스프링의 핵심은 무엇인가?

 

스프링이 자바 언어 기반의 프레임워크라는 점에 집중한다면, 스프링의 핵심은 곧 좋은 객체 지향 애플리케이션을 개발할 수 있도록 도와주는 것이라고 할 수 있다.

 

그렇다면 좋은 객체 지향 프로그래밍은 도대체 무엇을 의미하는가?

 

위 물음들에 대한 탐구는 다음 글을 통해 소개해보고자 한다.

 

 

<참고문헌>

https://velog.io/@tess/ejb%EC%9D%98-%EB%93%B1%EC%9E%A5

 

인프런 강의 김영한님의 <스프링 핵심 원리 -기본편>