스프링(Spring)의 역사와 탄생 배경

 

스프링(Spring)의 역사와 탄생 배경: EJB 지옥에서 시작된 혁신

자바 진영에서 가장 많이 사용되는 프레임워크 중 하나인 스프링(Spring)은 지금은 사실상 표준이라 불릴 정도로 널리 사용된다. 그러나 스프링은 처음부터 주류 기술이 아니었으며, 오히려 당시 표준으로 여겨지던 EJB(Enterprise Java Beans)의 무거움과 복잡함에 대한 비판에서 출발했다.

이 글에서는 스프링이 왜 등장했는지, 어떤 배경 속에서 성장했는지를 기술적 흐름에 맞춰 정리해본다.

 

---

EJB: 자바 엔터프라이즈 개발의 겨울

2000년대 초반, 자바 기반의 기업용 애플리케이션 개발에는 J2EE(Java 2 Platform, Enterprise Edition)가 널리 사용되었다. 그 중심에는 EJB(Enterprise Java Beans)가 있었으며, 이는 당시 기업 개발 표준 기술로 간주되었다. 그러나 개발자 입장에서는 여러 가지 한계점으로 인해 많은 어려움을 겪었다.

• 구조적 복잡성: 하나의 비즈니스 로직을 구현하기 위해 여러 인터페이스(EJBHome, EJBObject 등)를 구현해야 했고, 관련 설정 파일(XML)도 복잡했다.
• 개발 생산성 저하: 개발 속도가 느렸고, 디버깅과 유지보수가 어려웠다.
• 테스트의 제약: EJB는 컨테이너 환경에서만 동작했기 때문에 단위 테스트가 매우 어려웠다.
• 과도한 의존성과 느린 성능: 객체 간 의존성이 강하고, 실행 속도가 느렸다.

개발자들은 이를 두고 “EJB 지옥”이라 부르기도 했다. 실무에서 사용하는 데에 현실적인 한계가 많았기 때문이다.

---

복잡함에 대한 대안: 새로운 접근의 필요성

EJB의 한계를 극복하고자 다양한 오픈소스 기술들이 등장했다. 대표적으로는 Hibernate, iBATIS, Struts 등이 있으며 이들은 각각 데이터 접근이나 웹 MVC 등 특정 영역에서 EJB의 복잡함을 피하고자 하는 시도였다. 그러나 이러한 대안들도 부분적인 해결책에 불과했다.

• Hibernate: EJB의 엔티티 빈(Entity Bean)의 대안으로 등장한 ORM(Object-Relational Mapping) 프레임워크로, 자바 객체와 데이터베이스 간 매핑을 단순화했다.
• EclipseLink, OpenJPA 등: 다양한 ORM 도구들이 발전했고, 결국 이를 통합해 표준화한 것이 JPA(Java Persistence API)였다.
• Struts: EJB의 웹 계층을 대체할 수 있는 MVC 웹 프레임워크로 활용되었다.

그러나 진정한 해결은 이보다 더 큰 틀의 변화, 즉 개발 철학 자체의 변화를 필요로 했다.

---

Rod Johnson의 등판: 새로운 길을 제시하다

2002년, 호주의 개발자인 Rod Johnson은 《Expert One-on-One J2EE Design and Development》라는 책을 출간했다. 이 책은 기존 EJB 기반 개발 방식의 문제점을 명확하게 지적하며, EJB 없이도 충분히 확장 가능하고 유지보수하기 쉬운 엔터프라이즈 애플리케이션을 만들 수 있다는 사실을 보여주었다.

Rod Johnson은 다음과 같은 핵심 아이디어를 제시했다.

• POJO(Plain Old Java Object): 특별한 기술에 종속되지 않은 순수 자바 객체를 중심으로 개발할 수 있다.
• IoC(Inversion of Control): 객체의 생성과 생명주기를 개발자가 아닌 외부 컨테이너가 관리함으로써, 코드 간의 결합도를 낮출 수 있다.
• DI(Dependency Injection): 필요한 의존성을 명시적으로 주입함으로써 유연한 아키텍처를 구현할 수 있다.
• BeanFactory, ApplicationContext: 애플리케이션의 의존성을 관리하기 위한 컨테이너 구성 요소들

이 책에는 3만 줄이 넘는 기반 코드가 포함되어 있었고, 이 코드가 지금의 스프링 프레임워크의 초기 버전 역할을 했다.

 

---

스프링 프레임워크의 태동

Rod Johnson의 책이 개발자들 사이에서 주목을 받자, 독일 출신 개발자 Juergen Hoeller와 Yann Caroff는 Rod에게 이 기반 코드를 오픈소스 프로젝트로 발전시킬 것을 제안했다. 이때부터 스프링은 본격적인 프레임워크로서의 여정을 시작하게 된다.

Rod Johnson은 제안에 동의했고, 이후 Juergen Hoeller는 핵심 개발자로 합류하여 지금까지도 스프링의 주요 기능을 담당하고 있다. 스프링(Spring)이라는 이름은 J2EE의 “겨울”을 지나, 더 나은 개발 경험이라는 “봄”을 맞이한다는 상징적 의미를 담고 있다.

---

스프링 프레임워크 주요 릴리즈 히스토리

연도 버전 주요 특징

2003년	Spring Framework 1.0	XML 기반 설정, IoC/DI 개념 구현
2006년	Spring Framework 2.0	XML 편의성 개선, 사용자 정의 네임스페이스 도입
2009년	Spring Framework 3.0	자바 기반 설정(JavaConfig), SpEL(Spring Expression Language)
2013년	Spring Framework 4.x	자바 8 지원, WebSocket 지원 등
2014년	Spring Boot 1.0	자동 설정(AutoConfiguration), 내장 웹 서버, 실행 가능한 JAR
2017년	Spring Framework 5.0 / Spring Boot 2.0	리액티브 프로그래밍(WebFlux), Kotlin 지원
2020년	Spring Boot 2.4	구성 데이터(ConfigData) 구조 개편
2021년	Spring Boot 2.5~2.6	Gradle 빌드 공식 지원, 테스트 유연성 향상
2022년	Spring Boot 2.7 / Framework 5.3	유지보수 중심 릴리즈, 마이그레이션 지원
2023년	Spring Boot 3.0 / Framework 6.0	Jakarta EE 전환, Java 17 이상 요구, Native Image 지원 시작
2024년 이후	3.1 ~ 최신	GraalVM 기반 Native Image 성능 향상, AI/ML 통합 실험 등 진행 중

 

---

스프링이 남긴 유산

스프링은 기술적인 도구를 넘어, 자바 개발 방식 자체를 바꿔놓았다.

• 객체 지향의 원칙을 지키면서도 생산성과 유지보수를 높이는 방법을 제시했다.
• 테스트 중심 개발(TDD)과 모듈화된 시스템 구성에 적합한 아키텍처를 제공했다.
• 마이크로서비스, 클라우드 네이티브, 서버리스 등의 현대적 개발 패러다임에서도 중심이 되는 기술로 자리잡았다.

이러한 점에서 스프링은 단순한 프레임워크가 아닌, 현대 자바 생태계의 철학과 기준을 제시한 기술적 전환점이라 할 수 있다.

---

마치며

스프링의 역사를 이해하면 단순한 API 사용법 너머의 세계가 보인다.
왜 스프링이 지금과 같은 구조를 갖게 되었는지, 그 속에 담긴 철학은 무엇인지 이해하게 되면
보다 깊이 있는 사고와 효과적인 개발이 가능해진다.

다음 글에서는 스프링의 핵심 개념과 내부 구조에 대해 더 자세히 알아볼 예정이다.