Recent Changes Personalization

위키위키의 핵심기능은 RecentChanges입니다. 어느 글이 바뀌었는지 손쉽게 알아보는 방법은 RecentChanges가 거의 유일합니다. 그러나 다양한 View를 제공한다는 위키위키의 장점과는 달리 지금의 RecentChanges는 하나의 View만을 강요하고 있습니다.

이러한 기능의 제약을 보완한다면,

모든 글의 분류 지정
개인별로 원하는 분류에 대해서만 RecentChanges를 살펴보는 기능 제공
RecentChanges에서 수정내용의 주요부분을 간략히 요약해주는 기능
특정 글의 바뀐 부분을 한 눈에 볼 수 있도록 도와주는 기능 - 지난번 읽었던 부분과 다른 부분을 표시해주는 기능
RSS를 통해 다른 위키의 수정사항도 볼 수 있는 기능

..이 있었으면 합니다. 쉽게 개발할 수 있는 기능은 아니지만.

한국의위키위키열린세미나에서도 언급된 내용이지만, 커뮤니티가 성공하기 위해서는 매일 방문하는 사람, 1주일에 1~2번 방문하는 사람, 1달에 한번 방문하는 사람에게 각기 적절한 읽을 거리, 쓸 거리를 제공하는 공간이 필요합니다. 뿐만 아니라 다양한 부류의 사람에게 모두 같은 읽을 거리를 강요하지 않고 원하는 일부 컨텐츠만 선택적으로 살펴보는 기능을 제공할 필요가 있습니다. 지금의 RecentChanges는 마치 자유게시판 하나에서 여러 사람이 다양한 주제의 글을 올리는 것과 유사한 상태입니다. 이것을 적절히 쪼개어서 전체 커뮤니티에 대한 다양한 접근 방법을 제공해줄 필요가 있습니다.

위키위키를 공들여 제대로 개발해 볼 생각이 있는데, 1번의 경우 자연어처리, 문서자동분류 기능을 통해 관리자가 최소한의 인력으로 문서를 분류할 수 있도록, 혹은 글쓰는 사람이 적절한 분류를 고를 수 있도록 도와주고, 2번의 경우 시스템 디자인을 통해 해결해야 하고, 3번의 경우 디자인과 자연어처리를 통해 구현할 수 있습니다.

위키위키가 게시판이나 뉴스그룹보다 적게 쓰이는 이유 중 하나가 본래 상당한 컴퓨팅파워를 필요로 하는 애플리케이션이기 때문에 서버가 버티기 힘들다는 점, 그리고 지금의 위키위키는 오히려 게시판보다 글읽기에 불편함을 주는 단점이 있습니다. 특히 3~4페이지 이상 되는 글에서 토론이 진행되는 경우, 하나의 쓰레드로 줄줄이 글이 이어지지 않고 여러 쓰레드로 토론이 확장되는 경우 전통적인 게시판보다 글읽기가 더 불편합니다.

오오.. 기쁘군요.

일단 말씀드리고 싶은 것은, 위키위키는 컴퓨터가 할 일의 상당부분을 인간이 (머리숫자로) 대체해서 얻는 이득에 상당 부분 의존하고 있다는 점입니다. 자동화/시스템화를 하면서 잃게 되는 것은 무엇인가 한 번 더 생각해 보아야 할 것 같습니다.

1번에서 자연어처리를 언급하셨는데, 현재 Text Categorization은 특정 도메인에 한정된 내용이 아니면 정확도가 별로 좋지 못한 걸로 알고 있습니다. 그리고, 분류가 그렇게 중요하다고 생각하진 않습니다. 어떤 분류에도 해당하지 않는 문서가 (일시적으로라도) 존재할 수 있어야 한다고 봅니다. 분류에 대한 압력은 필요이상의 비용을 창출하는 듯 합니다. 대부분의 KMS 시스템이 semi-structured 및 unstructured information 관리에 쥐약인 (혹은 오히려 악영향을 주는) 것 처럼요.

새로운 분류의 글은 이름없는 분류로 간주되는 것이 맞겠죠. 제가 생각하는 자동분류시스템은 사람의 판단을 도와주는 시스템입니다. 위에서도 적었지만, 관리자가 글쓰는 사람을 도와주는 것이죠. 예를 들어, 지금 이 글을 쓰는데, 이 글에 적절한 분류가 있는지 없는지 저는 잘 모릅니다. 위키위키가 적절한 분류를 추천해주면 더욱 좋겠죠. 보통의 경우엔 분류에 대해 별 생각없이 글을 쓰고, WikiMaster가 돌아다니면서 분류없는 글에 적절한 분류를 찾아주는 방법도 있습니다.

