[개발일지] 02. Micro-Features Architecture가 무엇이고, Flyleaf에 왜 적용했을까요?

모듈화에 관심을 갖게 된 계기

이전 글에서 이야기했지만, 제가 최근 진행했던 TapTap이라는 프로젝트에서 모듈화를 적용해보는 경험을 할 수 있었습니다.

 

처음에는 단순히 부트캠프 특성상 새로운 기술에 도전해보고 싶다는 이유로 모듈화를 도입했습니다. 하지만 프로젝트 진행 당시에는 데드라인의 압박과 TCA의 높은 러닝 커브 때문에 모듈화에 대한 충분한 학습이 이루어지지 못했고, 모듈화 구조에 대한 이해도 역시 부족한 상태였습니다. 

 

쇼케이스가 끝난 이후 부족했던 모듈화 학습을 다시 진행했고, 그 과정에서 TapTap의 모듈 구조를 다시 살펴보게 되었습니다. 겉보기에는 모듈이 나뉘어 있는 것처럼 보였지만, 실제로는 논리적으로만 분리되어 있을 뿐 물리적으로는 제대로 분리되지 않은 구조였고, 결과적으로 모듈화의 장점을 제대로 활용하지 못하고 있었습니다.

 

이를 개선하기 위해 모듈 구조를 다시 정리하는 리팩토링을 진행했고, 그 과정에서 모듈화가 실제로 어떤 이점을 가지는지 직접 체감할 수 있었습니다. 리팩토링 이전과 이후를 모두 경험해보니, 모듈화의 장점이 훨씬 더 와닿았습니다.

 

리팩토링 과정에서 모듈 간 의존성을 정리하는 과정 자체가 아키텍처를 개선하는 경험이 되었고, 자연스럽게 모듈화에 관심이 생기게 되었습니다.

---

왜 Micro-Features Architecture를 적용했을까?

물론 현재 프로젝트는 1인 개발로 진행하는 개인 프로젝트이고, 프로젝트의 규모가 크지 않기 때문에 이러한 구조가 오버엔지니어링일 수도 있다고 생각합니다.

 

하지만 다음과 같은 이유로 Micro-Features Architecture를 적용해보기로 했습니다.

- TCA + SwiftUI 환경이 아닌 다른 아키텍처 환경에서의 모듈화를 경험해 보고 싶었습니다.

- Feature 내부 구현을 외부에서 직접 의존하지 않도록 Interface를 통해 의존성을 분리하는 구조를 경험해보고 싶었습니다.

---

Micro-Features Architecture?

What is Tuist? | Tuist

Micro-Features Architecture은 앱을 기능(Feature) 단위의 작은 모듈로 나누어 구성하는 아키텍처 방식입니다. 이 구조는 Tuist 문서에서 소개된 아키텍처 가이드로, 앱의 확장성, 빌드 속도, 테스트 효율성을 높이기 위한 목적으로 제안되었습니다.

 

+ 현재는 Micro-Features Architecture에서 TMA로 명칭이 공식적으로 바뀌었습니다. (관련 링크)

 

핵심 아이디어는 간단합니다.

앱을 여러 개의 독립적인 Feature로 나누고, 각 Feature를 명확한 API를 가진 작은 모듈로 구성한다.

 

하나의 iOS 앱은 보통 여러 기능으로 이루어져 있습니다.

 

예를 들어 아래와 같은 기능들이 있을 수 있습니다.

1. 로그인

2. 회원가입

3. 검색

4. 홈화면

5. 프로필

 

Micro-Features Architecture에서는 이러한 기능을 하나의 모듈로 묶는 것이 아니라, 더 작은 단위의 Feature 모듈로 분리하여 구성합니다. 각 Feature는 독립적으로 개발, 테스팅, 실행될 수 있는 작은 블럭처럼 동작하며, 이러한 블럭들을 조합하여 전체 앱을 구성하게 되는 것이 Micro-Features Architecture 입니다.

---

Micro-Features의 구성

Tuist가 제안하는 Micro-Feature 구조는 보통 아래와 같은 여러 Target으로 구성됩니다.

 

Feature(Source)

- 실제 Feature의 구현 코드가 포함된 모듈

 

FeatureInterface

- Feature의 공개 인터페이스(API)를 정의하는 모듈

 

FeatureTesting

- 테스트에 사용할 Mock, Stub, Test Data 등을 제공하는 모듈

 

FeatureTests

- 해당 Feature의 Unit Test와 Integration Test를 포함하는 모듈

 

FeatureExample

- Feature를 독립적으로 실행해볼 수 있는 Example 앱

 

즉, 하나의 Feature는 단순히 하나의 모듈이 아니라 여러 역할을 가진 모듈들의 조합으로 구성됩니다.

---

Micro-Features Architecture의 핵심 특징

1. Feature 단위 모듈화

기존 모듈화 구조에서는 UI, Domain, Network 등의 레이어 중심 구조로 모듈을 나누는 경우가 많았습니다.

 

하지만 Micro-Features Architecture에서는

- LoginFeature
- HomeFeature
- SearchFeature
- ProfileFeature

 

처럼 Feature 중심으로 모듈을 분리합니다. 이를 통해 하나의 Feature를 독립적으로 개발하고 테스트할 수 있습니다.

 

2. Interface 기반 의존성 구조

Micro-Features Architecture에서 가장 중요한 특징은 Interface 모듈의 존재입니다. 외부 모듈은 Feature의 구현이 아니라 Interface에만 의존해야합니다. 

 

