본문 바로가기

Tech Story

블로거뉴스 기능/역할, 그래서 미래는?

 최근에는 책읽기의 진도가 나가지 않아서 블로거뉴스 이야기와 반사회적 포스팅만 올리고 있는 것같다. 그래서 오늘도 블로거뉴스를 타겟으로 잡겠습니다. 블로거뉴스 서비스에 아주 조금 관련이 있는 사람으로써 옹호에 가까운 글을 적어왔고, 또 그런 글을 적더라도 이해해주기 바랍니다. 어차피 문제점들을 지적한 글들은 수 없이 많으니, 조금의 균형을 맞춘다는 생각으로 읽어주세요. 그리고, 간혹 컨피덴셜이 노출되었다고 생각되는 부분도 있을 수도 있으나, 전적으로 저 개인의 직감에 의한 추론임을 밝힙니다. 즉, '아니면 말고' 식의 글임을 상기해주시기 바랍니다.

 대한민국의 블로그스피어에서의 블로거뉴스 (일반적으로 '메타블로그'들)의 역할을 다양한 블로그의 글들을 수집하는 집산기능 crawling & collecting과 수집된 글들을 널리 퍼트리는 배포기능 distributing으로 요약하는 경우를 많이 보게 된다. 소위 파워블로거들, 그리고 어쩔 수 없이 블로거뉴스를 애용하시는 분들 - 다른 메타블로그들이 더 활성화되었다면 블로거뉴스를 바로 떠나실 분들도 계시다는 걸..., 중에서도 집산과 배포의 범위 내에서 블로거뉴스의 역할/기능을 정의하시는 분들이 종종 있는 것같다. (그래서, 블로거뉴스 = 웜홀 (= 블랙홀 + 화이트홀)이라고 명명한 적이 있다.) 좀더 파워블로거들 또는 더 강력한 블로거뉴스 비판자들은 집산과 배포에 더해서 수없이 쏟아지는 글들 중에서 악성글들을 제거/여과 (필터링)하고 좋은 글들만을 추려내는 정제기능 collective filtering (collaborative filtering은 아닌 듯, 이유는 아래에)에 대해서 얘기하시는 분들도 계시는 것같다. 현재로썬, 오픈에디터 및 추천제도가 이 정제기능을 담당하고 있다. 물론, 보이지 않는 곳에서는 자동으로던 수동으로던 블로거뉴스 비적합 글들을 추려내는 작업도 진행 중이지만, 크게 이슈가 되는 것같진 않아 보인다. (물론, 가끔 스크랩 의심 글이 베스트로 올라가거나 외부 신고에 의한 블라인드 처리되는 등에 민감한 반응을 보이시는 분들도 계시지만...) 집산과 배포에서 블로거뉴스 1.0의 시대였다면, 정제기능에서 블로거뉴스 2.0의 시대가 아니었나 생각해 봅니다. 그렇다면 블로거뉴스 3.0의 시대는 어떤 모습일까? 구체적으로 어떤 기능이 추가되면 블로거뉴스 3.0이라 명명할 것인가?에 대한 관심이 높을 수 밖에 없다. 

 현재의 추세대로 간다면 (사회적 추세, 기술적 추세, 그리고 블로거뉴스 개편의 추세) 블로거뉴스 3.0의 핵심 기능은 분명 '관계/연결기능'일 것입니다. 단순히 소셜네트워킹 social networking 또는 소셜미디어 social media의 틀 내에서의 개편이 이루어질 거라는 것은 너무나 쉬운 추론일까요? 말 많은 댓글 기능이나 '누가 추천했을까?'는 사람 대 사람 (블로거 대 블로거, 또는 블로거 대 독자)의 연결을 도모하기 위한 초석으로 보인다. 그리고 이전 포스팅에서 '자세히보기'에서 프리뷰가 너무 짧다는 의견을 피력한 바가 있다. 프리뷰가 짧은 것은 사실이지만, 당시 놓쳐버린 점도 있었다. 지금의 '자세히보기'는 소위 베타버전이라는 점이다. 자세히보기 창에 들어가야할 부가 내용 및 정보가 너무 많다는 점에서, 어쩌면 프리뷰의 길이를 민망할 정도로 짧게 둘 수 밖에 없었을지도 모른다. (자세히보기에 들어가면, '가장 많이 본 글'이 해당 카테고리의 베스트로 바뀐다는 걸 최근에서야 감지했다.) 대표적으로 들어가야할 정보로는 이미 언급했듯이 인적 네트워크와 관련된 정보다. 즉, 공감블로거들, 공감블로거들의 글들, 그리고 공감블로거들이 추천한 글들의 목록정보가 들어갈 것같다. 공감블로거의 선정방법은 글을 발행한 블로거가 임의로 선정하는 수동선정과 collaborative filtering (CF) 등의 학습 (이걸 기계학습이라 부르기는...)을 이용한 자동화 방법이 혼합된, hybrid 형태가 아닐까 추론해 본다. (어쩌면 공감블로거 선정을 위한 collaborative filtering 알고리즘을 개발할 때 참여해야할지도 모르겠다.) 두번째로 들어가야할 정보로는 문서 자체의 관계 정보가 들어가야할 것이다. 즉, 특정/선택된 문서와 가장 유사한 주제에 대해서 적은 이전/이후의 글들에 대한 목록 정보가 필요하다. 이런 목록을 만들기 위해서는 단순히 (문서) 클러스터링 (document) clustering으로 알려진 방법이 활용될 것이 뻔하다. 그렇지만, 인적관계에도 얘기했듯이, 이때도 당연히 발행자가 인위적으로 특정 포스팅들을 엮는 기능도 함께 제공해줄 거라고 추론해 본다. (문제는 발행자의 신뢰도... 단순 광고를 위해서 관계가 없는 글을 노출시킨다면...) 그리고 앞서 말한 공감블로거 정보가 문서 클러스터링 및 랭킹에 활용될 것같다. 즉, 유사한 문서들이 많다면 공감블로거들이 적은 글을 먼저 보여주는 등의 랭킹요소가 반영될 것으로 보인다. 그리고, 역으로 비슷한 주제의 글들을 적은 블로거들을 공감블로거 목록에 추가시키는 것도 가능하다. 기술적으로 content-based filtering (CBF) 알고리즘이 활용될 것이다. 세번째로 추가될 정보로는 이슈의 연결에 관한 것이다. 대표적인 것이 현재 운영중인 '자세히보기'의 오른쪽 날개의 해당 카테고리의 베스트 글 목록을 표시해주는 것도 초기의/간단한 이슈의 연결이 될 수 있다. 조금 더 복잡하게 들어간다면 앞서 문서의 관계에서 얻은 클러스트 내의 문서들을 다시 더 작은 이슈 클러스트들로 쪼개는 방법이 있을 수 있다. 문서관계에서는 굳이 복잡한 알고리즘으로 클러스트를 구현할 필요가 없다. 단순히 검색을 하듯이, 선택된 문서의 핵심어구 (사용자가 지정한 TAG가 될 수도 있고, 컴퓨터에 의해서 자동으로 선정될 수도 있다)가 포함된 문서들의 목록정도만 보여주면 되겠지만, 이슈연결에서는 그런 목록을 재그루핑을 해서 이슈별로 묶을 수 있을 것이다. 예를 들어, '블로거뉴스'에서 '댓글' 문제에 관한 그룹, '자세히보기'에 관한 그룹', '베스트 선정'에 관한 그룹 등의 다양한 이슈로 묶을 수 있을 것이다. 쉽게 설명해서 현재의 '인기이슈'가 더 세분화된다고 보면 될 것같다. 앞의 세가지 연결은 공간 space 상에서의 연결로 볼 수가 있다. 그렇다면, 시간축 time 상에서의 연결을 네번째 고려대상으로 보면 좋을 것같다. 가장 쉽게 생각되는 정보로는 해당 글을 발행자의 이전/이후 포스팅들의 목록이나 추천을한/댓글을단 글들의 목록을 보여주는 것이다. 현재 별도의 페이지상에서 보여주고 있지만, 이 정보가 '자세히보기'의 화면으로 통합되어서 운영될 것으로 보인다. 그리고, 앞서 설명한 문서 & 이슈/사건의 관계 역시 시간축에서 재구성될 것으로 보인다. 시간의 흐름에 따라서 이슈가 어떻게 발생해서 어떻게 변해가는지를 일목요연하게 보여주는 '사건의 재구성'이 자세히보기 창에서 보여질 것을 기대한다. 시간을 생략한 이슈트리나 이슈마인드맵 (세번째 부가정보에 들어가야겠군요)을 만들어서 제공될 수도 있고, 시간을 포함한 이슈히스토리를 만들어서 제공해줄 수도 있을 것이다. ... 또 다른 다양한 정보들이 더 추가될 것으로 기대하지만, 지금 당장 생각나는 부분은 이정도입니다. ... 이정도만 되어도 단순히 N's OC보다는 나아보이는데...

 혹시 이 정도의 부가정보들이 '자세히보기'에 추가된다면 현재의 (날개 베스트의) 2단계 네비게이션의 불편함을 해소시켜준다고 말할 수 있겠는가? 지금 많은 블로거들의 불만은 오른쪽 날개 베스트를 클릭했을 때, 광고만 큼지막한 '자세히보기' 창으로 들어가서 실제 '원문보기'를 클릭하지 않는다고 아우성이다. 그렇지만, 빈약한 현재의 자세히보기가 제대로된 모습을 갖춘 후, 이 부분에 대한 재평가가 필요하다. 그리고, 앞서 설명한 수준의 정보를 제공해주게 된다면 현재의 2단계 2-step 네비게이션이 2단계 2-way 네비게이션으로 바뀔 것으로 보인다. 즉, 오른쪽 날개의 베스트를 클릭했을 때, 현재 윈도우의 메인페이지에서는 '자세히보기' 내용을 보여주고, 새창을 띄워서 원문을 보여주는 그런 2-way 인터페이스로 바뀔 것으로 보인다. 현 시점에서 이런 2-way 인터페이스를 적용시킨다면, 크리티컬한 영역에서 또 다른 잡음이 발생할 것이 자명하기 때문에 현재 인터페이스는 다음단계의 원문링크를 위한 테스트 기간으로 보여진다.

반응형