[Mongle] Day 1 기획 피벗과 폴더 구조

프로젝트 피벗: 메뉴판 번역 → 웨딩 AI 플랜

사실 처음부터 Mongle이 아니었다.

팀이 처음 잡았던 주제는 AI 기반 메뉴판 사진 분석·번역 앱이었다. 해외여행 중 외국어 메뉴판을 카메라로 찍으면 Vision API가 텍스트를 분석하고 번역해주는 앱. 팀원들끼리 주제를 고르고, 기능 범위를 잡고, 역할까지 나눠둔 상태였다. 나쁘지 않은 출발이었다.

그런데 프로젝트 시작 당일, 담당 강사가 바뀌면서 과제 요구사항 자체가 달라졌다. 기존에는 앱 주제에 제약이 없었는데, 새 강사는 그룹웨어(Groupware) 형태의 앱을 만들어야 한다는 조건을 제시했다. 단순 개인용 앱이 아니라, 여러 사용자가 정보를 공유하고 함께 협업하는 구조여야 했다.

준비해 둔 내용을 전부 폐기해야 했다. 주제 선정부터 기획, 역할 분담까지 팀원들끼리 나름 합을 맞춰서 잘 시작할 수 있겠다 싶었는데, 첫날부터 다시 시작해야 했다. 솔직히 좀 아쉬웠다.

그래서 피벗했다.

새로운 주제: 예비 부부 & 웨딩 플래너 협업 AI 플랫폼 — Mongle.

AI 챗봇·일정 관리·예산 관리·업체 리스트를 통합하여 웨딩플래너와 예비부부가 실시간으로 협업할 수 있는 웨딩 플랜 AI 서비스

그룹웨어 조건과 가장 자연스럽게 맞아떨어지는 구조를 찾다 보니 결혼 준비 플랫폼이 됐다. 플래너와 커플이라는 두 역할이 일정·예산·업체 정보를 실시간으로 공유하는 구조는, 그룹웨어의 정의에 딱 맞는다. 조건에 맞추면서도 실제로 풀 만한 문제를 고른 셈이었다.

결혼 준비는 크게 두 당사자가 있다. 준비하는 예비 부부, 그리고 이를 도와주는 웨딩 플래너. 이 둘이 일정·예산·업체 정보를 실시간으로 공유하고, AI 챗봇이 중간에서 조율을 도와주는 서비스. 사용자 페르소나가 명확하고, 기능 범위도 현실적으로 잡힐 것 같았다.

문제 정의

무엇이 문제인가 (What)

• 결혼 준비는 수십 개의 업체 계약, 복잡한 일정, 불투명한 비용 구조가 뒤섞인 고난도 프로젝트
• 예비부부와 웨딩플래너 간 소통이 카카오톡·전화에 의존해 정보 유실 및 혼선이 잦음
• 비용 명세 공유 방식이 없어 추가 옵션·숨겨진 비용에 대한 불신이 지속적으로 발생함

왜 발생하는가 (Why)

• 웨딩 준비를 위한 통합 협업 도구가 없어 여러 앱·메신저·스프레드시트를 병행 사용해야 함
• 플래너가 관리하는 정보(일정·비용·업체)가 예비부부에게 실시간으로 공유되지 않아 신뢰도 저하
• 업체 추천이 플래너 주관에 의존하고, 실사용 후기·비용 투명화 시스템이 부재함

어떻게 해결하는가 (How)

• 플래너↔예비부부가 정보를 공유하는 실시간 협업 플랫폼 구축
• AI 챗봇으로 웨딩 관련 질문 즉시 응답 및 맞춤 업체·일정 추천 제공
• 비용 명세를 항목별로 투명하게 공개하고, 잔금 알림을 자동화하여 편의성 극대화

사용자 페르소나

페르소나 1 — 예비신부 김지수 (29세, 직장인)

결혼 준비 초기 단계. 스튜디오·드레스·메이크업·웨딩홀을 동시에 알아보는 중이다. 플래너 연락이 느리고 비용 항목이 불분명해 예산 초과 불안감이 크다. D-day 타임라인·비용 명세를 실시간으로 확인하고, 챗봇으로 즉시 궁금증을 해소하고 싶어한다.

페르소나 2 — 웨딩플래너 박지현 (32세, 경력 8년)

동시에 12쌍의 커플을 담당한다. 일정·비용 관리에 쓰는 행정 시간이 전체 업무의 40%. 커플마다 카카오톡 채널이 달라 메시지 누락·중복 응답이 잦다. 담당 커플 현황을 한 대시보드에서 파악하고, 반복 행정 업무를 줄이고 싶어한다.

통계로 보는 시장

• 국내 결혼 건수 연간 약 19만 쌍, 평균 웨딩 비용 3,200만 원 (통계청, 2023)
• 결혼 준비 스트레스 1위: ‘비용 및 업체 관리 복잡성’ (결혼정보회사 듀오, n=1,200)
• 웨딩 관련 앱 사용 경험 없는 예비부부 68% — 전용 협업 도구 수요 입증
• AI 챗봇 활용 시 고객 응대 시간 평균 40% 단축 (Salesforce, 2023)

기능 우선순위 정의 (MoSCoW)

MVP 범위를 잡기 위해 MoSCoW 기법으로 기능 우선순위를 정리했다.

Must 기능 데드라인을 **3월 26일(목)**으로 설정했다. 주말(3/28~3/29) 개발 불가 조건이 추가되면서 실질 개발 가능일이 9일에서 7일로 줄었기 때문에, 일정표를 전체 재설계해야 했다.

유사 서비스 분석

기존 서비스들이 해결 못 하는 지점을 먼저 정리했다.

