바이브 코딩 실전 6화: 이제 진짜 프로젝트를 만들어보자

드디어 여기까지 왔습니다.

#01부터 시작해서

MVP와 제품의 차이를 알아보고,

화면, 서버, DB, API, Git을 익히고,

AI 코딩 에이전트도 골라보고,

기능도 잔뜩 버리고,

PRD까지 만들었습니다.

그런데 아직 앱 화면은 하나도 나오지 않았습니다.

슬슬 이런 생각이 들 만합니다.

오늘입니다. 😎

이번 편부터 실제로 MyLog 프로젝트를 만들어봅니다.

하지만 오늘도 욕심은 조금 내려놓겠습니다.

기록 기능도 만들지 않습니다.

데이터 저장도 아직 하지 않습니다.

오늘의 목표는 딱 하나입니다.

앱이 켜지면 성공입니다.

별것 아닌 것처럼 보이지만 앞으로 우리가 만드는 모든 기능은 바로 이 상태 위에 올라갑니다.

1. 그런데 왜 Flutter를 선택했을까?

본격적으로 설치하기 전에 한 가지는 짚고 넘어가겠습니다.

이번 연재에서는 앱 개발 프레임워크로 Flutter를 사용합니다.

Flutter는 하나의 코드베이스로 모바일, 웹, 데스크톱 등 여러 플랫폼을 대상으로 앱을 개발할 수 있는 프레임워크입니다. 공식 Flutter 문서 역시 단일 코드베이스를 활용한 멀티플랫폼 개발을 주요 특징으로 안내하고 있습니다.

우리 연재의 최종 목표가

iOS

Android

macOS

까지 실제 배포해보는 것이기 때문에 꽤 잘 맞습니다.

하지만 중요한 점이 있습니다.

Flutter가 바이브 코딩의 정답이라는 뜻은 아닙니다.

React Native를 사용할 수도 있고,

Swift로 iOS 앱을 만들 수도 있고,

Kotlin으로 Android 앱을 만들 수도 있습니다.

웹 서비스라면 React나 Next.js가 더 자연스러울 수도 있습니다.

우리는 첫 연재에서 너무 많은 기술을 섞지 않기 위해 하나를 선택한 것입니다.

그리고 그 도구가 Flutter입니다.

2. 개발환경이라고 하니 갑자기 어려워 보인다

개발환경이라는 단어를 처음 들으면 거창합니다.

뭔가 검은 화면에 초록 글씨가 흘러야 할 것 같습니다.

하지만 지금 필요한 것을 정리하면 생각보다 단순합니다.

우리에게 필요한 것

1. 코드를 작성하고 볼 편집기
2. Flutter SDK
3. Android 개발환경
4. iOS 개발환경
5. 앱을 실행할 스마트폰 또는 가상 스마트폰
6. Git

여기서 오늘 가장 중요한 것은 Flutter SDK입니다.

SDK는 Software Development Kit의 약자입니다.

이름은 어렵지만 지금은

정도로 이해하면 충분합니다.

3. 코드 편집기는 취향대로 골라도 된다

먼저 코드 편집기가 필요합니다.

앞에서 살펴본 AI 코딩 에이전트를 사용할 수 있는 편집기를 선택하면 됩니다.

예를 들어

Cursor 같은 AI 중심 IDE를 사용할 수도 있고,

VS Code와 AI 코딩 도구를 조합할 수도 있습니다.

터미널 중심의 Claude Code나 Codex 계열 도구를 함께 사용할 수도 있습니다.

중요한 것은 특정 편집기가 아닙니다.

우리에게 필요한 것은

프로젝트 파일 확인
코드 변경 내용 확인
AI와 대화
터미널 실행
Git 변경사항 확인

을 무리 없이 할 수 있는 환경입니다.

이번 연재에서는 특정 에디터 버튼 위치에 지나치게 의존하지 않고 터미널 명령을 기준으로 설명하겠습니다.

도구를 바꿔도 그대로 따라갈 수 있기 때문입니다.

4. Flutter를 설치한다

현재 Flutter 공식 문서는 처음 설치하는 사용자에게 VS Code 또는 Code OSS 계열 편집기를 이용한 Quick Start 방식과 직접 SDK를 설치하는 Custom Setup 방식을 제공하고 있습니다.

