공간대여 예약 홈페이지 리뉴얼 전문가

[프로젝트 개요]
- 서울 7개 지점에서 연습실을 시간 단위로 대관하는 예약 홈페이지를 반응형으로 재구축합니다. PC 화면과 모바일 화면(/m/)으로 나뉜 현행 소스를 반응형 단일 소스로 통합하고, 예약 한 건 단위로 광고 유입 경로가 기록되게 하며, 운영자가 예약 데이터를 직접 내려받을 수 있게 하는 것이 목표입니다.
- 기존 서비스의 예약 흐름은 유지하되 화면과 코드를 다시 만드는 리뉴얼이며, 서비스 전면 재설계가 아닙니다. 운영 중인 예약·회원 데이터는 전량 이관합니다.
- 인프라 이전, 관리자 화면 안의 통계 대시보드, 접속 로그 이관은 이번 범위에 포함하지 않습니다.

[클라이언트 소개]
- 서울 7개 지점에서 댄스·연기·뮤지컬·보컬·악기 연습 공간을 시간 단위로 대관하는 서비스입니다. 자체 제작한 홈페이지로 실시간 예약을 받아 왔고 누적 예약은 5만 7천 건을 넘습니다. 일반 이용자가 직접 예약하는 고객용 서비스이며, 모든 지점은 무인으로 운영되어 예약자가 결제 후 발송되는 안내 문자로 출입 정보를 받습니다. 지점은 앞으로도 늘어날 예정입니다.

[프로젝트 배경 및 목표]
- 지금 상황: PC 화면과 모바일 화면(/m/)이 별도 소스로 존재합니다. 문구 하나를 고쳐도 두 곳을 손대야 하고 한쪽만 반영되는 일이 반복됩니다. 모바일 접속 시 PC 페이지가 자바스크립트로 모바일 경로로 보내는 방식이라, 그 과정에서 주소의 파라미터가 사라지고 원래 가려던 페이지가 아니라 메인으로 떨어집니다. 예약 데이터에는 결제 수단만 남고 유입 경로가 기록되지 않아, 광고비를 집행해도 어느 지점의 어느 예약이 그 광고에서 왔는지 확인할 방법이 없습니다. 관리자 화면에는 데이터 내보내기 기능이 없어 매출 집계나 지점별 분석이 필요할 때마다 수작업으로 추출하고 있습니다. 8년 가까이 기능을 덧붙이며 운영해 온 구조라 지금 형태로는 더 유지하기 어렵다고 판단했습니다.
- 끝나면 이렇게 되기를 바랍니다: 화면을 한 곳만 고치면 PC와 모바일에 함께 반영되고, 예약 한 건 단위로 유입 채널이 남아 지점별로 광고 성과를 분해할 수 있게 됩니다. 지금 손이 가장 많이 가는 일이 예약 데이터 수작업 추출인데, 운영자가 기간·지점 조건으로 직접 내려받게 되면서 그 일이 없어집니다.
- 다만 이런 점이 우려됩니다: 운영 중인 서비스이므로 데이터 이관이 이번 프로젝트에서 위험도가 가장 높은 구간입니다. 예약 원장 57,225행과 2026년 예약 5,079행은 컬럼 구성이 달라 그대로 합칠 수 없고, 별도 상주 인력 없이 예약과 안내 발송이 맞물려 돌아가는 구조라 이관이 어긋나면 출입 안내까지 함께 틀어집니다. 기존 URL이 다수 색인되어 있어 주소 구조가 바뀌는 과정에서 검색 유입이 빠지는 것도 우려되는 부분입니다.

