travel-recommender

동덕여자대학교 빅데이터(캡스톤 디자인) · 3인 팀

그룹 여행 합의 도구 — 기획안

원본 문서: docs/기획서.md (작성일 2026.09.12) 캡스톤 주제안: docs/캡스톤_주제안.md

---

1. 한 줄 정의

각자 가고 싶은 곳 5개만 고르면, 싸우지 않는 일정을 만들어주는 서비스.

일정을 만드는 앱이 아니라 합의를 만드는 앱입니다.

---

2. 문제 정의

실제로 벌어지는 일

친구 다섯 명이 여행을 갑니다. 한 명이 총대를 메고 일정을 짭니다. 나머지는 "다 좋아, 아무거나"라고 합니다. 그런데 막상 가면 불만이 나옵니다.

• 숙소가 생각보다 별로다
• 너무 많이 걷는다, 아침부터 너무 이르다
• 여기는 왜 온 건지 모르겠다
• 생각보다 돈을 많이 썼다

왜 미리 말하지 않았나

말하면 손해를 보기 때문입니다.

하고 싶은 말	하면 어떻게 보이나
게스트하우스면 충분해	궁색해 보임
호텔 아니면 잠을 못 자	유난스러워 보임
하루 종일 걷는 건 힘들어	민폐 같음
더 많이 돌아다니고 싶어	극성 같음

특히 돈과 체력이 그렇습니다. 둘 다 말하는 순간 자신의 형편이나 상태가 드러나는 정보라, 사람들은 입을 닫고 "아무거나"라고 답합니다.

핵심 통찰

문제는 서로의 취향을 모르는 것이 아니라, 말할 수 없는 것입니다.

더 좋은 추천 알고리즘으로는 풀리지 않습니다. 말하지 않아도 반영되는 구조로 풀어야 합니다.

---

3. 경쟁 분석

이미 잘 하고 있는 것

서비스	강점
Wanderlog	구글 지도 목록 가져오기, 실시간 공동 편집, 경로 최적화, 경비 정산
Triply	저장 장소를 일정으로 변환, 가까운 곳끼리 같은 날로 묶기
Plotline	틱톡·인스타·유튜브에서 장소 추출
트리플	AI 일정 자동 생성, 동행 초대, 하트로 취향 공유, 정산

일정을 만드는 기능은 포화 상태입니다. 여기서 경쟁하면 이기기 어렵습니다.

아직 비어 있는 것

위 서비스들은 모두 협업 편집기입니다. 여럿이 함께 넣고 옮기는 도구지, 서로 다른 선호를 분석해 합의점을 찾아주지 않습니다.

• 의견이 갈리면 채팅으로 넘깁니다
• 3명은 미식, 2명은 액티비티일 때 누가 양보할지 알려주지 않습니다
• 돈 얘기는 아예 다루지 않습니다
• 체력 차이는 어떤 앱도 고려하지 않습니다

그룹 추천 시스템(group recommendation) 연구는 많지만 상용 제품에는 들어가 있지 않습니다. 일부 앱이 목적지 투표 기능을 넣은 정도입니다.

우리의 위치

일정 생성으로 경쟁하지 않습니다. 합의 과정 자체를 제품으로 만듭니다.

---

4. 핵심 원리

원리 1 — 말하지 않아도 반영된다

모든 입력은 비공개입니다. 누가 얼마를 적었는지, 누가 무엇을 부담스러워했는지 끝까지 공개되지 않습니다. 결과만 공개됩니다.

원리 2 — 모두가 최소 하나는 지킨다

각자 5개 중 하나를 "이건 진짜 꼭"으로 지정합니다. 그 하나는 아무도 겹치지 않아도 무조건 일정에 들어갑니다.

겹침 투표만으로 뽑으면 취향이 특이한 사람은 하나도 못 건집니다. 다섯 개 다 떨어진 사람이 생기면 그 여행은 실패입니다.

원리 3 — 하한에 맞추되, 원하는 사람은 더

전부를 최저 기준에 맞추면 여유 있는 사람이 불만입니다. 항목마다 성격이 다릅니다.

항목	처리 방식	이유
숙소	타협 불가 — 가장 부담스러워하는 사람 기준	같이 자야 하므로
식사	각자 가능 — 예산이 다르면 그날만 갈라져도 됨	매 끼니를 같이 먹을 필요 없음
활동	코어 + 옵션 — 코어는 다 같이, 옵션은 원하는 사람만	체력 차이를 흡수

"모든 걸 다 같이 할 필요는 없다"를 시스템이 먼저 제안합니다. 사람이 먼저 "나 빠질게"라고 말하긴 어렵기 때문입니다.

원리 4 — 양보가 기록된다

