[Android] 앱 아키텍처 가이드

오늘은 Android 개발을 위한 아키텍처 가이드라인을 소개해드리려고 해요. Android 앱을 개발할 때 좋은 구조를 가지는 것은 유지보수와 확장성 측면에서 매우 중요해요. 이 글에서는 Google이 추천하는 아키텍처 패턴과 그 구성 요소들을 쉽게 설명해볼게요~

---

1. Android 앱 아키텍처란?

앱 아키텍처는 앱의 구성요소들 간의 관계와 기능을 정의해요. 예를 들어, 데이터를 어디에 저장하고, 화면에 어떻게 보여줄지를 정리하는 거죠. 좋은 아키텍처는 앱이 커져도 유지보수가 쉽고, 견고하게 동작하도록 도와줘요. 크게 UI 레이어, 도메인 레이어와 데이터 레이어로 나누어 생각해볼 수 있어요.

1. 관심사 분리

가장 중요한 원칙 중 하나는 관심사 분리예요. `Activity`나 `Fragment` 같은 UI 클래스에는 화면에 표시할 내용과 UI 관련 로직만 있어야 해요. 만약 모든 로직을 여기에 담으면, 유지보수가 어렵고 테스트도 힘들어져요. 따라서, 데이터 처리나 비즈니스 로직은 따로 관리하는 것이 좋아요. 예를 들어, 네트워크 요청이나 데이터베이스 작업 같은 로직은 별도의 클래스나 레이어에서 처리하도록 분리해야 해요. 이렇게 하면 UI 클래스는 화면을 그리는 역할만 담당하게 되어, 코드가 훨씬 깔끔해지고 테스트하기도 쉬워져요.

2. 데이터 모델에서 UI 도출하기

UI는 데이터를 기반으로 구성돼야 해요. 즉, 데이터를 중심으로 UI를 그려나가는 방식이죠. 이 데이터는 앱의 나머지 부분과 독립적이어야 해요. 이렇게 하면 네트워크가 끊겨도 앱이 동작할 수 있고, 앱이 꺼졌다 켜져도 데이터를 유지할 수 있어요. ViewModel은 UI와 데이터를 연결하는 역할을 해요. `ViewModel`은 화면 회전 등으로 `Activity`가 다시 생성되어도 데이터를 유지할 수 있기 때문에, UI 관련 데이터를 보존하기에 적합해요.

3. 단일 소스 저장소(SSOT)

데이터를 관리할 때는 **단일 소스 저장소(SSOT)**를 사용해야 해요. SSOT는 특정 데이터의 소유자 역할을 하며, 데이터를 수정하고 관리하는 유일한 곳이에요. 이렇게 하면 데이터의 일관성을 유지하고, 변경사항을 쉽게 추적할 수 있어요. Repository 패턴이 이 역할을 잘 수행해요. Repository는 데이터 소스(예: 로컬 데이터베이스, 네트워크 등)와 UI 사이에서 데이터를 관리하고 제공해주는 클래스예요. 이 구조를 사용하면 데이터를 중앙에서 관리하므로 데이터의 흐름이 명확해지고 오류를 줄일 수 있어요.

4. 단방향 데이터 흐름(UDF)

데이터는 한 방향으로만 흐르는 게 좋아요. 데이터가 데이터 소스에서 UI로 흐르고, 사용자 이벤트는 다시 데이터 소스로 되돌아가는 식이에요. 이렇게 하면 오류를 줄이고, 데이터의 일관성을 유지할 수 있어요. 단방향 데이터 흐름을 통해 데이터 변경이 일관되게 처리되고, 디버깅이 쉬워져요. 예를 들어, 사용자가 버튼을 누르면 ViewModel에서 이벤트를 처리하고, 변경된 데이터가 다시 UI에 반영되는 구조를 생각해볼 수 있어요.

---

2. 앱의 기본 레이어 구조

앱은 보통 다음 세 가지 레이어로 나뉘어요:

• UI 레이어: 화면에 데이터를 표시하고, 사용자의 입력을 받는 부분이에요. 주로 `Activity`, `Fragment`, 또는 Jetpack Compose로 구성돼요. UI 요소들은 ViewModel에서 데이터를 가져와서 화면에 그려요.

  

  앱 아키텍처에서 UI 레이어의 역할

• 데이터 레이어: 앱의 비즈니스 로직과 데이터 관리를 담당하는 부분이에요. 데이터를 불러오고 저장하는 역할을 하죠. 보통 Repository 패턴을 사용해 데이터를 관리해요. 데이터 소스는 로컬 데이터베이스(Room)나 네트워크 API로 구성될 수 있어요.

  

  앱 아키텍처에서 데이터 레이어의 역할

• 도메인 레이어: 도메인 레이어는 UI 레이어와 데이터 레이어 사이에서 복잡한 비즈니스 로직을 처리하거나 여러 ViewModel에서 재사용되는 로직을 캡슐화하는 역할을 해요. 모든 앱에 꼭 필요한 건 아니지만, 복잡한 로직이 있을 경우 이 레이어를 두면 코드를 깔끔하게 유지할 수 있어요. 주로 UseCase 클래스를 사용해서 특정 비즈니스 로직을 처리해요.

  

  앱 아키텍처에서 도메인 레이어의 역할

필요에 따라 이 세 레이어를 활용하면 앱의 구조를 명확하게 하고, 각 부분의 역할을 잘 나눌 수 있어요.

---

3. 좋은 아키텍처의 이점

• 유지보수성: 코드가 깔끔하고 구조가 명확해서 유지보수가 쉬워요. 각 레이어의 역할이 분리되어 있기 때문에 특정 기능을 수정할 때 다른 부분에 미치는 영향을 최소화할 수 있어요.
• 테스트 용이성: 각 부분이 독립적이어서 테스트하기가 쉬워요. 예를 들어, 비즈니스 로직이 ViewModel이나 UseCase에 잘 분리되어 있으면 UI를 제외한 부분을 쉽게 단위 테스트할 수 있어요.
• 확장성: 팀이 커지더라도 충돌 없이 각자 작업할 수 있어요. 예를 들어, UI 개발자와 데이터 관련 개발자가 각각 독립적으로 작업할 수 있어요.
• 사용자 경험 개선: 안정적인 앱을 제공할 수 있어 사용자 만족도가 높아져요. 데이터의 일관성을 유지하고, 네트워크가 끊겨도 앱이 동작하도록 설계되기 때문에 사용자에게 끊김 없는 경험을 제공할 수 있어요.

---

참고자료

https://developer.android.com/topic/architecture?hl=ko

앱 아키텍처 가이드 | Android Developers