비밀 관리: 주입 지점 선택과 무중단 키 교체

들어가며

.env 파일로 잘 돌아가던 서비스에서 어느 날 API 키를 바꿔야 할 일이 생깁니다. 이 키를 쓰는 서버가 몇 대인지, 지금 지워도 되는지, 누가 언제 읽었는지 바로 답하기 어렵습니다. 순서를 잘못 잡으면 키 하나를 바꾸다 서비스가 멈추기도 합니다.

이번 글에서는 비밀 관리가 다루는 범위와 값을 앱에 넣는 지점을 고르는 기준을 정리합니다. 값이 새는 자리와 서비스를 끊지 않고 키를 교체하는 순서도 함께 다룹니다.

1. 어디에 두느냐보다 누가 읽고 어떻게 바꾸느냐

비밀 관리는 API 키나 DB 비밀번호를 코드 밖 중앙 저장소에 두고 접근 통제, 감사, 교체까지 다루는 체계입니다. HashiCorp Vault, OpenBao, AWS Secrets Manager 같은 도구가 여기에 해당합니다.

.env 도 값을 코드 밖으로 빼는 역할은 합니다. 다만 서버마다 사본이 생기고, 누가 읽었는지 남지 않으며, 한 번에 바꾸기도 어렵습니다. 중앙 저장소는 앱의 신원을 확인한 뒤 허용된 값만 내주고 그 기록을 남깁니다.

2. 값을 앱에 넣는 지점

주입 방식은 크게 둘입니다. 환경변수 주입은 프로세스를 띄울 때 저장소에서 값을 받아 환경에 넣는 방식입니다. 앱을 고치지 않아도 되지만, 값을 바꾸면 재기동해야 반영됩니다.

API_KEY=$(vault kv get -field=key secret/app) exec python app.py

런타임 조회는 앱이 필요할 때 저장소 API로 값을 읽는 방식입니다. 재기동 없이 교체되는 대신, 저장소 장애가 앱으로 번질 수 있습니다. 그래서 짧은 TTL 로 캐시해 조회 횟수를 줄이고, 저장소가 잠깐 멈춰도 버티게 합니다.

def get_secret(name, ttl=300):
    hit = cache.get(name)
    if hit and time.time() - hit.at < ttl:
        return hit.value
    value = client.read(name)
    cache[name] = Entry(value, time.time())
    return value

쿠버네티스처럼 값을 파일로 마운트하는 방식도 있습니다. 앱이 파일을 다시 읽어야 새 값이 반영된다는 점만 챙기면 됩니다.

3. 저장소를 둬도 값은 샙니다

중앙 저장소는 보관 단계를 지켜 줄 뿐, 앱이 값을 받은 뒤의 일까지 막아 주지는 않습니다. 자주 새는 자리는 이미지 레이어, git 히스토리, 로그와 예외 메시지, 접속 문자열이 담긴 URL 입니다.

# 나쁨: 이미지 레이어에 값이 남는다
ENV API_KEY=<값>

# 좋음: 빌드에만 쓰고 레이어에 남기지 않는다
RUN --mount=type=secret,id=npm_token ./build.sh

Docker Compose 의 변수 치환도 자주 걸리는 지점입니다. ${API_KEY} 를 치환할 때는 셸 환경변수가 .env 파일보다 우선합니다. 파일은 고쳤는데 셸에 남은 옛 값이 들어가면 원인을 찾기 어려우므로, 컨테이너가 실제로 받는 최종 값까지 확인합니다.

4. 끊김 없는 키 교체

키 교체(로테이션)의 원칙은 새 키를 먼저 깔고, 옛 키는 마지막에 끄는 것입니다. 옛 키를 먼저 폐기하면 앱이 새 키를 받을 때까지 모든 요청이 실패합니다.

# 나쁨: 재기동이 끝날 때까지 전부 401
revoke(old_key)
put_secret("app/key", issue_key())
restart_all()
 
# 좋음: 겹쳐 두고 옮긴 뒤 폐기
put_secret("app/key", issue_key())
restart_rolling()
wait_until(no_recent_use(old_key))
revoke(old_key)

옛 키를 지워도 되는지는 키별 마지막 사용 시각으로 판단합니다. 여러 앱이 키 하나를 나눠 쓰면 어느 앱이 남았는지 구분할 수 없으므로, 키는 앱마다 따로 발급합니다.

헷갈리기 쉬운 점

• 저장소 값을 바꾸면 앱도 바로 새 값을 쓴다는 오해. 기동할 때 주입한 값은 재기동 전까지 옛 값 그대로입니다.
• 시크릿 매니저를 두면 유출이 끝난다는 오해. 앱이 받은 값은 여전히 로그, 예외, URL 로 샐 수 있습니다.
• git 히스토리에서 지우면 해결된다는 오해. 이미 복제됐다고 봐야 하므로 키 폐기가 먼저입니다.

면접에서 자주 받는 질문

정리

• 비밀 관리는 보관뿐 아니라 접근 통제, 감사, 교체까지 다루는 체계입니다.
• 환경변수 주입은 단순하지만 재기동이 필요하고, 런타임 조회는 교체가 빠른 대신 저장소 장애를 함께 떠안습니다.
• 키는 앱마다 따로 발급하고, 사용 기록을 확인한 뒤 옛 키를 폐기합니다.

평소의 교체는 새 키를 먼저 깔고 옛 키를 마지막에 끄면 됩니다. 유출됐을 때만 그 순서를 뒤집습니다.