이 시리즈를 1번 글부터 여기까지 왔다. @Composable 하나 찍어보는 걸로 시작해서, 지금은 Room에 저장하고 네트워크로 가져오고 애니메이션 붙고 폰/태블릿 다 대응하고 테스트까지 짜고 Play 스토어에 올릴 준비까지 된 할일 앱이 됐다.

마지막 글이니까 코드를 더 추가하진 않는다. 대신 이 앱의 구조가 왜 이렇게 바뀌어왔는지를 처음부터 끝까지 한 번 쭉 따라가본다. 그리고 전체 코드를 한 번에 모아둔다.

왜 처음부터 이 구조로 안 짰을까

사실 지금 구조를 안다면, 처음부터 ViewModel + Room + Hilt로 다 짤 수도 있었다. 근데 그렇게 했으면 "왜 이게 필요한지"를 몸으로 못 느꼈을 거다. 이 시리즈는 일부러 먼저 문제를 겪고, 그다음에 해결 도구를 배우는 순서로 짰다. 그 흐름을 다시 짚어보자.

1단계 → 2단계: 화면 하나에서 여러 화면으로

1번 글의 @Composable은 그냥 함수다. 함수인데 UI를 그린다는 게 낯설었을 거다. 2번 글의 remember { mutableStateOf(...) }로 "이 값이 바뀌면 다시 그려진다"는 리컴포지션의 기본을 배웠고, 3번 글의 rememberSaveable로 "화면 회전하면 왜 값이 날아가는지"를 겪었다.

5번 글에서 LazyColumn에 key를 안 쓰고 항목을 지웠을 때 체크 상태가 엉뚱한 항목에 붙는 버그를 직접 봤다. 이게 1번 글의 리컴포지션 원리와 바로 연결되는 지점이었다 — Compose는 "몇 번째 줄"이 아니라 "이게 그 항목인지"를 알아야 한다는 것.

6번 글의 Navigation에서 "화면 간에 객체를 통째로 넘기지 않고 id만 넘긴다"는 규칙을 배웠는데, 이 규칙이 나중에 Room에서 거꾸로 중요해진다(뒤에서 다시 나온다).

3단계: 상태를 한 화면 안에 두고 지내본 결과

7번 글(캡스톤 1)에서 일부러 상태를 화면 컴포저블 안에 뒀다. TodoApp 하나가 todoList, 네비게이션, 입력값까지 다 들고 있는 구조였다. 돌아가긴 했지만 두 가지가 불편했다.

• 화면 회전하면 (rememberSaveable을 안 쓴 값은) 날아간다
• 로직 테스트를 하려면 화면을 띄워야 한다

이 불편함을 겪고 나서야 8번 글 상태 호이스팅, 9번 글 ViewModel이 "왜 필요한지"가 납득이 된다. 순서를 바꿔서 ViewModel을 먼저 배웠다면 "그냥 이렇게 쓰라니까 쓰는" 암기가 됐을 거다.

4단계: 상태 관리와 구조

8번 글에서 TodoListScreen을 value + onValueChange(여기서는 todoList + onAdd/onToggleDone/onDelete) 패턴으로 stateless하게 만들었다. 이게 나중에 20번 글 UI 테스트에서 "ViewModel 없이 화면만 테스트"가 가능했던 이유다. 그때는 테스트를 염두에 두고 짠 게 아니라 "화면과 로직을 분리하면 재사용하기 좋다"는 이유였는데, 결국 테스트하기 좋은 구조와 같은 구조였다.

9번 글 ViewModel, 10번 글 StateFlow/UiState를 거쳐 11번 글에서 캡스톤 1을 리팩토링했다. data class TodoUiState(todoList, isLoading, errorMessage) 하나로 화면의 모든 상태를 표현하는 패턴이 여기서 자리잡았고, 이후 12~15번 글 내내 그대로 유지됐다.

5단계: 데이터 — 저장 방식이 늘어나도 UiState는 그대로

