![]()
클로드 바이브코딩(Claude Code vibe coding)으로 앱을 만들 때 첫 단계는 코드가 아니라 “누가 왜 쓰는 앱인지” 한 줄을 정하는 일이에요. 저는 그 한 줄에 3주를 썼고, 정해진 뒤에는 클로드코드(Claude Code)가 이틀 만에 화면 5개의 뼈대를 만들었어요. 이 글은 와이프의 최대 관심사인 화장품과 제가 할 수 있는 AI 개발을 합쳐 만든 K-뷰티 커뮤니티 앱 코스모(COSMO)의 기획 기록이에요.
3부작 중 1편이에요. 1편은 아이디에이션과 컨셉 확정, 2편은 구현기, 3편은 앱인토스(Apps in Toss) 오픈 완료까지 다뤄요.
왜 화장품 앱을 만들었나요?
거실 테이블에는 늘 화장품이 대여섯 개 올라와 있어요. 와이프가 새 쿠션이나 틴트를 사기 전에 유튜브 리뷰를 서너 개씩 돌려보거든요. “그거 점수로 딱 정리해 주는 데 없어?”라고 물어봤더니 없더라고요.
리뷰는 유튜브에 흩어져 있고, 쇼핑몰 리뷰는 광고인지 진짜인지 구분이 안 돼요. 그래서 와이프가 제일 좋아하는 것과 제가 할 수 있는 것을 합치기로 했어요. 제 쪽 재료는 데이터 분석과 클로드코드로 하는 바이브코딩이었어요.

이름은 코스모(COSMO), 코스메틱 덕후(Cosme Otaku)의 줄임말이에요. 로고는 코스모스 꽃이고, 이 로고와 핑크 팔레트는 기획서를 세 번 갈아엎는 동안에도 한 번도 바꾸지 않았어요.
아이디에이션은 어떻게 진행했나요?
처음 기획서는 가격 비교 앱이었어요. 올리브영 인기 상품을 수집하고, 유튜버가 언급한 상품을 연결하고, 네이버와 쿠팡 최저가를 보여주는 구조였죠. 기획서를 클로드코드에 넣고 “이거 어때?”를 반복하다 보니 구멍이 보였어요.

- v1 (3월 초), 정보 앱: 핫아이템 + 유튜버 픽 + 최저가. 만들고 보니 “검색하면 나오는 것”이었어요.
- v2, 리뷰 앱: 유튜브 리뷰를 AI로 요약하는 방향. 한 번 보고 나가는 구조라 다시 올 이유가 없었어요.
- v3 (3월 중순), 덕후 커뮤니티: 와이프가 실제로 시간을 쓰는 곳은 더쿠나 인스티즈 같은 커뮤니티였어요. “정보”가 아니라 “떠드는 자리”가 몸통이어야 했어요.
v3에서 확정한 결정은 세 가지예요. 모여(주제별 스레드)의 주제를 완전히 자유롭게 열기, 로그인은 후순위로 미루기, 수익화는 v1에서 제외하기. 이 단계에서 클로드코드가 한 가장 큰 기여는 코드가 아니라 “기존 코드를 고칠지, 새로 만들지” 비교표를 뽑아준 것이었어요.
| 항목 | 기존 v1 코드 수정 | 새로 개발 |
|---|---|---|
| 기능 구조 | 모여·아무말·#태그가 기존과 완전히 다름 | 처음부터 맞는 구조로 설계 |
| 코드 부채 | 억지로 끼워 넣기, 유지보수 어려움 | 깔끔한 아키텍처 |
| 디자인 | 그대로 사용 | 디자인 시스템만 이식하면 100% 동일 |
| 일정 | 분석 + 리팩토링 비용이 큼 | Phase별 구현이라 예측 가능 |
결론은 새로 개발이었어요. 로고, 컬러, 폰트, 공통 컴포넌트만 가져오고 나머지는 전부 버렸어요. 사람 손으로 짰으면 아까워서 못 버렸을 코드인데, 바이브코딩은 버리는 비용이 작아요. 방향을 바꾸는 게 싸다는 것, 이게 클로드 바이브코딩의 가장 큰 장점이에요.
코스모 컨셉은 무엇으로 확정했나요?

