바이브 코딩 실전 9화: 화면부터 예쁘게 만들지 마세요

지난 편에서는 AI에게 매번 같은 설명을 반복하지 않도록

PRD.md

PROJECT_RULES.md

같은 프로젝트의 기억을 만들어두었습니다.

이제 정말 화면을 만들 차례입니다.

그래서 AI에게 이렇게 말하고 싶어집니다.

이 프롬프트를 입력하면 꽤 근사한 화면이 나올 가능성이 높습니다.

둥근 카드가 생기고,

예쁜 아이콘이 들어가고,

색상도 그럴듯합니다.

첫인상은 좋습니다.

그런데 오늘은 그 버튼을 누르기 전에 조금만 참아보겠습니다.

이번 편에서 우리는 앱을 예쁘게 만드는 것보다 먼저 움직이게 만드는 설계를 할 겁니다.

바로

사용자 흐름(User Flow)

과

데이터 구조(Data Structure)

입니다.

1. 예쁜 화면부터 만들면 왜 문제가 될까?

UI는 눈에 바로 보입니다.

그래서 만들고 나면 성취감이 큽니다.

특히 바이브 코딩에서는 AI가 화면을 빠르게 만들어주기 때문에 더 재미있습니다.

그런데 화면부터 만들면 한 가지 문제가 생깁니다.

화면에 맞춰 기능을 끼워 넣게 됩니다.

예를 들어 AI가 기록 목록 화면을 이렇게 만들었다고 해보겠습니다.

오늘의 기록

[사진]
여름 바다 여행
2026.08.17
#여행 #바다

[사진]
오늘의 생각
2026.08.16
#일상

예쁩니다.

문제는 우리가 아직 사진 기능을 만들기로 한 적이 없습니다.

태그도 없습니다.

그런데 UI에 이미 들어가 버렸습니다.

그러면 사람 마음이 묘해집니다.

이렇게 범위가 다시 늘어나기 시작합니다.

지난 #04에서 힘들게 기능을 다이어트했는데 UI가 냉장고 문을 다시 열어버리는 겁니다. 🍰

2. 화면을 그리기 전에 사용자가 무엇을 하는지 본다

MyLog의 목적을 다시 떠올려보겠습니다.

그렇다면 첫 번째로 설계해야 하는 것은 화면 디자인이 아니라 사용자의 행동 순서입니다.

이를 흔히 User Flow, 사용자 흐름이라고 합니다.

MyLog의 첫 번째 사용자 흐름은 아주 간단합니다.

앱 실행

↓

기록 목록 확인

↓

새 기록 작성

↓

저장

↓

기록 목록으로 돌아감

↓

저장된 기록 선택

↓

상세 내용 확인

이게 우리 MVP의 핵심입니다.

사용자는 이 길 하나를 문제없이 걸을 수 있어야 합니다.

아직 버튼 색깔은 중요하지 않습니다.

3. User Flow는 앱의 도로망이다

사용자 흐름을 도시라고 생각하면 이해하기 쉽습니다.

화면은 건물입니다.

버튼은 출입문입니다.

User Flow는 그 건물 사이를 연결하는 도로입니다.

아무리 건물이 예뻐도 길이 이상하면 도시 사용이 불편합니다.

예를 들어 기록 작성 후 저장 버튼을 눌렀습니다.

그다음 어디로 가야 할까요?

선택지가 있습니다.

저장 후

A. 작성 화면에 그대로 있음

B. 기록 목록으로 이동

C. 방금 작성한 상세 화면으로 이동

이런 것도 미리 결정해야 합니다.

MyLog MVP에서는 단순하게 갑니다.

으로 정하겠습니다.

이제 AI가 임의로 행동을 결정할 필요가 하나 줄었습니다.

4. MyLog에 필요한 화면은 세 개면 충분하다

사용자 흐름을 보고 화면을 추출합니다.

기록 목록 화면

기록 작성 화면

기록 상세 화면

끝입니다.

다시 한번 강조하지만

프로필 화면 없습니다.

설정 없습니다.

검색 없습니다.

캘린더 없습니다.

로그인도 없습니다.

현재 사용 흐름에 필요한 화면만 만듭니다.

5. 첫 번째 화면, 기록 목록

사용자가 앱을 실행하면 가장 먼저 보는 화면입니다.

