🥾스프링 부트 소개: 설정의 늪에서 생산성의 혁명으로

1. Spring Boot의 혁신과 현대적 발전

Spring의 환경 설정(XML, 의존성 꼬임 등) 진입 장벽이 너무 높아지자, 이를 해결하고 현대적인 마이크로서비스 및 가벼운 배포 환경을 구축하기 위해 Spring Boot가 등장함. (참고: Boot 자체는 뛰려면 먼저 부츠 끈을 묶어야 한다에서 유래)

1) Spring Boot의 3대 편의성

1. 자동 구성 (아래 추가 설명)
   • pom.xml이나 build.gradle에 특정 라이브러리가 존재하면, 강력한 관례(Convention)를 기반으로 스프링이 알아서 관련 빈(Bean)과 설정을 자동으로 구성.
2. 내장 서버 (Embedded Tomcat)
   • 외부 WAS(Tomcat 등)를 별도로 설치하고 WAR 파일로 빌드하여 배포할 필요가 없음. 애플리케이션 내부에 톰캣이 내장되어 있어, 단독 실행 가능한 .jar 파일 하나만으로 어디서나 즉시 구동할 수 있음.
3. * Starter 의존성을 통한 *버전 관리 자동화 (spring-boot-starter-*)
   • 스프링 부트의 전유물이며, 복잡한 라이브러리들과 그에 맞는 호환 버전을 스타터 팩 하나로 묶어 제공하여 버전 충돌 문제를 해결한다. Spring Initializr 웹사이트에서 쉽게 구성 가능.
   • 스타터 시리즈의 버전은 항상  스프링 부트의 버전을 따라간다. 이 스타터가 내부적으로 가져오는 핵심 스프링 프레임워크(Spring Core, Web 등)의 버전은 2~3 정도 차이난다.

✨ Dependency Descriptor (의존성 설명자): Starter 시리즈

 

1) spring-boot-starter 개념

• 애플리케이션에 특정 기능(예: 웹, 데이터베이스 등)을 추가할 때 필요한 라이브러리들을 한데 묶어놓은 편리한 의존성 설명자 모음.
• 샘플 코드를 참고하며 수많은 복사, 붙여넣기를 할 필요 없이, 스타터 하나만 추가하면 관련 기술이 한 번에 세팅됨.

2) 주요 스타터 특징 및 용어

• 전이적 종속성 (Transitive Dependency): 내가 직접 의존성을 추가하지 않았더라도, 내가 추가한 라이브러리가 작동하기 위해 내부적으로 다시 의존하는 하위 라이브러리들까지 세트로 함께 관리 및 설치되는 개념.
• 💡자동 완성 팁: Eclipse나 STS(Spring Tools Suite) 플러그인이 설치되어 있다면, POM 편집기에서 spring-boot-starter-까지 입력한 후 Ctrl + Space를 누르면 전체 목록을 확인(락다운 형식)할 수 있음.

💡  Starter 자원 관리 및 버전 제어 (BOM & Parent)

 

과거 레거시 스프링 시절에는 웹 페이지 하나를 띄우려고 해도 톰캣 서버 라이브러리, Spring MVC 라이브러리, JSON 변환기 라이브러리 등을 버전까지 수동으로 매칭해야 했음 (하나라도 안 맞으면 에러)

 

1) BOM (Bill of Materials)

• 스프링부트가 내부적으로 미리 테스트해서 각 릴리스(버전)마다 함께 사용했을 때의 호환성을 검증한 서드파티 라이브러리 및 Spring 모듈들의 최적화된 버전 조합 (spring-boot-dependencies) 명세서.
• 이점: 개발자가 라이브러리의 버전을 일일이 맞출 필요 없이, Spring Boot가 보증하는 안정적인 버전 조합을 자동으로 적용(자동 관리)받을 수 있음. 필요한 경우 특정 버전을 직접 지정하여 덮어쓰는 것도 가능.
• 포함 기술 예시(의견기반): Spring Framework, Jackson(JSON 처리), Tomcat(웹 서버), Hibernate(ORM), Logback(로깅) 등.

