법적 페이지와 푸터 링크 일관성 보장
목차
terms, privacy 같은 법적 페이지들을 footer에서 일관되게 링크하고, 한 곳에서 관리할 수 있도록 구조를 정리했다.
왜 이렇게 작은 것도 챙겨야 하나
사실 처음엔 이런 작업이 우선순위에 밀리기 쉽다. 기능 개발도 바쁘고, 성능 최적화도 해야 하고. 그런데 서비스가 점점 커지면서 footer 어딘가에 깨진 링크가 남거나, 이용약관 페이지가 개발 환경에선 있는데 프로덕션에선 없다거나 하는 일들이 발생한다. 특히 법적 페이지들은 규제 요구사항이 들어가 있는 경우가 많아서, 단순히 "깨진 링크 정도야" 수준으로 넘어갈 수 없다.
팀 입장에서도 문제다. 누군가 footer의 약관 링크를 수정하고, 다른 누군가는 terms 페이지 자체를 리팩토링하다 보면 두 곳이 싱크가 맞지 않는다. 특히 국제화 작업을 시작하면 복잡도가 폭증한다—각 언어별로 페이지가 생기고, footer도 언어마다 달라지고, 경로도 달라지고...
한 곳에서 관리하는 패턴
이 작업에서는 terms 페이지 주변에서 privacy까지 함께 다루면서, footer에서 이 페이지들을 안정적으로 참조할 수 있는 구조를 만들었다.
일반적으로 이런 "법적 페이지 모음"은 몇 가지 방식으로 구현된다:
| 방식 | 장점 | 단점 |
|---|---|---|
| 하드코딩 footer | 간단함 | 경로 변경 시 모든 파일 수정 필요 |
| 설정 파일 (config) | 중앙화된 관리 | 빌드 타임에 반영 |
| 페이지 메타데이터 | 동적, 유연함 | 런타임 오버헤드 |
src/app/terms/page.tsx를 수정하면서 우리는 이 페이지와 privacy 페이지를 함께 관리할 수 있는 경로 규칙을 정했다. 예를 들어:
src/app/legal/
├── terms/
│ └── page.tsx # 이용약관
├── privacy/
│ └── page.tsx # 개인정보 처리방침
└── layout.tsx # 공통 레이아웃
이렇게 하면 footer component에서는 단순히 /legal/terms, /legal/privacy 로 참조하면 되고, 페이지가 추가되거나 제거될 때도 footer에서는 상관없다.
작은 것부터 잘 다루는 문화
사실 이런 작업이 팀 전체의 개발 문화를 반영한다. 기능만 추가하고 지저분한 부분은 방치하는 팀과, 작은 debt도 챙기면서 기초를 튼튼히 하는 팀. 저는 후자를 선호한다.
코드 리뷰할 때도 이걸 본다. 누군가 새 페이지를 추가했을 때, footer 링크를 빼먹지 않았는지 확인하는가? 아니면 "일단 기능만 가동되면 됨"으로 넘어가는가? 전자의 문화가 쌓이면 6개월 뒤, 1년 뒤 서비스가 훨씬 깔끔하다.
특히 이용약관, 개인정보 처리방침 같은 법적 페이지는 깨졌을 때 사용자 입장에서는 "서비스를 못 믿겠다"는 느낌을 주기도 한다. 단순 기능 버그와는 다른 종류의 손상이다.
이번 작업을 팀에 공유하면서 "이 정도 스케일의 리팩토링은 한 명이 30분에 끝낼 수 있으니, 계속 이렇게 작은 것부터 챙기자"고 말했다. 모래알 같은 개선들이 모이면 전체 시스템 신뢰도가 올라간다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.