Modular Monolith: 대부분의 스타트업이 시작해야 할 아키텍처

Source: Dev.to

“마이크로서비스만 시작하라”는 문제점

• 마이크로서비스는 조직 규모 문제를 해결하지만, 초기 단계 제품의 혼란을 해결하지는 못합니다.
• 초기 스타트업은 보통 다음과 같은 상황에 있습니다:
  • 제한된 자원
  • 급변하는 요구사항
  • 작은 팀

마이크로서비스를 도입하면:

• 복잡한 배포 파이프라인
• 증가된 운영 오버헤드
• 분산 디버깅 어려움

하나의 어려운 문제(코드 구조)를 다섯 개의 새로운 문제와 교환하게 됩니다. 이 단계에서는 그 트레이드오프가 거의 의미가 없습니다.

모듈형 모놀리쓰가 실제로 무엇인지

모듈형 모놀리쓰는 강력한 내부 경계를 가진 단일 배포 가능한 애플리케이션입니다.

핵심 특성

• 명확한 모듈 경계(예: /users, /billing, /analytics)
• 각 모듈이 자체 도메인 로직과 데이터 접근을 캡슐화
• 단순히 폴더 구조가 아니라, 경계가 코드와 아키텍처에 의해 강제됨

초기 단계에서 이렇게 잘 작동하는 이유

• 운영 비용이 저렴 – 한 번 배포하면 인프라 비용이 예측 가능하게 유지됩니다.
• 변경이 빠름 – 요구사항이 매일 바뀌는데, 단일 코드베이스가 수정하기 쉽습니다.
• 보안이 쉬움 – 하나의 애플리케이션이라 노출 표면이 적습니다.
• 팀 명확성 – 두 명의 개발자만 있어도 “누가 프로덕션을 망가뜨렸나?”라는 미스터리가 없습니다.

가장 중요한 부분: 깨끗한 경계

모듈형 모놀리쓰는 경계가 무시될 경우 실패합니다.

내가 적용하는 규칙

1. 모듈은 자신만의 데이터를 소유해야 하며, 다른 모듈의 테이블에 절대 접근하지 않아야 합니다.
2. 모듈 간 통신은 잘 정의된 인터페이스 또는 서비스 를 통해 이루어져야 합니다.
3. 순환 의존성을 허용하지 않으며, 각 모듈은 독립적으로 테스트 가능해야 합니다.

이 규율을 지키지 않으면 모놀리쓰는 금방 얽힌 코드베이스로 전락합니다.

확장 스토리 (여기서 빛을 발한다)

실제로 규모가 커질 때:

• 기존의 모듈 구조 덕분에 서비스를 추출하는 것이 직관적입니다.
• 점진적으로 트래픽이 많은 모듈을 독립 마이크로서비스로 옮길 수 있습니다.
• 전체 재작성은 필요 없으며, 아키텍처는 진화할 뿐, 초기화되지 않습니다.

초기 창업자에게 추천하는 이유

• 속도, 비용, 단순성을 최적화합니다.
• 엔지니어링 복잡성에 앞서 제품‑시장 적합성에 집중할 수 있게 해줍니다.
• 마이크로서비스를 배제하는 것이 아니라, 필요할 때까지 미루는 전략입니다.

이 규율은 변화를 두려워해서가 아니라, 실용적인 엔지니어링을 위한 것입니다.

마무리 생각

마이크로서비스는 진지함의 배지가 아닙니다.
문제를 충분히 이해하기 전에 짓는 아키텍처가 가장 비싼 아키텍처입니다.

모듈형 모놀리쓰부터 시작하세요. 진정한 규모가 복잡성을 스스로 얻게 하세요.