관리자 계정 보안은 콘텐츠를 다 쓰고 난 뒤에야 뒤늦게 챙기게 되는 항목입니다. 여러 사이트를 운영하다 보면 편의상 같은 아이디를 계속 재사용하게 되는데, 이는 한 곳이 뚫리면 나머지 계정까지 유추당할 수 있는 구조를 만듭니다. 실제로 워드프레스와 티스토리, 네이버까지 세 개 서비스의 아이디가 전부 동일한 상태로 몇 달을 운영해왔다는 걸 뒤늦게 인지했습니다. 이 글에서는 직접 관리자 계정을 교체하고 인증을 강화하며 밟은 다섯 단계를, 계획대로 되지 않았던 지점까지 포함해 순서대로 정리합니다.
관리자 계정 보안의 첫 번째 구멍은 아이디 재사용이다
아이디 하나가 노출되면 나머지가 유추된다
같은 아이디를 여러 서비스에 재사용하면, 공격자는 한 곳의 아이디만 알아내도 나머지 서비스에 로그인을 시도해볼 여지를 갖게 됩니다. 비밀번호가 서로 다르더라도 아이디가 노출돼 있으면 무차별 대입의 첫 관문은 이미 열린 셈입니다. 특히 블로그처럼 작성자 정보가 공개적으로 드러나는 플랫폼에서는 관리자 계정 보안을 아이디 노출 여부부터 점검하는 것이 출발점이 됩니다. 관리자 계정 보안을 비밀번호 강도 문제로만 생각했던 것이 첫 번째 오판이었습니다.
스크린샷보다 상시 노출 지점 찾기가 오래 걸렸다
처음에는 과거 글에 올린 스크린샷에서 아이디가 보이는 부분만 지우면 되는 문제라고 생각했습니다. 실제로 시간이 더 걸린 쪽은 화면에 항상 떠 있는 노출 지점을 찾아내는 일이었습니다. 도구 서비스의 특정 페이지에 네이버 아이디가 텍스트로 그대로 박혀 있는 걸 발견했는데, 스크린샷은 한 장씩 교체하면 끝나지만 이런 하드코딩된 노출은 코드를 고쳐야 사라집니다. 네이버 아이디는 정책상 변경 자체가 불가능하기 때문에, 노출 지점을 발견할 때마다 제거하는 것이 유일한 대응이었습니다.
계정 교체까지 실제로 밟은 세 단계
1단계 백업, 5분이 아니라 이틀이 걸린 이유
계정을 교체하기 전 가장 먼저 한 일은 데이터베이스와 파일 백업이었습니다. 호스팅사 자동 백업으로 DB와 DATA를 각각 요청했는데, DATA는 23초 만에 완료됐고 DB는 몇 분 더 걸렸습니다. 문제는 그다음이었습니다. 백업 파일을 내려받으려는 순간 휴대폰 본인인증 문자가 오지 않아 다운로드 자체가 막혔습니다. 인증 문제가 풀리기를 기다리는 대신, 이미 매일 쌓이고 있던 일일 정기 백업이 최근 7일치 보관된다는 걸 확인하고 이걸 안전망으로 삼아 진행하기로 판단했습니다. 완벽한 절차를 기다리기보다 이미 확보된 안전장치의 수준을 정확히 파악하는 편이 실제로는 더 중요했습니다. 관리자 계정 보안 작업에서 백업은 되돌릴 수 없는 단계 앞에 두는 마지막 보험이기 때문에, 형식보다 실제로 복구 가능한 파일이 어디에 있는지가 관건이었습니다.
2단계 새 계정 생성과 콘텐츠 귀속
새 아이디로 관리자 권한 계정을 만들고 정상 로그인을 먼저 확인했습니다. 여기서 예상 못 한 오류가 하나 나왔습니다. 기존에 쓰던 이메일 주소를 그대로 입력했더니 이미 등록된 이메일이라는 경고가 떴습니다. 워드프레스는 사용자 한 명당 이메일 하나만 허용하기 때문에, 기존 계정이 그 주소를 쓰고 있는 이상 별도 이메일이 필요했습니다. 이 참에 이 계정 전용 이메일을 새로 준비했습니다. 이후 기존 계정을 삭제하면서 콘텐츠를 다른 사용자에게 귀속하기 옵션을 선택해 기존 글 21편의 작성자를 새 계정으로 옮겼고, 삭제 후 사용자 목록에서 새 계정의 글 수가 정확히 21로 바뀐 것을 확인하고 나서 다음 단계로 넘어갔습니다.
계정 교체 직전 사용자 목록. 새 계정의 글 수는 0, 기존 계정이 21편을 보유한 상태였습니다.
3단계 화면에 노출되는 이름 정리
관리자 계정 보안을 강화해도 화면에 실명이나 옛 아이디가 그대로 뜨면 의미가 퇴색됩니다. 계정 교체 직후 글 하나를 열어보니 작성자 이름이 실명으로 표시되고 있었습니다. 로그인 아이디와 화면 표시 이름이 워드프레스 안에서 완전히 별개의 설정이라는 걸 이 시점에 알게 됐습니다. 프로필 이름 표시 항목에서 별명을 지정하고 나서야 실명이 사라졌습니다. 관리자 계정 보안 점검표에 화면 표시 이름 확인을 별도 항목으로 넣게 된 계기였습니다.
이어서 작성자 아카이브 페이지가 검색엔진에 어떻게 처리되는지 확인했습니다. 서치콘솔 URL 검사에서 Google에 등록되어 있지 않음으로 나왔고, 실제 URL 테스트를 돌려보니 robots 메타태그의 noindex 때문에 색인이 차단된 상태였습니다. 원인은 Rank Math 간편 모드에서 작성자 아카이브가 기본적으로 noindex로 설정되는 구조였습니다. 고급 모드로 전환해 작성자 로봇 메타에서 인덱스 없음 체크를 해제한 뒤 다시 테스트하자 색인 가능으로 바뀌었고, 같은 화면에서 프로필 페이지 구조화 데이터가 유효 항목으로 인식되는 것까지 확인됐습니다. 아래는 조치 후 다시 확인한 결과입니다.
2단계 인증과 백업 코드, 그리고 며칠 뒤 발견한 노출
4단계 2단계 인증 적용
관리자 계정 보안에서 가장 실질적인 효과를 낸 조치는 2단계 인증이었습니다. 아이디를 바꿔도 비밀번호가 유출되면 무력화되지만, 2단계 인증은 비밀번호가 뚫려도 로그인 자체를 막는 마지막 방어선이 됩니다. Two-Factor 플러그인이 이미 설치돼 있었는데 상태는 Disabled였습니다. TOTP 방식을 선택해 인증 앱으로 QR코드를 스캔하고 이를 기본 인증 수단으로 지정했습니다. 이메일 인증도 함께 켰지만 보조 수단으로만 남겨뒀습니다. 저장 직후 새 시크릿 탭에서 실제 로그인을 시도해 코드 입력까지 정상 작동하는 것을 확인했습니다.
5단계 백업 코드, 처음엔 0개였다
가장 놓치기 쉬웠던 부분이 백업 코드였습니다. TOTP를 설정한 직후 확인해보니 0 unused codes remaining이라는 문구가 그대로 남아 있었습니다. 코드를 발급받는 것과 그 방식을 활성화하는 것이 서로 다른 단계였는데, 이를 몰랐다면 인증 앱이 든 폰을 잃어버리는 순간 관리자 화면 자체에서 잠길 뻔했습니다. 10개를 발급받아 즉시 안전한 곳에 저장하고 활성화 체크까지 마친 뒤에야 이 단계가 끝났습니다. 관리자 계정 보안에서 흔한 실패가 이렇게 설정을 절반만 끝내고 다 됐다고 착각하는 경우라는 걸 이때 알았습니다.
계정 교체 며칠 뒤에도 남아 있던 노출 두 건
계정 교체가 끝났다고 작업이 끝난 게 아니었습니다. 함께 운영하는 도구 서비스의 한 페이지를 열어보니 스캔 대상 블로그 주소가 기본값으로 화면에 노출되고 있었습니다. 접속하는 모든 방문자에게 실시간으로 보이는 화면이라 스크린샷 한 장과는 차원이 다른 문제였습니다. 같은 날 도구 소개 페이지의 문의 이메일도 네이버 계정 주소가 그대로 적혀 있는 것을 확인했습니다. 두 건 다 계정 교체 작업과는 별개로 발견됐습니다. 결국 관리자 계정 보안은 한 번의 큰 작업으로 끝나는 게 아니라, 새 글을 발행할 때마다 습관적으로 점검하는 루틴으로 유지된다는 걸 실감했습니다.
자주 묻는 질문
아이디를 안 바꾸고 2단계 인증만 적용해도 충분한가요
2단계 인증만으로도 실질적인 방어 효과는 큽니다. 다만 아이디가 여러 서비스에 노출돼 있으면 계정을 특정당할 가능성 자체는 남아 있어서, 가능하면 둘 다 병행하는 편이 안전합니다. 네이버처럼 아이디 변경이 원천적으로 불가능한 서비스라면 2단계 인증과 로그인 알림 설정으로 방어선을 두껍게 만드는 방향으로 대신합니다.
백업 없이 계정 교체를 진행해도 되나요
콘텐츠 귀속 자체는 워드프레스가 공식 지원하는 표준 기능이라 위험도가 낮지만, 계정 삭제라는 되돌릴 수 없는 단계가 포함돼 있어 백업은 생략하지 않는 편을 권합니다. 파일 다운로드가 막히더라도 호스팅사의 일일 자동 백업이 있다면 그것만으로도 최소한의 안전망은 됩니다.
콘텐츠 귀속 대신 새 계정으로 직접 재작성해야 하나요
그럴 필요 없습니다. 귀속 기능을 쓰면 글 내용과 URL, 색인 상태가 전부 그대로 유지되고 작성자 필드만 바뀝니다. 재작성은 시간 낭비이고, URL이 바뀌면 색인까지 새로 쌓아야 하는 손해로 이어집니다.
Two-Factor 플러그인이 없는 워드프레스는 어떻게 하나요
워드프레스 코어팀이 배포하는 무료 Two-Factor 플러그인을 새로 설치하면 됩니다. 별도 유료 서비스 없이 TOTP와 이메일 인증, 백업 코드까지 기본 기능으로 제공합니다.
1인으로 사이트를 운영하다 보면 이런 식으로 계획에 없던 손질이 계속 생깁니다. 계정 하나를 바꾸는 작업이 결국 사흘에 걸친 점검으로 번진 것도 같은 이유였습니다. 도구를 직접 만들어 운영하며 겪은 비슷한 사례도 따로 정리해두었습니다.