[테크/회고] 자바 웹 프레임워크 연대기: 스트럿츠(Struts)의 왕좌와 스프링(Spring)의 대혁명

talkit (71)in #kr • 2 hours ago (edited)

[테크/회고] 자바 웹 프레임워크 연대기: 스트럿츠(Struts)의 왕좌와 스프링(Spring)의 대혁명

안녕하세요 가야태자 @talkit 입니다.

요즘 자바를 복기 해보고 있습니다. 그중에서 자바의 프레임워크 발전사에 관한글을 오늘 작성해봅니다.

자바(Java) 백엔드 생태계를 주도해 온 프레임워크의 역사를 되짚어보면, 이는 단순히 기술의 변화가 아니라 "복잡성과의 처절한 사투", 그리고 "개발자 중심의 생산성 향상"이라는 거대한 흐름의 연속이었습니다.

오늘날 자바 개발자들에게 공기처럼 당연한 존재가 된 Spring Boot와 Spring MVC가 있기까지, 자바 웹 생태계의 패러다임을 바꾸었던 두 주인공 '스트럿츠(Struts)'와 '스프링(Spring)'의 흥망성쇠, 그리고 자바의 표준이 된 스프링 생태계의 거대한 진화 과정을 한눈에 정리해 봅니다.

1. 태동기: EJB의 독점과 스파게티 코드의 어둠 (2000년대 초)

초기 대규모 자바 엔터프라이즈 환경은 썬 마이크로시스템즈(Sun Microsystems)가 주도한 J2EE 규격과 EJB(Enterprise JavaBeans)가 지배하고 있었습니다. 분산 환경과 트랜잭션을 컨테이너가 알아서 제어해 준다는 거창한 명분이 있었지만, 현실은 처참했습니다. 코드 한 줄을 고치거나 테스트하려면 수많은 인터페이스를 상속받아야 했고, 무거운 WAS(웹 애플리케이션 서버)를 매번 재부팅해야 했습니다. "자바의 본질인 객체지향(POJO)을 잃어버렸다"는 혹평이 쏟아졌습니다.

덮친 데 덮친 격으로 당시 웹 화면을 담당하던 JSP 영역은 HTML, 자바스크립트, 비즈니스 로직, 데이터베이스 쿼리까지 한 파일에 뒤섞여 있는 이른바 '모델 1' 방식이 흔했습니다. 조금만 프로젝트가 커져도 유지보수가 불가능한 스파게티 코드가 되기 일쑤였습니다.

2. 스트럿츠(Struts)의 등장: 최초의 웹 MVC 표준과 황금기 (2000년대 초중반)

이 어둠 속에서 자바 웹 구원의 투수로 등판한 것이 바로 아파치 재단의 스트럿츠(Struts)였습니다. 2001년 출시된 스트럿츠는 스파게티 코드처럼 엉켜있던 웹 개발 프로세스에 '모델 2 MVC(Model-View-Controller) 패러다임'을 확고하게 심어주었습니다.

화면(View), 비즈니스 로직(Model), 제어 흐름(Controller)을 명확하게 분리.
개발자들이 역할 분담을 할 수 있는 구조적 명확성 제공.

스트럿츠는 출시 직후 폭발적인 인기를 끌며 2003년부터 2007년 무렵까지 전 세계 자바 웹 시장을 사실상 지배했습니다. 당시 한국의 초기 대형 공공기관 프로젝트나 대기업 시스템 역시 대부분 스트럿츠를 뼈대로 구축되었습니다. 자바 웹 개발자들에게 "웹 앱은 무조건 MVC로 짜야 한다"는 공식을 각인시킨 주역이 바로 스트럿츠입니다.

3. 스프링(Spring)의 탄생: 오픈소스 혁명과 '공존'의 시대 (2000년대 중반)

스트럿츠가 앞단(웹 화면 제어)을 평정하고 있을 때, 뒤 영역(비즈니스 로직 및 객체 관리)에서는 또 다른 혁명이 시작되고 있었습니다. 2004년, EJB의 지독한 복잡성에 분노한 로드 존슨(Rod Johnson)을 필두로 스프링 프레임워크(Spring Framework) 1.0이 세상에 나왔습니다.

스프링은 무거운 컨테이너 없이도 엔터프라이즈 기능을 수행할 수 있도록 IoC/DI(의존성 주입)와 AOP(관점 지향 프로그래밍)를 전면에 내세웠습니다. 기술 인프라와 비즈니스 로직을 완벽히 분리하여 "다시 순수한 자바(POJO)로 돌아가자"고 외친 것입니다.

재미있는 점은, 초기 스프링은 스트럿츠의 경쟁자가 아니라 '가장 완벽한 파트너'였다는 사실입니다. 2000년대 중반 자바 웹 진영의 가장 트렌디하고 강력한 '꿀조합' 스택은 다음과 같았습니다.

