[Architecture] Modular Architecture VS Clean Architecture

 어느날 문득 Modular Architecture와 Clean Architecture에 대한 생각을 하게 되었습니다.
모듈화나 클린이나 결국엔 개념적으로 레이어를 나누고 개발자들의 상황에 맞춰 선택적으로 사용할텐데, 둘은 어떤 공통점이 있고, 어떤 차별화된 점이 있는지에 대해서 생각해 보려고 합니다.

개념과 목적

Modular Architecture나 Clean Architecture나 모두 레이어를 분리하여 코드의 가독성을 높이는 구조를 갖고 있어서, 둘 다 코드 가독성 면에서는 비슷한 장점을 공유하고 있습니다. 그렇다면 각 접근이 iOS개발의 어떤 필요성을 충족하는지, 특히 협업과 코드베이스 관리에 얼마나 유리한지, 유연성과 유지보수성이 어떻게 앱 품질에 기여하는지에 대해서 생각해 보게 되었습니다.

우선 코드의 가독성을 조금 더 세분화해서 설명해보면 다음과 같은 요소들이 중요하게 작용합니다.

1. 이해하기 쉬운 구조: Modular Architecture와 Clean Architecture 모두 코드의 가독성을 높이기 위한 구조를 제공합니다. 가독성이 높은 코드란, 그 코드가 하는 일이 명확히 드러나는 구조를 의미합니다. 즉, 다른 개발자가 봤을 때 코드의 의도를 쉽게 파악할 수 있는 코드입니다. 
   • iOS 앱에서 Navigation 기능이 있다면, 모듈화된 경우 별도의 네비게이션 모듈로 관리하고, 클린 아키텍처에서는 특정 레이어(예: Presentation Layer)에서만 네비게이션 처리를 담당하게 합니다. 이렇게 하면 네비게이션이 어디서 다뤄지는지 명확해져 협업자들도 쉽게 코드를 이해할 수 있습니다.
   • 이때 네이밍, 모듈 간 역할 분리, 명확한 인터페이스 설계가 이뤄지면 각 기능의 역할이 구체화되고, 코드를 읽기 쉽게 만듭니다.
2. 복잡성 관리: 프로젝트가 커질수록 복잡도가 높아지는데, 이때 모듈 분리를 통해 복잡성을 각 모듈 내로 제한할 수 있습니다. 이렇게 하면 각 모듈 코드가 더 작고, 읽기 쉬운 상태로 유지되며, 이를 통해 모듈 내 코드를 쉽게 파악할 수 있는 이점이 생깁니다. 특히 모듈 간의 의존성이 명확하게 관리되면, 특정 기능을 수정하거나 추가할 때 다른 모듈에 미치는 영향을 최소화할 수 있습니다.
3. 독립적인 책임 부여: Clean A.는 레이어를 분리해서 관심사를 분리하는 반면, Modular A.는 기능을 독립된 모듈로 나누어 각 모듈이 자체적으로 기능을 수행하도록 합니다. 이때 모듈화가 가독성에 미치는 영향은 모듈 자체의 명확한 역할 분리에 있습니다. 모듈별로 책임이 확실히 나누어지면, 각 모듈의 코드를 읽을 때 해당 모듈이 무엇을 담당하는지 명확히 알 수 있습니다.
4. 단일 책임 원칙(SRP) 적용의 용이성: 모듈화된 구조에서는 단일 모듈이 하나의 역할을 담당하는 것이 명확해지므로, 단일 책임 원칙을 적용하기가 더 쉬워집니다. 이렇게 하면 코드의 가독성이 더욱 좋아지며, 모듈 자체의 역할이 명확하게 구분되기 때문에 유지보수나 코드 수정 시 어디를 고쳐야 하는지 쉽게 파악할 수 있습니다.
5. 외부 툴의 개입: Modular Architecture는 모듈화와 의존성 주입을 손쉽게 관리하기 위해 외부 툴이 요구되는 경우가 많습니다. Tuist나 XCodeGen은 이러한 모듈 관리를 지원하는 유용한 툴이지만, 사용법을 익히고 적용하는 데 러닝 커브가 존재합니다. 반면, Clean Architecture는 필수적으로 외부 툴을 요구하지 않기 때문에 이 점에서는 더 간결하게 프로젝트를 관리할 수 있습니다.
6. 실제 활용 상황에서의 차별성: Modular Architecture는 특히 대규모 앱이나 기능이 복합적으로 모여 있는 앱에 적합합니다. 각 모듈에 대한 독립적인 테스트가 가능하며, 다양한 팀이 개별 모듈을 관리할 수 있어 협업이 원활해집니다. 반면, 작은 규모의 앱에서는 클린 아키텍처의 단순한 레이어 분리가 더 효율적일 수 있습니다.

 