Mongle의 차별점은 하나다. 일정·비용·챗봇·업체를 하나로 통합하고, 플래너↔커플이 초대코드로 연결되어 실시간으로 공유한다. 기존 서비스들은 각 기능을 파편화해서 제공한다.

4인 역할 분담

협업 규칙: PR은 팀장 리뷰 후 머지, 커밋 메시지 통일, 기능 완료 시 즉시 공유. 매일 오전 데일리 싱크 10분.

예상 리스크

“일정 부족”을 가장 높은 리스크로 분류했다. 주말이 빠지면서 실 개발일이 줄었고, 이게 후반부 일정 압박으로 이어질 가능성이 컸다. (실제로 Day 6에서 일요일에 혼자 7시간 일했다.)

비즈니스 모델

MVP를 만들면서도 “이게 실제 서비스가 된다면?” 을 함께 고민했다.

수익 구조: Freemium + Subscription + 업체 입점 수수료

국내 웨딩 시장은 연간 약 3조 원 규모다. 잠재 사용자(예비부부)는 38만 명, 웨딩플래너는 2만 명 이상으로 추정된다. 플래너 월 구독만으로도 의미 있는 고정 수익이 나온다.

커밋 1: 전체 폴더 구조 재세팅

chore: 프로젝트 주제 변경에 따른 전체 폴더 구조(Mongle-app) 재세팅 16:31 — 72 files changed, 173 insertions(+), 121 deletions(-)

기존 메뉴판 번역 앱 구조를 전부 걷어내고 Mongle 구조로 갈아엎었다. 변경 파일이 72개다. 사실상 새 프로젝트 초기화다.

핵심 결정: Expo Router 기반 라우팅 구조

app/
├── (auth)/          # 로그인·회원가입 [정서영]
├── (couple)/        # 커플 전용 탭 [이건영 + 윤지현]
│   ├── chat.jsx     # AI 챗봇 UI [윤지현]
│   ├── timeline.jsx # 결혼 준비 타임라인 [이건영]
│   └── budget.jsx   # 비용 명세서 [이건영]
└── (planner)/       # 플래너 전용 탭 [이건영]
    └── dashboard.jsx

Expo Router의 그룹 라우팅((couple), (planner))으로 역할별 화면을 완전히 분리했다. 커플 앱과 플래너 앱이 하나의 코드베이스 안에서 role 기반으로 다른 탭을 보여주는 구조다.

빈 파일들로 placeholder를 먼저 생성해두고, 팀원 각자가 자기 파일을 채워가는 방식으로 협업을 시작한다.

커밋 2: 폴더별 역할 설정 & README 전면 개편

chore: 폴더별 역할 설정 16:46 — README.md 전면 재작성

README를 완전히 갈아엎으면서 폴더 구조에 담당자를 직접 명시했다.

├── components/
│   ├── common/           # [공통] 전원 사용
│   ├── chat/             # [윤지현] MessageBubble, ChatInput
│   ├── budget/
│   │   └── AiAnalysisCard.jsx  # [윤지현] SSE 스트리밍 결과 표시
│   └── vendor/           # [정서영]

내가 직접 맡은 컴포넌트는 채팅 UI와 AI 분석 카드다. AiAnalysisCard.jsx는 AI 응답을 SSE(Server-Sent Events)로 스트리밍 받아서 표시하는 컴포넌트인데, 이건 나중에 백엔드 팀원과 붙여야 한다.

오늘 하루를 돌아보며

3/23은 코드를 한 줄도 짜지 않은 날이다. 그런데 이게 낭비라는 느낌이 전혀 없다.

기획 단계에서 역할 분담과 우선순위를 꼼꼼하게 정리해두니 내일부터 바로 코딩으로 들어갈 수 있다는 확신이 생겼다. 처음에는 일정이 빠듯하다는 불안감이 있었는데, 시간표를 시각화하고 나니 오히려 “이 정도면 할 수 있겠다”는 감각이 생겼다.

다만 주말 제외로 실 개발일이 생각보다 짧다는 점은 계속 신경 쓰인다.

내일(3/24) 오전 안에 환경설정을 끝내는 게 첫 번째 분기점이 될 것 같다.

• GitHub 레포 세팅 완료
• Expo 프로젝트 초기화
• Supabase 프로젝트 생성 + DB ERD 작성
• lib/supabase.js, stores/authStore.js, app/_layout.jsx 구현 시작

화면 기록

프로젝트 방향을 뒤집은 날이라 이때 정리해 둔 기획 자료와 협업 흔적을 같이 남겨둔다. 로고 시안, 이슈 관리 방식, 체크리스트 운영 방식이 Day 1의 분위기를 가장 잘 보여준다.

GitHub: APP-Project-Team1/mongle

첨부 파일

• APP 프로젝트 기획서(Mongle).md

외부 조건이 바꾼 방향, 그래도 잘 됐다

준비한 걸 첫날부터 버려야 했던 건 분명 아쉬운 경험이다. 팀원들끼리 나름 기대감을 갖고 시작했던 주제였고, 방향이 잡혀있던 상태에서 갑자기 조건이 바뀌었으니까.

그런데 돌아보면, 그룹웨어 조건이 오히려 프로젝트를 더 탄탄하게 만들었다. 단순 번역 앱은 개인 사용에 머물렀겠지만, Mongle은 플래너와 커플이라는 두 역할이 데이터를 공유하고 함께 움직이는 구조여야 했다. 권한 분리, 실시간 동기화, 역할별 화면 같은 설계 고민들이 그 조건에서 나왔다.

외부에서 주어진 제약이 방향을 강제한 셈인데, 결과적으로는 그게 프로젝트를 더 복잡하고 완성도 있게 만들었다. 준비했던 내용을 폐기한 아쉬움보다, 새로 잡은 방향에서 더 많은 걸 배웠다는 쪽이 맞다.