[기술조사] SW 아키텍처 5가지 그리고 모듈러 모놀리딕+시타델 아키텍처

SW Archtecture(아키텍처) 5가지 & 모듈러 모놀리딕 + 시타델  아키텍처

소프트웨어의 덩어리(결합도)를 고민하는 관점에서 아키텍처를 나열하고 간단히 설명하겠습니다. 

그리고, 모듈러 모놀리딕과 시타델 조합한 아키텍처에 대한 생각을 정리하였습니다.

1. 모놀리딕(Monolithic) : 하나의 거대한 성

 - 구조 : 모든기능이 단 하나의 코드 베이스와 하나의 데이터베이스(DB)를 공유하며 통째로 배포됩니다.

 - 특징 : 단순하고 초기 개발 속도가 압도적으로 빠르지만, 서비스가 커지면 코드가 스파게티처럼 엉켜 수정과 배포가 두려워지는 '거대함의 저주'에 빠집니다. 

2. 모듈러 모놀리딕(Modular Monolithic) : 방이 나뉜 하나의 성

 - 구조 : 배포는 모놀리딕처럼 단 하나의 파일로 하지만, 소스 코드 내부에서는 기능별로 경계(Module)를 철처히 분리하여 서로 간섭할 수 없게 만듭니다. 

 - 특징 : 배포와 인프라 관리는 모놀리딕처럼 편하게, 코드 관리는 MSA처럼 깔끔하게 생각한다면, 모듈러 모놀리딕 아키텍처를 선택합니다. 최근 가장 이성적인 대안으로 평가받습니다.

3. 매크로서비스(MacroService) : 3~4개의 큰 영지

 - 구조 : 시스템을 원자 단위로 잘게 쪼개는 대신, 비즈니스의 가장 거대한 도메인 단위로 큼직하게 3~4개의 중형 서비스로 쪼갭니다. 

 - 특징 : 무분별한 MSA도입으로 인프라 비용과 복잡성에 경험해본 기업들이 "적당히 큼직하게 묶어서 관리하자"라며 타협점으로 선택하는 아키텍처입니다.

4. 시타델(Citadel) : 본성과 외곽 마을

 - 구조 : 시스템의 중심이 되는 핵심 비즈니스는 단단한 모놀리딕(시타델, 성채)으로 남겨두고, 트래픽이 폭발하거나 변경이 잦은 특정 기능(예 알림, 추천 엔진)만 외곽의 마이크로 서비스로 분리합니다. 

 - 특징 : 기존의 거대한 모놀리딕을 한 번에 MSA로 갈아엎는 리스크를 피하면서, 필요한 부분만 효율적으로 확장하는 매우 현실적이고 안저한 하이브리드 전략입니다.

5. 마이크로서비스 아키텍처(MicroService, MSA) : 수십개의 전문 독립 도시

 - 구조 : 모든 기능을 비즈니스 최소 단위로 완저히 쪼개서, 수십~수백 개의 작은 서비스들이 각자의 DB를 가지고 API나 메시징으로만 통신합니다. 

 - 특징 : 서비스별 독립 배포와 무한한 기술 확장(Scale-out)이 가능해 대구모 트래픽에 유리하지만, 네트워크 복잡도와 데이터 정합성을 맞추기 위한 비용이 극도록 높습니다. 

모놀리딕 아키텍처와 마이크로서비스 아키텍처는 어떻게 보면 양극에 있는 아키텍처로 보일 수 있습니다. 

프로젝트 규모, 실행환경, 메시지 처리량, 실시간성 등을 고려해볼 때, 하이브리드 방식으로 사용하는 것이 상당히 좋을 것 같다는 생각을 하였습니다. 

