Profile Image of the Author
Moodturn
Welcome to MoodturnPost!

Dart 튜토리얼 23편: Web 앱 개발(Web·Deployment·Wasm)

2026-01-04
study
dart study

요약#

핵심 요지#

  • 문제 정의: 웹 앱은 “개발용 빌드”와 “배포용 빌드”가 다르고, JS/Wasm 타깃에 따라 제약이 달라서 기준 없이 진행하면 배포 단계에서 막힌다.
  • 핵심 주장: Dart 웹은 기본적으로 “개발(빠른 반복) ↔ 배포(최적화)” 컴파일 흐름이 있고, Wasm 컴파일은 stable이지만 여전히 제약과 임시 절차가 존재한다.
  • 주요 근거: 배포 빌드는 webdev build1, Wasm은 dart compile wasm2와 별도 정적 파일 복사/부트스트랩 구성 예시가 제시된다.
  • 실무 기준: JS 배포는 webdev build로, Wasm은 “지원 패키지 + package:web3 기반”을 전제로 실험적으로 접근한다.

문서가 설명하는 범위#

  • Dart 웹 플랫폼의 개요(개발용/배포용 JS 컴파일러)
  • 배포용 빌드(webdev build)와 배포 최적화(지연 로딩, 불필요 파일 제거 등)
  • Wasm 컴파일의 지원 범위/제약(브라우저, JS interop, webdev 미지원 등)과 임시 빌드 절차

읽는 시간: 12분 | 난이도: 초급

참고 자료#

문제 상황#

웹 앱은 “코드를 작성한다”에서 끝나지 않고, 브라우저가 이해할 수 있는 형태로 컴파일해 배포해야 합니다.
그런데 개발 단계(빠른 새로고침)와 배포 단계(작고 빠른 파일)는 목표가 다릅니다.
또한 Wasm은 안정 채널에서도 사용할 수 있지만, 아직 제약이 많아서 “그냥 켜면 된다” 수준이 아닙니다.
그래서 이 글은 웹 앱을 배포하는 기준과, Wasm 타깃을 언제/어떻게 고려해야 하는지 정리합니다.

해결 방법#

단계 1: Dart 웹은 “개발용 컴파일”과 “배포용 컴파일”이 다르다는 전제를 둔다#

Why#

NOTE

개발 단계에서는 빠르게 고치고 확인하는 반복이 중요합니다.
반면 배포 단계에서는 다운로드 크기와 실행 속도가 중요합니다.
웹에서는 이 두 목표가 충돌할 수 있으므로, 처음부터 모드를 분리해서 생각해야 합니다.

What#

NOTE

웹 플랫폼 페이지는 “개발(빠른 edit-refresh)용”과 “배포(코드 크기/속도)용” Dart→JavaScript 컴파일러가 있다는 개요를 제공합니다.

How#

TIP

학습/개발 단계에서는 “빠른 반복이 가능한 도구”를 사용하고, 배포 단계에서는 “배포용 빌드”로 넘어간다는 기준을 고정합니다.
이 기준이 잡히면, 배포용 빌드에서 나오는 결과물 위치/정리 작업도 자연스럽게 따라옵니다.

Watch out#

WARNING

웹 타깃을 바꿀 때(JS ↔ Wasm)는 단순 옵션 변경이 아니라 “지원되는 라이브러리/interop 방식”까지 영향을 받습니다.
즉, 처음부터 “타깃이 바뀔 수 있다”면 의존성 선택 기준을 더 엄격하게 가져가야 합니다.

결론: 웹 개발은 “개발용 ↔ 배포용” 모드를 분리해서 잡아야 배포 단계에서 흔들리지 않습니다.

단계 2: JS 배포는 webdev build로 결과물을 고정한다#

Why#

NOTE

배포는 “서빙할 정적 파일 묶음”이 확정되어야 합니다.
그래야 CDN/정적 호스팅에 올리는 작업이 단순해집니다.

What#

NOTE

