AI 네이티브 앱 제작 프로세스

 

사용자 문제 정의부터 디자인, 통합 명세, 구현, 검증까지 연결하는 실무 가이드

1. 문서 개요

목적

이 문서는 AI를 활용해 앱을 만들 때 곧바로 코드를 작성하지 않고, 사용자 문제와 제품 기준을 먼저 구체화하는 작업 절차를 설명한다. 독자는 이 절차를 따라 다음 산출물을 순서대로 만들 수 있다.

1. 사용자 문제 정의
2. design.md
3. 핵심 화면 시안
4. 통합 기획서 spec.html
5. 전체 화면 목업 design.html
6. 구현된 애플리케이션

완료 상태는 제품 요구사항, 디자인, 데이터 구조, 구현 코드가 서로 일치하고 핵심 사용자 흐름을 실행할 수 있는 상태다.

대상 독자

• AI 코딩 도구로 웹 또는 모바일 앱을 만들려는 기획자와 개발자
• 제품 아이디어를 실제 서비스 명세로 구체화하려는 1인 개발자
• AI가 생성한 화면과 코드를 검수해야 하는 제품 책임자

범위

이 문서는 제품 기획과 제작 순서를 다룬다. 특정 AI 도구의 설치 방법, 명령어, 요금, 배포 환경 설정은 다루지 않는다.

미검증 범위: 이 문서는 사용자가 제공한 영상 요약을 기술 문서 형식으로 재구성한 것이다. 영상 원본, 도구의 현재 기능, 실제 구현 결과는 별도로 검증하지 않았다.

---

2. 핵심 원칙

AI 네이티브 앱 제작의 핵심은 코딩 속도가 아니라 AI가 판단할 수 있는 기준을 먼저 제공하는 것이다. 전체 흐름은 다음과 같다.

아이디어
→ 사용자 문제 정의
→ 디자인 원칙 수립
→ 핵심 화면 탐색
→ 제품·디자인·기술 명세 통합
→ 전체 화면과 상태 설계
→ 구현 전 질의응답
→ 실제 개발
→ 검증과 반복 수정
→ 명세·디자인·코드 동기화
→ 배포

이 과정에서 AI는 여러 대안을 빠르게 생성한다. 사람은 해결할 문제, 디자인의 취향, 기능의 우선순위, 데이터 구조와 최종 품질 기준을 결정한다.

---

3. 예제 서비스: TasteMaker

TasteMaker는 영화, TV 프로그램, 게임처럼 여러 서비스에 흩어진 개인 취향을 한 페이지에 정리하고 공유하는 프로필 서비스다.

사용자 문제

영화, TV 프로그램, 게임 기록이 서로 다른 서비스에 나뉘어 있어 사용자가 자신의 취향 전체를 한 페이지로 보여주기 어렵다.

주요 기능

• 좋아하는 영화·TV 프로그램·게임 표시
• 최근 리뷰와 별점 표시
• 사용자가 만든 콘텐츠 목록 관리
• 공개 프로필 공유
• 회원가입과 온보딩
• 콘텐츠 추가·수정·정렬

이 예제는 이후 단계에서 어떤 산출물을 만들어야 하는지 설명하기 위한 기준으로 사용한다.

---

4. 단계별 제작 절차

4.1 사용자 문제 정의

목표

기능 목록을 작성하기 전에 제품이 해결할 사용자 문제를 한 문장으로 정의한다.

작성 항목

• 이 제품을 사용할 사람은 누구인가?
• 사용자는 현재 어떤 상황에서 불편을 겪는가?
• 기존 해결 방법은 왜 충분하지 않은가?
• 제품을 사용한 뒤 무엇이 달라져야 하는가?

사업화를 전제로 한다면 다음 항목도 조사한다.

• 실제로 같은 문제를 겪는 사용자가 있는가?
• 직접 또는 간접 경쟁 서비스는 무엇인가?
• 사용자가 비용을 지불할 가능성이 있는가?
• 지속 가능한 수익 모델을 구성할 수 있는가?

개인용 앱이나 내부 도구는 시장성 조사를 줄일 수 있지만, 사용자와 완료 상태는 명확히 정의해야 한다.

산출물 예시

[대상 사용자]는 [현재 상황]에서 [문제]를 겪는다.
기존에는 [대체 방법]을 사용하지만 [한계]가 있다.
이 제품은 [핵심 가치]를 제공해 [기대 결과]를 만든다.

완료 기준

