가야태자의 IT이야기

안녕하세요! 가야태자 @talkit 입니다. 😊

지난 글까지 우리는 MacOS 환경에서 우여곡절 끝에 Java 1.8 엔진을 얹고, STS4 설치에 이어 감격의 스프링 부트(Spring Boot) Hello World 웹 서버를 구동하는 데 성공했습니다! 매번 익숙한 윈도우 환경에서만 개발 설정을 하다가, 맥북 터미널을 두들기며 실습해 보니 사소한 에러를 잡는 것도 아주 색다르고 재미있네요. ^^

단순히 화면에 글자 하나를 띄우는 HelloWorld 단계를 넘어서니, 이제 실무에서 사용하는 진짜 비즈니스 로직(데이터베이스 연동, 아키텍처 설계 등)을 추가하고 싶어지더군요. 그래서 본격적인 코드 작성에 앞서, 머릿속을 맴돌던 몇 가지 근본적인 궁금증들을 정리해 보았습니다.

1. 전통적인 Spring MVC와 순수 Spring Boot 설정은 구체적으로 무엇이 다른가? (그 많던 XML들은 다 어디로 갔나?)
2. 사람들은 왜 유독 Spring Boot를 두고 '클라우드 친화적(Cloud-Friendly)'이라고 부르는가?
3. 그렇다면 기존 Spring MVC는 도커(Docker)나 쿠버네티스(Kubernetes) 같은 현대적인 클라우드 환경으로 전환이 불가능한가?

오늘은 본격적인 아키텍처 설계에 들어가기 전, 이 궁금증들을 아주 명쾌하고 쉽게 풀어보는 시간을 가져보겠습니다!

1. Spring MVC vs Spring Boot 설정의 차이: "설정 지옥의 해방"

전통적인 Spring MVC(예: 전자정부프레임워크 등)로 비즈니스 프로젝트를 시작하려면, 코드를 짜기도 전에 엄청난 양의 환경 설정에 지치곤 했습니다.

applicationContext.xml, spring-mvc.xml, context-datasource.xml 등 거대하고 복잡한 XML 파일들을 매번 복사해 와서 데이터베이스 커넥션 풀(DBCP)을 셋팅하고, 컴포넌트 스캔 범위를 지정해야 했죠. 오타라도 하나 나면 컴파일 시점엔 알 수도 없고 런타임 에러를 뿜어내기 일쑤였습니다.

하지만 Spring Boot는 이 패러다임을 완전히 바꿨습니다. 부트에는 스프링 관련 설정을 위한 XML 파일이 단 하나도 필요 없습니다!

스프링 부트는 "설정보다는 관례(Convention over Configuration)"를 내세웁니다.

• 자동 설정(Auto Configuration): spring-boot-starter-web 라이브러리를 추가하는 순간, 부트가 내부적으로 "아, 이 개발자가 웹 서버를 만드는구나!" 하고 내장 톰캣 서버, JSON 변환기, 문자 필터 등을 알아서 자바 코드로 셋팅해 줍니다.
• 프로퍼티 중심 제어: 과거 복잡했던 데이터소스(DB 접속) 설정은 이제 application.properties 파일에 딱 세 줄, 드라이버 이름과 URL, 계정 정보만 적어주면 끝납니다.
• 개발자는 인프라 설정에 힘을 뺄 필요 없이 오직 비즈니스 로직(Controller - Service - DTO - Mapper)에만 100% 집중할 수 있게 된 것이죠.

2. Spring Boot는 왜 '클라우드 친화적'일까?

최근 실무 백엔드 인프라의 대세는 AWS 같은 클라우드 환경입니다. 그리고 클라우드 세상에서 스프링 부트는 독보적인 위치를 차지하고 있습니다. 왜 그럴까요?

① 내장 WAS를 품은 '독립 실행형 JAR' (이식성)

레거시 Spring MVC는 빌드하면 WAR 파일이 나옵니다. 이 파일은 혼자서 실행할 수 없고, 클라우드 서버마다 외부 웹 서버(Tomcat)를 따로 설치하고 설정을 맞춘 뒤에 그 안에 '주입(Deploy)'해야 구동됩니다.
반면, Spring Boot는 웹 서버(Tomcat)를 자바 패키지 내부에 아예 내장하고 있습니다. 빌드하면 웹 서버가 포함된 단 하나의 JAR 파일이 툭 떨어집니다. 클라우드 서버에 자바만 깔려 있다면 java -jar app.jar 명령어 한 줄로 즉시 어디서든 똑같이 구동됩니다. 인프라 의존성이 사라진 것입니다.