웹 화면 및 요청 제어(MVC): Struts
비즈니스 로직 및 트랜잭션 관리(DI/AOP): Spring
데이터베이스 매핑(SQL 매퍼): iBATIS (현 MyBatis)

웹 요청을 받는 앞문(Controller)은 스트럿츠가 열고, 문을 열고 들어온 데이터를 처리하는 알맹이 객체 관리는 스프링이 맡는 식으로 두 프레임워크는 아름답게 공존했습니다.

4. 세대교체: '공존'에서 '대체'로, 스프링의 왕좌 장악 (2000년대 후반)

영원할 것 같았던 스트럿츠와 스프링의 동맹은 2000년대 후반으로 넘어가며 균열이 가기 시작했고, 결국 완전한 세대교체로 이어지게 됩니다. 여기에는 몇 가지 결정적인 이유가 있었습니다.

Spring MVC의 대두: 스프링 진영에서 자체 웹 프레임워크인 Spring MVC를 고도화(Spring 2.5 ~ 3.0)하면서 굳이 앞단에 스트럿츠를 따로 연동할 필요가 없어졌습니다. 스프링 컨테이너와 완벽하게 네이티브로 결합하는 Spring MVC는 스트럿츠보다 훨씬 유연하고 강력했습니다.
설정 지옥(XML)의 한계: 스트럿츠는 화면 하나나 액션 하나를 추가할 때마다 거대한 struts-config.xml 설정을 매번 장황하게 수정해야 하는 번거로움이 있었습니다.
결정타가 된 보안 취약점 사태: 스트럿츠가 스트럿츠2(Struts2)로 버전 업을 치는 과정에서, 원격으로 코드를 실행할 수 있는 치명적인 보안 취약점(CVE)이 주기적으로 발생했습니다. 금융권과 대기업 시스템이 해커들의 표적이 되자, 안정성이 최우선인 기업들은 대대적으로 스트럿츠를 버리고 스프링 생태계로 탈출하기 시작했습니다.
- 관련 기사 참고: 안전성 경고등 켜진 '아파치 스트럿츠2' 보안 취약점 주의보 (보안뉴스)

5. 스프링 생태계의 거대한 양대 축: Spring Framework vs Spring Boot

스트럿츠를 흡수하고 자바 생태계를 통일한 스프링은 거대해진 몸집만큼 강력한 진화를 거듭했습니다. 현대 자바 백엔드는 크게 인프라와 기술 표준을 정의하는 'Spring Framework'와, 이를 기반으로 빠른 생산성을 제공하는 'Spring Boot'의 두 축으로 움직입니다. 각 프레임워크가 걸어온 핵심 버전을 브리핑합니다.

🧱 Spring Framework의 진화 (1.0에서 6.0까지)

1.0 (2004): 순수 자바 객체(POJO) 기반의 DI/AOP 개념 증명. 무거운 XML 설정 중심.
2.0 ~ 3.0 (2006~2009): 웹 계층을 위한 Spring MVC의 본격적인 강화. 점차 XML을 벗어나 @Component, @Autowired 같은 자바 어노테이션(Annotation) 기반 설정의 표준 도입.
4.0 (2013): 자바 8(Java 8) 지원 개시. 람다식과 새로운 날짜 API 등을 수용하며 현대적 자바 문법과의 정합성 확보.
5.0 (2017): 대규모 트래픽 처리를 위한 비동기·논블로킹 리액티브 프로그래밍 스택인 Spring WebFlux 탑재.
6.0 (2022~현재): 자바 17을 최소 요구 버전으로 지정하여 구조적 최적화 단행. 가상 스레드(Project Loom) 연동 및 클라우드 환경을 위한 GraalVM 네이티브 이미지 빌드 공식 지원.
- 공식 발표 참고: Spring Framework 6.0 정식 버전(GA) 출시 안내 (스프링 공식 블로그)

🚀 Spring Boot의 진화 (1.0에서 4.5까지)

1.0 (2014): 수많은 XML/자바 설정에 지친 개발자들을 구원하기 위해 등장. "설정보다는 관례(Convention over Configuration)"를 모토로 내장 톰캣(Tomcat)과 자동 설정(starter) 개념 최초 도입.
2.0 (2018): Spring Framework 5.0 기반으로 업그레이드되면서, 리액티브 웹 스택과 새로운 모니터링 툴(Actuator) 기능 대폭 강화.
3.0 (2022): 자바 17 표준 탑재 및 Spring 6 기반 리프레시. 빌드 타임에 C/C++ 프로그램처럼 바이너리를 뽑아내어 구동 속도를 밀리초(ms) 단위로 줄이는 GraalVM 네이티브 컴파일 전면 수용. 클라우드 네이티브(MSA/Serverless)의 최적화 달성.
- 공식 발표 참고: Spring Boot 3.0 정식 버전(GA) 출시 안내 (스프링 공식 블로그)
4.0 ~ 4.5 (현재): 더 고도화된 자바 최신 스펙 완벽 튜닝. 대규모 언어 모델(LLM) 연동을 위한 Spring AI 프레임워크 인프라가 코어 단에 밀접하게 내장되었으며, 가상 스레드(Virtual Thread) 최적화를 통해 리액티브 코딩 없이도 초고효율 멀티스레딩을 가볍게 구동하는 완성형 아키텍처 구축.