이 화면의 목적은 하나입니다.

따라서 필요한 요소를 정해보겠습니다.

기록 목록 화면

- 화면 제목
- 저장된 기록 목록
- 새 기록 작성 버튼

각 기록에는 무엇을 표시할까요?

PRD에서 우리가 만든 데이터는

id
title
content
createdAt

였습니다.

목록에서 모든 내용을 보여줄 필요는 없습니다.

처음에는

title
createdAt

정도만 표시하면 충분합니다.

왜냐하면 전체 내용은 상세 화면에서 볼 수 있기 때문입니다.

6. 빈 화면도 화면이다

여기서 아주 중요한 상황이 하나 있습니다.

앱을 처음 설치했습니다.

아직 기록이 하나도 없습니다.

그러면 기록 목록 화면에는 무엇이 나와야 할까요?

이걸 Empty State, 빈 상태라고 합니다.

제품 개발에서는 굉장히 흔한 화면입니다.

MyLog에서는 이렇게 정할 수 있습니다.

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

첫 기록을 남겨보세요.

[새 기록 작성]

이렇게 하면 사용자는

"앱이 고장 난 건가?"

라고 생각하지 않습니다.

빈 데이터도 정상적인 상태라는 것을 알려줍니다.

바이브 코딩에서는 이런 작은 상태들을 AI가 알아서 처리하겠지 하고 넘어가기 쉬운데,

제품 수준으로 갈수록

데이터가 없을 때 무엇을 보여줄 것인가

도 반드시 생각해야 합니다.

7. 두 번째 화면, 기록 작성

이 화면의 목적은 더 단순합니다.

PRD에서 이미 입력 항목을 정했습니다.

제목

내용

그리고 규칙도 있었습니다.

제목은 필수

내용은 비어 있어도 됨

그렇다면 필요한 UI도 자연스럽게 나옵니다.

기록 작성

제목 입력

내용 입력

저장 버튼

여기서 벌써 데이터와 화면이 연결되고 있습니다.

이것이 오늘 중요한 포인트입니다.

화면은 데이터를 보여주거나 입력하기 위해 존재합니다.

8. 세 번째 화면, 기록 상세

목록에서 기록 하나를 누르면 상세 화면으로 이동합니다.

이 화면의 목적은

입니다.

필요한 데이터는

title
content
createdAt

정도입니다.

따라서 화면도 단순합니다.

제목

작성 날짜

내용

수정 버튼?

아직 없습니다.

삭제 버튼?

없습니다.

공유 버튼?

없습니다.

MVP는 여전히 다이어트 중입니다. 🥗

9. 화면 사이에 무엇을 전달할지도 생각한다

여기서 개발 구조가 조금 더 흥미로워집니다.

기록 목록에서 기록을 하나 눌렀습니다.

상세 화면은 어떤 기록을 보여줘야 할까요?

예를 들어 기록이 100개 있다면 어떤 데이터를 선택했는지 알아야 합니다.

이때 보통 기록의 고유한 값인

id

를 이용할 수 있습니다.

개념적으로 보면 이런 흐름입니다.

기록 목록

id = 42인 기록 선택

↓

상세 화면

id = 42 기록 표시

지금 이 로직을 직접 구현하지는 않습니다.

다만 화면끼리 이동할 때도 데이터가 함께 움직인다는 것을 이해하면 됩니다.

앱 개발에서 화면 전환은 단순히 페이지가 바뀌는 것이 아닙니다.

필요한 데이터도 함께 이동하는 경우가 많습니다.

10. 이제 데이터 구조를 다시 살펴보자

지난 편까지 MyLog의 데이터 모델은 이렇게 정의했습니다.

Record

id
title
content
createdAt

이것을 조금 더 구체적으로 생각해보겠습니다.

각 기록을 구분하는 고유 값

예를 들어

1
2
3
4

처럼 사용할 수도 있고 UUID 같은 값을 사용할 수도 있습니다.

지금 중요한 건 형태가 아닙니다.

각 기록을 서로 구분할 수 있어야 한다는 것입니다.

사용자가 입력하는 기록 제목입니다.

예를 들어

오늘 바이브 코딩을 시작했다

같은 값입니다.

PRD에서 필수 입력으로 정했습니다.

기록의 본문입니다.

오늘 처음으로 앱 개발을 시작했다.
생각보다 재미있다.

