[요약] Part 2. 마이크로서비스로 가는 징검다리, 모듈러 모놀리스

1. 모듈러 모놀리스의 개념과 장점

• 서버는 하나, 코드는 분리: 물리적인 서버 인프라는 1개로 단순하게 유지하면서, 내부 코드는 마이크로서비스처럼 도메인별로 완벽하게 격리하는 아키텍처 패턴입니다.
• 분산 시스템의 고통 제거: 네트워크 지연(Latency), 분산 트랜잭션, 복잡한 로깅 추적 등 마이크로서비스의 고질적인 인프라 문제를 겪지 않습니다.
• 안전한 확장성 확보: 모듈이 잘 격리되어 있으므로, 훗날 트래픽이 몰릴 때 필요한 모듈만 쉽게 분리하여 마이크로서비스로 전환할 수 있는 '징검다리' 역할을 합니다.
• 바이브코딩 최적화: 코드가 한 저장소에 모여 있고 모듈 경계가 명확하여, AI가 전체 시스템을 망가뜨리지 않고 특정 모듈의 컨텍스트에 집중해 코드를 작성하기 좋습니다.

2. 도메인 주도 설계와 코드 경계 설정

• 비즈니스 도메인 기준 분리: `controllers`, `services` 같은 기술적 계층이 아니라 `users`, `payments`, `orders`와 같은 비즈니스 기능(도메인) 단위로 최상위 폴더를 구성해야 합니다.
• 바운디드 컨텍스트(Bounded Context): 모든 곳에서 쓰는 거대한 범용 모델(예: 거대한 Product 클래스)을 만들지 말고, 각 모듈의 문맥에 맞게 작게 분리된 데이터 모델을 각각 정의해야 합니다.
• 직접 참조 금지: 다른 모듈의 내부 함수나 내부 클래스를 절대 `import` 해서는 안 되며, 린트(Lint) 도구를 활용해 이를 엄격하게 강제해야 스파게티 코드를 막을 수 있습니다.

3. 데이터베이스 분리와 독립성 보장

• 테이블 소유권 독점: 특정 데이터베이스 테이블은 반드시 하나의 담당 모듈만이 쓰고 읽어야 합니다. 다른 모듈이 남의 테이블에 직접 SQL 쿼리나 ORM으로 접근하는 것은 최악의 안티 패턴입니다.
• 외래 키(Foreign Key) 제약 최소화: 모듈을 넘나드는 외래 키를 걸면 모듈 간 강결합이 발생하므로 데이터베이스 레벨의 참조 무결성보다는 애플리케이션 레벨의 처리를 지향합니다.
• 조인(Join) 대신 인메모리 조합: 거대한 JOIN 쿼리 대신, 각 모듈에서 독립적으로 데이터를 가져온 후 백엔드 서버의 메모리 상에서 데이터를 조립(In-Memory Join)하는 방식을 사용해야 합니다.

4. 내부 API와 통신 설계

• 퍼블릭 인터페이스(Inbound Port): 각 모듈은 외부 모듈과 소통하기 위한 공식적인 API 파일(Facade 등) 단 하나만을 열어두고, 내부 구현의 복잡성을 완벽하게 숨겨야(캡슐화) 합니다.
• 동기 통신 vs 비동기 통신:
• 즉각적인 결과 확인과 강력한 트랜잭션이 필요할 때는 공개 인터페이스 함수를 직접 호출(동기식)합니다.
• 실행 시점의 결합도를 끊고 독립적인 흐름을 유지하려면 시스템 내부 이벤트 발행/구독(Event-Driven) 방식을 사용합니다.
• 마이크로서비스로의 전환 준비: 내부 API와 이벤트로 잘 설계된 시스템은, 향후 코드를 뜯어낼 때 로컬 함수 호출을 HTTP API나 카프카(Kafka) 통신으로 살짝만 교체하면 매끄럽게 분리될 수 있습니다.