2번 경우는 모임 때 제가 몇 번 언급했는데 Personal Magazine(혹은 Newspaper)과 HierarchicalWiki의 조합으로 가능합니다. 간단하게 말씀드리면 전체 위키 사이트 내에서 여러명의 잡지 편집자 혹은 신문 편집자가 존재합니다(누구나 될 수 있음). 그들은 루트의 RecentChanges에 올라온 글을 보고, 자신의 잡지/신문에 적절한 내용을 골라서 자기의 subwiki에 추가합니다. 그러면 그 사이트에 들어오는 사람들은 현존하는 여러 잡지/신문 중에서 자기가 좋아하는 것만 보면 됩니다. 만약 복수개의 서브위키에 관심이 있다면, 여러개를 선택하면 그걸 merge해서 보여줍니다. 루트의 RecentChanges는 사랑방처럼 아직 가공되지 않은 raw material이 되는 셈이겠죠. 하지만 몇 개의 서브 위키에서 해당 페이지를 언급하더라도 결국은 하나의 페이지만 존재합니다. 서브위키를 통해 전체 위키의 선택된 페이지를 보고, 수정하고 하는 것이죠. 이런 상황에서는 물론 어느 서브위키에도 속하지 않고 (마치 사랑방에 계속 남다가 사라지는 글처럼) 빠져 나가는 글들도 있을 겁니다.

지나치게 인력에 의존하는 시스템은 바람직해 보이지 않습니다. 사람이 관리하는만큼 세밀하고 유연한 조작이 가능하지만, 어느 정도는 자동화되어야 관리인력이 최소화되고, 그 인력으로 다른 창조적인 작업을 할 수 있지요. 예를 들어 이미 분류코드를 통해 분류별 RecentChanges를 따로 보여줄 수 있는 상황에서 굳이 Editor를 따로 둘 필요는 없지요. RecentChanges에 사소한 오타 수정이 반영되어 이용자가 헷갈릴 때, 누군가의 실수로 페이지이름바꾸기를 잘못하여 불필요하게 업데이트표시될 때, 관리자가 손으로 RecentChanges 목록을 수정하는 기능이 필요하겠지만, 일일이 RecentChanges를 손으로 만들어내야 한다면 매우 번거로운 작업이 될 겁니다. 실제로 잘 운영될 것 같지도 않고요. "반복작업은 자동화시켜라" 정도의 규칙은 꼭 필요하다고 생각되네요.

인터넷에 보면 특정 분야에 대해 "요즘 이런 웹문서가 떴다, 유익하다 봐라." 이런 식으로 소식지 비슷한 홈페이지가 많이 있죠? 또 그런 홈페이지들의 소식을 모으는 홈페이지도 있을 수 있고. 전 위키가 광범위하게 커지면 이게 거의 유일한 해결법이라고 생각하고 있습니다. 그리고, 모든 걸 인간이 하는 게 효율적이고 옳다는 건 아니고, 인간이 해서 효율적인 건 인간이 하자는 거죠. 프로그래밍을 하는 사람이 DRY 빼면 뭐가 남겠습니까 --김창준

물론입니다. 내용이 더 방대해지면 반드시 사람이 취합, 선별해서 요약해야 하겠죠. 그런 큰 규모, 많은 사람들이 관심을 가지기 때문에 누군가 노가다로 매일매일 글을 올릴 수 있는 규모가 아니라, 예를 들어 노스모크모인모인의 개발자, 이용자들의 위키페이지를 만들었을 때, OfficialAnnounce와 QnA, Advocacy, 개발자토론 등은 자동화되어 구분되어야겠다는 생각입니다. 음..생각해보니 이보다는 조금 더 규모가 커야겠네요. 노스모크와 영어토론모임, 노볼넷 정도의 관계를 생각하면 적당할 것 같습니다.

