스프링의 미래 질문

좋은 질문 감사합니다.
먼저 스프링 부트의 대항마라고 불리기도 하는 Micronaut나 Quakers 같은 도구들이 한때 주목을 받았던 것을 잘 알고 있습니다. 저도 써보기도 했고요. 스프링은 2003년부터 개발되어서 과거의 기술을 모두 포용할 수 있게 개발되어온 만큼 조금 무겁긴 합니다. 하지만 스프링 부트라는 매우 빠르게 개발하고 손쉽게 배포하고 쓸 수 있는 도구가 나온만큼 최근에 유행하는 스타일을 기반으로 만들어진 다른 도구들과 비교해서 빠르게 개발하고 편리하게 사용하는데 전혀 뒤쳐지는 건 없다고 생각합니다.

실제로 다른 프레임워크를 사용해서 개발을 해보면 아주 단순한 작업을 수행하는 정도는 간단하게 가능합니다. 그래서 편해보이기도 하죠. 하지만 아무리 클라우드에서 마이크로서비스로 동작하는 기술이라고 하더라도, 요즘처럼 각종 오픈소스, 외부 기술과 연동해서 필요한 요구를 빠르게 수용해야 하는 시대에는 메인 기술 그 자체보다 얼마나 많은 기술과 잘 호환되고, 그동안 경험이 쌓여왔는가도 중요합니다. 스프링만큼 엔터프라이즈 개발부터 스타트업의 간단한 프로로타입에 이르기까지 많이 사용되어진 기술도 없는 듯합니다. 그만큼 많은 검증이 있었고, 수많은 기술이 스프링 또는 스프링 부트를 직접 지원한다고 나섰죠.

그래서 다른 프레임워크를 흥미삼아 쓴다고 하더라도, 요구되는 기술의 종류가 많아지고 고도화 되면 점점 스스로 문제를 다 풀어나가야 하는 문제를 만나기 쉬운 듯합니다. 검색해도 문제를 해결할 다른 개발자들의 글이 발견되지 않는 기술을 써나가는 답답함을 경험해보시면, 그래도 연륜이 있고 충분히 검증되고 호환성이 좋은 스프링 부트가 좋지 않을까 생각이 들게 됩니다.

그래도 호기심에 궁금하시면 다른 도구도 한번 써보세요. 하지만 구인 공고에 나오는 요구 기술이나 시장에 도입되는 기술의 비율을 검색해보시면, 아직은 충분히 스프링 부트에 안착하는게 낫다는 판단을 하시게 될 겁니다.

GraalVM은 스프링6에서 충분한 검증을 거쳐 도입된만큼 아마 사용하는 비중이 점점 늘지 않을까 싶습니다. 단순히 JVM을 바꾼 것만으로도 10% 이상의 성능 향상을 가져오면, 요즘처럼 클라우드 비용이 중요한 시대에는 상당한 이득이 있겠죠. 반면 AOT 빌드를 하는 과정이 상당히 시간이 오래 걸린다는 단점이 있습니다. 빠르게 개발하고 자주 배포하는 스타일로 운영을 하는 경우에 상당한 부담을 줄 수도 있겠죠. JIT와 AOT를 적절한 상황에 선택해서 사용하는 등의 전략이 필요하지 않을까 싶습니다.

제가 지금 GraalVM+Spring6에 대한 다양한 연구와 실험을 해보는 중입니다. 이를 통해서 알게된 내용은 지금 준비중인 토비의 스프링 6의 두 번째 중급 강의를 통해서 자세히 설명을 드리려고 하고 있습니다.

GraalVM이 단순 성능 뿐 아니라 다른 언어로 작성된 코드를 같이 돌릴 수 있고, 연동이 잘 된다는 점도 주목할만한데 아직 적절한 케이스가 많지 않아서 이 부분도 지켜보면 재밌을 듯 합니다.