어느 방법을 사용해도 괜찮습니다.

중요한 것은 설치가 끝난 뒤 터미널에서

flutter --version

을 입력했을 때 Flutter 정보가 정상적으로 나오는 것입니다.

Flutter CLI는 프로젝트 생성, 분석, 테스트, 실행 같은 작업에 사용하는 기본 명령줄 도구입니다.

만약

flutter: command not found

같은 메시지가 나온다면 Flutter가 설치되지 않았거나 PATH 설정이 제대로 되지 않은 경우를 먼저 확인해야 합니다.

처음 만나는 검은 화면의 빨간 글씨라고 겁먹지 마세요.

개발하다 보면 빨간 글씨도 자주 보다 보니 나중에는 색상 테마의 일부처럼 느껴집니다. 🔴

5. PATH는 또 뭔가요?

Flutter를 설치하다 보면 높은 확률로 PATH라는 단어를 만나게 됩니다.

쉽게 말하면 컴퓨터에게

라고 알려주는 설정입니다.

Flutter 공식 문서에서도 터미널에서 flutter 명령을 사용하려면 SDK의 bin 디렉터리가 시스템 PATH에 포함되어 있어야 한다고 안내합니다.

PATH의 내부 동작을 지금 공부할 필요는 없습니다.

우리가 확인할 것은 이것 하나입니다.

flutter --version

정상 출력?

그럼 다음으로 갑니다.

6. Flutter Doctor를 만나보자

Flutter 설치가 끝났다면 바이브 코딩 생활에서 꽤 자주 만나게 될 명령어가 하나 있습니다.

flutter doctor

이름이 정말 Doctor입니다.

개발환경이 아픈 곳은 없는지 진찰해줍니다. 🩺

Android 공식 설정 가이드에서도 개발 도구 체인의 문제를 확인할 때 flutter doctor를 실행하도록 안내하고 있습니다.

실행하면 대략 이런 항목들을 볼 수 있습니다.

Flutter
Android toolchain
Xcode
Android Studio
Connected device
Network resources

환경에 따라 결과는 달라집니다.

그리고 각 항목 앞에 표시가 붙습니다.

[✓]

정상

[!]

확인할 내용이 있음

[✗]

설정이 필요함

처음 실행했는데 전부 초록색 체크가 아니라고 당황할 필요 없습니다.

오히려 처음부터 모든 것이 완벽하면 컴퓨터가 우리보다 개발 준비를 더 오래 했던 겁니다.

7. 모든 오류를 한 번에 고칠 필요는 없다

이 부분이 중요합니다.

flutter doctor를 실행하면 여러 경고가 나올 수 있습니다.

비개발자는 여기에서 첫 번째 멘붕을 만나기 쉽습니다.

Xcode가 어떻고,

Android SDK가 어떻고,

라이선스가 어떻고...

그러면 모든 빨간 글씨를 한 번에 없애려고 합니다.

그럴 필요 없습니다.

우선 우리가 첫 실행에 사용할 플랫폼부터 해결하면 됩니다.

Android부터 실행한다면

Flutter + Android toolchain + Android device

를 먼저 봅니다.

iOS부터 실행한다면

Flutter + Xcode + iOS Simulator

를 먼저 봅니다.

하나씩 처리합니다.

AI 코딩에서도 마찬가지입니다.

오류 열 개를 한 번에 고치게 하지 마세요.

하나씩 없애는 편이 훨씬 안전합니다.

8. Android 개발환경 준비하기

Android 앱을 실행하려면 Android 개발 도구가 필요합니다.

Flutter 공식 가이드에서는 Android Studio를 이용해 Android SDK와 관련 도구를 설정하고, 실제 Android 기기나 Android Emulator에서 Flutter 앱을 실행할 수 있도록 안내합니다.

Android Studio를 설치한 뒤 SDK Manager에서 필요한 Android SDK와 도구가 설치되어 있는지 확인합니다.

그리고 처음 설정할 때 자주 빠지는 것이 있습니다.

Android SDK 라이선스입니다.

터미널에서 다음 명령을 실행합니다.

flutter doctor --android-licenses