계속 맞춰주기만 하는 사람이 생기는 것이 그룹 여행의 진짜 통증입니다. 각자의 입력값과 최종안의 거리를 계산해 양보량을 기록하고, 다음 여행에서 우선권을 줍니다.

주의: 양보량을 그룹에 공개하면 원리 1이 깨집니다. "A님이 가장 많이 양보했다"는 곧 "A님이 돈이 없다"로 읽힙니다. 양보량은 본인에게만 보여주고, 그룹에는 다음 여행 우선권만 표시합니다.

---

5. 입력 — 두 번에 나눠 받습니다, 전부 비공개

5-0. 먼저 기간과 동행자만 같이 정합니다

첫 화면에서 **며칠 가는지(박 수)**와 **누구랑 가는지(이름)**만 정합니다. 여기까지가 같이 정하는 유일한 단계이고, 나머지는 각자 조용히 입력합니다. 인원은 2~6명입니다.

5-1. 1차 — 빈 화면에서 검색으로 5곳 찾기

후보 카드를 미리 깔아두지 않습니다. 검색창 하나와 카테고리(명소·식사·카페·쇼핑·문화·체험·자연)만 있는 빈 화면에서 시작해, 이름이나 지역으로 검색해 가고 싶은 곳 5곳을 찾습니다.

목록에 없으면 직접 추가합니다. 이름·카테고리·지역만 받고 비용·체류 시간은 비워도 됩니다 (카테고리 평균값으로 채웁니다). 좌표는 고른 지역의 중심을 빌려 쓰므로 동선은 대략값입니다.

고정된 후보 카드만 보여주면 "내가 진짜 가고 싶은 곳"이 목록에 없을 때 방법이 없고, 그러면 첫 화면부터 남의 취향에 맞추게 됩니다.

이 단계에서는 '꼭'도 '빼고 싶은 곳'도 고르지 않습니다. 남들이 뭘 찾아왔는지 모르는 상태에서 정하면, 모두의 후보가 모인 뒤에 마음이 바뀌어도 되돌릴 수 없기 때문입니다.

5-2. 2차 — 모두의 후보가 모인 화면에서 다시 고르기

전원이 1차를 마치면 모두가 찾아온 곳이 한 화면에 모입니다(5명이면 최대 25곳). 여기서 각자 다시 고릅니다.

• 가고 싶은 곳 5개
• 그중 1개는 "꼭" — 겹치지 않아도 일정에 반드시 들어갑니다
• 1개는 거부권 — "여기는 빼주세요" (선택)

누가 올린 곳인지는 보여주지 않습니다. 몇 명이 올렸는지만 표시합니다. 누가 올렸는지 보이면 그 사람 눈치를 보게 되고, 비공개 원칙이 1차에서만 지켜지는 셈이 됩니다.

5-3. 3차 — 조건 입력

축	질문	단위
돈	하루에 얼마까지 쓸 수 있나요	원/일 (여행 전체 예산은 일수를 곱해 구합니다)
체력	하루에 얼마나 걸을 수 있나요	걸음 수 — 5천보 많이 못 걸어요 / 8천보 적당히 / 1만2천보 꽤 걸어도 / 1만8천보 하루 종일
시간	하루 활동 시간	시간

예산을 여행 총액이 아니라 하루 단위로 묻는 이유는, 총액은 기간에 따라 감이 달라져 답하기 어렵기 때문입니다. 걷기를 km가 아니라 걸음 수로 묻는 이유도 같습니다 — 스마트폰이 매일 보여주는 숫자라 자기 한계를 이미 알고 있습니다. 대신 숫자만 주면 감이 안 오므로 "적당히"처럼 말도 같이 붙입니다.

왜 장소 선택만으로는 부족한가

사람들은 "가고 싶은 곳"을 고르지 "감당 가능한 곳"을 고르지 않습니다. 비싼 곳을 골랐다고 예산이 넉넉한 게 아닙니다. 체력도 마찬가지입니다. 그래서 이 둘만은 따로 묻습니다.

5-4. 인원에 따라 개수를 조정합니다

후보 총량이 필요한 일정 수의 약 두 배가 되도록 맞춥니다. 인원이 적으면 겹침 경쟁이 생기지 않아 합의 장치가 의미를 잃습니다.

인원	1인당 개수	후보 총량	3박4일 코어(12곳) 대비
3명	8개	24개	2.0배
4명	6개	24개	2.0배
5명	5개	25개	2.1배
6명	4개	24개	2.0배

5-5. 고르는 동안은 서로 안 보입니다

남이 무엇을 골랐는지 보이면 눈치를 봅니다. 인기 있는 것만 따라 고르게 되고 개수 제한의 의미가 사라집니다.