[필수 과업 범위와 결과물]
1. 수행 범위
- 상세 기획: 요구사항 정의서를 발주자가 제공하므로 요구사항 정의 공수는 범위 밖입니다. 다만 착수 전 화면설계서·ERD·API 명세·URL 매핑표를 작성해 승인받은 뒤 개발에 들어가는 순서로 진행합니다.
- UI·UX 디자인: 반응형 단일 소스 기준 모바일 최적화 화면 (현행 화면 파일 324본을 반응형으로 재구성)
- SW 개발: 사용자 웹, 관리자 웹, 조회 전용 API, DB 구축
- 데이터 이관: 예약 원장 57,225행, 2026년 예약 5,079행, 회원 정보 전량. 접속 로그 825,725행은 이관 대상이 아니며 아카이브로 보관합니다.
- SEO·URL 이행: 기존 URL 전체에 대한 301 매핑표 작성과 적용, robots.txt·사이트맵 재작성
- 인프라: 현행 서버를 그대로 사용하며 인프라 이전은 범위 밖입니다.
- 유지보수: 하자보수 3개월을 계약 범위에 포함합니다.

2. 상세 기능 요구 사항
2-1. 사용자 프론트엔드 (PC/Mobile 반응형 웹)
- 지점·룸 탐색: 지점 카드 목록 메인, 지점 소개 화면 (지점 7곳, 지점별 룸 1~4개)
- 실시간 예약: 지점 선택 → 룸 선택 → 캘린더 날짜 선택 → 잔여 시간 슬롯 확인 → 시간 다중 선택 → 인원 입력 → 예약자 정보 → 결제 → 즉시 확정 (호스트 승인 단계 없음)
- 동시 예약 충돌 방지: 같은 슬롯에 두 건이 들어가지 않도록 슬롯 잠금 처리
- 요금 자동 계산: 기본 인원 초과 시 초과 인원 × 이용 시간 × 단가 산출 (기본 인원은 룸마다 상이)
- 예약 취소·변경: 환불 규정 기준 금액 자동 판정 (결제 후 2시간 이내 전액 환불, 이후 이용일까지 남은 기간에 따라 차등)
- 회원·비회원 예약: 비회원 예약 지원, 회원 마이페이지 예약 내역 조회 및 취소
- 예약 확인·게시판·회원 기능: 기존 이용자 화면 구성 재구현
2-2. 결제·알림 연동
- 국내 PG 연동: 신용카드·무통장 입금 결제, 부분 취소 및 환불 처리 포함
- 알림 발송: 카카오 알림톡 우선 발송 및 실패 시 SMS 자동 폴백 (현재는 관리자 화면에서 별도 버튼으로 분리되어 수동 판단)
- 안내문 템플릿: 지점별 문안과 공통 템플릿 2단 구조 유지, 치환자 문법 1종으로 통일 (현재 자체 문법·알림톡 문법·문자 API 문법 3종 혼재)
- 지점 그룹 일괄 편집: 같은 공간을 쓰는 지점 묶음 단위 출입 안내문 동시 반영
2-3. 관리자 백오피스 (PC 웹)
- 지점·룸 관리: 등록 및 수정, 코드 수정 없이 관리자 화면에서 신규 지점 추가 완결
- 예약 관리: 예약 목록 조회 및 상태 관리
- CSV 다운로드: 기간·지점 조건 지정 예약 데이터 내보내기
- 조회 전용 API: 외부 분석 도구의 정기 수집용 예약 데이터 제공
- 발송 화면: 문자 발송, 알림톡 발송, 접속 로그 화면 재구현
- 환경 설정: 요금·운영시간·환불규정 설정
2-4. 유입 경로 계측
- 광고 파라미터 보관: 사이트 진입 시 주소의 utm 계열·네이버 NaPm 파라미터 보관 (보관 기간 30일)
- 예약 건 귀속 기록: 예약 저장 시 보관된 유입 정보 함께 기록 (첫 유입/마지막 유입 기준은 발주자 확정값 적용)
- 기존 계측 이식: Google Tag Manager 컨테이너 및 네이버 전환추적 스크립트 신규 사이트 이식
- 완료 페이지 값 전달: 예약 완료 페이지에 예약번호·결제금액 전달 (현재는 값을 받지 않는 정적 페이지)
2-5. 데이터 이관
- 예약 원장 이관: 57,225행 전량 이관 및 접수일 보존 (2018년~2025년 12월)
- 2026년 예약 병합: 5,079행 이관, 예약 원장과 컬럼 구성이 달라 별도 병합 규칙 필요 (접수일 컬럼 없음)
- 회원 정보 이관: 전량 이관
- 전환 방식: 무중단 전환, 어려울 경우 새벽 점검창(02시~05시) 안에 완료
- 이관 검증: 이관 전후 건수·금액 합계·지점별 분포 3축 일치 확인 및 검증 리포트 제출
2-6. 비기능 요구
- 반응형 단일 소스: PC/모바일 이원화 통합, 기존 모바일 경로(/m/)는 301 리다이렉트로 통합 경로에 매핑
- URL 301 매핑: 기존 URL 전체 매핑표 작성·제출 및 적용
- 성능: 예약 캘린더를 포함한 주요 화면 LCP 2.5초 이하
- 업로드 보안: 업로드 디렉터리 스크립트 실행 차단, 업로드 확장자 화이트리스트 적용
- 자격 증명 분리: 외부 서비스 인증 정보 환경변수 분리 (소스 하드코딩 금지)
- 개인정보 보호: 예약자 개인정보 암호화 저장, 관리자 접근 로그 기록