필요한 라이선스 내용을 확인하고 동의 절차를 진행합니다. Flutter 공식 Android 설정 문서에서도 이 명령으로 SDK 라이선스를 검토하고 승인하도록 안내하고 있습니다.

끝나면 다시 진찰합니다.

flutter doctor

개발하다 보면 flutter doctor를 자주 실행하게 됩니다.

컴퓨터가 아플 때마다 왕진 오는 셈입니다.

9. 실제 Android 폰과 가상폰, 무엇을 사용할까?

두 가지 모두 가능합니다.

첫 번째는 가지고 있는 Android 스마트폰을 USB로 연결하는 방법입니다.

두 번째는 컴퓨터에서 Android Emulator를 실행하는 방법입니다.

Flutter 공식 문서에서는 Android Studio의 Device Manager에서 가상 디바이스를 만들고 Android Emulator로 앱을 테스트할 수 있도록 안내합니다. 실제 Android 기기를 사용하는 경우 개발자 옵션과 USB 디버깅 등을 설정할 수 있습니다.

처음에는 에뮬레이터가 편합니다.

하지만 나중에는 반드시 실제 스마트폰에서도 확인해볼 겁니다.

컴퓨터에서는 멀쩡한데 실제 스마트폰에 넣는 순간

키보드가 화면을 덮고,

글자가 잘리고,

스크롤이 이상하고,

권한 요청이 안 뜨는

그런 현실 세계가 기다리고 있습니다. 📱

10. Flutter가 스마트폰을 보고 있는지 확인하자

기기나 에뮬레이터를 연결한 뒤 터미널에서

flutter devices

를 입력합니다.

Flutter 공식 문서에서도 연결된 Android 디바이스가 제대로 인식됐는지 flutter devices로 확인하도록 안내합니다.

정상적으로 연결되어 있다면 사용할 수 있는 기기가 표시됩니다.

예를 들어

Android Emulator
Chrome
macOS
iPhone Simulator

처럼 환경에 따라 여러 실행 대상이 보일 수 있습니다.

이제 Flutter가

알 수 있게 된 겁니다.

11. iOS 앱도 만들 거라면 Xcode가 필요하다

우리의 최종 목표에는 iOS 배포도 포함되어 있습니다.

Flutter에서 iOS 앱을 실행하고 빌드하려면 Xcode 개발환경을 준비해야 합니다. 공식 Flutter 가이드에서는 Xcode를 통해 실제 iOS 기기 또는 iOS Simulator에서 Flutter 앱을 실행하도록 안내합니다.

이 부분에서 플랫폼 차이가 하나 생깁니다.

Android 개발은 Windows와 macOS 등에서 진행할 수 있지만, iOS 개발환경에서는 Xcode가 필요하기 때문에 Mac 환경이 필요합니다.

Mac이라면 Xcode를 설치한 뒤 초기 설정과 라이선스 동의, 필요한 iOS 플랫폼 구성 요소를 준비합니다. Flutter 공식 iOS 설정 문서 역시 Xcode 설치와 Command Line Tools 설정을 iOS 개발환경 구성 과정에 포함하고 있습니다.

처음에는 실제 아이폰보다 Simulator로 시작하는 것도 좋습니다.

Simulator 실행은 터미널에서 다음처럼 할 수 있습니다.

open -a Simulator

Flutter 공식 문서에서도 초기 iOS 테스트는 실제 기기보다 Simulator 설정이 간단하다는 이유로 Simulator부터 시작할 것을 안내하고 있습니다. 다만 최종적으로는 실제 기기에서도 테스트하는 것이 권장됩니다.

12. 잠깐, 아직 Apple 개발자 등록은 하지 않아도 된다

첫 화면을 띄우는 단계부터 유료 Apple Developer Program 가입을 서두를 필요는 없습니다.

우리는 아직 App Store에 제출하는 단계가 아닙니다.

iOS Simulator에서 앱을 실행하며 개발하는 것과 실제 App Store에 앱을 배포하는 것은 별개의 단계입니다.

실제 아이폰 테스트와 코드 서명, 그리고 최종 App Store 배포는 후반부에서 차근차근 다루겠습니다.