② 압도적인 구동 속도와 가벼움 (오토스케일링 최적화)

클라우드의 핵심은 사용자가 몰릴 때 서버를 순식간에 수십 대로 늘리는 오토스케일링(Auto Scaling)입니다. 레거시 시스템은 톰캣을 켜고 WAR 압축을 풀고 비대한 XML을 읽느라 서버가 준비되는 데 수십 초에서 수분이 걸렸습니다.
하지만 스프링 부트는 불필요한 인프라 구조를 걷어내고 자바 코드로 즉시 기동하므로 구동 속도가 극도로 빠릅니다. 클라우드가 명령하는 즉시 트래픽을 받아낼 준비를 마칩니다.

③ 모니터링 기능(Actuator) 기본 내장

수많은 서버가 분산되어 있는 클라우드 환경에서는 서버 상태 감시가 필수입니다. 스프링 부트는 Actuator 라이브러리를 통해 현재 서버의 메모리 상태, DB 커넥션 풀 상태 등을 확인할 수 있는 모니터링 창구를 코딩 한 줄 없이 기본으로 제공해 줍니다.

3. 그럼 Spring MVC는 도커나 쿠버네티스를 사용하지 못하나요?

결론부터 말씀드리면, 당연히 사용할 수 있습니다! 꼭 스프링 부트만 써야 도커/쿠버네티스를 쓸 수 있는 것은 아닙니다.

도커(Docker)와 쿠버네티스(Kubernetes) 입장에서는 컨테이너 안에 담긴 프로그램이 옛날 스프링인지 최신 스프링 부트인지 상관하지 않습니다. 표준 규격만 맞추면 어떤 프로그램이든 다 담아서 굴려줍니다. 실제로 수많은 기업들이 기존에 운영하던 거대한 레거시 Spring MVC 시스템을 그대로 도커 이미지로 패키징하여 쿠버네티스 환경으로 이주(Migration)시켜 운영하고 있습니다.

다만, 장점을 활용하는 효율성의 차이가 존재합니다.

• Spring MVC를 도커에 올릴 때: 도커 이미지 안에 우분투 OS를 깔고, 외부 톰캣 서버를 설치하는 스크립트를 짜고, 거기에 WAR 파일을 복사해 넣어야 하므로 도커파일(Dockerfile)이 복잡해지고 이미지의 크기가 무거워집니다. 쿠버네티스가 컨테이너를 복제하거나 자가 치유(Heal)를 할 때도 구동 속도가 느려 굼뜨게 반응합니다.
• Spring Boot를 도커에 올릴 때: 순수한 자바 환경 이미지에 JAR 파일 하나만 복사해 넣으면 끝납니다. 이미지 크기가 매우 가볍고, 쿠버네티스의 헬스 체크(Liveness/Readiness Probe)와 부트의 Actuator 기능이 찰떡처럼 연동되어 시스템 자가 치유 능력이 극대화됩니다.

즉, "도커와 쿠버네티스는 Spring MVC라는 옛날 자동차도 트레일러에 실어서 얼마든지 움직여줄 수 있다. 다만, 처음부터 컨테이너 비행기에 쏙 들어가도록 규격화되어 설계된 Spring Boot를 태웠을 때 훨씬 더 가볍고 안전하게 날아갈 수 있다"고 이해하시면 좋습니다!

🏁 가야태자의 요약 및 예고

결과적으로, 기존의 복잡한 인프라 환경을 다루어보신 분들이라면 스프링 부트가 제공하는 이 간결함과 클라우드 네이티브(Cloud Native)적인 특성에 감탄할 수밖에 없습니다. 과거의 자동차 조립 단계 같은 설정을 뒤에서 부트가 다 알아서 해주니까요.

궁금증이 시원하게 해결되었으니, 다음 글에서는 진짜 실무 아키텍처의 뼈대를 세워보겠습니다!
우리가 설치한 자바 1.8 환경에 딱 맞춰서 Controller - Service - DTO - Mapper - MyBatis - DB까지 이어지는 표준 5계층 아키텍처의 패키지를 쪼개고 실제 소스 코드를 채워 컴파일하는 실전 과정으로 찾아오겠습니다.

환경 설정을 진행하시면서 궁금한 점이나 의견이 있으시면 언제든 댓글로 편하게 소통해 주세요. 감사합니다! bananas 🍌