모놀리식 vs 마이크로서비스, 어떤 아키텍처를 선택할까?

애플리케이션의 아키텍처 스타일(모놀리식 vs 마이크로서비스)에 대한 선택은 트렌드나 경쟁사의 특징을 따르기보다, 애플리케이션의 목표와 비즈니스 요구 사항에 따라 달라진다. 하지만 마이크로서비스 아키텍처가 대세로 떠오르면서 여러 프로젝트에 활발하게 채택되고 있다. 새롭게 구축하는 애플리케이션은 마이크로서비스로 전환해야 한다는 이야기도 자주 나오고 있다.

모놀리식 애플리케이션은 소프트웨어 개발을 위한 기본 접근 방식이다. 그렇다면 마이크로서비스가 대세가 된 현재 모놀리식 접근 방식을 버려야 할까? 만약 모놀리식 애플리케이션에서 마이크로서비스로 전환하면 어떤 이점이 있을까? 마이크로서비스로 애플리케이션을 만들면 비즈니스의 이점은 무엇일까? 이번 글에서는 모놀리식과 마이크로서비스 아키텍처를 비교하여 장단점을 살펴보고, 비즈니스에 적합한 소프트웨어 아키텍처를 선택하는 방법에 대해 알아보자.
 

모놀리식 아키텍처란?

모놀리식 아키텍처는 단일 코드 베이스의 애플리케이션이다. 예를 들어 Java로 작업할 때, 전체 애플리케이션은 단일 코드로 작성되어 단일 데이터베이스에 연결된다. 이것은 매우 일반적인 접근 방식으로, 거의 모든 개발자가 코딩을 시작할 때 이런 종류의 아키텍처에서 작업하게 된다. 그래서 모놀리식으로 개발한 애플리케이션은 마이크로서비스 아키텍처보다 구현이 쉽고, 덜 복잡하다는 장점이 있다.

1) 모놀리식 아키텍처의 장점

먼저 모놀리식 아키텍처의 장점을 살펴보자.

• 단순성: 모든 코드가 단일 코드 베이스에 있다. 변경 사항이 발생할 경우 필요한 모든 코드가 한곳에 존재한다는 의미이다. 애플리케이션을 로컬에서 실행해야 할 경우 단일 애플리케이션만 실행하면 된다.
• 간편한 배포: 단일 프로젝트로 배포하면 되기 때문에 간편하다. 새로운 기능이 추가되거나 버그가 수정될 때마다 단일 애플리케이션을 배포하면 된다.
• 보편성: 대부분의 개발자가 모놀리식 아키텍처에서 작업한 경험이 있어, 프로젝트를 쉽게 시작할 수 있다.
• 디버깅이 쉬움: 모든 코드가 단일 애플리케이션에 있기 때문에 디버깅하기 쉽다. 추가 구성을 수행하지 않고 코드를 실행하여 디버깅하면 된다.
• 쉬운 테스트: 디버깅과 마찬가지로 모든 코드가 단일 애플리케이션에 있어, 테스트 수행이 쉽다.
• 쉬운 모니터링: 코드가 모두 단일 프로젝트에 존재하여, 오류 시 문제가 발생한 위치를 식별하기 쉽다.

2) 모놀리식 아키텍처의 단점

다음으로 모놀리식 아키텍처의 단점을 살펴보자.

• 규모가 커지면 유지 보수가 어려움: 시간이 지남에 따라 애플리케이션이 커지면 관리가 어려울 수 있다. 모놀리식 애플리케이션은 중소형 애플리케이션에선 잘 작동하지만, 애플리케이션이 크고 복잡해지면 문제가 발생할 수 있다.
• 유연하지 않은 확장성: 모놀리식도 확장할 수 있지만 전체 애플리케이션의 확장만 가능하다. 예를 들어 애플리케이션의 특정 부분에 대해 요청을 받으면, 이 부분만 확장할 수는 없고 전체 애플리케이션을 확장해야 한다.
• 대규모 팀 작업이 어려움: 모든 팀이 동일한 코드, 동일한 프로젝트에서 작업하기 때문에 코드 병합에 대한 충돌 가능성이 높고, 기능 변경 시 다른 팀이 작업에 영향을 줄 수 있다.
• 기술 사용 제한: 모놀리식 애플리케이션을 다른 기술로 변경하는 것은 어렵기 때문에, 일반적으로 모놀리식 애플리케이션을 만들면 오랜 기간 동일한 기술을 사용해야 한다.

3) 모놀리식 아키텍처는 언제 사용하면 좋을까?

모놀리식 아키텍처는 다음과 같은 상황에서 사용할 수 있다.

• 규모가 작은 애플리케이션인 경우
• 현 비즈니스를 통해 성장할 계획이 없거나, 복잡한 시스템 설계 및 관리가 필요하지 않은 경우
• 아직 아이디어를 구상 중인 단계라면 모놀리식으로 시작하는 것이 유리하다.
• 팀의 규모가 작거나 신생 팀인 경우, 또는 새로운 도메인일 때 적합하다.
• 아직 제품이 MVP 상태라면, 모놀리식은 사용자로부터 피드백을 수집할 수 있는 가장 빠른 방법이다.
• 주된 작업이 CRUD일 경우

