지금 내 블로그를 돌리고 있는 바로 이 위키그로브를 만들면서 생각했던 것들을 정리해본다.
목표
내가 위키그로브를 만든 가장 큰 이유는 내가 쓰기 위함이었다. 하나는 내 블로그를 내 맘대로 활용하는 것, 그리고 또 하나는 팀에서 쓸 위키를 만드는 것. 모인모인도 역할을 잘해줬지만 엔드유저 대상으로 만든 게 아니다보니 귀찮은 점이 여러 가지 있었다. 계정 관리가 귀찮고, 플러그인 붙이려면 삽질이 좀 필요하다는 것. 그래서 이 두 가지 문제를 해결하는 것을 목표로 출발했다.
위지윅
근데 여기까지만 하면 좋았을 텐데, 스프링노트의 경험이 있다보니 일반 사용자도 쓰기 쉽게 만들고 싶었다. 사실 개발자란 종족이 따로 있는 게 아닌지라, 일반 사용자에게 불편한 건 역시 개발자에게도 불편하다. 아무리 텍스트를 가지고 노는 직업이라고 해도 위키문법으로 글을 쓰는 것과 WYSIWYG으로 글을 쓰는 것의 차이는 크다. 특히 긴 글을 쓸수록 위키문법은 불편하다. 무엇보다 가장 넣고 싶었던 기능은 스프링노트에서 내가 제안하고 특허까지 받았던 기능, 링크 걸 때 페이지를 추천해주는 기능이다. 스프링노트를 많이 쓰지는 않았지만 이 기능만큼은 정말 너무 편했고, 꼭 가져오고 싶었다. 물론 이건 위키문법으로도 구현 가능하지만, 위키문법을 쓴다는 건 에디터를 기본 textarea로 써서 오류 가능성을 줄이고 페이지를 가볍게 한다는 장점이 있는 건데, 이런 기능을 넣게 되면 결국 스크립팅을 해야 해서 위키문법을 쓰는 장점이 많이 사라진다. 그래서, 어차피 가볍고 심플한 위키문법의 장점을 살리지 못할 바에야 처음부터 위지윅 에디터로 가자는 것이 내 판단이었다.
위지윅 에디터로 가고 싶은 또 하나의 이유는 플러그인 기능이다. 앞서 언급한 것처럼 위키를 개발하는 핵심 이유가 쉽게 플러그인을 개발하고, 또 붙이기 쉽게 하는 것인데, 그러자면 역시 에디터에 뭔가는 손을 봐야 한다. 이래저래 에디터에 기능이 많이 붙을 수 밖에 없고, 그렇다면 위지윅이 유리하다.
물론, 스프링노트 때처럼 에디터를 만들 생각은 없었다. TinyMCE나 CKEditor가 충분히 안정적이라고 생각했기 때문이다. 물론 이건 다소 판단이 틀렸던 것 같다. 일단 맥에서는 제대로 안되는 게 많았다. 따지고보면 큰 문제들은 아니지만, 에디터를 손보려면 꽤 깊이 들어가야 하기 때문에 다른 기능들이 중요한 상황에서 이 컨텍스트 전환은 상당히 부담스러웠다. 그래서 결국 위키그로브의 품질에 꽤 큰 걸림돌이 되었다.
이 부분은 아직 어떻게 해결할지 고민 중이다. CKEditor 4 베타가 나왔는데, 이걸 써봐야 할지, 아니면 redactor를 구매해서 쓸지 고민 중이다. 품질을 평가하는 것 자체도 상당히 큰 일이라는 것이 문제다. 아마 당분간은 현재 그대로 두고 필요한 것만 수정해가면서 가지 않을까 싶다.
이 문제 때문에 Markdown도 심각하게 고려해보았다. Markdown은 위키문법보다는 텍스트 상태에서 좀더 봐줄만하다. mou처럼 사이드에 프리뷰를 제공하는 방법도 있다. 하지만 역시 위의 이유들을 고려하면 위지윅보다 나은 대안이라고 할 수 없었다. 그래서, 위지윅은 아마 포기하지 않을 듯 하다.
플러그인
다음으로 중요한 것은 플러그인. 예전에 유상민 씨와 잠깐 같이 일할 때 MoinMoin 쓰는 걸 보고 감탄한 적이 있었다. 플러그인을 업로드하는 것만으로 동작하도록 세팅해서 자유자재로 플러그인을 추가해가면서 쓰고 있었다. 가히 MoinMoin Master라고 할 만했다. 그래서, 그냥 나도 저렇게 MoinMoin을 쓸까 하는 생각도 많이 했는데, MoinMoin의 다른 단점들이 간단한 게 아니고 또 느렸기 때문에 그 방식 그대로 가고 싶진 않았다. 그래서 플러그인을 아주 쉽게 만들 수 있는 방법을 구상하기 시작했다.
그렇게 생각하다 나온 것이 아예 위키 페이지에서 코딩을 허용하자는 것이다. 이 아이디어도 사실 스프링노트를 만들 때부터 조금씩 다듬어오던 것이다. 그 때는 자바스크립트로 하려고 했었다. 위키 페이지에서 바로 코딩하고 저장하면 바로 동작하는 것. DB는 요즘 Document Storage류의 NoSQL처럼 위키 페이지를 Document Storage처럼 쓰면 된다. 이게 서비스로 나온다면 이제 웹 프로그래밍을 하기 위해 Rails고 Django고 할 필요가 없어진다. 그냥 가입해서 페이지를 만들고, 페이지에서 바로 코딩해서 저장하면 바로 동작하는 웹 어플리케이션이 탄생하는 것이다.
그래서 Programmable Wiki라는 컨셉을 만든 것이다. 위키 페이지에 바로 파이썬 코드를 넣을 수 있고, 위키 페이지를 열면 파이썬 코드가 바로 실행된다. 그럼 정말 뭐든지 할 수 있다. 그래서 이 컨셉이 위키그로브에 들어갔다.
템플릿 엔진
이게 되려면 위키 페이지를 편집할 때 코드를 삽입할 수 있어야 한다. 그럼 결국 JSP나 PHP 같은 문법이 필요해진다. 그래서 선택한 것이 Mako다. 언젠가 내가 템플릿 언어의 종류를 분류한 적이 있었는데, 템플릿 언어를 선택할 때 고민 요소는 크게 세 가지다.
- HTML을 그대로 쓸 것인가, 아니면 다른 형태의 마크업 언어를 도입할 것인가.
- 템플릿 상속을 할 것인가, 외부에서 레이아웃을 주입할 것인가.
- 프로그래밍 언어를 살릴 것인가, 템플릿 전용 언어를 만들 것인가.
예를 들어서 설명하면, 1번에서 전자에 속하는 건 PHP, JSP, erb, django template 등이다. 후자는 Haml 류, markdown, 위키문법 등이다. 2번에서 전자는 Mako, Cheetah template, django template등이고, 후자는 Rails의 layout이나 SiteMesh 등이다. 파이썬 템플릿 언어들은 대부분 템플릿 상속을 선택하고 있다. 3번에서 전자는 PHP, JSP, Mako, Cheetah template 등이고, 후자는 django template, velocity 등이다. 그러니까 템플릿 언어를 선택할 때는 이런 분류를 염두에 두고 결정해야 한다.
나는 1번의 경우는 후자의 장점을 꽤 체감했다고 생각하긴 하지만 여전히 전자가 좋다고 보고, 2번과 3번은 확실하게 전자를 선호한다. 2번에서 전자를 선호하는 이유는 명시성과 유연성. 이를테면 Rails의 경우 Rails의 layout 시스템을 알지 못하면 백날 view를 들여다봐도 이게 어떻게 조립되는지 모른다. 하지만 django template은 템플릿 파일 하나만 열어봐도 어떻게 조립되는지 짐작할 수 있다.
3번의 경우는 Cheetah template이나 Mako 개발자들의 의견에 동의한다. 파이썬은 이미 충분히 좋은 expression language다. 자바는 기본 문법이 verbose하니까 어쩔 수 없이 EL 같은 거 만들어서 쓰지만 이미 충분히 간결한 문법을 가진 파이썬, 루비, 자바스크립트에서 그럴 이유는 없다. 물론 django template은 view에서 복잡한 로직이 들어갈 필요가 없으니 제한한다고 말하지만, view도 리팩토링이 필요하고 programmability가 필요한 건 마찬가지다. 그리고, 새로운 언어를 도입할 만큼의 가치가 있는 이유도 아니다. 그래서, 파이썬 같은 언어에서 django template처럼 설계하는 것은 언어에 대한 모독이다!
암튼, 이런 기준으로 걸러보면 남는 건 거의 Mako 밖에 없다. Cheetah도 문법이 참 맘에 들고 좋지만, 아쉽게도 jQuery랑 충돌한다. 예전엔 Cheetah가 더 많이 쓰였다고는 하는데, 요즘은 Mako가 좀더 널리 쓰이는 것 같다. 그래서, Mako를 도입하기로 했다.
코드 에디터
웹 페이지에서 바로 코딩이 가능한 위키니까 에디터에서 코딩을 할 필요가 있다. 그런데, 그냥 텍스트로만 코딩하기에는 너무 불편했다. 그래서 어느 정도 코드 에디터스러운 기능들을 추가하고 싶었다. 다행히 CodeMirror라는 프로젝트를 알게 되었고, 이걸 붙여넣을 수 있었다. 덕분에 위키그로브는 무려 웹에서 syntax highlight된 코드를 보면서 코딩할 수 있는 위키가 되었다! 여러 가지 code assist 기능도 추가하려고 잔뜩 계획해놓고 있었다는.
테마
템플릿 상속이 가능하다는 것의 또 다른 의미는 테마를 자유자재로 적용할 수 있다는 것이다. 위키그로브에 헤드 편집이 따로 있는 이유가 이것이다. 다른 템플릿을 상속하도록 지정할 수 있는 것이다. Mako 코드를 직접 편집해서 할 수 있다. 그리고 BaseTemplate 자체를 수정해버리면 한 번에 사이트 전체의 테마를 바꿀 수도 있다. 기술적으로는 세상 어떤 CMS보다도 진보적인 테마 적용 기술이라고 자부한다. 하지만, 실제로 쓰기에는 역시 너무 어려웠다. 이것도 나의 욕심이 과했던 부분 중에 하나.
Fork
또 하나 정말 넣고 싶었던 기능은 Fork다. github이 Fork로 흥한 것처럼, 다른 사람의 위키페이지를 Fork할 수 있게 하는 것이다. 그러면 위키그로브는 프로그래밍이 가능한 위키니까 다른 사람이 만든 플러그인을 아주 쉽게 내 위키로 가져올 수 있다. 그러니까 플러그인 마켓 같은 것도 쉽게 만들 수 있는 것이다. 다른 기능이 모두 안정되고 나면 이것이 폭발력을 일으킬 수 있는 기능이라고 본 것. 그러나, 역시 다른 기능들을 완성도 있게 마무리 짓는 게 너무 어려워서 보류 중.
보안
Mako를 쓰면서 가장 큰 문제는 보안이었다. 아무리 Programmability를 준다고는 하지만 나쁜 짓을 하거나 실수를 할 수도 있으니까, 어느 정도 제한을 걸 필요가 있다. 특히 시스템 리소스는 막아야 한다. 그런데, 아쉽게도 파이썬은 자바처럼 보안 모델이 언어 차원에서부터 설계된 언어가 아닌지라 쉽게 할 수 있는 방법이 없었다. RestrictedPython 등등 여러 대안을 검토해봤지만, 일단 템플릿 언어에서부터 충분히 막아주지 못한다면 제대로 돌아가기 힘들다. 그런데 결국 Mako는 템플릿을 파이썬 코드로 변환하고 컴파일해서 exec하는 방식인지라 Mako의 그 부분 코드를 수정하지 않는 이상 완전한 보안은 불가능했다. 이것이 내가 새로운 템플릿 엔진 lit-python을 만든 이유다. 하지만 성능이 다소 낮은 pyparsing으로 만든 거라 production에서 쓰기까지는 갈 길이 멀었고, 보안 기능을 추가해 넣는 것도 작업이 많아 결국 여기까지 하다가 위키그로브를 접게 된다.
사실 초반에 어느 정도 사용자를 확보하게 되기까지는 보안 문제가 그리 중요하지 않을 수도 있긴 하다. 그러나, 결국 언젠가는 해결해야 서비스로서의 가치가 있는 문제이고, 위키그로브로 수익을 내기 전에 이 문제가 닥쳐올 가능성이 매우 높기 때문에 현실적으로 버텨낼 수 없다고 봤다. 그래서 결국 위키그로브를 접게 되었던 것.
목표했던 시장
위키그로브로 목표했던 시장은 굉장히 광범위하다. 일단 첫번째로는 스프링노트의 대체제. 그리고 테마와 플러그인 기능으로 노렸던 부분은 워드프레스와 드루팔이 먹고 있는 CMS 시장. 위키그로브가 이론대로만 구현된다면 On-site에서 모든 커스터마이즈를 할 수 있는 CMS가 된다. 드루팔의 경우 elance에서 프로그래머 일거리 개수가 1위로 올라오기도 할 정도로 파생 시장이 큰데, 이걸 위키그로브의 플러그인 마켓에서 흡수한다면 통행료를 받을 수 있게 된다.
여기서 programmability가 조금 더 강조되면 다음은 heroku나 webfaction을 노릴 수 있게 된다. heroku와 webfaction은 그야말로 웹호스팅과 deploy의 혁신을 보여준 사이트인데, 위키그로브는 그것보다 한 발 더 나아갈 수 있다. 모바일앱을 만들기 위해 Django를 로컬에 설치하고 개발하는 대신 그냥 위키그로브에 접속해서 페이지 하나 만들면 땡이다.
하지만 역시 노리는 시장이 너무 광범위하다보니 어느 쪽도 제대로 노리지 못했다는 것이 함정.
현재상황 및 계획
개발을 중단하긴 했지만 어떻게 하다보니 생각보다 너무 많은 기능이 이미 구현되어 버렸다. 소셜 로그인도 들어가서 로그인하기도 쉽고, 모인모인에서 가져오는 기능도 있고, 스프링노트에서 가져오는 기능도 있다. 서브페이지 기능도 있고, 실제 프로그래밍 기능을 활용한 게시판 기능도 플러그인으로 만들었다. 그래서 실제 내 블로그는 모인모인 import로 가져와서 쓰고, 개발자 위키와 이콜레모 사내 위키는 스프링노트에서 import 해와서 쓰고는 있는데, 아직 완성도가 낮다보니 너무 불편하다. 원래 내가 쓰려던 목적보다 좀 심하게 오바하다보니 품질 관리가 안된 것이다. 역시 전형적인 Feature creep이다. 그렇다, 내가 멍청한 짓이라고 말하는 바로 그 짓을 나도 한 적이 있다.
덕분에 이걸로 바꾸고 나서 오히려 내 블로그에 안 들어가게 된 참 어처구니 없는 현상이 벌어졌다. 내가 쓰려고 만든 블로그인데 내가 불편해서 안 들어간다니;;
어쨋든 짬이 나는 지금 그래서 이걸 어떻게든 수술을 하려고 생각 중이다. 현재 생각하는 대안은 다음과 같다.
- 욕심을 싸그리 버리고 소셜 로그인과 Markdown 문법 적용한 가벼운 위키로 간다.
- 위지윅만 보존하여 스프링노트의 대체제를 목표로 한다.
- 보안 문제 포기하고 현재 기능을 그대로 가지고 가되, github에 오픈소스로 공개해서 설치형으로 쓸 수 있게 한다.
- 설치형으로 하되, Markdown 문법 적용한다. 그럼 훨씬 빨리 완성도를 높일 수 있다.
매일매일 고민하지만 아직도 어떻게 결론을 내야 할지 잘 모르겠다.