멤버 검색 페이지 추가로 다국어 라우팅 기초 마련
목차
멤버 검색 페이지를 추가하고 데이터 시드를 설정하는 작업을 했다. 단순히 새로운 페이지 하나를 띄우는 것처럼 보이지만, 사실은 팀이 앞으로 다국어 기능을 확장할 때 따를 수 있는 패턴을 정립한 것이다.
왜 이 작업이 필요했나
사용자 입장에서 생각해보면, 특정 멤버를 찾고 싶을 때 메뉴를 통해 접근할 방법이 있어야 한다. 아이돌 정보 제공 서비스라면 "멤버는 누가 있나요?"라는 가장 기본적인 질문에 답할 수 있는 페이지가 필수다. 개발 초기에는 홈 페이지나 특정 섹션에서만 멤버 정보를 산발적으로 보여줄 수 있지만, 시간이 지나면서 "한 곳에서 전체 멤버를 확인하고 검색할 수 있는 dedicated 페이지"가 필요해진다.
동시에 다국어 지원이라는 숙제가 있었다. 같은 콘텐츠를 en, ja, ko 등 여러 언어로 제공하려면, 라우팅 구조부터 명확하게 잡아야 한다. 초반에 영어로만 구현했다가 나중에 다국어를 추가하려면 리팩토링 비용이 크다. 그래서 이번 작업에서 다국어 패턴을 먼저 정의하는 것을 우선했다.
라우팅 구조와 파일 조직
변경 파일들을 보면 흥미로운 패턴이 보인다.
src/pages/members/index.astro
src/pages/[lang]/members/index.astro
두 개의 경로가 있다. 일반적으로 [lang]/members 는 /en/members 또는 /ko/members 처럼 언어 파라미터를 받는 다국어 페이지고, members/index.astro 는 기본 경로나 리다이렉트 역할을 할 가능성이 높다. Astro의 파일 기반 라우팅에서는 이렇게 다층 구조를 만들 수 있고, 빌드 시 정적 페이지로 모두 생성된다.
이 구조의 장점:
- 각 언어별로 별도 URL을 가져 SEO 친화적
- 브라우저 기본 언어 설정을 감지하고 리다이렉트 가능
- 사용자가 수동으로 언어를 전환할 때 같은 경로 구조 유지
컴포넌트와 데이터 계층
변경 파일에는 MembersListPage.astro 라는 컴포넌트가 포함됐다. 이는 멤버 목록을 화면에 그리는 UI 로직을 담당하고, 실제 데이터는 src/lib/db.ts 를 통해 쿼리한다.
| 파일 | 역할 |
|---|---|
MembersListPage.astro |
멤버 리스트 UI 컴포넌트 |
db.ts |
데이터베이스 접근 계층 |
[lang]/members/index.astro |
다국어 페이지 (쿼리 + 컴포넌트) |
Base.astro |
공통 레이아웃 (네비게이션 등) |
이런 분리는 테스트와 재사용성 면에서 중요하다. 멤버 리스트 컴포넌트를 모달, 사이드바, 카드 그리드 등 여러 곳에서 재사용할 수 있기 때문이다. 또한 데이터 패칭 로직이 DB 계층에 모여 있으면, 나중에 API를 추가하거나 캐싱 전략을 변경할 때 한 곳만 수정하면 된다.
데이터 시드의 실용성
db/seed-rescene.sql 파일이 추가된 것도 주목할 점이다. 데이터베이스 마이그레이션만 있고 초기 데이터가 없으면, 개발자들이 로컬에서 테스트할 때 매번 수동으로 더미 데이터를 입력해야 한다. Seed 파일을 두면:
- 새 팀원이 온보딩할 때
db seed한 번으로 개발 환경 완성 - CI/CD 파이프라인에서 자동으로 테스트 데이터 준비
- Git 히스토리에 기록되어 언제 어떤 데이터가 추가됐는지 추적 가능
다만 시간이 지나면서 seed 파일이 비대해질 수 있다. 초반에는 괜찮지만, 수백 개의 멤버 정보가 들어가면 SQL이 길어지고 리뷰하기 어렵다. 이 경우 JSON 포맷으로 변경하거나, seed 생성을 자동화하는 스크립트를 별도로 두는 것도 고려할 만하다.
이 작업이 다음 기능 추가에 주는 영향
가장 중요한 부분은 앞으로 다른 페이지를 추가할 때 사람들이 따를 수 있는 템플릿이 생겼다는 것이다. 예를 들어 "공지사항 페이지"나 "팬아트 갤러리"를 추가할 때:
src/pages/[lang]/news/index.astro파일을 생성- 필요한 데이터는
db.ts에 쿼리 함수 추가 - UI 컴포넌트 (
NewsListPage.astro) 분리 - Seed 데이터 추가
이 흐름을 한 번 경험했으니, 다음 페이지는 빨리 따라갈 수 있다. 또한 Base 레이아웃이 업데이트되면 멤버 페이지도 자동으로 네비게이션이 추가되는 식으로 일관성이 유지된다.
한 가지 배운 점은, 작은 기능 하나를 추가할 때도 "이게 아키텍처 패턴이 될 수 있을까"를 생각하면서 구조를 잡는 게 중요하다는 것이다. 나중에 같은 패턴을 반복할 때 코드 복제가 줄어들고, 팀원들 사이에서 "아, members 페이지처럼 하면 되는군" 하는 공통 언어가 생긴다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.