지금까지 예제는 파일 한두 개에 다 들어갔다. 하지만 앱에 화면과 기능이 늘어나면 lib 폴더가 점점 어지러워진다. 가장 먼저 떠오르는 정리법은 종류별로 폴더를 나누는 것이다. 모델은 모델끼리, 화면은 화면끼리, 서비스는 서비스끼리 모은다.

lib/
  models/
    user.dart
    todo.dart
  views/
    user_list_page.dart
    user_detail_page.dart
    todo_page.dart
  services/
    user_service.dart
    todo_service.dart
  providers/
    user_provider.dart
    todo_provider.dart
  main.dart

처음엔 깔끔해 보인다. 그런데 "사용자 상세 화면에 이메일을 추가하라"는 작업을 해보자. 고쳐야 할 파일은 이렇다.

• models/user.dart: 필드 추가
• services/user_service.dart: 응답 파싱 수정
• providers/user_provider.dart: 상태 수정
• views/user_detail_page.dart: 화면 수정

네 개의 폴더를 오가며 파일을 열어야 한다. 기능이 열 개로 늘면 views 폴더에 화면이 서른 개 쌓여서, 이 화면이 어느 기능의 것인지도 파일 이름으로만 짐작해야 한다. 반대로 "할 일 기능을 통째로 지우자"고 하면 네 폴더에 흩어진 파일을 일일이 골라내야 한다.

원인: 같이 바뀌는 파일이 멀리 떨어져 있다

폴더를 나누는 기준이 "종류"(모델, 화면, 서비스)였다. 그런데 코드를 고칠 때는 보통 한 기능에 속한 파일들이 같이 바뀐다. 같은 이유로 바뀌는 파일은 가까이 모아둬야 한다. 이게 폴더 구조를 고르는 가장 큰 기준이다.

두 가지 방식

• Layer-first(계층 우선): 위의 구조처럼 종류(계층)로 먼저 나눈다. models/, views/, services/ 아래에 모든 기능의 파일이 섞여 들어간다
• Feature-first(기능 우선): 기능으로 먼저 나누고, 그 기능 안에서 종류를 나눈다

같은 앱을 Feature-first로 바꾸면 이렇다.

lib/
  main.dart
  core/                        # 여러 기능이 같이 쓰는 것
    network/
      dio_client.dart
    router/
      app_router.dart
    theme/
      app_theme.dart
  features/
    user/
      data/
        user_api_service.dart
        user_repository.dart
      model/
        user.dart
      ui/
        user_list_page.dart
        user_detail_page.dart
        user_view_model.dart
    todo/
      data/
        todo_repository.dart
      model/
        todo.dart
      ui/
        todo_page.dart
        todo_view_model.dart

이제 "사용자 상세에 이메일 추가"는 features/user/ 안에서 끝난다. "할 일 기능 삭제"는 features/todo/ 폴더 하나를 지우면 된다. 새 기능을 만들 때는 features/ 아래에 폴더를 하나 더 만들고 같은 모양으로 채우면 된다.

import는 package 경로로 쓴다

폴더가 깊어지면 상대 경로가 지저분해진다.

import '../../../core/network/dio_client.dart'; // 몇 단계 위인지 세어야 함

Dart는 lib 안의 파일에는 패키지 경로를 쓰는 걸 권한다. 앱 이름이 my_app이라면 이렇게 쓴다.

import 'package:my_app/core/network/dio_client.dart';

파일을 다른 폴더로 옮겨도 import 줄은 그대로 읽힌다.

규칙 세 가지

Feature-first는 폴더만 나눈다고 끝나지 않고, 지켜야 할 규칙이 있다.

• 의존은 한 방향으로만 흐른다: features/*는 core/를 가져다 쓸 수 있지만, core/가 features/*를 가져다 쓰면 안 된다. core가 user 기능을 알게 되면 user를 고칠 때 core도 같이 깨진다
• 기능끼리는 내부 파일을 직접 건드리지 않는다: todo 기능이 user 기능의 user_view_model.dart를 import하기 시작하면 두 폴더가 한 덩어리가 되어 Feature-first의 의미가 사라진다. 꼭 필요하면 model/처럼 공유해도 되는 부분만 연다
• shared, common 폴더를 조심한다: "어디 둘지 모르겠는 파일"을 거기 던지다 보면 쓰레기통이 된다. 정말 둘 이상의 기능이 쓰고 있을 때만 core로 올린다

그럼 둘 중 뭘 써야 하나

• 작은 앱, 화면 서너 개, 혼자 개발: Layer-first로 충분하다. 폴더가 단순해서 처음 만들기 쉽다
• 기능이 늘어나고 화면이 열 개를 넘어가거나 여러 사람이 같이 작업: Feature-first가 낫다. 한 사람이 한 기능 폴더만 맡으면 충돌도 줄어든다

처음부터 Feature-first로 시작하는 것도 나쁘지 않다. 기능이 하나뿐이어도 features/home/ 하나만 만들어 두면, 나중에 기능이 늘어도 구조를 갈아엎을 일이 없다.

두 방식을 섞는 경우도 많다

Flutter 공식 앱 아키텍처 가이드는 앱을 UI 계층과 데이터 계층으로 나누라고 권한다. UI 안에는 화면(View)과 ViewModel이 있고, 데이터 쪽에는 Repository와 Service가 있다. 이 계층 개념을 기능 폴더 안에 넣은 것이 위의 features/user/{data,model,ui}이다. "기능으로 먼저 나누고, 그 안에서 계층으로 나눈다"가 현실에서 가장 흔한 절충안이다. 이 계층이 각각 무슨 일을 하는지는 다음 글에서 다룬다.

Android, iOS와 비교하면

• 종류별로 모으기: Flutter Layer-first / Android package-by-layer(ui, data 패키지) / iOS의 Models, Views 그룹
• 기능별로 모으기: Flutter Feature-first / Android package-by-feature와 기능별 모듈 / iOS 기능별 그룹이나 Swift Package
• 의존 방향 강제: Flutter는 규칙으로 지킴 / Android는 Gradle 모듈로 강제할 수 있음 / iOS는 모듈 분리로 강제할 수 있음

안드로이드에서도 ui, data로 먼저 나눌지 기능별로 나눌지는 같은 고민이다. 다만 Gradle 모듈은 "이 모듈은 저 모듈을 못 쓴다"를 빌드가 막아주는데, Flutter의 폴더는 규칙을 개발자가 스스로 지켜야 한다는 점이 다르다. 앱이 정말 커지면 기능을 별도 패키지로 나누기도 한다.

정리

• 종류별(Layer-first)로만 폴더를 나누면 기능 하나를 고칠 때 여러 폴더를 오가고, 기능을 지우기도 어렵다
• 같은 이유로 바뀌는 파일은 가까이 모으는 게 폴더 구조의 기준이고, 그래서 features/기능이름/ 아래에 데이터, 모델, UI를 모으는 Feature-first를 많이 쓴다
• 여러 기능이 같이 쓰는 건 core/에 두고, 의존은 features가 core를 가리키는 한 방향으로만 흐르게 한다
• 기능끼리 서로의 내부 파일을 import하지 않고, shared, common을 쓰레기통으로 만들지 않는다
• lib 안의 파일은 package:앱이름/... 경로로 import한다
• 작은 앱은 Layer-first로 충분하고, 화면과 사람이 늘면 Feature-first로 가며, 기능 안에서 UI/데이터 계층을 나누는 절충안이 가장 흔하다

다음 글에서는 이 폴더 안의 data와 ui가 각각 무슨 역할인지, Repository 패턴과 MVVM을 다뤄보겠다.