25.12.24 스프링 부트은 스프링과 다른 건가요?

스프링 (Spring Framework)

스프링은 자바 엔터프라이즈 애플리케이션 개발을 위한 포괄적인 인프라를 제공하는 프레임워크이며, IoC/DI를 기반으로 비즈니스 로직에만 집중할 수 있게 해 준다.

유연성이 매우 높지만, 설정을 위해 많은 XML이나 Java 설정 파일이 필요하다. (소위 '설정 지옥'이라 불림)

 

설정 지옥이라고 불리는 이유

방대한 XML 설정의 습격

스프링 초기에는 객체 간의 의존 관계(DI)를 모두 XML 파일에 명시해야 했다.

• 문제: 프로젝트 규모가 커지면 XML 파일이 수천 줄로 늘어났고, 어떤 객체가 어디에 주입되는지 한눈에 파악하기가 불가능했다.
• 오류 취약성: XML은 텍스트 기반이라 오타가 나도 컴파일 시점에 알 수 없었고, 런타임에 서버가 터져야만 알 수 있는 경우가 허다했다.

 

수동적인 인프라 설정 (Boilerplate)

웹 애플리케이션 하나를 띄우기 위해 설정해야 할 요소가 너무 많았다.

• DispatcherServlet 설정: web.xml 파일에 서블릿 설정을 직접 적어야 함.
• View Resolver: HTML 파일을 어디서 찾을지 직접 경로 설정.
• DataSource: DB 연결 정보와 커넥션 풀을 일일이 Bean으로 등록.
• Transaction Manager: 트랜잭션 처리를 위한 객체도 직접 등록.

비즈니스 로직(예: 회원가입)은 10줄인데, 이를 위한 환경 설정에만 몇 시간이 걸리는 '배보다 배꼽이 더 큰' 상황이었다.

 

라이브러리 버전 관리의 어려움 (Jar Hell)

스프링은 수많은 외부 라이브러리(Hibernate, Jackson, Logback 등)를 조합해서 사용한다.

• 문제: 각 라이브러리마다 서로 요구하는 버전이 달랐다.
  예를 들어, 스프링 버전은 4.0인데 Hibernate는 5.0을 써서 충돌이 나거나, 특정 라이브러리가 누락되어 ClassNotFoundException이 발생하는 일이 비일비재했다.
• 이를 해결하기 위해 개발자는 수많은 라이브러리의 '호환성 조합'을 직접 공부해서 맞춰야 했습니다.

 

외부 WAS(Tomcat)의 별도 관리

과거에는 서버(Tomcat)를 별도로 설치하고 관리해야 했다.

• 서버를 설치하고, 환경 설정을 맞춘 뒤, 코드를 WAR 파일로 빌드해서 서버에 수동으로 올리는 과정이 필요했다.
  이 과정에서 서버 설정과 코드 설정이 맞지 않아 오류가 발생하는 경우가 많았다.

 

스프링 부트가 이 지옥을 어떻게 해결했나?

스프링 부트는 "설정보다는 관례(Convention over Configuration)"라는 철학으로 이 문제를 해결했다.

과저의 설정 지옥	스프링 부트의 해결책
수천 줄의 XML	@SpringBootApplication 하나로 자동 설정
복잡한 버전 맞추기	Starter 의존성으로 검증된 버전 조합 제공
수동 Bean 등록	Auto-Configuration 이 클래스패스를 읽어 자동으로 등록
외부 서버 설치	Embedded Tomcat으로 JAR 실행만 하면 끝

 

스프링 부트 (Spring Boot)

스프링을 기반으로 하지만, "실행만 하면 바로 서비스가 가능한(Just Run)" 수준의 애플리케이션을 만들기 위해 탄생한 도구다.

스프링의 복잡한 설정을 자동화하여 개발 생산성을 비약적으로 높였다.

 

구분	스프링 (Spring)	스프링 부트 (Spring Boot)
의존성 관리	각 라이브러리의 버전과 호환성을 개발자가 직접 관리 (spring-core, spring-web 등)	Starter 의존성을 통해 관련 라이브러리 세트를 버전 호환성 고민 없이 한 번에 관리
구성/설정	XML이나 @Configuration 자바 코드로 모든 설정을 직접 작성해야 함	Auto-Configuration (자동 설정) 기능을 통해 공통적인 설정을 자동으로 처리함
내장 서버	별도의 WAS(Tomcat 등)를 설치하고 WAR 파일로 배포해야 함	내장 서버(Embedded Tomcat 등)를 포함하고 있어 JAR 파일만으로 바로 실행 가능
모니터링	지원 기능 없음 (별도 구현 필요)	Actuator를 통해 애플리케이션의 상태, 로그 래벨, 메트릭 등을 쉽게 확인 가능

 

