블로그나 뉴스 사이트를 운영하는 개발자라면 콘텐츠 자체 못지않게 '어떻게 배포하느냐'도 신경 써야 한다. 피드(feed)는 그 핵심 수단이지만, 의외로 잘못 설정된 경우가 많다. 2022년 공개된 한 기술 가이드는 피드 발행의 모범 사례를 중요도 순으로 정리하면서, 각 항목이 왜 중요한지 근거까지 함께 제시한다. 콘텐츠의 질을 다루는 글이 아니라, 그 콘텐츠를 가장 넓은 범위의 리더(reader)와 검색엔진에 전달하는 방법에 관한 실무 지침이다.
RSS가 아니라 표준 포맷의 문제
흔히 '피드'를 'RSS 피드'라고 부르지만, 실제로 RSS만을 가리키는 경우는 드물다. RSS는 유일한 포맷도, 최선의 포맷도 아니다. 중요한 것은 표준화된 포맷을 쓰는 일이다. 가이드는 RSS 2 또는 Atom을 권한다. 둘 다 널리 지원되기 때문이다. 초기 RSS 표준이나 JSON Feed, Microformats h-feed 같은 포맷은 지원 범위가 좁아 피하는 편이 낫다.
아직 피드가 없다면 Atom을 강력히 추천한다는 점이 눈에 띈다. 명세의 모호함이 훨씬 적어 다양한 클라이언트와의 호환성 문제가 적게 발생하고, 전체적으로 더 단순하고 명확하기 때문이다. 다만 이미 RSS 2 피드를 운영 중이라면 굳이 바꿀 이유는 없다. 포맷을 여러 개로 동시에 제공할 필요도 거의 없다. Atom 피드가 있다면 RSS 피드를 따로 둘 필요가 없다는 것이다. 포맷 전환 자체는 안전하며, 같은 URL에서 내용을 바꾸거나 새 URL로 리다이렉트하는 방식 모두 가능하다. 단, Content-Type 헤더를 정확히 갱신하는 것을 잊어서는 안 된다.
절대 URL과 피드 디스커버리
실무에서 자주 빠뜨리는 부분이 URL 처리다. 피드 안의 모든 URL은 절대 경로(https://로 시작)여야 한다. Atom이 상대 URL 해석 방법을 명확히 규정하고는 있지만, 실제로 올바르게 구현된 리더는 드물기 때문이다. 이는 link 요소뿐 아니라 게시물 요약과 본문 안의 HTML에 포함된 모든 링크에 적용된다.
또한 사이트의 모든 페이지에 피드를 알리는 메타데이터를 넣어야 한다. HTML의 link 태그 하나로 리더와 검색엔진이 피드를 발견하고 구독할 수 있다. 피드가 여러 개라면 각각 적절한 제목을 달아 모두 알리되, '가장 중요한' 피드를 맨 위에 두는 것이 좋다. 많은 클라이언트가 순서를 그대로 보존해 사용자에게 보여주기 때문이다. 보통은 사이트 전체 피드, 카테고리 피드, 특정 페이지의 댓글 피드 순서가 된다. 설정이 제대로 됐는지는 W3C Feed Validation Service에 사이트 URL을 넣어 홈페이지, 목록 페이지, 개별 글 페이지에서 각각 확인할 수 있다. HTML 수정이 어렵다면 HTTP 응답의 Link 헤더를 쓸 수도 있지만 지원 범위가 좁으므로 link 태그가 우선이다.
전문 제공, 인증, 그리고 서버 부하
피드에는 글 전문을 담는 것이 일반적으로 권장된다. 대부분의 독자가 이를 선호하기 때문이다. Atom은 전문을 담는 content 외에 짧은 요약용 summary 요소도 따로 제공한다. 전문 공개가 수익화에 부담이 되는 매체도 있지만, 가이드는 피드에서 전문을 볼 수 없으면 독자가 아예 떠날 수 있고, 광고를 보지 않더라도 친구나 뉴스 애그리게이터에 공유해줄 가능성을 고려하라고 조언한다. 유료 콘텐츠라면 /feed.atom?user=토큰처럼 사용자별 인증 토큰으로 비공개 링크를 생성하게 하는 방법이 있다. 다만 basic auth 방식은 지원하는 리더가 더 적다.
피드는 끊임없는 폴링으로 소비되므로 서버 부하 관리가 중요하다. 캐시 헤더로 적절한 값을 제시하지 않으면 각 클라이언트가 제멋대로 주기를 정한다. 월 단위로 갱신하는 블로그라면 한 시간 캐시가, 하루에 여러 번 올리는 곳이라면 5분 캐시가 합리적이다. ETag나 Last-Modified 헤더를 반환하고 변경이 없을 때 304 응답을 주는 조건부 요청(conditional request)을 지원하면 양쪽 모두 폴링 효율이 올라간다. 실시간 갱신이 필요하면 WebSub 표준으로 업데이트를 밀어내 부하를 줄일 수 있지만, 허브가 피드 내용을 수정·주입할 수 있으므로 신뢰할 수 있는 곳을 골라야 한다.
흔히 놓치는 세부와 한계
의외로 큰 사고로 이어지는 실수들도 있다. 봇 차단 기술을 쓴다면 피드에 대해서는 반드시 꺼야 한다. 피드는 애초에 봇이 소비하도록 만든 것이기 때문이다. 엔트리 ID는 항목을 식별하는 핵심 수단이라 ID가 바뀌거나 중복되면 독자가 중복 글을 받거나 글을 놓친다. 발행 시각과 최종 수정 시각을 구분해 올바르게 처리하는 것, 피드의 self-link를 정확히 유지하는 것, 브라우저 기반 리더를 위해 CORS를 열어두는 것도 챙겨야 한다. 카테고리를 제공하면 독자가 특정 분류만 구독하거나 제외할 수 있어 구독 이탈을 막는 데 도움이 된다.
피드 URL은 가급적 바꾸지 말아야 하며, 불가피하다면 리다이렉트를 최대한 오래 유지해야 한다. 일부 구독자는 끝내 이전하지 않기 때문이다. 결국 처음부터 자신이 통제할 수 있는 좋은 URL을 고르는 '예방'이 사후 대응보다 낫다는 조언이 핵심이다. 다만 이 가이드가 다루는 요약 제공, RFC 5005 기반 페이지네이션 같은 항목은 상대적으로 덜 중요하며, 개인 블로그보다는 제품이나 피드 생성기를 만들 때 가치가 있다. 또 피드에 CSS와 HTML을 쓸 수 있지만 많은 리더가 최신 브라우저 엔진을 쓰지 않거나 요소를 걸러내므로, 여러 리더에서 직접 테스트해보는 수밖에 없다는 현실적 한계도 함께 언급된다. 결국 피드 운영은 화려한 기능보다 표준 준수와 호환성이라는 기본기에 달려 있는 셈이다.