이글로써 RSS에 대한 논쟁은 그만~ 이라고 말하고 싶긴 하지만, 그럴 깜냥은 아니고.
블로그 개발자들에게 도움이 되었으면 하는 마음에 적는다.

모두에게 happy한 RSS만들기, 그것은 기본에 충실하면 아주 간단한 일이다.
샘플 코드는 여기에.

주욱 따라오자. 중요한 곳은 행번호를 굵게 써둔다.

1행은 따로 설명할 필요 없고… 아, UTF-8로 만들어야 함을 잊지 말자.

2행 : rss버전과 그외 xml에서 사용되는 namespace에 대해 미리 선언을 해둔다. 이 예에서는 content라는 확장 namespace를 사용함을 알리고 있다.

4행 : title은 필수 요소이며, 채널 제목을 가리킨다. 채널의 title은 기왕이면 웹사이트의 이름과 동일하면 좋으나, 하나의 사이트가 여러개의 RSS채널을 가질 수 있으므로(예:코멘트RSS, 검색결과 RSS) 다른 채널과 구분짓도록 이름을 쓰자. encoding되지 않은 plain text를 사용해야한다. (이하 특별한 언급이 없다면 text가 들어가는 모든 부분에 동일).

5행 : link는 이 RSS 채널이 언급하는 사이트의 주소를 가리킨다. 역시 필수.

6행 : description은 이 RSS채널에 대한 설명을 간단히 적어넣는다. 역시 필수.

7행 : language는 ko-kr (한국이니까. 이 역시 사이트의 기본 language와 동일하게 맞춰준다.). 여기서부터는 써도 좋고, 안써도 좋은 선택사항.

8행 : copyright는 가입형 블로그라면 골치아플 수도 있다. 저작권이 어디에 있는가를 명백히 표시해주는 것이 좋다. 물론 블로그의 정책에 따라서.

9행 : pubdate는 발행시간. RFC822기준이다. 가끔 이 pubdate형식을 틀리는 경우들이 있으니 주의. 특히 외국산 설치형블로그들을 한글화하면서 날짜형식을 바꿨을 때에는 간혹 이 RSS에도 반영이 되어 문제가 생길 수 있다. GMT대신 +0900 처럼 적어도 된다.

10행 : lastbuilddate와 pubdate를 헷갈릴 수 있는데, 이는 최종적으로 수정된 시간을 가리킨다. 이것과 pubdate를 이용해서 RSS 리더들이 문서 갱신여부를 확인한다. 따라서 “나중에 글을 수정했는데 반영이 안되는 문제…”를 고민하는 거라면 자신의 RSS 파일이 이 정보들을 제대로 가지고 있는지 확인해보라. 그리고는 RSS리더기 제작자에게 이 정보들을 이용해 수정사항이 반영되도록 압력을 가하라. 즉, “나중에 글을 수정했는데 반영이 안되는 문제”를 해결하고 싶다면, 첫째, 자신의 블로그 제작자에게 pubdate와 lastbuilddate 정보를 정확히 제공하도록 요구하고, 둘째로 RSS리더기 제작자들에게 pubdate와 lastbuilddate를 반영하도록 요구해야 한다는 뜻이다. (이걸 가지고 엄하게 사용자끼리 전체공개를 해야 하네 말아야 하네 하는 것은 해프닝일 뿐이다.)

11행 : docs는 RSS파일 포맷형식이 기술된 곳을 가리킨다. HTML의 DTD라고 생각해도 좋다. 몇십년이 지나서 누군가 이 RSS파일을 열어보더라도 참조할 수 있는 사전을 알려준다는 뜻이다. RSS 2.0이라면 http://blogs.law.harvard.edu/tech/rss 를 적어주면 되긴 하는데, 한가지 문제가 있다. content:encoded같은 확장 RSS 2.0을 쓴다면 그 내용이 기술되어 있는 곳을 적어주라는 점.
그러나 이 항목은 대개 생략해도 큰 문제는 없는데, 대부분의 RSS리더들은 이 항목을 실제로 사용하고 있지는 않기 때문이다. Feed Validator들이나 사용할까… 따라서 크게 신경쓸 필요는 없다. 게다가 3행에서 이미 xml namespace에 대해 기술했기 때문에 없어도 되는 항목.

