Flutter 튜토리얼 41편: UI 레이어와 Data 레이어 - MVVM 아키텍처 실전 적용

요약#

핵심 요지#

문제 정의: Flutter 앱이 복잡해질수록 UI 코드와 비즈니스 로직이 뒤섞여 유지보수가 어려워진다.
핵심 주장: UI 레이어와 Data 레이어를 명확히 분리하면 코드의 재사용성, 테스트 용이성, 유지보수성이 크게 향상된다.
주요 근거: Flutter 공식 문서의 MVVM 아키텍처 케이스 스터디에서 제시하는 계층 분리 패턴을 따른다.
한계: 소규모 앱에서는 오버엔지니어링이 될 수 있으며, 팀 내 일관된 패턴 적용이 필요하다.

문서가 설명하는 범위#

MVVM 아키텍처의 구조와 역할
UI 레이어: View와 ViewModel의 관계
Data 레이어: Repository와 Service의 역할
실전 코드 예제와 적용 방법

읽는 시간: 25분 | 난이도: 중급

참고 자료#

App architecture: Case study - Flutter 공식 아키텍처 케이스 스터디
UI layer - UI 레이어 상세 문서
Data layer - Data 레이어 상세 문서

문제 상황#

앱의 규모가 커지면서 Widget¹ 안에 데이터 로딩, 에러 처리, 상태 관리 코드가 모두 섞이게 됩니다. 이런 코드는 테스트하기 어렵고, 같은 로직을 여러 화면에서 반복 작성하게 됩니다.

기존 방식의 한계#

1
// 모든 것이 Widget 안에 섞인 코드
2
class BookingScreen extends StatefulWidget {
3
  @override
4
  State<BookingScreen> createState() => _BookingScreenState();
5
}
6

7
class _BookingScreenState extends State<BookingScreen> {
8
  List<Booking>? bookings;
9
  bool isLoading = true;
10
  String? error;
11

12
  @override
13
  void initState() {
14
    super.initState();
15
    _loadBookings();
16
  }
17

18
  Future<void> _loadBookings() async {
19
    try {
20
      // 직접 API 호출
21
      final response = await http.get(Uri.parse('$baseUrl/bookings'));
22
      final data = jsonDecode(response.body);
23
      setState(() {
24
        bookings = data.map((e) => Booking.fromJson(e)).toList();
25
        isLoading = false;
26
      });
27
    } catch (e) {
28
      setState(() {
29
        error = e.toString();
30
        isLoading = false;
31
      });
32
    }
33
  }
34

35
  @override
36
  Widget build(BuildContext context) {
37
    // UI 빌드 로직
38
  }
39
}

문제는 다음과 같습니다.

UI 로직과 데이터 로딩 로직이 혼재되어 있다
같은 데이터를 다른 화면에서 사용하려면 코드를 복사해야 한다
단위 테스트를 작성하기 어렵다
Widget을 수정할 때 데이터 로직까지 영향을 받을 수 있다

해결 방법#

챕터 1: MVVM 아키텍처 개요#

Why#

NOTE
대규모 앱 개발에서 코드의 관심사를 분리하면 각 부분을 독립적으로 개발하고 테스트할 수 있습니다. MVVM² 패턴은 이를 위한 검증된 아키텍처입니다.

What#

NOTE
MVVM은 Model-View-ViewModel의 약자로, 앱을 세 가지 계층으로 분리합니다.
graph TD subgraph UI["UI Layer"] V[View - Widget] VM[ViewModel] end subgraph Data["Data Layer"] R[Repository] S[Service] end V -->|"사용자 입력"| VM VM -->|"상태 변경"| V VM -->|"데이터 요청"| R R -->|"결과 반환"| VM R -->|"API 호출"| S S -->|"응답"| R

계층 역할 예시
View UI 렌더링, 사용자 입력 처리 StatelessWidget, StatefulWidget
ViewModel 비즈니스 로직, 상태 관리 ChangeNotifier 상속 클래스
Repository 데이터 소스 추상화, 캐싱 BookingRepository
Service 외부 API 통신 BookingApiService

계층	역할	예시
View	UI 렌더링, 사용자 입력 처리	`StatelessWidget`, `StatefulWidget`
ViewModel	비즈니스 로직, 상태 관리	`ChangeNotifier` 상속 클래스
Repository	데이터 소스 추상화, 캐싱	`BookingRepository`
Service	외부 API 통신	`BookingApiService`

How#

TIP

Flutter에서 MVVM을 구현하는 기본 구조입니다.

1
// 1. Model - 데이터 구조 정의
2
class Booking {
3
  final String id;
4
  final String destination;
5
  final DateTime date;
6

7
  Booking({
8
    required this.id,
9
    required this.destination,
10
    required this.date,
11
  });
12
}
13

