RSS 표준 난립, 사용자를 고려하라

표준에서 가장 불가사의한 점은 바로 표준이 너무 많다는 것이다. 웹 신디케이션 기술 또한 예외가 아니어서 매우 다양한 표준들이 현재 사용되고 있다.RSS 1.0, RSS 2.0 - RSS 1.0의 후속 버전이 아닌, 오히려 0.94 버전을 의미하는 -, 아톰 등 서로 거의 관계가 없는 인터넷 신디케이션 기술군(群)에 대해 분명하게 이해하려면 학위 논문 수준의 연구가 필요하다.만약 명세 수준에서 문제가 발생해 해결될 수 없다면 - 몇몇 갈등 요소들은 언론에 의해 해결되기도 한다 - 이런 상황이 좀 더 나아질 수 있을까? 이 글은 특정한 ‘무엇’인가를 구동시키려 하는 사용자들인 ‘우리’에 관한 이야기다.RSS 2.0에 관해 본인이 직접 겪은 문제는 바로 출판업체들이 각각 다른 방식을 사용해 RSS 기반 피드(feed)를 제공한다는 점이다. 비록 이와 같은 유연성이 RSS 2.0의 가장 큰 장점 중의 하나긴 하지만, 다양한 RSS 피드를 분류하고 표현하기 위해 표준화하는 작업은 본시 생산보다는 소비적인 측면에서 이해돼야 한다.RSS 수집 프로그램 등 일반 사용자용 애플리케이션들은 각 문서 내의 변이값들을 임의로 처리할 수 있도록 지원하는 경우가 많다. 그러니까 아웃룩과 같은 RSS 관련 애플리케이션에게는 오히려 도움이 될 수도 있다는 것이다.하지만 문제는 이것이 아니다. 기술적으로 초보 단계인 사람이 지정, 클릭 & 드래그하는 방식으로 복합 트랜잭션에 관한 서버 애플리케이션을 손쉽게 구축할 수 있는, 소프트웨어 개발에 있어 치명적인 현 상황에서 RSS 피드 공급 업체들이 개발 작업을 수행하면서 이 솔루션이 얼마나 어려운 것인지 입증하게 되지나 않을까 심히 우려된다.RSS는 무엇보다도 XML이 대중을 위해 할 수 있는 것들을 홍보하는 포스터와 같은 존재이며 대다수 사람들이 XML을 이용해 작업할 때 가장 흔하게 만나는 것이다. RSS의 추진력이 뒷받침된다면 애플리케이션이 블로그와 병행하고 있는지 여부와 상관없이 이메일 검색이나 복잡한 워크플로우를 통한 트랜잭션 데이터의 교류와 같은 작업들이 구조적/비구조적인 모든 데이터가 주입되는 수단으로 순조롭게 전환될 수 있을 것이다.이제 본인의 경험을 얘기해보겠다. 우리는 ZDNet에 블로그를 구축하는 협동작업의 일환으로 내부에 위키(Wiki)를 구축했다. 시간이 지남에 따라 내용이 늘어날진 모르지만 현재 위키 홈페이지는 공유된 북마크를 저장하는 저장소의 모습에 더 가깝다.이와 별도로 본인은 멀티유저 시스템의 위력을 보여줄만한 2차 웹페이지를 구축했다. 이 페이지는 본인이 속한 워크그룹이 반드시 따라야 할 블로그의 공유된 시각이라 할 수 있다.또한 본인은 우리가 바라봐야 할 블로그 영역의 코너에 들어갈, 포탈이 될 단일 페이지에 RSS 기반 신디케이션 내용물을 집적시키기 위해 Twiki 헤드라인을 이용했다.로버트 스코블, 조다단 슈왈츠, 팀 브레이, 밥 프랑크스턴, 슬래쉬닷, 그록로우와 다른 사람들의 내용물을 추가한 바로 직후 ZDNet.com의 부사장인 스테판 하워드가 단 브리클린, 존 우델, 단 길모어, 필 윈드리, 닥 시얼스 등 일련의 업계 전문가들에게서 취합한 내용물로 페이지의 내용을 보강했다. 이 과정은 비록 포인트 & 클릭 방식의 서버 프로그래밍을 통해 진행되진 않았지만 매우 근사한 작업이었다.그러나 패키지 외부에서 내용물을 선정하고 웹페이지에 전시하는 과정을 처리하는 플러그인의 기본 형식은 것에 관한 플러그 인의 디폴트 포맷은 그다지 매력적이지 않다. 따라서 우리의 모든 콘텐츠에 대해 기능성을 설명하는 문서만 갖춰져 있으면 최종 페이지에서 각 내용물 중 5개의 최신 헤드라인을 선정한다는 선택 변수를 가진 플러그인을 공급했다.이처럼 변수를 그래픽적으로 선택하고 결과 코드를 자동으로 산출하고 해당 코드를 웹페이지로 전달하는 것과 같은 작업은 현재 본인의 접근 방법인 하드 코딩보다 오히려 포인트 & 클릭 프로그래밍에 적합한 연습과도 같은 것이다.콘텐츠를 제공하는 여러 집단의 민감성을 고려한 Wiki 수정 작업에서 하워드 사린은 자신의 내용물을 추가할 때 형식 설정에 관해 본인의 조언을 따랐다. 또한 손쉽게 사용할 수 있는 툴이 없었기 때문에 그는 코드의 복사 & 붙여넣기만을 했으며 그 결과 꼭 필요한 대체물을 공급해줬다.프로그래머가 아닌 사람들이 한 것치고는 괜찮지 않은가? 몇 시간에 걸친 2명의 공조작업으로 페이지가 갱신될 때마다 업데이트 정보를 제공하는 유용한 포탈이 구축된 것이다. 이제 우리는 단지 또 다른 몇 명의 ZDNet 임직원이 다른 이들의 것과 겹치지 않는 콘텐츠를 해당 페이지에 떨궈주기만을 기다리고 있다.그러나 문제가 생겼다. 피드 중 일부가 올바로 표시되지 않았다. 본인은 지난 프로젝트에 사용한 시간보다 훨씬 많은 시간을 낭비해야만 했다.예를 들어 조나단 슈왈츠가 운영하는 블로그의 각 기재 사항에서 그가 제공하는 피드값들은 다른 블로그에서 찾아볼 수 없는 특정 작업을 수행했다. 슈왈츠는 XML 형식 피드에서 아이템이라고 불리는 고유한 블로그 기재사항 중 링크 필드를 생략한 것이다.ZDNet의 것과 같은 다른 피드들은 대부분 개별 아이템에 - 이 경우에는 블로그 기재사항 대신 뉴스 기사다 - 직접 연결하는 URI를 저장하기 위해 링크 필드를 활용한다. 링크 필드가 없는 슈왈츠는 블로그 기재사항 각각에 영구적인 링크를 저장하기 위해 ‘퍼마링크(permalink)’라는 선택사항을 지닌 글로벌 유니크 인식자(GUID)를 사용하고 있다.전 인터넷을 가로질러 특정 콘텐츠의 아이템에만 한정된 링크는 전세계적으로 고유한 것이기 때문에 이와 같은 행동은 분명 타당성을 지닌다. 또 다른 것을 제안할 수도 있지만 왜 수고를 더하려 하는가?이런 이유로, 거의 모든 사람들이 GUID 내에 자신의 아이템에 대한 직접적인 링크를 저장한다. 대부분의 경우에서 이것은 사람들이 이 인식자를 사용하고 있다면 GUID에서 발견되는 데이터가 링크 필드에서 발견할 수 있는 데이터와 동일하다는 것을 의미한다.이와 같은 내용이 중요한 이유는 무엇인가? 우리의 포탈 페이지를 구축하면서 쉽게 재사용할 수 있는 플러그 인 변수들의 그룹을 제안하려 할 때 아마 중요하게 작용할 것이다. 포인트 & 클릭 프로그래밍에서 이 변수들의 그룹은 ‘객체’가 될 수 있다. 그러나 본인은 직접 봐야만 믿을 수 있겠다.이 그룹들은 우리의 포탈 페이지에 담겨 있는 각 피드들에 이상적으로 적용될 수 있다. 만약 한 객체가 언젠가는 소멸하는 세계를 대상으로 한 포인트 & 클릭 프로그래밍 분야에서 일정 시간 동안만 활동한다면, 오래지 않아 기권을 선언해야 하는 상황이 도래할 것이다.Twiki 관련 문서는 링크 필드의 활용 사례와 함께, 포탈 사용자들에게 원래의 아이템으로 돌아가는 링크를 제공하기 위해 링크 필드를 활용하는 경로를 아래로 살펴보게 한 것이다. 합리적이지 않은가?아무튼 슈왈츠의 블로그에서 보이는 것처럼 링크 필드가 없다면 우리의 포털 페이지는 죽은 링크를 차단하려 할 것이다. 이와 같은 문제를 조사하면서 RSS의 취약점을 다시 한 번 상기하게 된 것이다. 물론 이와 같은 과정이 일반적인 사용자들에게 있어 웹 신디케이션의 놀라운 위력을 맛보기 위해 반드시 거쳐야만 하는 것은 아니다.슈왈츠의 블로그가 원래 존재했던 GUID 내의 특정 아이템에만 한정된 URI를 저장하고 있다면 원래의 콘텐츠로 돌아가기 위해 GUID의 콘텐츠에 의지해야 한다는 것을 알 수 있다. 본인은 재활용 가능성의 명목으로 이런 작업을 우리가 바라보고 있는 모든 피드에 적용하는 것을 검토했다. 링크와 GUID가 항상 동일하지 않는 이유를 설명하는 RSS 2.0 세부사양의 본문은 본인의 이같은 성향을 확인해줬다.“GUID에 관해 흔히 묻는 질문 중 하나는 이와 링크의 비교다. 이들은 동일한 것이 아닌가? 일부 콘텐츠 시스템에서는 맞는 말이지만, 다른 시스템에선 그렇지 않다. 링크는 웹로그 아이템에 있어 퍼마링크다. 그러나 다른 시스템에서 각 아이템들은 보다 긴 내용에 대한 개요이며, 링크는 해당 내용을 가리키고, GUID는 웹로그 기재사항에 대한 퍼마링크다. 모든 경우에서 GUID를 제공하는 것을 추천하며 가능하면 이를 퍼마링크로 만들어라. 이는 RSS 수집 프로그램들이 심지어 편집상의 변화가 발생하더라도 아이템을 반복하지 않도록 해주는 역할을 한다.”이런 최상급 실무 추천사항은 의심할 여지없이 반드시 진행해야만 하는 것이다. 그러나 이와 함께 일단의 피드들이 다른 양식을 따른다는 사실도 암시하고 있다. 그리고 이것이 바로 정확하게 본인이 직면한 문제다.이미 재활용 가능성은 나와 있지만 본인은 심지어 포인트&클릭 프로그래밍의 세션을 시작하기 위해 마우스를 들려 하지도 않았다. 포탈에 추가한 각 내용물에 대해 어떤 변수 조합을 적용할 것인지를 결정하기 전에 본인은 먼저 해당 XML을 학습하고 있는 상황이다.그러나 GUID vs. 링크의 문제는 우리만의 도전과제가 아니다. 데이브 위너의 뉴스 스크랩과 같은 일부 피드들은 우리의 포탈에 또다른 숙제를 안겼다. 20개 이상의 내용물을 지니고 있으며 검색이 쉬운 포탈을 구축함에 있어서 가장 쉬운 방법은 단지 아이템 타이틀을 보여준 다음 타이틀을 완전한 본문에 링크시키는 것이라고 결정했기 때문에 문제가 된 것이다. 그러니까 아이템 링크나 또는 위에서 기술한 것처럼 GUID를 활용하는 것으로 무엇이든지 보다 적절한 것을 활용하도록 했기 때문이다.위너의 XML에서 우리가 획득한 관련 사항은 매우 단촐했다. 선택할 타이틀이 없는 상태에서 GUID, 아이템의 출판일(pubDate), 그리고 세부 내용인 아이템의 완전한 본문 그 자체 등 3가지의 각기 다른 선택만이 있을 뿐이다.하지만 몇 단어에서 몇 개 문단에 이르기까지 아이템의 완전한 본문이 어디서나 게재되고 있는 상황에서 하이퍼링크를 사용하는 것은 매우 합리적이지 못하다.슈왈츠의 블로그에서처럼 위너의 GUID는 완전한 본문에 대한 URI이다. 이것은 우리가 링크할 수 있는 텍스트로 활용할 수 있도록 남겨진 유일한 것은 출판일밖에 없다는 사실을 의미한다.모질라 재단의 스탭들도 이처럼 타이틀이 없는 아이템에 대해 분명히 똑같은 기분을 느꼈을 것이다. 파이어폭스는 RSS 피드를 추적하기 위해 ‘라이브 북마크(Live Bookmarks)’ 기능을 사용하는데 타이틀이 없는 피드에 대해 클릭할 수 있는 링크 메뉴를 산출할 때 출판일을 사용하고 있다.사실상 파이어폭스는 단 하나의 블로그 내에 타이틀을 특정 기재사항에만 적용시킨 존 롭과 같은 채널도 솜씨있게 처리하는 등 RSS의 획일적이지 않은 사용에 매우 뛰어난 솔루션이다.롭의 피드를 파이어폭스에 라이브 북마크로 추가할 때 나오는 메뉴들은 각 아이템에 대해 파이어폭스가 찾아낼 수 있는 것은 무엇이든지 보여준다. 일부에 대해선 출판일이며 다른 경우엔 타이틀이다. 이는 웹 신디케이션에서 소비 측면이 어떻게 공급 측면에서 만들어진 선택의 짐을 떠안는가에 관한 입증자료다.다른 말로 하면, 제어가 공급자에서 멀리 벗어나 콘텐츠 출판자에게로 이전해 온다는 것이다. 이러한 현상이 웹이 취한 방향성을 일부 역전시킨다는 사실에 주목하라. 인터넷 익스플로러의 인기와, 얼마나 많은 사이트들이 파이어폭스를 고려하지 않고 작업하는지 감안해 본다면 이러한 지혜는 공급 측면이 어떻게 소비 측면으로 맞춰 들어갔는지 설명해 줄 것이다.마찬가지로 소프트웨어가 사용자 측면에서 만들고 있는 매우 복합적인 일부 결정과 알고리즘을 어떻게 피해가는가에 대한 증거를 들어보자. 데이브 위너의 웹 기반 피드 수집 프로그램은 각기 다른 채널의 기재사항들을 수집 프로그램이 채널에 등재할 때의 순서에 따라 시간 반대순으로 혼합하는 하나의 인터페이스로 다양한 피드 양식들을 표준화하는 작업에서 놀라운 성능을 발휘한다.다른 말로 해서, 5개 엔트리는 한 채널에서 12:15로 보일 수 있다. 하지만 이들 중 가장 오래된 자료가 또 다른 채널에 등재된 엔트리보다 최신의 것이 아닐 수도 있다. 어떤 것도 최종 사용자의 시간대에 따라 출판일을 표현하진 않는다.웹 기반 RSS 피드 프로그램에 있어 본인은 최종 사용자의 시간대를 지정하는 게 가능할지 확신이 안 선다. 하지만 이것은 파이어폭스나 뉴스게이터와 같이 로컬 차원에서 운영되는 RSS 프로그램을 위한 것이다. 과연 인기를 끌 수 있을까?애초에 본인은 위너가 타이틀을 포함시키지 않은 것을 저주했다. 그러나 위너의 웹로그를 따라해 보기 시작한다면, 그의 선택으로 인한 경제적인 측면을 깨닫게 된다.그의 블로그는 단지 의식의 흐름이다. 만약 당신이 무언가 또는 어떤 것에 대해 생각하게 된다면 여기에 타이틀을 먼저 주겠는가? 그렇게 하지 않은 것은 위너도 마찬가지였으며, 또한 그는 그렇게 할 필요도 없을 것이다.그의 것을 포함한 기타 블로그를 위대하게 만들고 그들을 타이틀(헤드라인)을 지닌 뉴스 내용물과 차별화시키는 요소는 그들의 블로그는 다이어리와 같다는 점이다. 이들은 만약 저자가 모든 것에 타이틀을 달기 위해 멈춰야만 한다면 저자의 마음을 바로 바로 반영하지 못할 지도 모를 것 같은, 흔히 작성되는 엔트리들로 가득 차 있다.물론 예외도 있다. MS의 로버트 스코블은 웹의 인기 블로거 중 하나지만, 아무리 엔트리가 짧다고 할지라도 모든 엔트리에 타이틀을 다는 일을 용케 해내고 있다. 예를 들어 MS CEO인 스티브 발머가 애플 아이팟에 관해 말한 최근 엔트리에서 타이틀은 거의 본문 전체의 내용만큼이나 길게 작성됐다. 아마도 그가 보다 적은 수의 엔트리에 타이틀을 달거나 아예 안 단다면, 우리는 스코블의 뇌에서 보다 많은 것을 얻을 수 있을 것이다.다른 이들이 단지 복사와 붙여넣기만 해도 되는 수준의 재사용 가능한 변수 세트를 구축한다는 명목 아래, 위너의 내용물을 바라보면 바라볼수록 나는 다음의 2가지 선택 사항 사이에서 고민하게 됐다. 출판일을 우리의 TWiki 기반 포탈에서 링크할 수 있는 텍스트로 활용할 것인가, 아니면 단지 각 아이템의 설명에 저장된 완전한 본문을 그의 엔트리에서 다운로드해 전시할 것인가다.무엇보다도 우리의 페이지가 단지 최신 5개 엔트리까지만 수록하고 위너가 보통 하루에 5개 이상의 엔트리를 출판하는 것을 감안한다면 출판일 리스트를 보유하는 것은 각 엔트리가 출판된 정확한 시간 말고 우리가 모르는 다른 어떤 것을 알려 주지 않는다.우리가 정말 필요로 하는 것은 완전한 본문 그 자체에 있는 것들에 대한 일부 암시다. 위너의 것처럼 타이틀이 없는 피드의 경우에선 완전한 본문을 선택하는 것이 유일한 선택이 된다. 플러그 인의 수용능력을 감안한다면 말이다. 실제로 GUID, 설명, 출판일, 그리고 피드가 제공해야 할지도 모르는 다른 어떤 모든 것들을 한번에 다 가질 수 있게 하는 것이 우리의 포탈에 대한 가장 최선의 접근법처럼 인식되기 시작했다. 이 시점에서 문제는 정리됐다. 마침내 본인은 일상의 업무로 돌아올 수 있었다. 아마 아닐지도 모르지만 말이다. 위너가 내게 지적한 것처럼 이러한 접근법은 다른 많은 블로거와 달리 뉴스 출판자들의 경우 흔히 콘텐츠의 완전한 본문 대신에 설명 필드에 요약 내용을 제공하는 경우가 많으므로 실효성이 없을지도 모른다. 설상가상으로 설명 부분을 잡은 다음에 본인은 Twiki의 헤드라인 플러그 인이 일정하게 쓰여진 HTML을 처리할 수 없다는 사실을 발견했다. 이 프로젝트는 오래된 만화에 자주 등장하는 새기 쉬운 댐과 같다. 당신이 모든 구멍을 막았다고 생각한 순간, 또 다른 구멍이 열리게 마련이다. RSS 피드 공급자들이 계속 약속해 온 것처럼 본인도 해결책이 단지 한 순간 마우스 한번만 클릭하면 되는 곳에 있길 바라고 있다는 것을 발견했다. 하지만 어떤 진행 과정상에도 본인은 수년 이상 걸리지 않을까 하고 의아심을 품고 있다.여기에는 RSS를 채택하는 것이 과연 올바른 것인지에 관한 근원적인 토론 거리도 여전히 남아있다. 왜 이러한 유연함의 브랜드가 인터넷을 정의하는 자연적인 카오스 상태에 질서를 가져다 놓으려고 시도하는 모든 사람들, 예를 들어 공급자들과 같은 사람들의 삶을 힘들게 만드는 것일까. @