3번에서 수정 내용의 주요부분을 간략히 요약해 준다는 것을 잘 이해하지 못하겠습니다. 몇 몇 위키 엔진에서 페이지 편집시 이번 편집 내용의 요약글을 저장하고, 그걸 RecentChanges에서 각각 보여주는 기능이 있는데, 그런 걸 말씀하시는지? OriginalWiki에서 그 기능을 몇 년 전에 한 동안 지원하다가 없애버렸습니다. 제가 아는 이유로는, 처음에는 사람들이 열심히 하다가 거기에 드는 비용 대비 효용의 비율이 낮아서 점점 그런 comment를 달아주는 사람이 줄었다는 것과, 자신이 몇 군데를 고친 경우 그걸 한 줄 요약문으로 제대로 쓸 수 있는 사람이 거의 없다는 점이었습니다. OriginalWiki에서는 한 줄 요약문도 물론 위키페이지와 동일하게 모든 사람이 고칠 수 있었지만...

네. 편집내용의 요약글을 보여주는 기능을 말한 겁니다. 간단히 구현할 때에는 수정부분의 단락 1~2줄을 보여주는 방법이 있고, 문단요약이 가능해진다면 더욱 좋겠죠. 하지만 문단요약이 그렇게 쉽게 되지는 않을 겁니다. 많은 사람들이 돈을 들여 시도해 봤지만, 모두 다 실패했죠. 되면 좋겠다는 희망사항입니다.

문단요약 제대로 할 수 있는 시스템 개발하면 돈 많이 벌 겁니다.

특히 한국어는 현재 영어의 요약 자동화에 비하면 새발의 피 수준이라는데...

앞으로 2~3년 내로는 불가능할 겁니다. 아직 형태소분석, 문장구조인식도 제대로 못하는데 제대로 될 리가 없죠. 자동요약기능이 잘 작동한다면, 벌써 웹검색엔진에 붙었을 겁니다. 자동요약 구현하는 20억짜리 공공프로젝트가 있지만, 먹고 탈나는 것을 염려해 건드리지도 않습니다.

그리고, 4번은 현재 북마크 이상의 자동화를 생각하시는 것인가요?

마지막으로, 특히 3~4페이지 이상 되는 글에서 토론이 진행되는 경우, 하나의 쓰레드로 줄줄이 글이 이어지지 않고 여러 쓰레드로 토론이 확장되는 경우 전통적인 게시판보다 글읽기가 더 불편합니다. 라는 부분은 동감합니다. 위키에서는 모든 글이 직선위에 놓이는(linear) 경향이 있습니다. 그래서 들여쓰기 같을 것을 이용하기는 하지만, 글이 길어지면 보기 힘들어지죠. 대안으로는 글을 부분적으로 folding/unfolding하는 방법이 있을 겁니다. 하지만, OriginalWiki를 통해 느끼는 점은 오히려 이런 기능이 없어서 문서의 다큐먼트모드화가 더 장려되는 단점에서오는장점이 있더군요.

만약 쓰레드모드를 유지하면서 글읽기를 좋게 만들려면, 결국은 유저인터페이스와 인지심리학 등에 대한 심도 깊은 연구와 고민이 필요할 것 같습니다. 일단, 사람의 글읽기는 선형적(linear)이고, 한 번에 하나의 화자와 이야기만을 따라가는 것이 가장 편하다는 점을 고려한다면 위키 방식에서 쓰레드모드를 개선하는 것은 상당히 어려움이 많을 것 같습니다. Folding/Unfolding 이나 ZIP(Zooming Interface Paradigm) 같은 것으로 사람의 포커스를 쉽게 옮길 수는 있겠지만, 어차피 원래 글이 있고 거기에 댓글이 달리는 쓰레드 구조라면 원문이 아닌 이상 글이 조각 날 수 밖에 없죠. 이걸 막으려면 위키의 장점을 포기하고, 게시판처럼 독립된 페이지에 글을 따로 쓰거나 해야겠죠. 어쨌건, 누군가가 원문을 보면서 다른 사람과 현장에서 글을 부분부분 언급해가면서(손으로 가리키기도 하고) 하는 이야기를 듣는 경험에 상응하는 무엇을 컴퓨터 인터페이스를 통해 제공하는 것을 목표로 삼아야겠죠. --김창준

다큐먼트모드에서는 어느 부분이 추가되었는지 더욱 판별해 내기가 어렵더군요. 쓰레드의 순서가 있어 대충 어느 부분을 보면 되겠다는 감도 없으니까요. 다큐먼트모드에서는 Diff화면을 보는 수밖에 없겠습니다.
제가 생각하는 시스템은 각 개인별로 어느 글을 언제 읽었는지 기억해 놓고, 그 이후에 새로 수정된 부분만 눈에 띄게 보여주는 기능입니다. 시스템만 잘 설계하면 그렇게 부담스러운 기능은 아닙니다. 지금의 북마크는 전체 위키페이지에 동일하게 적용되기 때문에, 매번 읽을 글을 모두 읽지 않으면 무용지물이 되어 버립니다. 별 생각없이 시간되는대로, 손 가는대로 글을 읽는 사람에게는 불편합니다. 따로 페이지를 만들어 어떤 인터페이스인지 설명을 드리겠습니다. --Aragorn

