Career details
대표 프로젝트 경력기술서
전체 이력서는 Resume에 두고, 이 페이지에는 대표 프로젝트 몇 개만 최신순으로 떼어 자세히 정리했다.
아래 서사는 기존 경력기술서의 Problem / Bet / Action / Result 내용을 기준으로 한다.
- Problem
- Channel Manager MVP는 크롤링 기반 예약 동기화와 오버부킹 방지 수요를 검증했지만 안정적인 서비스 제공에는 한계가 있었다. 로그인 변경, 보안 프로토콜, 상품 식별 문제가 신뢰와 비즈니스 위험으로 이어졌다.
- Bet
- 숙박 운영자의 고통과 MVP의 사업 학습을 바탕으로, 공식 OTA/PMS 연동 기술과 국내·글로벌 OTA/PMS 스펙을 고려한 구조를 만들면 여전히 매력적인 사업이 될 수 있다고 봤다.
- Action
- 글로벌 OTA/PMS 확장을 기준으로 기획과 구조를 다시 잡았다. 채널별 프로세스와 요금 동기화 스펙을 설계하고, 긴급 설정/수정 업무를 셀프온보딩 쪽으로 옮겼다. 내부/외부 알림과 빠른 수정 가능성도 함께 설계했다.
- Result
- 클로즈드 베타 안정성 검증을 완료했고 정식 출시와 구독 전환을 계획했다. 불안정한 예약/재고/요금 동기화 구조를 통합 구조로 개선했으며, 운영 리스크를 줄이고 공식 국내·글로벌 OTA 연동, 다국어 준비, 무설치 서비스 환경을 마련했다.
- Problem
- 숙박 운영자는 빈방을 줄이기 위해 여러 OTA에 판매하지만, 재고·요금·예약을 수동으로 관리하는 일은 복잡하고 스트레스가 크다. 기존 SMS/이메일 파싱 방식은 OTA 메시지 형식 변경이나 데이터 누락에 취약해 예약 식별 실패와 신뢰 문제가 생겼다.
- Bet
- 취약한 메시지에서 데이터를 추출하기보다, 업주가 PC에서 보는 OTA 웹 정보를 RPA 기반으로 가져오면 더 안정적인 예약 연동이 가능하다고 봤다.
- Action
- OTA 채널 범위와 동기화 기간을 단계적으로 넓혀 15개 채널, 1일에서 30일, 180일 범위까지 확장했다. 누락 예약 같은 부작용을 막기 위해 `sell-stop` MVP를 냈고, 고객 만족과 인입 수요로 정성·정량 검증을 진행했다. 이후 수량 조정과 유료화도 시도했다.
- Result
- 예약 동기화 성공률은 97%에 도달했고, 펜션 고객 획득과 월 300건 이상의 인입 리드로 초기 수요를 확인했다. 다만 보안, 캡차, 플랫폼 대응과 지연 증가로 일관성 기대치와 간극이 생겼다. 재고/판매 상태 기능은 제한하고 예약 동기화만 남긴 뒤 Channel Manager 2.0으로 전환했다.
- Problem
- 가맹 신청은 지원팀과 점주 사이의 카카오톡 대화로 처리됐다. 서류와 사진 누락, 신청 지연, 휴가나 퇴사 때의 인수인계 약화, 계약 지연, 지원 피로가 반복됐다.
- Bet
- 신청 유형과 필요 서류를 웹 흐름으로 구조화하고 백오피스 처리와 연결하면 속도, 정확도, 협업이 개선될 것이라고 봤다.
- Action
- 내부 백오피스/T-board DB와 연결된 웹 신청서를 기획·구축했다. 개인/법인과 업종별 서류 체크리스트를 나누고, 카카오톡으로 링크를 보내면 백오피스 기록 생성과 담당자 배정이 자동으로 이어지게 했다.
- Result
- 신청 완료 시간은 3–5일에서 1–2일로 줄었다. 계약/지원팀의 서류 누락 병목이 줄었고, 접수부터 등록까지의 흐름이 자동화됐다.
- Problem
- 전국 매장 설치는 방문 설치가 기본이었다. 한 사람이 하루 2–5개 매장만 설치할 수 있어 지연, 이탈 위험, 팀 과부하가 생겼다.
- Bet
- 원격 설치에 대한 저항은 실제 설치 필요성보다 고객 기대와 내부 믿음에서 비롯된다고 봤다.
- Action
- 원격 전환 필요성을 내부에 공유하고, 부산 지점에서 4주 실험을 진행해 품질과 처리량 데이터를 모았다.
- Result
- 1인 설치 처리량은 하루 2–5개에서 최대 20개까지 늘었다. 원격 설치는 Spoqa의 표준 프로세스가 되었고, 이 프로젝트는 Spoqa Mate 선정으로 이어졌다.