배포 빌드에서는 webdev 도구로 앱을 빌드하고, 결과물이 build/web/main.dart.js에 생성된다고 설명합니다.
또한 트리 셰이킹(tree shaking)로 코드가 줄어든다는 설명이 함께 제시됩니다.

How#

TIP

배포용 빌드는 webdev build로 수행합니다.
또한 빌드 후 개발용 산출물(예: .js.map)을 제거하는 예시가 제시됩니다.

Terminal window
# 앱 루트에서:
$ find build -type f -name \"*.js.map\" -exec rm {} +

Watch out#

WARNING

배포 최적화는 빌드 도구만으로 끝나지 않을 수 있습니다.
예를 들어 “지연 로딩(deferred loading)” 같은 언어 기능을 적용하면 초기 다운로드 크기를 줄일 수 있다는 안내가 있습니다.
즉, 성능 목표가 있다면 코드 구조까지 함께 고려해야 합니다.

결론: JS 배포는 webdev build로 결과물 경로를 고정하고, 배포에 불필요한 파일은 제거합니다.

단계 3: Wasm은 “stable이지만 제약이 있다”를 먼저 받아들인다#

Why#

NOTE

Wasm은 브라우저에서 빠른 실행과 새로운 방향성을 제공하지만, 웹 생태계 전체가 완전히 동일한 상태는 아닙니다.
따라서 “지원 범위”를 모르고 시작하면 중간에 막힐 가능성이 큽니다.

What#

NOTE

Wasm 타깃은 다음 제약을 안내합니다.
WasmGC 기반 타깃이므로 브라우저 지원이 제한될 수 있고, 표준 Wasm 런타임(wasmtime/wasmer) 실행을 지원하지 않으며, JS interop는 next-gen 방식만 지원합니다.
또한 webdev는 Wasm을 위한 serve/build를 현재 지원하지 않는다고 안내합니다.

How#

TIP

Wasm 컴파일러는 dart CLI에 포함되어 있으며, 도움말 예시가 제시됩니다.

Terminal window
$ dart help compile wasm
Compile Dart to a WebAssembly/WasmGC module.


Usage: dart compile wasm [arguments] <dart entry point>
-h, --help                  Print this usage information.
-o, --output                Write the output to <file name>.
                            This can be an absolute or relative path.
-v, --verbose               Print debug output during compilation
    --enable-asserts        Enable assert statements.
-D, --define=<key=value>    Define an environment declaration.

Watch out#

WARNING

Wasm 빌드는 임시 절차가 제시됩니다.
예를 들어 dart create -t web으로 시작하고, package:web 기반이어야 하며, webdev 없이 산출물을 구성해 서빙하는 방식이 안내됩니다.
즉, Wasm은 “실험/검증” 관점에서 접근하는 편이 안전합니다.

결론: Wasm은 stable이지만 제약이 크므로, 지원 범위를 먼저 확인하고 실험적으로 적용합니다.

Footnotes#

  1. webdev build(webdev build): Dart 웹 앱을 배포 가능한 JavaScript 산출물로 빌드하는 명령이다. ↩

  2. dart compile wasm(dart compile wasm): Dart 코드를 WasmGC 기반 WebAssembly 모듈로 컴파일하는 명령이다. ↩

  3. package(package): 브라우저 API 접근을 제공하며, Wasm 타깃을 포함한 웹 interop의 기준이 되는 패키지다. ↩

공유

이 글이 도움이 되었다면 다른 사람과 공유해주세요!

Dart 튜토리얼 23편: Web 앱 개발(Web·Deployment·Wasm)
https://moodturnpost.net/posts/dart/dart-web-apps-deploy-wasm/
작성자
Moodturn
게시일
2026-01-04
Moodturn
Dart 튜토리얼 24편: 멀티플랫폼 & 환경 설정(Flutter·-D·fromEnvironment)
Dart 튜토리얼 22편: CLI 앱과 HTTP 서버(args·dart:io·서버 패키지)
© 2026 Moodturn. All Rights Reserved.
Powered by Astro

목차