참여 현황만 보여줍니다. "5명 중 3명 완료" — 내용은 보이지 않습니다.

---

6. 합의안 생성 — 규칙과 AI의 역할 분리

"AI가 알아서 정해준다"는 설명이 안 되면 사용자가 믿지 않습니다. 역할을 나눕니다.

6-1. 채택은 규칙으로 (투명성)

1. 각자의 '꼭' 1개를 먼저 확정            → 5명이면 5곳 확보
2. 거부권이 걸린 곳은 제외
3. 남은 자리를 겹침 순으로 채움            → 2명 이상 겹친 곳 우선
4. 예산 한도에 걸리면 중단                 → 나머지는 옵션
5. 체력 한도(최저 기준자)를 넘으면 중단     → 나머지는 옵션
6. 남은 장소 = 옵션 (자유시간에 동선 근처면 제안)

규칙이 공개돼 있으므로 결과에 아무도 불만을 갖지 않습니다.

6-2. AI가 맡는 일

역할	내용
합의에 맞는 곳 추가	아무도 고르지 않았지만 전원의 취향·예산에 맞는 곳을, 남은 자리와 남은 예산 안에서만 채움
빈칸 채우기	채택된 장소 사이에 들어갈 식사·카페·휴식을 동선과 시간대에 맞게 배치
동선 정리	하루치 장소를 지리적으로 묶고 이동이 적은 순서로 배열
설명 생성	왜 이 조합이 됐는지, 무엇이 빠졌는지 자연어로 설명
대안 제시	예산을 조금 올리면 무엇이 들어오는지

6-3. 지도는 합의의 증거로 씁니다

지도의 역할은 예쁘게 보여주기가 아니라 합의안이 실제로 감당 가능한지 증명하기입니다.

• 좌표 → 실제 이동 거리·시간 → 체력 합의 검증
• 장소별 입장료·평균 식비 → 합계 → 예산 합의 검증

오늘 코스는 총 8.2km, 이동만 1시간 40분입니다. 한 분이 감당 가능하다고 한 거리는 5km입니다.

말로 하는 합의가 계산으로 증명됩니다.

6-4. 트레이드오프 — 시스템이 대신 말한다

예산이 고정된 상태에서 한 축을 올리면 다른 축이 자동으로 내려갑니다.

숙소를 '리조트'로 올림
  ↳ 여행 스타일을 '로컬 위주'로 낮췄어요
  ↳ 이동을 '도보 중심'으로 낮췄어요

사람이 "네가 좀 양보해"라고 말하는 대신 시스템이 교환 관계를 설명합니다. 관계가 상하지 않습니다.

---

7. 사용자 흐름

[방 만들기]   며칠 · 누구랑(이름)
      ↓
[링크 공유]   카카오톡으로 초대
      ↓
[1차 입력]    빈 화면에서 검색으로 가고 싶은 곳 5곳 (없으면 직접 추가)   ← 비공개
      ↓
[참여 현황]   "5명 중 3명 완료"  (내용은 안 보임)
      ↓
[2차 입력]    모두가 찾아온 곳이 모인 화면에서 5곳 · 꼭 1곳 · 빼고 싶은 1곳   ← 비공개
      ↓
[조건 입력]   하루 예산 · 하루 걸음 수 · 하루 활동 시간   ← 비공개
      ↓
[합의안]      코어/옵션 + AI가 채운 곳 + 예산 + 동선 + 근거
      ↓
[충돌 조정]   갈리는 항목만
      ↓
[확정]        일정 공유 + 양보 기록
      ↓
[여행 중]     지출 기록 · 정산 · 결제 룰렛

---

8. 화면 구성

화면	핵심 내용
방 만들기	며칠, 누구랑(이름 입력)
초대	링크 공유, 참여 현황
장소 찾기 (1차)	빈 화면 + 검색 + 카테고리, 5곳 선택, 없으면 직접 추가
모두의 후보 (2차)	전원이 찾아온 곳, 5개 선택, '꼭' 지정, 거부권 (누가 올렸는지는 비공개)
조건 정하기	하루 예산 · 하루 걸음 수 · 하루 활동 시간
대기	참여 현황만 표시
합의안	코어 일정, 옵션 일정, 예산, 총 이동거리, 근거
충돌 조정	의견이 갈린 항목만
일정 확정	일자별 동선, 지도
여행 중	지출 기록, 환율 환산
정산	n빵 계산, 최소 송금, 결제 룰렛
회고	계획 대비 실제, 양보 기록(본인만)

합의안 화면 — 결과 예시

25곳 중 코어 11곳, 옵션 9곳으로 정리했어요 예산 때문에 5곳은 넣지 못했습니다

총 6.1km · 1인 62만원 — 전원 감당 가능합니다

