여러 페이지 footer의 법무 링크를 한 곳으로

footer에 있던 법무 링크 4개(이용약관, 개인정보처리방침, 이용정책, 제휴 정보 등)가 여러 템플릿 파일에 중복으로 박혀 있던 걸 발견했다. 이걸 central 도메인(legal.hedvion.com)으로 통일했다. 작은 정리 같지만 유지보수 관점에서 생각해볼 게 많은 작업이었다.

산재의 대가

처음엔 별 것 아닌 것 같았다. app/templates/base.html, portfolio/index.html, portfolio/en/index.html 이 3개 파일의 footer 영역에 4가지 법무 링크가 각각 들어가 있었는데, 생각보다 문제가 많더라.

• 링크 변경 시 여러 곳 동시 수정: 약관이 업데이트되거나 URL이 바뀌면 3개 파일을 다 뜯어야 함. 실수로 한 곳만 빠트리면 버전 불일치.
• 리뷰/테스트 부담 증가: footer 법무 링크 수정이라는 간단한 PR도 3개 파일을 grep 하고, 각 파일의 footer 부분을 일일이 확인해야 함.
• 새로운 페이지 추가 시 보일러플레이트: 포트폴리오나 새 서비스 페이지 추가할 때마다 footer 링크를 다시 복사-붙여넣기. 레거시 링크가 섞일 가능성도 있음.

코드로 보면 이런 식:

<!-- app/templates/base.html -->
<footer>
  <a href="/terms">이용약관</a>
  <a href="/privacy">개인정보처리방침</a>
  <a href="/policy">이용정책</a>
  <a href="/partnership">제휴정보</a>
</footer>

<!-- portfolio/index.html -->
<footer>
  <a href="/terms">이용약관</a>
  <a href="/privacy">개인정보처리방침</a>
  <a href="/policy">이용정책</a>
  <a href="/partnership">제휴정보</a>
</footer>

<!-- portfolio/en/index.html -->
<footer>
  <a href="/terms">Terms</a>
  <a href="/privacy">Privacy</a>
  <a href="/policy">Policy</a>
  <a href="/partnership">Partnership</a>
</footer>

이 중복을 없애면:

<!-- 모든 페이지 footer -->
<a href="https://legal.hedvion.com">법무정보</a>

중앙화의 이점

legal.hedvion.com 으로 단일 진실 공급원(Single Source of Truth)을 만든 효과:

또한 UX 관점에서도 좋은 점들이 생겼다:
- 모든 법무 정보를 한 곳에서 찾을 수 있으니 사용자 입장에서도 일관적
- legal 서브도메인이라는 명확한 정책으로 SEO와 신뢰성도 올라감
- 접근성(accessibility) 측면에서도 한 번에 관리 가능

팀장 관점에서의 의사결정

이런 작업은 "기능은 안 늘고 시간만 쓰는 거 아닌가" 하는 의문이 들 수 있다. 실제로 개발팀과 얘기할 때도 나왔던 질문이다. 하지만 내 경험상 이런 작은 정리들이 모여야 속도가 난다.

footer 링크 한 두 개 수정은 금방이겠지만, 서비스가 커지면서:
- 포트폴리오 V2, V3로 버전이 쌓임
- 지역별 랜딩 페이지 추가 (jp, zh, ko 등)
- 관리자 대시보드, 모바일 앱까지 늘어남

이 모든 곳에 법무 링크가 들어가면, 나중에 한 두 개 빠뜨려서 컴플라이언스 이슈가 나거나, PR 리뷰가 복잡해진다. 그래서 지금 당장 영향이 작을 때 정리하는 게 중요하다고 본다.

비슷하게 우리가 했던 개선들:
- API 엔드포인트를 .env 중앙화 (하드코딩된 URL 제거)
- 공통 에러 메시지를 constants 파일로 모음 (여러 컴포넌트의 복붙 제거)
- 설정값(타임아웃, 재시도 횟수)을 config 레이어로 분리

다 아주 작은 변경이지만, 이런 것들이 쌓이면 나중에 "앗, 이 설정 하나 바꾸려면 한 번에 끝낼 수 있네" 하는 경험이 생긴다.

배운 점

이 작업을 하면서 팀과 나눈 얘기:
- 초기엔 "footer는 작으니 그냥 두자"는 의견도 있었지만, 웹사이트 규모가 작을수록 정리가 쉬워진다는 걸 다시 한 번 느꼈다.
- 변경 통계가 작은 PR도 실은 "앞으로의 유지보수 비용"을 줄이는 작업이라고 팀원들과 공유했다.
- 코드리뷰할 때도 "이 코드가 다른 곳에도 있나?" 를 먼저 묻는 습관이 생겼다. 한 곳에 고쳐진 버그도 다른 곳에 있을 가능성이 크니까.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.