Wikinote 탄생 비화

위키노트는 2012년 9월 14일에 첫 commit이 이루어졌다.

지금와서 돌이켜 생각해보면 만들게 된 계기도 만드는 과정도 재밌었다. 첫 시작을 하던 때는 지금은 Yobi로 바뀐 nForge4를 만들기 위해서 노력 중이던 때였다. 당시에 nForge4팀에서 node.js를 활용해서 DevNote를 만들었었다. 이 DevNote는 git을 저장소로 사용하는 독특한 구조로 되어 있었는데 문법으로는 markdown을 사용했었다. 그 영향인지 개발문서도 markdown으로 작성되고 있었고 개인적으로도 참 괜찮은 문법이라고 생각했다.

이때에는 마침 위키에도 관심이 많을 때라서 개인 위키도 사용해 보고 싶었다. 하지만 문제는 나에게 서버가 없다는 것이다. 개인 위키를 돌릴만한 서버는 없었으니 자연스럽게 로컬에서 동작할수 있는 Wiki 엔진을 찾기 시작했는데 이때 나름대로 기준을 가지고 찾고 있었다.

1. 로컬에서 별 부담 없이 동작이 가능 할것
2. 설치가 매우매우 간편하고 백업이 쉬울것
3. 문법이 markdown처럼 매우 간편하거나 markdown을 parsing 할수 있을것
4. 위키가 없어도(작동 불능이 되어도) 내용을 볼수 있을것
5. 원하는 기능이 없으면 구현할수 있을것

대부분의 위키엔진은 1번과 2번을 만족시키기 어려웠다. 위키 자체가 집단지성을 활용하기 위한 일종의 협업 도구이다 보니 여러명의 접속을 위해서 DB를 요구하거나 혹은 많은 메모리 소모가 있었다. 뭐 DB야 Linux를 사용하고 있었으니 그냥 로컬에 설치하면 됬지만 사용하고 있는 Fedora의 Update주기가 6개월이라 6개월에 한번씩 꼭 재설치를 하고 있을 때였다. DB를 사용한다는건 매번 포맷을 할때마다 반드시 DB의 백업을 기억하고 있어야 한다는 의미이기도 했다.

나에게 맞는 위키는 어디있나….

DB를 사용하지 않는 위키엔진에는 오래전부터 아는 사람은 안다던 바로 그 국산 위키엔진 모니위키 엔진이 있었다. 이 위키엔진은 모든 정보를 파일(!!)로 저장 했는데 이로 인해서 대형 위키로 쓰기에는 성능이 좋지 않다는 치명적인 문제가 있었다. 하지만 당연하게도 나는 개인 위키로 쓸것이었기 때문에 이것 자체는 문제가 되지 않았다. 문제는 다른데 있었는데, php를 사용한다는 것이다. php의 해악 (영어원문)은 이미 널리 알려져 있고, 모니위키의 코드는 정말 스파케티 그 자체여서 더이상 마음대로 커스터마이징 하기 힘들다는 것과 익숙하지도 않은 아파치 셋팅을 해야한다는 점도 마음에 걸렸다.

그래서 모니위키는 일단 내버려 두고 DevNote를 사용해보려고 했었다. DevNote는 Nodejs기반의 깔끔한 인터페이스를 가지고 있었고 git repository를 이용해서 파일을 저장하기 때문에 백업도 간편했다(여차하면 github나 다른 repository에 올려버리면 된다). 하지만 DevNote는 위키가 아니였기에 링크를 걸기가 참으로 불편했다. 무엇보다 문서의 url이 복잡해서 어딘가에 링크를 걸기가 꺼려지는 정도였다. 거기다 1000개정도의 문서가 있으면 메인페이지의 로딩이 느려지는 문제가 있었다(최근 수정 문서 표시 때문에).

위키는 도쿠위키라는 소문이 있어서 도쿠위키를 찾아봤지만 도쿠위키도 역시 php이라 마음에 들지 않았다. 수많은 종류의 위키 엔진이 있었고 몇몇개를 검토 해봤지만 마음에 쏙드는 위키엔진은 없었다. 대부분의 위키는 php로 짜여져 있거나 DB를 사용하거나 혹은 사용성이 나쁘거나 해서 어딘가 한군데씩 모자랐다.

없으면 만든다!

내 마음에 쏙들지 않는 위키들만 있어서 뭘쓸지 고민하던 중에 문득 없으면 만들면 된다는 생각에 이르렀다. 사실 개인 위키를 쓰고 싶었던 이유는 간단한 문법으로 문서를 쉽게 작성할수 있기 때문이였다. 거기다가 링크를 통한 상호 참조가 매우 간편해서 한 주제에서 다른 주제로 넘어가기도 매우 간편했다. 이러한 장점은 markdown만으로도 가능할것이라고 생각했다. markdown은 기본적으로 html도 렌더링 할수 있으므로 복잡한 문서는 html로 작성할수 있었다.

