Toss 토큰 401 핑퐁 근본원인 - 캐시 재확인 없는 즉시 재발급
아침마다 되풀이되던 Toss API 토큰 무효화 소동의 진짜 원인을 찾아 고치고, 재발 여부를 사람이 기억하지 않아도 자동으로 확인하게 만들었다.
아침마다 되풀이되던 토큰 무효화
며칠 전부터 새벽~아침 시간대에 외부 시세 API 인증 토큰이 반복적으로 무효화되는 로그가 쌓이고 있었습니다. 처음엔 두 상주 프로세스의 재시작 시점이 어긋나서 생긴 일시적 현상으로 보고 재시작으로 넘겼는데, 며칠 뒤 같은 증상이 다시 나타났습니다.
실주문이 나가는 경로와는 무관하고 시세 조회만 영향을 받는 문제라 급하지는 않았지만, 같은 증상이 계속 재발하니 원인을 제대로 짚어야 했습니다. 다른 AI에게 코드를 직접 들여다보고 원인을 좁혀달라고 자문을 맡겼습니다.
근본원인은 "재발급 전에 캐시를 안 봤다"는 것
자문 결과, 진짜 원인은 재시작 시점 어긋남이 아니었습니다. 토큰이 거부당하면(401) 곧바로 새 토큰을 발급받는 구조였는데, 그 전에 혹시 다른 프로세스가 이미 새로 받아둔 토큰이 있는지 먼저 확인하지 않는 게 문제였습니다.
이 API를 쓰는 프로세스가 동시에 여러 개 떠 있다 보니, 한쪽이 거부당해 새 토큰을 발급받으면 그 순간 상대방이 쓰던 토큰이 즉시 무효화됩니다. 상대방도 같은 방식으로 반응해 또 새 토큰을 발급받으면, 이번엔 처음 쪽이 무효화됩니다.
이렇게 서로가 서로의 토큰을 계속 무효화시키는 핑퐁이 반복된 것이었습니다. 토큰 자체의 유효기간이 끝나는 시점(발급 후 하루 정도)에 첫 충돌이 시작된다는 것도 함께 확인됐습니다.
수정과 재발 확인 장치를 같은 날 배포했다
수정 방향은 명확했습니다. 거부당했을 때 곧바로 새 토큰을 받지 말고, 저장된 캐시를 먼저 다시 읽어서 이미 바뀐 토큰이 있으면 그걸로 재시도하고, 그래도 거부당할 때만 파일 잠금을 걸고 하나의 프로세스만 발급하도록 바꿨습니다.
이 수정은 격리된 작업 공간에서 구현하고 테스트까지 마친 뒤 코드를 검토해 병합했습니다. 장 마감 뒤 이 API를 쓰는 상주 프로세스 6개를 전부 재시작해서 깨끗하게 올라오는 걸 확인했습니다.
말로만 "고쳤다"고 끝내지 않으려고, 토큰 무효화 로그를 집계하는 전용 확인 스크립트를 따로 만들었습니다. 수정 전 구간에서는 수십 건이 잡혔고, 배포 이후 구간에서는 0건으로 확인됐습니다.
사람이 매번 기억해서 확인하는 대신, 다음 거래일들에 자동으로 이 집계를 돌려 텔레그램으로 결과를 받도록 예약해 뒀습니다. 재발하면 그 자리에서 바로 알게 되는 구조입니다.
가설 하나를 사전등록 기준대로 접었다
별도로 진행하던 통계적 가설 검증 하나도 오늘 결론이 났습니다. 수급 데이터 기반의 새 신호 후보가 예측력에 도움이 되는지를 미리 정해둔 절차대로 검증했는데, 첫 관찰 구간에서 통계적 기준을 넘지 못했습니다.
기준을 못 넘었다고 임계값을 낮추거나 구간을 바꿔서 재시도하지 않고, 검증 전에 정해둔 규칙 그대로 이 가설을 종결했습니다. 원하는 결과가 나올 때까지 조건을 바꿔 다시 찔러보면 통계적으로는 의미 없는 "우연한 성공"을 성공으로 착각하기 쉽기 때문에, 이렇게 미리 정한 규칙을 지키는 쪽이 당장 아쉬워도 더 안전합니다.