모니위키는 왜 텍스트기반을 고집하는가?
예전에 엔하위키 시절 모니위키가 감당못할정도로 느려졌을 무렵, 모니위키는 텍스트기반이라서 DB기반과는 다르기때문에 느리다는 주장을 인터넷에서 종종 보아왔다. 그 당시 엔하위키가 느렸던 것은 버그로 밝혀졌고, 그것을 고친 이후에도 그와 관련된 버그가 여전히 말끔하게 고쳐지지 않아서, 20만 페이지가 되었을 무렵에도 특정 병목 현상때문에 모니위키가 느려지는 현상이 있었고, 이러한 문제가 발생하면 어김없이 이런 얘기가 나왔다. 모니위키는 텍스트 기반이라서 느리다.
이미 이와 관련된 이야기를 여기서 한차례 언급했지만, 이번에는 좀 더 구체적으로 모니위키가 왜 당시에 엔하위키에서 느렸었는지 그 이유를 좀 더 자세히 밝혀보고, 현재 30만 페이지의 규모인 리그베다위키로 그 당시 불가능해 보였던 모니위키가 현재 어떻게 사용되고 있는지 등등을 써보려고 한다.
페이지 개수 매크로의 문제
그 당시 구버전의 모니위키의 경우 페이지 개수를 세는 매크로가 호출되면 디렉토리의 파일 개수를 모두 세었다. 사실 요즈음 파일 시스템 성능이 워낙 좋아져서, 30만 페이지가 가까이 되는 경우 ls 명령으로 시간을 재면 성능이 별로인 서버에서는 10초 미만으로 든다. 성능이 괜찮은 서버라면 훨씬 더 빠르다. (time ls text |wc) ls 명령을 쓰지 않고 간단히 PHP로 짜면 몇초가 들까? 놀랍게도 대폭 줄어들어 1초 수준이 된다. 게다가 이게 캐싱도 된다. 한번 명령을 내리면 1초라면 다음 한번 더 명령을 내리면 0.5초 미만으로 대폭 줄어든다. 정확한 지표는 아니겠지만 이정도로 빠르다.
그런데 모니위키의 속도 문제를 겪었던 구 버전의 경우에 페이지 개수만 세는 방식이 아니였다. 모든 페이지 목록을 가져오고 난 다음에 그 개수를 세었다. 5천 페이지 미만에서는 이 방식도 아주 빠르고 문제 없었지만 1만 페이지 이상 넘어가니 이게 문제가 되었던 것이다. 그래서 페이지 목록을 가져오지 않고 단순히 파일 개수를 세는 방식으로 바꾸었던 것이다. (변경 내역은 https://github.com/wkpark/moniwiki/commit/0ee14c6362ae945e8363ea975fb5721364f2d3eb#diff-10732b52856680bd57ef6fcab3abbbcf 참조)
구 엔하위키의 경우 예전 방식이 문제가 될 수 밖에 없었던 것은, 페이지 오른쪽 상단에 페이지 개수를 항상 보여주고 있었기 때문인데, 페이지 개수 세는 매크로가 테마에서 호출되어졌고, 테마는 페이지를 보여줄때마다 매번 페이지 세는 매크로를 호출했던 것이고, 더군다나 해당 매크로는 한번 갯수를 센 결과를 저장하지 않았기때문에 지속적인 CPU 부하의 원인이 되었던 것이다.
랜덤 페이지의 문제
아무튼 이렇게 페이지 개수를 세는 방법을 고치고나니 속도가 대폭 개선되었다. 그런데 또 다른 문제가 있었는데 그것은 랜덤페이지의 문제였다. 엔하위키시절부터 랜덤페이지는 꽤 인기있는 기능이어서 모니위키의 핫키 기능을 사용하여, 키보드의 "a"를 눌러서 랜덤페이지를 보며 여행하고는 했다. 그런데 이 랜덤페이지도 페이지 목록을 전부 가져와서 그중에 랜덤 페이지 하나를 고르는 방식이였다. 랜덤페이지 기능 자체가 이렇게 리소스를 차지하고 무거운 기능인데, 이 기능을 많이 이용하니 전체적으로 시스템의 로드가 올라갈 수밖에 없었다. 눈치챈 분이라면 페이지 개수를 세던 방식과 동일하게 페이지 전체 목록을 가져오는 문제가 있었다. 즉, 두 문제는 사실상 같은 문제였던 것이다.
그래서 랜덤페이지 기능을 개선하기 위해서 페이지 이름만을 따로 목록을 만드는 방식을 쓰게끔 고쳤다. 매번 페이지 목록을 만들어 읽어들이는것이 아니라, 페이지 목록을 미리 만들어서 텍스트로 저장하고, 랜덤으로 페이지를 고를 때는 전체 페이지 개수에 대해 랜덤으로 페이지 몇개를 고르고 정해진 개수의 페이지만을 리턴한다. 그런데 이런 단순 무식한 방법을 써도 꽤 빨랐고 문제점이 비로소 해결된 듯 보였다. 전페 페이지 목록을 미리 만들어두니, 20만 페이지가 되어도 전체 페이지 목록은 이미 만들어둔 파일을 읽기만 하면 된다. 30여만 페이지의 페이지 목록 파일은 5메가 수준이지만, 별 걱정할 정도로 큰게 아니였고, 랜덤 페이지 기능은 매우 빨랐다. 그 이후로는 이 무식한 방식이 리소스를 많이 쓰는 것을 보완하기 위해서 페이지 목록에 대한 작은 인덱스를 미리 만들어서, 전체 페이지 목록을 모두 읽어들일 필요가 없도록 고쳤다.
리소스를 최소로 사용하기
그리고 한동안 속도문제는 크게 문제가 되지 않다가 20여만 페이지 규모가 되었을 2013년 당시에도 상당히 사이트가 느려져 있었다. 그래서 원인을 점검해보니 역시나 페이지 개수를 세는 문제와 비슷한 문제로 인해 리소스를 많이 쓰고 있던 것이 문제였다. 그래서 고친 것은 다음과 같았다.
- 페이지가 업데이트되면 매번 페이지 개수를 다시 세는 방식 => 페이지가 추가되거나 삭제되면 페이지 카운팅만 가감.
- 페이지가 업데이트되면 매번 페이지 목록을 갱신하던 방식 => 페이지가 추가/삭제되면 목록에서 해당 페이지만 추가/삭제.
별것도 아닌 고침이였지만 리소스 사용률이 줄어서 훨씬 나아졌다. (https://github.com/wkpark/moniwiki/commit/91bb73078e7e2ac7f6092d315b93942855062167 참고) 그리고 뒤를 이은 일련의 고침들은 리소스 사용률과 CPU 부담을 최소로 하면서 최소한의 검색 기능이 작동하도록 하는 고침이였다.
검색의 문제
우선 그동안 제대로 지원하지 않던 검색을 보완했다. 제목 검색은 의외로 매우 단순한 방식으로 해결하였다. 모니위키의 경우에는 페이지 개수가 작은 경우에는 별 문제 없이 제목 검색에 regex를 쓸 수 있었다. 그런데 20여만 페이지 규모가 되니 MySQL같은 DBMS에 20만여개의 페이지에 대한 제목을 넣고 index를 생성한다고 할지라도 regex 검색을 하기는 어렵다. regex 검색을 하면 row를 모두 타야 검색이 되는 것이다. 그래서 간단한 Like 검색밖에 쓸 수 없다. 그러나 그 대신에 20여만 페이지의 파일 이름을 텍스트 파일로 만든 후에, 이 텍스트 파일을 적당히 잘라내어 읽어서 regex로 검색하면 놀라울 정도로 빠르게 20만 페이지의 제목을 모두 검색해낸다. 자모 검색을 할때에도 굳이 별도로 한글 자모 인덱스를 만들 필요조차 없었다. (리그베다위키는 현재 이 방식을 사용중이다)
하지만 본문 검색은 이 방식을 쓸 수 없었고 DBMS 없이 쉽게 지원하기는 어려웠다. 일단 개인 사용자라면 MySQL이나 DBMS에 익숙하지 않을 것을 가정하고 PHP 자체적으로 지원하고 있는 SQLite를 쓰거나 버클리DB를 이용하기로 하였다. 버클리DB를 이용한 간단한 n-gram PHP 검색 엔진이 있었기때문에 이를 고쳐서 모니위키에 적용했는데, 5만여 페이지일 경우에는 꽤 빠르게 검색이 되었는데, 20만 페이지 이상이 되니 이것도 그리 빠르지가 않았다. 그래서 일단은 아예 작동이 안되던 본문검색을 제한적으로나마 작동이 되도록 먼저 고쳤다. 검색을 하는 경우에는 5천여개의 페이지 목록만 가져와서 5천여개의 페이지의 본문만 검색하도록 하는 것이였다. 이러한 제한이 있는 대신에 regex를 사용할 수 있는 유연함을 가지고 있다. 물론 5천개의 검색 결과에서 못 찾으면 그 다음의 5천 페이지에 대한 검색을 하기 위해서, 다음 그 다음 버튼을 눌러야 하는 불편한 방식이다. 사용자가 검색어를 너무 간단한 것을 넣으면 검색 결과가 너무 많이 나오기때문에 사용자는 알아서 검색어를 수정할 것이며, 운 좋게 사용자가 원하는 페이지가 나올 수도 있다. (하지만 이런 방식으로는 부족했기때문에 Elastic Search 엔진을 달아서 테스트해보았다. Elastic Search엔진은 매우 유연하고 모니위키에 적용하기도 쉬웠고 속도도 적당히 빠른 수준이였지만, 결국엔 리그베다위키에 적용되지는 않았고, Elastic Search 엔진은 아직 실험중인 상태에 머물고 있다.)
이렇게 페이지를 몇천 페이지 단위로 잘라서 검색하는 간단한 방식을 쓰니 리소스도 적게 들고 원하는 반응 속도를 얻기 위한 적절한 타협점을 찾을 수 있었다. 속도를 얻기 위해 검색의 완전한 기능은 포기한 셈이다. dba를 사용한 tri-gram 검색엔진도 같이 만들었고 꽤 쓸만했지만 이는 모니위키에 아직 적용하지 못했으며, 그 대신에 이번에 모니위키 1.2.5 게발버전이 되어서야 MySQL을 통한 fulltext 서치를 본문 검색을 옵션을 제공하게 되었으며 30여만 페이지에 대한 검색을 비로서 대응할 수 있게 되었다. (미디어위키 역시 MySQL의 MYISAM 엔진의 FULLTEXT 인덱스를 사용함. 보다 최신의 MySQL은 InnoDB엔진에서도 FULLTEXT 지원)
개인위키를 위한 위키엔진과 RCS 버전 관리
모니위키는 사용자가 별로 좋지 않은 서버나 열악한 호스팅 환경을 가정으로 한다. 최신 PHP도 설치되어 있지 않고, MySQL 지원도 없는 값싼 호스팅 환경, 혹은 PC에서도 문제 없이 사용할 수 있는 개인 사용자에게 초점이 맞춰져 있다.
이러한 상황에서 MySQL지원은 당연히 첫번째 단계에서부터 제외된다. 모니위키가 텍스트기반이 될 수 밖에 없었던 첫번째 이유가 바로 모니위키는 개인위키를 목표로 하고있다는 것이다.
그런데 이러한 부분은 적은 리소스밖에 없는 상황에서도 굴러갈 수 있게 만드는 장점이 있다. 엔하위키 초창기에 모니위키를 선택했던 이유는 다름아닌 소규모 위키를 운영하려고 시작했던 것이 그 원인일 수 있다. 과거 트래픽이 부족해서 엔하위키를 오후에는 쓸 수 없는 경우가 많았다고 하니 어느정도 소규모로 처음에 운영했는지 알만하기는 하다.
두번째로 고려할 수 밖에 없는 부분은 위키엔진의 핵심적인 부분이기도 한 버전 컨트롤 시스템의 선택이다. 그 당시에 많은 위키엔진들은 텍스트 기반이 상당수가 있었고, 그중에 중대규모 위키엔진으로는 TWiki라는 둘째 가라하면 서러워할 유명한 위키엔진이 있다. 트위키는 RCS를 버전 컨트롤 시스템으로 채택하였다. 비단 TWiki뿐만 아니다. 상당수의 위키엔진은 RCS를 쓰고 있었는데 이것이 RCS를 자연스럽게 선택하게된 이유였다.
게다가 파이썬(Python)으로 만든 모니위키의 모체가 된 모인모인(MoinMoin)의 가장 큰 단점을 익히 알고있기도 했다. 모인모인은 자체적인 버전 컨트롤을 하고 있었는데, 모인모인은 과거 버전의 기록을 모두 완전한 텍스트로 저장하고 있었다. 과거 변경 이력을 보려면 과거 히스토리 파일을 모두 뒤져서 보여준다. 이게 소규모일 경우에는 별 문제 없지만, 몇천 페이지만 되어도 문제가 발생하게 된다. 히스토리 보기는 파일의 히스토리가 쌓일 수록 점점 느려졌고, 계속 거의 비슷한 복사본이 쌓이게 되는 구조였다. (노스모크는 이러한 문제점을 해결하기 위해서 주기적으로 과거의 히스토리를 지워버리고는 했다;;; 심지어 사용자의 편집 기록이 별도로 저장되는 editlog마져도 주기적으로 날려버렸다...) 최종버전 텍스트가 1GB라고 하고, 과거 변경 이력이 평균잡아 10개라고만 해도 벌써 10GB에 이르는 용량이 된다. 느리고 리소스도 많이 잡아먹는 이러한 자체적 버전관리 방식의 단점을 알고 있었기때문에 모니위키는 자체적인 버전관리 시스템을 사용하지 않고, RCS 버전관리 시스템을 당연한 듯 사용하게 되었다.
이번에 모니위키 1.2.5를 개발하면서 리그베다위키 서버를 잠시 살펴볼 수 있는 좋은 기회를 가지게 되었는데, 리그베다위키의 경우에는 28만 페이지의 규모에 최종 텍스트 버전이 2.8GB 수준이였으며 (tar.gz으로 압축하니 880MB), RCS 히스토리 파일의 개수는 32만개 정도 되고 그 용량은 12GB가 되었고, tar.gz로 압축하니 2.5GB가 되었다. 단순히 산술적으로 평균 버전 개수가 10개일 경우에 28GB 용량이 될 것이라는 예상을 깨고 그 절반도 안되는 12GB라는 것은 RCS 히스토리 파일의 효율성을 잘 보여준다. RCS는 최종 버전을 고스란히 가지고 있으며, 편집 로그도 자체적으로 보관하고, 각 버전간의 변경분인 delta만을 보존하고 있다. 뿐만아니라 리그베다위키는 editlog도 잘 보존하고 있었다. 2012년 이전의 기록은 안타깝게도 시스템 이전을 하다가 날려버리는 불상사를 겪었으나, 그 이후의 editlog는 모두 보존하고 있었으며 그 기록에는 2012년부터 2015년 5월까지의 편집 기록이 무려 7백4십만건이나 되었다. (editlog 파일은 아파치 로그처럼 일반 텍스트로 저장되므로 유닉스의 wc -l 명령으로 간단히 그 편집 항목수를 알 수 있다. 리그베다의 이러한 기록들을 분석한 결과는 다른 글로 보고할 기회가 있으면 한다)
RCS를 쓰지 않고 자체적으로 버전관리 방식을 쓰는 도쿠위키의 경우에는 과거의 버전을 온전한 텍스트 형태로 보존하되 압축해서 저장하고 있고, 미디어위키 역시 자체적인 버전관리방식을 쓰는데, 과거 버전이 모두 온전한 텍스트로 저장된다. @ditto님의 wikistat (http://sapzil.org/wikistat/)을 살펴보면 한국어 위키백과의 경우 사용자/토론 등등의 페이지를 모두 합쳐서 리그베다위키에 비해 3배 이상의 100백만 페이지를 가지고 있고, 이를 단순히 산술적으로 계산해도 10GB가 되며, 온전한 텍스트로 과거 이력을 보관하고 있기때문에 평균잡아 페이지당 버전이 10개만 되어도 전체 페이지 용량이 100기가 바이트를 넘기고 있다.
문제는 리소스
위키엔진은 사실 매우 단순한 형태라서 DB schema가 복잡할 이유가 전혀 없다. 검색도 제목검색, 본문검색 수준의 기본적인 작업만 된다면 문제될 것이 별로 없다. 제목은 UNIQ하고 index타기에 좋아 검색에 매우 유리하고, 가장 리소스를 잡아먹을 부분은 본문 검색 뿐이다. 본문검색의 경우 기능도 별로 없는 MySQL을 쓸것이 아니라 전문적인 검색엔진인 ElasticSearch을 쓰면 루씬과 같은 고급 형태소분석 엔진을 같이 사용하는게 가능하다. 위키엔진 그 자체는 사실 DBMS보다는 오히려 key-value 형태의 NoSQL이 유리하다 할 수 있다.
미디어위키처럼 DBMS를 써야하는 이유는 다른 것이 원인일 수는 있다. 수많은 사용자들에 대한 데이터베이스가 필요하고, 반달러의 어뷰징에 대비하고 IP를 블럭시키고 사용자에 대한 적절한 대응을 하려면 사용자의 패턴 및 과거 페이지 변경 이력에 대한 추적이 필요할 것이고, 이를 위해서라면 DBMS를 당연히 써야할 수밖에 없어 보인다.
그러나 모니위키는 개인위키를 목표로 하기때문에 이러한 사용자 추적이나 관리 기능이 사실상 전무하고 지원하고 있지도 않았다.
문제는 리소스와의 싸움이다. 모니위키가 DBMS 기반이 아니기때문에 모니위키가 느리다는 말은 전혀 잘못된 말이다. 리소스를 잘 활용하면 DBMS가 전혀 없는 상황에서도 대규모 위키를 지원하는 것이 가능하고, DBMS가 필요한 경우가 있고 그렇지 않은 경우가 있으며, DBMS를 쓰더라도 리소스 관리를 잘못하면 적은 자원으로는 서비스 하기가 곤란한 상황이 된다. 위키백과 같은 경우에는 리소스 부족하면 서버 더 사고, 하드디스크 싸니까 부족하면 붙이고, 메모리 늘리면 된다는 식으로 쉽게 말할 수 있지만 그게 그리 쉬운 말인가? 최소의 자원으로 최대의 효과를 내려는 노력은 당연한 것이고, 모니위키가 지금까지 DBMS를 쓸 필요를 느끼지 않았던 것은 이것만으로도 제 효과를 충분히 내었다고 판단했기 때문이다. 앞으로 MySQL과 같은 검색엔진의 지원이 추가되었으니, 규모에 맞춰서 선택할 수 있는 폭도 넓어졌고, 모니위키는 앞으로도 개인위키를 목표로 하고, 더 사용하기 쉬운 간단한 위키엔진을 추구할 것이다.
여전히 파일시스템 기반의 기조를 지킬생각이라고 누군가가 질문한다면 그렇다고 대답하겠다. 사실 지금의 파일시스템 성능은 과거 10년과 비교가 안될 정도로 좋아진 성능을 자랑한다. 리눅스의 파일 시스템 자체가 개속 개선되고 있는 상황이라는 것이다. 과거에는 DBMS만의 장점으로 꼽히던 일부 기능을 파일시스템 자체기능으로 포함시켜버리려는 시도도 있다. DBMS만 개선되는게 아니라 그만큼 파일시스템 그 자체도 진화하고 있다는 것이다. 그러한 와중에도 역시 리소스를 적게 차지하는 쪽은 파일시스템쪽이며, 특히나 버전관리 시스템의 대부분은 파일시스템을 사용한다. git / SVN / CVS / mecurial 등등의 버전관리 시스템은 모두 파일시스템을 사용한다. SVN은 약간 특이한 케이스인데, 구 버전의 SVN은 버클리DB기반의 버전 컨트롤을 사용했고, 이것이 자주 깨지는 등의 문제가 발생하자 FSFS라는 파일시스템 기반의 버전관리를 지원하게 되었다. (자세한 내용은 http://web.mit.edu/ghudson/info/fsfs를 참고) 그밖에 파일시스템이 더 유리한 경우는 https://www.eldos.com/solfs/articles/7853.php?page=all 문서를 참고하라. RCS보다 더 훌륭한 파일기반이 아닌 버전관리 시스템이 있다면 상황이 달라질 수 있겠지만, 위키위키에서만큼은 아직은 RCS가 버전관리 시스템으로 가장 훌륭해 보인다. (사실 git을 가지고 실험해본 적이 있다. 하나의 파일에 대해서 1000개의 버전을 생성시켜서 저장했더니 RCS이 경우에는 최종 텍스트 크기는 46KB, RCS 히스토리 파일은 820KB정도밖에 안되는 반면, git의 경우에는 46KB 최종 본문 크기 동일하지만 .git 크기가 19MB나 되었다...)
리그베다 위키와 모니위키의 개발 방향은..
모니위키처럼 개인위키를 표방하는 위키엔진이 30여만 페이지를 운영하고 있는 예는 사실 거의 없다. 도쿠위키는 본인의 실험에 의하면 5천 페이지에서 조차도 본문 검색이 너무 느렸다. (못하다는 뜻으로 말하는게 아니다. 그러한 대응이 필요했다면 이미 도쿠위키는 고쳤을 것이다. 다만 아직 필요하지 않아서 고칠 필요성을 못느끼는 것이다.) 유명한 중대규모 위키인 트위키조차도 이런 큰 규모의 위키를 운영하고 있지 않고, 트위키 개발 사이트조차도 사실 너무 느리다. 트위키 역시 대규모 위키에 대한 적절한 대응책을 마련하지 않은 것이다. 이것은 DBMS를 쓰느냐 쓰지 않느냐의 문제가 전혀 아니다.
모니위키는 이번 리그베다위키 사건으로 말미암아 기로에 서게되었지만 다른 한편으로 모니위키 및 모니위키 사용자에게 소식도 있다. 리그베다측에서는 본인의 개발에 필요할 수 있는 리그베다 운영시에 겪었던 여러 문제점을 알려주고, 서버를 개방하여서 본인이 직접 문제를 테스트할 수 있는 테스트 베드를 제공함과 동시에, 모니위키의 안정화를 위한 테스트과정에 참가한 테스터들의 협력을 앞으로도 이어나가며 안정화된 기능을 점진적으로 개방해 나아갈 것이라는 것이다.
뿐만 아니라 그간의 운영을 위해 자체적으로 개발하던 소스와 운영 노하우를 모니위키의 적용할 수 있도록 제공하고 적극 협조해 준다고 하였다. 이는 수많은 모니위키 개인 사용자에게 환영받을 소식임과 동시에 모니위키를 사용하고 있는 커뮤니티위키에도 좋은 소식이 된다.
이러한 것이 모니위키의 코드를 더 복잡하게 만들것이라 생각하는 분들도 계실것이다. 물론 단기적으로 봤을때에는 그렇게 보일 수도 있겠다. 그러나 모니위키는 그 코어 코드를 점점 줄이고 특정 기능을 확장하기 쉬운 구조로 개선하게 될 것이며, 작은 규모의 위키위키에서 고려하지 않았던 부분이 커다란 위키가 되었을 때에 리소스 문제가 발생할 수 있는 부분을 해결해 나아가며, 보안에 관련된 부분은 점점 보강하게 될 것이다.
그간 모니위키는 리그베다와 지극히 한정적인 형태의 협업을 하고 일년에 한두번 할까 말까했던 소통을 하였으나, 이번에 예정된 모니위키 1.2.5 개발판의 경우 리그베다에 100% 적용되었으며, 이제 리그베다위키의 소스는 99.9%가 모니위키와 일치하고, 그 나머지 부분도 모니위키에 반영되거나 더 간단한 방식이 적용될 것이다. 리그베다는 더이상 모니위키 소스를 별도로 관리할 필요가 없어지게 된 것이고, 보안에 대한 문제가 발생하였을 경우에 신속한 대처를 할 수 있게 되었다. 모니위키 1.2.5의 베타테스팅은 리그베다위키와 함께 진행되며, 테스터들과 직접 소통을 하며 의견을 조율하여 모니위키 소스에도 직접 반영할 수 있다는 것을 의미한다.
마치며
리그베다위키 사건으로 시작되었던 일련의 일들이 사실 상당히 혼란스럽고 보는 사람 입장에서도 당혹스럽지만, 이것을 일반 사용자 측면에서 본다면, 리그베다측이 그간 사용자의 요구를 제대로 반영하지 못했다는 점이 분명한 것 같다. 저작권 부분이 가장 이슈화 되었지만, 어디 저작권 뿐이겠는가. 위키백과의 경우에도 아무런 문제 없는 듯이 보이지만, 각 개별 기여자들이 당연히 누려야할 부분은 누리지 못하고 소외된 느낌이다. 위키백과는 누가 기여했는지 그 기여목록을 보려면 특수 기능을 눌러야 한다. 레퍼런스를 달려고 하면 기여자의 이름은 보이지 않고 Wikipedia contributors 라고만 나온다. 히스토리를 봐야 기여자의 이름을 볼 수 있을 뿐이다. 기여자의 링크나 연락처는 쉽게 알 방법이 없다. 하다못해 홈페이지나 이메일 주소도 일일히 찾아봐야 한다. 기여자에게 모든 저작권이 있다고 말하지만 정작 기여자에게 돌아가는 것은 없어보인다.
모니위키는 앞으로 리그베다와 기술적인 협력을 통해서 리그베다위키의 기여자들에게 돌아가야 할 마땅한 권리를 보장하려고 노력하고, 기술적인 것 뿐만 아니라 오픈소스/자유소프트웨어의 가치실현 및 위키위키의 공유정신을 실현해 나아가는 모습을 보여줄 수 있게 되기를 바란다.