프롤로그 이야기
이전 글에서는 퇴사 후 머릿속에만 있던 아이디어를 실제로 구현하기로 결심한 배경을 다뤘다. 문예창작을 전공하고 콘텐츠 마케팅을 해온 내가 왜 앱을 만들기로 했는지, MVP 범위를 어떻게 좁혔는지, 그리고 "요리의 감정과 맥락을 기록하는 공간"이라는 컨셉이 어떻게 정리됐는지 이야기했다.
이번 Episode 1에서는 본격적으로 기술 스택을 선정하고 초기 설계를 진행한 과정을 다룬다.
최소한, 필수적인
기획 문서를 쓰면서 이 앱에 꼭 필요한 기능 4가지가 자연스럽게 정리됐다.
1. 레시피 작성 및 감정 메모 기록
"요리 방법뿐만 아니라 왜 만들었는지, 누구를 위해 만들었는지 함께 기록하기."
- 작성 화면에
emotionalStory필드 추가 - 감정 상태를 Enum 타입으로 정의
#파티#혼밥#기념일등 감성 중심 태그 입력
2. AI 분석 및 자동 기록
"필요에 따라 AI로 분석하거나 레시피 추천받기."
- 기능과 토큰 비용을 고려해 AI 모델 선정
- 클라이언트는 프록시 토큰만 사용
- 재료, 소스, 조리법 분기 프롬프트와 모델 작업
3. 마일스톤과 게이미케이션
"요리 견습생 토끼 캐릭터가 성장하는 감성 게임적 요소로 동기부여하기"
- 레시피 저장 진행률 계산 → 레벨업·언락 팝업
- 감정 메모·태그 활용한 마일스톤 조건 정의
- 진행 상태 로컬 저장, 오프라인에서 여정 지속
기술 스택 선정 이유