모듈러 모놀리딕(철저한 모듈화) + 시타델(Citadel) 조합하여 사용한다면 성능(Performance)와 유지보수(Maintainability) 측면에서 장점이 있을 것으로 보입니다. 더 많은 생각을 해봐야 하지만, trade off 이 있을 것 같습니다. 시타델 아키텍처도 모놀리딕 기반에 처리량 또는 특정 기능을 분리하는 것인데, 모놀리딕 기반이 아닌 처음부터 모듈러 모놀리딕으로 적용하는 것입니다. 

제미나이(Gemini)에 자문을 구해본 결과, 긍정적으로 답변을 하였습니다. 

1. 유지보수 측면의 이점: "완벽한 내부 통제와 유연한 외부 확장"

 기존 시타델은 중심부(성채)가 덩어리 거대한 '일반 모놀리딕'이라 성채 내부가 스파게티 코드로 꼬이는 고질적인 문제가 있었습니다. 하지만 중심부를 모듈러 모놀리딕으로 설계하면 이야기가 완전히 달라집니다.

  -  성채 내부의 청정함 유지 : 중심부 시스템 안에서도 회원, 주문, 상품 등이 모듈로 칼같이 쪼개져 있기 때문에, 코드가 엉키지 않아 내부 유지보수성이 극대화됩니다.

  - 시타델 구조를 운영하다가 특정 모듈(예: 결제 모듈)의 트래픽이 감당 안 돼서 외곽 마을(MSA)로 탈출시켜야 할 때, 이미 '모듈러'로 경계가 짜여 있기 때문에 코드 수정 거의 없이 뜯어서 밖으로 휙 던지면(독립 서비스화) 끝납니다. MSA로의 전환 리스크가 제로에 수렴하게 되죠.

2. 성능 측면의 이점: "인프로세스 통신의 속도 + 필요한 곳만 무한 부스팅"

 전체 MSA의 가장 큰 성능 저하 원인은 모든 서비스가 네트워크(API)를 거쳐 소통하느라 생기는 네트워크 지연(Network Latency)입니다. 모듈러 모놀리딕 + 시타델  조합은 이 문제를 기가 막히게 해결합니다.

 - 대부분의 요청은 빛의 속도로 : 핵심 비즈니스(성채) 안에서의 모듈 간 소통은 네트워크를 타지 않고 메모리 내부(In-Process)에서 직접 함수를 호출하므로 성능이 압도적으로 빠르고 안정적입니다.

 - 트래픽이 폭발하는 특정 기능(예: 실시간 알림 발송, AI 추천 로그 분석 등)만 시타델 형태로 외곽 마이크로서비스로 분리해 둡니다. 그리고 그 외곽 서비스만 서버를 10대, 20대 늘리는(Scale-out) 구조를 취합니다.

 - 결과적으로 "안정적인 성능"을 베이스로 깔고, "대규모 트래픽 대응력"까지 동시에 갖추게 됩니다.

3. 비용과 운영 측면의 이점: "DevOps 지옥으로부터의 해방"

 완전한 MSA를 하면 수십 개의 DB와 쿠버네티스 같은 복잡한 인프라 관리 때문에 개발자보다 인프라 엔지니어가 더 많이 필요해지는 배보다 배꼽이 더 큰 상황이 옵니다.

 - 모듈러 모놀리딕 + 시타델 아키텍처는 데이터베이스(DB)를 성채용 거대한 하나(혹은 스키마 분리)와 외곽 특수 서비스용 1~2개 정도로만 쪼개서 관리하면 됩니다.

 - 분산 트래픽 아키텍처의 최대 난제인 '분산 트래픽 분산 데이터 정합성(Saga 패턴 등)'을 고민할 필요가 거의 없어지므로, 개발 팀의 정신 건강과 인프라 비용을 엄청나게 아낄 수 있습니다.

대기업인 우버(Uber)나 대형 테크 기업들도 최근 너무 쪼갠 MSA에서 다시 이와 유사한 '거대 도메인 묶음(Macro/Modular) + 특수 서비스 분리' 형태로 회귀하고 있습니다.