ℹ️ 기업 관점의 BOM: 기업 내에서 여러 마이크로서비스(MSA)나 프로젝트를 진행할 때, 팀마다 라이브러리 버전을 다르게 쓰면 호환성 문제가 발생. 따라서 회사 차원에서 표준화된 라이브러리 버전 집합(Custom BOM)을 지정해 두고 모든 프로젝트가 이를 따르도록 강제하는 중앙 집약적 버전 통제 플랫폼의 역할을 함.

 

2) Parent (부모 POM)

• Maven 등 환경(pom.xm 등)에서 <parent> 태그 설정을 통해, 단순히 실제 일반 의존성(Dependency)을 직접 상속받는 것이 아니라, 버전 관리를 위한 dependencyManagement를 상속받아 프로젝트 전체의 라이브러리 버전을 중앙에서 자동 관리하는 구조를 취함. (빌드 시스템에서 부모 standard 설정을 상속받는 구조)
  • 이는 라이브러리를 프로젝트에 직접 다운로드하는 것이 아니라, 앞으로 이 라이브러리를 쓸 거라면 이 버전을 사용하라고 버전만 정의해 두는 것. 실무에서는 이를 통해 전이적 종속성(하위 의존성: 의존성이 의존하는 라이브러리)의 버전까지 깔끔하게 자동 관리된다. (내부적으로 dependencyManagement가 작동)

 3) 전이적 종속성 작동 방식

1. 빌드 파일 상단에서 스프링 부트 버전을 하나만 정의(결정)
2. 예시: 개발자가 spring-boot-starter-web 가져오고자 함
3. 그러면 이 스타터가 내부적으로 웹 만드는 기능과 관련된 하위 수십가지 라이브러리를 가져옴 
   • 톰캣, Jackson(JSON 직렬화), WebMVC 등 수십 개의 하위 라이브러리를 호환성이 검증된 버전 세트로 한 번에 싹 다운로드해 줌
   • 그에 맞는 starter들과 내부 스프링 프레임워크 버전이 알아서 세트로 맞춰짐.
4. 결론: 스타터 뒤에 '버전 숫자'를 적지 않고서 버전이 맞춰짐
   • 스프링 부트 버전(예: 3.3.0)이 부모 가이드라인이 되어, 모든 스타터 시리즈의 버전을 자동으로 통제하기 때문

4) 실무에서 가장 많이 쓰는 대표적인 스타터들 (목적에 따라 추가)

• spring-boot-starter-web: RESTful API나 전통적인 웹 애플리케이션을 만들 때 씀. (내장 내장 톰캣 포함)
• spring-boot-starter-data-jpa: 데이터베이스와 자바 객체를 연결해 주는 강력한 ORM(JPA/Hibernate) 환경을 한방에 세팅.
• spring-boot-starter-security: 로그인, 권한 제어, CSRF 방어 등 필수 보안 기능을 필터 방식으로 일괄 처리하는 보안팩.
• spring-boot-starter-actuator: 현재 작성 중이신 글에도 강조되어 있듯, 운영(Remote) 환경에서 서버가 잘 돌아가고 있는지 모니터링하고 상태를 체크할 때 필수적인 부트 전용 모니터링 팩.

2) 운영 및 구동 메커니즘의 특징

• 운영 편의성 제공 (Actuator 등)
  • Actuator: 운영 환경(Remote)에서 웹 애플리케이션의 상태 체크, 모니터링, 메트릭 수집/측정 등 프로덕션 환경 운영에 필요한 핵심 기능을 기본 내장하여 제공. (쿠버네티스나 모니터링 툴과 연동할 때 필수로 추가)
  • 아래 접은글 추가 정리
• 서블릿 기반 구조
  • Spring Boot가 아무리 편리한 추상화와 자동 설정을 제공하더라도, 내부적으로는 여전히 전통적인 서블릿(Servlet) 형태와 DispatcherServlet을 기반으로 동작하는 안정적인 웹 메커니즘을 그대로 계승.

ℹ️ 실무 관점의 주요 디펜던시/기술 활용 정리

 

	디펜던시/기술(스타터/라이브러리) 비고