같은 내용이 들어갑니다.

현재 MVP에서는 내용이 비어 있어도 저장할 수 있습니다.

기록이 만들어진 시점입니다.

예를 들어

2026-08-17 20:30

같은 정보입니다.

사용자가 직접 입력하는 것이 아니라 앱이 자동으로 넣도록 할 수 있습니다.

11. 데이터 타입이라는 것도 살짝 맛만 보자

코드를 작성하다 보면 AI가 이런 말을 할 겁니다.

title은 String
createdAt은 DateTime

여기서 데이터 타입이라는 개념이 등장합니다.

지금 깊게 공부할 필요는 없습니다.

간단히 말하면

이 값에는 어떤 종류의 데이터가 들어가는가

입니다.

예를 들면

id → 문자열 또는 숫자

title → 문자열

content → 문자열

createdAt → 날짜/시간

정도입니다.

AI가 데이터 모델을 만들 때 이런 선택을 하게 됩니다.

우리는 적어도

정도만 이해하면 됩니다.

12. 데이터 구조를 먼저 정하면 AI가 덜 헤맨다

예를 들어 데이터 구조를 정하지 않고 AI에게

라고 했다고 생각해보겠습니다.

AI A는 이렇게 만들 수 있습니다.

title
content
date

AI B는

id
title
description
created
updated
category

로 만들 수도 있습니다.

다른 AI는

uuid
headline
body
created_at

를 만들 수도 있습니다.

각각 틀린 것은 아닙니다.

문제는 작업할 때마다 구조가 바뀌면 프로젝트 전체가 흔들린다는 것입니다.

그래서 우리는 먼저

Record

id
title
content
createdAt

을 기준으로 정합니다.

AI에게 선택지를 줄이는 겁니다.

13. 사용자 흐름과 데이터 구조를 연결해보자

이제 두 가지를 합쳐보겠습니다.

필요한 데이터

id
title
createdAt

입력하는 데이터

title
content

앱이 생성하는 데이터

id
createdAt

필요한 데이터

id
title
content
createdAt

이렇게 하면 화면을 만들기 전에 이미

어떤 화면에서 어떤 데이터가 필요한지

정리됩니다.

이 작업을 해두면 나중에 AI에게 화면을 구현시킬 때 훨씬 명확합니다.

14. 간단한 화면 설계도 만들어보자

이 단계에서는 Figma까지 사용할 필요 없습니다.

종이에 그려도 되고 텍스트로 표현해도 됩니다.

우리는 이렇게 만들어보겠습니다.

┌──────────────────────┐
│ MyLog                │
│                      │
│ 오늘의 생각          │
│ 2026.08.17           │
│                      │
│ 바이브 코딩 시작     │
│ 2026.08.16           │
│                      │
│                 [+]  │
└──────────────────────┘

기록 작성 화면은

┌──────────────────────┐
│ 새 기록              │
│                      │
│ 제목                 │
│ [________________]   │
│                      │
│ 내용                 │
│ [________________]   │
│ [________________]   │
│ [________________]   │
│                      │
│        [ 저장 ]      │
└──────────────────────┘

상세 화면은

┌──────────────────────┐
│ 오늘의 생각          │
│ 2026.08.17           │
│                      │
│ 오늘 바이브 코딩을   │
│ 시작했다.            │
│ 생각보다 재미있다.   │
│                      │
└──────────────────────┘

화려하지 않습니다.

하지만 기능은 보입니다.

이 정도면 AI가 실제 UI를 만들기 위한 충분한 출발점이 됩니다.

15. Wireframe은 디자인이 아니다

이런 단순한 화면 설계를 흔히 Wireframe, 와이어프레임이라고 부릅니다.

와이어프레임의 목적은 예쁜 화면을 만드는 것이 아닙니다.

무엇이 어디에 있어야 하는지 확인하는 것입니다.

그래서 색상도 필요 없고,

폰트 고민도 필요 없습니다.

애니메이션도 필요 없습니다.

지금은

목록이 여기에 있고

버튼이 여기에 있고

입력창이 이 정도 필요하다

만 확인하면 됩니다.

16. AI에게 와이어프레임을 맡겨도 된다

물론 AI에게 도움을 받을 수 있습니다.

예를 들어 이렇게 요청합니다.

