https://www.gpters.org/nocode/post/have-create-web-app-66ISTdyf5wC93UC
하다보니 claude code까지 오게 되었네요. 3주차 사례 발표 후 받은 여러가지 피드백을 받았습니다.
크로노타입 설문의 문항 수가 너무 적어서 정확하지 않을 것 같다. - 문항 수를 늘려라
시간 입력이 너무 귀찮으니 말로 쉽게 하거나 슬라이드로 하면 어떻겠냐
사용성을 높여봐라 .
피드백을 바탕으로 수정을 시작했습니다.
제대로된 웹앱을 만들어보자!
진행 방법
피드백을 바탕으로 좀 더 나은 수면 웹앱을 만들기 위해 Claude랑 Gemini를 많이 귀찮게 했습니다.
역시나 claude는 사용제한에 걸려서 기본만 만들고 Gemini로 주로 코드를 짰습니다.
처음에는 제가 처음 바이브코딩을 해보는 것이라 지피터스에서 배운대로 PRD 문서로 저의 의도를 전달을 하고 코드를 짜도록 했는데 하다보니 800줄이 넘는 코드를 내가 요청하 는 수정을 거칠때마다 처음부터 다시 짜는 것이었습니다.
그러다가 갑자기 이거 페이지별로 나눠서 해야 수정이나 관리가 편하다는 예전에 배운 기억이 떠올랐습니다.
첨부터 그렇게 했어야했는데 참 공부를 띄엄띄엄해서 시간 낭비를 좀 했습니다.
그래서 Gemini가 만들어 준 코드를 Claude에게 주고 나누어 달라고 요청 했습니다.
claude가 아래 처럼 구조를 짜서 기존 코드를 분리했습니다.
sleep-tracker/
├── index.html (메인 HTML)
├── styles/
│ └── main.css (모든 스타일)
├── js/
│ ├── main.js (메인 진입점)
│ ├── firebase-config.js (Firebase 설정)
│ ├── data/
│ │ ├── questions.js (설문 데이터)
│ │ └── chronotypes.js (크로노타입 데 이터)
│ ├── utils/
│ │ ├── auth.js (인증 관련)
│ │ ├── database.js (데이터베이스 유틸)
│ │ └── time-picker.js (시간 선택기)
│ └── pages/
│ ├── dashboard.js (대시보드)
│ ├── survey.js (설문 페이지)
│ ├── morning-form.js (아침 기록)
│ ├── evening-form.js (저녁 기록)
│ └── history.js (기록 보기)
└── components/
└── time-picker.js (공통 컴포넌트)이때까지도 Claude code를 쓰지 않았습니다.
나누어진 코드를 구조에 맞게 다시 local 폴더에 저장할려니 귀찮아서
Claude 데스크톱의 filesystem을 활용하여 만들어달라고 했습니다.
끝까지 Code는 안 쓰고 완성해보려했으나 firebase 배포 할려면 CLI를 실행시켜야 했기야 이번 기회에 Claude code를 설치하기로 마음 먹었습니다.
어렵게 (?) 설치를 하고 아주 쉽게 실행을 하니 바로 배포가 되었습니다.
이 후 수정도 여러번 거치면서 현재는 혼자서 잘 사용하고 있습니다.
관심 있는 분들은 아래 링크에 들어가셔서 사용하시면 됩니다.
구글 로그인 하시고 25 문항의 설문을 작성하시면 본인의 크로노 타입에 맞는 수면 팁과 설정으로 사용하실 수 있습니다.
결과와 배운 점
바이브 코딩을 시작하기 전 꼭 PRD 문서 뿐 아니라 여러 기본 문서들이 있습니다.
1. 제품/기획 문서 (무엇을, 왜 만드는가?)
PRD (Product Requirements Document, 제품 요구사항 명세서): 가장 핵심적인 문서입니다. 이 제품을 왜 만드는지(배경), 누구를 위한 것인지(타겟 유저), 어떤 문제를 해결하는지(목표), 그리고 어떤 기능들(Features & User Stories)이 포함되어야 하는지를 상세히 정의합니다. 모든 팀원이 동일한 목표를 보도록 기준을 잡아줍니다.
User Personas (사용자 페르소나): 우리 제품을 사용할 가상의 인물을 구체적으로 설정한 문서입니다. 개발자와 디자이너가 '실제 사용자가 어떻게 생각하고 행동할까?'를 끊임없이 상기하며 의사결정을 내리도록 돕습니다.
경쟁 분석 및 시장 조사 자료: 우리 제품이 시장에서 어떤 위치에 있으며, 경쟁 제품 대비 어떤 강점과 약점을 가질지 분석한 자료입니다.
2. 디자인/UX 문서 (어떻게 보이고, 어떻게 작동하는가?)
User Flow (사용자 흐름도): 사용자가 특정 목표를 달성하기 위해 앱 내에서 거치게 되는 여정(화면 이동, 버튼 클릭 등)을 시각적인 다이어그램으로 표현한 것입니다. 앱의 전체적인 뼈대를 파악할 수 있습니다.
Wireframe (와이어프레임): 색상이나 디자인 요소를 배제하고, 화면의 구조와 레이아웃, 기능 요소의 배치에만 집중한 흑백 설계도입니다. 개발 초기 단계에서 빠르게 구조를 잡고 검토하는 데 용이합니다.
UI Mockup & Prototype (UI 목업 및 프로토타입): 와이어프레임에 실제 디자인(색상, 폰트, 아이콘 등)을 입힌 것이 '목업'입니다. 여기서 더 나아가 사용자가 직접 클릭하며 실제 앱처럼 상호작용할 수 있게 만든 것이 '프로토타입'입니다. 개발자가 최종 결과물을 명확히 이해하게 해줍니다.
3. 기술/개발 문서 (어떻게 구현할 것인가?)
System Architecture Document (시스템 아키텍처/앱 구조 문서): 말씀하신 문서입니다. 프론트엔드, 백엔드, 데이터베이스, 외부 API 등이 서로 어떻게 연결되고 데이터를 주고받는지 보여주는 기술적인 청사진입니다. 개발의 큰 그림을 그리고 확장성을 고려하는 데 필수적입니다.
Technical Specification (기술 사양서): 아키텍처보다 더 상세한 기술 문서입니다. 사용할 프로그래밍 언어, 프레임워크, 라이브러리 등을 명시하고, 특히 API의 상세한 명세(Endpoints, Request/Response 형식 등)와 데이터베이스 스키마(테이블 구조) 등을 정의합니다.
API Documentation: 외부 서비스를 연동하거나, 프론트엔드와 백엔드가 분리된 경우 API 통신 규칙을 명확하게 정리한 문서입니다. 개발 효율성을 극대화합니다.
물론 1인 개발 프로젝트나 매우 작은 규모의 프로토타이핑에서는 이 모든 문서를 완벽하게 갖출 필요는 없습니다. 하지만 최소한 PRD(간략하게라도), User Flow, 그리고 기본적인 시스템 아키텍처는 반드시 정리하고 시작하는 것이 좋습니다. 이는 나중에 스스로 길을 잃지 않게 해주는 나침반이 됩니다.
과정 중에 어떤 시행착오를 겪었나요?
local에서 실행해서 앱이 어떻게 돌아가는지 확인해봐야하는데 구글 로그인이 잘 되지 않아 계속 수정 요청만 하다가 이게 local에서 구글 로그인이 돌아가게 할려면 이것도 firebase에서 인증을 받아야한다는 것을 수많은 디버깅 후에야 알게 되었습니다.
local 실행도 처음에는 cursor로 하다가 지금은 claude code로 아주 쉽게 하고 있습니다.
앞으로의 계획이 있다면 들려주세요.
여러 사용자들에게 피드백을 받아 좀 더 완성도 높은 수면 기록 앱으로 발전시켜 볼 예정입니다.
도움 받은 글 (옵션)
18기 옵시디언 스터디장님과 스터디원들의 피드백
