모듈화가 무엇인지 살짝 알아보자

[dbqls200]

모듈화 Modularization

앱을 여러 개의 독립적인 모듈로 나누어 개발하는 설계 방식
단순히 규모가 큰 것을 작게 나눈 조각이 아니라, 하나 이상의 논리적인 기능을 수행하기 위한 명령어들의 집합을 의미한다.

모듈은,

• 다른 프로그램이나 다른 모듈에서 호출하여 사용할 수 있어야 한다.
• 모듈 자체로서 재사용될 수 있고 독립적으로 컴파일 가능해야 한다.

모듈은 하나의 완결된 기능 단위이며, 다른 코드와의 의존성을 최소화해 유지보수성과 확장성을 높일 수 있다 🚀

왜 모듈화를 해야 할까?

모듈화를 통한 장점 중 가장 공감됐던 글

모듈화를 도입한 사례 중, 타다 테크 블로그에서 본 SwiftUI 프리뷰 효율화 관련 글이, 현재의 나에게 가장 와닿는 이유였다.

🔗 모듈화를 통한 SwiftUI Preview 효율화

요약해보면,

• SwiftUI 프리뷰는 종속된 모든 코드를 컴파일해야 하므로 프리뷰 로딩 속도가 느릴 수밖에 없다.
• 타다에서는 UI 코드가 필수적이지 않은 Core 모듈이나 프레임워크까지 참조하게 되면서 SwiftUI 프리뷰 성능에 영향을 주는 문제가 있었다.
• 이를 해결하기 위해, Feature 모듈 내부에 UI 모듈을 분리해 실제 UI에 필요한 최소한의 의존성만 유지하도록 구조를 개선했다.
• 결과적으로 불필요한 종속성 제거 → 프리뷰 성능 개선이라는 실질적인 이점을 얻을 수 있었다.

이 글을 보면서, “단순히 구조를 나누고 의존성을 최소화하는 것이 아니라, 이렇게 개발 효율과 경험을 직접적으로 개선할 수 있구나.”를 체감할 수 있었다.

---

모듈화 방식

아래 예시 그림처럼, 모듈화는 구조화된 개발을 위해, 특정 기준을 갖고 계층을 분리할 수 있다.

• 기능 기반 : 앱의 화면 단위나 기능 단위로 나누는 방식
• 레이어 기반 : 아키텍처 계층 기준으로 나누는 방식
• 공통 모듈 분리 : 여러 기능에서 공통으로 사용하는 모듈을 따로 분리

모듈을 어떻게 나눌지에 대한 기준은 프로젝트 상황에 따라 달라질 것 같다.
그래서 모듈화를 도입할 때 팀이 함께 고민해야 하는 부분은, “어떻게 나누느냐”가 아니라 “어느 정도 크기로 나눌지”인 것 같다 !

너무 작게 만들면 → 관리하기 힘들다.
너무 크게 만들면 → 모듈화의 이점이 줄어든다.

그래서 다들 말하는

모듈 간 결합은 느슨하게, 모듈 내 응집은 강하게.

원칙이 중요하다고 생각했다.

좋은 모듈화를 위해서는 ?

좋은 모듈화란, 각 모듈이 독립적이면서도 자기 역할에 집중된 구조를 만드는 것을 의미한다.

이때 중요한 개념이 결합도와 응집도이다.

결합도

모듈 간의 상호 의존 정도

• 두 모듈이 얼마나 서로 밀접하게 연결되어 있는지를 나타내는 지표이다.
• 결합도가 높을수록, 하나의 모듈 변경이 다른 모듈에 영향을 줄 가능성이 커진다.
• 반대로 결합도가 낮으면 → 수정 시 검토할 범위가 줄어들어 유지보수가 쉬워진다.

응집도

모듈 내부 요소들이 하나의 목적에 집중되어 있는 정도

• 모듈 안의 함수나 클랙스들이 얼마나 관련된 책임을 공유하고 있는지를 뜻한다.
• 응집도가 높을수록 해당 모듈이 하나의 역할에 집중하고 있다고 본다.
• 응집도가 낮을수록 다양한 역할이 섞여 있어서 재사용과 테스트가 어려워진다.

좋은 모듈화는 낮은 결합도 + 높은 응집도를 가져야 한다.

다른 곳에서는 어떻게 모듈화 하고 있을까?

토스

책임과 역할에 따라 계층 분리

하위 계층에 있는 모듈은 상위 계층에 있는 모듈을 의존할 수 없다.

App : 사용자에게 제공될 최상위 계층
Feature : 수백 개의 서비스 모듈 위치
Foundation : 공통적으로 쓰이는 유틸리티 모듈 위치

모듈 간 의존성 폭발적으로 증가
같은 계층 내에 의존 관계 복잡도 증가
순환 참조 문제 발생 및 전반적인 모듈 구조 이해도 어려움
→ Tuist의 Microfeature 아키텍처 도입

