숙박 예약 통합관리 서비스(PMS) 채널 연동 오류 수정·안정화 전문가

[프로젝트 개요]
- 저희가 React·Firebase로 직접 만들어 운영 중인 숙박 예약 통합관리 웹 서비스(PMS)에서, 예약 취소·게스트 메시지·요금 변경이 Airbnb·Booking.com·Agoda·Trip.com에 한 번에 전송되지 않는 연동 오류를 고쳐 안정적으로 운영할 수 있게 만들려 합니다. 기존 소스를 인수해 코드를 리뷰하고 수정하는 작업이며, 채널 연동은 채널매니저 Channex API를 거칩니다.

[클라이언트 소개]
- 소형 숙박업을 운영하면서 숙박업 운영자 커뮤니티를 함께 꾸리고 있습니다. 호텔 같은 큰 업장이 아니면 여러 예약 플랫폼을 한곳에서 관리하기 어려워, 커뮤니티 회원들을 위해 이 서비스를 만들었습니다. 사용자는 소형 숙박업 운영자입니다.
- 프로젝트 의사결정 구조: 대표 1인이 요구사항 확정, 문의 응답, 미팅, 범위 변경 승인을 모두 맡습니다.
- 개발 지식: 개발자 출신으로 이 서비스를 AI 코딩 도구로 직접 만들었습니다. 코드를 읽고 기술 논의를 할 수 있지만, 연동 오류의 원인을 끝까지 잡을 시간과 경험이 부족해 전문가께 맡기려 합니다.

[프로젝트 배경 및 목표]
- 지금 상황: 예약을 불러오는 것은 문제가 없습니다. 그런데 예약이 취소됐을 때, 게스트와 메시지를 주고받을 때, 요금을 바꿨을 때 이 내용이 각 플랫폼에 한 번에 전송되지 않습니다. 취소 뒤에 판매중지가 남거나, 채널 연결이 끊기거나, 예약 변경 알림(웹훅)이 비활성화된 적도 있습니다. 커뮤니티 회원들에게 본격적으로 배포하기 전에 이 문제부터 해결하려는 것이 지금 진행하는 이유입니다.
- 끝나면 이렇게 되기를 바랍니다: 한 번 바꾸면 네 플랫폼에 모두 반영되고, 실패하면 제가 먼저 알림을 받아 바로 재처리할 수 있기를 바랍니다. 플랫폼마다 들어가 반영됐는지 하나씩 확인하는 일이 없어지는 것이 목표입니다.
- 다만 이런 점이 우려됩니다: AI 코딩 도구로 빠르게 만든 코드라 구조가 정리돼 있지 않습니다. 고치는 과정에서 지금 잘 되는 예약 불러오기까지 깨지거나, 실제 손님 예약이 잘못 바뀌는 일이 생길까 걱정됩니다.


[필수 과업 범위와 결과물]
1. 수행 범위
- 상세 기획: 예약·연동 코드 리뷰와 오류 원인 판정, 채널별 지원 현황 정리, 예약 데이터 규칙(숙소·객실·요금제 대응, 취소 규칙) 문서화
- SW 개발: 기존 React·Firebase 소스의 예약·채널 연동 오류 수정, 기록 대조·재처리, 장애 감지·알림, 핵심 시나리오 자동 테스트
- 인프라 구축·배포: 운영과 분리된 시험 환경 구성(Channex 시험 계정 연결), 배포 전후 점검·되돌리기, 백업 확인·복구 시험. 계정은 저희 명의로 보유하고 있습니다
- 유지보수: 검수 후 60일 하자보수

2. 상세 기능 요구 사항
2-1. 인수·코드 리뷰
- 코드 리뷰: 예약·채널 연동 부분 소스와 Firebase 데이터 구조 분석, 오류별 재현·원인·수정 방향 판정표
- 시험 환경: 실제 손님 예약과 분리된 검증 환경 및 Channex 시험 계정 연결
- 채널 지원 현황: Airbnb·Booking.com·Agoda·Trip.com별 예약·재고·요금·메시지 지원 범위와 제약 정리

2-2. 예약·채널 연동 오류 수정
- 예약 취소 반영: 취소 후 재고·판매 상태 복원 (수동 판매중지·다른 예약은 유지, 중복 취소 시 과다 복원 방지)
- 예약 변경 알림 처리: 중복·순서 뒤바뀐 알림 처리와 처리 완료 응답(ACK), 처리 중 재시작 시 미처리 건 복구
- 요금 변경 전송: 전 채널 반영 확인 및 실패 재전송
- 메시지 송수신: 게스트 메시지 전송 오류 수정과 중복 발송 방지
- 연결·웹훅 장애 대응: 채널 연결 끊김·웹훅 비활성화 감지와 빠진 예약 보충
- 외부 호출 실패 처리: 인증 실패·호출 제한·타임아웃·응답 유실 등 유형별 재시도와 중복 실행 방지