지금 모든 것을 해결하려고 하지 않는 것이 포인트입니다.

오늘은 첫 실행만 성공하면 됩니다.

13. 드디어 MyLog 프로젝트를 만든다

개발환경이 준비됐다면 이제 프로젝트를 만들어봅니다.

프로젝트를 저장할 폴더로 이동합니다.

예를 들어

cd ~/Projects

그리고 다음 명령을 실행합니다.

flutter create mylog

Flutter CLI에서 flutter create <프로젝트명> 명령을 이용해 새로운 프로젝트를 생성할 수 있습니다. 프로젝트 이름은 일반적으로 lowercase_with_underscores 형식을 사용하도록 공식 문서에서 안내하고 있습니다.

잠시 후 여러 파일과 폴더가 만들어집니다.

처음 보는 순간 이런 반응이 자연스럽습니다.

정상입니다. 😂

14. 프로젝트 폴더를 한번 구경해보자

모든 폴더를 이해할 필요는 없습니다.

지금은 몇 개만 얼굴을 익히겠습니다.

mylog/

android/
ios/
lib/
macos/
test/
pubspec.yaml

여기서 가장 먼저 기억할 곳은

lib/

입니다.

Flutter에서 우리가 작성하는 주요 Dart 코드가 들어가는 곳입니다.

그리고 그 안에 보통

main.dart

가 있습니다.

쉽게 생각하면

입니다.

android/ 폴더에는 Android 플랫폼 관련 파일들이 들어 있고,

ios/에는 iOS 관련 설정이 있습니다.

macos/에는 macOS 앱에 필요한 플랫폼 파일들이 들어갑니다.

pubspec.yaml도 앞으로 매우 자주 보게 됩니다.

외부 패키지와 프로젝트 설정 등을 관리할 때 사용합니다.

지금 다 외우지 않아도 됩니다.

우리는 관광객처럼 이름표만 보고 지나가겠습니다. 🚌

15. AI에게 이 프로젝트를 보여줄 때 첫 요청은?

여기서 바로

라고 하지 않습니다.

지난 편에서 만든 PRD가 있습니다.

우선 AI에게 프로젝트 구조부터 확인시킵니다.

예를 들면 이렇게 시작할 수 있습니다.

이 프로젝트는 Flutter로 만드는 MyLog 앱이다.

아직 코드를 수정하지 마.

먼저 현재 프로젝트 구조를 확인하고
다음 내용을 설명해줘.

1. Flutter 프로젝트가 정상적으로 생성되었는지
2. 앱의 시작 파일이 무엇인지
3. 현재 기본 앱이 어떤 구조인지
4. 앞으로 MyLog를 만들면서 주로 수정할 파일이 무엇인지
5. 현재 단계에서 제거하거나 추가할 것이 있는지

아직 기능 구현은 하지 마.

여기서 중요한 문장은 또 등장합니다.

"아직 코드를 수정하지 마."

AI에게 프로젝트를 처음 보여주는 순간부터 무조건 공사를 시작하게 할 필요는 없습니다.

일단 집 구조부터 둘러보게 합니다.

16. 먼저 기본 앱을 그대로 실행한다

MyLog 코드를 작성하기 전에 Flutter가 기본으로 만들어준 앱부터 실행합니다.

프로젝트 디렉터리로 이동합니다.

cd mylog

그리고 실행합니다.

flutter run

Flutter 공식 문서에서도 프로젝트 생성 후 flutter run을 이용해 연결된 실행 대상을 선택하고 앱을 실행할 수 있도록 안내합니다.

여러 기기가 연결되어 있다면 어느 기기에서 실행할 것인지 선택하게 될 수 있습니다.

조금 기다리면 스마트폰 또는 에뮬레이터에 Flutter 기본 앱이 나타납니다.

화려하지 않습니다.

우리가 만든 것도 아닙니다.

그런데 이 순간이 상당히 중요합니다.

개발환경 → Flutter → 프로젝트 → 기기

전체 통로가 처음으로 연결됐기 때문입니다.

17. 이 화면이 뜨면 오늘은 성공이다

우리는 오늘 MyLog 기능을 하나도 만들지 않았습니다.

그런데 기본 Flutter 화면이 정상적으로 나타났다면 오늘 목표는 완료입니다.