Actuator	Remote 환경에서 웹 애플리케이션 모니터링 시 필수
Validation	컨트롤러 인입 데이터의 유효성 검증용 (spring-boot-starter-validation으로 제공되는 유효성 검증 팩)
JPA (Data JPA/Hibernate)	Data-JDBC나 수동 호스트 SQL 대신 사용(생산성과 강력한 ORM 기능 때문), 관리형 전이적 종속성 세트
OAuth-Client	소셜 로그인 등 구현용 / 외부 전문 솔루션(SaaS/픈소스/클라우드)을 가져다 쓰는 것이 대세이기 때문에 Authorization Server(자체 인증 서버)는 미사용  (spring-boot-starter-oauth2-client로 제공)
Security	세션/토큰 기반 인증, URL 수준의 인가 제어, CSRF 및 CORS 방어 등 엔터프라이즈 운영에 필수적인 보안 기능을 가로채기(Filter) 방식으로 일괄 처리
WebMVC	옛날 방식이지만 여전히 쓸 수 있음 (상황에 따라 판단) (spring-boot-starter-web 내부에 포함되어 동작하는 핵심 모듈)
Tomcat / Netty	기본 내장 웹 서버 및 비동기 서버 내장 (각각 spring-boot-starter-web(톰캣 기본 내장) 또는 spring-boot-starter-webflux(네티 기본 내장)의 스타터를 통해 자동 주입되는 내장 서버 스타터 팩 구조)
Kafka	RabbitMQ나 ActiveMQ 대신 카프카 채택 (대용량 트래픽 및 이벤트 기반 아키텍처(EDA)가 주류) ※ 이벤트 기반 메시징 (MSA): Kafka 스타터 (RabbitMQ/ActiveMQ 대체 기술) ※ 애플리케이션과 애플리케이션 사이에서 데이터를 안전하게 중계해 주는 메시지 브로커이자 데이터 스트리밍 미들웨어 성격을 가짐 (완성된 화면이나 기능 제공 X, 시스템 아키텍처의 중간 레이어 역할)
Jackson	JSON 객체 직렬화/역직렬화(마샬링) 표준 ※ JSON 직렬화를 담당하는 독립 오픈소스 라이브러리 (부트 웹 스타터가 내부적으로 당겨서 씀)
Elasticsearch	검색 엔진용 ※ 데이터를 중계하는 것을 넘어, 데이터 저장, 역색인 검색, 분석, 그리고 Kibana와 연동한 시각화까지 통으로 제공하는 분산 검색 엔진 솔루션 플랫폼
기타	AspectJ(AOP 관련 라이브러리), Batch, Flyway, Freemarker/Templates(GraphQL 희망), HATEOAS, Integration, Liquibase, Artemis(JMS 구현체, X), MongoDB, Hazelcast, JMS(개념), Zipkin 등

---

2. Spring Boot 핵심 작동 원리

1) 자동 구성 (Auto-Configuration)

Spring Boot의 가장 강력한 기능으로, 개발자가 복잡한 설정을 하지 않아도 추가된 jar(디펜던시)를 기반으로 내장 서버와 Spring 환경을 자동으로 추측하여 구성해 줌.

• spring-boot-starter-web이 있으면 톰캣 서버와 Spring MVC가 필요한 것으로 판단하고 자동으로 세팅함.
• 내부 메커니즘: spring-factories 파일 내에 자동 구성(autoConfiguration)을 위한 키값들이 정의되어 있음.
• 단점: 모든 과정이 추상화되어 가려져 있기 때문에, 에러 발생 시 추적과 문제 해결이 까다로울 수 있음.

2) 핵심 어노테이션 정의

1. @SpringBootApplication
   • 최상위 메인 클래스에 단 한 번 선언.
   • 3가지 핵심 메타 어노테이션의 조합:
     1. @EnableAutoConfiguration: 종속성 라이브러리 기반 자동 구성 지시
     2. @ComponentScan: 컴포넌트 스캔 범위를 지정 (해당 클래스가 있는 최상위 패키지부터 하위 패키지까지 검색)
     3. @SpringBootConfiguration: Spring Boot 설정을 담당
