Flutter 실전 프로젝트 구조 설계하기 — 기능 분리, 폴더링, 확장성 고려하기

Flutter 프로젝트를 처음 시작하면, 보통은 lib/main.dart 하나로 모든 걸 처리한다.
하지만 프로젝트가 커질수록 디렉토리는 복잡해지고, 유지보수는 악몽이 된다.

이번 글에서는 기능 기반 분리와 폴더 구조 설계 전략을 통해,
확장 가능한 Flutter 앱의 구조를 어떻게 잡아야 할지 정리해보려 한다.

---

🧱 기본 구조 vs 기능 기반 구조

📦 기본 구조 (초기 템플릿)

lib/
├── main.dart
├── screens/
├── widgets/

작은 앱에선 이 구조도 충분하다. 하지만 기능이 많아질수록 화면/위젯 분류만으로는 한계가 온다.

📦 기능 기반 구조

lib/
├── main.dart
├── core/          # 공통 유틸, 상수, 테마 등
├── services/      # API, Firebase, DB 등 외부 연동
├── features/
│   ├── auth/
│   │   ├── data/
│   │   ├── domain/
│   │   ├── presentation/
│   ├── home/
│   │   ├── ...

기능을 중심으로 폴더를 나누면 기능 단위 유지보수가 쉬워지고, 팀원 간 협업 시 충돌도 줄일 수 있다.

---

🧩 각 레이어의 역할

• data: API 통신, 모델 정의, DTO 변환
• domain: 비즈니스 로직, 상태 관리, useCase
• presentation: UI, 화면, 뷰모델

→ Clean Architecture에 영감을 받은 설계로, 규모가 커질수록 빛을 발한다.

---

🔌 서비스 레이어 분리 예시

공통 기능(API, Firebase 등)은 /services 폴더로 분리하는 것이 좋다.

lib/
└── services/
    ├── firebase_auth_service.dart
    ├── network_service.dart
    └── local_storage_service.dart

이렇게 하면 기능별로 구현을 바꾸더라도 UI나 기능 로직을 손대지 않아도 된다.

---

🧪 확장성과 테스트까지 고려하기

• 폴더마다 mock/ 폴더 두기 → 테스트가 쉬워짐
• interface → 구현체 분리 → DI 적용 가능
• Riverpod, Bloc 등 상태관리도 레이어 안에서 나눠서 사용

아키텍처는 겉멋이 아니다. “변화에 강한 구조”를 만들기 위한 개발자의 사려 깊음이다.

---

💡 마무리 폴더링 꿀팁

• 공통 UI 컴포넌트는 lib/components/로 분리
• Router 파일은 lib/routes/ 아래 관리
• assets 관련 상수는 lib/core/constants/로

정리된 구조는 협업도, 유지보수도, 리팩터링도 쉽게 만들어준다.

---

🧘 마무리하며

코드 한 줄보다 중요한 건, 그 코드가 어디에 위치해 있느냐다.
Flutter는 자유롭지만, 구조를 잘 잡아야 자유를 유지할 수 있다.

작을 때부터 구조를 고민하자. 그게 미래를 지킨다.

✍️ 이 글은 터미널 밖으로 나온 개발자의 Flutter 심화과정입니다.