[Spring Framework] 부품화의 미래

 

 

여기까지 부품화의 이야기(포스팅)은 아키텍처로서의 모놀리식(monolithic) 형태를 대상으로 해왔다.

여기서는 현재의 이야기를 해보자.

 

우선 모놀리식의 아키텍처는 웹 애플리케이션이 하나의 프로젝트 형태로 디플로이된 형태이다. 따라서 모놀리식 아키텍처에서는 부품화 후 한 부품을 수정하더라도 전체를 다시 디플로이 해야 한다. 이렇게 되면 부품화한 의미가 흐려질 것이다.

 

 

그래서 어느 정도의 크기 및 모놀리식이라고 보이는 복잡한 시스템은 부품을 개별로 작성-수정해서 디플로이할 수 있다고 생각한 마이크로서비스(Microservices)가 나왔다. 

 

어느 비즈니스 용건에 특화한 단위로, 거기에 UI부터 DB의 액세스까지 포함해도 문제(단, 라이브러리 같은 범용, 공용 부품은 별도)가 되지 않는다. 

 

이렇게 잘라낸 부품을 서비스라고 한다. 

(일반적인 비즈니스 로직 층의 서비스와 다른 개념이다.) 

 

이 서비스를 하나의 프로덕트로 생각해서 팀별로 분담해서 개발하고 프로덕트에 최선인 개발 언어를 선택한다. 

 

이렇게 구성된 서비스를 경량의 통신 수단(REST와 RabbitMQ) 등으로 유연하게 결합한 시스템을 만들어가는 것이 마이크로서비스 아키텍처이다. 지금까지 부품화 이야기와 비교해서는 꽤 큰 부품이 되지만, 그 서비스의 내부에서는 다시 세세한 부품으로 이루어진 구조이다.

 

 

화면을 포함하지 않는다면 EJB가 최초에 목표로 한 방향이나 그 후의 웹 서비스 및 SOA와 같은 이야기이다. 실제로 해외의 유명한 프로그래머들은 마이크로서비스 아키텍처와 같지 않은가를 논의하기도 하니, 크게 다르지 않다고 생각해도 좋을 듯 하다.

이러한 마이크로서비스 아키텍처의 상세한 이야기와 DDD의 이야기, 혹은 마이크로서비스와 같이 나오는 DevOps 등은 길게 언급하지 않겠지만 스프링을 사용하는 한 여러 아키텍처를 이해하는 것은 중요하다.

물론 지금 개발 중이고 운영 중인 시스템에 마이크로서비스를 적용하라는 말은 아니다. 현실적으로 운영 면이나 경험이 풍부한 모놀리식 아키텍처보다 마이크로서비스가 어려운 것은 굳이 해보지 않아도 알 수 있다고 생각한다. 게다가 원래 복잡한 도메인에서는 마이크로서비스로 분류는 쉽게 할 수 있지만, 복잡한 도메인 자체가 없어지는 것은 아닐 것이다. 

"스프링은 마이크로서비스 아키텍처에 어떻게 대응할까?" 그 대답 중 하나가 스프링 부트(Spring Boot)이다. 

 

스프링 부트에서 개발한 애플리케이션이 서비스되고 이것들을 조합해서 작업함으로써 마이크로서비스 아키텍처가 실현될 것이다. 그리고 클라우드 네이티브(처음부터 클라우드용으로 애플리케이션을 만든다는 생각) 아키텍처가 최신 아키텍처로 자리잡고 있다.