광고 매체 API 갱신 토큰이 유실되어 데이터 수집이 멈췄을 때: 토큰 저장 경로를 운영 체계로 만드는 법

📖 약 3분 읽기

광고 성과 대시보드는 매체 API에서 매일 데이터를 받아 와야 움직입니다. 어느 시점부터 특정 광고 매체에 연결된 몇몇 광고 계정에서 수집이 한꺼번에 멈추는 일이 발생했습니다. 코드 저장소에는 변경 이력이 없었고 배포 기록에도 특이점이 없었습니다. 원인은 화면에 보이지 않는 인증 토큰의 수명 관리에 있었습니다.

데이터 수집이 멈춘 날

해당 매체는 접근 토큰을 갱신할 때 일정 조건을 만족하면 새로운 갱신 토큰을 함께 발급하고, 기존에 쓰던 갱신 토큰은 그 자리에서 폐기하는 정책을 씁니다. 보안 측면에서는 합리적인 설계이지만, 토큰을 받는 쪽이 새 값을 어딘가에 남겨 두지 않으면 다음 요청부터 인증 수단 자체가 사라지는 구조이기도 합니다.

기존 수집 배치를 대체하기 위해 새로 만든 수집 모듈은 토큰 교환 요청에는 정상적으로 응답을 받았습니다. 문제는 그 응답에 담긴 새 갱신 토큰을 저장하는 절차가 빠져 있었다는 점입니다. 기존 토큰은 매체 쪽에서 이미 폐기한 뒤였고, 새 토큰은 어디에도 남지 않았습니다. 다음 날 같은 계정들의 수집은 기존 배치와 새 모듈 양쪽 모두에서 인증 실패로 멈췄습니다. 같은 방식으로 토큰을 주고받는 다른 매체 연동도 같은 위험을 그대로 안고 있었습니다.

갱신 토큰 폐기와 저장 누락의 구조

접근 토큰과 갱신 토큰을 나눠 쓰는 인증 방식은 여러 매체 API에서 공통으로 쓰입니다. 접근 토큰은 수명이 짧아 자주 갈아 끼우고, 갱신 토큰은 그 접근 토큰을 다시 발급받을 때 쓰는 열쇠 역할을 합니다. 일부 매체는 보안을 강화하기 위해 갱신 토큰을 쓸 때마다 새 값으로 바꾸고 이전 값을 무효화하는 회전 정책을 적용합니다.

이 방식에서는 토큰을 받는 시스템이 응답에 담긴 새 값을 즉시, 그리고 확실하게 저장하는 절차가 전제되어야 합니다. 저장이 한 번이라도 빠지면 이전 토큰은 이미 쓸 수 없고 새 토큰은 어디에도 남지 않아, 다음 인증 시도부터는 복구할 단서 자체가 사라집니다. 코드가 틀리지 않아도 운영이 멈추는 지점이 바로 여기입니다.

실행 기록으로 원인을 재구성하는 과정

원인을 짐작만으로 단정하지 않기 위해 배치 로그와 클라우드 로그를 시간 순서로 맞춰 표로 정리했습니다. 어느 모듈이 언제 토큰 교환을 시도했는지, 언제부터 인증 실패가 기록되기 시작했는지를 나란히 놓고 보니 실패 시점이 새 모듈의 첫 토큰 교환 직후와 정확히 겹쳤습니다. 추측이 아니라 기록으로 원인을 확정한 뒤에야 다음 조치를 정할 수 있었습니다.

수정 전에 판단해야 할 세 가지

새 갱신 토큰을 저장하는 경로를 만드는 쪽으로 방향은 정했지만, 구현에 들어가기 전에 먼저 확인해야 할 항목이 남아 있었습니다. 다음 세 가지를 판단하는 단계를 거치기로 했습니다.

1. 수집 모듈이 운영 환경에서 토큰 저장소에 실제로 도달할 수 있는지 확인하는 것.
2. 저장 작업을 어떤 인증 계정의 권한으로 수행할지 정하는 것.
3. 저장이 실패했을 때 재시도할지, 알림을 보낼지, 수집을 중단할지를 정하는 것.

구현과 검수, 반영 작업의 담당을 나누어 한 사람이 전체 단계를 혼자 처리하지 않도록 역할을 분리했습니다.

시스템을 교체할 때 점검해야 할 운영 동작

이번 사례는 기능만 옮기고 운영 동작은 빠뜨리기 쉽다는 점을 보여 줍니다. 시스템을 바꿀 때는 다음과 같은 항목을 점검 목록으로 확인하는 과정이 필요합니다.

1. 인증 토큰을 포함해 수명이 있는 값이 갱신될 때마다 저장되는지 확인하는 항목.
2. 토큰이나 자격 증명이 폐기되는 조건과 그 영향 범위를 파악하는 항목.
3. 저장이나 갱신이 실패했을 때 감지하고 알리는 절차가 있는지 확인하는 항목.
4. 같은 구조를 쓰는 다른 연동이 동일한 위험을 안고 있는지 점검하는 항목.

데이터 수집 장애의 상당수는 코드 결함보다 인증 수명 관리에서 비롯됩니다. 기능 전환에 성공했는지 뿐 아니라 운영 동작까지 빠짐없이 옮겨졌는지를 확인하는 절차가 함께 있어야 수집이 끊기지 않습니다.