Nested는 이미 상당 부분 구현돼 있습니다. 상태 열을 반드시 확인하세요. ✅는 이미 동작합니다. 다시 만들지 마세요.
상태 표기
- ✅ 완료 — 실제 API 연동, 동작함
- 🟡 연결 필요 — 백엔드는 있는데 화면이 데모 데이터 → 프론트만 작업
- 🔴 미구현 — 백엔드 없음 → 풀스택 작업
| 역할 | 담당 영역 | 담당 백엔드 모듈 | 담당자 |
|---|---|---|---|
| A. AI 엔지니어 | 추천·매칭 (신규 개발) | (신규) | |
| B. 회원/프로필 풀스택 | 인증·계정·프로필·알림 | auth, notifications |
|
| C. 주거 등록/관리 풀스택 | 호스트·숙소 등록·관리자 | rooms, admin, storage |
|
| D. 검색/상세/상호작용 풀스택 | 검색·예약·메시지·커뮤니티 | reservations, messages, chat, community, favorites |
|
| E. 총괄/통합 | 아키텍처·인프라·통합·리뷰 | 전체 | 배병환 |
모듈이 겹치지 않게 나눴습니다. 다만 몇 군데 조율이 필요합니다 → E-3 참고
⚠️ 현재 Nested에는 AI 기능이 전혀 없습니다. 다른 역할과 달리 기존 코드에 기댈 게 없습니다. 설계부터 시작해야 합니다.
| 기능명 | 기능 설명 | 상태 | 우선순위 |
|---|---|---|---|
| 성향 데이터 스키마 설계 | 추천에 쓸 사용자 성향·선호 데이터 정의 | 🔴 | 1 |
| 성향 설문 | 가입 시 생활 패턴 조사 (흡연·소음·청결·생활시간대 등) | 🔴 | 1 |
| 성향 수정 | 가입 후에도 설문 내용 변경 | 🔴 | 2 |
데이터가 없으면 추천도 매칭도 불가능합니다. 이게 가장 먼저입니다.
결정할 것:
User에 성향 필드를 추가할지, 별도UserPreference모델을 팔지. 후자를 권합니다 (설문 항목이 늘어날 수 있으므로).
⚠️ 스키마 변경은 E(총괄)와 반드시 협의. 다른 역할도 스키마를 건드립니다.
| 기능명 | 기능 설명 | 상태 | 우선순위 |
|---|---|---|---|
| 매칭 알고리즘 | 성향 기반 궁합 점수 계산 | 🔴 | 2 |
| 매칭 화면 | /match 페이지 |
🔴 | 2 |
| 매칭 이유 표시 | 왜 이 사람을 추천하는지 근거 | 🔴 | 3 |
/match페이지가 UI만 데모로 존재합니다 (백엔드 없음). 화면을 재활용할지 새로 짤지는 자유입니다.
| 기능명 | 기능 설명 | 상태 | 우선순위 |
|---|---|---|---|
| 개인화 숙소 추천 | 성향·검색 이력 기반 | 🔴 | 3 |
| 추천 이유 표시 | 추천 근거를 자연어로 설명 | 🔴 | 3 |
| 유사 숙소 추천 | 상세 페이지의 "비슷한 숙소" | 🔴 | 3 |
- 규칙 기반 vs ML — 초기엔 규칙 기반(가중치 점수)으로도 충분합니다. 사용자 데이터가 없는 상태에서 ML은 학습할 게 없습니다. 데이터가 쌓이면 고도화하세요.
- LLM 활용 — 추천 이유를 자연어로 생성하는 데 쓸 수 있습니다.
- 계산 시점 — 실시간 vs 배치 후 캐시. Redis가 이미 있습니다.
⚠️ D(검색)와 협의: 추천 결과를 검색 API에 녹일지, 별도 엔드포인트로 뺄지.
담당 모듈: auth, notifications, notifications-api
| 기능명 | 기능 설명 | 상태 |
|---|---|---|
| 로컬 회원가입 / 로그인 | 이메일·비밀번호 | ✅ |
| 소셜 로그인 | 구글·카카오·네이버 (자동 가입) | ✅ |
| 소셜 로그인 콜백 | 토큰 전달 → 로그인 처리 | ✅ |
| 자동 로그인 | JWT + refresh token | ✅ |
| 로그아웃 | 토큰 폐기 | ✅ |
| 내 정보 조회 | GET /auth/me |
✅ |
| 기능명 | 기능 설명 | 상태 | 우선순위 |
|---|---|---|---|
| 프로필 수정 | 이름·자기소개 변경 | 🔴 | 1 |
| 설정 페이지 | /me/settings 실제 동작 |
🔴 | 2 |
| 비밀번호 변경 | 기존 비밀번호 확인 후 변경 | 🔴 | 2 |
| 회원 탈퇴 | 계정 삭제 | 🔴 | 3 |
| 비밀번호 찾기 | 이메일로 재설정 링크 | 🔴 | 3 |
프로필 수정 (첫 작업 추천):
PATCH /auth/me신규 추가User.bio필드는 이미 있습니다. 스키마 변경 불필요 → 바로 시작 가능⚠️ 이메일·role은 수정 불가로 막으세요. role을 바꿀 수 있으면 누구나 관리자가 됩니다.
회원 탈퇴 (정책 논의 필요): 예약·리뷰·메시지가 남은 사용자를 어떻게 처리할지. 하드 삭제 vs 소프트 삭제(익명화). E와 상의하세요.
| 기능명 | 기능 설명 | 상태 | 우선순위 |
|---|---|---|---|
| 알림 조회 | 목록 + 안읽음 수 | ✅ | - |
| 개별/전체 읽음 | 읽음 처리 | ✅ | - |
| 실시간 알림 | 이벤트 발생 시 즉시 수신 | 🟡 | 2 |
| 알림 클릭 이동 | 알림 → 해당 페이지 | 🟡 | 3 |
| 알림 삭제 | 알림 삭제 | 🔴 | 3 |
⚠️ 실시간 알림 — D와 반드시 협의. 백엔드에 Socket.io 게이트웨이가 이미 있습니다. 알림과 메시지가 같은 소켓을 씁니다. 한쪽이 연결 로직을 만들고 공유하세요. 중복 구현하면 소켓이 두 개 열립니다.
| 기능명 | 기능 설명 | 상태 | 우선순위 |
|---|---|---|---|
| 내 프로필 화면 | 이름·이메일·가입일 | ✅ | - |
| 내 리뷰 목록 | /me/reviews |
🟡 | 2 |
| 뱃지 | 활동 뱃지 (현재 데모) | 🔴 | 3 |
내 리뷰:
GET /reviews는roomId가 필수입니다. 작성자 기준 조회 API를 추가해야 합니다 (GET /reviews/written등).GET /reviews/mine(호스트용)이 이미 있으니 그대로 본뜨세요.
⚠️ C와 파일이 겹칩니다 —reviews.module.ts. 수정 전 알려주세요.
담당 모듈: rooms, admin, storage
| 기능명 | 기능 설명 | 상태 |
|---|---|---|
| 숙소 등록 | 사진·주소·가격·조건 | ✅ |
| 사진 업로드 | Cloudinary 서명 업로드 (파일 + URL) | ✅ |
| 주소 지오코딩 | 도로명 주소 → 좌표 (서버 처리) | ✅ |
| 실매물 확인 | 호스트 확인 체크박스 (백엔드 강제) | ✅ |
| 숙소 관리 목록 | 내 숙소 + 승인 상태 배지 | ✅ |
⚠️ 유지해야 할 설계 결정 (수정 시 주의):
- 좌표를 클라이언트에서 받지 않습니다. 서버가 주소를 지오코딩합니다. → 클라이언트가 좌표를 보내면 주소와 무관한 위치에 매물을 찍을 수 있습니다.
- 정확한 주소는 공개 API 응답에서 제거됩니다. 게스트에겐 대략 위치만. →
findOne에서address를 빼는 코드가 있습니다. 되돌리지 마세요.- 새 매물은
published: false— 관리자 승인 전까지 검색에 안 뜹니다. 버그 아닙니다.
| 기능명 | 기능 설명 | 상태 | 우선순위 |
|---|---|---|---|
| 문의함 | 게스트 문의 조회·답장 | ✅ | - |
| 리뷰 관리 | 받은 리뷰 + 답글 (본인 숙소만) | ✅ | - |
| 숙소 수정 | 등록한 숙소 정보 변경 | 🟡 | 1 |
| 예약 관리 | 호스트가 받은 예약 조회·처리 | 🟡 | 1 |
| 호스트 대시보드 | 수익·예약·문의 집계 (/host) |
🔴 | 2 |
| 캘린더 | 날짜별 예약 현황, 예약 불가일 | 🔴 | 3 |
숙소 수정:
PATCH /rooms/:id가 이미 있습니다 (이미지 교체까지 지원). 프론트 화면만 만들면 됩니다.호스트 대시보드: 집계 API가 없습니다. E와 설계 협의 — 관리자 통계와 방식이 겹칩니다.
| 기능명 | 기능 설명 | 상태 | 우선순위 |
|---|---|---|---|
| 숙소 승인 / 거부 | 대기 매물 검토 (예약 있으면 삭제 차단) | ✅ | - |
| 회원 관리 | 목록·검색·정지 | 🟡 | 1 |
| 신고 관리 | 신고 조회·상태 변경 | 🟡 | 1 |
| 관리자 대시보드 | 지표 카드 | 🟡 | 1 |
| 통계/매출 차트 | 월별 추이 | 🔴 | 2 |
| 공지/배너 | 모델·API 모두 없음 (완전 신규) | 🔴 | 3 |
🟡 우선순위 1 세 개가 첫 작업으로 가장 좋습니다. 백엔드가 이미 돌고 있습니다.
lib/api/admin.ts와app/admin/approvals/page.tsx를 그대로 본뜨세요.정확한 요청 형태 (코드 뒤질 필요 없이):
- 회원 정지:
PATCH /admin/members/:id/suspend— body{ suspended: boolean }- 신고 상태:
PATCH /admin/reports/:id— body{ status }값은RECEIVED|IN_REVIEW|RESOLVED셋뿐 (다른 값은 400)- 지표:
GET /admin/stats→{ users, rooms, reservations, gmv, commission }통계 차트:
GET /admin/stats는 합계만 줍니다. 월별 추이는 시계열 API를 새로 만들어야 합니다 (PrismagroupBy또는 raw SQL).
담당 모듈: reservations, messages, chat, community, favorites
| 기능명 | 기능 설명 | 상태 | 우선순위 |
|---|---|---|---|
| 숙소 검색 | 지역·가격·방 종류 필터 | ✅ | - |
| 숙소 상세 | 사진·가격·편의시설·호스트·리뷰·지도 | ✅ | - |
| 둘러보기 (지도) | 지도 기반 탐색 | ✅ | - |
| 찜하기 / 찜 목록 | 관심 숙소 저장·조회 | ✅ | - |
| 정렬 | 최신순·가격순·평점순 | 🟡 | 2 |
| 페이지네이션 / 무한스크롤 | 목록 페이징 | 🟡 | 2 |
둘 다 백엔드에 이미 있습니다. 프론트만 붙이면 됩니다:
- 검색 API에 커서 페이징(
nextCursor)이 있습니다sort파라미터도 이미 받습니다
⚠️ A(AI)와 협의: 추천 결과를 검색 API에 녹일지, 별도 엔드포인트로 뺄지.
| 기능명 | 기능 설명 | 상태 | 우선순위 |
|---|---|---|---|
| 예약 견적 / 생성 / 취소 | 요금 계산·예약·취소 | ✅ | - |
| 결제 승인 | PG 연동 (토스·아임포트·Stripe) | ✅ | - |
| 쿠폰 할인 계산 | pricing.ts의 couponDiscount() |
✅ | - |
| 예약 목록 (내 여행) | /me/trips |
🟡 | 1 |
| 결제 내역 | /me/payments |
🟡 | 2 |
| 쿠폰 발급/관리 | 모델은 있음, API 없음 | 🔴 | 3 |
내 여행 (첫 작업 추천):
GET /reservations가 이미 있습니다. 프론트만.쿠폰: 할인 계산 로직은 이미 있습니다 (
couponDiscount(),markCouponUsed()). 없는 건 발급·관리 API와 화면입니다. 생각보다 작은 작업입니다.⚠️ 단, 기존 로직이 실제로 예약에 연결돼 있는지 먼저 확인하세요. 로직만 있고 호출되지 않을 수 있습니다.
| 기능명 | 기능 설명 | 상태 | 우선순위 |
|---|---|---|---|
| 채팅방 개설 | 게스트↔호스트 (숙소 단위, 중복 방지) | ✅ | - |
| 메시지 목록 / 전송 | 텍스트 (DB 저장) | ✅ | - |
| 커뮤니티 글/댓글 | 작성·조회·삭제 | ✅ | - |
| 실시간 메시지 | Socket.io 연결 | 🟡 | 1 |
| 읽음 처리 | 읽음 표시·안읽음 카운트 | 🔴 | 2 |
| 이미지 전송 | 채팅 사진 첨부 | 🔴 | 3 |
실시간 메시지 (첫 작업 추천): 백엔드에
ChatGateway(Socket.io)가 이미 있습니다. 현재 프론트는 REST로만 통신해서 새로고침해야 새 메시지가 보입니다. 소켓에 연결하면 실시간이 됩니다.
⚠️ B(알림)와 반드시 협의. 알림도 같은 소켓을 씁니다. 한쪽이 만들고 공유하세요.읽음 처리:
Message.readBy필드가 이미 있습니다 (String[]). 스키마 변경 없이 백엔드 로직 + 프론트만 만들면 됩니다.이미지 전송:
Message.imageUrl필드가 이미 있습니다. 업로드는 C가 만든 Cloudinary 서비스를 재사용하세요 (/storage/cloudinary-signature).
| 항목 | 설명 | 우선순위 |
|---|---|---|
| Prisma 마이그레이션 도입 | db push로만 운영 중. 이력·롤백 없음 |
0 |
| 브랜치 보호 | PR 필수 | ✅ 완료 |
| 개발/프로덕션 DB 분리 | DB가 하나뿐 | 1 |
| 목업 데이터 정리 | 위 작업 완료 후 lib/admin.ts 등 제거 |
3 |
⚠️ 마이그레이션이 가장 급합니다.스키마를 건드리는 역할:
- A → 성향 필드 (
UserPreference신규) — 가장 큰 변경- B → 프로필 (기존
User.bio사용 → 변경 불필요), 뱃지는 신규 필요- C → 공지/배너 모델 신규 (우선순위 낮음)
- D →
Message.readBy가 이미 있어 변경 불필요즉 A가 스키마 변경의 대부분을 차지합니다. 그래도 마이그레이션 체계는 A가 시작하기 전에 갖춰야 합니다. 기능 개발 시작 전에 정리하세요. →
MIGRATION_RUNBOOK.md
| 항목 | 설명 |
|---|---|
| 스키마 변경 게이트키핑 | 모든 schema.prisma 변경은 E를 거침 |
| PR 리뷰 | 전체 PR 리뷰 |
| 아키텍처 결정 | 집계 API, 소켓 연결 방식 등 |
| 배포 관리 | Vercel · Railway |
| 공통 코드 | lib/api/client.ts, 어댑터, 공용 UI |
이 표를 회의에서 함께 보세요. 충돌 예상 지점입니다.
| 충돌 지점 | 관련 역할 | 조율 내용 |
|---|---|---|
schema.prisma |
전원 | 4명이 모두 스키마를 건드립니다. 마이그레이션 순서 조율 필수. |
| Socket.io 연결 | B, D | 알림과 메시지가 같은 소켓을 씁니다. 한쪽이 만들고 공유. |
reviews.module.ts |
B, C | B는 "내 리뷰"(작성자), C는 "리뷰 관리"(호스트). 같은 파일. |
| 집계 API 설계 | C, E | 호스트 대시보드 + 관리자 통계. 방식이 겹칩니다. |
| 추천 ↔ 검색 | A, D | 추천을 검색 API에 녹일지, 별도로 뺄지. |
| Cloudinary 업로드 | C, D | C가 만든 걸 D(채팅 이미지)가 재사용. 중복 구현 금지. |
각자 가장 쉬운 것부터 시작해 코드베이스에 익숙해지세요.
| 역할 | 첫 작업 | 난이도 | 왜 |
|---|---|---|---|
| A. AI | 성향 스키마 설계 + 설문 | 중 | 데이터 없이는 아무것도 못 합니다. E와 스키마 협의 먼저. |
| B. 회원 | 프로필 수정 (PATCH /auth/me) |
낮 | bio 필드가 이미 있어 바로 시작 |
| C. 주거 | 관리자 회원 관리 (🟡) | 낮 | 백엔드 있음. 프론트 패턴 익히기 |
| D. 상호작용 | 내 여행 (/me/trips, 🟡) |
낮 | GET /reservations 이미 있음 |
| E. 총괄 | Prisma 마이그레이션 | 중 | 나머지가 스키마를 건드리기 전에 |
B·C·D는 🟡 작업부터 시작하세요. 백엔드가 이미 돌고 있어서 프론트 클라이언트만 쓰면 됩니다. 한 번 해보면 이 코드베이스의 프론트↔백 왕복이 한 번에 이해됩니다.
A만 예외입니다. 기댈 코드가 없어서 설계부터 해야 합니다.
ONBOARDING.md— 로컬 실행, 구조, 뭐가 진짜/목업인지ISSUES.md— 상세 이슈 (완료 기준 포함)MIGRATION_RUNBOOK.md— Prisma 마이그레이션 절차 (⚠️ 프로덕션 DB 주의)