한 줄 컨셉은 “코덕들이 유튜버 리뷰 데이터로 화장품을 비교하고, 퍼스널컬러 진단과 뷰티 커뮤니티까지 한 번에 즐기는 K-뷰티 앱”이에요. 타겟은 퍼스널컬러에 관심 있는 2030 뷰티 덕후, 즉 와이프 같은 사용자예요.
| 구성 요소 | 역할 | 내용 |
|---|---|---|
| ① 코덕 커뮤니티 | 몸통 | 모여(주제별 스레드) + 아무말(자유 게시판). 글 안에서 #태그로 상품을 바로 호출 |
| ② 유튜버 리뷰 데이터 | 대화 재료 | 리뷰 영상 자막을 수집해 감성분석으로 점수화. 예: “유튜브 리뷰 종합 4.1점” |
| ③ 퍼스널컬러 | 모이는 이유 | 10문항 자가 진단 + 봄라·여뮤·가딥·겨브 8타입별 모여가 매월 자동 개설 |
뺀 것도 분명해요. 최저가 비교는 정보 앱처럼 보여서, 결제는 사업자 등록이 필요해서, 소셜 로그인은 첫 진입 장벽이라서 제외했어요. 하단 탭은 홈, 모여, 아이템, 아무말, 마이 다섯 개로 고정했어요.
플레이스토어 대신 앱인토스(Apps in Toss)를 택한 이유는?
원래는 안드로이드 앱으로 플레이스토어에 올릴 계획이었고, 5월까지 스토어 등록 직전 단계까지 갔어요. 6월 말에 토스 안에서 바로 열리는 미니앱, 앱인토스로 방향을 틀었어요.
| 비교 | 플레이스토어 앱 | 앱인토스 미니앱 |
|---|---|---|
| 설치 | 스토어에서 다운로드 | 설치 없음, 토스 안에서 바로 실행 |
| 로그인 | 카카오·구글 소셜 로그인 직접 구현 | 토스가 사용자 식별, 로그인 화면 불필요 |
| 심사 | 정책 항목이 많고 기간이 김 | 영업일 최대 3일 |
| 결제 | 가능(사업자 필요) | 없음으로 확정, 사업자 불필요 |
| 기술 | 네이티브 앱 | 웹(React) 미니앱 |
커뮤니티 앱은 사람이 모여야 의미가 있는데 “앱 설치해 주세요”가 가장 큰 벽이었어요. 토스 안에 있으면 링크 하나로 와이프 친구들에게 바로 보여줄 수 있고, 결제와 로그인이 없어서 v1 범위도 크게 줄었어요.
아쉬운 점은 네이티브 앱으로 만든 화면을 웹으로 다시 만들어야 했다는 것이에요. 웹뷰에서만 발생하는 버그도 여럿 있었고, 이 부분은 2편 구현기에서 다뤄요.
바이브코딩 계획은 어떻게 세웠나요?