docs/PRD.md와 PROJECT_RULES.md를 기준으로
MyLog MVP의 사용자 흐름을 분석해줘.

아직 Flutter 코드를 작성하지 마.

다음 내용을 먼저 정리해줘.

1. 필요한 화면
2. 각 화면의 목적
3. 화면별 필요한 데이터
4. 화면 사이 이동 경로
5. 빈 데이터 상태
6. 사용자 입력 오류 상황

MVP에 없는 기능을 추가하지 마.

결과를 확인한 뒤

라고 요청할 수도 있습니다.

여기에서도 AI를 먼저 설계 도우미로 사용하는 것입니다.

17. 화면보다 상태를 먼저 생각하는 습관

제품 앱에는 단순히 화면 하나만 존재하지 않습니다.

같은 화면도 데이터 상태에 따라 달라집니다.

예를 들어 기록 목록 화면만 해도 최소 두 가지 상태가 있습니다.

기록 있음

기록 없음

조금 뒤 네트워크가 들어오면 더 늘어납니다.

로딩 중

정상

데이터 없음

오류

현재 MyLog MVP는 로컬 저장이므로 아직 네트워크 상태는 없습니다.

덕분에 단순합니다.

바로 이것이 우리가 첫 MVP에서 서버를 뺀 이유 중 하나입니다.

기술 하나를 추가하면 화면 상태도 함께 늘어납니다.

18. 작성 화면에도 상태가 있다

기록 작성 화면도 마찬가지입니다.

정상 상태에서는

제목 있음

내용 있음

저장 가능

입니다.

하지만 제목이 비어 있다면?

PRD에서 이미 정했습니다.

제목이 비어 있으면 저장하지 않는다.

사용자에게 안내한다.

따라서 화면에는 이런 상태가 필요합니다.

제목을 입력해주세요.

아주 작은 기능 같지만 이것이 Validation, 입력 검증입니다.

앞으로 앱을 제품답게 만들수록 이런 검증이 계속 등장합니다.

19. 데이터 저장 위치도 다시 확인한다

현재 MyLog MVP에서 중요한 결정 하나를 이미 내렸습니다.

로컬 저장만 사용한다.

따라서 흐름은 이렇게 됩니다.

사용자

↓

Flutter 앱

↓

로컬 저장소

아직

API
서버
클라우드 DB

는 없습니다.

이 구조 덕분에 첫 번째 데이터 흐름도 아주 단순합니다.

제목 + 내용 입력

↓

저장 버튼

↓

Record 생성

↓

로컬 저장

↓

목록 갱신

앱 실행

↓

로컬 기록 읽기

↓

목록 표시

우리가 #02에서 배웠던 구조가 조금씩 실제 앱에 연결되고 있습니다.

20. Data Flow도 그려보자

사용자 흐름이 사람이 움직이는 길이라면,

Data Flow는 데이터가 움직이는 길입니다.

MyLog에서 새로운 기록을 저장한다고 생각해보겠습니다.

[작성 화면]

title
content

↓

[Record 생성]

id
title
content
createdAt

↓

[로컬 저장]

↓

[목록 화면]

title
createdAt 표시

그리고 상세 화면에서는

[목록]

Record 선택

↓

[상세 화면]

title
content
createdAt 표시

이 정도만 알고 있어도 AI가 만든 코드 구조를 이해하기 훨씬 쉬워집니다.

21. UI와 데이터 모델을 따로 만들면 생기는 문제

AI에게 먼저 예쁜 화면을 만들게 했습니다.

그다음 다른 대화에서 데이터 모델을 만들어달라고 했다고 해보겠습니다.

화면에서는

memoTitle
memoDate

를 사용하고 있는데,

데이터 모델에서는

title
createdAt

을 사용합니다.

물론 AI가 연결할 수 있습니다.

하지만 프로젝트가 커질수록 이런 작은 불일치가 계속 쌓입니다.

그래서 화면을 설계할 때부터

데이터 이름과 의미를 어느 정도 일치시키는 것

이 좋습니다.

제품 개발에서는 이름을 정하는 것도 생각보다 중요한 일입니다.

22. 이름은 한번 정했으면 쉽게 바꾸지 않는다

예를 들어 우리는 기록 객체를

Record

라고 부르기로 했습니다.

그런데 다음 작업에서 AI가

Memo

라고 만들고,