Microfeature 이것 뭐에요 .. ?

대충 이런 친구구나 ~
모듈화에 대해 좀 알고 기본적인 거 실습해보고 나서 나중에 이 글 다시 읽어봐야겠다 ~

레고처럼 조립하는 토스 앱

카카오뱅크는 기능 단위로 모듈을 분리했다.

• 로그인, 송금, 계좌조회 등 주요 기능 단위로 모듈 분리
• 공통적으로 사용되는 네트워크, 디자인 시스템은 별도의 공통 모듈로 분리

뱅크샐러드는 처음엔 단순한 공통 모듈 분리에서 시작해서 점차 기능 기반 모듈화로 확장했다.

• 공통적으로 사용하는 Utility나 디자인 컴포넌트를 먼저 모듈화
• 점차 Feature 단위로 나누며 점진적으로 구조 고도화

그래서 Swift에서 말하는 모듈은 뭔데요?

Swift에서 말하는 모듈이란,

외부에서 import해서 사용할 수 있는 하나의 독립적인 단위를 말한다.

• 하나의 모듈은 컴파일 단위이자 접근 제어 범위를 결정하는 단위이다.

Swift에서 모듈화를 진행하는 방법에는 세 가지가 있다.

• Library
• Framework
• Swift Package

Library

• 코드와 데이터를 포함하는 집합 (리소스 포함 X)
• 링킹 시점에 따라 Static / Dynamic으로 나눌 수 있다.

Static Library

• 컴파일 시점에 링킹되어 .o (오브젝트 파일)로 변환됨.
• 타겟의 소스 코드와 병합되어 하나의 실행 파일로 만들어짐.
• 실행 시 힙(Heap) 메모리에 올라감.

Dynamic Library

• 런타임 시점에 링킹됨.
• 실행 파일에는 참조 값만 포함되며, 필요할 때 메모리에 동적으로 로드됨.
• 앱 시작 속도는 빠르지만, 런타임 성능은 다소 낮을 수 있음.

iOS에서는 Stand-alone Dynamic Library 사용이 제한되므로, 동적 라이브러리는 보통 Framework 형태로 제공된다.

Framework

• 라이브러리 + 리소스를 포함하는 패키지 형태.
• 배포 및 재사용 가능한 형태로 만든 번들
• 내부에 포함된 라이브러리는 Static / Dynamic 일 수 있음.

🍎 UIKit, Foundation 등은 Apple이 제공하는 시스템 다이나믹 프레임워크로, 런타임에 필요할 때 메모리에 로드되어 사용된다.

Swift Package

• Package.swift라는 파일 하나로 모듈 정의 및 의존성 관리가 가능하다.
• 내부적으로는 각 모듈을 Target으로 관리한다.

products	외부에 공개되는 모듈의 목록
targets	실제 코드 및 의존성 정의 단위
dependencies	외부 패키지 의존성 정의

Xcode와 모듈의 관계

Target과 Module을 혼용하여 사용하는 경우가 있지만,

Module은 그룹핑에 초점을 맞춘 거라면

Target은 빌드의 목적을 갖고 있다.

Target

• Xcode의 빌드 단위
• Swift 컴파일러가 인식하는 모듈 단위
• 보통 하나의 Target == 하나의 모듈
• 모듈의 최소 단위

Scheme

• 특정 Target을 어떻게 빌드 / 실행 / 테스트할 것인지 정의하는 설정
• 여러 개의 Target을 가진 프로젝트에서 빌드 대상을 선택할 때 사용

Xcode에서는 Target 단위로 모듈이 정의되고 Target을 빌드하는 방식은 Scheme으로 관리된다.

---

🗣️ 같이 얘기해봐요 !

다들 프로젝트 할 때 언제 모듈화가 필요하다는 생각이 드셨나요 ?

저는 늘 규모가 작은 프로젝트만 해왔어서 모듈화의 필요성을 직접적으로 체감한 적이 없어서 스터디원들의 경험이 궁금합니다!

• 프로젝트 규모가 커지면서 컴파일 시간이 길어졌던 경험?
• 한 기능을 수정하려 했는데 다른 쪽 코드에 영향이 가서 힘들었던 경험?
• 다른 사람과 협업하면서 충돌이 자주 났던 경험?

추가로, 어제 플젝 iOS 팀이랑 앞으로 기술 스택에 대해 잠깐 얘기를 했었는데요.
개인적으로 모듈화를 고려하는 시점이 언제가 좋을지에 대해 궁금해졌어요 !

프로젝트 시작부터 모듈화를 고려해서 개발하자 ~
vs
나중에 앱 좀 커지면 도입하자 ~

스터디원들이랑 같이 얘기해보고 싶어서 가져왔습니다.

---

참고자료

모듈화 개념
Modularization