소개
Spring Boot는 Spring 플랫폼을 빠르게 시작하고 운영 환경에 맞게 구성하기 쉽게 해주는 프레임워크입니다. 자동설정(auto-configuration), 스타터(starter) 의존성, 프로퍼티 기반 구성, 실행 가능한 JAR 구조 등의 핵심 아이디어를 통해 개발 생산성을 높입니다. 이 글에서는 안정적인 개념을 설명하고, 주요 설계 선택에서의 트레이드오프를 정리한 뒤, 간단한 실전 예제를 제공합니다.
핵심 개념 정리
Spring Boot의 핵심 요소는 다음과 같습니다.
1) 자동설정 (Auto-configuration)
애플리케이션의 클래스패스와 설정을 바탕으로 필요한 빈을 자동으로 구성합니다. 이는 초기 구성 작업을 크게 줄여주지만, 때로는 개발자가 명시적으로 제어해야 하는 상황이 생깁니다.
2) 스타터 (Starters)
spring-boot-starter-web, spring-boot-starter-data-jpa 등 목적별 의존성 묶음을 제공합니다. 번들 형태로 필요한 라이브러리를 한 번에 추가할 수 있어 편리합니다.
3) 프로퍼티/프로파일 (application.yml/properties & profiles)
환경별 설정을 properties 또는 YAML로 관리하고, Spring 프로파일을 이용해 환경(개발/스테이징/운영)에 따라 다른 설정을 적용할 수 있습니다.
4) 실행 가능한 아티팩트
Spring Boot는 실행 가능한 'fat JAR' 형태로 패키징하여 의존성을 포함한 단일 배포 파일을 만들 수 있습니다. 또한 레이어드 도커 이미지를 지원해 캐시 효율을 높일 수 있습니다.
5) 운영 기능 (Actuator 등)
헬스체크, 메트릭스, 설정 노출, 환경 정보 등을 제공하는 Actuator 모듈로 운영 가시성을 확보할 수 있습니다.
주요 트레이드오프
Spring Boot는 많은 편의를 제공하지만, 설계와 운영에서 고려해야 할 선택지들이 있습니다.
단순화 vs 제어
자동설정은 빠른 시작을 돕지만, 내부에서 어떤 빈이 생성되는지 이해하지 못하면 문제 해결이 어려워질 수 있습니다. 복잡한 환경에서는 자동설정을 일부 비활성화하고 명시적 설정을 선호할 수 있습니다.
Fat JAR vs Modular/Layered Images
Fat JAR은 배포가 쉽지만 이미지층(layer)을 나누지 않으면 도커 빌드 캐시를 활용하기 어렵습니다. 레이어드 JAR/이미지를 사용하면 반복 빌드에서 종속성 레이어를 재사용해 빌드 시간을 절약할 수 있습니다.
Monolith vs Microservices
Spring Boot는 모놀리식 앱에서 작은 마이크로서비스까지 폭넓게 사용됩니다. 작은 서비스로 분리하면 배포 독립성과 확장성이 좋아지지만, 운영 복잡성과 네트워크 비용(지연, 회복 등)이 증가합니다. 팀 조직, 배포 파이프라인, 모니터링 상태를 고려해 선택하세요.
Servlet(블로킹) vs Reactive(비동기)
spring-boot-starter-web은 전통적인 서블릿(블로킹) 모델, spring-boot-starter-webflux는 리액티브(비동기, 논블로킹) 모델을 제공합니다. I/O 집약적이고 동시 요청이 매우 높은 경우 리액티브가 유리할 수 있지만, 라이브러리 호환성과 개발 복잡성이 증가합니다. CPU 바운드 작업이 많은 경우 리액티브의 이점이 제한적입니다.
JVM 실행 vs Native (AOT)
GraalVM 기반 네이티브 이미지는 빠른 시작 시간과 낮은 메모리 사용을 제공하지만, 빌드 복잡도, 일부 라이브러리 제한(리플렉션 등), 디버깅 어려움 등 비용이 있습니다. Spring에서는 AOT와 네이티브 빌드를 지원하는 도구가 발전했지만, 모든 프로젝트에 기본 선택은 아닙니다. 서버리스 또는 콜드 스타트가 중요한 환경에서는 네이티브를 고려하세요.
간단한 실전 예제: REST 서비스 만들기
아래 예제는 최소한의 Spring Boot REST 애플리케이션입니다. Java 17 이상을 권장합니다.
1) 기본 애플리케이션 클래스
package com.example.demo;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class DemoApplication {
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
}
2) 간단한 컨트롤러
package com.example.demo.web;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
record Greeting(String message) {}
@RestController
@RequestMapping("/api")
public class HelloController {
@GetMapping("/hello")
public Greeting hello() {
return new Greeting("Hello from Spring Boot");
}
}
3) application.properties 예시
server.port=8080
management.endpoints.web.exposure.include=health,info
4) 간단한 Maven 의존성(핵심만 발췌)
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
</dependencies>
5) 간단한 Dockerfile (멀티스테이지)
FROM maven:3.9.0-openjdk-17 AS build
WORKDIR /workspace
COPY pom.xml .
COPY src ./src
RUN mvn -B -DskipTests package
FROM eclipse-temurin:17-jre-jammy
EXPOSE 8080
COPY --from=build /workspace/target/demo-0.0.1-SNAPSHOT.jar /app/app.jar
ENTRYPOINT ["java","-jar","/app/app.jar"]
6) 실행
# 로컬 빌드 및 실행
mvn -DskipTests package
java -jar target/demo-0.0.1-SNAPSHOT.jar
# 도커 빌드/실행
docker build -t demo-app .
docker run -p 8080:8080 demo-app
운영/성능 관련 실무 팁
- 프로파일을 활용해 dev/test/prod 설정을 분리하세요. 민감 정보는 환경 변수나 Vault 같은 비밀관리 솔루션으로 관리합니다.
- Actuator는 운영에 유용하지만 노출 범위를 제한하고 인증을 적용하세요.
- 컨테이너 이미지는 가능한 한 레이어를 분리(의존성 / 애플리케이션 코드)하여 CI 빌드 캐시를 활용하세요.
- 메모리와 GC 설정은 프로덕션에서 측정과 튜닝이 필요합니다. 기본 설정으로 충분하지 않은 경우가 많습니다.
- 네이티브(AOT)는 스타트업/메모리 이점이 큽니다만, 빌드 시간 증가와 런타임 제약을 고려하세요. 테스트와 호환성 검증이 필수입니다.
결론
Spring Boot는 빠른 개발과 운영 편의성을 제공하는 강력한 플랫폼입니다. 그러나 자동화와 추상화의 이면에 있는 동작을 이해하고, 애플리케이션 요구사항(성능, 확장성, 운영 비용 등)에 맞는 설계 결정을 내려야 합니다. 위에서 소개한 예제와 트레이드오프 관점이 실무 적용에 도움이 되길 바랍니다.