'만능 아니다' 마이크로서비스의 단점 5가지

클라우드 애플리케이션 개발에서 마이크로서비스 아키텍처(microservices architecture)란, 작고 느슨하게 결합된 여러 서비스의 조합을 통해 소프트웨어 애플리케이션을 만드는 구조적인 방법론을 가리킨다. 여기서 서비스란 재고 물품을 데이터베이스에 추가하거나, 새로운 고객의 신용을 확인하는 등 특정 비즈니스 작업 혹은 기능을 가리킨다. 이들 서비스는 보통 별도의 프로세스로 처리되고 API 혹은 가벼운 프로토콜을 통해 다른 서비스와 통신한다.
 

마이크로서비스는 서비스지향아키텍처(SOA, services-oriented architecture)와 애플리케이션 개발 과정을 개선하려는 필요에서 출발해 현재는 최신 애플리케이션을 개발하는 가장 선호되는 방법론으로 자리잡았다. 필자 역시 느슨한 연결과 격리 특성 때문에 마이크로서비스 아키텍처를 즐겨 사용한다.
 

마이크로서비스의 장점

마이크로서비스 아키텍처에서는 각 서비스가 느슨하게 결합된다. 다른 서비스의 기능에 직접적으로 의존하지 않고 독립적으로 작동하도록 할 수 있고, 개발팀이 개별 서비스를 개발, 배포하는 것은 물론 독립적으로 확장할 수 있어 유연성을 높일 수 있다. 또한, 독립적으로 실행되므로 회복탄력성을 개선하는 장점도 있다. 이는 모두 느슨한 연결에 따른 독립과 격리 덕분이다. 각 서비스를 별도로 개발하고 테스트하고 배포하고 확장할 수 있다.

역사적으로 보면 마이크로서비스는 어느날 새롭게 등장한 것은 아니다. 오히려 1970년대 구조적인 모범사례가 진화한 형태에 더 가깝다. 구조화된 개발, 객체지향 개발(object-oriented development), CBD(component-based development), 서비스 재사용 등을 거쳐 마이크로서비스로 발전했다. 각 방법론이 그 다음 방법론에 영향을 주고 있고 이런 진화는 지금도 진행중이다.
 

마이크로서비스의 단점 5가지

개발에 있어 ‘공짜 점심’은 없다. 모든 방법론과 툴, 언어, 아키텍처에는 장점 외에 반드시 함께 알아야 할 단점이 함께 있기 마련이다. 때로는 과대광고 때문에 이런 단점을 놓치기도 한다. 마이크로서비스의 단점을 살펴보자.

가장 큰 단점은 복잡성이다. 마이크로서비스의 복잡성은 모놀리식(monolithic) 아키텍처와 차원이 다르다. 시스템이 수많은 서비스로 쪼개지므로, 전체 아키텍처는 더 복잡해지고 각 서비스 간 상호작용을 이해하기도 쉽지 않다. 마이크로서비스를 배포하려는 대상이 복잡한 분산 시스템이라면 상황은 더 힘들어진다. 멀티클라우드를 구축, 배포하는 거의 모든 기업이 직면한 어려움이다.

마이크로서비스의 또다른 고민거리는 배포다. 마이크로서비스를 이용하면 네트워크를 통해 빈번하게 서비스간의 통신이 이뤄지는데, 이는 결국 지연, 네트워크 장애, 더 많은 부하 등으로 이어질 수 있다. 필자는 마이크로서비스 기반 애플리케이션을 배포한 후 여러 가지 이유로 네트워크까지 업그레이드해야 했다. 상당한 비용이 들었다.

데이터 관리도 더 복잡해진다. 마이크로서비스는 그 내부에 자체 데이터베이스 혹은 데이터스토어를 가질 수 있는데, 이 경우 여러 서비스 간에 데이터를 일관되게 유지하는 것이 문제다. 보통은 이를 위해 데이터 무결성을 관리하는 추가 작업이 필요한데, 기업은 문제가 발생하기 전까지 이런 작업을 왜 해야 하는지 이해하지 못한다. 이 문제는 충분히 해결할 수 있지만, 예상보다 훨씬 많은 리소스가 필요하다.

서비스 의존성도 마이크로서비스의 단점이다. 마이크로서비스는 API를 통해 상호작용하기 때문에 한 서비스를 변경하면 다른 서비스에 연쇄적으로 영향을 준다. 이는 버저닝과 호환성 문제로 이어지는데, 특히 업그레이드나 서비스 변경 과정에서 문제가 될 수 있다. 마지막으로 과도한 리소스 사용의 문제다. 여러 마이크로서비스 인스턴트를 운영하면 대부분의 경우 단일 모놀리식 애플리케이션보다 더 많은 리소스가 필요하다. 이는 인프라 비용의 증가로 이어지고 특히 비효율적으로 관리할 때 큰 문제가 된다.
 

만능이 아니다

현재 대부분 클라우드 개발자와 아키텍트는 거의 종교적인 신념처럼 마이크로서비스 아키텍처를 도입하고 있다. 당연히 마이크로서비스 역시 모든 애플리케이션에 만능처럼 적용할 수 있는 것이 아닌데도, 많은 경우 이를 강제하고 있다. 이미 클라우드로 전환했거나 현재 클라우드로 옮기고 있는 애플리케이션을 마이크로서비스로 현대화하는 경우가 대표적이다. 앞서 언급한 마이크로서비스의 여러 단점 때문에, 기업이 예상했던 것보다 훨씬 많은 리소스가 필요하다.

따라서 마이크로서비스는 가장 표준적인 아키텍처처럼 사용되지만 이를  실제 도입하기 전에 그 단점을 반드시 고려해야 한다. 중요한 것은 핵심 애플리케이션 요건을 만족하는 것이므로 이에 맞춰 방법론을 검토해야 한다.

하지만 안타깝게도 현실에서는 마땅히 해야 할 고민이 충분히 이뤄지지 않는 것처럼 보인다. 결과적으로 코어 애플리케이션 요건과 맞지 않는 방법론으로 인한 비효율성으로 이어진다. 다른 모든 방법론과 마찬가지로, 마이크로서비스 역시 문맥을 읽어야 한다. 마이크로서비스의 장단점을 고려해 써야 할 때와 그렇지 않을 때를 제대로 구분해야 한다.
editor@itworld.co.kr