다섯 분의 '꼭 가고 싶은 곳'은 모두 지켰습니다

마지막 줄이 이 서비스가 하는 일을 한 문장으로 보여줍니다.

---

9. MVP 범위

기능	우선순위
방 만들기(기간·동행자) · 링크 초대	MVP
1차 검색으로 5곳 찾기 + 장소 직접 추가	MVP
2차 모두의 후보에서 5개 선택 + '꼭' 지정 + 거부권	MVP
조건 입력 (하루 예산 · 걸음 수 · 활동 시간)	MVP
AI가 합의에 맞는 곳 추가	MVP
비공개 입력 · 참여 현황	MVP
규칙 기반 합의안 생성	MVP
코어/옵션 분리	MVP
지도 동선 + 거리 계산	MVP
AI 빈칸 채우기 · 설명 생성	MVP
n빵 정산 · 결제 룰렛	MVP
트레이드오프 자동 조정	2차
양보 기록 · 다음 여행 우선권	2차
여행 중 실시간 재조정	2차
지도 앱 저장 목록 가져오기	검토 보류

기존 작업에서 재사용

• 취향 슬라이더 컴포넌트와 트레이드오프 엔진
• 5개 도시 106개 장소 데이터 (좌표 · 주소 · 한국인 리뷰 · 예상 비용)
• 일정 생성 · 지도 · 일정 편집 화면
• 그룹 초대, n빵 정산, 결제 룰렛

버리는 것

• 카드 소비 분석, 예산 자동 산출, 카드 혜택 비교
• 소비 성향 분류
• 지도 앱 저장 목록 내보내기·업로드

---

10. 리스크와 대응

리스크	대응
5명이 각자 입력하게 만들기 어려움	입력 40초 이내. 미참여자가 있어도 결과가 나오게 설계
인원이 적으면 겹침 경쟁이 안 생김	인원수에 따라 1인당 선택 개수 조정
장소 선택이 인기 쏠림으로 흐를 수 있음	입력 중 비공개 유지. '꼭' 1개로 소수 취향 보장
후보 장소가 부족하면 선택의 의미가 없음	도시별 25곳 이상 확보
AI 생성 일정의 신뢰도	채택은 규칙으로, AI는 빈칸·설명만 담당
양보 기록이 비공개 원칙과 충돌	양보량은 본인에게만. 그룹에는 우선권만 표시
예산을 장소 선택으로 추정할 수 없음	예산·체력은 슬라이더로 별도 입력

---

11. 데모 시나리오

1. 5명이 오사카 3박4일 방에 참여합니다

2. 각자 후보 25곳 중 5곳씩 고릅니다 — 서로 안 보입니다

3. 슬라이더로 예산과 체력을 입력합니다 — 다섯 명 값이 제각각입니다

4. 30초 뒤 합의안이 나옵니다

   1인 68만원 · 3성급 호텔 · 하루 5시간 활동으로 맞췄습니다 이 조건이면 다섯 분 모두 무리하지 않습니다 80만원으로 올리면 두 분이 부담스러워합니다

5. 지도에 코어 동선이 그려지고, 옵션 장소는 다른 색으로 표시됩니다

6. "정민님의 꼭 가고 싶은 곳 — 지켜졌습니다"

심사에서 차별점이 드러나는 지점은 4번과 6번입니다.

---

12. 다음 단계

• 화면 흐름 상세 설계 (와이어프레임)
• 채택 규칙 수치 검증 (인원별·기간별 시뮬레이션)
• 후보 장소 데이터 확장 (도시별 25곳 이상)
• 입력 시간 측정 (목표 40초 이내)
• 서비스 이름 정하기
• MVP 개발

---

협업 규칙

• main 직접 푸시 금지. feature 브랜치 → PR → 리뷰 1인 → merge.
• 작업은 시작할 때 Draft PR을 먼저 열고 assignee를 단다. 누가 무엇을 잡았는지 보여야 3명이 겹치지 않는다. 커밋이 하나도 없으면 PR을 만들 수 없으므로 빈 커밋으로 연다 — git commit --allow-empty -m "작업 시작". 끝나면 Ready for review로 전환한다. 문서 수정 같은 단발 변경은 예외.
• 이슈는 따로 만들지 않는다. 논의가 이슈와 PR 두 군데로 흩어지면 한쪽이 방치되므로 PR 한 곳에 모은다.
• 브랜치명: <타입>/<요약> 예) feat/search-filter, fix/map-marker
• 커밋 메시지: 한 줄 명령형. 예) 추천 결과 카드 레이아웃을 추가한다
• 비밀값(API 키, 계정 정보)은 커밋하지 않는다. .env는 gitignore한다.