← WORK 목록으로
KOREA위시켓웹 개발

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

React·Vite·Firebase(Vercel 배포)로 운영 중인 숙박 예약 통합관리 서비스(PMS)의 채널 연동 오류를 수정·안정화하는 유지보수 프로젝트입니다. Channex 채널매니저 API를 통해 Airbnb·Booking.com·Agoda·Trip.com 4개 채널에 예약 취소·게스트 메시지·요금 변경이 일괄 반영되도록 하고, 웹훅 수신·재시도·대기열·장애 알림·기록 대조 재처리 등 연동 안정성을 확보하는 것이 핵심입니다. 외부 API 연동, 멱등성·재시도·웹훅 처리 경험이 있고 AI로 급조된 코드를 안전하게 인수·리팩터링할 수 있는 백엔드 중심 풀스택 개발자에게 적합합니다.

2026.10.15VIEW 5위시켓에서 수집
Budget6,666,666원
Difficulty고급
Duration1.5~2개월
Work style외주
Required stack

필요 기술

ReactFirebaseViteVercelChannex APIWebhookNode.js
Project brief

프로젝트 내용

[프로젝트 개요]
- 저희가 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 등)·숙박 예약 플랫폼 연동 경험과, 다른 사람이 만든 서비스를 인수해 고친 경험을 알려 주세요.
지원 기회 분석

지원 전에 볼 것

핵심 요구사항

  • Channex API 기반 4개 OTA 채널 연동 오류 수정(취소 반영·요금 전송·메시지 송수신)
  • 웹훅 수신 안정화: 중복·순서 역전 처리, ACK, 재시작 시 미처리 건 복구
  • 외부 호출 실패(인증·레이트리밋·타임아웃·응답 유실) 유형별 재시도와 멱등성 보장
  • 내부 데이터와 외부 채널 불일치 기록 대조·수동 재동기화·실패 건 재처리 UI
  • 운영/시험 환경 분리(Channex 시험 계정), 배포 전후 점검·롤백·백업 복구 시험
  • 핵심 시나리오(생성→변경→취소, 반복·역순 알림) 자동 테스트 작성

예상 산출물

  • 수정된 전체 소스코드(클라이언트 저장소 반영, 변경 내역 포함)
  • 인수 진단 보고서(오류별 재현·원인·수정·회귀 시험, 채널별 지원 현황)
  • Firebase DB 구조 정의서 및 예약 데이터 규칙
  • 운영 매뉴얼(장애 알림·재처리·배포·롤백·백업 복구)
  • 자동 테스트 코드 및 시험 결과

매력 포인트

  • 오류 목록·요구사항 정의서 등 스펙이 비교적 명확하고 환경이 준비됨
  • 기술 이해도 있는 대표 1인 단일 의사결정 구조로 커뮤니케이션 효율적
  • 60일 하자보수 명시 및 분리된 시험 환경 제공

확인할 점

  • AI 코딩 도구로 급조되어 구조가 정리되지 않은 코드를 인수해야 함(숨은 난이도·리팩터링 리스크)
  • 운영 중 실서비스로 실제 손님 예약·재고를 건드릴 위험이 있어 회귀 리스크가 큼
  • '아직 정하지 않은 범위(예약 외 오류)'로 스코프가 확장될 여지가 있음
Client signal

클라이언트 정보

회사 · 위시켓 / 지역 · 서울특별시 중구 / 고용형태 · CONTRACTOR
START THE LOOP · CHOOSE

시장과 사람의 답을 봤다면,
다음 결과물의 구조를 고릅니다.

한 번의 결과에 기대지 않고 다시 만들 수 있도록, 문제 발견부터 제작·배포·수익화까지 이어지는 전체 흐름을 익혀보세요.

TTJ CLASS에서 다음 구조 고르기 →
처리 중...