체크해보겠습니다.

Flutter 설치 완료

✓ flutter --version 실행

✓ flutter doctor 확인

✓ Android 또는 iOS 실행환경 준비

✓ flutter devices에서 기기 확인

✓ MyLog 프로젝트 생성

✓ flutter run 성공

✓ 실제 화면 표시

이 상태를 Baseline, 즉 우리가 출발할 정상 상태로 생각하겠습니다.

18. 여기서 바로 Git을 사용한다

지난 #02에서 Git을 왜 강조했는지 이제 실제로 연결됩니다.

앱이 정상적으로 실행되는 상태를 확인했다면 Git 상태를 확인합니다.

Flutter 프로젝트를 생성할 때 환경에 따라 Git 저장소가 함께 초기화될 수 있지만, 핵심은 현재 정상 상태를 하나의 기준점으로 남기는 것입니다.

예를 들어 첫 커밋의 의미는 이런 식입니다.

Initial Flutter project

또는

Flutter 프로젝트 생성 및 첫 실행 확인

이제부터 AI가 코드를 수정하다가 문제가 생기면

아무것도 안 되던 과거

가 아니라

정상적으로 실행되던 첫 상태

와 비교할 수 있습니다.

우리에게 첫 번째 안전지대가 생긴 셈입니다. 🏕️

19. AI에게 환경설정 오류를 맡길 때 주의할 점

개발환경을 구성하다 보면 높은 확률로 오류 하나쯤 만납니다.

예를 들어

Android toolchain 문제

Xcode configuration 문제

No devices found

같은 메시지가 나타날 수 있습니다.

이때 AI에게 그냥

라고 하지 마세요.

더 좋은 방법은 오류 메시지를 그대로 제공하면서 변경 전에 원인부터 분석하게 하는 것입니다.

flutter doctor 결과에서 아래 오류가 발생했다.

[오류 내용]

아직 시스템 설정이나 파일을 변경하지 말고

1. 오류 원인
2. 현재 개발에 영향을 주는지
3. 반드시 해결해야 하는지
4. 해결 순서
5. 실행해야 할 명령어

를 먼저 설명해줘.

특히 개발환경 문제에서는 AI가 오래된 설치 방법을 제안할 수도 있습니다.

따라서 SDK 설치, Android SDK 버전, Xcode 설정처럼 버전에 따라 바뀌는 내용은 공식 문서를 기준으로 다시 확인하는 습관을 들이는 것이 좋습니다.

AI는 훌륭한 길잡이지만 표지판이 어제 바뀌었을 수도 있으니까요.

20. 오늘의 삽질 방지 팁 🛠️

처음부터 iOS, Android, macOS를 전부 완벽하게 설정하려고 하지 마세요.

우선 플랫폼 하나에서 앱이 실행되는 것을 목표로 합니다.

예를 들어 Android부터 한다면

Flutter 설치

↓

Android Studio / SDK

↓

Android Emulator

↓

flutter doctor

↓

flutter devices

↓

flutter run

여기까지 성공합니다.

그다음 iOS 환경을 추가해도 늦지 않습니다.

문제가 생겼을 때 변수 하나만 움직이는 것이 중요합니다.

Flutter도 설치하고,

Xcode도 업데이트하고,

Android SDK도 바꾸고,

AI가 프로젝트 파일도 수정했는데

갑자기 앱이 안 된다?

범인은 다섯 명인데 CCTV가 없습니다. 🕵️

하나씩 합시다.

21. 그리고 한 가지 더, 설치부터 AI에게 전부 맡기지는 말자

요즘 AI 에이전트는 터미널 명령을 직접 실행할 수 있습니다.

그래서

라고 하고 싶을 수 있습니다.

저는 첫 프로젝트에서는 추천하지 않습니다.

적어도

Flutter가 어디에 설치되는지,

Android SDK가 왜 필요한지,

Xcode가 어떤 역할을 하는지,

flutter doctor가 무엇을 검사하는지,

flutter run이 어떤 역할인지

정도는 직접 경험하는 것이 좋습니다.

이 과정을 한 번 알고 나면 두 번째부터 AI에게 더 많이 맡겨도 됩니다.