• 특정 기능명을 사용하지 않고도 문제를 설명할 수 있다.
• 대상 사용자와 사용 상황이 드러난다.
• 제품이 제공할 변화가 한 문장으로 정리된다.
• 사업용 제품이라면 경쟁 서비스와 지불 가능성을 조사할 계획이 있다.

---

4.2 디자인 레퍼런스 수집과 design.md 작성

목표

“예쁘게 만들어 달라”는 추상적인 요청을 시각적 기준과 구현 가능한 디자인 규칙으로 바꾼다.

절차

1. Mobbin, Dribbble, 실제 앱 화면 등에서 레퍼런스를 수집한다.
2. 각 레퍼런스에서 채택할 요소와 제외할 요소를 구분한다.
3. 제품의 콘텐츠와 사용 맥락에 맞는 디자인 원칙을 정한다.
4. 결정한 내용을 design.md에 기록한다.

레퍼런스는 방향을 찾는 자료로만 사용하고 화면을 그대로 복제하지 않는다.

design.md 권장 구조

# Design Direction

## Design Principles
- 콘텐츠가 인터페이스보다 먼저 보이게 한다.
- 장식 요소는 사용자의 판단을 방해하지 않는 범위에서 사용한다.

## Color
- 배경색:
- 기본 텍스트:
- 보조 텍스트:
- 강조색:
- 상태 색상:

## Typography
- 제목:
- 본문:
- 보조 정보:

## Spacing and Layout
- 기본 간격 단위:
- 최대 콘텐츠 너비:
- 카드 간격:

## Components
- 버튼:
- 카드:
- 입력창:
- 모달 및 시트:

## Content Density
- 한 화면에 노출할 정보량:
- 모바일 축약 규칙:

TasteMaker의 디자인 방향은 인터페이스를 조용하고 단순하게 유지하고, 영화와 게임의 커버 이미지가 화면의 주요 색상을 담당하게 하는 것이다.

완료 기준

• 색상, 타이포그래피, 간격, 카드와 버튼 규칙이 정의되어 있다.
• 레퍼런스에서 가져올 원칙과 복제하지 않을 요소가 구분되어 있다.
• AI가 서로 다른 화면에서도 같은 시각 언어를 적용할 수 있다.

---

4.3 핵심 화면 탐색

목표

전체 화면을 만들기 전에 제품의 가치와 디자인 방향을 가장 잘 보여주는 화면 두 개를 설계한다.

TasteMaker에서는 다음 화면을 먼저 만든다.

1. 비로그인 사용자가 보는 랜딩 페이지
2. 영화·TV 프로그램·게임 취향을 보여주는 공개 프로필

절차

1. design.md와 사용자 문제를 AI 디자인 도구에 제공한다.
2. 서로 다른 레이아웃과 테마의 시안을 요청한다.
3. 각 시안을 콘텐츠 우선순위와 사용성 기준으로 비교한다.
4. 적합한 방향을 하나 선택한다.
5. 불필요한 요소를 제거하고 배치, 밀도, 문구를 반복 수정한다.

시안 변형 예시는 다음과 같다.

• 행 중심 레이아웃
• 그리드 중심 에디토리얼 레이아웃
• 라이트 모드
• 다크 모드

피드백 작성 원칙

“더 예쁘게”처럼 평가 기준이 없는 표현보다 대상과 변경 내용을 함께 적는다.

[대상 화면 또는 컴포넌트]에서
[현재 문제]가 있으므로
[구체적인 변경]을 적용한다.
[변경 후 확인할 기준]은 다음과 같다.

예:

• 사용하지 않는 팔로우 버튼을 삭제한다.
• 즐겨찾기 콘텐츠를 한 행에 6개 배치한다.
• 콘텐츠 행에 좌우 이동 버튼을 추가한다.
• 리뷰는 작은 카드 그리드 대신 전체 너비의 한 줄 구조로 표시한다.
• 공개 프로필 왼쪽에 섹션 빠른 이동 메뉴를 배치한다.
• 랜딩 페이지에서 실제 공개 프로필 예시를 크게 보여준다.

완료 기준

• 선택한 화면이 제품의 핵심 가치를 설명한다.
• 콘텐츠 우선순위와 화면 밀도가 정리되어 있다.
• 두 핵심 화면이 같은 컴포넌트와 시각 규칙을 사용한다.
• 선택하지 않은 시안과 선택 이유를 기록했다.

---

4.4 통합 기획서 spec.html 작성

목표

제품 요구사항, 디자인 시스템, 기술 설계를 하나의 기준 문서로 통합한다.

spec.html은 최소한 Product, Design, Tech의 세 영역으로 구성한다.