14
// 2. Service - API 통신
15
class BookingApiService {
16
  Future<List<Booking>> getBookings() async {
17
    // HTTP 요청 로직
18
  }
19
}
20

21
// 3. Repository - 데이터 소스 관리
22
class BookingRepository {
23
  final BookingApiService _service;
24

25
  BookingRepository(this._service);
26

27
  Future<List<Booking>> getBookings() {
28
    return _service.getBookings();
29
  }
30
}
31

32
// 4. ViewModel - 비즈니스 로직
33
class BookingViewModel extends ChangeNotifier {
34
  final BookingRepository _repository;
35

36
  BookingViewModel(this._repository);
37

38
  // 상태와 로직
39
}
40

41
// 5. View - UI
42
class BookingScreen extends StatelessWidget {
43
  @override
44
  Widget build(BuildContext context) {
45
    // ViewModel을 사용한 UI 구성
46
  }
47
}

Watch out#

WARNING
모든 앱에 MVVM이 필요한 것은 아닙니다. 단순한 앱이나 프로토타입에서는 오히려 복잡성만 증가시킬 수 있습니다. 팀의 규모와 앱의 복잡도를 고려하여 적용 여부를 결정하세요.

결론: MVVM 아키텍처는 UI, 비즈니스 로직, 데이터 접근을 분리하여 유지보수성을 높인다.

챕터 2: UI 레이어 - View 구현#

Why#

NOTE
View는 사용자에게 정보를 표시하고 입력을 받는 역할만 담당합니다. View가 비즈니스 로직을 알지 못하면 UI 변경이 다른 코드에 영향을 주지 않습니다.

What#

NOTE
Flutter에서 View는 Widget으로 구현됩니다. View는 ViewModel³의 상태를 구독하고 화면에 표시합니다.
flowchart LR subgraph View W[Widget] LB[ListenableBuilder] end subgraph ViewModel VM[ChangeNotifier] S[State] end LB -->|"구독"| VM VM -->|"notifyListeners"| LB LB -->|"rebuild"| W

컴포넌트 역할 Flutter 구현
View UI 렌더링 StatelessWidget
State 구독 상태 변경 감지 ListenableBuilder
입력 처리 사용자 액션 전달 ViewModel 메서드 호출

컴포넌트	역할	Flutter 구현
View	UI 렌더링	`StatelessWidget`
State 구독	상태 변경 감지	`ListenableBuilder`
입력 처리	사용자 액션 전달	`ViewModel` 메서드 호출

How#

TIP

ListenableBuilder⁴를 사용하여 ViewModel의 상태를 구독하는 View를 만듭니다.

1
class BookingScreen extends StatelessWidget {
2
  final BookingViewModel viewModel;
3

4
  const BookingScreen({
5
    super.key,
6
    required this.viewModel,
7
  });
8

9
  @override
10
  Widget build(BuildContext context) {
11
    return Scaffold(
12
      appBar: AppBar(title: const Text('내 예약')),
13
      body: ListenableBuilder(
14
        listenable: viewModel,
15
        builder: (context, _) {
16
          // ViewModel의 상태에 따라 UI 분기
17
          if (viewModel.isLoading) {
18
            return const Center(
19
              child: CircularProgressIndicator(),
20
            );
21
          }
22

23
          if (viewModel.error != null) {
24
            return Center(
25
              child: Column(
26
                mainAxisAlignment: MainAxisAlignment.center,
27
                children: [
28
                  Text('오류: ${viewModel.error}'),
29
                  ElevatedButton(
30
                    onPressed: viewModel.loadBookings,
31
                    child: const Text('다시 시도'),
32
                  ),
33
                ],
34
              ),
35
            );
36
          }
37

38
          return ListView.builder(
39
            itemCount: viewModel.bookings.length,
40
            itemBuilder: (context, index) {
41
              final booking = viewModel.bookings[index];
42
              return ListTile(
43
                title: Text(booking.destination),
44
                subtitle: Text(booking.date.toString()),
45
                onTap: () => viewModel.selectBooking(booking),
46
              );
47
            },
48
          );
49
        },
50
      ),
51
    );
52
  }
53
}

Watch out#

WARNING

View에서 직접 데이터를 가공하거나 비즈니스 로직을 수행하지 마세요.

1
// 잘못된 예시: View에서 데이터 가공
2
builder: (context, _) {
3
  // View에서 필터링하면 안 됨
4
  final activeBookings = viewModel.bookings
5
      .where((b) => b.date.isAfter(DateTime.now()))
6
      .toList();
7
  return ListView.builder(
8
    itemCount: activeBookings.length,
9
    // ...
10
  );
11
}
12