역할 분담을 먼저 정했어요. 제 일은 기획, 결정, 실기기 테스트, 와이프 피드백 수집이에요. 코드는 전부 클로드코드가 쓰고, 저는 코드를 읽기만 하고 직접 타이핑하지 않아요. 대신 클로드코드 안에 역할별 에이전트를 네 개 두고, 프로젝트 규칙 파일(CLAUDE.md)에 팀 구조를 적어뒀어요.
- CEO 에이전트: 기획서를 읽고 작업을 쪼개서 아래 셋에게 분배
- Founding Engineer: 앱 화면과 FastAPI 백엔드 구현
- TestEng: 구현 후 QA와 회귀 테스트
- UX Designer: 화면이 바뀔 때만 디자인 리뷰
진행은 기획서를 Phase로 쪼개 순서대로 맡겼어요. Phase 0은 디자인 시스템 이식(로고, 핑크 팔레트, 폰트), Phase 1~3은 홈·모여·아이템·아무말 화면과 백엔드, Phase 4~5는 #아이템태그와 글쓰기, 그다음이 데이터 수집이에요. 작업마다 이슈 번호(COD-1, COD-2 …)를 붙였고, 4월 초까지 149개가 쌓였어요.
규칙도 몇 개 고정했어요. 순서는 항상 생각, 계획, 구현, 리뷰, 테스트, 배포, 회고. 버그는 조사 없이 고치지 않기, 같은 버그를 3번 실패하면 멈추고 사람에게 묻기, rm -rf 같은 위험 명령은 실행 전 확인받기.
첫 커밋은 3월 14일이었고, 3월 15일에 홈·모여·아이템·아무말 네 화면의 뼈대가 올라갔어요. 3주 고민하고 이틀 만에 형태가 나온 셈이에요. 생각이 길고 구현이 짧은 것이 바이브코딩 일정의 특징이에요. 클로드코드 설치와 기본 사용법은 클로드코드 사용방법 2026에, 에이전트에게 역할을 주는 방법은 스킬 개념편에 정리했어요.
지금 코스모는 어떤 모습인가요?
아이템 탭에서 상품 하나를 누른 화면이에요. 위에는 상품 사진과 가격, 아래에는 유튜브 리뷰를 종합한 점수가 붙어요.

스크롤을 내리면 유튜버별 한 줄 요약과 별점이 나와요. “호불호 갈리겠는데” 같은 부정적 리뷰도 그대로 두는 것이 원칙이에요. 광고 카피가 아니라 데이터니까요.

이 화면이 나오기까지 웹뷰 흰 화면, 그리드 깨짐, 탭바 높이 같은 문제가 줄줄이 있었어요. 2편에서 하나씩 정리해요.
자주 묻는 질문
Q. 코딩을 전혀 몰라도 클로드 바이브코딩으로 앱을 만들 수 있나요?
코드를 쓰지 못해도 되지만 읽을 줄은 알아야 해요. 제 일의 대부분은 “이 방향이 맞나”를 결정하는 것이었고, 그 판단은 코드가 무엇을 하는지 대략 알아야 가능했어요.
Q. 기획서는 얼마나 자세히 써야 하나요?
화면별 기능이 표로 정리될 정도면 충분해요. 코스모 v3 기획서는 탭 5개, 화면별 구성 요소, 뺄 기능 목록이 전부였고, 나머지는 클로드코드가 질문하면서 채웠어요.
Q. 앱인토스는 누구나 올릴 수 있나요?
결제가 없는 앱이면 사업자 등록 없이 올릴 수 있어요. 개인정보처리방침 페이지와 고객센터 이메일은 필요하고, 심사는 영업일 최대 3일이에요.
Q. 방향을 세 번 바꾼 것은 시간 낭비 아니었나요?
버린 코드는 낭비가 아니라 학습이었어요. v1을 실제로 만들어 봤기 때문에 “이건 정보 앱이다”를 눈으로 확인할 수 있었고, 머리로만 기획했으면 더 늦게 알았을 거예요.
다음 편
2편은 구현기예요. 안드로이드 앱을 웹 미니앱으로 옮긴 과정, 토스 웹뷰에서만 발생한 흰 화면 버그, 이미지 그리드가 갑자기 커지던 문제까지 다뤄요. 3편은 앱인토스 심사 제출부터 오픈 완료까지예요. 비용이 궁금하다면 클로드코드 비용 2026을 먼저 보세요.
이 글은 개인 프로젝트 기록이고 특정 도구나 플랫폼의 광고가 아니에요. 앱인토스 심사 기준은 2026년 9월 기준이며 바뀔 수 있어요.

Leave a Reply