Product 영역

• 사용자 문제와 대상 사용자
• 제품 목표와 성공 기준
• 핵심 기능과 우선순위
• 화면별 요구사항
• 기본 상태와 예외 상태
• 사용자 권한과 접근 범위

Design 영역

• 디자인 원칙
• 색상과 타이포그래피
• 간격과 레이아웃 규칙
• 공통 UI 컴포넌트
• 컴포넌트별 상태와 사용 규칙
• 반응형 동작

Tech 영역

• 프런트엔드와 백엔드 기술
• 인증 방식
• 데이터베이스
• 데이터 스키마와 관계
• 외부 API와 의존성
• 오류 처리와 로딩 전략
• 구현 제약과 미결정 사항

공통 컴포넌트 정의

컴포넌트마다 다음 항목을 기록한다.

항목설명

이름	코드와 디자인에서 공통으로 사용할 이름
목적	사용자가 이 컴포넌트로 수행하는 작업
변형	크기, 강조 수준, 용도별 형태
상태	기본, 호버, 포커스, 비활성, 로딩, 오류
콘텐츠 규칙	허용 길이, 줄바꿈, 생략 방식
접근성	키보드 조작, 레이블, 대비 등

데이터 스키마 정의

데이터 모델마다 다음 항목을 명시한다.

• 엔터티 이름과 역할
• 필드명, 데이터 형식, 필수 여부
• 고유값과 기본값
• 엔터티 간 관계
• 생성·수정·삭제 규칙
• 공개 정보와 비공개 정보
• 정렬과 검색에 필요한 인덱스

스키마가 확정되지 않은 항목은 추정하여 채우지 않고 미결정으로 표시한 뒤 구현 전에 질문한다.

완료 기준

• 모든 핵심 기능이 특정 화면 또는 사용자 흐름에 연결된다.
• 공통 컴포넌트의 이름과 상태가 정의되어 있다.
• 데이터 스키마가 화면의 입력·출력과 연결되어 있다.
• 미결정 사항과 결정 책임자가 구분되어 있다.

---

4.5 전체 화면과 상태 설계

목표

정상 상태뿐 아니라 실제 사용 중 나타날 수 있는 빈 화면, 오류, 권한, 긴 콘텐츠와 작은 화면까지 설계한다.

TasteMaker의 화면 목록

• 랜딩 페이지
• 공개 프로필
• 본인 프로필 편집
• 콘텐츠 추가
• 리뷰 작성·수정
• 전체 영화·게임 목록
• 콘텐츠 상세 시트
• 회원가입과 온보딩
• 사용자 핸들 선택
• 좋아하는 콘텐츠 6개 선택
• 프로필 공유

화면별 필수 상태

상태	확인할 내용
기본	대표 데이터가 있을 때의 정상 화면
빈 화면	데이터가 없을 때의 안내와 다음 행동
최초 가입	사용자가 처음 진입했을 때의 안내
로딩	대기 중인 영역과 사용자 조작 가능 범위
오류	오류 설명, 재시도, 안전한 이탈 방법
검색 결과 없음	검색어 수정 또는 초기화 방법
저장 전·후	미저장 변경과 저장 성공 여부
권한 없음	접근 제한 이유와 가능한 다음 행동
긴 콘텐츠	긴 제목, 리뷰, 사용자 이름 처리
작은 화면	모바일 배치, 축약, 탐색 방식

화면 명세 템플릿

화면 이름:
사용자 목표:
진입 조건:
주요 데이터:
주요 행동:
공통 컴포넌트:
정상 상태:
빈 상태:
로딩 상태:
오류 상태:
권한 조건:
모바일 규칙:
완료 조건:

완료 기준

• 모든 핵심 사용자 흐름에 시작점과 종료점이 있다.
• 각 화면에 필요한 데이터와 사용자 행동이 정의되어 있다.
• 빈 상태, 로딩, 오류, 권한 없음 상태를 확인했다.
• 긴 콘텐츠와 모바일 화면에서 레이아웃이 깨지지 않는 기준이 있다.

---

4.6 구현 전 검토와 실제 개발

목표

코딩 에이전트가 임의로 결정해야 하는 부분을 줄이고, 합의된 명세와 디자인을 코드로 옮긴다.

입력 파일

• spec.html: 제품, 디자인, 기술 요구사항
• design.html: 전체 화면과 상태의 목업

구현 전 요청 예시

spec.html과 design.html을 검토하세요.
아직 구현하지 말고, 두 문서가 충돌하거나 구현에 필요한 정보가
빠진 부분을 질문 목록으로 정리하세요.

