API 키를 발급받을 때는 잘 동작하던 자동화가 어느 날 갑자기 인증 오류로 멈추면, 어디서부터 확인해야 할지 막막해집니다. 특히 키가 일정 기간마다 만료된다면 그때마다 사람이 기억해서 갱신하는 방식은 놓치기 쉽습니다. 그래서 이번 글에서는 29일 주기로 갱신해야 하는 API 키를 Make에서 다루는 기본 흐름을 정리합니다. 핵심은 29일마다 무조건 새 키를 요청하는 것이 아니라, 만료 기준을 확인하고 갱신에 성공한 경우에만 다음 일정을 저장하는 것입니다. API 제공처마다 발급 방식이 다르기 때문에, 실제 연결에 앞서 확인해야 할 항목도 함께 짚어 보겠습니다.
29일의 기준부터 정한다
- 만료일이 발급 시점부터 29일 뒤인지 확인합니다.
- 갱신 요청을 만료 전에 할 수 있는지 확인합니다.
- 새 키 발급 후 기존 키가 언제까지 유효한지 확인합니다.
쉽게 설명하면, 새 열쇠가 언제까지 문을 열 수 있는지 먼저 확인해야 갱신할 날짜를 정할 수 있습니다. 발급한 날부터 29일 뒤에 만료되는지, 매달 정해진 날짜에 만료되는지에 따라 계산 방법이 달라집니다. 갱신 요청을 만료 전에 보낼 수 있는지도 확인해야 합니다.
이 기준을 정하지 않고 29일 간격으로만 실행하면, 첫 실행 날짜에 따라 실제 만료일까지 남은 기간이 달라질 수 있습니다. 그래서 일정 자체를 29일 간격으로 고정하기보다 마지막 갱신에 성공한 시점을 기준으로 다음 갱신일을 계산하는 편이 안전합니다. 다만 API 제공처가 정해진 날짜에만 키를 갱신할 수 있다면 그 규칙을 먼저 따라야 합니다.
또한 만료 직전에만 갱신할 수 있는지, 새 키를 받은 뒤에도 기존 키를 잠시 쓸 수 있는지 확인해야 합니다. 이 조건에 따라 갱신을 시작할 때가 달라질 수 있으니, 적용하기 전에 제공처의 규칙을 살펴보는 편이 좋습니다. 기준이 정리됐다면 이제 Make가 언제 실행되고, 어떤 조건에서 갱신 요청을 보낼지 정할 수 있습니다.
실행 시점보다 조건을 먼저 설계한다
- 정기 실행 후 저장된 다음 갱신일을 확인합니다.
- 갱신일이 되지 않았다면 요청을 보내지 않습니다.
- 갱신 응답이 성공한 경우에만 새 키와 다음 날짜를 기록합니다.
풀어서 설명하면, Make가 매일 달력 날짜를 확인하더라도 갱신일이 오기 전에는 API 키를 바꾸지 않도록 조건을 두는 방식입니다. 시나리오는 매일 실행하되, 저장해 둔 다음 갱신일이 되었을 때만 API에 요청을 보낼 수 있습니다. 이렇게 하면 확인하는 주기와 실제로 키를 갱신하는 주기를 따로 관리할 수 있습니다. 날짜를 비교할 때는 시나리오의 시간대와 저장된 날짜 형식도 맞춰야 합니다.
갱신 요청은 보통 HTTP 요청과 응답 처리 단계로 나눌 수 있지만, 인증 정보와 요청 형식은 제공처 문서에 맞춰야 합니다. 새 키가 응답으로 오면 성공 여부와 필수 값이 있는지 먼저 확인하고, 그다음에 키와 다음 갱신일을 저장합니다. 실패했는데도 다음 갱신일을 기록하면, 그날부터 한동안 다시 확인하지 않아 기존 키가 만료될 수 있습니다.
반대로 29일마다 한 번만 실행하면 구성이 단순해질 수 있지만, 한 번 실패한 뒤 다시 시도할 때까지 기다려야 할 수 있습니다. 매일 확인하는 방식은 실패 후에도 조건이 계속 참으로 남아 다음 실행 때 다시 시도할 여지가 있습니다. 다만 너무 자주 요청하면 제공처의 제한에 걸릴 수도 있으니, 재시도 간격과 허용 횟수는 문서에서 확인하는 편이 좋습니다. 실행 조건을 정했다면 다음으로는 새 키를 안전하게 교체하고, 이를 사용하는 시나리오에 반영해야 합니다.
키 교체는 성공한 뒤에 반영한다
- 새 키를 확인하기 전까지 기존 키를 덮어쓰지 않습니다.
- 키를 읽고 쓰는 위치와 사용 시나리오를 확인합니다.
- 실패 내역을 남기되, 로그에 키 값이 노출되지 않게 합니다.
일상에 빗대어 보면, 새 열쇠가 제대로 맞는지 확인하기 전에 쓰던 열쇠를 버리지 않는 것과 같습니다. 새 키를 받으면 성공 응답인지, 키 값이 비어 있지 않은지 먼저 확인한 뒤 기존 값을 바꾸는 편이 안전합니다. 키가 Make 연결이나 별도 저장소 중 어디에 있는지는 구성에 따라 다르므로, 현재 어떤 시나리오가 그 값을 사용하는지부터 확인해야 합니다.
새 키로 API 요청을 시험해 볼 수 있다면, 확인을 마친 뒤 사용 경로를 바꾸는 방법도 생각해 볼 수 있습니다. 하지만 새 키가 발급되는 순간 기존 키가 폐기된다면 두 키를 함께 비교하는 방식은 어려울 수 있습니다. 이때는 응답 형식과 오류 처리를 꼼꼼히 확인하고, 교체 뒤 문제가 생겼을 때 다시 연결할 방법도 미리 생각해 두는 편이 좋습니다.
오류 알림에는 어느 단계에서 문제가 생겼는지와 응답 코드처럼 점검에 필요한 내용만 담고, 실제 키나 인증 값은 기록하지 않아야 합니다. 그러면 원인을 찾으면서도 비밀 값이 로그에 남을 가능성을 줄일 수 있습니다. 다만 로그에 남길 수 있는 정보는 서비스 설정이나 운영 환경에 따라 다를 수 있으니, 적용 전에 기록 내용을 한 번 확인하는 것이 좋습니다. 이제 이 흐름을 시험 실행해 성공과 실패 상황에서 날짜와 키가 의도대로 처리되는지 확인하면 됩니다.
날짜보다 성공 기록을 믿는다
29일 주기 갱신을 마지막 성공 시점과 연결하면, 실행이 한 번 늦거나 실패하더라도 다음 시도를 이어 갈 여지가 생깁니다. Make에서 날짜 조건, 응답 확인, 키 교체를 각각 나누어 점검하면 수동 갱신에 기대는 부분을 줄일 수 있습니다. 다음 글에서는 이 구조에 갱신 실패 알림과 재시도 경로를 더할 때 어떤 상태를 기록해야 하는지 다루겠습니다.