API 키 교체 — 서비스를 멈추지 않는 순서

API 키는 한 번 만들고 계속 쓰는 것이 기본값처럼 되어 있습니다. 그런데 키가 오래될수록 유출 위험이 쌓입니다.

이 글은 키를 주기적으로 바꾸는 절차와, 바꿀 때 서비스가 멈추지 않게 하는 순서를 정리합니다.

왜 바꿔야 하는가

• 노출 기회가 누적됩니다. 화면 공유, 스크린샷, 질문 글, 로그 파일. 한 번도 안 새는 것이 오히려 어렵습니다.
• 퇴사·이관이 있습니다. 그 키를 알던 사람이 조직을 떠나도 키는 살아 있습니다.
• 유출을 모를 수 있습니다. 조용히 쓰이면 사용량이 조금 늘어날 뿐이라 알아채기 어렵습니다.

세 번째가 핵심입니다. 유출됐는지 모르는 상태가 가장 위험하고, 주기적 교체는 그 상태의 지속 기간을 제한합니다.

교체 순서 — 서비스를 멈추지 않고

키를 지우고 새로 만들면 그 사이에 호출이 실패합니다. 순서를 지키면 중단이 없습니다.

1. 새 키를 먼저 발급합니다. 옛 키는 아직 살려 둡니다.
2. 설정을 새 키로 교체합니다. 환경 변수나 설정 파일을 바꿉니다.
3. 새 키로 실제 호출이 되는지 확인합니다. 여기까지 왔으면 옛 키는 이제 안 쓰입니다.
4. 사용량 화면에서 옛 키의 호출이 0인지 며칠 지켜봅니다. 놓친 곳이 있으면 여기서 드러납니다.
5. 옛 키를 폐기합니다.

4번을 건너뛰면 어딘가 남아 있던 설정이 갑자기 실패합니다. 배치 작업이나 잊고 있던 스크립트가 대체로 여기서 걸립니다.

용도별로 나누면 교체가 쉬워집니다

키가 하나면 교체할 때 모든 곳을 동시에 바꿔야 합니다. 나눠 두면 하나씩 처리할 수 있습니다.

두 번째는 요금 분석에도 도움이 됩니다. 키가 하나면 어느 작업이 얼마를 쓰는지 구분되지 않습니다.

교체 주기

정답은 없지만 기준을 하나 제안드리면, “이 키가 지금 유출됐다면 얼마나 곤란한가”로 잡으시는 것입니다.

• 지출 한도가 낮게 걸린 개발용 키 — 유출돼도 피해가 제한적이므로 주기가 길어도 됩니다.
• 한도가 큰 운영용 키 — 짧게 가져가시는 편이 안전합니다.
• 사람이 떠날 때 — 주기와 무관하게 즉시 교체합니다.

여기서 보이듯 지출 한도가 교체 주기를 정하는 변수입니다. 한도를 낮게 걸어 두면 유출의 최대 피해가 그 금액으로 제한됩니다.

교체를 잊지 않으려면

• 키를 만든 날짜를 기록해 둡니다. 서비스 화면에 생성일이 표시되는 경우가 많습니다.
• 구독 점검 때 함께 봅니다. 반년에 한 번 하는 점검에 항목을 하나 더하면 됩니다.
• 안 쓰는 키는 즉시 폐기합니다. 살아 있는 키가 적을수록 관리가 쉽습니다.

확인 범위

이 글은 일반적인 절차를 다룹니다. 서비스별 키 발급·폐기 화면의 위치와 생성일 표시 여부는 서비스마다 다르고 화면도 자주 바뀝니다. 각 서비스의 키 관리 화면에서 확인하시기 바랍니다.