2. 스테레오 타입 (Stereotype):
   • 각 소스코드 구성 요소가 어떤 역할과 책임(라벨)을 가지는지 명시하는 메타 어노테이션.
   • @Component를 기반으로 하며, @Service, @RestController 등이 이에 해당.
   • @RestController는 @Controller와 @ResponseBody를 합친 스테레오 타입.

---

3. Spring Boot의 컴포넌트 스캔 자세히

1) 변화점

이제 AnnotationConfigApplicationContext를 직접 코드로 작성하여 사용하는 방식은 거의 쓰이지 않음. 스프링 부트를 사용하면서 SpringApplication.run() 호출 한 줄로 이 모든 과정이 자동화되기 때문.

2) @ComponentScan의 효율적인 위치 선정

• @ComponentScan은 보통 @Configuration과 함께 사용됨.
• 최상위 레벨 패키지 배치: 메인 애플리케이션 클래스를 프로젝트 패키지의 최상위 루트(상위 레벨)에 위치시키는 것이 관례.
• 이렇게 하면 하위(sub) 패키지들을 스프링이 자동으로 모두 뒤져서 컴포넌트를 등록하므로, 별도로 스캔 경로를 지정하지 않아도 됨.

---

4. 레거시 웹 방식 vs Spring Boot 차이점

	레거시 웹 방식 (Legacy Web)	Spring Boot 방식
톰캣 서버	외부에서 아파치 톰캣을 직접 다운로드하고 IDE에 경로 및 포트를 수동 설정해야 함	임베디드 톰캣(Embedded Tomcat) 형태로 Web 라이브러리 내부에 서버가 포함되어 있음
구동 방식	특정 폴더에 서블릿 코드(Jakarta Servlet)를 작성하여 외부 톰캣에 올려 호스팅함	별도 설치 없이 애플리케이션 실행만으로 내장 톰캣이 자동으로 구동됨
코드 제어	Tomcat tomcat = new Tomcat(); 등 서버 인스턴스를 직접 생성하거나 복잡한 XML 설정 필요	@SpringBootApplication과 run() 메서드 한 줄로 자동 구동 및 IoC 컨테이너 설정 완료

• 트러블슈팅 노트: 터미널에서 mvn spring-boot:run 실행 시 mvn: command not found 에러가 발생한다면, STS4 등 IDE 내장 메이븐이 아닌 운영체제(OS) 자체에 별도의 Maven 설치 및 환경변수 설정이 누락되었기 때문.

---

5. 현대 자바/스프링 생태계의 진화 과제 (미래 기술 트렌드)

아래는 클라우드 네이티브 환경과 대규모 트래픽 처리를 위해 최근 몇 년간 도입된 자바/스프링 진영의 최신 트렌드이자 미래 기술 과제들.

1) 대규모 트래픽과 성능 혁신

• 동시성 혁신: 가상 스레드 (Virtual Threads)
  • 자바의 전통적인 스레드 모델(OS 스레드와 1:1 매핑)의 한계를 극복하기 위해 도입. 매우 가볍고 메모리 오버헤드가 적어, 스레드 고갈 걱정 없이 대규모 동시성 요청을 효율적으로 처리 제어 가능.
•  리액티브 프로그래밍 (Reactive)
  • 선언형 스타일의 비동기/논블로킹 스트림 처리를 지원하여, 적은 자원으로도  높은 처리량을 낼 수 있도록 도움.
• 성능 최적화: AOT 컴파일과 GraalVM
  • JIT(실행 시 컴파일)의 한계: 기존 HotSpot VM 방식으로, 실행 시점에 바이트코드를 기계어로 바꾸기 때문에 초반 부팅 속도가 다소 느리고 메모리 소모가 있음.
  • AOT(Ahead-Of-Time) 컴파일 & GraalVM: 빌드 시점에 미리 기계어로 변환하여 부팅 속도를 획기적으로 끌어올림. 초고속 부팅이 생명인 서버리스(Serverless) 및 MSA 환경의 필수 과제. (매우 유리)

2) 관측 가능성 (시스템 안정화)

• 모니터링: Micrometer
  • 시스템 메트릭 측정을 위한 표준 도구. 애플리케이션의 성능과 JVM 상태를 정밀하게 모니터링하고 시각화할 수 있는 기반을 제공하여 클라우드 환경의 필수재가 됨.