바이브 코딩 실전 10화: Flutter 첫 화면과 최소 기능 앱 만들기

바이브 코딩 실전 10화입니다. Flutter에서 MyLog의 첫 번째 실제 기능인 기록 목록, 작성, 상세 화면을 연결하고 앱 실행 중 입력 데이터를 저장해 다시 확인하는 흐름을 구현합니다. 데이터베이스나 상태관리 패키지 없이 List<Record>, Navigator, 입력 검증, 수동 테스트, flutter analyze, Git commit까지 작은 단계로 개발하고 검증하는 방법을 다룹니다.

1. 오늘은 데이터베이스도 패키지도 필요 없다

기록 앱을 만든다고 하면 흔히 이런 생각부터 합니다.

데이터베이스는 뭘 쓰지?

SQLite?

Hive?

Isar?

SharedPreferences?

벌써 이름이 많습니다.

하지만 오늘은 아무것도 고르지 않겠습니다.

앱 안에 간단한 목록 하나만 만들어 기록을 담아두겠습니다.

개념적으로는 이렇습니다.

앱 실행

↓

List<Record>

↓

기록 추가

↓

화면 갱신

앱이 살아 있는 동안에는 데이터가 존재합니다.

앱을 완전히 종료하면 사라집니다.

제품으로서는 부족하지만 오늘 우리가 확인하려는 것은 저장 기술이 아닙니다.

사용자 흐름이 제대로 작동하는가?

입니다.

기능과 저장 기술을 동시에 붙이지 않는 이유도 여기에 있습니다.

문제가 생겼을 때 범인을 줄이는 겁니다.

2. 먼저 Git 세이브부터 한다

AI에게 첫 번째 본격적인 코드 수정을 맡기기 전에 지난 편에서 만든 습관부터 사용합니다.

git status

현재 변경사항을 확인합니다.

앱도 정상적으로 실행되는지 확인합니다.

그리고 필요하다면 커밋합니다.

예를 들면

chore: MyLog 화면 구현 전 기준 상태

이제 AI가 코드를 멋지게 만들어도 좋고,

예술적으로 폭파해도 괜찮습니다.

돌아올 집은 남아 있습니다. 🏠

3. AI에게 "앱 만들어줘"라고 하지 않는다

우리는 이미 PRD와 APP_FLOW.md를 가지고 있습니다.

따라서 첫 요청도 구체적으로 할 수 있습니다.

docs/PRD.md
docs/PROJECT_RULES.md
docs/APP_FLOW.md

문서를 먼저 확인해줘.

이번 작업에서는 MyLog MVP의 기본 화면 구조만 구현한다.

필요한 화면은 다음 세 개다.

1. Record List
2. Record Create
3. Record Detail

데이터 모델은 다음과 같다.

Record
- id
- title
- content
- createdAt

이번 단계에서는
로컬 DB나 외부 패키지를 추가하지 않는다.

Record 데이터는 앱 실행 중 메모리에서만 관리한다.

아직 코드를 수정하지 말고

1. 생성하거나 수정할 파일
2. 각 파일의 역할
3. 화면 이동 방법
4. 데이터 전달 방법

을 먼저 설명해줘.

우리가 #03에서 배운 방식입니다.

바로 코드부터 작성하게 하지 않습니다.

먼저 작업 계획을 봅니다.

4. 파일 구조도 너무 거창하게 만들지 않는다

AI가 제안한 구조가 지나치게 복잡하다면 줄입니다.

MyLog MVP에서는 이 정도면 충분합니다.

lib/
│
├── main.dart
│
├── models/
│   └── record.dart
│
└── screens/
    ├── record_list_screen.dart
    ├── record_create_screen.dart
    └── record_detail_screen.dart

파일이 네 개 정도 생깁니다.

아직

repositories/
services/
providers/
controllers/
usecases/
datasources/

같은 구조는 만들지 않습니다.

그런 구조가 나쁜 것은 아닙니다.

지금은 필요하지 않을 뿐입니다.

기록 네 개 저장하는 앱인데 기업용 ERP의 폴더 구조부터 가져오면 현관보다 지하주차장이 먼저 완공되는 일이 생깁니다. 😅

5. 첫 번째로 Record를 만든다

지난 편에서 데이터 구조를 정했습니다.

Record

id
title
content
createdAt

이것을 코드에서도 하나의 모델로 만듭니다.

예를 들어 개념적으로는 이런 모습입니다.