예를 들어 로그인 기능이 있다면 구조는 아래와 같이 나뉩니다.

- LoginInterface: 외부에 공개되는 API

- LoginFeature: 실제 로그인 기능 구현

import LoginFeature // X
import LoginInterface // O

외부 모듈은 LoginFeature가 아니라 LoginInterface에만 의존하게 됩니다.

 

이렇게 하면 Feature 내부 구현이 변경되어도 외부 코드에 영향을 주지 않고, 모듈 간 결합도를 낮출 수 있습니다.

---

왜 Micro-Features Architecture를 사용할까?

1. 확장성

Feature 단위로 모듈이 분리되어 있기 때문에 기능이 추가되더라도 기존 구조에 큰 영향을 주지 않습니다.

Features
 ├ Login
 └ Home

예를 들어 이러한 Feature가 있다고 가정해보겠습니다. 여기에 새로운 Search 기능이 추가된다면 기존 코드를 수정하는 것이 아니라 새로운 Feature 모듈을 추가하면 됩니다.

Features
 ├ Login
 ├ Search
 └ Home

기존 Feature와 독립적으로 동작하기 때문에 다른 기능에 영향을 주지 않고 기능을 확장할 수 있습니다.

 

2. 빌드 속도 개선

작은 모듈 단위로 분리되어 있기 때문에 전체 앱을 빌드하지 않고 Feature 단위로 빠르게 빌드할 수 있습니다.

 

예를 들어 Login 기능을 개발하고 있는 상황이라고 가정해보겠습니다. 기존 구조에서는 Login 기능을 수정하면 전체 앱을 다시 빌드해야 합니다.

App
 ├ Login
 ├ Home
 ├ Profile
 └ Search

 

하지만 Micro-Features Architecture에서는 LoginFeature만 다시 빌드하면 됩니다. 이처럼 변경된 모듈만 다시 빌드하기 때문에 빌드 시간을 단축할 수 있습니다.

 

3. 테스트 효율성

각 Feature가 독립적인 모듈이기 때문에 테스트를 쉽게 작성할 수 있습니다.

 

예를 들어 Login 기능의 테스트를 작성한다고 가정해보겠습니다.

Login
 ├ LoginFeature
 ├ LoginInterface
 ├ LoginTesting
 └ LoginTests

Login과 관련된 테스트는 Login 모듈 안에서 작성할 수 있기 때문에 다른 Feature와 섞이지 않습니다. Mock이나 Test Data도 Feature 내부에서 관리할 수 있어 테스트 코드의 유지보수도 용이합니다.

 

 

4. 예제 앱

개인적으로 모듈화를 적용하면서 가장 체감이 크게 되었던 장점이 바로 예제 앱입니다.

 

클라이언트 개발을 하다 보면 UI 작업을 위해 특정 화면을 빠르게 확인해야 하는 경우가 많습니다. 하지만 기존 구조에서는 특정 화면을 확인하기 위해 앱의 진입점을 수정하거나 네비게이션 흐름을 변경해야 하는 번거로움이 있었습니다. 또한 단순히 한 화면을 확인하기 위해서도 전체 앱을 빌드해야 했기 때문에 빌드 시간이 오래 걸리는 문제도 있었습니다.

 

하지만 Micro-Features Architecture에서는 Feature 단위로 예제 앱을 만들 수 있기 때문에 전체 앱을 실행하지 않고도 해당 Feature만 독립적으로 실행하여 확인할 수 있습니다.

 

또, 예제 앱은 협업에서도 엄청난!! 장점을 제공합니다.

예를 들어 디자이너와 온라인 환경에서 작업할 때 예제 앱을 테플이나 빌드 파일로 공유하면, 전체 앱을 실행하지 않고도 해당 Feature 화면만 빠르게 확인하며 피드백을 주고받을 수 있습니다.

 

Flyleaf 개발에서도 적극 활용 중!

---

Toss Team의 Micro-Features Architecture 이야기

Micro-Features Architecture에 대해 레퍼런스를 찾아보던 중 우연히 토스 팀의 이야기를 접하게 되었습니다. 글을 읽으면서 여러 내용이 인상 깊었지만, 개인적으로 가장 공감이 갔던 부분은 예제 앱에 대한 이야기였습니다.....! 

불을 처음 발견한 원시인 마냥.. 예제 앱을 처음 접했을 땐 WOW

여러분 정말정말 편합니다... (예제 앱 신봉자)

 

넘어가 볼까요? ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

---

 

저는 고작 열댓 개의 모듈과 몇 천 줄 정도의 코드 규모의 작은 프로젝트에서도 모듈화의 장점을 체감할 수 있었는데, 토스처럼 수백 개의 모듈과 수백만 줄의 코드로 구성된 슈퍼앱 환경에서는 모듈화의 중요성이 얼마나 더 클까? 하는 생각이 들었습니다.

 

토스와 같은 대규모 서비스에서는 수많은 기능이 동시에 개발되고 유지보수됩니다. 이런 환경에서 모듈 간 의존성이 정리되지 않은 상태라면 빌드 속도, 개발 속도, 협업 효율 모두 크게 영향을 받을 수 밖에 없다고 생각합니다.

 

정말 재밌으니까 여러분도 한 번 찾아보시는 걸 추천드립니다 !! 

영상ver랑 글ver 있는데, 영상ver 한 번 보시고 다시 글로 읽어보시는 거 추천드립니다!

 

https://toss.tech/article/slash23-iOS

https://youtu.be/zsLQQTuGiVw?si=hy9AinGPiQ4eG4n6