왜 Flutter를 선택했을까?
비개발자가 기술 스택을 선택하는 과정은 쉽지 않다. 나는 바이브 코딩 강의에서 추천받은 플러터+하이브 구조를 택했다.(툴 후기는 여기) 그리고 다른 옵션들과 어떤 차이점이 있는지 궁금해져서 더 알아봤다. 우선 Flutter부터.
- Hot Reload로 1초 내 변경사항 확인
- 크로스 플랫폼으로 iOS/Android 동시 개발
- Dart 단일 언어로 학습 부담 최소화
- 풍부한 위젯과 패키지
기술 스택 비교
| 항목 | Flutter | React Native | Swift/Kotlin |
|---|---|---|---|
| 크로스 플랫폼 | iOS/Android 동시 지원 | iOS/Android 동시 지원 | 각각 별도 개발 필요 |
| 개발 속도 | 매우 빠름 | 빠름 | 느림 |
| Hot Reload | 지원 | 지원 | 느림 |
| 학습 곡선 | Dart 단일 언어 | JavaScript + 일부 네이티브 | Swift와 Kotlin 모두 학습 |
| 비개발자 진입 | 중간 난이도 | JavaScript 지식 필요 | 전문 개발자 필수 |
| 한달 완성 가능성 | 높음 | 높음 | 낮음 |
비교해보니 더 적합했던 Flutter
- 1인 개발에 최적화: iOS/Android 동시 개발
- 빠른 MVP: 핫 리로드로 시행착오 시간 단축
- 풍부한 생태계: pub.dev에 5만+ 패키지 활용
왜 Hive일까?
하이브는 로컬에 데이터를 JSON으로 저장하는 NoSQL 구조라 직관적이고 오프라인 우선 설계에 최적화되어있다. 한 마디로 초보자가 DB 구축하기에 진입장벽이 낮음!
- Flutter 공식 추천 로컬 DB 중 하나
- iOS/Android에서 모두 작동
- 데이터가 JSON으로 저장돼 구조 이해 쉬움
- 복잡한 테이블 설계, 마이그레이션 고민 불필요
데이터 베이스 비교
| 기준 | Hive | Firebase | SQLite |
|---|---|---|---|
| 설정 복잡도 | 매우 간단 | 복잡 (Cloud 설정) | 중간 |
| 로컬 저장 | 완벽 | 클라우드 기반 | 완벽 |
| 속도 | 매우 빠름 | 네트워크 의존 | 빠름 |
| 비용 | 무료 | 사용량 따라 과금 | 무료 |
| Flutter 통합 | 완벽 | 좋음 | 보통 |
| MVP 적합성 | 완벽 | 오버스펙 | 적합 |
비교해보니 더 적합했던 Hive
Firebase는 사용자 계정이 없는 로컬 기반 MVP에 어울리지 않고 플러터 연동하기에 SQLite보다 Hive가 적합했다. 설치 5분 만에 끝나고 NoSQL 구조라 스키마 변경도 자유로웠다.
결론, 초보자에게 추천하는 Flutter + Hive 조합
- 빠른 프로토타이핑 가능
- 로컬 우선 앱 만들기 최적화
- 초보자도 비교적 쉽게 접근 가능한 스택
실제로 개발하면서 이 조합의 장점을 체감했다. 특히 중간에 데이터를 클라우드화하는 시도를 했을 때 Hive Box에 데이터를 저장하는 코드 구현이 비교적 간단한 편이었음을 깨달았다. 디버깅하느라 예상보다 시간을 많이 썼지만 그 시행착오 덕분에 구조를 더 잘 이해하게 됐다.
그리고 앱 심사 제출 시 꼭 챙겨야 할 것! 지원 및 개인정보처리방침 같은 정책 문서 작업 시 와닿았던 장점도 적어본다.
로컬 데이터베이스 채택 시 운영과 정책상 메리트
- 운영 비용 및 유지보수 리소스 축소
- API 보안 강화 및 상태 처리 간소화
- 앱스토어 심사 정책 관련 작업 용이
이후 클라우드 백업이나 알림을 붙일 때는 필요한 정책·보안 체크리스트를 준비해야한다.
AI 기능은 필수
AI 기능은 요즘 서비스들의 핵심 경쟁력 중 하나다. 나는 특히 블로그 레시피를 요약해서 나만의 킥을 정리해두고 싶은 니즈가 있었다. 그 외에 사진 분석이나 키워드로 레시피 생성 등도 필요했다. 직접 API 호출당 예상 비용과 AI 모델 성능을 비교해봤을 때 비전 기능까지 있으면서도 토큰 비용이 합리적인 모델은 4o-mini여서 이걸로 결정했다.
- GPT-4o-mini: 텍스트, 이미지 분석 가능
- 한국어 지원: OCR도 되고 레시피 분석도 무난
- 빠른 응답: 대기 시간 3-5초 정도로 길지 않음
API key 보안
설계 및 개발 단계에서는 로컬 env로 기능 구현 위주로 테스트했고, API 기능 완료 후 프록시 설정으로 전환했다.
사용자 앱 → 프록시 서버 (API 키 보관) → OpenAI API
- 앱에는 임시 토큰만 저장, API 키는 서버에만
- 릴리즈 빌드 전
.env파일 제거 필수 체크
처음에 다른 방법도 시도해보았는데 그건 더 돌아서 가는 길이었다. 새로운 교훈을 얻으며 보안상 필수였던 과정도 마무리되었다.(에피소드 5정도에서 다룰 예정)
프록시가 필수인 이유
- 앱에 직접 OpenAI API Key를 넣으면 리버스 엔지니어링으로 키가 노출됨
- 악의적 사용자가 APK/IPA 파일을 디컴파일해서 키를 추출할 수 있음
- 추출된 키로 무제한 API 호출 시 예상치 못한 과금 폭탄 가능
초기 설계 과정