2-3. 기록 대조·재처리
- 기록 대조: 처리 실패·누락·중복 점검, 내부 데이터와 외부 채널의 불일치 확인 및 관리자 수동 재동기화·복구
- 실패 건 재처리: 실패 건 목록과 재처리, 채널 반영 상태(마지막 정상 시각) 표시

2-4. 운영 안전장치
- 장애 알림: 연결·웹훅·실패율 경보의 담당자 알림 (로그의 개인정보·인증정보 가림)
- 자동 테스트: 예약 생성→변경→취소, 반복·역순 알림 시나리오
- 배포·백업: 배포 전후 점검과 되돌리기, 백업 확인 및 실제 복구 시험
- 권한 점검: 숙소·사용자별 접근 권한 점검 (다른 숙소 데이터 차단)
- 수정은 시험 환경에서 먼저 검증하며, 실제 손님 예약·재고는 임의로 변경하지 않습니다.

3. 결과물
- 전체 소스코드 (저희 소유 저장소에 반영, 버전별 변경 내역 포함)
- 데이터베이스 구조 정의서 (Firebase 데이터 구조와 예약 데이터 규칙)
- 인수 진단 보고서 (오류별 재현·원인·수정·회귀 시험 결과, 채널별 지원 현황)
- 운영 매뉴얼 (장애 알림 대응·재처리·배포·되돌리기·백업 복구 절차)
- 자동 테스트 코드와 시험 결과

[아직 정하지 않은 범위]
- 아래는 저희가 확정하지 못한 항목입니다. 포함하는 편이 나은지, 뺀다면 나중에 어떻게 붙일 수 있는지를 의견과 함께 적어 주세요.
1. 코드 리뷰 중 발견되는 예약 외 오류 — 예약 기능 밖에서도 수정이 필요한 부분이 나오면, 먼저 보고받고 승인한 뒤 작업하려 합니다. 보고·승인 방식과 비용 산정 방식을 제안해 주세요
- 다음 단계로 미룬 범위: 웹 화면 UI/UX 리뉴얼(40~60대 운영자 대상), Android·iOS 앱(예약 확인·푸시 알림), AI 메시지 자동 응답(별도 프로젝트로 등록 예정)은 이번 안정화 뒤에 진행합니다. 이번에 메시지 송수신과 데이터 구조를 정리할 때 이 확장을 고려해 주세요.

[클라이언트 준비 사항]
- 준비된 것: 운영 중인 웹 서비스와 전체 소스(React·Vite·Firebase, Vercel 배포), Channex 채널매니저 계정과 4개 채널(Airbnb·Booking.com·Agoda·Trip.com) 연결, 요구사항 정의서와 오류 목록
- 이 프로젝트 담당: 대표 1인이 담당하며, 코드와 기술 내용을 직접 확인할 수 있습니다

[오픈 시점과 예산]
- 개발 기간: 약 2개월
- 예산: 1,000만원 이내 (부가세 별도)

[제안 포함 필수 사항]
- 지원 내용은 아래 기준으로 검토합니다.
1. 기술 스택 제안 — 기존 React·Firebase 구조를 유지할지, 연동 처리 부분(웹훅 수신·재시도·대기열)을 어떤 방식으로 보강할지 이유와 함께 제안해 주세요.
2. 완료 기준에 대한 전문가 의견 — 어떤 부분이 완료되어야 이 프로젝트가 성공적으로 마무리되었다고 보시는지 적어 주세요.
3. 아직 정하지 않은 범위에 대한 의견 — 포함하는 편이 나은지, 뺀다면 나중에 어떻게 붙일 수 있는지 적어 주세요. 각 항목은 기본 범위에 섞지 말고 별도 견적으로 나누어 적어 주세요. 공고만으로 판단이 어려워 확인이 필요한 부분도 함께 적어 주세요.
4. 기존 기능 보호 방안 — 지금 잘 동작하는 예약 불러오기를 깨뜨리지 않고, 실제 손님 예약을 건드리지 않으면서 오류를 재현·수정하는 방법을 제안에 포함해 주세요. 정리되지 않은 코드를 고치는 일이라 이 부분을 특히 중요하게 보고 있습니다.
5. 포트폴리오·경험 — 채널매니저(Channex 등)·숙박 예약 플랫폼 연동 경험과, 다른 사람이 만든 서비스를 인수해 고친 경험을 알려 주세요.