5장. 모듈이란 무엇인가?

모듈 분할의 전략적 기준들

Jul 7. 2025

모듈은 단순한 기능 단위가 아니라, 독립성과 재사용 가능성을 갖춘 설계 단위입니다. 예를 들어 한 글로벌 유통 플랫폼의 물류 시스템은 주문, 결제, 배송 등의 개별 모듈로 구성되어 있어, 빠른 개선과 확장이 가능합니다. 소프트웨어에서의 모듈 또한 기능 중심으로 구현되며, 설계 단위로 기능합니다. 단지 물리적으로 눈에 보이지 않고, 소프트웨어 자체가 디지털 데이터이기 때문에 모듈 구성 단위를 수치화하거나 추적하기 용이하다는 특징이 있습니다.

또한, 모듈을 평가하는 주요 기준은 응집도(cohesion)와 결합도(coupling)이며, 이는 좋은 모듈을 판단하는 핵심 지표입니다.

5.1 모듈의 본질은 ‘경계와 책임’

많은 개발자들이 모듈을 ‘하나의 폴더’, ‘클래스’, ‘라이브러리’ 등으로 간단히 정의합니다. 그러나 진정한 모듈은 명확한 책임(Responsibility)을 가진 독립된 단위입니다. 이 책임은 기능, 데이터, 인터페이스, 상태 등 다양한 차원에서 정의되며, 외부와는 느슨하게 결합되고 내부적으로는 강하게 응집되어야 합니다.

모듈은 단순한 구조 분할이 아니라, 시스템을 구성하는 핵심 건축 단위입니다. 잘 정의된 모듈은 유지보수, 확장, 재사용, 테스트, 협업 등 모든 개발 활동의 기반이 됩니다.

일부는 프로그래밍 언어 특성상 이미 모듈이 나뉘어 있다고 생각할 수 있습니다. 하지만, 명확한 규칙과 의도가 없는 구조는 모듈이 아니라 단순한 소스코드의 묶음에 불과합니다.

5.2 응집도와 결합도: 좋은 모듈의 기준

모듈의 품질은 응집도와 결합도로 평가할 수 있습니다.

응집도(cohesion): 모듈 내부 구성요소 간의 관련성입니다.

결합도(coupling): 모듈 간 의존성의 정도를 의미합니다.

이상적인 모듈은 응집도는 높고 결합도는 낮아야 합니다.

예를 들어, 사용자 인증 기능에서 로그인, 로그아웃, 토큰 발급, 세션 관리 기능이 하나의 모듈 내에 모여 있다면 이는 높은 응집도를 의미합니다. 반면, 이 모듈이 사용자 관리나 결제 모듈과 과도하게 양방향으로 호출을 주고받는다면 높은 결합도로 인해 유지보수에 어려움을 겪을 수 있습니다.

이 두 지표는 모듈 간 인터페이스를 설계하는 기준이자, 모듈의 경계를 정의하는 핵심 기준이기도 합니다.

실무에서는 SonarQube, Structure101, Lattix와 같은 정적 분석 도구를 통해 실제 코드의 응집도와 결합도를 시각적으로 분석하고 개선 방향을 도출할 수 있습니다.

※ 실무 사례: 모놀리식 구조에서 경계 실패의 대가

한 글로벌 콘텐츠 플랫폼은 모든 기능이 단일 애플리케이션에 얽혀 있는 구조로 인해, 하나의 변경이 전체 서비스 장애로 이어지는 문제가 반복되었습니다. 사용자 인증, 결제, 스트리밍 제어 등 기능이 명확히 분리되지 않았기 때문입니다. 이후 각 기능을 명확히 분리하고 독립 서비스로 전환함으로써 시스템 복잡도를 낮추고 확장성과 안정성을 확보할 수 있었습니다.

5.3 모듈의 유형: 기능, 서비스, 플랫폼 모듈

소프트웨어 모듈은 역할과 배치 위치에 따라 다음과 같이 분류할 수 있습니다.

기능 모듈 (Functional Module): 단일 기능을 수행하는 모듈입니다. 예: 결제 처리, 이미지 인코딩 등

서비스 모듈 (Service Module): 비즈니스 로직 중심의 독립 실행 단위입니다. 예: 회원 가입 API, 배송 추적 API

플랫폼 모듈 (Platform Module): 다른 모듈에 공통 기능을 제공하는 기반 모듈입니다. 예: 인증 시스템, 로깅 프레임워크

기능 모듈은 가장 일반적인 형태로, 기능 단위의 분할이 핵심입니다. 하지만 기능의 복잡도나 규모에 따라 적절한 분해가 선행되어야 합니다.

서비스 모듈은 일반적으로 기능 모듈보다 규모가 크며, 여러 기능이 조합되어 하나의 서비스를 이루는 경우가 많습니다. 이 경우 재사용성이나 범용성이 떨어질 수 있습니다.

플랫폼 모듈은 공통 인프라 역할을 하며, 규모가 크고 수명 주기(Lifecycle)도 깁니다. 이러한 모듈은 다른 모듈에 비해 비대칭적인 특성을 갖습니다.