13
// 올바른 예시: ViewModel에서 제공
14
builder: (context, _) {
15
  // ViewModel이 이미 필터링된 데이터를 제공
16
  return ListView.builder(
17
    itemCount: viewModel.activeBookings.length,
18
    // ...
19
  );
20
}

결론: View는 ViewModel의 상태를 화면에 표시하는 역할만 담당하며, 로직은 ViewModel에 위임한다.

챕터 3: UI 레이어 - ViewModel 구현#

Why#

NOTE
ViewModel은 View에 필요한 상태를 관리하고 비즈니스 로직을 처리합니다. View와 Data 레이어 사이의 중재자 역할을 하여 두 계층을 분리합니다.

What#

NOTE
Flutter에서 ViewModel은 ChangeNotifier⁵를 상속받아 구현합니다. 상태가 변경되면 notifyListeners()를 호출하여 View에 알립니다.
stateDiagram-v2 [*] --> Idle Idle --> Loading: loadBookings() Loading --> Success: 데이터 수신 Loading --> Error: 에러 발생 Success --> Loading: refresh() Error --> Loading: retry() Success --> Idle Error --> Idle

상태 설명 UI 표시
Idle 초기 상태 빈 화면
Loading 데이터 로딩 중 로딩 인디케이터
Success 데이터 로드 성공 목록 표시
Error 에러 발생 에러 메시지와 재시도 버튼

상태	설명	UI 표시
Idle	초기 상태	빈 화면
Loading	데이터 로딩 중	로딩 인디케이터
Success	데이터 로드 성공	목록 표시
Error	에러 발생	에러 메시지와 재시도 버튼

How#

TIP

ChangeNotifier를 상속받아 ViewModel을 구현합니다.

1
class BookingViewModel extends ChangeNotifier {
2
  final BookingRepository _repository;
3

4
  BookingViewModel(this._repository);
5

6
  // 상태 필드
7
  List<Booking> _bookings = [];
8
  bool _isLoading = false;
9
  String? _error;
10

11
  // Getter - View에서 접근
12
  List<Booking> get bookings => List.unmodifiable(_bookings);
13
  bool get isLoading => _isLoading;
14
  String? get error => _error;
15

16
  // 계산된 속성
17
  List<Booking> get activeBookings =>
18
      _bookings.where((b) => b.date.isAfter(DateTime.now())).toList();
19

20
  // 비즈니스 로직
21
  Future<void> loadBookings() async {
22
    _isLoading = true;
23
    _error = null;
24
    notifyListeners();
25

26
    try {
27
      _bookings = await _repository.getBookings();
28
    } catch (e) {
29
      _error = e.toString();
30
    } finally {
31
      _isLoading = false;
32
      notifyListeners();
33
    }
34
  }
35

36
  void selectBooking(Booking booking) {
37
    // 선택 로직
38
    notifyListeners();
39
  }
40

41
  Future<void> deleteBooking(String id) async {
42
    try {
43
      await _repository.deleteBooking(id);
44
      _bookings.removeWhere((b) => b.id == id);
45
      notifyListeners();
46
    } catch (e) {
47
      _error = '삭제 실패: $e';
48
      notifyListeners();
49
    }
50
  }
51
}

Watch out#

WARNING

ViewModel에서 BuildContext⁶를 사용하지 마세요. ViewModel은 UI에 독립적이어야 테스트가 가능합니다.

1
// 잘못된 예시: BuildContext 사용
2
class BookingViewModel extends ChangeNotifier {
3
  void showError(BuildContext context) {
4
    // ViewModel에서 context 사용 금지
5
    ScaffoldMessenger.of(context).showSnackBar(...);
6
  }
7
}
8

9
// 올바른 예시: 상태로 전달
10
class BookingViewModel extends ChangeNotifier {
11
  String? _snackBarMessage;
12
  String? get snackBarMessage => _snackBarMessage;
13

14
  void clearSnackBarMessage() {
15
    _snackBarMessage = null;
16
    notifyListeners();
17
  }
18
}

결론: ViewModel은 상태 관리와 비즈니스 로직을 담당하며, View와 Data 레이어를 연결한다.

챕터 4: Command 패턴으로 액션 처리#

Why#

NOTE
사용자 액션이 복잡해지면 로딩 상태, 에러 처리, 결과 처리가 반복됩니다. Command⁷ 패턴을 사용하면 이런 공통 처리를 재사용할 수 있습니다.

What#

NOTE
Command는 실행 가능한 액션을 캡슐화하는 객체입니다. 실행 상태(running, error, result)를 함께 관리합니다.
flowchart TD subgraph Command E[execute] R[running] ER[error] RS[result] end subgraph ViewModel VM[메서드] C[Command 인스턴스] end VM -->|"생성"| C C -->|"실행"| E E -->|"상태 업데이트"| R E -->|"성공"| RS E -->|"실패"| ER

