[워드프레스] 5. 주소 : 퍼머링크와 리라이트 규칙 동작 원리

* 이 게시물은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

(워드프레스 해부 ⑤) 주소

/?p=123 같은 주소가 어떻게 /my-post/처럼 예쁘게 바뀌는 걸까? 서버에 my-post라는 폴더가 있는 것도 아닌데. 이 마법의 정체가 리라이트(rewrite)다.

순서는 이렇다. 방문자가 /my-post/를 요청하면, 웹서버(Apache면 .htaccess, Nginx면 설정)가 “실제 파일이 없네? 그럼 전부 index.php로 보내”라고 넘긴다. 그러면 워드프레스가 그 URL 문자열을 받아 rewrite_rules라는 정규식 규칙표와 대조해서 “아, 이건 slug가 my-post인 글을 달라는 거구나” 하고 내부 쿼리로 번역한다. 즉 예쁜 URL → 정규식 매칭 → DB 쿼리의 흐름이다.

이 규칙표는 어디 있냐면, 놀랍게도 데이터베이스에 있다. wp_options 테이블의 rewrite_rules 옵션에 통째로 저장돼 있다. 그래서 퍼머링크 구조를 바꾸면 이 규칙표를 새로 만들어야(flush) 한다.

Table of Contents

직접 해보기

설정 → 고유주소에서 구조를 바꿔보고, 규칙표가 실제로 DB에 들어 있는 걸 확인하자. WP-CLI가 있으면:

# 현재 저장된 리라이트 규칙 보기 (정규식 → 쿼리 매핑이 쭉 나온다)
$ wp option get rewrite_rules --format=json | head

# 퍼머링크 구조 확인
$ wp option get permalink_structure
# 예: /%postname%/

/%postname%/(슬러그 기반)가 SEO에 제일 유리하다. 숫자 ID(/?p=123)나 날짜 기반보다 키워드가 URL에 담기니까. 다만 구조를 바꾸면 기존 URL이 바뀐다 — 이미 운영 중인 사이트라면 옛 주소에서 새 주소로 301 리다이렉트를 챙겨야 검색 순위를 잃지 않는다.

✅ 확인 — 퍼머링크 구조를 바꾼 뒤 글이 404가 난다면, 규칙표가 아직 갱신 안 된 거다. 설정 → 고유주소에서 “변경사항 저장”을 한 번 누르면 flush 되면서 해결된다. 이 “저장만 눌러도 고쳐지는” 현상의 정체가 바로 rewrite_rules flush다.

구조 고르기 — /%postname%/이 정석

설정 > 고유주소에서 구조를 고른다. SEO와 가독성 면에서 글 슬러그만 쓰는 /%postname%/가 가장 무난하다. 몇 가지를 비교하면 이렇다.

구조	예시	평가
기본	/?p=123	안 예쁘고 SEO 불리
날짜형	/2026/08/글-제목/	URL이 길고 글이 낡아 보임
글 이름	/글-제목/	짧고 명확 — 권장
카테고리+이름	/분류/글-제목/	괜찮지만 분류 바꾸면 URL이 바뀜

리라이트가 안 먹을 때 — 규칙 플러시

위의 ✅확인에서 본 그 현상, 코드 쪽 얘기를 마저 하자. 플러그인에서 커스텀 포스트 타입이나 새 구조를 등록했는데 404가 뜨는 것도 같은 원인이다. 해결은 간단하다 — 설정 > 고유주소 화면을 열고 아무것도 안 바꿔도 ‘변경사항 저장’만 누르면 규칙표가 다시 생성(플러시)된다. 코드에선 flush_rewrite_rules()인데, 매 요청마다 부르면 안 되고 플러그인/테마 활성화 시 한 번만 부른다.

register_activation_hook( __FILE__, function () {
    my_register_cpt();        // 먼저 규칙을 등록하고
    flush_rewrite_rules();    // 활성화 때 딱 한 번 플러시
} );

커스텀 리라이트 직접 만들기

/recipe/kimchi 같은 예쁜 URL을 직접 만들려면 add_rewrite_rule로 정규식 규칙을 등록하고, 필요하면 add_rewrite_tag로 쿼리 변수를 연결한다. URL 문자열을 정규식으로 잡아 내부 쿼리로 번역하는 것이다.

add_rewrite_rule(
    '^recipe/([^/]+)/?$',            // 이런 URL이 오면
    'index.php?recipe=$matches[1]',  // 이 내부 쿼리로 번역
    'top'
);

Nginx라면 — .htaccess가 없다

아파치의 .htaccess 얘기만 하고 넘어가면 반쪽이다. Nginx엔 .htaccess가 없어서, “없는 파일은 전부 index.php로”를 서버 설정에 직접 적는다 — 핵심은 try_files 한 줄이다.

# nginx server 블록
location / {
    try_files $uri $uri/ /index.php?$args;
}
# 파일 있으면 그대로, 폴더면 폴더로, 둘 다 없으면 index.php로

워드프레스 쪽 리라이트 규칙표는 서버와 무관하게 DB에 있으므로, Nginx로 옮겨도 퍼머링크 로직 자체는 그대로다 — 관문(index.php로 보내기)만 서버마다 다르게 열어줄 뿐이다.

구조를 바꿀 땐 반드시 301 리디렉션

이미 검색에 색인된 사이트의 퍼머링크 구조를 바꾸면 기존 링크가 전부 깨진다(404 → SEO 타격). 부득이 바꿔야 한다면 301 리디렉션으로 옛 URL을 새 URL로 이어줘야 한다. Redirection 같은 플러그인이나 서버 설정으로 처리한다. 사실 최선은 처음에 잘 정하고 두 번 다시 안 바꾸는 것이다.

기초 구조는 여기까지다. 마지막 편에선 이 시리즈를 제대로 따라오기 위한 워드프레스 분해용 실습 환경을 세팅한다 — 안을 들여다보는 도구 세 가지.

자주 묻는 질문 (FAQ)

퍼머링크 구조를 바꾸면 기존 링크가 깨지나요?

깨질 수 있습니다. 옛 URL이 404가 될 수 있어, 리다이렉트를 걸어 통합해야 합니다.

리라이트 규칙이 안 먹혀요.

설정 → 고유주소에서 한 번 저장하면 규칙이 다시 생성(flush)됩니다. .htaccess 쓰기 권한도 확인하세요.