기획 방향에 맞춘 Recipe 모델
단순한 메모장이 아닌 아카이빙 앱을 만들고자 했던 방향에 맞춰 레시피 작성 화면을 구성했다.
class Recipe {
String id;
String title; // 요리 이름
String emotionalStory; // 이게 핵심! 왜 만들었는지의 이야기
List<Ingredient> ingredients; // 재료들
List<String> instructions; // 만드는 방법
String? localImagePath; // 사진 (있으면)
List<String> tags; // #태그들
DateTime createdAt; // 언제 만들었는지
Mood mood; // 그때의 감정
int? rating; // 맛있었는지 (별점)
}
emotionalStory레시피 메타데이터로 감정 메모 저장Mood감정 상태를 8가지 Enum으로 구조화 (기쁨, 슬픔, 평온...)
감정의 포맷화
텍스트로 "기쁨", "슬픔" 저장하면 오타가 날 수 있어서 나중에 통계 낼 때 불편할 것 같았다. 감정은 Mood enum으로 고정하고 아이콘 키·국문·영문 이름을 함께 저장하도록 설계해 UI와 검색에서 동일한 값을 재사용했다.
- 감정 아이콘 키도 저장돼 UI에서 바로 사용
- 이후 특정 감정의 레시피만 모아볼 때 편리
- 오타 걱정 없음!
컨셉 덕분에 빠르게 정한 디자인
아이보리 & 올리브 그린 테마 선택
내가 만들고 싶었던 건 조용히 기록하는 공간이었기에 강렬한 색보다 차분한 톤이 어울리겠다는 생각이 들었다. 최종적으로 아이보리와 올리브의 조합을 선택했다.
그리고 아이템 초기부터 잡아두었던 컨셉 키워드로 '아날로그, 동화적인, 빈티지 레시피북, 햇살이 내리쬐는 정원의 채소와 야채' 등으로 있었고, 레퍼런스 이미지들까지 수집해 폴더링해두었던 상태여서 빠르게 정리됐다.
primaryColor: #8B9A6B // 연한 올리브 그린
backgroundColor: #FAF8F3 // 아이보리 백그라운드
cardColor: #F8F6F1 // 따뜻한 아이보리
accentOrange: #D2A45B // 빈티지 오렌지 (포인트)
textPrimary: #2E3D1F // 다크 올리브 (텍스트)
화면 구조, 고민될 땐 레퍼런스를
바텀 네비게이션을 4개로 할지, 5개로 할지 고민했다. 프로토타입으로 5개 탭을 구현해놓고 "모바일 특성상 탭이 너무 많은가?"싶어서 다른 분야의 평소 자주 쓰는 앱들을 리서치해보았다. 평균 3-5개 정도의 탭을 사용하고 있어서 나는 아래처럼 정했다.
5개 탭 Bottom Navigation
├── 홈 (최근 레시피)
├── 검색 (감정/태그로 찾기) *추후 토끼굴로 대체
├── 통계 (요리 패턴 분석)
├── 보관함 (폴더별 정리)
└── 설정 (백업/설정)
스켈레톤 수준으로 아직 뼈대만 잡아둔 상태. 이후 검색 탭은 보관함에 통합시키고 '토끼굴'이라는 마일스톤 기능으로 대체했다.
FAB 버튼, 스피드 다이얼 메뉴
빈티지 오렌지 색으로 눈에 띄게 만들었다. 제일 많이 쓸 "레시피 작성" 버튼이니까 확 보이게 해뒀다. 그리고 어느 화면에서든 FAB 버튼이 최상위 레이어에 자리하도록 설정했다. 초기에는 아래처럼 4가지 스피드 다이얼 메뉴가 있었고 이후 냉장고 재료 입력 기능 등을 붙여서 최종 5개가 되었다.
- 퀵레시피 작성하기
- 링크로 가져오기
- 사진으로 가져오기
- 나만의 레시피 작성하기
마무리하며
아이디어 단계부터 컨셉을 분명하게 정해두니 기술 스택 선정이든 디자인이든 빠르게 결정할 수 있었다. 범위를 제한하고 필요한 만큼만 작업했기에 포기하지 않고 앱을 완성할 수 있었다. 기획 단계는 기존에 머릿속에 구상해둔 게 있다 보니 나름 스무스하게 흘러갔다.
하지만 다음 에피소드에 나올 개발 단계부터는 막히는 부분이 많았다. 그래도 모든 시행착오 끝에 앱이 실제로 작동하고, 앱스토어에 등록된 화면을 봤을 때의 뿌듯함은 이루 말할 수 없었다.
이번 프로젝트는 '일단 출시'가 목표였지만, 향후에는 이 앱이든 다른 서비스든 실제 사용자 반응을 기반으로 수익화 방향도 천천히 탐색할 계획이다.
이번 에피소드 핵심 요약
MVP 핵심 기능
- 감정 메모와 함께 레시피 기록
- AI 요약 및 분석
- 자유로운 재료·방법 입력 + 태그
기술 스택
- Flutter: 크로스 플랫폼, 빠른 개발
- OpenAI API: GPT-4o-mini
- Hive: 심플한 NoSQL 로컬 저장
- Provider: 최대한 심플한 상태 관리
- 로컬 DB: 사용자 데이터는 기기에만
디자인
- 빈티지 아이보리 테마: 따뜻하고 감성적
- Bottom Navigation: 5탭 구조
- 감정 중심 UI: 이모지, 색상 팔레트
그렇게 며칠만에 앱의 첫 버전을 완성했다.
다음 이야기, Episode 2 예고편
"앱이 작동하네..? 이게 진짜 내가 만든 거 맞아...?"
- 24시간 개발 타임라인: 새벽부터 밤까지
- OpenAI API 연동: 요리 사진도 분석!
- 레시피 CRUD: 작성/저장/목록/삭제까지
- 문서 작성의 힘: 과거의 나와 대화하는 기분
가장 중요한 부분은 AI 연동 과정이었다.
다음 편에서 계속...