속성 타입 설명
execute Future Function() 실행할 비동기 함수
running bool 실행 중 여부
error Exception? 발생한 에러
result T? 실행 결과
completed bool 완료 여부

속성	타입	설명
`execute`	`Future Function()`	실행할 비동기 함수
`running`	`bool`	실행 중 여부
`error`	`Exception?`	발생한 에러
`result`	`T?`	실행 결과
`completed`	`bool`	완료 여부

How#

TIP

Flutter 공식 문서에서 제안하는 Command 클래스 구현입니다.

1
class Command<T> extends ChangeNotifier {
2
  Command(this._action);
3

4
  final Future<T> Function() _action;
5

6
  bool _running = false;
7
  Exception? _error;
8
  T? _result;
9

10
  bool get running => _running;
11
  Exception? get error => _error;
12
  T? get result => _result;
13
  bool get completed => _result != null;
14

15
  Future<void> execute() async {
16
    if (_running) return;
17

18
    _running = true;
19
    _error = null;
20
    notifyListeners();
21

22
    try {
23
      _result = await _action();
24
    } on Exception catch (e) {
25
      _error = e;
26
    } finally {
27
      _running = false;
28
      notifyListeners();
29
    }
30
  }
31

32
  void clear() {
33
    _result = null;
34
    _error = null;
35
    notifyListeners();
36
  }
37
}

ViewModel에서 Command를 사용하는 예시입니다.

1
class BookingViewModel extends ChangeNotifier {
2
  final BookingRepository _repository;
3

4
  late final Command<List<Booking>> loadCommand;
5
  late final Command<void> deleteCommand;
6

7
  BookingViewModel(this._repository) {
8
    loadCommand = Command(() => _repository.getBookings());
9
    deleteCommand = Command(() => _deleteSelectedBooking());
10
  }
11

12
  List<Booking> get bookings => loadCommand.result ?? [];
13

14
  Future<void> _deleteSelectedBooking() async {
15
    if (_selectedId == null) return;
16
    await _repository.deleteBooking(_selectedId!);
17
  }
18
}

Watch out#

WARNING

Command의 result는 nullable입니다. View에서 사용할 때 null 체크를 해야 합니다.

1
// View에서 Command 사용
2
ListenableBuilder(
3
  listenable: viewModel.loadCommand,
4
  builder: (context, _) {
5
    final command = viewModel.loadCommand;
6

7
    if (command.running) {
8
      return const CircularProgressIndicator();
9
    }
10

11
    if (command.error != null) {
12
      return Text('Error: ${command.error}');
13
    }
14

15
    // result가 null일 수 있음
16
    final bookings = command.result ?? [];
17
    return ListView.builder(
18
      itemCount: bookings.length,
19
      // ...
20
    );
21
  },
22
)

결론: Command 패턴을 사용하면 비동기 액션의 상태 관리를 표준화할 수 있다.

챕터 5: Data 레이어 - Repository 구현#

Why#

NOTE
ViewModel이 데이터 소스를 직접 알면 데이터 소스 변경 시 ViewModel도 수정해야 합니다. Repository⁸가 데이터 소스를 추상화하면 ViewModel은 데이터가 어디서 오는지 알 필요가 없습니다.

What#

NOTE
Repository는 데이터의 단일 진실 공급원(Single Source of Truth)입니다. 여러 데이터 소스(API, 캐시, 로컬 DB)를 통합하여 일관된 인터페이스를 제공합니다.
flowchart TD VM[ViewModel] subgraph Repository R[BookingRepository] end subgraph Services API[ApiService] Cache[CacheService] DB[LocalDatabase] end VM -->|"getBookings()"| R R -->|"fetchFromApi()"| API R -->|"loadFromCache()"| Cache R -->|"queryLocal()"| DB

역할 설명
데이터 추상화 데이터 소스의 구현 세부사항 숨김
캐싱 전략 데이터 캐싱 및 유효성 관리
데이터 변환 DTO를 도메인 모델로 변환
에러 변환 서비스 에러를 도메인 에러로 변환

역할	설명
데이터 추상화	데이터 소스의 구현 세부사항 숨김
캐싱 전략	데이터 캐싱 및 유효성 관리
데이터 변환	DTO를 도메인 모델로 변환
에러 변환	서비스 에러를 도메인 에러로 변환

How#

TIP

Repository 클래스 구현 예시입니다.

