네이버 서치어드바이저 소유 확인 자체는 이미 끝난 상태였다. 인증용 HTML 파일 주소로 접속하면 HTTP 200이 나왔고, 파일 내용도 정상적으로 응답했다.
겉으로 보면 더 손댈 이유가 없어 보였다.
문제는 파일이 어디에 있느냐였다. 당시 WordPress의 /var/www/html은 Docker named volume인 wordpress_data를 사용하고 있었고, 네이버 인증 파일도 그 안에 런타임 상태로 존재했다. 같은 볼륨을 계속 쓰는 동안에는 문제가 없지만, 저장소만 받아 새 환경을 구성하면 Compose 파일 어디에도 그 인증 파일을 복원할 정보가 없었다.
그래서 인증 방식을 바꾼 게 아니라, 이미 잘 동작하던 파일을 배포 구성이 다시 만들 수 있는 상태로 옮겼다.
잘 되는 파일을 굳이 Git으로 옮긴 이유
네이버 서치어드바이저의 HTML 파일 소유 확인 안내를 보면 발급받은 HTML 파일을 사이트 루트 폴더에 업로드하도록 되어 있다.
일반적인 호스팅이라면 FTP로 루트에 올려두는 것으로 끝날 수 있다. Docker WordPress에서는 여기서 한 가지를 더 생각해야 했다.
WANY BLOG의 WordPress document root는 이미 named volume으로 관리되고 있었다.
volumes:
- wordpress_data:/var/www/html이 구조에서는 WordPress 컨테이너를 다시 만들어도 같은 wordpress_data 볼륨을 붙이면 기존 파일이 남는다. 따라서 이번 문제를 단순히 “컨테이너를 재생성하면 인증 파일이 사라진다”라고 설명하면 맞지 않는다.
대신 이런 차이가 있었다.
기존 상태
Git + Compose ──> WordPress 실행
└─ wordpress_data 안에 인증 파일이 수동으로 존재
원하는 상태
Git + Compose ──> 인증 파일 위치와 내용까지 재현 가능운영 중인 서버에서는 잘 보이지만, 새 서버에서 저장소를 clone하고 새 볼륨으로 시작하면 인증 파일은 자동으로 생기지 않는다. 런타임 볼륨에만 있던 파일이기 때문이다.
WordPress 전체가 아니라 인증 파일 하나만 bind mount했다
해결할 때 기존 wordpress_data 구조를 없애지는 않았다.
네이버에서 받은 인증 파일을 저장소의 wordpress/ 아래에 두고, 그 파일 하나만 WordPress document root의 같은 경로에 read-only로 연결했다.
실제 인증 토큰이 들어간 파일명은 여기서는 가리고 구조만 적으면 다음과 같다.
services:
wordpress:
volumes:
- wordpress_data:/var/www/html
- ./wordpress/naverXXXXXXXX.html:/var/www/html/naverXXXXXXXX.html:ro핵심은 마지막의 :ro다.
Docker의 bind mount 공식 문서에서도 bind mount는 호스트의 파일이나 디렉터리를 컨테이너 경로에 연결할 수 있고, ro 또는 readonly 옵션으로 컨테이너에서 쓰지 못하게 할 수 있다고 설명한다.
인증 파일은 WordPress가 수정할 이유가 없는 정적 파일이다. 그래서 document root 전체를 Git 쪽으로 바꾸거나 별도 플러그인을 추가할 필요 없이, 필요한 파일 하나만 읽기 전용으로 겹쳐 올리는 쪽이 단순했다.
기존 구조는 그대로다.
/var/www/html
├─ WordPress 파일들 ← wordpress_data
├─ wp-content ← 기존 구성
└─ naverXXXXXXXX.html ← Git 파일을 read-only bind mount수정 뒤에는 파일 존재 여부보다 응답 내용까지 확인했다
마운트를 추가한 뒤에는 WordPress 컨테이너만 다시 만들어 같은 결과가 유지되는지 확인했다.
검증은 세 군데를 봤다.
먼저 Docker 설정에서 해당 경로가 실제 bind 타입이고 쓰기 불가능한 상태인지 확인했다. 저장소의 인증 파일 내용도 예상한 한 줄과 정확히 같은지 비교했다.
그다음 컨테이너 내부에서 document root의 인증 파일을 읽어 같은 내용이 나오는지 확인했다.
마지막으로 공개 주소에서 파일을 직접 요청했다.
https://wanyblog.com/naverXXXXXXXX.html이 요청은 HTTP 200을 반환했고, 공개 응답 본문도 저장소에서 관리하는 내용과 일치했다. WordPress 컨테이너만 재생성한 뒤에도 같은 결과가 유지됐다.
여기서 확인한 것은 네이버 소유 확인 파일이 공개 주소에서 정확히 제공된다는 것까지다. 이 상태가 검색 노출이나 순위를 보장한다는 의미는 아니다.
결국 바꾼 것은 인증 방식이 아니라 복구 방식이었다
처음부터 인증 파일이 깨져 있었던 것은 아니다. 오히려 이미 잘 동작하고 있었기 때문에 놓치기 쉬운 문제였다.
런타임 볼륨에만 존재하는 파일은 현재 서버에서는 계속 살아 있을 수 있다. 하지만 서버를 새로 만들거나 볼륨을 새로 시작했을 때 저장소와 Compose만으로 같은 상태를 만들 수 있는지는 별개의 문제다.
WANY BLOG에서는 네이버 인증 파일을 Git에 두고 파일 하나만 read-only bind mount하면서 이 차이를 없앴다. 기존 WordPress named volume은 그대로 유지했고, 외부에서 반드시 같은 경로로 제공되어야 하는 작은 정적 파일만 배포 구성에 포함했다.
Docker WordPress에서 서치어드바이저 인증 파일을 관리한다면, 파일이 지금 열리는지만 확인하는 것보다 새 환경에서도 그 파일을 어떻게 다시 만들 것인지까지 같이 정해두는 편이 관리하기 쉽다.