로그는 남기는 것보다 조회할 수 있어야 한다: 외부 API 로그 분리기

외부 PMS와 연동하는 예약 시스템에서는 당사 서버가 정상적으로 요청을 보냈는지, PMS가 어떤 응답을 반환했는지를 확인할 수 있어야 합니다. 이 프로젝트에서도 외부 API의 요청과 응답을 기록하고 있었지만, 운영 과정에서 로그를 남기는 것과 장애 시점에 로그를 조회할 수 있는 것은 다른 문제 라는 점을 경험했습니다.

로그는 있었지만 확인할 수 없었다

초기에는 예약·회원 데이터와 외부 API 통신 로그를 같은 업무 DB에 저장했습니다. 운영이 이어지면서 로그가 수백만 건까지 증가했고, 문제가 발생한 예약 건을 조사하기 위해 로그 테이블에 접근하자 DB GUI가 다운됐습니다.

예약 기능 자체에 미친 영향은 거의 없었습니다. 실제 문제는 당사에 로그가 존재하는데도 필요한 시점에 조회할 수 없었다는 점이었습니다. 결국 해당 예약 요청과 응답을 직접 확인하지 못해 PMS 업체에 확인을 요청해야 했습니다.

업무 DB에서 시스템 로그로 분리하다

프로젝트 전체에서는 이미 정해진 구조 안에서 기능을 구현하는 역할이었지만, 이 운영 문제에 대해서는 로그 저장 경로를 분리하는 방향을 정하고 직접 구현했습니다.

외부 API 통신 로그를 업무 DB에 적재하는 대신 PHP Proxy에서 syslog()로 전달하도록 변경했습니다. 요청 시각과 호출 대상, 응답 상태, 요청·응답 내용을 시스템 로그에서 확인할 수 있도록 구성해 업무 데이터와 통신 로그가 같은 저장소에 쌓이지 않도록 분리했습니다.

이 변경의 목적은 예약 처리 속도를 높이거나 파일 쓰기 횟수를 줄이는 것이 아니었습니다. 업무 DB의 상태와 무관하게 외부 연동 기록을 확인할 수 있는 경로를 확보하는 것 이 핵심이었습니다.

예약 요청 흐름과 로그 저장 경계의 변화

변경 전
React → PHP Proxy → PMS
              └→ 업무 DB 통신 로그
                   └→ 수백만 건 누적
                        └→ 장애 조사 시 DB GUI 접근 불가

변경 후
React → PHP Proxy → PMS
              └→ syslog
                   └→ 서버 시스템 로그에서 요청·응답 추적

예약 요청이 React에서 PHP Proxy를 거쳐 PMS로 전달되는 흐름은 바꾸지 않았습니다. 통신 로그의 저장 위치만 업무 DB에서 시스템 로그로 옮겨, 업무 데이터와 장애 조사 기록의 경계를 분리했습니다.

당사 기록으로 예약 흐름을 추적하다

변경 후 예약 문제가 발생했을 때 서버의 시스템 로그에서 해당 요청과 응답을 직접 확인할 수 있었습니다. 이전처럼 PMS 업체에 먼저 확인을 부탁하지 않아도 당사 요청이 어떻게 전달됐고 어떤 응답을 받았는지부터 조사할 수 있게 됐습니다.

처리 시간 단축이나 장애 감소율을 별도로 측정하지는 않았습니다. 이 작업에서 확인한 결과는 외부 시스템에 의존하는 예약 흐름을 당사 로그로 추적할 수 있게 됐다 는 운영 범위까지입니다.

지금 다시 구현한다면

이 경험을 통해 외부 API 연동 로그는 단순히 많이 남기는 것이 아니라, 장애가 발생했을 때 실제로 검색하고 책임 범위를 확인할 수 있어야 한다고 생각하게 됐습니다.

현재 다시 구현한다면 검증했던 syslog 기반 분리 구조는 유지하되 요청과 응답 전체를 그대로 기록하지는 않겠습니다. 인증값과 개인정보를 마스킹하고 장애 추적에 필요한 정보만 남기며, 로그 보존 기간도 함께 관리하겠습니다.

외부 API 연동에서 로그의 목적은 모든 데이터를 축적하는 것이 아닙니다. 당사 요청과 외부 응답을 안전하게 연결해 문제가 어느 경계에서 발생했는지 확인할 수 있도록 만드는 것입니다.