1
class BookingRepository {
2
  final BookingApiService _apiService;
3
  final BookingCacheService _cacheService;
4

5
  BookingRepository({
6
    required BookingApiService apiService,
7
    required BookingCacheService cacheService,
8
  })  : _apiService = apiService,
9
        _cacheService = cacheService;
10

11
  // 캐시된 데이터
12
  List<Booking>? _cachedBookings;
13
  DateTime? _lastFetch;
14

15
  // 캐시 유효 시간
16
  static const _cacheValidDuration = Duration(minutes: 5);
17

18
  Future<List<Booking>> getBookings({bool forceRefresh = false}) async {
19
    // 캐시가 유효하면 캐시 반환
20
    if (!forceRefresh && _isCacheValid()) {
21
      return _cachedBookings!;
22
    }
23

24
    try {
25
      // API에서 데이터 가져오기
26
      final bookings = await _apiService.fetchBookings();
27

28
      // 캐시 업데이트
29
      _cachedBookings = bookings;
30
      _lastFetch = DateTime.now();
31

32
      // 로컬 캐시에도 저장
33
      await _cacheService.saveBookings(bookings);
34

35
      return bookings;
36
    } catch (e) {
37
      // 오프라인이면 로컬 캐시 시도
38
      final cached = await _cacheService.loadBookings();
39
      if (cached != null) {
40
        return cached;
41
      }
42
      rethrow;
43
    }
44
  }
45

46
  bool _isCacheValid() {
47
    if (_cachedBookings == null || _lastFetch == null) {
48
      return false;
49
    }
50
    return DateTime.now().difference(_lastFetch!) < _cacheValidDuration;
51
  }
52

53
  Future<void> deleteBooking(String id) async {
54
    await _apiService.deleteBooking(id);
55
    _cachedBookings?.removeWhere((b) => b.id == id);
56
    await _cacheService.removeBooking(id);
57
  }
58

59
  Future<Booking> createBooking(BookingRequest request) async {
60
    final booking = await _apiService.createBooking(request);
61
    _cachedBookings?.add(booking);
62
    return booking;
63
  }
64
}

Watch out#

WARNING

Repository에서 UI 관련 로직을 처리하지 마세요. Repository는 데이터만 다루고, 표시 형식은 ViewModel에서 결정합니다.

1
// 잘못된 예시: Repository에서 UI 형식 결정
2
class BookingRepository {
3
  Future<String> getFormattedDate(String id) async {
4
    final booking = await getBooking(id);
5
    // Repository에서 날짜 포맷팅하면 안 됨
6
    return DateFormat('yyyy-MM-dd').format(booking.date);
7
  }
8
}
9

10
// 올바른 예시: 원시 데이터 반환
11
class BookingRepository {
12
  Future<Booking> getBooking(String id) async {
13
    return await _apiService.fetchBooking(id);
14
  }
15
}

결론: Repository는 데이터 소스를 추상화하여 ViewModel이 데이터 출처에 의존하지 않게 한다.

챕터 6: Data 레이어 - Service 구현#

Why#

NOTE
Service⁹는 외부 시스템과의 통신을 담당합니다. HTTP 요청, 응답 파싱, 에러 처리를 캡슐화하여 Repository의 복잡성을 줄입니다.

What#

NOTE
Service는 상태를 갖지 않는(stateless) 클래스입니다. API 호출과 응답 변환만 담당합니다.
flowchart LR R[Repository] subgraph Service S[ApiService] P[Parser] end subgraph External API[REST API] end R -->|"fetchBookings()"| S S -->|"HTTP GET"| API API -->|"JSON"| S S -->|"parse"| P P -->|"List<Booking>"| R

책임 설명 예시
HTTP 통신 API 엔드포인트 호출 GET, POST, DELETE
인증 처리 토큰 추가, 갱신 Bearer 토큰
응답 파싱 JSON을 모델로 변환 Booking.fromJson()
에러 처리 HTTP 에러를 예외로 변환 ApiException

책임	설명	예시
HTTP 통신	API 엔드포인트 호출	GET, POST, DELETE
인증 처리	토큰 추가, 갱신	Bearer 토큰
응답 파싱	JSON을 모델로 변환	`Booking.fromJson()`
에러 처리	HTTP 에러를 예외로 변환	`ApiException`

How#

TIP

HTTP 클라이언트를 사용하는 Service 구현입니다.