6. 두 프레임워크의 상관관계: 엔진과 자동차

종종 신입 개발자들이 "스프링 프레임워크와 스프링 부트 중 무엇을 공부해야 하나요?" 혹은 "부트가 나왔으니 스프링 프레임워크는 끝난 건가요?"라는 질문을 하곤 합니다. 하지만 두 기술은 대체 관계가 아닌 완벽한 상호보완적 결합 관계입니다.

쉽게 비유하자면, 스프링 프레임워크는 '고성능 자동차 엔진'이고, 스프링 부트는 그 엔진을 얹고 바퀴, 시트, 내비게이션까지 완벽하게 조립해 둔 '완성차'입니다.

Spring Boot: 편리한 완성차 (내장 톰캣, 자동 설정, 자동 버전 관리)
Spring Framework: 핵심 심장 엔진 (DI/AOP Core, Spring MVC, WebFlux 테크놀로지)

스프링 부트는 독자적인 프레임워크가 아닙니다. 내부를 뜯어보면 결국 스프링 프레임워크가 핵심 심장(Core)으로 돌고 있습니다. 과거에는 엔진(Spring Framework)만 덜렁 주어졌기 때문에 개발자가 직접 차체(Tomcat 서버)를 구해서 용접하고, 연료 공급 장치(XML 파일 수백 줄)를 직접 커스텀 조립해야 했습니다.

반면, 스프링 부트는 개발자가 Boot를 실행하는 순간, 뒤편에서 스프링 프레임워크의 DI/AOP 엔진을 깨우고 필요한 라이브러리들을 관례에 맞게 알아서 조립해 줍니다. 결국 부트를 깊고 단단하게 쓴다는 것은 그 내부에서 돌아가는 스프링 프레임워크의 사상을 완벽히 이해하는 것과 같습니다.

🏁 마치며

스트럿츠(Struts)는 무질서하던 자바 웹 개발에 최초로 MVC 패턴의 규격을 제시하며 웹 제어의 대중화를 이끈 선구자였습니다.
스프링(Spring Framework)은 EJB의 무거움에 반대하며 순수 자바(POJO) 정신을 깨웠고, 기술을 유연하게 통합하는 포용력으로 시작해 웹 영역(Spring MVC)까지 완벽히 흡수하며 생태계를 통일했습니다.
스프링 부트(Spring Boot)는 거대해진 스프링 엔진을 개발자들이 단 몇 초 만에 도로 위로 끌고 나갈 수 있게 완성차 형태로 포장해 준 혁신이었습니다.

현재 스트럿츠는 오래된 레거시 시스템의 유지보수 단계에서나 볼 수 있는 '살아있는 화석'이 되었지만, 그가 남긴 MVC 패러다임은 여전히 스프링의 심장 속에 살아 숨 쉬고 있습니다. 세월을 관통하며 다듬어진 이 견고한 생태계 덕분에, 현대의 우리는 인프라 설정에 고통받지 않고 오롯이 비즈니스 로직에만 집중할 수 있는 최고의 개발 풍요를 누리고 있습니다.

[Java 보안] 오픈 JDK 벤더별 EOS 비교 및 자바 보안 패치의 중요성 / https://www.steemit.com/kr/@talkit/java-jdk-eos--xz1g03

[Java와 AI] 자바가 AI 시대의 주역이 되지 못한 이유와 새로운 반격 / https://www.steemit.com/java/@talkit/java-ai-ai--tfzrzd

[개발 상식] 1960년대 기계어부터 현대 AI 기반 코드 최적화까지 한눈에 보기 / https://www.steemit.com/kr/@talkit/ai--px1egt

[Java] 자바 역사 가이드: SE와 EE(Jakarta EE) 통합 타임라인과 대전환 비화 / https://www.steemit.com/kr/@talkit/java-se-eejakarta-ee--p5j85z

[Java] 자바의 탄생 배경과 역사, C언어와의 차이점 총정리 / https://www.steemit.com/kr/@talkit/java-c--ji3f9j

_{Posted using SteemX}

#java #kr-dev #talkit #history #spring #struts