---

Modular Architecture?

Modular Architecture는 앱을 독립적인 모듈 단위로 분리해 각 모듈이 독립적으로 배포, 테스트, 유지보수될 수 있도록 하는 아키텍처입니다. 각 모듈은 특정 기능이나 책임을 담당하며, 다른 모듈과 최소한의 의존성만 가지도록 설계됩니다.

모듈 구조를 통해 각 모듈은 독립적으로 개발 및 변경이 가능해지며, 다른 모듈에 미치는 영향을 최소화하여 유지보수가 쉬워집니다. 또한 모듈 단위로 테스트가 가능해 전체 프로젝트에 영향 없이 특정 기능을 빠르게 수정하고 배포할 수 있습니다.

 

Modular Architecture의 장점

1. 독립적 배포와 테스트: 각 모듈이 분리되어 있어, 특정 기능에 대한 수정 사항이 발생해도 다른 모듈에 영향을 주지 않습니다. 각 모듈이 개별적으로 테스트와 배포가 가능하므로, 테스트 커버리지를 높이고 출시 프로세스를 간소화할 수 있습니다.
2. 확장성과 협업성: 모듈 단위의 구조로 인해, 여러 팀이 각자 담당 모듈을 독립적으로 관리할 수 있습니다. 대규모 프로젝트에서는 이 아키텍처가 팀 간 협업을 원활하게 하고, 프로젝트 확장성을 높여주는 역할을 합니다.
3. 유연한 기능 관리: 모듈화된 구조에서는 필요에 따라 새로운 기능을 추가하거나 불필요한 기능을 제거하기가 쉽습니다. 이로 인해 앱을 유연하게 확장할 수 있고, 프로젝트가 커질수록 모놀리식 아키텍처에서 발생할 수 있는 복잡성과 의존성 문제를 피할 수 있습니다.

 

Modular Architecture 활용

Modular Architecture를 통해 대규모 프로젝트나 복잡한 앱에서 코드의 독립성과 협업 효율성을 높일 수 있습니다. 예를 들어, 네트워크 모듈, 데이터베이스 모듈, UI 모듈을 독립적으로 관리해 기능 변경이 필요할 때 각 모듈만 수정할 수 있습니다. 또한, Swift Package Manager나 외부 툴(Tuist, XcodeGen)을 사용해 각 모듈의 의존성을 효과적으로 관리할 수 있습니다.

대규모 프로젝트나 확장 가능한 앱 개발에서 Modular Architecture는 특히 독립적 기능 관리와 협업의 유연성 측면에서 유리한 선택이 될 수 있습니다.

---

Clean Architecture?

Clean Architecture는 시스템을 레이어별로 분리해 관심사를 명확히 분리하고 유지보수성을 높이는 아키텍처입니다. 클린 아키텍처에 대한 설명은 아래 자세하게 되어있으니, 참고하세요. 😁

[Clean Architecture, SwiftUI] SwiftUI를 위한 클린 아키텍처

 

이 아키텍처의 핵심은 각 레이어가 다른 레이어에 의존하지 않고, 오직 상위 레이어에만 의존하도록 설계되는 것입니다. 이를 통해 비즈니스 로직이 외부 요인에 영향을 받지 않으며, 기능이 변화해도 최소한의 수정으로 대응할 수 있습니다.

 

