개발 slecs

블로그에 정적 페이지·사이트맵·푸터를 추가해 서비스 완성도를 높인 과정

목차

블로그 서비스의 뼈대는 어느 정도 잡혀 있었는데, 정작 About / Contact / Privacy 같은 "정보성 정적 페이지"가 없었다. 크롤러가 들어왔을 때 sitemap도 없고, footer도 없으면 서비스 완성도가 떨어진다는 판단이 있었고, 이 타이밍에 한 번에 묶어서 처리했다.


왜 정적 페이지를 이 시점에 넣었나

기능 개발을 먼저 치고 나서 이런 정보성 페이지는 "나중에"로 미루는 경우가 많다. 근데 실제로 배포 이후에 검색 엔진 인덱싱, 법적 고지(Privacy), 연락처 안내가 없으면 서비스가 미완성처럼 보인다. 특히 Privacy Policy는 구글 애드센스나 각종 서드파티 연동 전에 반드시 있어야 하는 요건이기도 해서, 기능 완성도와 별개로 배포 가능 상태를 만들기 위한 최소 조건 중 하나다.

About 페이지도 마찬가지다. 사람이 블로그를 읽다가 "이 사람 누구지?" 하는 순간 About 링크를 찾는데, 그게 없으면 신뢰도가 확 떨어진다. 기술적으로 별거 아닌 작업이지만 서비스 완결성 면에서는 꽤 중요한 부분이라고 생각한다.


변경 파일별 역할 정리

파일 역할
app/main.py /about, /contact, /privacy 라우트 등록, sitemap 엔드포인트 추가
app/templates/base.html 전체 레이아웃의 footer 삽입 — 모든 페이지에 일괄 반영
app/templates/about.html About 정적 콘텐츠 템플릿
app/templates/contact.html Contact 정적 콘텐츠 템플릿
app/templates/privacy.html Privacy Policy 정적 콘텐츠 템플릿

base.html에 footer를 넣은 게 핵심이다. 개별 페이지마다 footer를 넣으면 나중에 수정할 때마다 모든 템플릿을 손봐야 하는 구조가 되는데, 베이스 템플릿에 한 번 박아놓으면 이후에 링크 추가/수정이 한 곳에서 끝난다. 이런 DRY 원칙은 템플릿 구조에서도 동일하게 적용된다.


라우트와 sitemap 처리 패턴

main.py에 라우트를 추가하는 건 단순하지만, sitemap은 조금 신경을 써야 한다. 정적 페이지 URL과 블로그 포스트 URL을 모두 포함해야 하기 때문에 DB에서 포스트 목록을 조회해서 동적으로 생성하는 구조가 필요하다.

@app.get("/sitemap.xml", response_class=Response)
async def sitemap():
    urls = [
        "https://example.com/",
        "https://example.com/about",
        "https://example.com/contact",
        "https://example.com/privacy",
    ]
    # 동적 포스트 URL도 여기에 append
    # posts = await get_all_published_posts()
    # for post in posts:
    #     urls.append(f"https://example.com/posts/{post.slug}")

    xml_content = generate_sitemap_xml(urls)
    return Response(content=xml_content, media_type="application/xml")

sitemap에서 자주 빠뜨리는 게 <lastmod>, <changefreq>, <priority> 같은 메타 필드들이다. 정적 페이지는 changefreq를 monthly, 포스트는 weekly 정도로 설정해두면 크롤러한테 적절한 힌트를 줄 수 있다. 지금 당장은 기본 구조 먼저 잡고, 이 부분은 추후 개선 여지로 남겨뒀다.


footer는 단순히 링크 모음이 아니라 서비스 신뢰도의 마지막 레이어다. 보통 About / Contact / Privacy 링크가 footer에 들어가고, 여기에 SNS 링크나 RSS 피드 링크도 같이 넣는 경우가 많다.

base.html 수정이 모든 페이지에 영향을 주는 만큼, 이 파일을 건드릴 때는 항상 전체 페이지를 훑어보는 습관이 필요하다. 특히 레이아웃 관련 CSS 클래스나 Jinja2 블록 구조가 깨지면 한 페이지만 이상한 게 아니라 전체가 터지기 때문에 변경 후 로컬에서 각 페이지를 한 번씩 확인하는 게 기본 루틴이다.

이번 작업처럼 "기능적으로는 단순하지만 서비스 완결성에 필요한 작업"들이 사실 팀 내에서 우선순위가 밀리기 쉽다. 근데 배포 품질을 올리는 데 있어서 이런 작업들이 생각보다 큰 역할을 한다는 걸 다시 한번 확인했다.

끝.


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

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

댓글 0

첫 댓글 달아줘.