I Built a Real App With AI (Copy My Prompts)
Quick Summary
I Built a Real App With AI (Copy My Prompts)를 중심으로, 기존 영양 추적 앱의 수기 입력 부담과 사진 분석 구독료를 문제로 정의하고, 음식 사진 한 장에서 칼로리·단백질·탄수화물·지방을를 핵심 판단 포인트로 압축 정리한다.
영상 보기
클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 결론
I Built a Real App With AI (Copy My Prompts)를 중심으로, 기존 영양 추적 앱의 수기 입력 부담과 사진 분석 구독료를 문제로 정의하고, 음식 사진 한 장에서 칼로리·단백질·탄수화물·지방을를 핵심 판단 포인트로 압축 정리한다.
📌 핵심 요점
- 기존 영양 추적 앱의 수기 입력 부담과 사진 분석 구독료를 문제로 정의하고, 음식 사진 한 장에서 칼로리·단백질·탄수화물·지방을 자동 기록하는 서비스를 해결책으로 삼았다.
- Idea Browser에서 검증된 단백질 추적 아이디어를 선택한 뒤 보디빌더·크로스핏 이용자·의료상 단백질 관리가 필요한 사람을 초기 고객으로 설정하고, 월 9.99달러와 7일 무료 체험을 포함한 MVP 범위를 정했다.
- 개발에 앞서 제품 맥락·기능 명세·시장 진입 전략·검증 신호를 PRD로 고정했다. 이는 개발 후반의 기능 불일치와 LLM 환각으로 인한 흐름 붕괴를 줄이는 기준점이 됐다.
- Awesome Design과 Dribbble의 검증된 화면 및 스크린샷을 시각적 레퍼런스로 제공하고, 글자 대비·카드 균형·버튼·아이콘·모션을 반복 교정해 획일적인 바이브 코딩 화면에서 벗어났다.
- React Router로 랜딩 페이지와 대시보드를 분리하고 Firebase 인증·데이터베이스와 Gemini 2.5 Flash를 연결했다. 음식 분석 결과를 구조화된 JSON으로 저장해 대시보드를 갱신하는 핵심 흐름은 약 24분 만에 작동했다.
🧩 배경과 문제 정의
- 기존 영양 추적 앱은 끼니마다 음식과 영양소를 직접 입력해야 해 번거롭고, 사진 분석 기능을 쓰려면 월 구독료까지 부담해야 한다.
- 검증된 제품 아이디어와 구체적인 프롬프트를 활용해 사진 한 장으로 칼로리·단백질·탄수화물·지방을 기록하는 앱을 한 시간 안에 구현하는 것이 목표다.
- 화면만 생성하는 수준을 넘어 제품 요구사항, 차별화된 디자인, 사용자 인증, 데이터베이스, 인공지능 이미지 분석까지 실제로 작동하는 흐름이 필요하다.
🕒 시간순 섹션별 상세정리
1. 사진 한 장으로 영양소를 계산하는 앱
- 스테이크 사진을 올리자 Gemini 2.5 Flash가 950㎉와 단백질 55g·탄수화물 90g·지방 45g을 계산하며, 별도의 수기 입력 없이 한 번에 주요 영양소를 기록한다. [00:24]
- Idea Browser로 검증된 아이디어를 찾고 Google AI Studio로 프런트엔드와 백엔드를 구현해, 전체 앱을 한 시간 안에 완성하는 범위를 잡는다. [00:50]
2. 검증된 아이디어와 MVP 범위 선택
- Idea Browser의 1,000개 이상 검증된 아이디어 가운데 인공지능 단백질 추적 서비스를 선택하며, 매일 숙제처럼 느껴지는 영양 기록과 현실 일정에 맞지 않는 정적 식단표를 핵심 문제로 삼는다. [01:20]
- 초기 고객은 보디빌더·크로스핏 이용자·의료상 단백질 관리가 필요한 사람이며, 월 9.99달러와 7일 무료 체험을 적용하고 사진 기반 음식 인식과 개인화 식단 추천을 MVP에 포함한다. [02:03]
3. PRD로 개발 기준 고정
- 제품 맥락·기능 명세·시장 진입 전략·검증 신호를 Google AI Studio에 전달하고, 이미 수익을 내는 유사 서비스 사례를 근거로 개발 방향과 사업 가능성을 구체화한다. [02:57]
- PRD는 무엇을 왜 만들고 성공을 어떻게 측정할지 먼저 고정하며, 이를 생략하면 개발이 90% 진행된 뒤 기능이 맞지 않거나 LLM의 환각으로 흐름이 무너질 위험이 커진다. [04:30]
4. 핵심 기능과 확장 기능 설계
- 핵심 기능인 AI 비전 음식 기록기는 휴대전화 카메라로 음식을 식별하고 영양소를 계산하며, 월 15달러짜리 기존 앱을 대체할 수 있는 직접적인 사용자 가치를 만든다. [05:16]
- 식료품 배송 API, Google Fitness·Apple Health 연동, 바코드 스캔을 확장 기능으로 두어 칼로리와 탄수화물·지방 등 제품별 영양 정보를 자동 입력할 수 있게 한다. [05:30]
5. 랜딩 페이지의 구조와 브랜드 기준 수립
- 랜딩 페이지는 히어로 영역·행동 유도 버튼·모션 요소를 반복 개선하고, 7일 무료 체험 같은 전환 장치와 브랜드 색상·스타일을 함께 설계한다. [06:05]
- 무료 GitHub 저장소인 Awesome Design의 Apple·Amazon·Airbnb 등 검증된 디자인 시스템을 참고해, 단순한 미적 취향이 아니라 성과가 확인된 화면 구조를 기반으로 삼는다. [06:42]
6. 텍스트보다 강한 시각적 레퍼런스 활용
- Dribbble의 피트니스 랜딩 페이지를 참고하되 그대로 복제하지 않고, 스크린샷으로 레이아웃과 분위기를 전달해 원하는 디자인 방향을 구체화한다. [07:42]
- LLM은 긴 텍스트 지시보다 여러 장의 이미지와 스크린샷에서 디자인 의도를 더 잘 파악하며, 충분한 시각적 맥락이 획일적인 바이브 코딩 화면을 벗어나는 데 도움이 된다. [09:05]
7. 첫 생성물의 한계와 기술 스택 확정
- 첫 결과물은 현대적인 컴포넌트 구조에 맞춘 브랜드 패키지와 랜딩 페이지 설계안을 만들었지만, 실제 화면보다 구현 청사진에 가까웠다. [09:56]
- GitHub 저장소를 코드 템플릿으로 처리하려던 시도는 컨텍스트 한도에 걸렸고, 후속 요청에서 Stripe·Vercel·Airbnb 등의 디자인 원칙을 담은 가이드 모음으로 다시 해석했다. [10:21]
8. 스크린샷과 구체적인 피드백으로 디자인 교정
- 첫 화면은 히어로 영역과 일부 레이아웃이 깨져 있었고, 첫 시도에서 완벽한 결과를 기대하는 대신 수집한 스크린샷을 디자인 기준으로 다시 투입했다. [12:39]
- 스크린샷 기반 결과는 피트니스 앱의 정체성이 선명해졌지만, 배경과 섞이는 글자·불균형한 카드·어색한 버튼·이모지 아이콘은 추가 수정이 필요했다. [13:18]
9. 완성도와 신뢰성을 함께 점검
- 모션과 카피를 다듬은 화면은 개인화 식단과 즉시 사진 기록이라는 제품 가치를 전면에 배치해, 단순 영양 추적기보다 인공지능 코치에 가까운 인상을 만든다. [14:43]
- 자동 생성된 가짜 후기는 방문자의 신뢰를 해칠 수 있으므로 제거하고, 실제 사용자 후기만 사용해야 한다. [15:14]
10. 백엔드 연결과 실제 음식 사진 검증
- React Router로 랜딩 페이지와 대시보드를 분리하고 Firebase 인증·데이터베이스를 연결해, 사용자가 가입하고 7일 무료 체험을 시작할 수 있는 백엔드 기반을 마련한다. [16:26]
- Gemini 2.5 Flash는 업로드한 사진에서 음식명·칼로리·단백질·탄수화물·지방을 구조화된 JSON으로 반환하고, 결과를 개인 데이터베이스에 저장해 대시보드를 실시간으로 갱신한다. [17:50]
🧾 결론
- AI 앱 개발의 속도를 결정한 것은 한 번의 막연한 요청이 아니라 검증된 문제, 명확한 MVP, PRD, 시각 자료, 구체적인 수정 피드백의 조합이었다.
- 실제 앱의 기준은 화면 생성이 아니라 가입·인증·데이터 저장·AI 분석·대시보드 갱신이 하나의 사용자 흐름으로 연결되는지에 있다.
- 첫 생성물은 구현 청사진이나 깨진 화면에 머물 수 있으므로, 사람이 결과를 검토하고 디자인과 신뢰 요소를 반복적으로 교정해야 한다.
📈 투자·시사 포인트
- Google AI Studio와 Gemini·Firebase 같은 도구는 프런트엔드부터 AI 분석과 데이터 저장까지의 MVP 제작 시간을 크게 압축해, 소규모 팀도 제품 가설을 빠르게 시험할 수 있게 한다.
- 사진 기반 영양 기록은 수기 입력을 줄이고 월 15달러짜리 기존 앱을 대체할 직접적인 가치를 제시한다. 다만 월 9.99달러와 무료 체험이 실제 결제 전환으로 이어지는지는 별도 검증이 필요하다.
- 코드 생성이 보편화될수록 차별화 요소는 생성 속도 자체보다 문제 선택, PRD의 품질, 브랜드 디자인, 실제 사용자 후기와 같은 신뢰 장치로 이동할 가능성이 크다.
- 웹 앱을 먼저 만들고 Capacitor로 모바일 앱까지 확장하는 방식은 동일한 프레임워크를 유지하면서 초기 제품의 배포 범위를 넓히는 경로를 보여준다.
⚠️ 불확실하거나 확인이 필요한 부분
- Gemini 2.5 Flash의 영양소 계산은 스테이크와 새우 팟타이 사례로만 제시됐으며, 실제 영양값과의 오차율이나 다양한 음식·양·촬영 조건에서의 정확도는 확인되지 않았다.
- 한 시간 이내 제작과 약 24분의 핵심 흐름 구현은 시연 결과일 뿐, 장기 운영에 필요한 안정성·확장성·개인 데이터 보호 수준까지 입증하지는 않는다.
- 월 9.99달러, 7일 무료 체험, 기존 수익 서비스 사례는 사업 가능성의 신호이지만 실제 전환율·유지율·수익성 데이터는 제시되지 않았다.
- 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
- 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
- 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.
✅ 액션 아이템
- 초기 고객, 반복되는 영양 기록 문제, 사진 기반 핵심 기능, 가격과 무료 체험 조건을 하나의 MVP 문서로 고정한다.
- 개발 전에 제품 목적·기능 명세·시장 진입 전략·성공 측정 기준을 포함한 PRD를 작성한다.
- 검증된 디자인 시스템과 피트니스 앱 스크린샷을 수집하고, 복제가 아닌 레이아웃·분위기·브랜드 기준을 전달하는 프롬프트 자료로 사용한다.
- 랜딩 페이지, 라우팅, 인증, 데이터베이스, 대시보드, AI 비전 기록 순서로 구현하고 각 단계의 실제 작동 여부를 확인한다.
❓ 열린 질문
- 혼합 요리, 가려진 음식, 서로 다른 양과 촬영 각도에서도 칼로리와 영양소 추정 정확도가 유지되는가?
- 월 9.99달러와 7일 무료 체험이 초기 고객군의 실제 가입·결제·장기 이용으로 이어지는가?
- 음식 사진과 개인 영양 데이터를 저장할 때 사용자별 데이터 보호와 운영 안정성을 어떤 기준으로 검증할 것인가?
