분류 > IT 게시판

FastAPI 라우팅 최적화: 한글 URL 쿼리를 영문 Slug로 변환하여 SEO 점수와 웹사이트 신뢰도(E-E-A-T) 높이기

👤 인스피

조회 수 15

1. 왜 영문 Slug(식별자)를 사용해야 할까?

구글 애드센스의 승인 가이드라인(E-E-A-T)과 검색엔진 최적화(SEO) 정석에 따르면, URL은 사용자와 로봇 모두가 읽고 이해하기 쉬워야 합니다.

한글로 된 쿼리 스트링(?board=자유게시판)은 개발할 때는 직관적일지 모르나, 웹의 표준 통신 규약 상 브라우저가 이를 ASCII 문자로 변환해야 하므로 끝없이 긴 특수문자 조합으로 깨지게 됩니다.

반면, 게시판의 고유 식별자를 영문 소문자와 하이픈(-)으로 이루어진 Slug(슬러그)로 처리하게 되면 다음과 같은 엄청난 이점이 생깁니다.

신뢰성(Trust) 상승: 링크가 깔끔해져(?board=gif) 유저들이 안심하고 클릭 및 공유할 수 있습니다.
SEO 최적화: 구글 크롤러 봇이 URL만 보고도 해당 페이지가 어떤 성격의 페이지(예: /board/tech, /board/humor)인지 의미(Semantic)를 파악할 수 있어 색인 점수가 올라갑니다.

2. 백엔드(FastAPI) 및 데이터베이스 구조 변경

이 아이디어를 실제 시스템에 적용하기 위해서는 파이썬 FastAPI 백엔드와 PostgreSQL 데이터베이스의 매핑 구조를 변경해야 했습니다.

가장 먼저 데이터베이스의 Board (게시판) 테이블에 slug라는 새로운 컬럼을 추가했습니다.

기존: name = "움짤 게시판"
변경: name = "움짤 게시판", slug = "gif"

그리고 FastAPI의 라우터 코드에서 게시판 목록을 조회할 때, 기존에는 한글 이름을 직접 필터링했다면 이제는 영문 slug를 받아 매핑하도록 비즈니스 로직을 수정했습니다.

프론트엔드(Jinja2 템플릿)의 HTML 링크들도 모두 <a href="/?board={{ board.slug }}"> 형태로 찾아바꾸기를 진행하여, 더 이상 한글이 URL에 노출되지 않도록 완벽하게 봉쇄했습니다.

3. 트러블슈팅: 기존에 색인된 한글 URL들의 404 에러 방어

프론트엔드와 백엔드 코드를 깔끔하게 영문 Slug로 바꾼 후 배포를 완료했습니다. "이제 완벽하다!"라고 생각했지만, 며칠 뒤 구글 서치 콘솔에서 '404 Not Found (페이지를 찾을 수 없음)' 에러가 폭증하기 시작했습니다.

원인은 구글 검색 로봇이었습니다. 구글은 이미 과거의 지저분한 한글 URL(?board=%EC%9B...)들을 수집해서 검색 결과에 띄워두었는데, 제가 백엔드에서 한글 파라미터를 더 이상 받지 않도록 로직을 바꿔버렸으니 로봇과 기존 방문자들이 모두 404 에러 페이지를 마주하게 된 것입니다.

이를 해결하기 위해, 저는 FastAPI에 '301 영구 리다이렉트(Permanent Redirect)' 미들웨어 로직을 긴급하게 추가했습니다. 만약 누군가 과거의 한글 파라미터로 접속을 시도하면, 에러를 뿜는 대신 "이 페이지는 영문 주소로 이사 갔어!"라고 알려주며 새로운 Slug 주소로 강제 이동시켜 주는 것입니다.

이 코드를 적용한 직후 404 에러는 말끔히 사라졌고, 구글 검색 엔진도 기존의 한글 주소를 새로운 영문 Slug 주소로 자연스럽게 업데이트하기 시작했습니다.

맺으며: 1인 개발자의 집요함이 신뢰를 만든다

URL에 쿼리 스트링 몇 글자가 깨진다고 해서 당장 사이트가 멈추거나 서비스가 불가능해지는 것은 아닙니다. 하지만 이런 작은 디테일들이 모여 웹사이트 전체의 '유저 경험(UX)'과 '신뢰도'를 결정짓습니다.

특히 2026년 이후의 구글 애드센스 승인과 검색 알고리즘은 "이 사이트가 얼마나 전문적으로 잘 관리되고 있는가?"를 매우 까다롭게 평가합니다. 스팸처럼 보이는 긴 인코딩 주소를 직관적인 영문 Slug(?board=gif 또는 /board/gif)로 정돈하는 백엔드 개발자의 집요한 최적화 과정은, 심사 봇과 유저 모두에게 최고의 평가를 받을 수 있는 확실한 무기가 될 것입니다.

❓ 자주 묻는 질문 (FAQ)

Q1. `?board=gif` 같은 Query String 방식 말고 `/board/gif` 같은 패스 파라미터(Path Parameter) 방식이 더 좋지 않나요?

A. 네, 맞습니다! SEO 관점에서는 쿼리 파라미터(?board=gif)보다 계층 구조가 명확한 패스 파라미터(/board/gif) 방식이 조금 더 유리한 정석적인 방법입니다. 하지만 기존 시스템의 아키텍처와 라우터 충돌 여부를 고려하여 현재 구조에서 가장 안전한 방식을 채택하는 것이 실무적으로는 더 중요합니다.

Q2. 영문 Slug를 도입하면 개별 게시글 주소(예: `/post/1234`)도 다 영어로 바꿔야 하나요?

A. 아닙니다. 게시판(카테고리) 이름처럼 문자로 식별해야 하는 곳에는 영문 Slug가 필수적이지만, 개별 게시글은 지금처럼 1234 같은 고유한 숫자 ID(Primary Key)를 그대로 사용하는 것이 데이터베이스 조회 속도(인덱스 탐색) 면에서 훨씬 빠르고 효율적입니다.

Q3. 한글을 썼던 모든 과거 링크에 301 리다이렉트를 반드시 걸어줘야 하나요?

A. 절대적으로 필요합니다. 301 리다이렉트 없이 구조만 바꾸면 기존에 구글 검색이나 외부 커뮤니티에 공유되었던 모든 링크가 404 에러를 뿜으며 죽은 링크(Broken Link)가 됩니다. 이는 검색엔진 최적화(SEO) 점수를 폭락시키는 최악의 지름길이므로, 주소 체계를 바꿀 때는 301 이동 로직을 필수적으로 짜주어야 합니다.