관리자 로그인 보안 강화와 DB 백업, 무엇부터 손대야 할까

학습 주제

• 주제: my-blog 관리자 로그인(admin/login) 보안 강화 및 DB 백업 구성
• 날짜: 2026-07-24

탐구 과정

평소에 admin/login 경로가 그대로 노출되어 있는 게 계속 신경 쓰였습니다. 누구나 주소만 알면 로그인 페이지에 접근할 수 있으니, 비밀번호를 더 강력하게 만들고 URL 자체도 덜 눈에 띄게 바꿀 수 없을까 궁금했습니다. 여기에 더해 DB 백업도 제대로 되어 있지 않다는 걸 알고 있어서, 이참에 같이 손보자고 생각했습니다.

먼저 배포 설정 파일들을 뒤져봤는데, 다행히 admin 경로가 코드 여기저기 하드코딩되어 있지는 않았습니다. 만약 여러 곳에 박혀 있었다면 경로 하나 바꾸는 데도 손댈 곳이 많았을 텐데, 구조가 그렇게 나쁘지 않아서 조금 안심이 됐습니다. 그다음엔 기존에 백업 스크립트가 있는지, 어떤 DB를 쓰고 있는지부터 확인하는 과정을 거쳤습니다.

이 과정에서 깨달은 건, 무작정 코드를 고치기 전에 "지금 무엇을 어떻게 결정할지"부터 정리해야 한다는 점이었습니다. 비밀번호 정책을 어느 수준으로 강화할지, URL을 어떤 방식으로 숨길지, 백업 주기와 보관 기간을 어떻게 잡을지—이런 결정들이 먼저 없으면 구현은 시작할 수도 없다는 걸 알게 됐습니다.

핵심 학습 내용

로그인 URL을 숨기는 것의 한계

admin/login 같은 경로를 알아보기 어렵게 바꾸는 건 분명 효과가 있습니다. 자동화된 봇들의 스캐닝을 상당히 줄여주기 때문입니다. 하지만 이건 어디까지나 "security through obscurity"—경로를 숨겨서 얻는 보안일 뿐, 근본적인 보안 대책은 아니라는 걸 다시 확인했습니다. URL이 노출되는 순간 무의미해지니, 다른 보안 계층과 함께 가야 의미가 있습니다.

비밀번호를 강화한다는 것

단순히 "비밀번호를 길게 하자"가 아니라 몇 가지 층위가 있다는 걸 정리했습니다.

• 비밀번호 자체의 복잡도 정책 (길이, 문자 조합)
• 저장 방식: 평문이 아니라 bcrypt, argon2 같은 해싱 알고리즘 사용
• 로그인 시도 제한(rate limiting) — 무차별 대입 공격 방어
• 2단계 인증(2FA) 추가 여부

이 중에서도 해싱 알고리즘 선택이나 로그인 시도 제한은 URL을 숨기는 것보다 훨씬 실질적인 방어라는 걸 알게 됐습니다.

DB 백업은 정책이 먼저

백업이라고 하면 그냥 파일을 복사해두면 될 거라 생각했는데, 실제로는 고려할 게 더 많았습니다.

mysqldump -u [user] -p [database] > backup_$(date +%F).sql

이런 명령어 하나만 있어도 되는 게 아니라,

• 얼마나 자주 백업할지 (cron으로 스케줄링)
• 백업본을 얼마나 오래 보관할지 (retention policy)
• 백업본을 로컬에만 둘지, 아니면 원격/클라우드에도 이중으로 저장할지

이런 정책이 먼저 정해져야 스크립트를 짤 때 방향이 잡힌다는 걸 배웠습니다. 로컬 서버 하나에만 백업이 있으면 그 서버 자체가 문제 생겼을 때 백업도 같이 날아간다는 점도 새삼 다시 생각하게 됐습니다.

이해한 내용

보안이든 백업이든 "한 가지로 완성되는 것"이 아니라 여러 계층을 쌓아야 한다는 게 이번에 다시 확인한 핵심이었습니다. URL을 숨기는 것 하나로 안전해지지 않고, 백업 파일 하나 만들어두는 것으로 안전해지지 않습니다. 그리고 실제로 코드를 고치기 전에, 기존 구조(배포 설정, 백업 스크립트 유무)를 먼저 파악하는 게 왜 중요한지도 체감했습니다. 구조를 모른 채 손대면 나중에 꼬이는 부분이 반드시 생기기 때문입니다.

다만 아직 구체적인 구현—어떤 해싱 라이브러리를 쓸지, 백업 스크립트를 실제로 어떻게 짤지—까지는 정하지 못한 상태라, 이 부분은 다음 단계에서 좀 더 파고들어야 할 것 같습니다.

실전 적용

my-blog 프로젝트에 다음 순서로 적용해볼 계획입니다.

1. admin 경로를 코드에 직접 쓰지 않고 환경변수로 분리
2. 비밀번호 해싱 방식 점검 및 필요시 교체
3. 로그인 실패 횟수 제한 로직 추가
4. cron + mysqldump(또는 사용 중인 DB에 맞는 덤프 도구)로 매일 자동 백업 스크립트 작성
5. 오래된 백업 파일은 자동 삭제되도록 보관 기간 설정
6. 가능하면 백업본을 로컬 외의 다른 저장소에도 복사

추가 학습 계획

• bcrypt와 argon2의 실제 성능·보안 차이 비교해보기
• Fail2ban 같은 로그인 시도 제한 도구 조사
• 백업 스크립트를 직접 작성한 뒤 복구까지 실제로 테스트해보기 (백업만 하고 복구가 안 되면 의미 없으니)
• TOTP 기반 2FA 도입 방법 알아보기