마이크로서비스 아키텍처란?

마이크로서비스 아키텍처에서는 애플리케이션을 작은 서비스로 분할하고, 각 서비스가 서로 독립적이라(느슨하게 결합) 기술에 구애받지 않는다. 그래서 각각 고유한 데이터베이스를 소유할 수 있다. 그로 인해 많은 이점을 제공하지만, 문제도 많고 복잡성을 함께 수반한다. 때문에 마이크로서비스 아키텍처로 프로젝트를 진행하려면 많은 경험이 필요하다.

1) 마이크로서비스 아키텍처의 장점

마이크로서비스 아키텍처는 다음과 같은 장점이 있다.

• 유연한 확장: 각 마이크로서비스는 다른 서비스와 독립적으로 확장할 수 있다. 예를 들어 애플리케이션의 일부가 요청을 받을 경우, 전체 애플리케이션을 확장하는 대신 특정 마이크로서비스만 확장할 수 있기에 애플리케이션의 고가용성이 필요할 때 매우 유용하다.
• 독립적인 배포: 마이크로서비스는 느슨하게 결합되어 있으므로 하나의 마이크로서비스만 배포할 수 있다. 이렇게 하면 애플리케이션의 작은 부분만 업데이트되므로 전체 애플리케이션의 작동을 멈출 필요가 없다.
• 단일 실패 지점 제거: 애플리케이션을 여러 소규모 서비스로 분할하여, 전체에 영향을 미치는 단일 실패 지점을 제거한다.
• 전체 서비스 중단 위험 감소: 특정 마이크로서비스가 중단되더라도 전체 애플리케이션에 영향을 미치지 않고, 해당 마이크로서비스에만 영향을 미친다. 다른 부분은 정상적으로 작동될 수 있다.
• 다른 데이터베이스를 소유: 각 마이크로서비스별로 데이터베이스를 소유할 수 있다. 어떤 마이크로서비스에서는 관계형 데이터베이스가 최선일 수 있고, 다른 마이크로서비스에서는 NoSQL이 더 적합할 수 있다. 이렇듯 각 서비스에 적합한 데이터베이스를 정의할 수 있다.
• 다양한 기술 수용 가능: 각 마이크로서비스는 서로 다른 기술을 가질 수 있다. 하나는 Java, 다른 하나는 Node 등에서 수행될 수 있다.
• 민첩성: 마이크로서비스를 이용하면 전체 애플리케이션에 큰 영향을 주지 않고, 새로운 것을 추가할 수 있어 새 버전을 배포하는 것이 매우 쉽다.

2) 마이크로서비스 아키텍처의 단점

일반적으로 마이크로서비스 아키텍처에서 작업하는 것은 모놀리식 아키텍처에서 작업하는 것보다 훨씬 더 복잡하다. 다음은 마이크로서비스 아키텍처의 단점이자 과제이다.

• 개발 생산성 필요: 여러 개의 마이크로서비스 중 하나에 새로운 기능을 구현해야 할 때, 다른 서비스에 접근할 수 있도록 로컬에서 많은 애플리케이션을 실행할 수 있는 환경을 갖춰야 한다.
• 디버깅이 어려울 수 있음: 디버깅하거나 테스트를 위해 둘 이상의 마이크로서비스를 실행해야 해서, 디버깅이 어려울 수 있다.
• 마이크로서비스 간 통신: 동기/비동기 방식의 통신을 고려해야 하며, 이런 부분이 애플리케이션의 복잡성을 증가시킨다.
• 오류 처리: 두 개 이상의 마이크로서비스를 사용해 요청을 처리한다면, 첫 번째 마이크로서비스에 대한 요청에서 문제 발생 시 작업을 이전 상태를 되돌릴 수도 있음을 고려해야 한다.
• 표준화 부족: 공통 플랫폼이 없어 여러 언어, 로깅 표준 및 모니터링이 사용될 수 있다. 마이크로서비스에서 발생하는 모든 오류 또는 문제를 모니터링할 수 있는 중앙 모니터링 체계를 갖추는 것이 필요하다.
• 오류 식별의 어려움: 마이크로서비스 아키텍처에서 오류를 식별하는 것은 모놀리식보다 훨씬 복잡하고 어렵다. 특히 비동기 통신일 때 더욱 어렵다. 애플리케이션을 디버깅하고 문제를 찾아야 하는 경우 로컬에서 둘 이상의 마이크로서비스를 실행해야 할 수 있다.

3) 마이크로서비스 아키텍처는 언제 사용하면 좋을까?

마이크로서비스 아키텍처는 다음과 같은 상황에서 유용하다.

