장례 서비스에 지역별 가이드 카테고리 추가

지역별 가이드 카테고리를 새로 추가했다. 파일 하나, 한 줄짜리 커밋처럼 보이지만 이 작업이 왜 지금 시점에 필요했는지는 좀 풀어둘 필요가 있다.

배경 — 카테고리 구조가 왜 중요한가

장례 관련 서비스에서 콘텐츠를 다룰 때 카테고리 설계는 생각보다 까다로운 영역이다. 단순히 "태그 목록"이 아니라 콘텐츠 분류 체계 자체가 곧 사용자 탐색 경험이 되기 때문이다. 특히 장례처럼 사용자가 혼란스럽고 시간 압박이 있는 상황에서 접근하는 서비스일수록 "내가 지금 어디 있는지"를 즉각적으로 파악할 수 있게 해주는 게 중요하다.

기존에는 절차 안내, 비용 안내 등 일반적인 카테고리들로만 구성돼 있었다. 그런데 실제로 서비스를 운영하다 보면 "우리 동네 장례식장은 어디?", "이 지역에서는 어떤 절차가 일반적이야?" 같은 지역 기반 질문이 꾸준히 들어온다. 정보의 성격 자체가 지역마다 달라지는 케이스가 분명히 존재하는 것이다.

작업 내용 — categories.ts 한 파일의 무게

변경 파일은 src/lib/categories.ts 하나다. 통계가 지정되지 않았으니 라인 수로 보면 아마 크지 않은 수정이었을 것이다. 하지만 이 파일이 어떤 역할인지를 보면 얘기가 달라진다.

lib/categories.ts 같은 파일은 보통 애플리케이션 전역에서 카테고리 상수나 타입을 공급하는 소스 오브 트루스(Source of Truth)로 쓰인다. 여기에 새 항목을 추가한다는 건 단순 데이터 추가가 아니라:

• 라우팅 구조에 영향을 줄 수 있고
• 카테고리 필터 UI 컴포넌트가 자동으로 반영되는지 확인이 필요하며
• CMS나 어드민 쪽에서 카테고리 enum을 바라보고 있다면 그쪽도 연동 확인이 필요하다

// 예시: 카테고리 상수 구조
export const CATEGORIES = {
  PROCEDURE: 'procedure',       // 절차 안내
  COST: 'cost',                 // 비용 안내
  REGION: 'region',             // 지역별 가이드 (신규 추가)
} as const;

export type CategoryKey = keyof typeof CATEGORIES;
export type CategoryValue = typeof CATEGORIES[CategoryKey];

이런 식으로 상수 + 타입 추론까지 묶어두면 이후 컴포넌트에서 하드코딩 없이 안전하게 쓸 수 있다. 타입스크립트를 쓰는 이유 중 하나가 바로 이런 열거형 확장 시 컴파일 타임에 누락을 잡아주는 것이기도 하고.

카테고리 추가, 언제 팀 논의가 필요한가

이런 "작은 것처럼 보이는" 추가 작업에서 팀장 입장으로 항상 신경 쓰는 부분이 있다.

특히 마지막 항목은 자주 놓친다. 카테고리를 코드에서 먼저 추가하고, 실제 콘텐츠 등록은 나중에 하는 경우 사용자가 빈 목록 페이지를 보게 되는 상황이 생긴다. 릴리즈 타이밍을 콘텐츠팀과 맞추는 게 중요한 이유다.

회고

region이라는 카테고리 키워드 자체가 흥미롭다. 지역 정보는 정적 콘텐츠이면서도 로컬라이즈 요구사항이 붙을 수 있는 영역이라, 이게 추후 어떻게 확장될지를 살짝 고민하게 된다. 광역시/도 단위로 세분화할 건지, 아니면 지역 태그를 별도로 가져갈 건지는 콘텐츠 볼륨이 쌓인 뒤에 결정해도 늦지 않다.

지금은 카테고리 하나 추가로 시작하지만, 이 결정이 나중에 필터 UI, 사이트맵, 검색 인덱싱까지 이어지는 시작점이 된다는 걸 팀 전체가 인식하고 있어야 한다. 작은 커밋에도 맥락 공유가 필요한 이유.

다음엔 이 카테고리에 실제 콘텐츠가 붙는 작업이 이어질 것 같다.