서비스를 중단하지 않고 JWT 서명키나 API 비밀키를 교체할 때 배포 순서와 유출 대응을 어떻게 나누나요?
잠깐, 답변을 보기 전에
먼저 내 말로 설명해 볼까요?
답변과 점검 포인트 펼치기답변 접기
구두 답변
정의를 외우기보다, 원리와 조건을 연결해 설명해 보세요.
키 교체의 본질은 새 값을 만드는 일이 아니라 생산자와 검증자가 서로 다른 버전을 보는 기간을 안전하게 관리하는 것입니다. 정상적인 무중단 교체와 이미 유출된 키의 긴급 회수는 순서와 가용성 목표가 다릅니다. JWT 서명키는 검증자가 새 공개키를 먼저 알게 한 뒤 새 키로 발급하고, API 대칭 비밀키는 상대가 새 키를 잠시 함께 허용할 수 있는지부터 확인하겠습니다.
정상 교체는 중첩 기간으로 진행합니다
JWT라면 새 키 쌍을 만들고 공개키를 JWKS 같은 검증 경로에 key ID와 함께 배포합니다. 모든 검증 서비스와 캐시가 새 kid를 찾을 수 있는지 확인한 다음 발급자가 새 키로 서명합니다. 이전 토큰이 남아 있는 유효 기간 동안 이전 공개키도 검증에 남겨 두되, 무기한 허용하지 않고 토큰 최대 수명·시계 오차·캐시 수명을 고려해 제거 시점을 정합니다. 검증자가 새 kid를 모른다고 무제한 재조회하면 장애가 증폭될 수 있으므로 제한된 refresh와 재시도 정책을 둡니다.
API 비밀키처럼 상대 서버가 두 값을 동시에 인정할 수 있다면 새 키를 상대와 소비자에게 먼저 전달하고, 실제 인증 호출을 확인한 뒤 생산자를 전환합니다. 모든 인스턴스·배치·장기 실행 작업·connection pool이 새 값을 사용하는지 관찰하고 이전 키를 폐기합니다. 상대가 한 번에 한 키만 허용한다면 교체 창, 순서, 실패 시 안전한 재시도와 롤백 키를 별도로 설계합니다. ‘설정 파일 배포 완료’와 ‘실제 호출 성공’은 다른 상태입니다.
유출 대응은 가용성보다 차단을 우선합니다
이전 키가 공격자에게 알려졌다면 이전 키를 다시 활성화해 장애를 완화하는 롤백은 안전하지 않습니다. 즉시 revoke·rotate하고, 그 키로 서명된 토큰의 신뢰를 철회하고 관련 세션·갱신 토큰 계열에 재인증 정책을 적용해야 할 수 있습니다. JWT 형식 자체에 family가 자동으로 존재하는 것은 아닙니다. API key는 사용 주체·범위·마지막 사용 시각을 기준으로 영향 범위를 조사하고 대체 키로 전환한 뒤 폐기합니다. 키 원문은 제한된 비밀 저장소에서만 읽고, 로그에는 버전·kid·성공률·실패 사유만 남깁니다.
부분 배포, 공개키 캐시 지연, kid 미발견, 비밀 저장소 장애, 이전 토큰 만료, 시계 오차를 정상 교체 테스트에 넣습니다. 새 검증자가 없는 상태에서 발급하면 일부 사용자가 동시에 실패할 수 있고, 반대로 이전 키를 오래 허용하면 유출 대응이 약해집니다. 인증서 교체나 refresh token 회수처럼 연관된 자격의 수명도 별도로 확인하겠습니다.
롤백은 유출된 값을 되살리는 절차가 아니라 안전하게 보존된 이전 버전 또는 새로 만든 대체 키로 서비스를 안정화하는 절차여야 합니다. 성공률만 보고 완료하지 않고 각 검증자가 어느 버전을 사용하며, 이전 키가 실제로 더 이상 받아들여지지 않는지 확인하는 것이 기준입니다.
키 버전은 설정 파일 이름만으로 관리하지 않고 발급·검증 경로에서 관찰 가능한 상태로 만들겠습니다. 예를 들어 검증 서비스가 kid=old를 계속 선택하는 비율이 남아 있으면 이전 토큰이 아직 살아 있는지, 캐시가 낡았는지, 일부 발급자가 전환되지 않았는지 원인을 나눠 조사합니다. 대칭 API 키를 양쪽에서 잠시 허용하는 경우에는 새 키를 먼저 제한된 scope로 시험하고, 모든 소비자가 전환된 뒤 이전 키를 폐기합니다. 상대가 키 두 개를 지원하지 않으면 임시 중계나 호출 중단 창을 검토하되, 유출된 자격을 계속 허용하는 방식으로 무중단을 가장하지 않겠습니다. 키를 읽는 프로세스가 crash dump·환경 변수·디버그 로그에 원문을 남기지 않는지도 확인합니다.
교체 완료 판정은 새 키가 한 번 성공했다는 단일 샘플이 아니라 모든 호출 경로의 사용률과 오류를 기준으로 합니다. 일부 배치나 오래 살아 있는 worker가 이전 키를 계속 사용하면 폐기 뒤에만 실패가 드러날 수 있으므로, 전환 전에 마지막 사용 시각과 실행 예약을 조회하고 갱신합니다. 키 ID가 없는 레거시 호출은 자동 추정으로 살려 두지 말고 명시적인 호환 창과 종료 시각을 둡니다.
득점 포인트
이해가 드러나는 지점을 확인해 보세요.
- 검증자 준비→새 발급·사용→중첩 기간→이전 키 제거의 순서를 설명한다.
- JWT 공개키와 API 대칭 비밀키의 교체 계약을 구분한다.
- 정상 교체와 유출 시 즉시 회수·재인증을 분리한다.
- 부분 배포·캐시·장기 작업·원문 비로그를 운영 검증에 포함한다.
감점 포인트
놓치기 쉬운 조건과 오해를 짚어 보세요.
- 모든 인스턴스가 동시에 새 키를 안다고 가정한다.
- 이전 키를 무기한 허용하거나 새 공개키 준비 전에 발급한다.
- 유출된 키를 장애 때 다시 활성화해 롤백한다.
- 설정 배포 성공을 실제 인증 호출 성공과 동일시한다.
더 파고들 거리
하나 더 질문하며 이해의 범위를 넓혀 보세요.
- 새 kid를 모르는 서비스가 JWKS를 반복 조회합니다. 캐시·singleflight·실패 backoff를 어떻게 조합하나요?
- 짧은 토큰 수명과 오래 실행되는 작업의 인증 갱신을 어떻게 연결할까요?
- 비밀 저장소 장애 중 기존 키를 허용할 최대 기간을 어떤 위협으로 정할까요?
득점·감점 포인트는 학습용 자기 점검 기준이며, 특정 회사의 실제 채점표가 아닙니다.
원리부터 공부하고 싶다면
답변을 보충하는 개념·예제·슈도코드를 읽어 보세요.