Android 앱 모듈화 가이드

여러 Gradle 모듈이 있는 프로젝트를 다중 모듈 프로젝트라고 합니다. 이 가이드에는 다중 모듈 Android 앱 개발을 위한 권장사항과 권장 패턴이 포함되어 있습니다.

증가하는 코드베이스 문제

코드베이스가 계속 증가하다 보면 시간이 지남에 따라 확장성, 가독성 및 전반적인 코드 품질이 떨어지는 경우가 많습니다. 그 원인은 코드베이스 규모가 커지고 있음에도 불구하고 유지관리 담당자가 쉽게 유지관리할 수 있는 구조를 적용하기 위한 적극적인 조치를 취하지 않기 때문입니다. 모듈화는 유지관리 가능성을 개선하고 이러한 문제를 방지할 수 있는 방식으로 코드베이스를 구조화하는 방법입니다.

모듈화란?

모듈화는 코드베이스를 느슨하게 결합된 독립적인 부분으로 구성하는 방법입니다. 각 부분이 모듈에 해당합니다. 각 모듈은 독립적이며 명확한 역할을 합니다. 하위 문제를 해결하기 위해 문제를 더 작고 쉬운 문제로 나누면 대형 시스템 설계와 유지보수의 복잡성이 줄어듭니다.

그림 1: 샘플 다중 모듈 코드베이스의 종속 항목 그래프

모듈화의 이점

모듈화의 이점은 많지만 모두 코드베이스의 유지관리 가능성과 전반적인 품질을 개선하는 데 중점을 둡니다. 아래 표에 주요 이점이 요약되어 있습니다.

이점 요약
재사용성 모듈화를 사용하면 코드를 공유하고 동일한 기반을 토대로 여러 앱을 빌드할 수 있습니다. 모듈은 사실상 구성요소의 역할을 합니다. 앱은 기능의 총합으로, 각 기능은 별도 모듈 형태로 구성됩니다. 특정 모듈이 제공하는 기능은 특정 앱에 사용되거나 사용되지 않을 수 있습니다. 예를 들어, :feature:news가 전체 버전과 Wear 앱에는 있고 데모 버전에는 없을 수 있습니다.
엄격한 공개 상태 제어 모듈을 사용하면 코드베이스의 다른 부분에 노출할 내용을 쉽게 제어할 수 있습니다. 공개 인터페이스를 제외한 모든 항목을 internal 또는 private으로 표시하여 모듈 외부에서 사용하지 못하도록 할 수 있습니다.
맞춤설정 가능한 전송 Play Feature Delivery는 App Bundle의 고급 기능을 사용하여 앱의 특정 기능을 조건부로 또는 주문형으로 전송할 수 있도록 합니다.

위의 이점은 모듈식 코드베이스에서만 얻을 수 있습니다. 다음 이점은 다른 기술을 사용해서도 얻을 수 있지만 모듈화를 사용하면 더욱 극대화할 수 있습니다.

이점 요약
확장성 긴밀히 결합된 코드베이스에서는 하나의 변경사항이 관련 없어 보이는 코드 부분까지도 연쇄적으로 바꾸어 놓을 수 있습니다. 적절히 모듈화된 프로젝트는 관심사 분리 원칙을 수용하므로 결합을 제한합니다. 이를 통해 참여자는 더 큰 자율성으로 더 많은 권한을 얻게 됩니다.
소유권 모듈은 자율성을 보장하는 것 외에 책임성을 부여하는 데도 사용할 수도 있습니다. 모듈에는 코드 유지관리, 버그 수정, 테스트 추가, 변경사항 검토 등을 담당하는 전용 소유자를 둘 수 있습니다.
캡슐화 캡슐화는 코드의 각 부분이 다른 부분에 관한 지식을 최소한으로만 갖고 있어야 함을 의미합니다. 분리된 코드가 읽고 이해하기가 더 쉽습니다.
테스트 가능성 테스트 가능성은 코드를 얼마나 쉽게 테스트할 수 있는지를 나타냅니다. 테스트 가능한 코드는 구성요소를 격리된 상태로 쉽게 테스트할 수 있는 코드입니다.
빌드 시간 증분 빌드, 빌드 캐시 또는 병렬 빌드와 같은 일부 Gradle 기능은 모듈성을 활용하여 빌드 성능을 개선할 수 있습니다.

일반적인 문제

코드베이스의 세분화는 코드베이스가 모듈로 구성된 정도를 나타냅니다. 코드베이스가 세분화되면 될수록 모듈이 더 작고 숫자가 늘어납니다. 모듈식 코드베이스를 설계할 때 세분화의 수준을 결정해야 합니다. 그렇게 하려면 코드베이스의 크기와 상대적 복잡성을 고려해야 합니다. 너무 세분화되면 오버헤드가 가중되고 너무 대략적이면 모듈화의 이점이 줄어듭니다.

일반적인 몇 가지 문제는 다음과 같습니다.

  • 너무 세분화됨: 빌드 복잡성과 상용구 코드가 늘어남으로써 모든 모듈에서 일정량의 오버헤드가 발생합니다. 복잡한 빌드 구성으로 인해 모듈 간에 일관된 구성을 유지하기가 어렵습니다. 상용구 코드가 너무 많아 관리하기 어렵고 번거로운 코드베이스가 됩니다. 오버헤드가 확장성 개선에 해가 되는 경우 일부 모듈을 통합하는 것이 좋습니다.
  • 너무 대략적임: 반대로 모듈이 너무 커지면 또 하나의 모놀리식이 될 수 있으며 모듈성이 제공하는 이점을 놓칠 수 있습니다. 예를 들어 작은 프로젝트에서는 데이터 영역을 단일 모듈 내에 넣어도 괜찮습니다. 그러나 크기가 커지면 저장소와 데이터 소스를 독립형 모듈로 분리해야 할 수 있습니다.
  • 너무 복잡함: 프로젝트를 모듈화하는 것이 항상 적합한 것은 아닙니다. 결정적 요소는 코드베이스의 크기입니다. 프로젝트가 특정 기준점 이상으로 확장될 것 같지 않으면 확장성 및 빌드 시간 면의 이점은 누릴 수 없습니다.

모듈화가 적합한 기법인가요?

재사용성, 엄격한 공개 상태 제어 등의 이점이 필요하거나 Play Feature Delivery를 사용하려면 모듈화가 필수입니다. 그러지는 않더라도 확장성과 소유권, 캡슐화 또는 빌드 시간 개선을 통한 이점을 얻으려면 모듈화를 고려하는 것이 좋습니다.

샘플