Portfolio

HonestPick

예약·방문 이력 기반으로 리뷰 권한을 통제한 음식점 리뷰·예약 웹서비스

2025.05 ~ 2025.06 · Java / JSP / Servlet / Oracle · 백엔드 2인 팀 프로젝트

한눈에 보기

문제

광고성·허위 리뷰로 인해 리뷰 신뢰도 가 저하되는 문제를 정의했습니다.

해결

예약·방문 완료 이력 을 검증하여 리뷰 작성 권한을 부여하도록 설계했습니다.

담당

  • 예약/리뷰/결제/관리자 핵심 백엔드 구현
  • 리뷰 작성 권한 검증 로직 구현
  • Toss 결제 · Kakao 지도 API 연동

핵심 결과

  • 허위 리뷰 유입 경로를 구조적으로 차단했습니다.
  • 신고·제재 등 운영 흐름을 데이터로 추적 가능하게 구성했습니다.
  • 멤버십 결제와 노출 정책을 서비스 구조에 반영했습니다.

프로젝트 개요

HonestPick은 예약·방문 완료 데이터를 근거로 리뷰 작성 권한을 부여 하여, 리뷰 신뢰도를 확보한 음식점 리뷰·예약 웹서비스입니다.

서비스 흐름

  • 매장 선택 → 예약 → 방문 완료 → 리뷰 작성
  • 신고·숨김 처리 등 운영 기능 제공

비즈니스 구조

  • 점주 멤버십 결제 시 매장 상단 노출 정책 적용
  • 사용자(신뢰)·점주(노출)·관리자(운영) 관점 요구사항 반영

주요 기능

예약 기반 리뷰

예약·방문 이력이 있는 사용자만 리뷰 작성 가능

예약 · 방문 처리

예약 생성부터 방문 완료까지 상태 기반 흐름 구현

점주 멤버십 결제

Toss 결제 연동 및 멤버십 매장 상단 노출 정책 반영

관리자 기능

회원/매장/리뷰 관리 및 신고 리뷰 제재(숨김) 처리

담당 역할 & 기여

기능 구현과 함께 “예약 기반 리뷰” 규칙이 운영에서 일관되게 적용되도록 데이터 흐름과 검증 로직을 설계·구현했습니다.

  • 음식점/메뉴/리뷰/예약 도메인 CRUD 및 비즈니스 로직 구현
  • 예약·방문 상태 기반 리뷰 작성 권한 검증 로직 구현
  • Toss 결제 API 연동 및 점주 멤버십 결제/갱신 이력 관리
  • 멤버십 매장 상단 노출 정책(알고리즘) 설계
  • Kakao 지도 API 연동(위치 기반 매장 조회/상세)
  • 세션/쿠키 기반 로그인 유지 및 자동 로그인 구현
  • 관리자 페이지(회원/매장/리뷰 관리 및 제재 기능) 구현
가장 고민했던 문제 예약 기반 리뷰를 확실하게 보장하는 방법

예약·방문 완료 사용자만 리뷰를 작성 하도록 보장하는 것이 목표입니다. 다만 “예약”만으로는 방문 여부를 증명하기 어렵기 때문에 추가 검증이 필요했습니다.

문제 정의

  • 예약만 생성하고 미방문 상태로 남는 케이스가 발생합니다.
  • 검증을 코드에만 의존할 경우 운영·추적이 어려워집니다.

해결 방식

  • 예약 테이블과 리뷰 테이블을 연결해 “근거 데이터”를 남기도록 설계했습니다.
  • 예약 상태(예약/방문완료/취소)를 분리해 관리했습니다.
  • 리뷰 작성 시, 해당 예약이 “방문완료”인지 확인하도록 검증 로직을 구현했습니다.

결과

  • 허위 리뷰가 생길 수 있는 경로를 구조적으로 줄였습니다.
  • 관리자 기능(신고/제재)에서도 근거 데이터가 남아 운영이 쉬워졌습니다.

주요 화면

HonestPick 메인 화면
메인 화면
매장 목록
매장 목록
매장 상세
매장 상세

기술 스택

  • Language : Java
  • Web : JSP / Servlet, JSTL
  • DB : Oracle
  • Infra : Tomcat 9
  • 외부 API : Kakao Map, Toss 결제

주요 모듈

Reservation Review Payment Admin Owner Membership Map API Login Session/Cookie
DB 설계 포인트 예약 기반 신뢰 리뷰를 위한 설계 의도
  • Reservation – 예약이 “방문 근거”의 출발점이 되도록 설계하고, 예약 상태(예약/방문완료/취소/노쇼)로 리뷰 작성 가능 여부를 통제
  • Review – 리뷰를 예약(ResNo)과 연결해 ‘실방문 리뷰’만 노출 가능하게 하고, 별점(ReviewEstimation)과 추천수(ReviewRecommendation)를 분리해 평점 조작 리스크를 낮춤
  • Store – 매장 기본정보(주소/연락처/편의시설)와 운영정보(스케줄)를 분리 수준으로 관리해, 노출 정책/검색/필터 요구가 늘어도 확장 가능하게 구성
  • Menu – 메뉴를 Store FK로 종속시켜 매장별 메뉴/가격 변동을 이력화(업데이트 시간)할 수 있게 하고, 상세 설명을 길게 저장해 SEO/검색 품질을 확보
  • WishList – “찜”을 단순 교차 테이블로 두어 조회가 빠르고, 개인화 추천/재방문 유도(찜 기반 알림, 인기 매장 등) 기능 확장에 유리
  • Inquiry – 문의/CS를 별도 테이블로 관리해 운영 대응(처리 상태, 응답 SLA)을 구조화하고, 신고/분쟁 케이스의 증빙 흐름으로 연결 가능
  • AutoLogin – 토큰/만료를 별도 관리해 보안(세션 탈취 대응)과 기기별 로그인 유지 정책을 서버에서 통제 가능
  • Advertisement – 광고를 리뷰/매장과 분리해 노출 정책(기간/소재/문구) 변경에도 데이터 모델이 흔들리지 않도록 설계
기술적 고민 해결 전략 및 트레이드오프
  • 외부 API(Toss/Kakao) 연동 시 성공/실패 흐름을 분리하고 예외 케이스를 처리했습니다.
  • 세션/쿠키 기반 로그인에서 만료·삭제 상황을 고려해 상태를 정리했습니다.
  • 복합 JOIN 조회에서 정합성을 우선으로 하고, 조회 목적에 따라 쿼리를 분리했습니다.
  • JSP/Servlet URL 패턴을 통일해 기능 단위로 관리하기 쉽게 구성했습니다.