class Record {
  final String id;
  final String title;
  final String content;
  final DateTime createdAt;

  Record({
    required this.id,
    required this.title,
    required this.content,
    required this.createdAt,
  });
}

처음 보면 조금 낯설 수 있습니다.

하지만 지금 모든 Dart 문법을 공부할 필요는 없습니다.

우리가 읽어야 할 부분은 이것입니다.

Record 하나에는

id가 있고
title이 있고
content가 있고
createdAt이 있다.

#09에서 설계했던 데이터가 그대로 코드가 된 것입니다.

이게 중요합니다.

AI가 갑자기 category, imageUrl, userId 같은 필드를 추가했다면 물어볼 수 있습니다.

PRD에 없는 데이터인데 왜 추가했어?

코드를 직접 쓰지 않아도 설계와 코드가 맞는지는 확인할 수 있습니다.

6. 기록 목록은 어디에 보관할까?

현재는 DB를 사용하지 않습니다.

그래서 기록들을 앱의 메모리에 보관합니다.

개념적으로는 이런 목록 하나입니다.

final List<Record> records = [];

처음에는 비어 있습니다.

사용자가 첫 번째 기록을 작성하면

records

[첫 번째 기록]

두 번째 기록을 작성하면

records

[첫 번째 기록]
[두 번째 기록]

이렇게 됩니다.

그리고 기록이 추가될 때 화면을 다시 그려줘야 합니다.

Flutter에서는 변경 가능한 상태를 가진 화면에 StatefulWidget과 State를 사용할 수 있고, 상태를 변경한 뒤 setState()를 호출하면 프레임워크가 해당 UI를 다시 그립니다.

처음에는 이렇게 기억하면 충분합니다.

데이터 변경

↓

setState()

↓

화면 갱신

7. 기록이 없을 때부터 구현한다

Record List 화면을 처음 열었습니다.

당연히 아무 기록도 없습니다.

지난 편에서 Empty State를 정의했습니다.

그래서 하얀 화면만 보여주지 않습니다.

예를 들면

아직 작성한 기록이 없습니다.

첫 기록을 남겨보세요.

        [첫 기록 작성]

정도면 충분합니다.

그리고 화면 한쪽에 새 기록 작성 버튼을 둡니다.

Flutter라면 FloatingActionButton 같은 기본 UI를 이용할 수도 있습니다.

지금 중요한 것은 버튼 모양이 아닙니다.

버튼을 눌렀을 때 기록 작성 화면으로 이동하는 것입니다.

8. 화면 이동은 Navigator로 시작한다

MyLog는 현재 화면이 세 개뿐입니다.

복잡한 라우팅 패키지를 추가할 필요가 없습니다.

Flutter는 기본 Navigator를 이용해 새로운 화면으로 이동하는 push()와 이전 화면으로 돌아오는 pop() 방식을 제공합니다.

개념적으로는

Record List

Navigator.push()

↓

Record Create

입니다.

그리고 작성을 마치면

Record Create

Navigator.pop()

↓

Record List

로 돌아옵니다.

스택이라는 용어도 만나게 되겠지만,

지금은 화면을 책 위에 한 장씩 올려놓는다고 생각하면 쉽습니다.

Record List

위에

Record Create

작성 화면을 닫으면 위에 있던 한 장이 사라지고 다시 목록이 보입니다.

9. 기록 작성 화면을 만든다

이제 두 번째 화면입니다.

필요한 입력은 딱 두 가지입니다.

제목

내용

Flutter에는 사용자 텍스트 입력을 위한 TextField와 TextFormField가 제공됩니다.

그리고 입력한 값을 코드에서 읽어야 합니다.

이때 사용할 수 있는 것이 TextEditingController입니다.

Flutter 공식 가이드에서도 TextField에 입력된 값을 가져오기 위해 TextEditingController를 연결하는 방법을 안내하고 있습니다. 사용이 끝난 컨트롤러는 dispose()로 정리하는 것도 중요합니다.

개념만 보면 이렇습니다.

final titleController = TextEditingController();
final contentController = TextEditingController();

그리고 저장 버튼을 눌렀을 때

titleController

→ 사용자가 입력한 제목


contentController

→ 사용자가 입력한 내용

을 가져옵니다.

10. 제목이 없으면 저장하지 않는다

여기서 PRD가 또 등장합니다.

우리는 이미 규칙을 만들었습니다.

title = 필수

content = 선택