DokuWiki나 모니위키처럼 저장소를 파일로 사용한다면 폴더 구조를 그대로 가져다가 markdown으로 렌더링만 하면 손쉽게 위키비슷한 어플리케이션을 만들수 있겠다고 생각했다. 즉 항목명을 그대로 path로 활용해서 로컬에 저장해두고 markdown 렌더러만 잘 붙이면 어설프지만 위키 흉내를 낼수 있었다. histroy기능은 DevNote처럼 git을 이용하면 별달리 구현하지 않아도 알아서 잘 관리해 주기 때문에 이 부분도 별문제가 안되었다.

생각보다 쉬울꺼라고 생각이 들어서 곧장 구현을 시작했다. 맨 처음으로 어떤 언어를 사용해서 할것인가 를 정해야 했는데 이때는 nodejs가 한창 주가를 올리고 있을때였다. nodejs는 엄청난 수의 패키지를 가지고 있었고 npm의 존재로 인해서 원하는 패키지를 아주 쉽게 받을수 있었다. 오히려 어떤 패키지를 선택해야만 좋을까라는 이슈가 있을 정도로 원하는 기능의 패키지는 넘쳐났다. 또한 비동기 방식의 구현은 메모리 사용량을 줄이는데 아주 탁월했고 I/O집약적인 작업에 유리했다. wiki는 기본적으로 I/O작업이 주를 이루고 있었고 Web Application으로 만들기 위한 훌륭한 Framework인 Expressjs도 있었다.

험난한 제작과정

하지만 쉬울것 같다고 해서 마냥 쉬운것은 아니였다. 가장 먼저 부딫힌 문제는 바로 path문제였다. Web Application이라면 반드시 CSS와 JavaScript를 사용하게 되는데 이 파일들은 항목에 포함되면 안되는게 가장 큰 문제였다. 즉 Web Application에 사용되는 static 파일들을 제대로 전달할수 없는 문제가 있었다. 가장 흔한 해법은 public 같은 접두어를 붙이고 해당 항목을 생성하지 못하게 하는 것이지만 Application 자체에서 사용하는 다른 경로들도 존재할수 있다는게 가장 큰 문제였다. 이를 위해서 URL Encoding은 하지 않지만 일반적으로 자주 사용하지 않는 문자가 필요했다. 해당 문자를 prefix로 사용하기 위해서 였는데 적어도 특수문자 하나만을 항목으로 등록하는 경우는 잘 없을것이라 판단하여서 나온 결정이었다.

또하나의 이슈는 바로 첨부파일의 경로 문제였다. 첨부파일의 경우 markdown 렌터링을 하면 안된다. 만약 그림 파일이나 실행파일에 대고 렌더링을 시도한다면 끔찍한 결과를 초래할것이다. 첨부파일과 항목명을 구분하는 것 또한 상당한 난관이었는데 리눅스에서는 파일 확장자를 사용하지 않을수도 있기 때문이었다. 이러한 문제들을 처음부터 하나하나 결정하면서 만들기에는 귀찮기도 하고 어차피 혼자사용할 것이라고 생각해서 대충 겨우 돌아만 가도록 만든 측면이 있다.

이렇게 중요한 결정들을 즉흥적으로 한 이유는 단 한가지 wikinote의 코드를 작성한 곳이 지하철(!)이기 때문이다. 지하철을 오가면서 소요되는 시간은 한시간 남짓이었는데 이중 30분은 반드시 앉아 있을수 있는 시간이 있었다. 노트북을 항상 들고 다니는 성격이였기 때문에 지하철에서 코딩할수 있었고 이 시간을 활용해서 WikiNote를 만들었던것이다. 정신없는 지하철에서 코딩을 하다보니 디자인도 대충하게 되고 코드의 구조 또한 그리 좋지 않아서 결국 나중에 다시 리펙토링 해야만 하는 코드가 만들어졌지만 어찌되었던 사용을 할수는 있었다. 이 지하철 코딩에서는 이름도 짓게 되었는데 딱히 생각나는 이름이 없어서 대충 만든 이름이 바로 Personal Wiki.

지금와서야 생각해보면 참 단순하고 멋 없는 이름이었다. 이걸 나름 써먹어보겠다고 이거 붙이고 저거 붙이고 하다보니 그럭저럭 쓸만한 놈이 된건 2012년 12월쯤. 지하철 좌석에서 시작된 위키노트는 잘써먹었으면 좋으련만 막상 쓸려고 하니 기능 부족이 드러나서 이것 저것 덕지 덕지 붙게 된다. 완전히 개인적인 취향으로..

그래도 nodejs 연습용 프로젝트로 이만한 것이 없기도 했고 새로운 기능이 필요하다고 느낄떄 마다 패치 해가며 아직도 쓰고 있다. 이제는 집에서 raspberry를 이용해서 서버에서 굴리고 있지만 아직도 이것 저것 확장할 것도, 고칠것도 많다. node.js 0.8.x버전에서 부터 0.10.28 까지. Expressjs버전 3.0에서부터 4.9가 나오는 지금까지 꾸준히 패치해가며 학교레포트용으로도 프리젠테이션 용으로도 잘 써먹었다. 부족한 기능만큼 발전 가능성이 크다고 생각하며 오늘도 위키노트의 패치를 만든다.