DEVOCEAN

저는 SK(주) C&C에서 마이크로서비스 아키텍처를 적용하는 프로젝트의 개발방법론 적용과 기술지원 업무를 담당하고 있습니다.

프로젝트를 지원하다보면, 고객이 시스템의 요구사항에 마이크로서비스 아키텍처를 적용해 달라고 하는 경우가 꽤 있습니다.

아마도 시스템이 확장성이 있고, 장애에 유연해서 갑작스런 부하에도 끄떡없이 운영되고, 또 고객의 needs에 맞춰 빠른 개선을 위해 필요하다고 생각한 것 같습니다.

맞습니다.

애플리케이션을 나누는, 즉 마이크로서비스 아키텍처를 적용하는 비즈니스의 동인은 ① speed-to-market과 ② 타 사 대비 경쟁 우위확보라 할 수 있습니다.

speed-to-market, 제품을 빠르게 출시하려면, 변화에 신속하게 대응하는 능력이 필요합니다.

이것을 우리는 "민첩성"이라고 하고요. 민첩성은 유지보수성, 시험성, 배포성 등 많은 아키텍처의 특성을 포함하고 있습니다.

경쟁 우위는 우리의 애플리케이션이 높은 가용성과 확장성을 갖고 있어서, 변경사항이나 개선사항을 빠르게 반영해서 신속한 출시가 가능합니다.

회사의 규모나 사용자가 늘어나도 그만큼 더 큰 확장을 할 수 있습니다.

우리도 이런 경쟁 우위와 민첩성을 위해 분산 아키텍처, 마이크로서비스 아키텍처를 선택하는 경우가 많았습니다.

마이크로서비스 아키텍처를 경험해보신 분들은 아실겁니다.

마이크로서비스 아키텍처의 많은 장점을 누리기 위해, 애플리케이션과 데이터베이스의 분할에 따른 많은 외부 아키텍처 기술 요소를 추가해야 하고,

데이터의 정함성 같은 문제를 해결하기 위해 다양한 패턴을 적용해야 하는데, 이 일이 어렵고 많다는 걸 말이죠.

(Service Registry, Service Discovery, External Config. Server, Loggin, Messaging 등)

그러나, 꼭 마이크로서비스가 아니더라도 모놀리스 아키텍처에서 애플리케이션의 내부를 잘 모듈화해서도 달성할 수 있습니다.

이렇게 모놀리스 애플리케이션을 기반으로 그 내부를 모듈화한 것을 모듈러 모놀리스(Modular Monolith) 아키텍처라고 합니다.

또한 마이크로커널 (Micro-Kernel) 아키텍처로도 달성할 수 있습니다.

이름에서 알 수 있듯이, 마이크로한 커널이 있는 아키텍처로, Core System을 중심으로 플러그인을 붙여 나가는 방식으로 Plugin 아키텍처라고도 합니다.

Core System은 시스템 실행에 필요한 최소한의 기능만 구현하고, 다양한 기능을 별도 Plugin으로 구현해서 필요에 따라 붙여서 사용하는 방식입니다.

이 아키텍처는 개별 Plugin 컴포넌트들로 분리되어 있어서 테스트와 배포 시간을 엄청나게 줄일 수 있습니다.

"아키텍트는 뚜렷한 비즈니스 동인 없이 시스템을 잘게 나누어서는 안된다."

"우리 시스템은 마이크로서비스로 가야한다"보다는 우리 시스템의 명확한 목표를 정하고 그에 맞는 합리적인 아키텍처를 선택해야 한다는 걸 말씀드리고 싶습니다.

"자동차는 무조건 넓고 배기량 큰게 좋지" 보다는, 사용 목적에 맞춰 적합한 사양의 차를 사는게 필요합니다.

자동차 구매를 예로들면 출퇴근이 목적이라면 작은 승용차를, 주말 캠핑이 목적이라면 짐을 많이 실을 수 있는 SUV가 적합하다는 것입니다.

무조건 마이크로서비스 아키텍처보다는, 목적에 맞춰 위에 소개한 모듈러 모놀리스 아키텍처와 마이크로커널 아키텍처도 검토했으면 하는 생각에 글을 작성해 보았습니다.