[안드로이드] 안드로이드 앱 아키텍처

모바일 애플리케이션을 개발할 때 올바른 아키텍처를 적용하면 유지보수성과 확장성을 높이고, 팀원 간 협업을 원활하게 하며, 사용자 경험을 향상시킬 수 있다. 이 글에서는 안드로이드 앱 아키텍처의 핵심 원칙과 권장사항을 다룬다.

 

모바일 앱의 환경

안드로이드 앱은 Activity, Fragment, Service, Content Provider, Broadcast Receiver 등 여러 구성 요소로 이루어져 있으며, 운영체제가 이들을 관리한다.

하지만 모바일 환경은 리소스가 제한적이며, 운영체제가 필요에 따라 앱의 프로세스를 종료할 수도 있다. 따라서 앱을 설계할 때는 구성 요소가 개별적으로 실행될 수 있도록 하고, 서로 종속되지 않도록 해야 한다.

 

아키텍처의 이점

• 유지보수성 증가 – 코드의 구조가 명확하여 수정이 용이
• 확장성 확보 – 여러 개발자가 동시에 작업 가능
• 테스트 용이성 – 각 모듈을 독립적으로 테스트 가능
• 버그 분석 용이 – 데이터 흐름이 명확하여 디버깅이 쉬움
• 안정성과 성능 향상 – 사용자 경험이 개선됨
• 아키텍처를 처음 적용하는 데 시간이 필요하지만, 장기적으로 보면 개발 생산성을 높이고 앱의 품질을 개선하는 데 큰 도움이 된다.

 

앱 아키텍처의 핵심 원칙

1. 관심사 분리 (Separation of Concerns)

• 앱의 각 구성 요소는 자신의 역할에만 집중해야 한다.
• 예를 들어 Activity와 Fragment는 UI 관련 로직만 담당해야 하며, 비즈니스 로직과 데이터 처리는 별도의 클래스로 분리하는 것이 좋다.
• 나쁜 예시

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val items = fetchData()  // ❌ 네트워크 호출을 직접 수행
        displayData(items)
    }

    private fun fetchData(): List<String> {
        // API 요청 수행
    }

    private fun displayData(items: List<String>) {
        // 데이터를 UI에 표시
    }
}

👉 위 코드는 Activity가 데이터 요청과 UI 처리를 모두 담당하고 있어 유지보수하기 어렵다.

• 좋은 예시 

class MainActivity : AppCompatActivity() {
    private val viewModel: MainViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        viewModel.items.observe(this) { items ->
            displayData(items)
        }
    }

    private fun displayData(items: List<String>) {
        // 데이터를 UI에 표시
    }
}

👉 Activity는 UI만 담당하고, 데이터 처리는 ViewModel에서 수행하도록 개선되었다.

 

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

• UI는 데이터 모델을 기반으로 생성되어야 하며, 데이터 모델은 UI와 독립적으로 유지되어야 한다.
• 즉, 데이터가 변경되면 UI가 자동으로 갱신되는 구조를 만드는 것이 중요하다.
• LiveData, StateFlow 같은 반응형 데이터 사용 권장 ✅

class MainViewModel : ViewModel() {
    private val _items = MutableLiveData<List<String>>()
    val items: LiveData<List<String>> get() = _items

    fun fetchData() {
        // 네트워크 요청 후 데이터 갱신
        _items.value = listOf("Item1", "Item2", "Item3")
    }
}

👉 UI는 ViewModel의 LiveData를 관찰하여 자동으로 업데이트된다.

 

3. 단일 소스 저장소 (Single Source of Truth, SSOT)

• 하나의 데이터 유형에 대해서는 단 하나의 데이터 소스만 존재해야 한다.
• 예를 들어, 네트워크에서 데이터를 가져오거나 로컬 DB에서 데이터를 읽는 경우 모든 데이터 처리는 Repository에서 수행해야 한다.
• Repository 패턴 적용 ✅

class UserRepository(private val apiService: ApiService, private val userDao: UserDao) {
    suspend fun getUserData(): User {
        val user = apiService.getUser()
        userDao.insert(user) // 로컬 DB에 저장
        return user
    }
}

👉 UserRepository가 단일 데이터 소스 역할을 하며, 네트워크 또는 로컬 데이터를 일관되게 관리한다.

 

4. 단방향 데이터 흐름 (Unidirectional Data Flow, UDF)

• 데이터는 항상 한 방향으로 흐르도록 설계해야 한다.
• 즉, View → ViewModel → Repository → Data Source 순서대로 데이터가 흐른다.
• 데이터 변경 이벤트는 반대 방향으로 전달된다.
• UDF 적용 예시 ✅

사용자 액션 (버튼 클릭) → ViewModel에 이벤트 전달 → Repository에서 데이터 요청 → UI 업데이트

// ViewModel
fun onButtonClicked() {
    viewModelScope.launch {
        val userData = repository.getUserData()
        _user.postValue(userData)
    }
}

👉 데이터 흐름을 명확하게 분리하여 유지보수가 쉬워진다.

 

권장 앱 아키텍처

구글이 권장하는 앱 아키텍처는 UI 레이어, 데이터 레이어, 도메인 레이어로 구성된다.

1. UI 레이어 (Presentation Layer)

• View (Activity, Fragment, Compose)
• ViewModel (UI 상태 및 로직 관리)

2. 데이터 레이어 (Data Layer)

• Repository (데이터 소스 관리)
• Data Source (로컬 DB, 네트워크 API 등)

3. 도메인 레이어 (Domain Layer, 선택사항)

• UseCase (비즈니스 로직 처리 및 데이터 변환)

권장 아키텍처 다이어그램 ✅

[ UI Layer ]
   └ View (Activity, Fragment, Compose)
   └ ViewModel (LiveData, StateFlow)

[ Domain Layer ] (선택적)
   └ UseCase (비즈니스 로직)

[ Data Layer ]
   └ Repository (데이터 관리)
   └ Data Source (API, DB)

👉 레이어를 분리하면 코드가 명확해지고 유지보수가 쉬워진다.

 

결론

안드로이드 앱을 개발할 때는 관심사 분리, SSOT, 단방향 데이터 흐름 같은 원칙을 적용하여 유지보수성과 확장성을 높여야 한다.

 

✅ 핵심 요약

• UI와 데이터 처리를 분리하여 관리하기 쉽도록
• ViewModel과 LiveData를 활용하여 반응형 UI 구현
• Repository 패턴을 적용하여 단일 데이터 소스 유지
• UDF 패턴을 사용하여 데이터 흐름을 한 방향으로 유지

💡 처음에는 복잡해 보일 수 있지만, 장기적으로 보면 개발 효율성과 앱 품질이 크게 향상된다.