Clean Architecture의 장점

1. 높은 유지보수성: 레이어가 분리되어 있어 각 레이어의 수정이 다른 레이어에 미치는 영향을 최소화합니다. 예를 들어, UI와 데이터 소스가 변경되어도 비즈니스 로직이 변경되지 않는 구조입니다.
2. 테스트 용이성: 핵심 로직이 독립된 상태로 유지되기 때문에, 테스트 작성이 용이합니다. 특정 기능이나 규칙을 테스트할 때 UI나 네트워크 의존성을 제거하고 순수 비즈니스 로직을 테스트할 수 있어, 단위 테스트가 쉬워집니다.
3. 관심사 분리: 각 레이어가 독립적인 역할을 갖고 있어, 비즈니스 로직과 UI 코드가 분리됩니다. 이러한 관심사 분리는 코드가 일관성을 유지하고, 새로운 요구사항을 쉽게 반영할 수 있게 합니다.

 

Clean Architecture 활용

앱의 UI와 비즈니스 로직을 명확히 분리하여, 앱 구조가 커져도 관리가 용이한 장점을 얻을 수 있습니다. 예를 들어, 앱의 네트워크 요청이나 데이터 저장소 로직을 Use Case와 Repositories 레이어로 분리하여 각각의 역할을 뚜렷하게 구분할 수 있습니다.

작은 규모의 프로젝트나 기능을 갖춘 앱에서는 Clean Architecture가 모듈화된 구조를 요구하지 않고도 관심사 분리와 테스트 용이성을 제공하여 간결하면서도 유연한 구조를 유지할 수 있습니다.

 

---

결론적으로

  제가 혼자했던 Modular Architecture를 적용했던 경험에 비추어 보면, 이 아키텍처는 앱이 매우 크거나, 여러 기능을 동시다발적으로 개발해야 하는 경우에 특히 적합하다고 느꼈습니다. 예를 들어, 다양한 미니게임을 한 앱에 모으는 경우처럼 각 기능이 독립적으로 관리되고 확장되어야 할 때, 또는 프로젝트 마지막에 모든 모듈을 합쳐 하나의 거대한 앱을 완성하는 느낌이라면, Modular Architecture를 도입하는 것이 확실히 유리합니다. 모듈별로 기능을 분리해 유지보수를 쉽게 하고, 필요 시 각 모듈을 독립적으로 배포할 수 있어 협업과 확장성 측면에서 강점이 큽니다. 단점으로는 모듈 관리를 위해 Tuist에서 한세월을 보내고 있는 자신을 볼 수 있습니다. 🤣

반대로, 앱 구조가 복잡하지 않고 각각의 UI 로직과 비즈니스 로직을 명확히 분리하기만 해도 충분할 경우에는 Clean Architecture가 더 적합하다고 생각합니다. Clean Architecture로 간단하게 각 역할을 구분하고 필요할 때만 세부 레이어를 추가하는 것이 더 실용적입니다. 협업을 위한 앱의 구조라고 이해를 하고 있습니다. 

(위에서 언급한 아키텍처들은 모두 '팀' 프로젝트에서 도입하시기를 추천합니다... 이전에 혼자 Clean Architecture를 적용해본 적이 있는데 하나의 기능을 만들때 최대 12개의 파일을 제어해야 했을때..매우 심란했던 경험이 있습니다...🙃)

결국, 프로젝트의 규모와 요구 사항에 따라 각 아키텍처의 장점을 최대한 활용할 수 있는 선택이 필요하다고 생각합니다. 확장성과 독립성이 중요한 경우에는 Modular Architecture를, 간결하고 명확한 관심사 분리가 중요한 경우에는 Clean Architecture를 적용하는 것이 최적의 선택이 될 것입니다.

 

---

 

[Xcode / Swift] 빌드 시스템에 대한 이해 / 증분 빌드 / 병렬 처리 / Eager Linking / Incremental