Flutter Web과 Desktop 대응 — 코드 한 번으로 모든 플랫폼? 현실은?

Flutter를 처음 접했을 때 가장 설렜던 한 마디.
"한 번의 코드로 iOS, Android, Web, Desktop까지!"
마치 마법 같았고, 실제로도 그렇게 돌아갔다.
하지만 실전에서 마주한 건 기대 이상의 현실의 벽이었다.

이 글에서는 Web과 Desktop 플랫폼 대응을 어떻게 접근해야 하는지,
Flutter의 가능성과 한계를 중심으로 이야기해본다.

---

🌍 Flutter Web — 모바일 감성 그대로 웹으로?

Flutter Web은 모바일에서 만든 UI를 그대로 웹에서도 보여줄 수 있다는 장점이 있다.
하지만 브라우저의 특성과 Flutter의 CanvasKit 구조 때문에 제한사항도 많다.

✅ 장점

• 모바일 앱 UI 그대로 가져올 수 있음
• 빠른 프로토타입 공유 및 데모 배포에 유용
• Firebase Hosting, GitHub Pages와도 잘 맞음

⚠️ 현실적 한계

• 초기 로딩 시간 & 용량 큼 (특히 CanvasKit 사용 시)
• 브라우저 호환성 이슈 (Safari에서 한글 렌더링 깨짐 등)
• SEO에 취약 (SPA 구조)

💡 대응 전략

• flutter build web --release 최적화 빌드 필수
• url_strategy 패키지로 '#/' 제거
• 가능한 텍스트보단 이미지 사용으로 렌더링 안정화

---

💻 Flutter Desktop — 데스크톱 앱도 Flutter로?

Windows, macOS, Linux까지 Flutter로 앱을 만들 수 있다는 건 큰 매력이다.
특히 내부 툴, 관리자 프로그램 등을 개발할 땐 빠르게 결과물을 만들 수 있다.

✅ 장점

• 모바일과 동일한 코드 베이스 유지
• 플랫폼 API (파일 시스템, 단축키 등) 접근 가능
• macOS 메뉴바, 윈도우 창 크기 조절 등 대응 가능

⚠️ 현실적 한계

• 디자인 감각: 모바일 UI 그대로는 데스크톱 UX에 어색함
• 플랫폼 별 플러그인 지원 아직 불균형 (특히 Linux)
• 스크롤 감도, 키보드 입력 대응이 민감함

💡 대응 전략

• UI 크기 자동 조절 → LayoutBuilder 활용
• kIsWeb, Platform.isWindows 등으로 조건 분기 처리
• 플러터 커뮤니티 기반의 Desktop Plugin 적극 활용

---

🔄 멀티플랫폼 대응의 핵심 전략

• 조건 분기: 플랫폼마다 코드 분기해 UX 최적화
• 공통 로직과 UI 분리: 예를 들어 서비스 레이어는 공통, UI는 플랫폼 별
• 플랫폼 디버깅 필수: 로컬에서는 되지만 Safari에서 깨지는 경우 많음

if (kIsWeb) {
  // 웹 전용
} else if (Platform.isWindows) {
  // 윈도우 전용
}

---

🧘 마무리하며

Flutter는 정말 멋진 프레임워크다.
하지만 "한 번의 코드로 모든 걸 해결한다"는 말에는 많은 단서가 붙는다.

우리는 그 단서 속에서 최적의 구조를 찾고, 최대한 공유 가능한 코드를 만드는 연습을 해야 한다.
Flutter는 가능성을 제공하고, 개발자는 균형을 설계한다.

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