개발 slecs

백업 계정 주기 교체로 인증 안정성 확보

목차

백업 계정의 주기적 로테이션을 자동화하는 매니저를 구현했다. 기존엔 수동으로 처리되던 B레이어의 계정 교체를 Python 풀 매니저로 일괄 관리하고, 셸 스크립트로 인증 상태를 실시간 검증하는 구조로 변경했다.

배경: 백업 계정 전략의 맥락

서비스 인증 시스템에서 '백업 계정'은 단순 보험이 아니다. 주 계정이 일시적으로 손상되거나 정책 변경으로 접근이 제한될 때 비상 진입로 역할을 하는데, 이 계정들이 오래되거나 주기적으로 갱신되지 않으면 오히려 보안 위험이 된다. 특히 B레이어 같은 기반 인프라 계층에서는 계정이 여러 개 존재하고, 각각의 생명주기와 권한이 다르기 때문에 휴먼 에러로 인한 관리 누락이 발생하기 쉽다.

내가 이번 작업을 우선순위에 올렸던 이유는 다음과 같다:
- 자동화 가치: 월 1회 수동 확인 작업이 팀 누군가에겐 "까먹을 수 있는 일"이 되고 있었다
- 감시 공백: 계정 상태를 실시간으로 추적하지 못해, 계정이 언제부터 만료되었는지 늦게 발견하는 경우가 있었다
- 확장성: 팀 규모가 커지거나 서비스가 추가되면, 수동 관리는 선형적으로 부담이 증가한다

구현: 계정 풀 매니저와 인증 검증 분리

두 스크립트로 책임을 나눴다:

스크립트 역할 실행 빈도
claude-account.py 백업 계정의 생명주기 관리 (생성, 갱신, 폐기) 주간/월간
claude-auth-check.sh 현재 계정 상태 검증 및 알림 매일/매시간

claude-account.py (풀 매니저)는 계정 풀의 상태를 추적하고, 로테이션 정책에 따라 새 계정을 발급하고 구 계정을 폐기하는 역할을 한다. 단순히 계정을 만드는 것이 아니라, 이미 발급된 계정들의 나이(age)를 계산하고, 임계값을 넘은 것들을 자동으로 교체 대상으로 마킹하는 로직을 포함한다.

계정 풀의 일반적인 상태 전이:
ACTIVE(나이 0~30일) 
  ↓
ACTIVE(나이 31~60일, 갱신 준비)
  ↓
DEPRECATED(나이 61일 이상, 신규 계정 발급 대기)
  ↓
INACTIVE(공식 폐기, 안전 보관 기간 만료)

claude-auth-check.sh는 더 자주 실행되며, 풀 매니저가 만든 계정들이 실제로 작동하는지 검증한다. 인증 토큰 갱신, 권한 확인, 네트워크 연결 테스트 등을 수행하고, 문제가 있으면 즉시 알림을 보낸다. 이를 통해 계정이 "종이 위에서는 유효하지만 실제론 못 쓰는" 상황을 사전에 방지한다.

계정 로테이션의 일반론

이 작업을 하면서 깨달은 것이 몇 가지 있다. 첫째, 로테이션은 보안과 가용성의 트레이드오프다. 계정을 자주 바꾸면 보안은 좋아지지만, 매번 바뀔 때마다 시스템이 새 계정을 감지하고 연결을 다시 수립해야 하므로 일시적 지연이 생길 수 있다. 그래서 우린 "충분히 자주, 그런데 너무 자주는 아닌" 주간 교체를 선택했다.

둘째, 검증 없는 로테이션은 의미가 없다. 계정을 만들기만 하고 그게 정말 작동하는지 확인하지 않으면, 결국 "발급되지 않은 계정을 사용하려다가 장애 나는" 상황이 발생한다. 그래서 자동화 매니저 옆에 검증 도구를 반드시 붙이는 게 중요하다.

셋째, 감시와 알림이 자동화의 절반이다. 백업 계정 자체가 뭔가 문제 상황의 "backup"이기 때문에, 정상적인 운영 흐름에서는 잘 사용되지 않는다. 그러면 문제가 생될 때쯤엔 "아, 이 백업 계정도 안 된다"는 상황을 맞이한다. 그래서 실시간 검증과 사전 알림이 중요하다.

팀 관점의 의미

나는 이 작업을 구현하면서 팀이 "수동으로 할 수 있는 일이지만, 하면 실수할 수 있는 일"을 찾아내고 자동화하는 것이 얼마나 중요한지 다시 한 번 느꼈다.

백업 계정 교체는 긴급 상황에서만 필요한 것이라 상대적으로 주목도 낮다. 그런데 "관심이 없는 작업일수록 사람이 빠뜨린다"는 원칙을 적용하면, 이런 기반 작업이야말로 자동화해야 할 가장 우선 대상이다. 왜냐하면 정상 상황에선 아무도 체크 안 하다가, 한 번 필요할 때 "어? 계정이 왜 안 돼?"라는 상황을 맞이하기 때문이다.

코드리뷰 때 팀원들한테 강조한 포인트도 있다: "이 스크립트는 팀 전체의 신뢰도를 높이는 작업이다. 누구나 '음, 계정 로테이션은 매니저가 알아서 할 거겠지'라고 생각할 수 있게 한 것."

다음 고민

로테이션 주기와 검증 주기를 얼마나 촘촘하게 할지는 여전히 팀의 운영 정책과 시스템 부하의 균형을 봐야 한다. 현재는 보수적으로 설정했는데, 실제 모니터링을 돌려보면서 필요하면 조정할 예정이다. 또한 B레이어 이외의 다른 레이어에서도 비슷한 패턴이 필요한지 검토해야 할 것 같다.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.