이용약관 페이지 정식 추가
목차
이용약관 페이지를 드디어 정식으로 배포했다. 단순한 정적 페이지 하나지만, 이 작업에는 생각보다 많은 고민이 들어갔다. 특히 법무 요구사항을 기술 구현과 깔끔하게 정렬하는 과정이 흥미로웠다.
왜 이 작업이 필요했나
사실 이용약관은 처음부터 어딘가에 있어야 했다. 서비스를 제공하는 모든 플랫폼은 법적으로 약관을 명시하고 사용자가 쉽게 접근할 수 있어야 한다. 우리 팀에서도 처음엔 임시 페이지나 외부 링크로 때웠는데, 이제 제대로 된 시점이 왔다고 판단했다. 법무팀에서 약관 내용을 정의하고 업데이트할 준비가 됐을 때, 우리는 그것을 담을 "집"을 제공해야 했다.
작업의 세 레이어
이 커밋에는 세 가지 요소가 들어갔다: template, controller, footer link.
Template (terms.html): 약관 내용을 렌더링할 HTML 구조. 법무팀이 주기적으로 업데이트할 내용을 안전하게 보관하고, 버전 히스토리를 git 으로 추적할 수 있게 한다. 단순 static HTML 대신 템플릿으로 만든 이유는, 나중에 "약관 개정 날짜", "버전 번호" 같은 메타데이터를 동적으로 노출하거나, 사용자가 "이전 버전 보기" 기능을 원할 때 대응하기 쉽게 하기 위해서다.
Controller: 요청이 들어오면 템플릿을 렌더링해서 돌려보내는 백엔드 로직. 간단해 보이지만 두 가지가 숨어 있다. 첫째, 이 페이지는 로그인 없이 누구나 접근해야 하므로 인증 체크가 필요 없다 (보안 정책상 명시적으로 exclude). 둘째, HTTP 캐싱 헤더를 적절히 설정해야 한다. 약관은 자주 바뀌지 않으니 브라우저/CDN 에서 캐시할 수 있게 했다.
Footer link: 모든 페이지의 푸터에 "이용약관" 링크를 추가했다. 왜 이게 커밋에 명시적으로 들어갔나? UX 일관성 때문이다. 법적으로 약관은 "쉽게 찾을 수 있어야" 한다. 헤더에만 넣거나, 어딘가 깊숙이 숨겨두면 나중에 법무팀이나 감시기관에서 지적받을 수 있다. 푸터는 모든 페이지에 노출되는 가장 안전한 위치다.
설계 결정: 왜 백엔드인가
초반에는 "그냥 정적 HTML 파일로 /static/terms.html 에 두고 끝내면 되지 않나?" 라고 생각했다. 하지만 몇 가지 이유로 백엔드 렌더링을 선택했다:
- 버전 관리: git history 에서 약관 변경을 추적할 수 있다. 누가 언제 뭘 바꿨는지 명확하다.
- 메타데이터: 나중에 "최종 수정일" 같은 정보를 동적으로 노출하거나, 데이터베이스와 연동할 여지가 있다.
- 권한 체크: 약관 수정 API 를 만들 때, 인증된 운영자만 변경할 수 있게 제어하기 쉽다.
- A/B 테스트: 필요하면 사용자 그룹에 따라 다른 약관을 보여줄 수 있다. (실제로는 거의 안 하지만, 구조상 가능하다)
반대로 정적 파일이었다면 매번 배포가 필요하고, 어느 버전의 약관이 live 되어 있는지 추적하기 힘들었을 거다.
일반적 고려사항
이런 "약관" 같은 지루해 보이는 페이지를 추가할 때 흔히 놓치는 부분들:
| 항목 | 고려사항 | 우리의 선택 |
|---|---|---|
| SEO | 검색 엔진이 약관을 크롤링하도록 sitemap.xml 에 등록 | 했음 |
| 성능 | 약관 페이지도 응답 시간 측정 대상 | 캐싱으로 보장 |
| 국제화 | 다국어 지원이 필요한가 | 현재는 한국어만, 나중에 i18n 라우팅 추가 가능 |
| 접근성 | 스크린 리더기 사용자도 읽을 수 있나 | semantic HTML + ARIA 라벨 확인 |
| 모바일 | 긴 텍스트가 모바일에서 읽기 좋나 | responsive margin/padding 적용 |
팀 협업 관점
이 작업을 하면서 깨달은 점은, "기술만으로는 부족하다"는 것이다. 법무팀과 미리 대화했어야 했다:
- 약관을 HTML 파일로 둘 때 포맷 (마크다운? docx? git-friendly 텍스트?)
- 변경 이력이 중요한가 (회사 입장에서 "2026년 6월 17일에 OO 조항 추가" 기록이 필요할 수 있음)
- 공시 대상 (사용자에게만? 관계사 내 공유? 감시기관 제출 대상?)
결과적으로 우리는 약관을 git-friendly 텍스트로 보관하고, 커밋 메시지로 변경 맥락을 기록하기로 결정했다. 이건 기술팀과 법무팀 모두에게 유리한 선택이었다.
마지막 회고
작은 기능이라고 생각했는데, 실제로는 여러 관심사(법적 요구사항, UX, 캐싱, 버전 관리)가 얽혀 있었다. "이 정도면 대충 해도 되지" 라고 넘어가기 쉬운 작업일수록, 오히려 팀의 기준이 드러난다. 우리는 약관 하나를 추가할 때도 왜 백엔드 렌더링인지, 푸터에 왜 링크를 달았는지를 명확히 할 수 있었다. 그게 다음 유지보수자나 새로 들어온 팀원에게도 도움이 될 것 같다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.