면접 답변식 요약

가장 큰 차이점은 '설정의 자동화'와 '독립 실행 가능 여부'입니다.

첫째, 의존성 관리 측면입니다. 스프링은 각 라이브러리의 버전 호환성을 직접 맞춰야 했지만, 부트는 'Starter'를 통해 필요한 라이브러리 조합을 한 번에 가져오고 버전 관리도 자동으로 해줍니다.

둘째, 설정 방식입니다. 스프링 부트는 Auto-Configuration 기능을 지원하여, 반복적이고 복잡한 Bean 설정을 개발자가 일일이 하지 않아도 프레임워크가 자동으로 처리해 줍니다.

셋째, 배포의 편의성입니다. 스프링은 별도의 WAS 서버에 WAR 파일을 배포해야 했지만, 스프링 부트는 내장 서버(Embedded Server)를 탑재하고 있어 단독 실행 가능한 JAR 파일만으로 어디서든 애플리케이션을 구동할 수 있습니다.

결론적으로 스프링 부트는 스프링의 복잡한 초기 설정 부담을 줄여주어, 개발자가 오로지 비즈니스 로직 구현에만 집중할 수 있도록 돕는 확장 프레임워크라고 할 수 있습니다.

 

번외
모니터링이 왜 필요한가?

애플리케이션 상태 확인 (Health Check)

서버가 단순히 '켜져 있는가'를 넘어, '정상적으로 서비스할 준비가 되었는가'를 확인한다.

• 데이터베이스(DB)와의 연결이 끊기지는 않았는지?
• 디스크 용량이 꽉 차서 로그를 못 쌓는 상황은 아닌지?
• 외부 API 서버와 통신이 가능한지? 등을 실시간으로 체크.

 

성능 지표 수집 (Metrics)

현재 서버가 얼마나 힘들어하고 있는지 수치로 확인한다.

• 메모리/CPU 사용량: 메모리 누수(Memory Leak)가 발생해 서버가 곧 죽을 위기인지 확인한다.
• 트래픽: 초당 요청 수(TPS)가 급증했는지, 응답 시간이 평소보다 느려졌는지 파악한다.

 

실시간 설정 변경 및 문제 해결 (Troubleshooting)

서버를 껐다 켜지 않고도 긴급한 조치를 취할 수 있다.

• 로그 레벨 변경: 에러가 발생했을 때, 서버 재시작 없이 로그 레벨을 INFO에서 DEBUG로 바꿔서 상세한 에러 로그를 확인할 수 있다.
• 스레드 덤프/힙 덤프: 서버가 멈췄을 때(Deadlock 등), 현재 어떤 코드가 CPU를 점유하고 있는지 스냅샷을 찍어 분석할 수 있다.

 

클라우드 및 마이크로서비스(MSA) 환경 대응

최근에는 수십, 수백 개의 서버를 띄우는 MSA 환경이 일반적이다. 관리자가 일일이 서버에 접속할 수 없으므로, Prometheus나 Grafana 같은 시각화 도구와 연동하여 모든 서버의 상태를 한눈에 관리하기 위해 모니터링 기능이 필수이다.

 

• MSA: 하나의 거대한 애플리케이션을 비즈니스 기능 단위(서비스)로 쪼개어, 각 서비스가 독립적으로 동작하게 만드는 방식이다. 각 서비스는 각자의 DB를 가지고 있으며, 서로 네트워크(API)를 통해 통신한다.
  
  • 장점: 필요한 부분만 수정하고 배포, 결제 서버가 터져도 로그인/조회 가능, 서비스마다 언어/DB 선택 가능(Ployglot), 주문량이 늘어나면 주문 서버만 증설
  • 단점: 배포
• 스프링 생태계에는 MSA를 쉽게 구현하도록 돕는 Spring Cloud라는 강력한 도구가 있다.
  • API Gateway: 여러 서버로 들어오는 요청을 한곳에서 받아 알맞은 서버로 전달해 주는 문지기.
  • Service Discovery (Eureka): 수십 개의 서버가 각각 어디에(IP주소) 있는지 자동으로 찾아주는 전화번호부.
  • Config Server: 여러 서버의 설정 파일들을 한 곳에서 관리하는 중앙 저장소.