따라서 저장 버튼을 눌렀을 때 제목이 비어 있다면 기록을 만들지 않습니다.

예를 들면

제목을 입력해주세요.

라는 안내를 보여줍니다.

AI가 그냥 저장하도록 만들었다면 요구사항과 맞지 않습니다.

이럴 때 우리는

코드가 실행되냐?

만 확인하지 않습니다.

PRD대로 실행되냐?

를 확인합니다.

제품 개발에서는 둘이 다른 질문입니다.

11. 저장 버튼을 누르면 Record 하나를 만든다

제목이 정상적으로 입력됐다면 이제 Record를 만듭니다.

예를 들어

final record = Record(
  id: DateTime.now().microsecondsSinceEpoch.toString(),
  title: titleController.text.trim(),
  content: contentController.text.trim(),
  createdAt: DateTime.now(),
);

처럼 만들 수 있습니다.

여기서 id 생성 방식은 지금 중요한 것이 아닙니다.

현재 MVP에서는 각 기록을 서로 구분할 수 있는 값이면 충분합니다.

나중에 DB를 사용하면 ID 생성 방식도 달라질 수 있습니다.

중요한 것은

사용자가 입력한 값

↓

Record 객체

↓

목록에 추가

라는 흐름입니다.

12. 그런데 작성한 Record를 목록으로 어떻게 돌려보낼까?

여기서 재미있는 부분이 나옵니다.

우리는 Record Create 화면에서 새 기록을 만들었습니다.

그런데 실제 기록 목록은 Record List 화면이 가지고 있습니다.

그러면 새로 만든 Record를 목록 화면으로 돌려줘야 합니다.

Flutter의 Navigator.pop()은 화면을 닫을 때 결과 값을 이전 화면으로 돌려줄 수 있습니다. 이전 화면에서는 Navigator.push()가 반환하는 결과를 받아 사용할 수 있습니다.

흐름은 이렇게 만들 수 있습니다.

Record List

↓

Record Create 열기

↓

사용자 입력

↓

Record 생성

↓

Navigator.pop(record)

↓

Record List에서 record 받음

↓

records에 추가

↓

setState()

↓

목록 화면 갱신

이 흐름이 오늘 구현의 핵심입니다.

13. 코드보다 흐름을 읽어보자

대략 이런 형태가 될 수 있습니다.

final newRecord = await Navigator.push<Record>(
  context,
  MaterialPageRoute(
    builder: (_) => const RecordCreateScreen(),
  ),
);

if (newRecord != null) {
  setState(() {
    records.add(newRecord);
  });
}

코드 한 줄 한 줄을 외울 필요는 없습니다.

우리는 이렇게 읽습니다.

작성 화면을 연다.

↓

기다린다.

↓

새로운 Record가 돌아오면

↓

records에 추가한다.

↓

화면을 갱신한다.

비개발자 바이브 코딩에서 이런 식으로 코드의 문법보다 코드의 역할을 읽는 습관이 굉장히 중요합니다.

14. 기록이 생기면 목록 화면도 달라진다

처음에는 Empty State였습니다.

아직 작성한 기록이 없습니다.

이제 records에 데이터가 하나 생겼습니다.

그러면 목록을 보여줍니다.

예를 들면

MyLog

────────────────────

바이브 코딩 첫 기록
2026.08.17

────────────────────

                       +

두 번째 기록을 작성하면

MyLog

────────────────────

오늘의 생각
2026.08.17

────────────────────

바이브 코딩 첫 기록
2026.08.17

────────────────────

처럼 늘어날 수 있습니다.

여기서 중요한 것은 데이터가 바뀌자 화면도 바뀌었다는 것입니다.

바로

State

↓

UI

관계입니다.

15. 기록을 누르면 상세 화면으로 이동한다

이제 마지막 흐름입니다.

목록의 기록 하나를 누릅니다.

이번에는 새 데이터를 만들 필요가 없습니다.

이미 선택한 Record가 있습니다.

그 Record를 상세 화면에 전달합니다.

Record List

선택한 Record

↓

Navigator.push()

↓

Record Detail

↓

title
content
createdAt 표시

상세 화면은 데이터를 수정하지 않습니다.

그냥 전달받은 값을 보여줍니다.

그래서 현재 단계에서는 상태 관리도 훨씬 단순합니다.

16. 왜 Provider나 Riverpod을 아직 안 쓰나요?

Flutter 상태 관리를 검색하다 보면 거의 바로 이런 이름들을 만나게 됩니다.