12번 글 Room을 붙이면서 Todo가 @Entity가 됐다. 여기서 6번 글의 "id만 넘긴다"는 규칙이 다시 나온다 — Room의 @Update/@Delete는 primary key로 행을 찾기 때문에, 이번엔 반대로 객체 전체(또는 최소한 id가 포함된 전체)를 넘겨야 제대로 수정/삭제가 된다는 걸 배웠다. 6번 글과 정반대 결론처럼 보이지만, 실제로는 "같은 질문(뭘 기준으로 그 항목을 찾는가)에 상황마다 다른 답"이라는 걸 보여주는 좋은 대조였다.

13번 글 DataStore로 다크 모드 설정을 저장하고, 14번 글 Retrofit으로 서버에서 할일을 가져오는 기능을 붙였다. 이때 UiState에 isLoading/errorMessage가 왜 미리 들어있었는지(10번 글에서 만들었을 때는 쓸 데가 없었다)가 드디어 쓰인다.

15번 글 Hilt로 TodoRepository(Room + Retrofit을 감싼)를 ViewModel에 주입했다. @HiltViewModel + hiltViewModel()로, 이제 ViewModel이 Repository를 직접 new하지 않는다. 이 구조가 20번 글에서 Repository를 인터페이스로 뽑아 Fake로 바꿔 끼울 수 있었던 전제조건이었다.

6단계: 심화 — 있는 구조를 건드리지 않고 다듬기

16번 글 LaunchedEffect/DisposableEffect, 17번 글 애니메이션, 18번 글 성능 최적화(derivedStateOf) 모두 지금까지의 구조(ViewModel + UiState + stateless 화면)를 바꾸지 않고 그 위에 얹었다. 구조를 한 번 제대로 잡아두면, 그 뒤로는 기능을 "추가"하는 작업이 "다시 설계"하는 작업이 안 된다는 걸 보여주는 구간이었다.

19번 글 WindowSizeClass로 PhoneLayout/TabletLayout을 나눌 때도 마찬가지였다. TodoListScreen, TodoDetailScreen이 stateless라서, 두 레이아웃이 그 화면들을 그냥 재사용만 하면 됐다.

7단계: 테스트와 배포 — 구조가 좋았는지 확인받는 순간

20번 글에서 테스트를 짜보면서, 지금까지의 설계가 "말로는 좋다"던 게 아니라 실제로 테스트하기 쉬운 구조였는지 확인받았다. stateless 화면 + 인터페이스로 분리된 Repository 덕분에 ViewModel 테스트와 UI 테스트가 둘 다 어렵지 않게 됐다.

21번 글에서 서명 키를 만들고 AAB를 빌드하는 법을 봤다. 이건 코드 구조와는 별개로, "만든 걸 남에게 전달하는 절차"를 알아야 한다는 실용적인 글이었다.

전체코드: todo_project 최종 구조

지금까지 흩어져 있던 코드를 한 데 모으면 대략 이런 모습이다. (라이브러리 버전, Hilt 모듈 등 세부는 각 글을 참고. 여기서는 구조의 흐름만 보기 위한 요약이다.)

// data/Todo.kt
@Entity
data class Todo(
    @PrimaryKey(autoGenerate = true) val id: Int = 0,
    val title: String,
    val isDone: Boolean = false
)

// data/TodoDao.kt
@Dao
interface TodoDao {
    @Query("SELECT * FROM Todo")
    fun getAll(): Flow<List<Todo>>

    @Insert suspend fun insert(todo: Todo)
    @Update suspend fun update(todo: Todo)
    @Delete suspend fun delete(todo: Todo)
}

// data/TodoDatabase.kt
@Database(entities = [Todo::class], version = 1)
abstract class TodoDatabase : RoomDatabase() {
    abstract fun todoDao(): TodoDao
}

// data/TodoRepository.kt — 인터페이스로 뽑아서 20번 글에서 Fake로 교체 가능하게 함
interface TodoRepository {
    val todoList: Flow<List<Todo>>
    suspend fun addTodo(title: String)
    suspend fun toggleDone(todo: Todo)
    suspend fun deleteTodo(todo: Todo)
    suspend fun importFromServer()
}