각 질문에는 다음 내용을 포함하세요.
1. 관련 화면 또는 요구사항
2. 현재 모호한 점
3. 결정하지 않았을 때 구현에 미치는 영향
4. 선택 가능한 대안

구현 순서

1. 코딩 에이전트의 질문에 답하고 미결정 사항을 확정한다.
2. 핵심 사용자 흐름부터 수직으로 구현한다.
3. 로컬 환경에서 화면과 동작을 확인한다.
4. 디자인과 다른 부분, 누락 기능, 상태 처리를 수정한다.
5. 인증과 데이터베이스를 연결한다.
6. 실제 데이터의 생성, 조회, 수정, 삭제를 확인한다.
7. 변경된 요구사항을 spec.html과 design.html에 반영한다.

검수 항목

• 리뷰 영역 등 필수 콘텐츠가 빠지지 않았는가?
• 카드의 호버 상태처럼 상호작용 조건이 디자인과 일치하는가?
• 좌우 이동, 정렬, 필터 등 탐색 동작이 요구사항과 일치하는가?
• 여백, 글꼴, 정렬, 반응형 동작이 디자인과 일치하는가?
• 인증 상태에 따라 접근 권한이 올바르게 달라지는가?
• 입력한 데이터가 실제 데이터베이스에 저장되고 다시 조회되는가?

완료 기준

• 구현 전 질문에 답했으며 남은 미결정 사항이 표시되어 있다.
• 핵심 사용자 흐름을 로컬 환경에서 처음부터 끝까지 실행할 수 있다.
• 요구사항, 디자인, 구현의 차이를 기록하고 해소했다.
• 코드 변경으로 요구사항이 달라졌다면 문서도 함께 갱신했다.

---

5. 산출물 간 추적 관계

각 산출물은 독립 문서가 아니라 다음 단계의 입력이다.

산출물	포함할 내용	다음 단계에서의 용도
문제 정의	사용자, 상황, 문제, 기대 변화	기능과 우선순위 판단
design.md	디자인 원칙과 시각 규칙	핵심 화면 시안 생성
핵심 화면	선택한 레이아웃과 콘텐츠 구조	상세 요구사항 발견
spec.html	제품·디자인·기술 명세	전체 화면 설계와 구현 기준
design.html	전체 화면과 상태	구현 결과의 시각적 기준
애플리케이션 코드	실제 동작	테스트와 배포 대상

요구사항이 바뀌면 영향을 받는 산출물을 함께 수정한다. 예를 들어 프로필에서 즐겨찾기 개수가 6개에서 8개로 바뀌었다면 Product 요구사항, 컴포넌트 규칙, 화면 목업, 데이터 검증 규칙과 구현 코드를 모두 확인한다.

---

6. 단계별 품질 게이트

다음 단계로 넘어가기 전에 각 질문에 답한다.

문제 정의 완료

• 대상 사용자가 구체적인가?

• 사용 상황과 문제가 한 문장으로 설명되는가?

• 기능이 아니라 사용자의 변화를 중심으로 작성했는가?

디자인 방향 완료

• 레퍼런스의 채택·제외 기준이 있는가?

• 색상, 글꼴, 간격, 컴포넌트 원칙이 있는가?

• 제품 콘텐츠가 시각적 장식보다 우선하는가?

핵심 화면 완료

• 최소 두 가지 이상의 대안을 비교했는가?

• 선택 이유를 설명할 수 있는가?

• 불필요한 요소를 제거했는가?

통합 명세 완료

• 기능이 화면과 사용자 흐름에 연결되는가?

• 공통 컴포넌트와 상태가 정의되어 있는가?

• 데이터 스키마와 권한 규칙이 정의되어 있는가?

• 미결정 사항을 질문 목록으로 분리했는가?

전체 디자인 완료

• 정상·빈·로딩·오류 상태가 있는가?

• 권한 없음과 검색 결과 없음 상태가 있는가?

• 긴 콘텐츠와 모바일 화면을 확인했는가?

구현 완료

• 핵심 흐름을 실제로 실행했는가?

• 저장한 데이터를 다시 조회할 수 있는가?

• 명세와 디자인의 차이를 수정했는가?

• 변경된 코드와 문서를 동기화했는가?

---

7. 자주 발생하는 실패와 대응

추상적인 디자인 요청

증상: 화면마다 전형적인 색상과 구성요소가 반복되고 제품의 개성이 드러나지 않는다.