Provider

Riverpod

Bloc

Cubit

GetX

그리고 평화롭게 시작한 비개발자는 갑자기 상태관리 종교전쟁 한복판에 떨어집니다. 🫠

지금은 빠져나옵시다.

Flutter 공식 문서에서도 setState를 위젯에 국한된 간단한 상태를 처리하는 기본적인 접근 방식으로 설명하고 있습니다. 앱 상태가 커지면 다른 상태 관리 방식을 고려할 수 있습니다.

현재 MyLog의 기록 목록은 작고 구조도 단순합니다.

그래서 지금은

List<Record>

+

setState()

면 충분합니다.

나중에 앱 구조가 커지고 여러 화면이 동일한 상태를 공유하게 되면 그때 상태 관리 구조를 다시 생각하면 됩니다.

필요해지기 전에 복잡성을 선불로 결제하지 않겠습니다.

17. 이제 AI에게 실제 구현을 맡긴다

계획을 검토했다면 구현을 요청합니다.

계획대로 구현해줘.

조건은 다음과 같다.

- Record 모델을 만든다.
- 기록 목록 화면을 만든다.
- 기록 작성 화면을 만든다.
- 기록 상세 화면을 만든다.
- 새 패키지를 추가하지 않는다.
- 데이터는 앱 실행 중 메모리에서만 관리한다.
- 제목은 필수 입력이다.
- 저장 성공 후 목록으로 돌아온다.
- 생성한 Record를 목록에 추가한다.
- 목록에서 Record를 선택하면 상세 화면으로 이동한다.
- 현재 MVP 범위를 벗어난 기능은 추가하지 않는다.

구현 후

flutter analyze

를 실행하고 오류를 확인해줘.

아직 Git Commit은 하지 마.

여기서도 마지막 문장이 중요합니다.

AI가 코드를 만들었다고 바로 커밋하지 않습니다.

사람이 먼저 확인합니다.

18. AI의 "완료했습니다" 뒤에서 해야 할 일

AI가 말합니다.

구현이 완료되었습니다.

이제부터가 우리 일입니다.

먼저 변경 파일을 확인합니다.

git status

그리고 Diff도 봅니다.

우리가 예상했던 파일과 비슷한가요?

record.dart

record_list_screen.dart

record_create_screen.dart

record_detail_screen.dart

main.dart

정도라면 자연스럽습니다.

그런데 갑자기

android/
ios/
build.gradle
Info.plist

까지 잔뜩 변경됐다면 이유를 확인해야 합니다.

오늘 작업은 화면 세 개 만드는 일이었습니다.

플랫폼 설정을 대규모로 건드릴 이유가 거의 없습니다.

19. flutter analyze도 확인한다

Flutter에는 소스 코드를 정적으로 분석하는 명령이 있습니다.

flutter analyze

AI에게 실행하게 할 수도 있고 직접 실행해도 됩니다.

오류가 없다는 것을 확인합니다.

하지만 이것만으로 충분하지 않습니다.

그다음 진짜 중요한 명령입니다.

flutter run

그리고 직접 사용합니다.

20. 오늘은 손으로 테스트한다

우리는 아직 테스트 코드를 본격적으로 만들 단계는 아닙니다.

대신 실제 앱을 손으로 사용해봅니다.

테스트 1

앱 실행

기록 없음

→ Empty State가 보이는가?

테스트 2

새 기록 작성

제목 입력

내용 입력

저장

→ 목록에 기록이 나타나는가?

테스트 3

저장된 기록 선택

→ 상세 화면에 제목과 내용이 맞게 나타나는가?

테스트 4

제목 없이 저장

→ 저장되지 않고 안내가 나타나는가?

테스트 5

기록 두 개 작성

→ 두 기록이 모두 목록에 나타나는가?

이 다섯 개가 모두 된다면 오늘은 상당히 성공적입니다.

21. 그리고 일부러 앱을 종료해본다

여기서 마지막 테스트가 있습니다.

앱을 완전히 종료합니다.

다시 실행합니다.

기록이 없습니다.

😱

앱이 망가진 걸까요?

아닙니다.

정확히 우리가 만든 대로 동작한 것입니다.

현재 데이터는 스마트폰 저장소에 기록된 것이 아니라 앱이 실행되는 동안의 메모리에만 존재합니다.

앱 실행

records 존재

↓

앱 종료

records 사라짐