3. 결과물
- 화면설계서, ERD, API 명세, URL 매핑표 (발주자 승인 후 개발 착수)
- 스테이징 환경 (주 1회 시연)
- 이관 스크립트, 이관 검증 리포트
- 전체 소스코드 (발주사 귀속, Git 저장소로 인계)
- DB 스키마
- 배포 문서, 관리자 매뉴얼
- 하자보수 3개월 (인수 확인 후 개시)

[아직 정하지 않은 범위]
- 아래는 저희 쪽에서 확정 중인 사항으로 계약 전까지 정리해 전달하겠습니다.
1. 결제 영수증 자동 발송 포함 여부 — 무통장 입금 건의 현금영수증 및 세금계산서 수요를 확인하는 중입니다
2. 현행 PG 계약의 승계 가능 여부
3. 2026년 예약 테이블 병합 규칙 — 접수일 컬럼이 없어 예약 원장과 그대로 합칠 수 없습니다. 접수일이 없는 사유와 덤프 주기를 정리해 전달할 예정이며, 병합 규칙은 제안 단계에서 함께 검토해 주세요
4. 광고 유입 귀속 기준 — 첫 유입 기준과 마지막 유입 기준 중 미정입니다. 두 방식의 장단점을 정리해 주시면 판단에 반영하겠습니다

[기술 스택]
- 서버 언어: 지정하지 않습니다. 현행은 PHP(CodeIgniter 계열, URL에 index.php 세그먼트 노출)입니다.
- DB: MySQL (기존 데이터 이관 대상)
- 결제: 국내 PG. 해외 결제 게이트웨이는 대상이 아닙니다.
- 알림: 카카오 알림톡(비즈뿌리오), SMS (현행 카페24 SMS API)
- 인프라: 현행 서버 유지
- 지원 브라우저: Chrome, Safari, 삼성 인터넷 최신 2개 버전

[클라이언트 준비 사항]
- 준비된 것: 요구사항 정의서, 지점별 룸 구성·요금 체계·운영 규정
- 준비 중인 것: 현행 소스 전체(화면 파일 324본)와 데이터베이스 스키마·데이터 덤프를 서버 정리 후 인계할 예정입니다. 위 '아직 정하지 않은 범위' 4건도 계약 전까지 정리해 전달합니다.

[예산]
- 예산: 500만~1,000만원 (부가세 별도)

[제안 포함 필수 사항]
- 지원 내용은 아래 기준으로 검토합니다.
1. 적합한 기술 스택과 그 선택 이유를 제안에 포함해 주세요. 현행 PHP를 유지하며 개선하는 방향과 신규 스택으로 전환하는 방향 중 어느 쪽을 권하시는지 근거와 함께 적어 주시면 도움이 됩니다.
2. 파트너님께서 판단하시기에 어떤 부분이 완료되어야 이 프로젝트가 성공적으로 마무리되었다고 보시는지 제안에 포함해 주세요. 전문가로서 이 프로젝트의 결과물에 대한 의견 부탁드립니다.
3. 예약 원장 5.7만 건을 무중단으로 이관할 경우의 절차와 실패했을 때의 롤백 방안을 제안에 포함해 주세요. 본 프로젝트에서 가장 큰 위험 요소 하