다음 AI는

JournalEntry

라고 만들면 프로젝트가 혼란스러워집니다.

각 이름은 모두 그럴듯합니다.

그래서 프로젝트 규칙이나 PRD에 용어를 정해두는 것도 좋습니다.

예를 들어

용어 규칙

사용자가 작성하는 하나의 기록 단위를 Record라고 부른다.

이제 AI에게도 같은 표현을 사용하게 합니다.

작은 프로젝트에서는 별것 아닌 것 같지만,

프로젝트가 커지면 이런 일관성이 유지보수에 큰 차이를 만듭니다.

23. 그렇다면 화면 디자인은 언제 하나요?

물론 UI 디자인도 합니다.

다만 순서를 이렇게 가져갑니다.

1. 사용자 목표

↓

2. User Flow

↓

3. 필요한 화면

↓

4. 데이터 구조

↓

5. 화면별 필요한 데이터

↓

6. Wireframe

↓

7. 실제 UI

이제 UI를 만들면 단순히

"예쁜 화면"

이 아니라

기능과 데이터가 들어갈 자리가 정해진 화면

이 됩니다.

집으로 치면 이제 배관과 전기 위치가 정해졌습니다.

이제 벽지를 고를 수 있습니다.

처음부터 예쁜 벽지를 붙이고 나중에 수도관을 넣으려면 벽을 다시 뜯어야 합니다. 🔨

24. MyLog 설계 문서를 하나 추가해도 좋다

지금까지 프로젝트 문서는

docs/

PRD.md
PROJECT_RULES.md

였습니다.

이제 작은 설계 문서를 하나 추가할 수 있습니다.

예를 들어

docs/
├── PRD.md
├── PROJECT_RULES.md
└── APP_FLOW.md

APP_FLOW.md에는 이런 내용을 넣습니다.

# MyLog App Flow

## Screen 1. Record List

목적:
저장된 기록을 확인한다.

표시 데이터:
- id
- title
- createdAt

행동:
- 기록 선택
- 새 기록 작성

빈 상태:
저장된 기록이 없다는 안내와
새 기록 작성 버튼을 표시한다.


## Screen 2. Record Create

목적:
새로운 기록을 작성한다.

입력:
- title
- content

규칙:
- title 필수
- content 선택

저장 성공:
기록 목록 화면으로 이동


## Screen 3. Record Detail

목적:
저장된 기록의 전체 내용을 확인한다.

표시 데이터:
- title
- content
- createdAt

이 정도면 충분합니다.

엄청난 설계 문서가 아닙니다.

AI와 우리가 같은 그림을 보는 것이 목적입니다.

25. 문서는 살아 있어야 한다

여기서 또 중요한 원칙입니다.

나중에 수정 기능이 추가되면 화면 흐름이 바뀔 수 있습니다.

그때 코드만 변경하지 않고 APP_FLOW.md도 함께 수정합니다.

예를 들어

Record Detail

↓

Edit Record

화면이 추가될 수 있습니다.

문서와 코드가 다르면 문서는 금방 쓰레기 정보가 됩니다.

그래서 문서는

작성하는 것보다 유지하는 것이 더 중요합니다.

필요한 것만 짧게 만드는 이유도 여기에 있습니다.

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

AI에게 UI를 요청할 때 이렇게 시작하지 않는 것을 권합니다.

대신 먼저 구조를 줍니다.

아래 사용자 흐름과 데이터 구조를 기준으로
Flutter 화면을 구현할 계획이다.

사용자 흐름:
기록 목록 → 기록 작성 → 저장 → 기록 목록 → 기록 상세

데이터:
Record
- id
- title
- content
- createdAt

현재는 UI 구현 전 단계다.

아직 코드를 작성하지 말고
각 화면에 필요한 UI 요소와
사용자 행동을 먼저 정리해줘.

MVP 범위 밖의 기능은 추가하지 마.

이렇게 하면 AI가 디자인 상상력을 펼치기 전에 제품 구조부터 맞추게 할 수 있습니다.

상상력은 나중에 써도 늦지 않습니다.

27. 비개발자에게 설계가 필요한 이유

여기까지 오면 이런 생각이 들 수 있습니다.

모든 세부 설계를 직접 할 필요는 없습니다.

AI에게 제안받아도 됩니다.

중요한 것은

