수트 한 벌을 맞출 때, 기성복을 살 것인가 아니면 마스터 테일러에게 맞춤 제작을 맡길 것인가? 전자는 빠르고 편리하지만 약간의 타협이 따르고, 후자는 완벽한 핏을 보장하지만 시간과 비용을 투자해야 한다.
Java 생태계에서 가장 유명한 이 두 프레임워크의 관계도 정확히 이렇다. 많은 개발자들이 ‘Spring’과 ‘Spring Boot’를 혼용하지만, 이 둘은 엄연히 다른 존재다. 한 마디로 정의하자면, Spring Boot는 Spring이라는 완성도 높은 수트를 ‘입는 방식’을 혁신적으로 바꾼 전략이다.
오늘날 한국 개발 현장에서 Spring Boot는 단순한 유행을 넘어 사실상의 표준(De facto standard) 이 되었다. 왜 모든 개발자가 Spring Boot에 열광하는지, 그리고 여전히 전통적인 Spring이 필요한 순간은 언제인지, 이 둘의 차이를 단호하게 파헤쳐보자.
1. 핵심 차이: ‘설정’이라는 늪에서 탈출하라
전통적인 Spring: 수동의 미학, 그러나 번거로움의 대명사
Spring Framework 자체는 2003년부터 Java 세계를 지배해 온 거대한 생태계다. 의존성 주입(DI), 관점 지향 프로그래밍(AOP), 그리고 방대한 모듈(Spring MVC, Spring Security 등)을 제공한다 . 문제는 이것들을 조립하는 방식에 있었다.
옛날 방식의 Spring 개발자는 프로젝트를 시작하기 위해 다음과 같은 지루한 의식(?)을 수행해야 했다.
- pom.xml:
spring-webmvc,jackson-databind,servlet-api등 필요한 라이브러리를 하나하나 찾아서 버전까지 직접 명시한다. 버전 충돌은 기본 옵션이다 . - web.xml:
DispatcherServlet을 등록하고 URL 맵핑을 설정한다. XML 태그 하나 잘못 쓰면 서버가 아예 뜨지 않는다 . - servlet-context.xml: 빈(Bean) 스캔, View Resolver, DataSource 등 수십 줄의 XML 설정을 작성한다.
이 모든 과정은 마치 요리를 하기 전에 장작을 패고 불을 피우는 것과 같았다. 비즈니스 로직 한 줄 작성하기 전에 이미 체력이 70%는 소모된 상태였다.
Spring Boot: ‘설정보다 관습’의 선언
2014년, Spring Boot는 이 모든 설정 지옥에 종지부를 찍었다. Rod Johnson의 정신을 계승한 이 프레임워크는 “일단 달려, 설정은 내가 할게” 라는 철학을 내세웠다 .
- 자동 구성(Auto-Configuration):
pom.xml에spring-boot-starter-web만 추가하면, 톰캣(Tomcat) 설정부터 Spring MVC 설정까지 모든 것이 자동으로 등록된다 . 더 이상web.xml을 본 적이 없는 세대가 바로 Spring Boot 세대다. - 스타터(Starter): ‘그냥 실행 가능한 JAR’라는 개념을 실현시켰다.
main()메서드를 가진 클래스를 실행하는 순간, 내장 톰캣이 자동으로 뜨고 애플리케이션이 기동된다.
| 특징 | Spring Framework (전통적 방식) | Spring Boot |
|---|---|---|
| 설정 방식 | 수동 XML 또는 Java Config | 자동 구성 (Auto-configuration) |
| 의존성 관리 | 버전을 직접 명시하며 관리 | Starter가 버전 호환성까지 관리 |
| 서버 | 외부 WAS (Tomcat, JBoss) 필요 | 내장 서버 (Tomcat, Jetty) 기본 탑재 |
| 배포 방식 | WAR 파일을 서버에 배포 | JAR 파일 실행 (java -jar) |
| 생산성 | 낮음 (설정에 시간 소모) | 매우 높음 (비즈니스 로직 집중) |
2. Spring Boot의 ‘오만함’이 가져온 기적과 대가
Spring Boot는 단순히 편리함만 가져온 것이 아니다. 마이크로서비스 아키텍처(MSA) 시대를 열었고, 클라우드 네이티브 환경과 찰떡궁합을 자랑한다 .
장점: 당신이 뛰어야 할 시간을 벌어준다
- 개발 속도의 폭발적 증가: 프로토타입 제작 시간이 몇 시간에서 몇 분으로 단축된다. 국내 스타트업들이 Spring Boot를 사랑하는 이유다. 환경 설정에 하루를 소모하지 않아도 된다.
- 운영의 용이성:
spring-boot-starter-actuator하나만 추가하면, 애플리케이션의 건강 상태(/health), 메트릭(/metrics)을 실시간으로 모니터링할 수 있다 . - 마이크로서비스와의 결합: Spring Boot는 Spring Cloud와의 궁합이 완벽하다. 서비스 디스커버리, 설정 관리, 서킷 브레이커 등을 손쉽게 도입할 수 있어 대규모 분산 시스템 구축의 난이도를 확 낮췄다.
단점: ‘블랙박스’ 속으로 빠지지 마라
하지만 ‘편리함’은 항상 대가를 동반한다.
- 마법(매직)에 취약하다: “어? 왜 이 빈이 자동으로 등록되지 않지?” Spring Boot의 자동 설정은 강력하지만, 문제가 발생했을 때 내부 메커니즘을 모르면 헤맬 수밖에 없다 .
@Conditional어노테이션이 어떻게 동작하는지 이해하지 못하면, 디버깅은 그야말로 암호 해독 놀이가 된다. - 리소스 사용량: 내장 톰캣과 수많은 자동 설정 빈들은 메모리를 꽤 잡아먹는다. 전통적인 Spring이 WAR 파일로 50MB라면, Spring Boot JAR는 기본 의존성만으로도 100MB를 훌쩍 넘긴다 .
- 과도한 ‘관습’의 함정: Spring Boot가 너무 편리하다 보니, 개발자들이 IoC 컨테이너의 원리나 서블릿(Servlet)의 동작 방식 같은 근본적인 개념을 소홀히 하는 경향이 생겼다. 이는 결국 ‘잘 하는 척’ 하는 실력자를 양산할 위험이 있다.
3. 그래서, 지금 당신의 프로젝트는 무엇을 선택해야 하는가?
Spring Boot를 선택해야 하는 순간 (99%의 경우)
- 새로운 프로젝트를 시작한다면? 고민할 필요 없다. 전자정부 프레임워크조차 최신 버전은 Spring Boot를 기반으로 재구성되고 있다 .
- 마이크로서비스, 클라우드 환경(AWS, NCP), 쿠버네티스(K8s)에 배포할 예정이라면? Spring Boot는 선택이 아닌 필수다.
- 팀의 생산성을 극대화하고 싶다면? 초기 셋업 시간을 0에 가깝게 만들고 비즈니스 로직에 집중하라.
프로 팁: Spring Boot를 사용한다고 해서 Spring Framework 자체를 무시해도 되는 것은 아니다. Spring Boot는 Spring의 ‘확장판’이지, 대체제가 아니다. 내부적으로 동작하는 @Autowired의 원리, ApplicationContext의 생명주기, AOP의 프록시 메커니즘은 결국 Spring Framework의 지식을 요구한다.
전통적인 Spring 방식을 고수해야 하는 순간 (1%의 극한 상황)
- 레거시 시스템 유지보수: 2010년대 중반에 개발된 전자정부 프레임워크(Spring 3.x/4.x 기반)를 운영 중이라면, 굳이 Boot로 마이그레이션할 필요는 없다. 안정성이 최우선이다 .
- 초저지연(Low-latency) 또는 극한의 경량화: 메모리 사용량을 10MB 단위로라도 아껴야 하는 IoT 디바이스나 극도로 최적화된 시스템이라면, 내장 톰캣조차 사치일 수 있다.
- 진정한 커스터마이징: Spring Boot의 자동 설정을 모두 꺼야 하는 극단적인 환경이라면, 차라리 순수 Spring으로 모든 빈을 수동으로 컨트롤하는 것이 더 깔끔할 수 있다.
최종 평결: 겉멋만 들지 마라
결국 Spring Boot는 도구다. 이것을 사용한다고 해서 당신이 갑자기 뛰어난 아키텍트가 되는 것은 아니다. 오히려 편리함 뒤에 숨겨진 Spring의 깊은 철학을 이해하려는 노력이 필요하다.
수트 한 벌을 살 때도 그렇다. 기성복(Spring Boot)으로 우아하게 입는 법을 먼저 배우고, 정말 중요한 자리에서는 테일러(Spring Core)에게 내 체형을 설명할 수 있어야 한다.
액션 플랜: 당장 start.spring.io에 접속해서 Spring Boot 프로젝트를 하나 생성해보라. @SpringBootApplication 하나만으로 세상이 어떻게 돌아가는지, 그 안에서 톰캣이 어떻게 기동되고, DispatcherServlet이 어떻게 등록되는지. 그 내부를 파고드는 호기심이야말로 진짜 ‘잘하는 개발자’로 가는 지름길이다.
지금 당신의 프로젝트는 어떤 프레임워크로 구축되어 있나요? 아니면 지금 막 시작하려는 중인가요? 댓글로 고민을 나눠보세요.
