마지막 날은 코딩이 아니었다

3월 23일부터 시작된 Mongle 프로젝트의 9번째 실개발일. 오늘은 커밋이 많지 않다.

코드는 어제(Day 8)로 거의 마무리됐다. 오늘 할 일은 따로 있었다.

  • 시연 영상 촬영
  • 결과 발표 PPT 완성
  • 발표 연습

내일(4/2)이 최종 발표다.


시연 영상

PPT보다 먼저 시연 영상을 찍었다. 영상이 있어야 PPT에 QR이든 링크든 넣을 수 있으니까.

앱을 실행해서 커플 로그인 → 홈 화면 → AI 추천 → 채팅 → 예산 관리 → 견적 비교 순으로 흐름을 녹화했다. 플래너 로그인도 별도로 찍었다. Day 8에서 네 번의 반복 끝에 잡은 로그인 버그 덕분에, 오늘 촬영에서 인증 흐름이 한 번도 튀지 않았다.

CapCut으로 편집하고 자막 달았다.


결과 발표 PPT: 구조

PPT는 총 45슬라이드, 5개 챕터로 구성했다.

01 문제 인식     — 웨딩 시장의 문제 정의
02 해결책 소개   — Mongle 소개, 핵심 가치, 시스템 구조
03 개발 & 기술   — 팀, 타임라인, 기술 스택, UI/UX 시연
04 비즈니스 & 운영 — 수익화, 법적 이슈, 트러블슈팅, 협업
05 평가 & 결론   — 자체 평가, 개별 코멘트, 마무리

01 문제 인식: 웨딩 시장의 6대 문제

슬라이드 오프닝은 레스토랑 비유로 시작했다.

“밥 먹으러 갔는데 가격표 없는 메뉴판, 100개가 넘는 선택지, 직원이 손에 든 메뉴판에서만 추천해주는 상황이라면?”

이게 지금 웨딩 시장의 현실이다. 데이터와 함께 6가지 문제로 정리했다.

문제통계
웨딩업체 가격 비공개85%가 가격 정보 부족 경험
스드메 불투명성83%가 예상치 못한 추가 비용 발생
직접 상담 필요웨딩홀 90% 이상 방문 상담 시에만 가격 공개
사람마다 다른 가격동일 서비스에서 최대 2~3배 차이
검색 번거로움75%가 여러 플랫폼 검색 필요 경험
플래너 추천 제휴 중심60%가 제휴 중심 추천 경험

출처: 한국소비자원 「2024 소비자 시장평가지표」, 기획재정부 「2024 결혼서비스 실태조사」

핵심 문제는 정보 비대칭과 결정 피로. Mongle이 풀려고 하는 것도 정확히 이 두 가지다.


02 해결책: Mongle의 핵심 가치와 경쟁 위치

Mongle을 기존 경쟁 서비스(메링, 웨딩플로우)와 기능 비교표로 나란히 놨다.

기능메링웨딩플로우Mongle
AI 추천부분부분완벽
견적 분석없음기본심층
예산 최적화없음기본AI
일정 관리있음있음스마트
채팅있음있음AI
가격 투명성낮음중간높음

AI 추천과 예산 최적화에서 기존 서비스 대비 명확한 차별점이 있다.


03 개발 & 기술

팀 구성

팀원역할기여 영역
윤지현 (Evan)PM / AI LeadAI 기능, DB 연동, Web UI
정서영UI/UX커플 화면, 추천 화면, 예산 화면 디자인, DB 연동
이건영FE업체 상세, 채팅창, 로그인/회원가입, 디버깅
강주영BEDB 설계, API 개발, Web UI, DB 연동

개발 타임라인

3/23(월)   기획  — 주제 선정, 기획서 작성, 환경 통일, 역할 분담
3/24~26    세팅  — 백엔드 세팅, UI 제작, AI 구현, 회원가입
3/27(금)   위기  — PR 승인 오류, 5만 줄 rollback, 복구 완료
3/28(토)   휴식
3/29~31    확장  — 플래너 UI, DB 연동, 알림 시스템, 디버깅
4/1~2      발표  — 시연 영상, PPT 제작, 발표 연습, 최종 발표

8일 만에 기획 → 개발 → 위기 극복 → 완성까지.

시스템 아키텍처

App Layer     React Native (Expo Router)
                    ↕ REST API
API Layer     FastAPI (Python)

Database      Supabase (PostgreSQL + Auth + RLS)

AI Layer      GPT-4o / GPT-4o-mini / Claude

AI 구조

AI가 처리하는 세 가지 기능을 명확하게 구분했다.

1. 챗봇 (RAG)

사용자 메시지
  → GPT-4o-mini: 검색 필터 추출 (district, category)
  → Supabase: 지역/카테고리 기반 업체 조회
  → GPT-4o: 실제 업체 데이터 기반 스트리밍 응답

2. 예산 최적화

Jaccard 유사도 기반 스타일 매칭 + 가격 절감 점수 (3:7 가중합)으로 현재 업체 조합보다 저렴하면서 스타일이 비슷한 대안을 추천한다.

3. 견적 비교 (GPT-4o Vision)

사용자가 견적서 사진을 업로드하면 GPT-4o가 이미지를 분석해서 구조화된 데이터를 추출한다. 저화질 사진에서 금액 단위를 웨딩 업계 상식으로 유추하도록 프롬프트를 설계했다.


04 비즈니스 & 운영

법적 리스크 대응

