"서버"가 아니라 "기능"을 띄우는 시대
AWS를 학습할 목적으로 설정해 볼 기회가 있었다.
익숙한 방식으로 접근했다.
Spring Boot 애플리케이션을 EC2에 올리면 되는거 아냐?
조금 더 알아보니.. 생각이 바뀌기 시작했다..
클라우드가 단순히 물리적인 (내가 직접 관리하는)서버 없이 인스턴스를 실행한다고만 생각했었는데
AWS는 인증, 배치, 스케일링 등 기존 서버 애플리케이션 또는 인프라가 제공하는 기능들을 서비스로 제공하고 있었다.
- 인증 -> Cognito
- 배치 작업 -> Lambda/ Fargate / EC2
더이상 "백엔드 = EC2 서버 1대"가 아님.
이런 맥락으로 기존에 서버 애플리케이션이 담당하던 일들을 클라우드가 지원해준다면,
애플리케이션 개발은 점점 더 핵심 기능에 집중 할수 밖에 없겠다는 생각이다.
특히, 생성형 AI 기반 코딩과 결합한다면,
"빠르게 유닛을 만들고, 클라우드에 배포하고, 최소 단위로 실험하는 개발 방식"이 새로운 생산성 향상 전략이 되지 않을까 싶다.
(극단적인 MSA 형태가 될것 같은데.. 테스트 환경을 별도로 구성하지 않으면, 쉽지 않겠다.. 로컬에서 Cognito를 테스트 한다거나, Lambda를 Mocking 한다거나, 기능단위로 쪼개진 코드를 통합해서 테스트 한다거나.. 추후 생각..)
이런 환경의 변화속에서도 스프링 기반 개발은 유용할까?
스프링은 편하다.. 편해도, 너무 편하다.
자바 백엔드 개발씬에서 스프링 생태계는 개발 생산성과 유지보수성을 담보해주는 독보적인 선택지임은 부정할 수 없는 사실이다.
- 수많은 예제와 레퍼런스
- 풍부한 커뮤니티와 기술문서
- Spring Security, Spring Data, Spring Cloud 등 일관성 있는 추상화
솔직히 이정도면 안쓰는게 이상하다.. 아니, 안쓴다는걸 상상하기 어렵다. (제 수준에서요..)
하지만, 이 편리함은 대가가 있다.
Spring은 편한 만큼 많은 리소스를 사용한다.
- 콜드 스타트 = 느린 기동 시간
- JVM 기반의 비교적 높은 메모리 사용량
- Serverless / Container 환경에서 고비용
대안이 있을까?
스프링은 개발하기 편한 대신, 클라우드에서 사용하기에 무겁고, 느리고, 비싸다..
환경의 변화에 대응하여, Quarkus, Micronut과 같은 클라우드 친화적인 프레임워크들이 등장했다. 이 프레임워크들은 GraalVM 기반 네이티브 이미지로 작동하면서 JVM의 제약을 넘어섰다.
- 빠른 기동 시간 (초 -> 밀리초)
- 메모리 사용량 (수백MB -> 수십MB)
- Container / Lambda 환경에 최적화
그렇다고 무조건 좋은점만 있는건 아니다.
- 긴 빌드 시간 - 네이티브 이미지로 기동하면서 기동시간 자체는 짧지만, 이미지를 생성하는 시간이 오래걸림(수 분 단위)
- 리플렉션 / 프록시 제약 (안되는건 아니지만, 설정이 번거로움..)
- 서드파티 라이브러리 호환성 이슈
- 스프링처럼 쉽게 가져다 쓸수 없음.
이런 단점은 한계가 아니라 성장과정이다. Quarkus, Micronaut는 단점들을 지속적으로 개선하고 있으며, 생태계도 확장중이다.
그럼, 스프링은 그대로 인가?
스프링이 네이티브 이미지를 원활하게 지원하지 못했던건 구조적인 문제였다.
스프링은 리플렉션, 동적 프록시, 빈탐색을 사용하면서 동적 구성에 많이 의존했다.
반면, GraalVM 기반의 네이티브 이미지는 주로 정적 분석만 가능하기 때문에 아래와 같은 문제가 발생했다.
- 리플렉션 - 미리 어떤 클래스에 접근할지 모르면 컴파일 할 수 없음.
- 동적 프록시 - 런타임에 만들어지는 프록시 객체 (AOT에선 불가능함).
- 빈 탐색 - @Autowired, @ComponentScan 동작이 제한됨.
때문에, 기존의 스프링 구조는 네이티브 이미지에 부적합했다.
그러나, Spring Boot 3.5 부터는 기존의 생산성을 유지하면서, GraalVM 기반의 네이티브 이미지를 안정적으로 지원하고 있다.
- Spring AOT엔진 안정화
- 컴파일 시점에 빈 구성, 리플렉션 정보 등을 미리 계산
- spring-aot, native hints 를 통해 자동으로 네이티브 대응 코드를 생성
- Spring 공식 스타터들이 네이티브 최적화
- spring-web, spring-security, spring-data등 핵심 모듈이 AOT 모드 대응
- 대부분의 spring-boot-srarter가 네이티브 환경에서 작동 가능
- GraalVM 네이티브 이미지 툴과 공식 연동
- spring-boot-plugin에 nativeImage 빌드 옵션이 포함됨
- 빌드툴에서 쉽게 빌드 가능
스프링의 생산성을 유지하면서도 네이티브의 성능을 확보할 수 있는 길이 열리고 있다!
(사실, 스프링 부트가 네이티브 이미지까지 완전하게 지원해준다면 내 입장에선 더할 나위 없겠다.. 테스트 할 가치가 높다고 생각.. 추후..)
결국, 선택은 "현실"을 기준으로 해야 한다.
기술은 늘 진화한다.
하지만, 새로운 기술이 언제나 "더 나은 선택"은 아니다.
- 시스템의 규모는 어떤지?
- 투입 가능한 개발 인력의 수준은 충분한지?
- 클라우드 사용 전략 또는 재정적 지원이 충분한지?
현실적인 부분들이 가장 우선시 되어야 한다고 생각한다.
예를 들어,
기존의 IDC 환경에서 주요 시스템을 운영하면서, 서버리스가 유리한 특정 기능만 클라우드로 분리해 Lambda나 Fargate에 배포하는 구조도 충분히 현실적인 대안이 될 수 있다고 생각함.
기술은 트랜드 보다 맥락, 속도보다 균형
팀과 비즈니스가 감당할 수 있는 수준에서, 편의성과 성능, 생산성과 비용 사이의 균형점을 찾는것 또한 개발자가 가져야 할 진짜 기술 감각이 아닐까?