외부 서비스를 자동화할 때 가장 먼저 부딪히는 벽은 "공식 API가 없다"는 상황입니다. 소셜 파티 운영사의 예약 상당수가 들어오던 외부 예약 플랫폼이 정확히 그랬습니다. 개발자에게 공개된 SDK도, 문서화된 엔드포인트도 없었습니다. 그렇다고 운영자가 그 플랫폼 화면을 회차마다 손으로 확인하게 둘 수는 없었습니다. 그래서 택한 방법은 그 플랫폼의 호스트 대시보드 자체가 어떻게 서버와 통신하는지를 관찰하고 같은 방식으로 우리 시스템이 직접 말을 거는 것이었습니다.
화면 뒤에서 오가는 요청을 읽는다
웹 대시보드는 결국 브라우저에서 서버로 요청을 보내 화면을 그립니다. 그 요청을 관찰하면 이 플랫폼이 어떤 구조로 데이터를 주고받는지 드러납니다. 관찰해 보니 로그인은 별도 인증 서버에 REST로 붙고 예약 목록 조회나 상태 변경 같은 실제 데이터 작업은 GraphQL 엔드포인트 한 곳으로 모이는 구조였습니다.
이 두 계층을 분리해 다루는 것이 첫 설계였습니다. 로그인 클라이언트는 인증 서버에 자격 증명을 보내 접근 토큰을 받아 오는 일만 하고 조회 클라이언트는 그 토큰을 헤더에 실어 GraphQL로 예약을 읽고 상태를 바꿉니다. 역할을 나눠 두면 인증 방식이 바뀌어도 조회 로직은 그대로 두고 로그인 부분만 손보면 됩니다.
GraphQL은 이런 역공학에 특히 유리합니다. 필요한 필드를 요청에 명시하는 구조라 대시보드가 실제로 어떤 필드를 읽는지 그대로 따라가면 응답의 모양을 정확히 재현할 수 있습니다. 예약 식별자, 주문 정보, 참가자 표시 이름과 성별, 상품과 회차, 티켓 수량처럼 운영에 필요한 필드만 골라 담은 질의를 만들어 화면이 보여 주는 것과 같은 데이터를 우리 데이터베이스로 가져왔습니다.
캡차 앞에서 멈추지 않게
자동 로그인에는 함정이 하나 있습니다. 사람이 아닌 자동 접근으로 의심되면 로그인 과정에서 캡차가 뜨고 그 순간 REST 로그인은 막힙니다. 이 지점에서 시스템이 멈춰 버리면 예약 동기화 전체가 멈추므로 우회 경로가 반드시 필요했습니다.
해법은 이중화였습니다. 평소에는 가벼운 REST 로그인으로 토큰을 받되 이 경로가 캡차 등으로 실패하면 실제 브라우저를 자동으로 띄우는 방식으로 전환해 로그인 화면을 통과하고 세션을 확보합니다. 브라우저 자동화는 무겁고 느리기 때문에 상시 경로가 아니라 폴백으로만 씁니다. 대부분의 경우 빠른 경로로 처리하고 막혔을 때만 무거운 경로로 넘어가는 구조입니다.
한 번 확보한 세션을 오래 쓰는 것도 중요했습니다. 로그인은 부담이 큰 작업이므로 매 조회마다 다시 하지 않고 받아 둔 토큰을 만료 전까지 재사용합니다. 그리고 토큰이 만료되기 전에 미리 다시 받아 두는 갱신 작업을 여섯 시간 간격으로 돌려 조회 도중에 토큰이 죽어 동기화가 끊기는 일을 막았습니다.
예약은 30초마다, 조용히 반영된다
연동이 완성되자 예약 조회는 30초 간격으로 자동 실행됩니다. 새 예약이 들어오면 30초 안에 어드민 대시보드의 명단에 나타나고 취소나 변경도 같은 주기로 따라옵니다. 운영자가 그 플랫폼 화면을 직접 열어 확인할 이유가 사라졌습니다.
주의할 점은 상대 서버에 부담을 주지 않는 것입니다. 조회는 필요한 회차와 기간으로 범위를 좁혀 요청하고 상태를 바꾸는 작업은 실제로 변경이 필요할 때만 보냅니다. 남의 서비스에 얹혀 도는 연동일수록 조용하고 예의 바르게 동작해야 오래 안정적으로 유지됩니다.
이렇게 붙인 예약 플랫폼 연동은 전체 시스템의 입구 하나일 뿐입니다. 이 플랫폼과 제휴 플랫폼 웹훅, 구글폼 예약을 하나의 명단으로 합치는 이야기는 예약 채널 3종을 한 명단으로 통합에서 이어집니다. 전체 시스템의 모습은 소셜 파티 운영 자동화 시스템 사례에서 볼 수 있습니다.
자주 묻는 질문
공식 API 없이 연동하는 것은 안정적인가요?
상대 서비스의 화면이 크게 바뀌면 영향을 받을 수 있다는 점은 분명합니다. 그래서 로그인과 조회 계층을 분리하고 실패를 감지하면 폴백 경로로 넘어가거나 로그에 남기는 구조를 함께 설계합니다. 문서화된 API가 없는 서비스라도 이런 방어 장치를 갖추면 실운영에서 충분히 안정적으로 돌릴 수 있습니다.
캡차가 뜨면 어떻게 되나요?
빠른 REST 로그인이 캡차로 막히면 실제 브라우저를 자동으로 띄우는 경로로 전환해 로그인 화면을 통과합니다. 이 무거운 경로는 상시로 쓰지 않고 막혔을 때만 사용하며 확보한 세션은 재사용하고 만료 전에 미리 갱신해 로그인 빈도 자체를 낮춥니다.
이런 연동이 상대 서비스에 부담을 주지 않나요?
조회 범위를 필요한 회차와 기간으로 좁히고 상태 변경 요청은 실제로 바뀔 때만 보냅니다. 남의 서비스에 연결되는 자동화일수록 요청 빈도와 양을 절제하도록 설계해야 하며 이 프로젝트도 사람이 화면을 열람하는 것과 비슷한 수준의 조회 부하만 발생하도록 맞췄습니다.