1
class BookingApiService {
2
  final http.Client _client;
3
  final String _baseUrl;
4
  final AuthService _authService;
5

6
  BookingApiService({
7
    required http.Client client,
8
    required String baseUrl,
9
    required AuthService authService,
10
  })  : _client = client,
11
        _baseUrl = baseUrl,
12
        _authService = authService;
13

14
  Future<List<Booking>> fetchBookings() async {
15
    final response = await _authenticatedGet('/bookings');
16

17
    final List<dynamic> data = jsonDecode(response.body);
18
    return data.map((json) => Booking.fromJson(json)).toList();
19
  }
20

21
  Future<Booking> fetchBooking(String id) async {
22
    final response = await _authenticatedGet('/bookings/$id');
23
    return Booking.fromJson(jsonDecode(response.body));
24
  }
25

26
  Future<Booking> createBooking(BookingRequest request) async {
27
    final response = await _authenticatedPost(
28
      '/bookings',
29
      body: request.toJson(),
30
    );
31
    return Booking.fromJson(jsonDecode(response.body));
32
  }
33

34
  Future<void> deleteBooking(String id) async {
35
    await _authenticatedDelete('/bookings/$id');
36
  }
37

38
  // 공통 HTTP 메서드
39
  Future<http.Response> _authenticatedGet(String path) async {
40
    final token = await _authService.getToken();
41
    final response = await _client.get(
42
      Uri.parse('$_baseUrl$path'),
43
      headers: {'Authorization': 'Bearer $token'},
44
    );
45
    _checkResponse(response);
46
    return response;
47
  }
48

49
  Future<http.Response> _authenticatedPost(
50
    String path, {
51
    required Map<String, dynamic> body,
52
  }) async {
53
    final token = await _authService.getToken();
54
    final response = await _client.post(
55
      Uri.parse('$_baseUrl$path'),
56
      headers: {
57
        'Authorization': 'Bearer $token',
58
        'Content-Type': 'application/json',
59
      },
60
      body: jsonEncode(body),
61
    );
62
    _checkResponse(response);
63
    return response;
64
  }
65

66
  Future<http.Response> _authenticatedDelete(String path) async {
67
    final token = await _authService.getToken();
68
    final response = await _client.delete(
69
      Uri.parse('$_baseUrl$path'),
70
      headers: {'Authorization': 'Bearer $token'},
71
    );
72
    _checkResponse(response);
73
    return response;
74
  }
75

76
  void _checkResponse(http.Response response) {
77
    if (response.statusCode >= 400) {
78
      throw ApiException(
79
        statusCode: response.statusCode,
80
        message: response.body,
81
      );
82
    }
83
  }
84
}

Watch out#

WARNING

Service에서 데이터를 캐싱하지 마세요. 캐싱은 Repository의 책임입니다.

1
// 잘못된 예시: Service에서 캐싱
2
class BookingApiService {
3
  List<Booking>? _cache; // Service에서 캐시하면 안 됨
4

5
  Future<List<Booking>> fetchBookings() async {
6
    if (_cache != null) return _cache!;
7
    // ...
8
  }
9
}
10

11
// 올바른 예시: Service는 항상 API 호출
12
class BookingApiService {
13
  Future<List<Booking>> fetchBookings() async {
14
    // 항상 새로운 데이터 요청
15
    final response = await _authenticatedGet('/bookings');
16
    // ...
17
  }
18
}

결론: Service는 외부 API와의 통신만 담당하며, 캐싱이나 비즈니스 로직은 포함하지 않는다.

챕터 7: 의존성 주입과 테스트#

Why#

NOTE
각 계층이 인터페이스에 의존하면 테스트 시 Mock 객체로 대체할 수 있습니다. 의존성 주입¹⁰을 사용하면 유연한 구조를 만들 수 있습니다.

What#

NOTE
의존성 주입은 객체가 필요로 하는 의존성을 외부에서 제공하는 패턴입니다.
flowchart TD subgraph DI["의존성 주입 컨테이너"] S[Service] R[Repository] VM[ViewModel] end subgraph App V[View] end DI -->|"주입"| V S -->|"주입"| R R -->|"주입"| VM VM -->|"주입"| V

방식 설명 Flutter 패키지
생성자 주입 생성자 매개변수로 전달 기본
Provider Widget 트리를 통한 주입 provider
GetIt 서비스 로케이터 패턴 get_it
Riverpod 컴파일 타임 안전성 riverpod

방식	설명	Flutter 패키지
생성자 주입	생성자 매개변수로 전달	기본
Provider	Widget 트리를 통한 주입	`provider`
GetIt	서비스 로케이터 패턴	`get_it`
Riverpod	컴파일 타임 안전성	`riverpod`

How#

TIP

생성자 주입과 Provider를 사용한 의존성 주입 예시입니다.

1
// main.dart - 의존성 설정
2
void main() {
3
  // Service 생성
4
  final httpClient = http.Client();
5
  final authService = AuthService();
6
  final apiService = BookingApiService(
7
    client: httpClient,
8
    baseUrl: 'https://api.example.com',
9
    authService: authService,
10
  );
11
  final cacheService = BookingCacheService();
12

13
  // Repository 생성
14
  final repository = BookingRepository(
15
    apiService: apiService,
16
    cacheService: cacheService,
17
  );
18

19
  runApp(
20
    MultiProvider(
21
      providers: [
22
        // Repository를 Provider로 제공
23
        Provider<BookingRepository>.value(value: repository),
24
        // ViewModel은 ChangeNotifierProvider로
25
        ChangeNotifierProvider<BookingViewModel>(
26
          create: (context) => BookingViewModel(
27
            context.read<BookingRepository>(),
28
          ),
29
        ),
30
      ],
31
      child: const MyApp(),
32
    ),
33
  );
34
}
35