class TodoRepositoryImpl @Inject constructor(
    private val dao: TodoDao,
    private val apiService: TodoApiService
) : TodoRepository {
    override val todoList: Flow<List<Todo>> = dao.getAll()

    override suspend fun addTodo(title: String) = dao.insert(Todo(title = title))
    override suspend fun toggleDone(todo: Todo) = dao.update(todo.copy(isDone = !todo.isDone))
    override suspend fun deleteTodo(todo: Todo) = dao.delete(todo)

    override suspend fun importFromServer() {
        val remoteTodos = apiService.getTodos()
        remoteTodos.forEach { dao.insert(Todo(title = it.title)) }
    }
}

// ui/TodoUiState.kt
data class TodoUiState(
    val todoList: List<Todo> = emptyList(),
    val isLoading: Boolean = false,
    val errorMessage: String? = null
)

// ui/TodoViewModel.kt
@HiltViewModel
class TodoViewModel @Inject constructor(
    private val repository: TodoRepository
) : ViewModel() {

    val uiState: StateFlow<TodoUiState> = repository.todoList
        .map { TodoUiState(todoList = it) }
        .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5000), TodoUiState(isLoading = true))

    fun addTodo(title: String) = viewModelScope.launch { repository.addTodo(title) }
    fun toggleDone(todo: Todo) = viewModelScope.launch { repository.toggleDone(todo) }
    fun deleteTodo(todo: Todo) = viewModelScope.launch { repository.deleteTodo(todo) }
    fun importFromServer() = viewModelScope.launch { repository.importFromServer() }
}

// ui/TodoApp.kt — 폰/태블릿 분기 + 네비게이션
@Composable
fun TodoApp(viewModel: TodoViewModel = hiltViewModel(), windowSizeClass: WindowSizeClass) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()

    if (windowSizeClass.isWidthAtLeastBreakpoint(WindowSizeClass.WIDTH_DP_MEDIUM_LOWER_BOUND)) {
        TabletLayout(uiState, viewModel::addTodo, viewModel::toggleDone, viewModel::deleteTodo)
    } else {
        PhoneLayout(uiState, viewModel::addTodo, viewModel::toggleDone, viewModel::deleteTodo)
    }
}

// ui/TodoListScreen.kt — stateless, 테스트와 재사용이 쉬운 핵심 화면
@Composable
fun TodoListScreen(
    todoList: List<Todo>,
    onAdd: (String) -> Unit,
    onToggleDone: (Todo) -> Unit,
    onDelete: (Todo) -> Unit,
    onTodoClick: (Todo) -> Unit
) {
    // ... (5번, 8번 글에서 다룬 LazyColumn + key, 상태 호이스팅)
}

이 앱이 앞으로 더 커진다면

이 구조는 작은 할일 앱 하나에는 넉넉하다. 더 커진다면 보통 이런 방향으로 간다.

• 화면/기능이 많아지면 모듈을 쪼갠다 (:feature:list, :feature:detail 같은 멀티 모듈)
• 서버와 로컬 DB를 동기화하는 로직이 복잡해지면 Repository에 "오프라인 우선" 전략을 추가한다
• 테스트가 늘어나면 Fake를 매번 손으로 만들지 않고 테스트 전용 라이브러리(MockK 등)를 도입한다

지금 당장 할 일은 아니다. 지금 구조에서 자연스럽게 확장되는 방향이라는 것만 알아두면 된다.

정리

• 이 시리즈는 "문제를 먼저 겪고 도구를 나중에 배우는" 순서로 짰다. 1~7번에서 불편함을 겪었고, 8번부터 그 불편함을 하나씩 해결하는 도구들이 나왔다.
• TodoUiState 하나로 로딩/에러/데이터를 표현하는 패턴은 10번 글에서 만들어서 15번 글까지 그대로 썼다.
• stateless 화면 + 인터페이스 Repository라는 두 가지 선택이, 나중에(20번 글) 테스트를 쉽게 만들어준 핵심이었다.
• 구조를 한 번 제대로 잡으면 이후 기능 추가(애니메이션, 적응형 UI)는 구조를 안 건드리고 얹을 수 있다.
• 코드와 구조가 다 돼도 서명 키, AAB, Play Console 등록 같은 "전달하는 절차"가 따로 있다는 것도 21번 글에서 봤다.

여기까지가 22편짜리 Compose 시리즈 전체다. 다음은 또 다른 주제로 새 시리즈를 시작할 차례다.