Spring Boot 시대, 왜 미들웨어가 다시 중요해졌을까요
Spring Boot 기반 환경에서 개발 생산성은 높아졌지만 운영 복잡성도 함께 증가했습니다. 기업들이 다시 미들웨어에 주목하는 이유와 Embedded LENA가 해결하는 운영 과제를 소개합니다.
오늘날 애플리케이션이 실행되는 환경의 종류와 방식은 이전보다 훨씬 더 빠르게 늘어나고 있습니다.
예를 들면, 어떤 애플리케이션은 여전히 전통적인 WAS 위에서 운영되고, 일부는 Spring Boot로 개발되어 컨테이너로 배포되고, 또 다른 일부는 쿠버네티스 위에서 마이크로서비스 형태로 운영되기도 합니다.
하지만 이런 다양한 선택지 속에서도 Spring Boot를 기반으로 한 Embedded 애플리케이션은 클라우드 네이티브 Java 환경에서 널리 사용되는 방식으로 자리 잡았습니다. Spring Boot는 애플리케이션을 더 빠르게 만들고 더 쉽게 배포할 수 있게 만들어주었습니다. 각각의 서비스는 독립적으로 실행되고, 필요한 설정과 의존성을 자체적으로 포함하며 운영됩니다. 이러한 변화는 개발 속도를 크게 끌어올렸지만, 서비스별 자율성이 확대되면서 애플리케이션 구성 및 운영 방식이 다양화되었습니다.
조합의 자유가 남긴 또 하나의 과제에 직면하게 된 것입니다.
속도는 빨라졌지만 운영은 더욱 복잡해졌습니다
Spring Boot 기반의 환경에서 우리는, 애플리케이션을 보다 자율적으로 개발하고 배포할 수 있습니다. 개발팀이 인프라와 애플리케이션의 배포를 직접적으로 다루게 되면서 이전에 비해 배포 속도가 빨라졌고, 서비스 단위의 개선도 훨씬 유연해졌습니다. 서비스는 잘 분리되어 있고, 각 기술은 안정적이며, 확장성도 충분하기에 개발 단계에서 봤을 때, 이 구조는 매우 이상적으로 보입니다. 그렇지만, 운영자들의 고민은 오히려 늘고 있습니다.
왜 일까요?
서비스의 설정을 변경하는 방식과 변경 이력을 추적하는 방법이 각기 다르고, 서비스의 흐름을 한 눈에 보기 어려워졌기 때문입니다. 그리고, 장애가 발생했을 때는 어느 부분을, 또 어디부터 보아야 하는지도 파악하기도 쉽지 않았습니다. 지금 구조에서는 이 모든 흐름이 하나로 보이지 않기 때문에, 운영자는 점점 더 많은 것을 추적해야만 하게 되었죠.
이처럼 기술 환경이 빠르게 변화하는 과정에서 운영 체계에 대한 표준화와 거버넌스 정립은 상대적으로 뒤쳐졌습니다.
Spring Boot 기반의 개발 환경은 개발 생산성을 크게 향상 시켰지만, 서비스 별로 운영 방식과 관리 체계가 서로 다른 형태로 발전하면서 운영 복잡성 역시 함께 증가했습니다. 운영자는 애플리케이션 뿐만 아니라 배포 방식, 설정 관리, 장애 대응 절차까지 서비스 별 특성을 모두 이해해야 했고, 이는 점차 높은 부담으로 이어졌습니다.
CNCF Platform 백서에서도 이 문제를 명확히 짚고 있습니다. 자율성은 속도를 높이지만, 그 이면으로 개발팀이 인프라와 지원 책임까지 떠안게 되면 인지 부하(Cognitive Load)가 커지고 가치 창출에 집중할 수 있는 시간은 줄어든다고 말합니다.
속도는 빨라졌지만 운영은 오히려 더욱 복잡해진 상황이 된 것이지요. 조직 차원의 운영 기준과 플랫폼 전략이 없다면, 이러한 유연성은 결국 파편화라는 이름으로 돌아오게 됩니다.
기업들이 다시 미들웨어에 관심을 갖는 이유
그래서 기업들은 자연스럽게 아래와 같은 질문에 도달하게 되었습니다.
어디에서 실행되든 같은 방식으로 운영할 수는 없을까?
이 문제를 해결하기 위해 플랫폼 엔지니어링이라는 개념이 나왔지만 실제 운영 표준화는 그 속도를 따라가지 못하고 있습니다. 특히 Spring Boot 기반 환경에서는 애플리케이션 단위로 모든 것이 분산되어 있기 때문에 운영 기준을 조직 차원에서 통일하기가 더욱 어려웠습니다. 그래서 기업들은 다시 미들웨어를 찾기 시작합니다. 하지만 기업들이 다시 찾는 미들웨어란 과거와 같은 의미의 미들웨어가 아니었습니다.
미들웨어에 바라는 것은 런타임이 아닙니다
기업들이 미들웨어에 바라는 것은 단순히 미들웨어가 자신 본연의 역할을 충실히 수행하는 것 만이 아니었습니다. 기업들이 미들웨어에 바란 것은 운영 규율이라는 더 본질적인 것이었습니다.
- 같은 방식으로 다루는 표준
- 변경을 추적하는 감사
- 정보를 통제하는 보안
- 상태를 한눈에 보는 가시성
위의 네 가지 요구사항들은 특정 런타임과 관련이 없습니다. 어디에서든 반드시 유지되어야 하는 운영 기준입니다.
Spring Cloud Config가 중앙 설정 관리와 Git 기반의 이력을 제공하고, HashiCorp Vault가 강한 접근 통제와 감사 로그를 제공하며, CNCF가 플랫폼의 핵심 요소로 포털, API, Secret관리, 보안을 함께 묶는 이유도 여기에 있습니다. 운영자는 같은 질문을 반복합니다.
- 누가 바꿨지?
- 무엇이 반영됐지?
- 지금 어디가 달라졌지?
- 문제가 생기면 어느 부분으로 되돌릴 수 있는거지?
기업이 중요하게 바라보는 것은 이 질문들에 답을 하게 해주는 구조입니다. 이 문제에 대한 답은 점점 하나의 방향으로 수렴하고 있습니다. 미들웨어가 다루어야 하는 것은 '변경 → 검증 → 승인 → 반영 → 확인 → 롤백'의 운영 흐름이라는 것입니다.
ArgoCD는 상태 비교, Audit trail, Rollback을 통합했습니다. AWS AppConfig는 validator와 자동 롤백을 제공합니다. 구현 방식은 다르지만 공통점이 있습니다. 바로 변경이 끝까지 통제되고 추적되어야 한다는 것입니다.
그리고 이 흐름을 일관되게 강제하는 계층이 바로 미들웨어입니다. 미들웨어는 런타임을 보조하는 계층이 아니라, 운영 규율을 구현하는 계층으로 재정의되고 있습니다.
Spring Boot 시대의 공백
하지만 이런 흐름이 모든 환경에서 적용되고 있는 것은 아닙니다.
많은 기업의 서비스들이 실행되는 Spring Boot 기반의 Embedded 환경은 아직도 운영이 분산된 상태로 남아 있습니다.
각각의 애플리케이션이 독립적으로 실행되면서 설정 관리나 변경 통제, 상태 가시성을 서비스 내부나 개별 도구에 의존하게 되기 때문입니다.
이것을 Spring Boot 시대의 공백이라고 볼 수 있지 않을까요?
이러한 공백은 결코 추상적인 이야기가 아닙니다. Spring Boot 가 품고 있는 Embedded Tomcat 환경에서는 운영자가 매번 부딪히는 구체적인 어려움으로 나타납니다.
첫째, 흔적이 너무 쉽게 사라집니다. Spring Boot 애플리케이션은 컨테이너 단위로 떴다가 사라지기 때문에 Pod가 종료되면 그 안에 쌓여있던 스레드 덤프, 힙 상태를 비롯한 각종 이벤트 기록이 함께 사라집니다. 정작 장애 직후 '이 Pod가 왜 죽었지?' 를 들여다보아야 하는 순간에 증거가 남아있지 않게 됩니다.
둘째, 자기 자신 밖에 보지 못합니다. 국내 한 대형 시중은행 MSA 환경에서 특정 Pod 에 요청이 지연되자, 그 Pod를 호출하던 다른 Pod들에 연쇄적으로 장애가 전파된 사례가 있었습니다. 이런 상황에서는 개별 애플리케이션의 로그만으로는 문제 상황이 어디서 시작됐고, 어디까지 번졌는지 파악하기 어렵습니다. 시스템에 대한 운영 가시성을 확보하기 어렵기 때문입니다.
셋째, 프레임워크의 기본 동작은 환경과 설정에 따라 예상하지 못한 운영 상의 차이를 만들어 냅니다. 설정 모듈이 기본적으로 포함되기 때문에 의도하지 않은 외부 호출이 발생하거나 컴포넌트 기동 순서에 따라 모니터링이 누락될 수 있습니다. 결국 애플리케이션 단위의 높은 자율성은 공통 운영 기준이 부재한 환경에서 운영 파편화라는 형태로 나타나게 됩니다.
Embedded LENA가 풀고자 하는 문제
Embedded LENA가 풀고자 하는 문제도 바로 이 지점에 있습니다. Spring Boot 기반의 Embedded 환경에서 설정, 변경, 상태를 하나의 기준으로 관리하고 운영 흐름을 플랫폼 차원에서 통합 관리할 수 있도록 합니다.
앞서 짚은 세 가지의 어려움도 같은 방식으로 메워집니다.
첫 번째로 OOM, Full GC, Stuck Thread, Exception 과 같은 이벤트를 자동으로 추적합니다.
이 이벤트들은 애플리케이션이 아니라 LENA Manager에 모이기 때문에 Pod가 사라진 뒤에도 장애 이력과 덤프가 그대로 남기 때문에 휘발성이라는 Embedded 환경의 약점이 사라집니다.
두 번째로 가시성을 확보할 수 있습니다. LENA Manager를 통해 Embedded LENA를 Topology 화면과 실시간 모니터링 기능을 통해 Pod 별 스레드 풀, 힙 메모리, 데이터 소스 풀 상태를 한 눈에 보고 서비스 단위로 전체 상태를 조회할 수 있습니다.
세 번째로 사용자 활동, 로그인 이력 로깅, 계정, 권한(IAM)과 인사 시스템 연동, SSO 연동을 애플리케이션 마다 하는 것이 아니라 하나의 체계 안에서 다룰 수 있도록 합니다.
실제로 외부 메신저 알림, 계정 및 권한(IAM) 연동, 로그인 이력 관리 등을 Embedded LENA 기반의 표준 체계로 통합하여 운영하고 있는 금융사 사례는 이러한 관리 체계의 실효성과 활용 가치를 잘 보여줍니다.
애플리케이션의 자율성은 유지하면서도 운영자가 필요로 하는 것들을 하나의 관리 체계 안에서 다룰 수 있게 하는 것입니다. Embedded LENA를 통해 운영 흐름이 갖추어지면 개별 애플리케이션에 흩어진 운영이 조직 차원의 통제 가능한 구조로 모이게 됩니다.
분산 된 운영을 어떻게 하나의 기준으로 통제할 수 있을까. Spring Boot 시대에 미들웨어가 다시 필요해진 이유도 여기에 있습니다. 이제 미들웨어는 애플리케이션을 실행하기 위한 계층이 아닌, 흩어진 운영을 하나의 기준으로 통제하기 위한 구조로 다시 정의되고 있습니다.
참고
- Cloud Native Computing Foundation (CNCF), Platforms White Paper v1, 2023
- HashiCorp, 2024 State of Cloud Strategy Survey, commissioned by HashiCorp and conducted by Forrester Consulting