• 비즈니스가 계속 성장하고 있는 경우
• 비즈니스 도메인에 대해 잘 알고 있거나, 요구 사항이 명확한 경우
• 복잡한 애플리케이션이 될 것임을 식별할 수 있는 경우
• 가용성 및 유연한 확장이 요구사항인 경우
• 서비스를 만드는 서로 다른 독립적인 팀이 존재하는 경우

모놀리식과 마이크로서비스 아키텍처의 차이점

확장성

확장성은 마이크로서비스에서만 유효한 것 같지만, 모놀리식도 확장이 가능하다. 다만 모놀리식 애플리케이션은 여러 복사본을 배포하는 형태로 확장할 수 있는 것에 비해, 마이크로서비스는 더 적은 리소스로도 확장할 수 있어 훨씬 유리하다.

복잡성

앞서 모놀리식 아키텍처는 복잡성이 낮다고 설명했다. 이에 비해 마이크로서비스는 애플리케이션 복잡성에 따라 소스 코드, 프레임워크 및 기술이 포함되고, 여러 서비스가 API를 통해 서비스 간 통신하는 형태로 구축된다. 그래서 전체 아키텍처에 대한 높은 수준의 관리와 기술에 대한 이해가 필요하다.

지연 시간

마이크로서비스는 다른 서비스와 통신할 때, 네트워크를 통해 데이터를 보내거나 받는다. 반면 모놀리식은 모든 서비스가 동일한 워크플로우 내에 있기 때문에 네트워크 대기 시간이 발생하지 않는다. 이런 이유로 마이크로서비스는 모놀리식보다 성능이 느리다.

신뢰성

모놀리식은 단 하나의 서버로 구성된다. 즉, 장애가 발생하면 전체 애플리케이션이 다운된다. 반면 마이크로서비스는 하나가 실패하면 장애 격리를 통해 애플리케이션을 유지할 수 있다.

비즈니스를 위한 최선의 선택은 무엇일까?

복잡한 애플리케이션을 만들려면 필요한 지식 외에도 경험과 시간, 비용이 준비되어야 한다. 아래는 모놀리식과 마이크로서비스를 비교한 표이다.

아키텍처를 결정하기까지는 여러 사람의 의견이 오고 갈 것이다. 어떤 사람들은 처음엔 모놀리식으로 구축한 다음, 마이크로서비스로 전환해야 한다고 생각한다. 하지만 목표가 마이크로서비스로 개발하는 것이라면 굳이 모놀리식으로 시작할 필요는 없다. 가장 적합한 아키텍처를 선택하려면 다음의 요소들을 고려해야 한다.

• 개발하려는 애플리케이션 유형
• 프로젝트의 타임라인
• 예산
• 팀의 경험

이와 관련해 얼마 전 스타트업을 대상으로 ‘스타트업에 가장 적합한 아키텍처는?’라는 주제로 강의를 진행하게 되어, 일부 관련 자료를 첨부했다. 적합한 아키텍처를 선택하기 전, 우선 스타트업에 대한 정의가 필요했다. 스타트업은 첫 번째 그림에서 A 영역에 위치하고 있고, 높은 성장 목표와 확장 가능한 비즈니스 모델을 검증해야 하는 입장이다. 즉, 비즈니스 모델이 시장에서 인정받아야 가치를 창출할 수 있는 것이다.

스타트업이라면 결국 비즈니스 모델을 시장에서 인정을 받아야 하는 목적은 동일하다. 트위터나 우버의 경우 모놀리식 기반의 MVP로 앱을 개발한 후 비즈니스 모델의 가치를 인정받고, 비즈니스가 확장됨에 따라 마이크로서비스로 전환한 사례이다. 이런 사례들을 참고해 먼저 모놀리식으로 개발하는 것을 권고한다. 그러나 일반 모놀리식이 아닌 프로세스 내부의 코드가 모듈로 분해되는 모듈식 모놀리스(Modular Monolith)를 추천하고 있다.

마치며 

아키텍처는 여러 가지 비즈니스 상황을 고려해 선택해야 한다. 최근 마이크로서비스가 대세라지만, 맞지 않는 상황도 존재하기 때문이다. 어떤 아키텍처를 사용해야 하는지 막막하다면, 다음 몇 가지 질문을 통해 현재 상황을 분석해보자.

• 애플리케이션이 크고 복잡해질 가능성이 높은가?
• 우리 팀은 도메인에 대해 잘 알고 있는가?
• 가용성과 확장성을 갖춰야 하는가?
• 마이크로서비스에 대한 경험이 있는가?

위의 질문에 대한 대답이 모두 Yes라면 마이크로서비스 아키텍처가 더 적합할 것이다.

개발자라면 누구나 내가 설계하고 작성한 코드가 비즈니스에 큰 가치를 줄 때 성취감을 느낄 것이다. 이것은 우리가 기술을 다루지만, 항상 비즈니스를 염두에 두고 고민해야 함을 뜻한다. 이번 글을 참고하여, 현 비즈니스 상황에 최적화된 아키텍처를 선택할 수 있길 바란다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.