AI가 제안한 구조가 우리의 요구사항과 맞는지 판단할 수 있어야 한다는 것입니다.

예를 들어 AI가 데이터 모델에

userId

를 추가했다고 해보겠습니다.

우리는 알 수 있습니다.

바로 이런 질문을 할 수 있게 됩니다.

이게 비개발자의 제품 바이브 코딩에서 굉장히 중요한 능력입니다.

코드를 직접 쓰지 않아도

구조가 요구사항과 맞는지 보는 눈

은 필요합니다.

28. 좋은 설계는 미래를 전부 예측하는 것이 아니다

설계한다고 하면 미래 기능까지 완벽하게 대비해야 할 것처럼 느껴집니다.

그럴 필요 없습니다.

"나중에 SNS가 될 수도 있으니까 팔로워 테이블도..."

"나중에 AI 기능을 넣을 거니까..."

"글로벌 서비스가 될 수도 있으니까..."

이렇게 가다 보면 다시 프로젝트가 커집니다.

현재 MyLog에서 필요한 구조는 현재 MVP를 잘 지원하면 됩니다.

Record

id
title
content
createdAt

충분합니다.

미래는 미래의 우리가 처리하겠습니다.

AI도 있을 겁니다.

아마 지금보다 더 일을 잘하겠죠. 🤖

29. 오늘 MyLog에서 확정한 사용자 흐름

이제 이번 편에서 결정한 것을 정리하겠습니다.

앱 실행

↓

기록 목록

↓

새 기록 작성

↓

제목 / 내용 입력

↓

저장

↓

기록 목록

↓

기록 선택

↓

기록 상세

Record List Screen
Record Create Screen
Record Detail Screen

Record

id
title
content
createdAt

title = 필수
content = 선택

로컬 저장

수정
삭제
검색
사진
로그인
클라우드
태그
알림
AI 기능

이제 화면과 데이터의 뼈대가 생겼습니다.

30. 오늘의 완료 조건

이번 편도 확인해보겠습니다.

[ ] MyLog의 핵심 사용자 흐름을 정했다.

[ ] 필요한 화면을 세 개로 확정했다.

[ ] 각 화면의 목적을 정의했다.

[ ] 화면마다 필요한 데이터를 정리했다.

[ ] Record 데이터 구조를 확정했다.

[ ] 빈 기록 목록 상태를 정의했다.

[ ] 제목이 없는 경우의 입력 오류 처리를 정했다.

[ ] 저장 후 이동할 화면을 결정했다.

[ ] 로컬 저장 데이터 흐름을 이해했다.

[ ] MVP 범위를 벗어난 화면과 기능을 추가하지 않았다.

여기까지 됐다면 이제 드디어 AI에게 실제 Flutter 화면을 만들어달라고 할 수 있습니다.

이번에는

가 아닙니다.

우리가 이미

어떤 화면을 만들고

어떤 데이터를 보여주며

어떻게 이동해야 하는지

알고 있습니다.

AI에게 훨씬 좋은 일을 맡길 준비가 된 것입니다.

다음 편에서는 드디어 MyLog의 첫 번째 실제 기능을 구현합니다.

기록 목록 화면,

기록 작성 화면,

기록 상세 화면을 만들고

사용자가 입력한 데이터를 화면 사이에서 이동시켜보겠습니다.

아직 영구 저장은 하지 않습니다.

일단 앱을 켜놓은 상태에서

작성 → 목록 → 상세

흐름이 제대로 이어지는지 확인합니다.

그다음 편에서 데이터를 앱을 껐다 켜도 남게 만들 겁니다.

다음 편은

[바이브 코딩 실전 #10] 첫 화면을 만들어보자 | 입력·저장·목록으로 만드는 최소 기능 앱

입니다.

이제 정말 우리가 만든 화면이 스마트폰 안에서 움직이기 시작합니다.

#01에서 "비개발자도 앱을 출시할 수 있을까?"라고 물었는데,

이제 슬슬 답을 말이 아니라 화면으로 보여줄 차례입니다. 📱✨

#바이브코딩 #VibeCoding #AI코딩 #Flutter #앱설계 #UserFlow #사용자흐름 #데이터구조 #DataModel #Wireframe #와이어프레임 #비개발자앱개발 #MVP개발 #AI에이전트 #MyLog #바이브코딩실전