블로깅 툴 플러그인에 대한 생각

현재 우리 주변엔 수많은 블로깅 툴이 있다. 일단 포탈 내지는 서비스 형태로 제공되는 것만 해도 네이버, 다음, 엠파스. 그리고 이글루스와 티스토리 닷 컴이 있다.  설치형으로도 국내의 태터툴즈 혹은 텍스트 큐브, 국외로 눈을 돌리면 MetaWeblog, TypePad, WordPress, ExpressionEngine … 같이 수많은 툴들이 있다.

그리고 포탈 서비스 들을 제외한 툴들 중 상당수는 플러그인을 지원하는 아키텍쳐이다. 즉, 블로깅 툴을 만드는 쪽에선 코어 서비스에 집중하고, 전체 블로깅 툴의 상당 부분 혹은 전체를 공개하거나 사용할 수 있게하고, 여기에 붙을 수 있는 플러그인 구조†를 도입한다. 이런 플러그인 제작이 활성화되면 많은 기능을 상대적으로 쉽게 블로깅 툴에서 이용할 수 있게 된다.

그런데 여기에 하나의 계층layer이 더 추가되기 시작했다. 바로 각 블로그 툴들이 제공하는 공통 API 집합을 이용하는 툴들의 등장인데, 오프라인에서 리치-인터페이스를 제공하는 것들이 있고, 혹은 웹이나 다른 서비스에서 블로그로 글을 쓰게 해주는 기능을 하는 것들이 있다.

이 중에서 첫번째 것에만 집중해서 얘기를 해보면, 이런 툴들에서 추가적인 플러그인 기능이 지원되는 경우가 많다. 이런 경향이 시사하는 것은 “공통 API를 배경으로 한 오프라인 플러그인의 대두 “가 예고되는게 아닌가 생각한다. 특히나 오프라인 블로깅 툴들의 공통 API나 적절한 adaptor-layer 만 존재해도 – 이미 이정도면 망상일지도 모르겠지만. 컴퓨터 공학은 추상화 계층을 추가하면 모든 문제가 풀리는 학문이다(어이) .

사실 이런게 가능하지 않을까 생각한다.

오프라인 플러그인 (P_offline) → 오프라인 블로깅 툴 → 개별 블로깅 툴에 대응하는 추상화 계층(adaptor abstract-layer; AAL) → 개별 블로깅 툴의 플러그인 API → 서버 쪽 플러그인 (P_server)

즉 오프라인 블로깅 툴 위에 붙은 플러그인으로 만족하는게 아니라, 일단 하나의 블로그 툴에서 잘 돌고, 그 기능이 좋아서 널리 퍼질만하다(…)라고 생각되면, 다른 블로그 툴에도 이를 옮기는데 서버 쪽에서 처리해야하는 스크립트들만 블로깅 툴에 속한 플러그인(P_server) 으로 개발하고, 오프라인 블로깅 툴에 속한 플러그인(P_offline)은 유지할 수 있지 않겠냐는 것이다.

이게 조금 더 커지면 오프라인 블로깅 툴 여러 개를 묶는 공통 API집합이 …

컴퓨터 과학/공학의 역사에서 computation power 가 커지면서 원래는 사실상 실용화가 불가능했던 것 들이 실현되는 것이 수 년 단위에서 일어나고 있다. 추상화 계층이 많아지면 많아질 수록 상대적으로 강력하면서도 유연한 시스템이 등장하게 되고, 그에 따라 원래는 불가능하다고 믿었던 협업들이 일어난다. 그런 의미에서 내 망상도 실현되는 날이 오지 않을까 :)

*

† 툴에 따라선 add-on 같은 이름으로 부르기도 한다.

‡ 첫번째에 해당하는 것은 MS Windows에서 쓸 수 있는 Windows Live Writer, MS Word(…), Zoundry Blog Writer, Mac에서 사용되는 ecto, 그리고 파이어폭스 위에서 구동하는 Performancing (파이어폭스 익스텐션이다) 같은 툴들이다.

두번째에 해당하는 것은 스프링노트에서 블로그에 글을 쓴다거나, me2day에서 글을 쓴다거나 하는 것들이다.