비개발자에게 중요한 것은 모든 명령어를 암기하는 것이 아닙니다.

컴퓨터 안에서 지금 무슨 일이 일어나고 있는지 대략 알고 있는 것입니다.

22. 첫 실행은 생각보다 큰 이정표다

화면에는 Flutter 기본 앱 하나만 떠 있습니다.

아직 MyLog라는 이름조차 제대로 보이지 않을 수도 있습니다.

하지만 우리가 지금까지 한 것을 연결하면 이야기가 달라집니다.

아이디어

↓

MVP 범위 결정

↓

PRD 작성

↓

개발환경 구축

↓

Flutter 프로젝트 생성

↓

실행환경 연결

↓

첫 앱 실행

이제 우리는 문서에서 실제 소프트웨어로 넘어왔습니다.

여기부터는 AI가 코드를 수정할 때마다 결과를 직접 눈으로 확인할 수 있습니다.

그리고 앞으로 지킬 기본 흐름도 하나 만들어졌습니다.

요구사항 확인

↓

AI에게 현재 구조 분석 요청

↓

작업 계획 확인

↓

작은 단위로 코드 수정

↓

flutter run

↓

실제 화면 확인

↓

문제없으면 Git Commit

앞으로 이 루프를 정말 많이 돌게 됩니다.

바이브 코딩의 핵심 화면은 어쩌면 화려한 AI 채팅창이 아니라 이 반복 과정일지도 모릅니다.

23. 오늘의 완료 조건

#05에서 배운 방식대로 이번 편도 완료 조건을 명확하게 해보겠습니다.

오늘은 아래 항목이 되면 성공입니다.

[ ] Flutter가 설치되어 있다.

[ ] flutter --version이 정상적으로 실행된다.

[ ] flutter doctor 결과를 확인했다.

[ ] Android 또는 iOS 실행 환경 하나 이상을 준비했다.

[ ] flutter devices에서 실행할 기기를 확인할 수 있다.

[ ] mylog 프로젝트를 생성했다.

[ ] flutter run으로 앱을 실행했다.

[ ] 스마트폰 또는 에뮬레이터에서 Flutter 앱 화면을 확인했다.

[ ] 정상 상태를 Git으로 남겼다.

모두 체크됐다면 다음 단계로 갈 준비가 끝났습니다.

오늘 만든 것은 기능이 아닙니다.

개발할 수 있는 상태 자체를 만든 것입니다.

이제 AI에게 코드를 수정하게 할 수 있습니다.

그런데 바로 첫 화면부터 만들지는 않겠습니다.

다음 편에서는 앞으로 AI가 코드를 마음껏 바꾸기 전에 반드시 준비해야 할 안전장치를 하나 제대로 다뤄보겠습니다.

바로 Git입니다.

이미 조금 사용했지만 다음에는

커밋이 무엇인지,

변경 내용을 어떻게 확인하는지,

AI가 프로젝트를 망가뜨렸을 때 어떻게 이전 상태로 돌아가는지,

어느 시점에 커밋하면 좋은지,

그리고 AI에게 Git 작업을 어디까지 맡겨도 되는지

를 비개발자 관점에서 실제 프로젝트와 연결해보겠습니다.

다음 편은

[바이브 코딩 실전 #07] AI가 코드를 망쳐도 돌아갈 수 있게 | 비개발자를 위한 Git과 버전관리

입니다.

이제부터 AI에게 조금 더 과감하게 일을 시킬 수 있습니다.

뒤에 세이브 포인트가 생길 테니까요. 🎮

연재 기준: 2026년 8월Flutter, Android SDK, Xcode 등 개발 도구의 설치 방법과 지원 버전은 변경될 수 있습니다. 개발환경 관련 명령이나 요구사항은 실제 설치 시점의 Flutter 및 각 플랫폼 공식 문서를 함께 확인하는 것을 권장합니다.

#바이브코딩 #VibeCoding #AI코딩 #Flutter #Flutter설치 #Flutter개발환경 #비개발자앱개발 #앱개발 #AndroidStudio #Xcode #FlutterDoctor #FlutterRun #AI에이전트 #MVP개발 #MyLog #바이브코딩실전