PPT 작업하면서 법적 이슈 슬라이드가 가장 오래 걸렸다. 웨딩 업체 정보를 수집해서 공개하는 과정에서 실제로 법적 리스크가 있다.

“전문가 실시간 상담을 시도했는데 8분에 19,000원이었다”는 내용을 그대로 넣었다. 해결책을 모른 채 회피하는 것보다, 리스크를 인지하고 있다는 걸 보여주는 게 낫다고 판단했다.

단기 전략: 비식별화 처리, 범위형 정보 제공, 직접 상담 유도
장기 전략: 공식 제휴 기반 가격 등록 시스템 구축

마침 2025년 말 도입된 웨딩업체 가격공개 의무 제도가 있다. 계도기간이 2026년 5월에 끝나고 6월부터 본격 시행된다. Mongle의 비즈니스 구조가 이 흐름과 맞아떨어진다.

수익화 모델

세 가지 수익원을 조합한 하이브리드 모델.

💍 중개 수익  — 업체/플래너 매칭 수수료
               평균 웨딩 2,000만 원 × 5% = 커플당 100만 원

📊 SaaS 구독  — 커플 ₩9,900/월, 플래너 프로 ₩29,900/월

🤖 AI 프리미엄 — 견적 분석 ₩9,900, 예산 최적화 ₩14,900

광고 기반이 아니라 “의사결정이 일어나는 순간”에 수익이 발생하는 구조다.

트러블슈팅

PPT에 넣은 주요 이슈들.

5만 줄 rollback (Day 5): 코드 리뷰 없이 PR을 머지하다가 vendors.jsx 전체 라우팅이 꼬였다. git log --oneline 파일명으로 마지막 정상 커밋을 찾아서 수동으로 복구했다. 교훈: “Merge Conflict가 없다고 문제가 없는 게 아니다.”

인증 401 오류: Supabase access token을 API 요청마다 수동으로 붙여야 했는데 누락됐다. Axios 인터셉터로 자동 포함 처리.

챗봇 검색 결과 없음: 사용자 입력 “강남”과 DB 저장값 “강남구” 불일치. 지역명 매핑 딕셔너리(DISTRICT_MAP)로 해결.

패키지 충돌: 버전 충돌로 앱 실행 자체가 안 된 상황. 환경 초기화 후 Git clone 재시작.


05 자체 평가: 8.5 / 10

종합 점수를 8.5로 정한 이유를 한 줄로 요약하면: “핵심 기능은 다 구현했고, 일부 최적화가 남아있다.”

팀원별 측정 기준도 수치화했다.

팀원목표측정 방법
윤지현 (PM/AI)AI 정확도 98%테스트 케이스 기반 측정
DB 연동실시간 동기화 동작 확인
일정 준수 100%마일스톤 기준
정서영 (UI/UX)사용성 4.8/5내부 피드백
이건영 (FE)응답속도 0.2s로컬 측정
버그 해결률 95%이슈 기준
강주영 (BE)API 안정성 99%테스트 기준

향후 개선 방향 4가지:

  1. 추천 정확도 99% (데이터/프롬프트 튜닝)
  2. UX 피드백 반영 (흐름·마이크로카피)
  3. API 응답시간 0.1s 단축 (캐시/쿼리 최적화)
  4. 실사용자 테스트 → 측정 → 개선 루프

개별 코멘트 (내 것)

PPT의 마지막 실질 섹션이 각자의 코멘트다. 나는 이렇게 썼다.

가장 어려웠던 점: 팀원의 장점을 잘 몰라 역할 분담에 어려움을 겪었다.
해결: 이슈 기준으로 역할을 재정렬하고 체크리스트로 실행을 관리했다.
배운 점: 합의된 룰이 속도와 품질을 동시에 올린다.
다음 프로젝트에 적용: 체크리스트를 포스트잇 방식으로 바꿔 더 직관적으로.


발표 연습

슬라이드를 다 완성한 뒤 각자 맡은 파트를 말로 해봤다. 처음엔 시간이 예상보다 훨씬 많이 나왔다. 여러 번 줄여서 전체 흐름을 맞췄다.

내일 발표다.


11일을 돌아보며

PPT 마지막 슬라이드에 이렇게 썼다.

복잡한 웨딩 준비를, 더 투명하고 더 스마트하게.

프로젝트 시작할 때 잡았던 방향이다. 그게 지금도 유효하다.

3월 23일 기획서 한 장에서 시작해서, 오늘 45장짜리 발표 자료까지 왔다. 중간에 5만 줄 rollback, 로그인 버그 4회 반복, 알림 시스템 폐기, 라우팅 전면 재설계 같은 일들이 있었다.

그 과정에서 배운 것들이 있다.

  • 코드 리뷰 없는 머지는 시한폭탄이다. Conflict가 없어도 문제는 있을 수 있다.
  • 알고리즘 가중치는 수식이 아니라 도메인 판단이다. 스타일 60:가격 40을 30:70으로 바꿨을 때 추천 결과가 완전히 달라졌다.
  • 방어적 코드는 선택이 아니다. AI가 데이터를 못 가져와도 앱이 멈추지 않아야 한다.
  • git log는 항상 열려있는 비상구다. git log --oneline 파일명으로 언제든 과거로 돌아갈 수 있다.
  • 합의된 룰이 팀 속도를 만든다. Branch naming, PR template, 작업 파일 사전 공유. 후반부로 갈수록 머지 충돌이 사라졌다.

GitHub: APP-Project-Team1/mongle


첨부 파일

결과보고서_1팀(Mongle).pptx