API 키가 만료된 뒤에야 자동화가 멈춘 걸 알아차린 적이 있다면, 갱신 시점을 미리 정해 두고 싶어집니다. 다만 모든 API 키가 정해진 주기로 자동 갱신되는 것은 아니어서, 날짜만 등록한다고 문제가 해결되지는 않습니다. 먼저 사용하는 서비스가 키 갱신을 지원하는지 확인하고, 29일 주기를 어떤 기준으로 계산할지 정해야 합니다. 그런 다음 새 키를 안전하게 발급하고 기존 키와 교체하는 단계, 실패했을 때 확인할 방법까지 하나의 스킬로 묶어 보겠습니다.
갱신 주기보다 키의 종류를 먼저 확인한다
- 키가 자동 갱신되는 방식인지 확인합니다.
- 만료일과 실제 교체 절차를 구분합니다.
- 키를 발급하는 서비스의 정책을 기준으로 설계합니다.
쉽게 설명하면, API 키는 서비스에 접속할 때 본인임을 확인하는 비밀 번호 같은 값입니다. 갱신이라고 해도 기존 키의 사용 기간을 늘리는 방식인지, 새 키를 받아서 사용 중인 곳의 값을 바꾸는 방식인지에 따라 필요한 작업이 달라집니다. 또 어떤 키는 정해진 만료일이 없거나, 관리 화면에서 직접 바꿔야 할 수도 있습니다.
이 차이는 OAuth 액세스 토큰과 비교하면 더 분명해집니다. 액세스 토큰은 갱신 토큰으로 새 토큰을 받는 구조일 수 있지만, API 키는 서비스에 따라 새로 발급하고 기존 키를 폐기해야 합니다. 그래서 이 스킬은 모든 API에서 똑같이 쓸 수 있는 기능이라기보다, 특정 서비스의 발급 절차에 맞춘 작업 흐름으로 보는 편이 안전합니다.
만약 새 키 발급이 수동 작업만 지원한다면, 스킬은 갱신 시점을 알려 주는 역할까지만 할 수도 있습니다. 반대로 발급 API가 있다면 자동화 범위를 넓힐 수 있지만, 서비스 정책에 따라 가능한 단계가 달라질 수 있습니다. 이 차이를 확인하고 나면, 이제 29일을 언제부터 세고 어떤 시점에 작업을 시작할지 정해야 합니다.
29일은 실행 시점이 아니라 기준부터 정한다
- 최초 발급일 또는 마지막 갱신 완료일을 기준으로 삼습니다.
- 서비스의 실제 만료일이 확인되면 그 날짜를 우선합니다.
- 정기 실행이 누락됐을 때 다시 처리할 조건도 정합니다.
풀어서 설명하면, 29일을 셀 때는 달력의 특정 날짜에 맞춰 실행할지, 마지막 갱신이 끝난 뒤 29일을 기다릴지 먼저 정해야 합니다. 달마다 날짜 수가 다르기 때문에 매달 같은 날짜에 실행하는 방식은 정확히 29일 간격이 아닐 수 있습니다. 작업이 하루 늦게 실행됐을 때 다음 실행일을 원래 계획에 맞출지, 실제 갱신 완료일을 기준으로 다시 계산할지도 결정해야 합니다. 우선 마지막 갱신 완료 시각을 기록하고, 그 시각을 다음 주기의 기준으로 삼는 구성을 생각해 볼 수 있습니다.
그런데 29일이라는 간격이 실제 만료 시점보다 충분히 이른지는 서비스 정책을 확인한 다음 판단해야 합니다. 키가 언제부터 만료 기간을 계산하는지, 새 키를 발급한 직후 기존 키가 무효화되는지에 따라 적절한 시점이 달라질 수 있기 때문입니다. 따라서 29일은 고정된 정답이라기보다, 확인한 만료 조건에 맞춰 조정할 수 있는 설정값으로 두는 편이 낫습니다.
또 자동화가 중단되거나 실행에 실패할 가능성도 생각해야 합니다. 실행 기록에 마지막 성공 시점을 남겨 두면, 다음 실행에서 예정일이 지났는지 확인하고 누락된 작업을 처리할지 판단할 수 있습니다. 기록 기준과 예외 조건에 따라 누락된 실행을 처리하는 방법도 달라질 수 있으니, 이런 기준을 정했다면 실제 발급과 교체를 어떤 순서로 할지 나눠 볼 차례입니다.
새 키 발급과 사용처 교체를 분리한다
- 새 키를 발급한 뒤 유효성을 확인합니다.
- 확인이 끝나면 자동화에서 참조하는 값을 교체합니다.
- 교체 결과와 기존 키 처리 여부를 기록합니다.
다르게 말하면, 키를 바꾸는 일은 새 열쇠를 받는 것에서 끝나지 않고 그 열쇠가 문을 여는지 확인하는 과정까지 포함합니다. 그래서 작업을 '발급', '검증', '교체', '기록' 단계로 나누면 문제가 생긴 곳을 찾기 쉽습니다. 새 키를 받았더라도 필요한 권한이 있는지, 실제 요청에 쓸 수 있는지 확인한 뒤 자동화에 저장된 값을 바꿔야 합니다. 검증에 쓸 요청 방식은 API마다 다를 수 있으므로 해당 서비스에서 제공하는 방법을 확인해야 합니다.
그다음에는 키를 어디에 저장할지도 정해야 합니다. 시나리오나 코드 안에 키를 직접 적어 두면 교체가 번거롭고, 실행 기록이나 알림에 키가 노출될 위험도 생깁니다. 따라서 플랫폼의 비밀값 저장 기능이나 접근 제어 방식을 활용하고, 로그에는 키 자체 대신 처리 결과와 필요한 최소 정보만 남기는 방향을 고려할 수 있습니다.
기존 키를 언제 폐기할지도 서비스 정책에 따라 달라집니다. 두 키를 잠시 함께 쓸 수 있다면 새 키가 제대로 작동하는지 확인한 뒤 기존 키를 없앨 수 있지만, 동시 사용이 허용되지 않는 서비스도 있습니다. 교체 순서에 따라 실패했을 때 되돌리는 방법도 달라질 수 있으니, 이 기준을 정했다면 알림과 재시도 조건까지 마련해야 합니다.
갱신 자동화에는 실패 경로도 넣는다
- 발급 실패와 검증 실패를 구분해 기록합니다.
- 실패 시 알림을 보내고 재시도 조건을 둡니다.
- 성공한 경우에만 갱신 완료 시점을 갱신합니다.
일상에 빗대어 보면, 새 키 발급과 사용처 교체는 집 열쇠를 새로 만들고 실제 문에 맞는지 확인하는 일과 비슷합니다. 새 키 발급은 됐지만 사용처 교체가 실패했다면, 기존 키가 아직 작동하는지와 새 키가 어디까지 반영됐는지를 확인해야 합니다. 반대로 발급 자체가 실패했다면 새 키가 없는 상태이므로, 이전 성공 기록을 갱신 완료로 덮어쓰지 않는 편이 문제를 추적하기 쉽습니다.
이어서 어떤 오류를 자동으로 다시 시도할지도 서비스의 응답과 제한 정책에 맞춰 정해야 합니다. 무조건 반복 요청하면 요청 제한에 걸릴 수 있고, 실패 원인에 따라서는 다시 시도해도 해결되지 않을 수 있습니다. 알림과 재시도 조건은 환경에 따라 달라질 수 있으므로, 한 서비스에 맞춰 발급부터 알림까지 작은 흐름으로 시험해 보면 자동화할 범위를 판단하기 쉽습니다. 이런 과정을 거치면 29일 주기뿐 아니라 작업이 멈췄을 때 확인할 기준도 갖추게 됩니다.
주기는 고정해도 절차는 서비스에 맞춘다
29일이라는 숫자만 반복 실행하는 것보다, 만료 정책을 확인하고 발급·검증·교체·기록을 연결하는 편이 키 만료로 인한 중단을 줄이는 데 도움이 됩니다. 이 구조를 적용하면 갱신 시점과 실패 위치를 확인할 수 있어, 수동 개입이 필요한 단계도 구분하기 쉬워집니다. 다음 글에서는 이 설계를 실제 자동화 도구의 실행 흐름으로 나누고, 일정 관리와 실패 알림을 구성하는 방법을 이어서 다룰 수 있습니다.