오늘 이 현상을 직접 보는 것이 중요합니다.

그래야 다음 편에서

"왜 영구 저장소가 필요한가?"

를 몸으로 이해하게 됩니다.

22. MVP를 일부러 덜 완성하는 이유

여기서 이런 생각이 들 수 있습니다.

어차피 다음 편에 로컬 저장할 건데 처음부터 같이 만들면 안 되나요?

할 수 있습니다.

AI라면 금방 추가할 수도 있습니다.

하지만 우리는 일부러 분리했습니다.

오늘 문제가 생기면 확인할 곳은

화면
입력
Navigator
Record
상태 갱신

정도입니다.

여기에 로컬 데이터베이스까지 넣으면

직렬화
파일 저장
DB 초기화
읽기
쓰기
비동기 처리
데이터 복구

같은 변수가 추가됩니다.

바이브 코딩에서 작업 단위를 작게 만드는 이유는 AI가 일을 못해서가 아닙니다.

문제가 생겼을 때 사람이 이해할 수 있게 하기 위해서입니다.

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

AI에게 이런 요청을 조심하세요.

기록 앱 기본 기능을 완성해줘.

AI에게는 "기본 기능"의 범위가 모호합니다.

검색을 넣을 수도 있고,

수정을 넣을 수도 있고,

삭제를 넣을 수도 있습니다.

심지어 로컬 DB 패키지를 알아서 골라 넣을 수도 있습니다.

대신 이렇게 말합니다.

이번 작업의 완료 범위는

작성
→ 목록 표시
→ 상세 보기

까지다.

앱 재실행 후 데이터 유지 기능은
이번 작업에 포함하지 않는다.

수정, 삭제, 검색 기능도 추가하지 않는다.

완료 범위를 알려주는 것만큼 중단선을 알려주는 것도 중요합니다.

AI에게 어디까지 달릴지 알려줘야 브레이크 없이 다음 마을까지 가지 않습니다.

24. AI에게 구현 후 설명도 시켜보자

작업이 정상적으로 끝났다면 이런 질문을 해보는 것도 좋습니다.

이번 구현을 비개발자가 이해할 수 있게 설명해줘.

특히 다음 데이터 흐름을 중심으로 설명해줘.

1. 사용자가 제목과 내용을 입력하면 어디에 들어가는지
2. Record가 언제 생성되는지
3. 작성 화면에서 목록 화면으로 Record가 어떻게 전달되는지
4. records 목록이 어떻게 갱신되는지
5. 목록에서 상세 화면으로 데이터가 어떻게 전달되는지

코드 문법보다는 데이터 흐름 위주로 설명해줘.

이 과정을 반복하다 보면 코드가 조금씩 읽히기 시작합니다.

직접 작성하지 않아도

"이 데이터가 어디에서 생겨서 어디로 가는지"

는 볼 수 있게 됩니다.

그 능력이 나중에 오류를 찾을 때 상당히 도움이 됩니다.

25. 정상이라면 이제 Commit

직접 실행해봤고,

제목 검증도 되고,

목록도 나오고,

상세 화면도 정상입니다.

그러면 Git에 저장합니다.

예를 들면

feat: 기록 작성 목록 상세 흐름 구현

이제 새로운 세이브 포인트가 생겼습니다.

Flutter 기본 프로젝트

↓

화면 설계

↓

기록 작성·목록·상세 동작 완료 ← SAVE

다음 편에서 저장 기능을 붙이다 프로젝트가 이상해져도 오늘의 정상 상태로 돌아올 수 있습니다.

26. 오늘 드디어 앱다운 것이 생겼다

지금 MyLog에서 가능한 것은 이것입니다.

앱 실행

↓

기록 작성

↓

제목과 내용 입력

↓

Record 생성

↓

목록 추가

↓

목록 확인

↓

상세 보기

아직 단순합니다.

디자인도 화려하지 않습니다.

앱을 종료하면 데이터도 사라집니다.

하지만 굉장히 중요한 변화가 생겼습니다.

이전까지 MyLog는

문서 속의 앱

이었습니다.

이제는 사용자가 실제로 버튼을 누르고 데이터를 입력하며 화면을 이동할 수 있는 작동하는 소프트웨어가 됐습니다.

27. 오늘의 완료 조건

이번에도 완료 기준을 확인해보겠습니다.

[ ] Record 데이터 모델이 만들어졌다.

[ ] 기록 목록 화면이 만들어졌다.