※ 주의할 점: 흔히 마이크로서비스와 모듈을 혼동하지만, 모듈은 아키텍처적 설계 단위이고, 마이크로서비스는 배포 단위이자 실행 단위입니다.

※ 실무 사례: 서비스 모듈화의 과잉과 복잡성 증가

한 글로벌 모빌리티 기업은 기능 단위로 서비스를 지나치게 세분화하면서 수천 개의 마이크로서비스가 생성되었습니다. 이는 단일 책임 원칙을 따르려는 의도였지만, 서비스 간 호출이 과도하게 얽히며 복잡성이 증가하고, 운영 난이도와 장애 추적 비용도 커졌습니다. 이후 관련 기능을 도메인 중심 서비스로 통합하거나, 공통 기능을 플랫폼 모듈로 추상화하여 구조를 단순화하였습니다.

5.4 경계를 정의하는 방법

모듈을 설계하실 때는 ‘경계(Boundary)’를 명확히 설정하는 것이 가장 먼저 해야 할 일입니다. 다음과 같은 질문들이 많은 도움이 됩니다.

이 모듈은 무엇을 책임지나요?

어떤 데이터를 내부에서 유지하며, 외부와는 어떤 데이터를 교환하나요?

어떤 기능을 제공하고, 어떤 이벤트에 반응하나요?

변경이 발생하면, 어떤 모듈까지 영향을 받게 되나요?

이러한 질문을 통해 명확한 경계를 설정하시면, 코드 구조뿐 아니라 문서화, 테스트 전략, 배포 단위, 팀 협업 방식까지도 보다 체계적으로 구성하실 수 있습니다.

응집도와 결합도를 측정하여 이를 기반으로 경계를 정의할 수 있으며, 이는 물리적인 객체를 다루는 기구 영역보다 오히려 정량화가 가능한 소프트웨어 영역에서 더 유리할 수도 있습니다.

응집도와 결합도를 산출하는 방식에는 다음과 같은 예시들이 있습니다.

Fan-in / Fan-out 분석: 특정 모듈이 다른 모듈로부터 얼마나 호출(Fan-in)되며, 또 몇 개의 모듈을 호출(Fan-out)하는지를 측정함으로써 의존도를 정량화할 수 있습니다.

공통 기능 분석: 모듈 내 함수들이 동일한 목적의 기능을 수행하는 정도를 파악함으로써 응집도를 평가할 수 있습니다.

Lexical Similarity / Semantic Clustering: 함수명, 클래스명, 주석 등에서 의미상 유사도를 기반으로 기능의 응집 정도를 계산할 수 있습니다.

Static Dependency Graph 분석: 소스코드 간 호출 관계를 정적으로 분석하여 시각화함으로써 결합 구조를 이해하고 개선 방향을 도출할 수 있습니다.

이처럼 다양한 분석 방식은 설계 단계뿐만 아니라, 리팩토링이나 품질 개선 시에도 유용하게 활용하실 수 있습니다.

※ 실무 사례: 경계 정의 실패로 인한 데이터 동기화 혼란

한 제조 기업에서는 여러 개발 팀이 각자 '사용자 데이터'를 관리하는 모듈을 개발하면서, 데이터의 소유권과 책임이 불분명해졌습니다. 이로 인해 사용자의 상태 정보가 서로 다른 DB에서 충돌하거나, 업데이트 시점이 엇갈려 동기화 오류가 자주 발생하게 되었습니다. 이는 모듈의 경계가 불명확하고, 데이터 책임이 명확히 분리되지 않았기 때문이었습니다. 결국 ‘데이터 소유권’을 명확히 정의하고, 이를 기준으로 모듈 경계를 다시 설정함으로써 문제가 해결되었습니다.

5.5 코드 수준에서 모듈 구현 시 고려사항

실제 구현 단계에서는 모듈이 다음과 같은 방식으로 나타날 수 있습니다.

하나의 패키지 또는 네임스페이스

독립적인 클래스 또는 클래스 집합

공유 라이브러리 또는 마이크로서비스

이때 가장 중요한 요소는 인터페이스 설계입니다.

외부에 노출되는 함수, API, 데이터 구조는 변경을 최소화할 수 있도록 설계되어야 하며, 안정성과 일관성을 확보하는 것이 중요합니다. 내부 구현은 자주 바뀔 수 있지만, 외부와 연결된 인터페이스는 최대한 안정적으로 유지하셔야 합니다.

또한 모듈 내부는 철저히 블랙박스화되어야 하며, 외부의 변화에 따라 민감하게 반응하기보다는 사전에 정의된 규칙에 따라 독립적으로 동작할 수 있어야 합니다.

※ 실무 사례: 내부 시스템 간 연계의 명시적 인터페이스화

한 대형 기술 기업은 내부 시스템 간 직접 호출로 인해 모듈 간 의존성과 변경 전파 문제가 반복적으로 발생하고 있었습니다. 이를 해결하기 위해 모든 팀이 반드시 문서화된 API를 통해 통신하도록 정책을 강화하였습니다. 결과적으로 팀 간 협업 구조가 명확해지고, 시스템의 안정성도 크게 향상되었습니다. 이러한 인터페이스 중심의 접근은 이후 플랫폼화 전략의 기반이 되기도 하였습니다.