Flutter SDK ZIP을 압축 해제하고 flutter 명령이 한 번 실행됐다고 설치가 끝난 것은 아닙니다. 공식 파일을 받았는지, 새 터미널에서 SDK가 잡히는지, 목표 플랫폼의 도구가 준비됐는지, 빈 프로젝트가 분석·테스트·빌드되는지를 따로 확인해야 합니다.
2026년 9월 30일 Windows 10 x64의 격리 폴더에서 당시 stable인 Flutter 3.47.5를 새로 받아 검증했습니다. 시스템 PATH는 바꾸지 않고 SDK 경로를 현재 프로세스에만 추가했습니다. 공식 릴리스 JSON의 SHA-256과 내려받은 1,933,437,428바이트 ZIP의 해시를 비교한 뒤 flutter doctor -v, 기기 조회, Android·Web 빈 프로젝트 생성, 정적 분석, 위젯 테스트, Web release 빌드를 차례로 실행했습니다.
이번 실행에서 성공한 것과 남은 차단점
| 확인 항목 | 관찰 결과 | 판정 |
|---|---|---|
| 공식 ZIP 무결성 | 공식·로컬 SHA-256 일치 | 통과 |
| SDK 버전 | Flutter 3.47.5 stable, Dart 3.13.4 | 통과 |
| Android SDK | SDK 36.1.0, platform 36, build-tools 36.1.0 감지 | 감지됨 |
| Android JDK | No Java Development Kit (JDK) found |
Android 실행 차단 |
| 연결 대상 | Windows·Chrome·Edge 3개, Android 기기 0개 | Android 미검증 |
| 빈 프로젝트 | Android·Web 프로젝트 파일 생성 | 통과 |
| 정적 분석 | No issues found! |
통과 |
| 위젯 테스트 | All tests passed! |
통과 |
| Web 빌드 | √ Built buildweb |
통과 |
14개 기대 조건은 모두 통과했습니다. 다만 이 숫자에 Android 앱 실행 성공은 포함하지 않았습니다. 프로젝트 안에 Android 폴더가 생성된 것과 APK가 실제로 빌드·설치되는 것은 다른 단계입니다. 이번 PC에서는 JDK가 Flutter에 연결되지 않았고 Android 기기도 없었으므로, 그 상태를 숨기지 않고 설치 완료선에서 제외했습니다.
공식 ZIP은 버전명보다 해시까지 확인한다
Flutter 공식 수동 설치 문서는 Windows에서 Git을 먼저 준비하고, 권한 상승이 필요 없으며 공백·특수문자가 없는 경로에 SDK를 풀도록 안내합니다. 이번에는 공식 Windows 릴리스 JSON에서 stable 해시와 archive 경로를 읽었고, 로컬 파일에 다음 명령을 실행했습니다.
Get-FileHash .flutter_windows_3.47.5-stable.zip -Algorithm SHA256
# 관찰값
0ccd71931f49c2fbe394b1eeb6d79af3d624058a043ea0d03d34160581624fb8이 값은 2026년 9월 30일에 확인한 3.47.5 archive의 값입니다. 독자가 설치하는 날의 stable 버전은 달라질 수 있으므로 위 문자열을 그대로 정답처럼 사용하면 안 됩니다. 먼저 Flutter 공식 수동 설치 문서에서 현재 bundle을 선택하고, 필요하면 공식 Windows 릴리스 JSON의 해당 archive 해시와 비교해야 합니다.
PATH 문제는 새 터미널과 실제 실행 파일 경로로 분리한다
SDK의 bin을 사용자 PATH에 넣은 뒤 이미 열려 있던 PowerShell에서 바로 시험하면 이전 환경 변수가 남아 있을 수 있습니다. 모든 터미널과 IDE를 닫고 새 PowerShell을 열어 다음 세 줄을 확인합니다.
Get-Command flutter
flutter --version
flutter doctor -vGet-Command flutter의 Source가 방금 설치한 SDK의 binflutter.bat인지 먼저 봅니다. 명령을 찾지 못하면 Android Studio나 JDK를 다시 설치할 단계가 아닙니다. PATH에 SDK 루트가 아니라 flutterbin이 들어갔는지, 폴더를 이동한 뒤 예전 경로가 남지 않았는지부터 고칩니다.
이번 검증은 사용자 PATH를 영구 변경하지 않고 자식 프로세스에만 flutterbin을 앞에 붙였습니다. 그 상태에서도 flutter --version --machine이 framework 3.47.5, channel stable, Dart 3.13.4를 반환했으므로 ZIP·압축 해제·실행 경로 단계는 서로 분리해 확인할 수 있었습니다.
doctor의 느낌표는 플랫폼별로 읽어야 한다
flutter doctor -v는 “Flutter가 설치됐는가” 한 가지만 답하지 않습니다. Flutter SDK, 운영체제, Android toolchain, 브라우저, Windows 개발 도구, 연결 기기, 네트워크를 각각 검사합니다. 그래서 모든 줄을 초록색으로 만들기 전에 무엇을 개발할지 정해야 합니다.
| 목표 | 반드시 정상이어야 하는 영역 | 현재 목표와 무관할 수 있는 영역 |
|---|---|---|
| Android 앱 | Flutter, Android toolchain, Android 기기 또는 emulator | Windows desktop용 Visual Studio |
| Web 앱 | Flutter, Chrome 또는 지원 브라우저 | Android toolchain |
| Windows 앱 | Flutter, Visual Studio의 C++ desktop workload, Windows SDK | Android SDK |
이번 PC는 Android SDK 36.1.0과 emulator를 찾았지만 JDK를 찾지 못했습니다. 즉 “Android SDK가 없다”가 아니라 “Java 실행 경로가 Flutter에 제공되지 않았다”가 실제 첫 차단점입니다. 이 차이를 보지 않고 SDK를 반복 설치하면 원인을 해결하지 못한 채 설치본만 늘어날 수 있습니다.
JDK 경고가 나오면 다음 네 값을 기록한다
where.exe java
$env:JAVA_HOME
flutter doctor -v
flutter config --listwhere.exe java와 JAVA_HOME이 비어 있는지, 서로 다른 JDK를 가리키는지, doctor가 실제로 어느 Android SDK를 읽었는지를 함께 기록합니다. Android Studio를 설치했더라도 Flutter 프로세스가 사용할 Java를 찾지 못할 수 있습니다. 현재 권장 JDK와 Android Studio·Gradle 호환 범위는 바뀔 수 있으므로 Flutter Android 설정 문서의 당일 절차를 우선합니다.
JDK가 연결된 뒤에야 다음 단계로 이동합니다.
flutter doctor --android-licenses
flutter doctor -v
flutter devices
flutter run -d <android-device-id>라이선스 동의는 내용을 확인한 뒤 진행해야 합니다. flutter devices에 Android 대상이 없는데 flutter run만 반복하는 것은 해결 순서가 아닙니다. 실기기라면 데이터 전송 가능한 USB 케이블, 개발자 옵션·USB 디버깅, Windows 제조사 드라이버를 확인하고, emulator라면 가상화와 Device Manager의 부팅 상태를 확인합니다.
빈 프로젝트로 SDK 문제와 프로젝트 문제를 갈라낸다
기존 프로젝트는 오래된 Gradle 설정, package 버전, 서명, 사내 proxy 같은 변수가 섞여 있습니다. 설치 확인에는 별도 빈 폴더를 사용해야 합니다. 이번에는 다음 명령으로 Android와 Web target만 생성했습니다.
flutter create --org dev.applicationdownload --project-name first_app --platforms android,web first_app
cd first_app
flutter analyze
flutter test
flutter build web프로젝트 생성 후 android/app/build.gradle.kts와 web/index.html이 존재했습니다. 정적 분석은 7.3초에 No issues found!, 기본 counter widget test는 All tests passed!, Web release 빌드는 30.2초에 buildweb을 만들었습니다.
이 결과는 Flutter SDK와 Dart 도구, package 해석, analyzer, test runner, Web compiler가 동작한다는 근거입니다. Android toolchain의 JDK 경고가 남았으므로 APK·AAB 성공 근거로 확대 해석하지 않았습니다. Android 앱을 목표로 한다면 JDK 설정 후 같은 빈 프로젝트를 실제 emulator나 기기에서 실행해야 설치 검증이 끝납니다.
증상별로 처음 확인할 한 곳
| 보이는 증상 | 처음 확인할 것 | 아직 하지 않을 것 |
|---|---|---|
flutter 명령을 찾지 못함 |
Get-Command flutter와 PATH |
Android SDK 재설치 |
| Android SDK는 보이지만 JDK 오류 | where java, JAVA_HOME, doctor 경로 |
Flutter ZIP 재다운로드 |
| licenses not accepted | flutter doctor --android-licenses |
Gradle 파일 임의 변경 |
| 기기가 목록에 없음 | flutter devices, USB·emulator 상태 |
앱 코드 수정 |
| 빈 프로젝트는 되지만 기존 앱만 실패 | 첫 Gradle·package·서명 오류 | SDK 전체 재설치 |
flutter analyze만 실패 |
첫 analyzer 진단과 해당 코드 | JDK 교체 |
이번 검증으로 말할 수 없는 것
- Android JDK가 연결되지 않아 APK·AAB 빌드와 emulator·실기기 실행을 수행하지 않았습니다.
- Android Studio 설치 화면이나 Flutter IDE plugin 설치 과정은 재현하지 않았습니다.
- 사내 proxy, 보안 프로그램, 백신 quarantine 환경은 시험하지 않았습니다.
- Windows desktop 실행은 doctor에서 도구 감지만 확인했고 별도 desktop build를 만들지 않았습니다.
- 버전·해시·도구 화면은 바뀔 수 있으며, 결과는 2026년 9월 30일 Flutter 3.47.5 stable과 기록한 PC에 한정됩니다.
다음 단계는 설치 반복이 아니라 목표별 첫 실행이다
설치 글의 종료점은 ZIP을 받은 순간이 아닙니다. Android를 목표로 한다면 doctor의 Android toolchain, 기기 목록, 빈 프로젝트의 실제 실행까지 확인해야 합니다. 그 뒤 학습 순서는 Flutter 앱 개발 시작 로드맵처럼 화면·상태·데이터·테스트로 확장할 수 있습니다. 프레임워크 자체를 아직 고르지 않았다면 Flutter·React Native·Kotlin·Swift 선택 기준에서 플랫폼 제약을 먼저 비교하는 편이 낫습니다.