요즘은 차라리 누군가 바톤을 이어받았으면 싶은 생각도 있을만큼 기획의 진행이 늦으니 어디 쥐구멍이라도 숨고싶습니다만.. 자외선차단지수100의 두꺼운 파운데이션을 얼굴에 덕지덕지 바르고 어쨌건 결자해지의 원칙을 고수하자는 생각에 이슈하나는 던져둡니다.

TRAC도 열려있고 지금껏 도출된 기획문서에 대한 구체화도 진행중인것으로 알고 있는중에 오픈이슈를 하나라도 줄여야 하지 않을까요? 일단 최근 이 포럼에서 떠오르고 있는 위키문법에 대한 부분을 FIX하고 넘어가야 할것 같습니다. 이 게시물은 이 부분에 대한 의견을 모으고 결정사항을 고정하기 위한 게시물입니다.

일단 '위키'라는 이름을 규정하게 하는 요소 중 위키만의 독자적인 문법을 빼놓을 수는 없겠지요. 하지만 이것을 '하나의 기능'으로 떼어놓고 생각해보면.. 'HTML로 표시될 문서를 위한 약속된 문법'이 아닐까 싶습니다. 즉, HTML로 표시하기 위해서 별도의 약속을 사용하는 셈인데... HTML도 약속된 문법이기 때문에.. '약속을 위한 약속'이라는 인상을 지울수가 없네요. 그래서 지금까지 도출된 이슈문서안에서 위키문법에 대한 지원을 구체적으로 명시하지 않은 감이 있습니다. 아니, 처음에만 약간 언급하고 그뒤로는 찬밥취급을 했다고 해도 과언이 아닙니다.

하지만, 이런 부분을 생각해 봐야 할것 같습니다. '위키모듈'에서 처음부터 문서를 쌓는 경우도 있지만, 다른 위키클론에서 마이그레이션하는 경우엔 어떻게 해야 할까요?

물론 여기에서 새로운 고민거리가 등장합니다. '위키문법에는 사투리가 많다'는 점인데.. 같은 볼드체 표시를 위한 문법인데도 위키클론마다 제각각입니다. 마이그레이션을 제쳐두고라도 '위키모듈이 위키문법을 지원했을때, 어디까지를 수용해야 하며, 어떤 위키클론의 문법을 기준으로 삼는가'하는 문제가 있습니다.

위키모듈을 위한 위키문법 파서의 구체화 방법은 이런게 있겠네요..

1. 위키문법에 대한 처리를 에디터 컴포넌트에서 하도록 한다.
2. 특정 위키클론(예: 미디어 위키)의 문법을 받들어(?) 전면적으로 수용한다.
3. 위키모듈의 코어에 위키문법 파서를 관리자가 선택하도록 한다.
4. 위키문법 자체를 포기하고 (스프링노트가 그렇습니다) 나머지 위키의 장점만을 취한다.

위키문법과 ZBXE의 위지윅 에디터의 접점을 찾기 위해서는 이러한 부분에 대한 결정이 선결과제로 보입니다. 각 구체화 방안에 대해서 다시 생각해 보면...

1. 위키문법에 대한 처리를 에디터 컴포넌트에서 한다면
-> 에디터컴포넌트에서 처리해야 하는 양이 방대해집니다. 이 부분을 AJAX를 통해 처리할 수는 있겠지만.. 아시다시피.. AJAX는 게시물 하나를 통째로 보내서 처리할만큼 대용량처리에 대한 부분을 신뢰하긴 어렵지 않나.. 하는 생각을 합니다.
-> 아마 위키문법을 HTML로 파싱하는건 어렵지 않다고 봅니다만, 그 역은 되려 어렵지 않나.. 하는 생각을 합니다. 아마 별도의 문법을 매칭해 줄 수 있는 사전을 필요로 하는 큰 작업이 되지 않을까 싶네요..

2. 특정 위키클론의 문법을 전면수용한다면
-> 미디어 위키와 같은 위키클론의 파서만 떼어내서 적용하는건 기본적으로 어렵지 않다고 봅니다.
-> 가장 손쉬운 방법이 될 수 있겠지만.. 이미 그 시점에서 위키모듈의 확장성을 제한하는 선택이 아닐까 싶습니다.

3. 위키문법 파서를 선택할 수 있게 한다면
-> 마찬가지로 다른 위키클론에서 문법 파서를 떼어다가 ZBXE에 맞도록 포팅해서 특정 위치에 넣을 수 있게 하면 될것으로 보입니다.
-> 이 역시 사전의 구축이 필수적이 아닐까 싶습니다.

4. 위키문법 자체를 포기한다면
-> 많은 위키사용자들에게 환영받을많은 선택은 아니라는 생각도 있습니다. 위키문법이라는 것이 많은 위키사용자들이 불편하다고 하기도 하지만, 그 자체에 익숙해져버린 유저들도 분명 있으니까요. 지금같은 GUI환경에서 vi에디터가 최고라고 여기는 유저에게 '당신은 틀렸어'라고 말할수는 없습니다.


제 생각은 이렇습니다. 굳이 '위키문법'에 얽메이기 보다는 다른 위키클론에서 ZBXE의 위키모듈로 옮겨오는걸 손쉽게 할 수 있는 어떤 방법론을 제시하는것이 어떨까 하는데요.. 왠만한 위키클론이 테마, 혹은 Print View를 지원하는 것에 착안해서, ZBXE의 마이그레이션이 그렇듯, 원격으로 해당 URL를 접속해서 내용을 긁어다가 DB에 집어넣는.. 이 경우 위키문서의 버젼히스토리라든지 하는부분이 걸리기도 하고 실제로 구현상의 난점이 존재할 것으로 보입니다만.. 아무튼 하나의 아이디어로써 봐주시면 좋겠습니다.

즉, 위키모듈의 개발에 있어서 '위키문법'을 주된 이슈로 보기보다는 차후에 생각할 수 있는 '하나의 곁가지'로 인식하자는것이 제 생각입니다. 이 부분은 처음에 위키모듈에 대한 제안이 오고갈때에 한번 언급된 적이 있기도 하구요.


여려분의 생각은 어떠신지 궁금합니다. 의견 많이 달아주세요.. :)



덧: 사실 위키문법보다 시급한건 버젼컨트롤이라든지, 자기조직화를 어떤방식으로 이끌어내게 하는가, 위키문서의 내용이 통합검색에서도 걸려올라와야 하기 때문에 위키문서의 보관방식이라든지 하는 코어가 중요하다고 보고 있습니다. 이 부분에 대한 논의나 규정이 먼저 이루어져야 하겠지요..

덧 2: 솔직히 모니위키를 쓰면서도 꺾쇠괄호를 통해 다른문서를 링크하는건 무척 편하게 사용했던 위키문법이었습니다. 이것이 에디터컴포넌트로 구현된다면 일단 사용성의 면에서도 위키클론을 직접 사용하는것보다 불편할수밖에 없구요.

덧 3: 다른문서를 링크한다거나, ISBN과 같은걸 끌어다 붙인다거나 하는 문법 이외에 문서의 모양을 만드는 위키문법은 솔직히 매우매우불편했습니다. 특히 테이블을 만드는건 거의 쥐약이었죠.. ㅎㅎ