[ ] 데이터가 없을 때 Empty State가 표시된다.

[ ] 새 기록 작성 화면으로 이동할 수 있다.

[ ] 제목과 내용을 입력할 수 있다.

[ ] 제목 없이 저장할 수 없다.

[ ] 기록을 저장하면 목록으로 돌아온다.

[ ] 작성한 기록이 목록에 표시된다.

[ ] 기록을 선택하면 상세 화면으로 이동한다.

[ ] 상세 화면에서 제목과 내용을 확인할 수 있다.

[ ] 새 외부 패키지를 추가하지 않았다.

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

[ ] 실제 기기 또는 에뮬레이터에서 직접 테스트했다.

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

여기까지 체크됐다면 오늘 목표는 끝입니다.

그리고 마지막 항목 하나를 일부러 체크하지 않았습니다.

[ ] 앱을 종료해도 기록이 유지된다.

이건 아직 안 됩니다.

바로 다음 편의 주인공입니다.

28. 다음에는 진짜로 저장한다

현재 MyLog의 기억력은 금붕어에 가깝습니다.

앱을 켜놓으면 잘 기억합니다.

껐다 켜는 순간

처음 뵙겠습니다.

가 됩니다. 🐠

다음 편에서는 기록을 스마트폰의 로컬 영역에 저장해보겠습니다.

그러면 처음으로

기록 작성

↓

저장

↓

앱 완전 종료

↓

다시 실행

↓

기록 그대로 존재

가 가능해집니다.

그리고 여기서부터 새로운 개념도 등장합니다.

메모리와 영구 저장의 차이,

데이터를 저장 가능한 형태로 바꾸는 방법,

저장과 불러오기,

그리고 AI가 로컬 저장 기술을 골라줄 때 우리가 무엇을 확인해야 하는지까지 살펴보겠습니다.

다음 편

[바이브 코딩 실전 #11] 앱을 껐다 켜도 데이터가 남게 하려면? | 로컬 저장소 이해하기

#01에서 앱스토어 출시 이야기를 시작했는데 이제 우리 앱에도 드디어 기억이 생깁니다.

조금씩이지만 확실하게 MVP가 제품 쪽으로 걸어가고 있습니다. 📱🌱

연재 기준: 2026년 8월Flutter API와 권장 개발 방식은 업데이트될 수 있습니다. 본문에서는 현재 Flutter 공식 문서의 StatefulWidget, setState(), Navigator, TextEditingController 기본 사용 방식을 기준으로 설명했습니다.

#바이브코딩 #VibeCoding #AI코딩 #Flutter #Flutter앱개발 #비개발자앱개발 #앱만들기 #StatefulWidget #setState #FlutterNavigator #TextEditingController #MVP개발 #AI에이전트 #MyLog #바이브코딩실전

바이브 코딩 실전 10화: 첫 화면을 만들어보자

목차

1. 오늘은 데이터베이스도 패키지도 필요 없다

2. 먼저 Git 세이브부터 한다

3. AI에게 "앱 만들어줘"라고 하지 않는다

4. 파일 구조도 너무 거창하게 만들지 않는다

5. 첫 번째로 Record를 만든다

6. 기록 목록은 어디에 보관할까?

7. 기록이 없을 때부터 구현한다

8. 화면 이동은 Navigator로 시작한다

9. 기록 작성 화면을 만든다

10. 제목이 없으면 저장하지 않는다

11. 저장 버튼을 누르면 Record 하나를 만든다

12. 그런데 작성한 Record를 목록으로 어떻게 돌려보낼까?

13. 코드보다 흐름을 읽어보자

14. 기록이 생기면 목록 화면도 달라진다

15. 기록을 누르면 상세 화면으로 이동한다

16. 왜 Provider나 Riverpod을 아직 안 쓰나요?

17. 이제 AI에게 실제 구현을 맡긴다

18. AI의 "완료했습니다" 뒤에서 해야 할 일

19. flutter analyze도 확인한다

20. 오늘은 손으로 테스트한다

테스트 1

테스트 2

테스트 3

테스트 4

테스트 5

21. 그리고 일부러 앱을 종료해본다

22. MVP를 일부러 덜 완성하는 이유

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

24. AI에게 구현 후 설명도 시켜보자

25. 정상이라면 이제 Commit

26. 오늘 드디어 앱다운 것이 생겼다

27. 오늘의 완료 조건

28. 다음에는 진짜로 저장한다

다음 편

댓글