12행 : generator는 이 RSS를 만든 프로그램을 가리킨다.

13행 : managingeditor는 컨텐트 편집자의 이메일 주소를 가리킨다. 만약 사람 이름을 병기하고 싶다면, “xxx@blog.ooo.com (개똥이)” 처럼 ()안에 병기하면 된다. 단 이름만 적으면 안된다. 여기에도 한가지 문제가 있는데, RSS에 적혀있는 이메일 주소는 스패머들에게 좋은 먹이감이 되기 쉽상이라는 점이다. 그러나 그럼에도 불구하고, 아예 이 항목을 안쓴다면 모를까, 쓴다면 메일주소는 적어주도록 하자. 필요하다면 nospam형식으로 변형시키는 것도 가능하겠다.

14행 : webmaster는 이 사이트 전체의 웹마스터이다. 역시 이메일 주소를 적는다.

15행 : category별 RSS제공을 안하는 경우들이 많은데, 해주면 감사할 이들이 참 많을 것이다. 만약 category archive같은 것이 있다면 domain 속성을 이용해 해당 URL을 기술해주면 더 좋다.

16행 : cloud는 거의 쓰이지 않을 항목일 것이다. 원래는 RSSCloud라는 웹서비스를 지원하기 위한 항목이다. 물론 예시에 든 것처럼, rpc.allblog.net 같은 건 실제로 없다. 만약 올블로그가 rpc서비스를 만든다면 이런 식으로 쓰면 된다.. 는 뜻이다. RSSCloud에 대해 좀 더 자세히 알고 싶다면 여기 참조.

17행 : ttl은 time to live의 약자이다. 이 RSS 파일이 생성된 후 몇 분간 “유효”한가를 알려주는데 사용된다. 어떤 RSS파일은 발행된지 너무 오래되어 그 내용이 사이트와 맞지 않을 수도 있다. 이럴 때를 대비해서 사용한다.

18~23행 : textInput은 구독자와의 interactive action을 위해 준비된 항목이다. 용도는 위에 적은 예외에도, 품질평가라든가, 구독확인이라든가… 뭐 이래저래 다양한 곳에 쓰일 수 있다… 고는 하는데, 실제로 지원하는 RSS리더기가 거의 없어서 유명무실하긴 하다. RSS 리더기를 만들 개발자라면 한번 구현해보시길.

24행 : rating은 PICS rating을 지정하는데 쓰인다. PICS rating은 해당 아이템에 대한 PICS등급을 매기는데, 원래는 아이들에게 접근가능한 컨텐트인지 확인하는데 쓰였으나 현재는 그밖에도 여러 용도로 쓰인다.
허나 국내에서는 PICS를 활용하는 서비스도 없고 해서 굳이 적어둘 필요는 없는 항목이다. 만약 해외에 교육용으로 쓰일 사이트라면 알아두는 것도 좋겠다.

25~29행 : image는 이 RSS 채널을 상징하는 이미지 배너를 정의하는데 쓰인다. 필수는 아니나 지정해두면 몇몇 RSS 리더기에서는 괜찮은 외관을 보이는데 쓰인다. GIF, JPG, PNG 모두 가능하며, 사이즈는 최대 144X400 이지만 88X31이 기본값이다.

