약관 페이지 추가하며 풋터 구조를 다시 보다

약관 페이지를 추가하고 풋터에 링크를 달았다. 작업 자체는 간단해 보였지만, 공통 레이아웃을 수정한다는 게 생각보다 많은 것들을 함께 결정하는 일이었다.

약관이 필요했던 이유

서비스가 성장하면서 법적인 페이지들이 필수가 된다. 약관은 단순한 법적 문서가 아니라, 사용자와의 신뢰 관계를 명시하는 첫 번째 인상이다. 특히 사용자 데이터를 다루거나 거래 관계가 있는 서비스라면, 약관의 가시성이 중요하다.

풋터는 서비스 전체에서 가장 일관되게 노출되는 영역이다. 모든 페이지 하단에 있으므로, 약관 링크를 풋터에 넣는 것은 "우리는 투명성을 중요하게 생각한다"는 신호다. 사용자도 필요할 때 자연스럽게 찾을 수 있고, 서비스 신뢰도도 올라간다.

구현: 페이지 추가에서 풋터 링크까지

두 가지 파일을 수정했다.

src/pages/terms.astro — 약관 페이지 본체다. 정적 페이지 생성 방식이므로, 빌드 시점에 HTML로 변환되어 서빙된다. 검색 엔진도 쉽게 크롤링할 수 있고, 로딩 속도도 빠르다. 약관은 자주 바뀌지 않는 콘텐츠이므로 정적 페이지가 적합하다.

src/layouts/Base.astro — 공통 레이아웃 파일이다. 거의 모든 페이지가 이 레이아웃을 상속받는다. 여기서 풋터를 관리하므로, 한 곳만 수정하면 전체 사이트의 풋터가 일관되게 업데이트된다.

구현 패턴은 이렇다:
- 약관 페이지를 새 파일로 작성
- 레이아웃의 풋터 영역에 약관 링크 추가
- 빌드 시 정적 HTML로 생성되어 배포

이 과정에서 "어느 풋터에 어떤 순서로 링크를 놓을 것인가"라는 소소한 결정들이 쌓인다.

공통 컴포넌트 변경이 의미하는 것

Base.astro는 공통 레이아웃이므로, 이 파일을 수정한다는 건 팀 전체에 영향을 미친다는 뜻이다.

• 다른 팀원이 새 페이지를 만들 때 풋터에 자동으로 약관 링크가 들어간다
• 풋터 링크 정책이 암묵적으로 정해진다
• 향후 개인정보 같은 다른 법적 페이지를 추가할 때 일관된 패턴을 따를 수 있다

그래서 공통 컴포넌트를 수정하기 전에 확인했어야 할 것들:
- 풋터 링크 순서나 구조가 팀 내에서 정해진 건가?
- 다른 팀원들도 이 변경을 명확히 인지할 것인가?
- 앞으로 비슷한 법적 페이지들(개인정보, 연락처 등)을 어떻게 일관되게 관리할 건가?

이런 게 명시적이지 않으면, 나중에 누군가 또 다른 링크를 "임의로" 풋터에 추가할 수 있고, 그러다 보면 풋터가 정책 없이 자라난다.

배운 것들

약관 같은 법적 페이지는 매우 "정책적"인 콘텐츠다. 단순히 개발 관점에서만 보면 "파일 추가 + 링크 추가"지만, 실제로는:

• 검색 최적화: 약관도 검색 엔진에 노출되길 원하는가? 메타 설명, 구조화된 데이터 등을 고려했는가?
• 접근성: 약관 텍스트가 스크린 리더로 읽기 쉬운 구조인가?
• 다국어 지원: 향후 여러 언어를 지원한다면, 약관도 각 언어로 관리할 건가?
• 버전 관리: 약관이 바뀌었을 때 이전 버전은 어디에 보관할 건가?
• 링크 전략: 약관 링크를 풋터에만 놓을 건가, 아니면 회원가입/결제 플로우에도 넣을 건가?

이런 고민들이 사후에 "아, 저걸 미리 정했어야 하는데" 하는 기술 부채가 되지 않도록, 작업 초반에 팀과 함께 논의하면서 진행하는 게 좋다.

특히 공통 레이아웃 변경은 전체 팀의 개발 경험과 일관성에 영향을 주므로, 단순히 "링크 하나 추가"로 보지 않고 "이게 미래에 어떤 구조를 결정하는 선택인가"라고 보는 습관이 중요하다. 한 번의 작은 결정이 나중에 수십 개의 페이지에 영향을 준다는 걸 항상 기억하면서.

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

• 노트북 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

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