저번에 clublet 보셨나요? 옆에 노란색줄이 표시되는... 근데, 이렇게 "새로 바뀐 내용"에 신경을 쓰는 것은 자꾸 뭐가 "바뀌었나"를 보려고 하는 데서 오는 것 같습니다. WardCunningham 같은 경우는, 다큐먼트모드일 경우 그냥 문서를 거듭 읽고(다큐먼트모드 정제에 상당히 도움이 되는..) 그 최종상태의 것으로 평가를 하고, 수정을 하라고 조언을 합니다. 근데, 내가 어느 페이지를 봤다 안봤다 하는 것은 웹브라우져에서 링크 색깔로 구분해 주지 않나요? 그 페이지 내에서 누가 무엇을 읽었다 안읽었다를 컴퓨터가 어차피 가릴 수 없는 것과, 현재의 타임스탬프 방식의 북마크 체제의 불편함에 큰 차이가 있을까요? 페이지의 모든 글을 읽었다는 전제가 있어야 하므로, 저번에 특정 페이지를 읽었던 시점 이후에 새로 바뀐 내용을 표시해 주는 것도 큰 차이가 없을 듯 한데. --김창준

지난번 열린세미나에는 제가 늦게 참석해서 창준님 말씀을 거의 못 들었습니다. [http]

TWiki같은 경우에도 Diff기능이 강력합니다. 대충 만든 [http]

인터페이스가 설명에 도움이 될지 모르겠습니다.
WardCunningham의 위 이야기는 변명 내지는 구라:) 라고 생각됩니다. 다큐먼트 모드의 글이 하나의 정리된 아티클이 아닌 경우, 예를 들어 분류를 나열한 페이지, 관련링크를 잘 정리한 북마크와 같은 페이지의 경우 수정부분을 표시해주는 것이 훨씬 도움이 됩니다. 정리된 아티클의 경우에도 길이가 3~4페이지를 넘어간다면, 수정된 부분의 문맥만 앞뒤로 따지는 것이 훨씬 좋습니다.
시스템 디자인만 잘 된다면, 하나의 글 안에서 어느 부분을 읽었는지 읽지 않았는지 구분해주는 것이 충분히 가능합니다. 어차피 위키에서 history를 관리하기 때문에, 가장 최종본은 온전한 현재의 상태를 기록하고, history에서 역으로 수정된 내용을 기록하는 것이죠. 누가 그 페이지를 보는지에 따라 몇번째 history를 적용할 것인지 결정하면 됩니다.

순간 WishList가 하나 더 늘어났는데, 이렇게 실시간으로 한 주제에 대해 논의할 때 동시수정의 충돌이 심합니다. 글쓰는 시간 10~20분에 3~4명이 한 주제에 대해 이야기하는 경우가 많은데 위키위키는 좀 답답하죠. 이런 때에는 게시판이 정말 편하다는 생각을 하게 되고요. --Aragorn

일전에 퍼키씨도 언급을 했던 자동 merge 기능을 구현하면 어느 정도는 해소될 듯 싶습니다. 위치를 바꾸는 문서구조조정만 아니라면...

자동 머지 기능 구현이 끝났습니다. 패치는 http://fallin.lv/distfiles/moinmoin-automerge.txt 에 있습니다. --퍼키

DeadLink 자동 머지 기능이 어떻게 구현되었는지 모르겠는데, 대신에 반자동 머지 기능을 넣는 것은 어떨까요 ? MoniWiki는 반자동 merge기능을 넣었습니다. conflict되면 사용자가 선택적으로 merge하고, merge된 텍스트가 textarea로 넘겨지면서 현재의 text와 diff정보를 하단에 추가적으로 제공합니다. --고무신

이 페이지에 제기된 몇 가지 기본적인 문제의식에 동감하는 사람들이 현행 RecentChanges, 분류패턴, 지도패턴의 개선방향에 대해 머리를 모아보고자하는 취지에서 위키키워드토론 페이지를 열었습니다. 위키위키와 노스모크에서의 실전/경험에 바탕한 지식은 물론, 많은 참신한 아이디어들로 적극적인 참여 바랍니다.

위키기술분류