30~37행 : skiphours와 skipdays는 RSS 리더기의 수집을 금하는 시간을 지정한다. 위의 예에서는 매일 0시부터 3시까지의 수집을 금하며, 덧붙여 일요일에는 수집을 금한다는 뜻이다. 수집을 금하는 이유는 여러가지가 있는데, 이른바 사이트 정기점검 등의 문제가 있기 때문이다. RSS를 수집하러 갔는데 해당 파일에 접근할 수 없다면 수집기는 이 사이트가 더이상 존재하지 않아서라고 판단할 수도 있다. 이런 것을 방지하기 위해 수집기의 활동을 금지하는 시간을 RSS채널에 적어둔다. 물론 이 항목들은 이외에도 트래픽관리등을 위해서도 쓰인다.
사실, 이 skiphours, skipdays 그리고 ttl 항목을 통해 수집기들이 내 RSS를 긁어가는 시간을 조절할 수 있어야 하는데, 국내의 많은 리더기들은 이 항목들을 반영하지 않는다. 무조건 10분에 한번씩 RSS를 읽어가는 모 메타블로그같은 경우, 이미지도 매번 긁어가기에 트래픽량이 장난이 아니다. ttl에서 60분간 유효하다 했으면 60분마다 긁어갈 것이지… 요즘은 수정되었는지 모르겠다.

39행부터는 개별 항목(item)에 관한 내용이다.

40행 : title은 필수요소이며 해당 아이템에 대한 제목이다. 블로그 글목록 RSS라면 엔트리제목일테고, 신상품RSS라면 상품제목일테고…

41행 : link는 해당 item의 “원본”을 가리키는 URL이다. 주지하다시피, RSS란 원본에 대한 또다른 카피가 아닌, “원본에 대한 설명”임을 명심하자.

42행 : description은 해당 item에 대한 설명이다. 만약 description이 item 그 자체라면 title과 link는 생략가능하다. 최소한 title과 description 둘 중에 하나는 반드시 있어야 한다.
description은 인코딩되지 않은 plain text이며 다음과 같이 CDATA나 entity encoding을 사용할 수 있다.
[xml]
this is <b>bold</b>
[/xml]
[xml]
< ![CDATA[this is bold]]>
[/xml]
description은 말 그대로 해당 item에 대한 설명이다. 조금 철학적인 문제로 들어가서, 그럼 과연 “해당 item에 대한 설명”이란 무엇인가? 가장 좋은 것은 요약(excerpt)이다. 신문의 헤드라인을 생각해도 좋다. 문제는 국내의 대부분의 블로그툴에 excerpt를 입력받는 방법이 없다는 것이다. 왜 안넣는지는 모르겠다. 분명 사용자들이 excerpt를 제대로 입력할 것이라는 기대는 어렵다. 100명중에 1명이나 제대로 입력할까.
사실, 요즘 유행하는 more 기능이라는 것도 원래는 excerpt - entry body 개념에서 나온 것이다. index archive에서는 excerpt만 보여주고 해당 페이지에 들어가야 entry body를 보여주는 방식이었는데(물론 선택가능하다.), 이것이 우리나라에서는 어찌어찌 와전되어 그저 본문을 접었다 폈다 하는 기능으로 바뀌었다. 귤이 회수를 건넜더니 탱자가 되더라. 아니 한라봉이 된걸까?
어쨌거나 바라노니, 국내의 블로그 제작자들은 블로그에 글 쓸 때 excerpt를 입력받는 기능을 추가해주었으면 좋겠다. excerpt는 여러가지로 쓰일 수 있는데, RSS뿐만 아니라 index페이지나 archive페이지에서 글의 개요를 보여줄 때도 쓸 수 있고, 또 more 기능을 구현할 때에도 쓰일 수 있다.
만약 사용자가 excerpt를 입력하지 않는다면??? 그럴 경우 de facto표준인 MovableType에서는 사용자가 입력한 글 중 일부를 따와서 excerpt 대신 사용한다. 물론 MT의 경우에는 몇자나 딸지 지정가능하고, 그 지정에 따라서 본문 전체를 description에 담을 수도 있다. 나름 합리적아닌가?
description안에 html 태그를 넣는 것은 지양해야 하는데, 그 이유는 모든 리더기가 description의 html을 해석하지는 못하기 때문이다. 즉, 이 안에 html 태그를 적는다 해서 그대로 보여준다는 보장은 없다. 그 외에도 여러가지 문제가 있긴 하다.