36
// View에서 ViewModel 사용
37
class BookingScreen extends StatelessWidget {
38
  @override
39
  Widget build(BuildContext context) {
40
    final viewModel = context.watch<BookingViewModel>();
41

42
    return Scaffold(
43
      body: viewModel.isLoading
44
          ? const CircularProgressIndicator()
45
          : ListView.builder(
46
              itemCount: viewModel.bookings.length,
47
              // ...
48
            ),
49
    );
50
  }
51
}

테스트 시 Mock 객체 사용 예시입니다.

1
// ViewModel 단위 테스트
2
void main() {
3
  group('BookingViewModel', () {
4
    late MockBookingRepository mockRepository;
5
    late BookingViewModel viewModel;
6

7
    setUp(() {
8
      mockRepository = MockBookingRepository();
9
      viewModel = BookingViewModel(mockRepository);
10
    });
11

12
    test('loadBookings updates state correctly', () async {
13
      // Arrange
14
      final testBookings = [
15
        Booking(id: '1', destination: 'Seoul', date: DateTime.now()),
16
      ];
17
      when(mockRepository.getBookings())
18
          .thenAnswer((_) async => testBookings);
19

20
      // Act
21
      await viewModel.loadBookings();
22

23
      // Assert
24
      expect(viewModel.bookings, equals(testBookings));
25
      expect(viewModel.isLoading, isFalse);
26
      expect(viewModel.error, isNull);
27
    });
28

29
    test('loadBookings handles error', () async {
30
      // Arrange
31
      when(mockRepository.getBookings())
32
          .thenThrow(Exception('Network error'));
33

34
      // Act
35
      await viewModel.loadBookings();
36

37
      // Assert
38
      expect(viewModel.bookings, isEmpty);
39
      expect(viewModel.error, isNotNull);
40
    });
41
  });
42
}

Watch out#

WARNING

순환 의존성을 피하세요. A가 B에 의존하고 B가 A에 의존하면 앱이 초기화되지 않습니다.

1
// 잘못된 예시: 순환 의존성
2
class UserRepository {
3
  final BookingRepository bookingRepo; // BookingRepository에 의존
4
  UserRepository(this.bookingRepo);
5
}
6

7
class BookingRepository {
8
  final UserRepository userRepo; // UserRepository에 의존 - 순환!
9
  BookingRepository(this.userRepo);
10
}
11

12
// 올바른 예시: 단방향 의존성
13
class UserRepository {
14
  final UserApiService apiService;
15
  UserRepository(this.apiService);
16
}
17

18
class BookingRepository {
19
  final BookingApiService apiService;
20
  BookingRepository(this.apiService);
21
}

결론: 의존성 주입을 통해 각 계층을 독립적으로 테스트하고 교체할 수 있다.

챕터 8: 전체 아키텍처 조합#

Why#

NOTE
개별 컴포넌트를 이해했다면 전체 앱에서 어떻게 조합되는지 파악해야 합니다. 실제 앱에서는 여러 기능이 함께 동작합니다.

What#

NOTE
전체 아키텍처는 다음과 같이 구성됩니다.
graph TB subgraph Presentation["UI Layer"] V1[BookingScreen] V2[ProfileScreen] VM1[BookingViewModel] VM2[ProfileViewModel] end subgraph Domain["Data Layer"] R1[BookingRepository] R2[UserRepository] end subgraph Infrastructure["Service Layer"] S1[BookingApiService] S2[UserApiService] Cache[CacheService] Auth[AuthService] end V1 --> VM1 V2 --> VM2 VM1 --> R1 VM2 --> R2 R1 --> S1 R1 --> Cache R2 --> S2 S1 --> Auth S2 --> Auth

How#

TIP

전체 앱 구조 예시입니다.

1
lib/
2
├── main.dart                 # 앱 진입점, DI 설정
3
├── app.dart                  # MaterialApp 설정
4
│
5
├── data/                     # Data Layer
6
│   ├── repositories/
7
│   │   ├── booking_repository.dart
8
│   │   └── user_repository.dart
9
│   ├── services/
10
│   │   ├── booking_api_service.dart
11
│   │   ├── user_api_service.dart
12
│   │   └── auth_service.dart
13
│   └── models/
14
│       ├── booking.dart
15
│       └── user.dart
16
│
17
├── ui/                       # UI Layer
18
│   ├── booking/
19
│   │   ├── booking_screen.dart
20
│   │   ├── booking_view_model.dart
21
│   │   └── widgets/
22
│   │       └── booking_card.dart
23
│   ├── profile/
24
│   │   ├── profile_screen.dart
25
│   │   └── profile_view_model.dart
26
│   └── shared/
27
│       └── widgets/
28
│           └── loading_indicator.dart
29
│
30
└── core/                     # 공통 유틸리티
31
    ├── command.dart
