모듈 경계
한 줄 정의
모듈 경계는 함께 바뀌는 코드와 독립적으로 바뀌어야 하는 코드를 나누어 변경 영향과 의존성을 관리하는 기준이다.
실무에서 왜 문제 되는가
- 모듈이 너무 크면 작은 변경도 전체 빌드와 테스트에 영향을 준다.
- 모듈을 너무 잘게 나누면 경계 간 DTO, 매핑, 설정 비용이 커진다.
- 경계가 불명확하면 다른 모듈의 내부 구현을 직접 사용하게 된다.
- 데이터 소유권이 섞이면 트랜잭션과 정합성 책임이 모호해진다.
실무 판단 기준
| 기준 | 설명 |
|---|---|
| 변경 이유 | 같이 바뀌는 코드는 같은 모듈 후보가 된다 |
| 데이터 소유권 | 같은 데이터를 책임지는 코드가 경계를 이룬다 |
| 의존 방향 | 경계가 정해진 뒤 허용할 참조 방향을 정한다 |
| 배포 단위 | 독립 배포가 필요하면 더 강한 경계가 필요하다 |
자주 나는 실수
- 패키지만 나누고 내부 구현은 서로 직접 참조한다.
- 공통화를 너무 빨리 해서 업무 개념을 common에 넣는다.
- 모듈 분리를 마이크로서비스 분리와 동일하게 생각한다.
- DB 테이블을 공유하면서 모듈이 독립적이라고 착각한다.
확인 방법
- 모듈 간 import 방향과 순환 의존을 확인한다.
- 한 기능 변경 시 수정되는 모듈 수를 본다.
- 다른 모듈의 내부 Entity나 Repository를 직접 사용하는지 확인한다.
핵심 요약
모듈 경계는 변경 이유와 데이터 소유권을 기준으로 정한다.
경계가 강할수록 독립성은 높아지지만 통합 비용도 증가한다.
공통 모듈은 재사용보다 안정성과 의미가 먼저 검증되어야 한다.
모듈 분리는 배포 단위 분리와 같지 않다.
좋은 경계는 변경 영향으로 먼저 검증하고, 의존 방향은 그 경계를 지키기 위한 규칙으로 둔다.
꼬리 질문
- 모듈을 나누는 기준은 무엇인가?
- common 모듈이 커지면 어떤 문제가 생기는가?
- 모듈 경계와 트랜잭션 경계는 어떤 관계가 있는가?