빙상장 대관 예약 시스템을 직접 개발하면서 가장 어려웠던 부분은 결제도 아니고 디자인도 아니었습니다.
바로 네이버 예약 연동이었는데요.
실제 운영을 시작하고 보니 상당수 고객은 네이버 예약을 통해 유입되지만 정작 사업자가 활용할 수 있는 공개 API는 사실상 존재하지 않았습니다.
그 결과 네이버 예약 화면과 자체 예약 시스템이 따로 움직이게 되었고 직원들은 두 화면을 번갈아 확인하며 예약 현황을 수동으로 맞춰야 했습니다.
이번 글은 빙상장 예약 시스템을 구축하면서 네이버 예약과 자체 시스템을 양방향으로 연동하기 위해 직접 부딪히고 해결했던 경험을 정리한 기록입니다.
왜 클라우드 서버 방식은 실패했을까
처음에는 일반적인 방식대로 서버에서 네이버 예약 데이터를 수집하는 구조를 생각했습니다.
하지만 실제 테스트를 진행해 보니 네이버 예약 파트너 페이지는 로그인 세션과 접속 IP에 상당히 민감하게 반응했습니다.
클라우드 서버에서 접속하면 재인증이 발생하거나 접근 자체가 제한되는 경우가 많았는데요.
여러 차례 테스트 끝에 내린 결론은 단순했습니다.
“네이버 예약 연동 매장 PC에서 직접 처리해야 한다.”
그래서 선택한 방식이 크롬 확장 프로그램이었습니다.
점주가 로그인한 브라우저 세션을 그대로 활용해 네이버 예약 데이터를 읽고, 반대로 자체 시스템의 변경 사항을 네이버에 반영하는 브릿지 구조를 만들었습니다.
■ 가장 어려웠던 문제는 CSRF 토큰
예약 목록을 읽어오는 기능은 생각보다 빠르게 구현할 수 있었습니다.
진짜 문제는 데이터를 네이버에 다시 반영하는 과정이었는데요.
예약 가능 시간 변경이나 예약 상태 반영 같은 쓰기 작업에는 CSRF 토큰이 필요했습니다.
문제는 이 토큰이 페이지 접속 시점에 생성되지 않는다는 점이었습니다.
실제 사용자가 특정 동작을 수행해야만 토큰이 발급되는 구조였기 때문에 미리 확보하는 것이 불가능했습니다.
결국 초기 버전에서는 대부분의 쓰기 요청이 “CSRF 토큰 없음” 상태로 실패했습니다.
며칠 동안 여러 방법을 시도했지만 안정적으로 선점하는 방법은 찾지 못했습니다.
■ 실패를 없애려 하지 않고 대기로 바꿨다
문제를 해결한 방법은 의외로 단순했습니다.
완전 자동화를 포기하고 반자동 구조를 받아들인 것입니다.
기존에는 토큰이 없으면 실패로 처리했지만 이후에는 이를 대기 상태로 변경했습니다.
토큰이 확보되는 순간 대기열에 쌓여 있던 작업이 자동으로 실행되도록 구조를 변경했는데요.
이 방식으로 바꾸자 반복되던 실패 로그가 사라졌고 실제 반영 성공률도 크게 향상됐습니다.
이번 개발 과정에서 가장 의미 있었던 설계 변경이기도 합니다.
■ 운영하면서 마주한 자잘한 문제들
예약 상태와 매출 상태 분리
처음에는 예약 상태와 결제 상태를 하나로 관리했습니다.
하지만 네이버의 예약 상태와 실제 매출 데이터가 서로 다른 기준을 사용하면서 수치가 어긋나기 시작했는데요.
결국 naver_status 컬럼을 별도로 분리해 문제를 해결했습니다.
취소 예약 충돌 문제
네이버에서 취소된 예약이 기존 시간대를 점유하고 있는 것으로 처리되면서 가짜 충돌 경고가 발생했습니다.
취소 상태 예약을 충돌 검사 대상에서 제외해 해결했습니다.
상품 자동 매핑
네이버 상품명에 포함된 특정 키워드를 활용해 링크장 정보를 자동으로 연결하는 구조를 만들었습니다.
덕분에 수작업 매핑 과정을 크게 줄일 수 있었습니다.
네트워크 안정화
사내망 환경에서 QUIC 프로토콜이 차단되면서 통신이 불안정해지는 문제가 발생했습니다.
터널 연결을 HTTP/2로 고정해 안정성을 확보할 수 있었습니다.
■ 실제 운영을 통해 얻은 교훈
이번 프로젝트를 진행하며 가장 크게 느낀 점은 완벽한 자동화가 항상 정답은 아니라는 것이었습니다.
공식 API가 없는 외부 서비스를 연동할 때는 상대 시스템의 제약을 인정하고 그 안에서 안정적으로 동작하는 구조를 만드는 것이 훨씬 중요했는데요.
특히 세션과 IP, CSRF 토큰처럼 개발자가 통제할 수 없는 영역에서는 문제를 제거하려고 하기보다 문제가 발생해도 시스템이 멈추지 않도록 설계하는 것이 더 현실적인 접근이었습니다.
비슷한 연동 프로젝트를 고민하고 있다면 막히는 부분을 억지로 뚫으려 하기보다 실패해도 데이터가 깨지지 않는 구조를 먼저 만드는 것을 추천드립니다.
그 경험이 결국 가장 큰 안정성을 만들어 주었습니다.
※ 실제 운영 중인 예약 시스템 구축 경험을 바탕으로 작성했습니다.