32
    └── exceptions.dart

main.dart에서 전체를 조합합니다.

1
void main() async {
2
  WidgetsFlutterBinding.ensureInitialized();
3

4
  // Infrastructure 계층
5
  final httpClient = http.Client();
6
  final authService = AuthService();
7
  final cacheService = CacheService();
8

9
  // Service 계층
10
  final bookingApiService = BookingApiService(
11
    client: httpClient,
12
    baseUrl: Environment.apiBaseUrl,
13
    authService: authService,
14
  );
15
  final userApiService = UserApiService(
16
    client: httpClient,
17
    baseUrl: Environment.apiBaseUrl,
18
    authService: authService,
19
  );
20

21
  // Repository 계층
22
  final bookingRepository = BookingRepository(
23
    apiService: bookingApiService,
24
    cacheService: cacheService,
25
  );
26
  final userRepository = UserRepository(
27
    apiService: userApiService,
28
  );
29

30
  // 앱 실행
31
  runApp(
32
    MultiProvider(
33
      providers: [
34
        Provider.value(value: authService),
35
        Provider.value(value: bookingRepository),
36
        Provider.value(value: userRepository),
37
      ],
38
      child: const MyApp(),
39
    ),
40
  );
41
}

Watch out#

WARNING

기능별로 폴더를 나눌지, 계층별로 폴더를 나눌지는 팀 규모에 따라 결정하세요.

1
// 소규모 앱: 계층별 구조
2
lib/
3
├── data/
4
├── ui/
5
└── core/
6

7
// 대규모 앱: 기능별 구조
8
lib/
9
├── features/
10
│   ├── booking/
11
│   │   ├── data/
12
│   │   └── ui/
13
│   └── profile/
14
│       ├── data/
15
│       └── ui/
16
└── core/

결론: 아키텍처 패턴을 일관되게 적용하면 팀원 모두가 코드를 쉽게 이해하고 수정할 수 있다.

한계#

학습 곡선: MVVM 패턴에 익숙하지 않은 개발자는 초기 학습이 필요하다
보일러플레이트: 간단한 기능에도 여러 클래스를 작성해야 한다
과도한 추상화: 소규모 앱에서는 불필요한 복잡성을 추가할 수 있다

Widget(위젯): Flutter에서 UI를 구성하는 기본 단위이다. ↩
MVVM(Model-View-ViewModel): UI와 비즈니스 로직을 분리하는 아키텍처 패턴이다. ↩
ViewModel(뷰모델): View에 필요한 데이터와 로직을 제공하는 클래스이다. ↩
ListenableBuilder(리스너블빌더): Listenable 객체의 변경을 감지하여 위젯을 재빌드하는 빌더이다. ↩
ChangeNotifier(체인지노티파이어): 리스너에게 변경을 알리는 기능을 제공하는 클래스이다. ↩
BuildContext(빌드컨텍스트): 위젯 트리에서 현재 위젯의 위치를 나타내는 참조이다. ↩
Command(커맨드): 실행 가능한 액션과 그 상태를 캡슐화하는 패턴이다. ↩
Repository(레포지토리): 데이터 소스를 추상화하여 단일 진실 공급원을 제공하는 클래스이다. ↩
Service(서비스): 외부 시스템과의 통신을 담당하는 stateless 클래스이다. ↩
Dependency Injection(의존성 주입): 객체가 필요로 하는 의존성을 외부에서 제공하는 디자인 패턴이다. ↩

Flutter 튜토리얼 41편: UI 레이어와 Data 레이어 - MVVM 아키텍처 실전 적용

요약#

핵심 요지#

문서가 설명하는 범위#

참고 자료#

문제 상황#

기존 방식의 한계#

해결 방법#

챕터 1: MVVM 아키텍처 개요#

Why#

What#

How#

Watch out#

챕터 2: UI 레이어 - View 구현#

Why#

What#

How#

Watch out#

챕터 3: UI 레이어 - ViewModel 구현#

Why#

What#

How#

Watch out#

챕터 4: Command 패턴으로 액션 처리#

Why#

What#

How#

Watch out#

챕터 5: Data 레이어 - Repository 구현#

Why#

What#

How#

Watch out#

챕터 6: Data 레이어 - Service 구현#

Why#

What#

How#

Watch out#

챕터 7: 의존성 주입과 테스트#

Why#

What#

How#

Watch out#

챕터 8: 전체 아키텍처 조합#

Why#

What#

How#

Watch out#

한계#

Footnotes#

공유

목차