스프링 부트는 빠르고 간편하게 웹 애플리케이션을 개발할 수 있는 자바 기반 프레임워크로, 내장 WAS를 통해 독립 실행형 애플리케이션 형태로 제공됩니다.
이는 별도의 WAS 설치 없이 Tomcat, Jetty와 같은 서버를 포함하여 실행되기 때문에 설정과 배포 과정이 단순합니다. 하지만 외부 WAS와 비교하면 고급 관리 기능(예: 세션 복제, 로드 밸런싱)에서는 제한적일 수 있습니다.
내장 WAS의 장점은 독립 실행 및 배포 간소화, 빠른 테스트 환경 제공에 있고, 단점은 고도화된 WAS 기능을 활용하기 어렵다는 점입니다.
반면, 외부 WAS는 대규모 시스템 환경에서 유리하며 고급 기능을 제공하지만 배포와 관리가 더 복잡합니다.
HTTPS를 설정할 때는 Let's Encrypt와 같은 무료 SSL 인증서를 활용해 자동 갱신할 수 있으며, 클라우드 환경에서는 관리형 SSL 서비스를 통해 보안을 강화할 수 있습니다.
이 글에서는 스프링 부트가 내장 WAS와 외부 WAS에서 각각 어떻게 동작하는지, 그리고 REST API에서 HTTPS를 설정하는 방법을 다뤘습니다.
애플리케이션 환경에 맞는 적절한 방식을 선택해 효율적인 개발과 운영을 경험해 보세요!
스프링 부트(Spring boot) 프레임 워크의 특징
스프링 부트(Spring Boot)는 전통적인 의미에서 WEB 또는 WAS(Web Application Server)로 정확히 분류되지는 않습니다. 대신 스프링 부트는 웹 애플리케이션 개발을 위한 프레임워크이며, 내장된 WAS 기능을 포함합니다. 이를 자세히 설명하면 다음과 같습니다:
1. 스프링 부트의 특징
- 스프링 부트는 프레임워크다
스프링 부트는 개발자가 빠르게 애플리케이션을 개발할 수 있도록 도와주는 자바 기반 프레임워크입니다. 기본적으로 스프링 프레임워크의 확장판으로, 복잡한 설정 없이 애플리케이션을 개발할 수 있습니다.
- 내장 WAS 포함
스프링 부트는 기본적으로 Tomcat, Jetty, Undertow와 같은 WAS를 내장하고 있어 별도의 외부 WAS 설치 없이 실행 가능한 애플리케이션을 제공합니다. 예를 들어, spring-boot-starter-web 의존성을 추가하면 내장 Tomcat이 포함됩니다.
2. WEB과 WAS의 정의와 스프링 부트의 위치
- WEB
웹(Web)은 정적 HTML, CSS, JS와 같은 리소스를 제공하는 역할을 수행합니다. 단순히 HTTP 요청에 정적 파일을 반환하는 서버를 의미합니다.
- WAS
WAS(Web Application Server)는 동적인 웹 애플리케이션을 실행하고, 비즈니스 로직을 처리하며, 데이터베이스와 연동하는 서버입니다. 예를 들어, Tomcat, JBoss, WebLogic 등이 WAS에 속합니다.
- 스프링 부트
스프링 부트는 애플리케이션 개발을 위한 프레임워크이지만, 내장된 WAS 기능 덕분에 애플리케이션이 독립적으로 실행 가능한 형태로 패키징됩니다. 이는 스프링 부트가 WAS 역할도 수행 가능하다는 것을 의미합니다.
3. 스프링 부트는 어떻게 동작하는가?
- 내장 Tomcat/Jetty
스프링 부트는 기본적으로 내장된 WAS(Tomcat 등)를 통해 웹 애플리케이션을 실행합니다. 실행 가능한 JAR 파일로 빌드되며, 이를 실행하면 내장된 WAS가 애플리케이션과 함께 시작됩니다.
- 외부 WAS에 배포 가능
만약 별도의 WAS가 필요하다면, 스프링 부트 애플리케이션을 WAR 파일로 패키징하여 기존의 외부 WAS에 배포할 수도 있습니다.
4. 결론
- 스프링 부트 자체는 프레임워크입니다.
- 내장된 WAS를 포함하고 있어, 독립 실행형 애플리케이션 형태로 작동할 수 있습니다.
- 스프링 부트를 사용하는 애플리케이션은 WAS 역할도 수행 가능합니다.
스프링 부트의 내장 WAS vs 외부 WAS 사용의 장단점
내장 WAS를 사용하는 경우
장점
1. 독립 실행형 애플리케이션
JAR 파일로 패키징하여 내장 WAS와 함께 실행 가능하므로 별도의 WAS 설치나 설정이 불필요.
2. 배포 간소화
내장 WAS 덕분에 다른 서버 환경에 관계없이 동일하게 동작하므로 DevOps에 유리.
3. 빠른 개발 및 테스트
내장된 WAS를 통해 로컬에서 쉽게 테스트 가능.
4. 유지보수 용이성
WAS의 버전 관리가 애플리케이션에 통합되므로 버전 충돌 가능성이 줄어듦.
단점
1. 운영 환경 제약
특정 환경에서 고도로 커스터마이징된 WAS 설정(예: WebLogic, JBoss)이 필요하다면 내장 WAS가 적합하지 않을 수 있음.
2. 관리 도구 부족
기존의 외부 WAS가 제공하는 관리 기능(예: 클러스터링, 세션 관리)이 부족할 수 있음.
3. WAS 재시작 필요
애플리케이션 코드 변경 시 내장 WAS와 함께 다시 시작해야 하므로 작업 시간이 늘어날 수 있음.
외부 WAS에 배포하는 경우
장점
1. 전문 WAS 기능 활용
외부 WAS가 제공하는 고급 기능(예: 세션 복제, 고급 보안 설정, 관리 도구)을 활용 가능.
2. 운영 표준화
대규모 조직에서는 외부 WAS에 여러 애플리케이션을 표준화하여 관리하는 것이 유리.
3. 애플리케이션 분리
애플리케이션 코드와 WAS 설정이 분리되어 유지보수가 쉬움.
단점
1. 복잡한 설정
외부 WAS의 설정과 애플리케이션 배포 작업이 추가로 필요.
2. 배포 비효율
WAR 파일로 패키징해야 하며, 배포 시 WAS와 애플리케이션 간의 의존성이 증가.
3. 환경 종속성
WAS 설정이 서버 환경에 의존하므로 특정 WAS에 맞춘 애플리케이션 변경이 필요할 수 있음.
스프링 부트를 사용하여 REST API 서버를 구축할 때 고려해야 할 보안 설정
1. HTTPS 사용
HTTP 대신 HTTPS를 설정하여 데이터 암호화를 적용.
→ server.ssl.key-store, server.ssl.key-store-password 등을 설정.
2. CORS(Cross-Origin Resource Sharing) 설정
REST API가 다른 도메인에서 호출될 경우 CORS 정책을 명확히 설정.
→ @CrossOrigin 또는 CorsConfiguration 클래스 사용.
3. JWT 또는 OAuth2 인증
REST API의 인증 및 권한 관리를 위해 토큰 기반 인증(JWT)이나 OAuth2를 구현.
4. CSRF 보호 비활성화
REST API는 일반적으로 CSRF 공격에 덜 취약하므로 CSRF 보호를 비활성화.
→ http.csrf().disable().
5. Rate Limiting
DDoS 또는 과도한 요청 방지를 위해 API 호출 횟수 제한(예: API Gateway 사용).
6. 민감 정보 숨기기
애플리케이션 설정 파일에 암호나 API 키를 노출하지 않도록 .properties 또는 .yml 파일에서 암호화 또는 환경 변수를 사용.
7. 보안 헤더 추가
HTTP 응답에 X-Content-Type-Options, X-Frame-Options, Content-Security-Policy 등 보안 헤더를 설정.
8. 유효성 검증
입력값(특히 JSON 데이터)에 대해 유효성 검증을 철저히 수행하여 SQL Injection, XSS 등 방지.
내장 WAS를 사용하지 않고 외부 WAS에 스프링 부트를 배포하려면 필요한 작업
1. WAR 파일 생성
스프링 부트 애플리케이션이 기본적으로 JAR로 빌드되지만, 외부 WAS에 배포하려면 WAR 파일로 패키징해야 함.
@SpringBootApplication
public class Application extends SpringBootServletInitializer {
@Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) {
return builder.sources(Application.class);
}
}
2. 의존성 변경
pom.xml에 필요한 플러그인과 의존성을 추가
<packaging>war</packaging>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>provided</scope>
</dependency>
3. WAS에 배포
생성된 WAR 파일을 Tomcat, JBoss 등의 webapps 디렉토리에 복사하여 배포.
4. 컨텍스트 루트 설정
WAS에서 애플리케이션의 컨텍스트 루트를 설정(예: /my-app).
5. 설정 파일 관리
WAS 환경에 맞는 외부 application.properties 또는 application.yml 파일 준비.
내장 WAS의 동작 원리와 외부 WAS의 기술적 차이점
1. 내장 WAS의 동작 원리
스프링 부트는 내장 WAS(Tomcat, Jetty, Undertow 등)를 사용하여 애플리케이션과 WAS를 하나의 실행 가능한 JAR 파일로 패키징합니다. 실행 시 내장 WAS가 애플리케이션과 함께 시작되며, HTTP 요청을 처리합니다.
동작 과정
1. 애플리케이션이 실행되면 스프링 부트는 내장 WAS를 자동으로 초기화합니다.
2. DispatcherServlet을 통해 HTTP 요청을 처리하며, 애플리케이션의 컨트롤러로 요청을 전달합니다.
3. 내장 WAS는 애플리케이션과 같은 JVM 프로세스에서 동작하여 빠른 통신과 실행 환경을 제공합니다.
특징
- 애플리케이션의 코드와 WAS 설정이 하나로 통합됩니다.
- 빠르게 실행 가능하며 배포 환경 설정이 간소화됩니다.
- 별도의 WAS 설치가 필요하지 않으므로 독립적인 실행이 가능합니다.
2. 외부 WAS의 기술적 차이점
외부 WAS는 애플리케이션과 별도로 동작하며, WAS가 제공하는 고급 기능과 관리 도구를 활용할 수 있습니다. Tomcat, WebLogic, JBoss, WildFly 등이 외부 WAS의 예입니다.
동작 과정
1. 외부 WAS는 독립된 프로세스로 실행됩니다.
2. 스프링 부트 애플리케이션은 WAR 파일로 패키징되어 WAS에 배포됩니다.
3. 외부 WAS가 HTTP 요청을 수신하고, 이를 애플리케이션의 서블릿 컨테이너로 전달합니다.
특징
- WAS 설정과 애플리케이션이 분리되어 관리가 독립적입니다.
- 고급 관리 기능(예: 세션 복제, 로드 밸런싱, 트랜잭션 관리)을 제공합니다.
- WAS와 애플리케이션 간 네트워크 통신을 추가로 처리해야 하므로 성능에 약간의 영향을 줄 수 있습니다.
※ 기술적 차이 요약
| 특징 | 내장 WAS | 외부 WAS |
| 설치 여부 | 별도의 WAS 설치 불필요 | WAS 설치 필요 |
| 배포 형태 | 실행 가능한 JAR 파일로 패키징 | WAR 파일로 패키징 |
| 실행 환경 | 애플리케이션과 WAS가 같은 프로세스에서 실행 | WAS와 애플리케이션이 별도 프로세스에서 실행 |
| 관리 기능 | 제한적 | 세션 복제, 클러스터링, 로드 밸런싱 등 고급 기능 |
| 성능 | 네트워크 통신 오버헤드가 적음 | 네트워크 통신 필요로 인해 약간의 오버헤드 |
| 유연성 | 애플리케이션과 WAS가 밀접하게 통합 | 환경에 따라 애플리케이션 교체 및 관리 용이 |
스프링 부트 REST API에서 HTTPS 설정 시 SSL 인증서를 자동으로 갱신할 수 있는 방법
HTTPS를 사용하려면 SSL 인증서가 필요하며, 이를 자동으로 갱신하려면 다음과 같은 방법을 사용할 수 있습니다.
1. Let's Encrypt를 활용한 SSL 인증서 자동 갱신
Let's Encrypt는 무료로 SSL 인증서를 제공하며, 이를 자동 갱신할 수 있는 도구를 지원합니다.
Let's Encrypt
Let's Encrypt is a free, automated, and open certificate authority brought to you by the nonprofit Internet Security Research Group (ISRG). Read all about our nonprofit work this year in our 2023 Annual Report.
letsencrypt.org
- 자동 갱신 도구: Certbot
1) Certbot 설치: 서버에 Certbot을 설치합니다.
sudo apt-get install certbot
2) SSL 인증서 발급: Certbot을 사용하여 인증서를 발급받습니다.
sudo certbot certonly --standalone -d your-domain.com
3) Cron Job 설정: 인증서를 자동으로 갱신하고 스프링 부트를 다시 시작하도록 스크립트를 추가합니다.
0 0 * * * certbot renew --post-hook "systemctl restart your-springboot-service"
2. Spring Boot HTTPS 설정
발급받은 인증서를 스프링 부트 애플리케이션에 적용합니다.
- application.properties 설정
server.port=443
server.ssl.key-store=classpath:keystore.p12
server.ssl.key-store-password=yourpassword
server.ssl.key-store-type=PKCS12
- 키스토어 생성 Certbot으로 발급받은 인증서를 Java 키스토어로 변환
openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out keystore.p12 -name tomcat -CAfile chain.pem -caname root
3. 클라우드 환경에서의 SSL 자동 갱신
AWS, GCP, Azure와 같은 클라우드 환경에서는 Load Balancer를 통해 SSL 인증서를 관리할 수 있습니다.
- AWS: ACM(AWS Certificate Manager) 사용.
- GCP: Google Managed SSL 사용.
- Azure: App Service에서 HTTPS 적용 가능.
요약
- 내장 WAS는 독립적인 실행과 간소화를, 외부 WAS는 고급 기능과 확장성을 제공합니다.
- SSL 인증서를 자동으로 갱신하려면 Let's Encrypt + Certbot을 활용하거나 클라우드 환경에서 관리형 SSL 서비스를 사용하는 것이 효율적입니다.