확인: design.md에 콘텐츠 우선순위, 제외할 스타일, 컴포넌트 규칙이 있는지 점검한다.

대응: 실제 레퍼런스에서 채택할 원칙을 뽑고 색상, 간격, 밀도와 컴포넌트 상태를 명시한다.

첫 번째 시안을 완성품으로 사용

증상: 불필요한 버튼, 배지, 문구가 남고 콘텐츠 구조가 사용자 목표와 맞지 않는다.

확인: 서로 다른 구조의 대안을 비교했는지, 삭제 중심의 피드백을 진행했는지 확인한다.

대응: 레이아웃 대안을 만든 뒤 콘텐츠 우선순위, 정보 밀도와 사용자 행동을 기준으로 하나를 선택한다.

정상 화면만 설계

증상: 실제 데이터가 없거나 오류가 발생했을 때 화면과 다음 행동이 정의되지 않는다.

확인: 화면 명세에 빈 상태, 로딩, 오류, 권한과 모바일 항목이 있는지 확인한다.

대응: 상태 매트릭스를 만들고 각 상태의 메시지, 행동과 복구 경로를 정의한다.

화면마다 다른 컴포넌트 생성

증상: 같은 역할의 버튼과 카드가 화면마다 다른 크기, 색상, 동작을 사용한다.

확인: 컴포넌트 이름, 변형과 상태가 spec.html에 정의되어 있는지 확인한다.

대응: 공통 컴포넌트 목록을 만들고 디자인과 코드에서 같은 이름을 사용한다.

문서와 코드 불일치

증상: 구현은 변경됐지만 명세나 목업에는 이전 동작이 남아 있다.

확인: 변경 사항이 제품 요구사항, 디자인, 데이터와 코드 중 어디에 영향을 주는지 추적한다.

대응: 구현 작업의 완료 조건에 관련 문서 갱신을 포함한다.

---

8. 운영 원칙

기획에 충분한 시간 배정

제공된 영상은 전체 제작 시간의 최소 50%를 사전 기획에 투자하라고 제안한다. 이 비율은 이 문서에서 독립적으로 검증하지 않았다. 실무에서는 데이터베이스 구조, 인증 방식, 화면 구조, 핵심 사용자 흐름과 공통 컴포넌트처럼 변경 영향이 큰 결정을 구현 전에 우선 검토한다.

구체적인 반복 피드백

AI의 첫 결과는 검토할 초안으로 취급한다. 피드백에는 대상, 문제, 변경 내용과 확인 기준을 포함한다. 시각적 취향만 말하지 않고 사용자 목표와 제품 원칙을 근거로 판단한다.

단일 기준 문서 유지

spec.html과 design.html을 구현의 기준으로 사용한다. 코드에서 요구사항이 바뀌면 관련 문서도 같은 작업 범위에서 수정한다. 문서와 코드가 충돌하면 어느 쪽이 최신 결정인지 확인한 뒤 한쪽을 임의로 덮어쓰지 않는다.

---

9. 최종 완료 정의

다음 조건을 모두 충족하면 제작 프로세스가 완료된 것으로 판단한다.

• 해결할 사용자 문제와 대상 사용자가 명확하다.
• 선택한 디자인 방향과 선택 이유가 문서화되어 있다.
• 전체 기능, 화면, 상태, 컴포넌트와 데이터 스키마가 정의되어 있다.
• 구현 전에 모호한 요구사항을 질문하고 결정했다.
• 핵심 사용자 흐름이 실제 환경에서 동작한다.
• 빈 상태, 로딩, 오류, 권한과 모바일 화면을 검증했다.
• 명세, 디자인과 코드가 같은 요구사항을 반영한다.
• 배포 전 테스트 결과와 남은 미검증 항목이 기록되어 있다.

10. 결론

AI 네이티브 앱 제작은 AI에게 한 번의 명령으로 완성품을 요청하는 과정이 아니다. 사용자 문제를 정의하고, 디자인의 판단 기준을 만들고, 핵심 화면으로 제품 구조를 탐색한 뒤, 제품·디자인·기술 명세를 구현 가능한 수준으로 연결하는 과정이다.

AI는 대안 생성과 구현 속도를 높이는 역할을 맡는다. 사람은 어떤 문제를 해결할지, 어떤 화면이 더 적합한지, 무엇을 삭제할지, 어떤 데이터 구조와 품질 기준을 채택할지 결정한다. 따라서 최종 품질은 코드 생성 속도뿐 아니라 기획, 디자인 판단, 명세 작성과 검수 능력에 달려 있다.