Rails의 기본 URL 구조와 한계
Ruby on Rails에서 모델 인스턴스를 참조하는 URL을 생성할 때, 프레임워크는 기본적으로 데이터베이스의 기본 키(Primary Key)인 id 값을 사용합니다. 예를 들어 article_path(@article)을 호출하면 /articles/42와 같은 경로가 생성됩니다. 이러한 방식은 명확하고 단순하지만, 몇 가지 단점이 존재합니다.
- 가독성 부족: URL만 보고는 해당 페이지가 어떤 내용을 담고 있는지 알 수 없습니다.
- SEO 불리: 검색 엔진 최적화 측면에서 키워드가 포함되지 않아 검색 결과 노출에 불리할 수 있습니다.
- 보안 및 프라이버시: 시스템의 내부 식별자와 데이터의 양이 외부에 노출될 수 있습니다.
to_param 메서드를 활용한 커스터마이징
Rails의 URL 헬퍼 메서드들은 내부적으로 모델의 to_param 메서드를 호출하여 URL에 포함될 문자열을 결정합니다. 기본값은 id.to_s를 반환하도록 설정되어 있지만, 이를 모델 클래스 내에서 오버라이드함으로써 원하는 형태의 URL을 정의할 수 있습니다.
1. 슬러그(Slug) 기반 URL 구현
가장 일반적인 방법은 제목(title) 등을 변형한 ‘슬러그’를 사용하는 것입니다.
```ruby class Article < ApplicationRecord before_save { self.slug = title.parameterize }
def to_param slug end end ```
이렇게 구현하면 URL은 /articles/understanding-rails-extensions와 같은 형태가 됩니다. 다만, 이 경우 컨트롤러에서 find 대신 find_by!(slug: params[:id])를 사용하여 레코드를 찾아야 하며, 슬러그 컬럼에 유니크 인덱스를 설정해야 합니다.
2. ID와 슬러그의 결합 (Hybrid Approach)
가장 효율적인 절충안은 ID 뒤에 슬러그를 붙이는 방식입니다.
ruby
def to_param
"#{id}-#{title.parameterize}"
end
이 방식의 영리한 점은 Ruby의 문자열 처리 특성을 활용한다는 것입니다. "42-some-title".to_i를 실행하면 정수 42가 반환됩니다. 따라서 컨트롤러에서 별도의 수정 없이 기존의 Article.find(params[:id]) 코드를 그대로 사용할 수 있으면서도, 브라우저 주소창에는 의미 있는 텍스트가 노출됩니다.
고려해야 할 사항과 전문 도구
직접 to_param을 구현할 때는 몇 가지 주의점이 있습니다. 슬러그가 변경될 경우 이전 URL로 접속하는 사용자들을 위해 301 리다이렉트를 처리해야 할 수도 있으며, 중복된 슬러그가 발생하지 않도록 로직을 설계해야 합니다.
더 복잡한 요구사항이 있는 경우에는 다음과 같은 라이브러리를 고려해 볼 수 있습니다: - friendly_id: 슬러그 생성, 중복 방지, 변경 이력 추적(History) 등 슬러그와 관련된 거의 모든 기능을 제공하는 업계 표준 라이브러리입니다. - prefixed_ids: Stripe 스타일의 인코딩된 ID(예: user_5vJjb…)를 생성하여 순차적인 ID 노출을 방지하면서도 고유성을 유지합니다.
이러한 기법들을 적절히 활용하면 서비스의 전문성을 높이고 사용자에게 더 나은 탐색 경험을 제공할 수 있습니다.