TNF Needlworks

시간을 달리는 교주님

즐거운 이야기 2007/07/12 15:20 by J.Parker

태터툴즈에서 오늘의 Textcube까지 오기까지 험난한 길 였던 것 같습니다. 현 Needlworks의 Creator로 참여는 하고 있지만, 수행 부족이었는지 따라잡기가 여간 힘든 것이 아닌듯합니다.
매번 고공행진을 하고 계시는 교주님의 엄청난 스킬이란 두말 할 필요 없을 것 같습니다.

현재 Textcube 1.5 베타에 접어 들어서 인지 요즘은 더욱 눈에 안 보이시게 날라 다니시는 듯합니다.
본 자리가 있음에도 야간분투(夜間奮鬪) 하시는 것을 보면 정말이지 박수를 안 보낼 수가 없을 듯합니다.
Needlworks의 Balancer답게 구성원들을 조화롭게 잘 이끌어 나가시니 더욱 균형 있고 활기있는 Needlworks가 될듯합니다.

곧 있을 세 번째 태터캠프에서도 블로거 분들께 멋지고 기발한 모습을 보여주시리라 믿습니다.

더운 여름 현업과 Needlworks 일에 열심히 함께 달려주시는 lifthrasiir님, gofeel님, graphittie님, daybreaker님, LonnieNa님, coolengineer님께 화이팅과 박수를 보내드립니다. ^^;

요즘 훨~~훨~~ 날라다니는 교주님을 생각하니 호소다 마모루 감독의 '시간을 달리는 소녀'가 문득 생각나더군요.. 아무리 생각해도 저 문구는 '시간을 달리는 교주님'이 더욱 어울릴 듯 하여 교주님을 위한 포스터 하나 만들어 봤습니다.ㅋㅋ (얼굴 합성은 2탄에서 ^^)

교주님께서 태클 걸어오셔도 삭제 절대 안합니다.ㅋㅋ

---

태터캠프 레어 기념품 광고?

즐거운 이야기 2007/07/12 03:50 by inureyes

포럼에서는 신나게 세번째 태터캠프의 논의를 하고 있습니다. 오늘 밤에는 니들웍스 분들과 두시간동안 스카이프로 컨퍼런스 콜 -인터넷을 통해 여려명이 동시에 통화하는 것이라고 생각하시면 됩니다- 을 했지요. 이것도 익숙해지니 중독됩니다.^^

이번 태터캠프때는 정말 희귀한 기념품을 만들 예정입니다. (절대 이후에 또 만들 기약이 없다거나 그래서가 맞습니다) 텍스트큐브라는 이름이 알고보면 글씨나 글을 의미하는 텍스트가 아니고, 상자를 의미하는 큐브가 아닙니다. 그래서 이번 기념품에는 그 의미를 확 풀어서 다 써 버렸습니다.

태터캠프 블로그에 광고 하나 만들어보래서, paint.net으로 긁적긁적 하나 만들어 보았습니다.
컨셉은

그런 컨셉으로 만들었습니다.


물론 자체 검열 후 태터캠프 블로그에 글 열심히 적고 있는 gofeel님께는 넘기지 않았습니다.

애플 디자이너가 같은 컨셉으로 만들면 레퍼드의 타임머신이 되고, 제가 만들면 저렇게 되는군요.

---

태터툴즈.. 아직도 어려워요.

머리아픈 이야기 2007/07/09 00:21 by LonnieNa

태터툴즈를 처음 알게된건 작년(2006년) 1월이었습니다.
그러고보니 벌써 1년 반동안 태터툴즈를 써오고 있었네요.
이제 곧 텍스트큐브라는 이름으로 다가오게 되겠지요.
태터툴즈에서 텍스트큐브로 넘어과는 과정에서의 글이라 어떠한 영향을 미치게 될지는 잘 모르겠습니다.
니들웍스의 일원이지만, 그 보다 태터툴즈를 사용하는 한 유저로 적어봅니다.

'나를 세상에 표현하는 가장 간단하고 예쁜방법'
간단한 것인가 쉬운 것인가.
이는 분명히 다릅니다.

작년 여름쯤부턴가 SVN[footnote]오픈소스 코드 관리 툴[/footnote]을 알게 되어 태터툴즈 개발자 버전이나, 베타, 알파 버전이 나올때마다 업데이트하여 사용하고 있습니다.
때론 그 결과로 블로그에 댓글이 달리지 않는다던가, 특정 기능이 작동하지 않는건 흔한일이고, 망가져 열리지 않아 애를 태운적도 여러번 있었습니다.
어쩌면 그렇게 에러나면 또 복구해보고 하는데 재미를 붙이는것일지도 모르겠습니다.

근데 요즘같이 무더운날에는 은근히 짜증이 나기도 합니다.
잘 되면 좋을련만, 아주 좋은 기능임에는 확실하나..
초보자분과 여러유저의 편의성과 다양성을 위해 존재하는 기능들이 간혹 뒷통수를 때릴 때가 있습니다.
태터툴즈 Q/A게시판에, '이전의 블로그에서 데이터를 백업해와서 이전을 하려고 하는데 복구가 안된다'는 글을 종종 보게 됩니다.
그 글 내용은 핵심은 '몇번째 줄이 올바르지 않습니다'가 대부분일 듯 싶습니다.
백업해온 블로그는 이미 없어지고 달랑 백업/복구 기능만을 찰떡같이 믿고 있던 유저에게 위와 같은 메시지는 청천벽력일수 밖에 없습니다. 저도 몇번 당해보니 눈앞이 캄캄해지더라구요.(사실 오늘도 저는 이 메시지를 봐야만 했습니다. ㅠㅜ)
여기저기서 들은 건 있어가지고 </comment>가 정상적으로 막아지지 않아 발생한다 라든지 막막한 내용만 알고 있는 저를 포함해 아무것도 모르는 유저는 에디터로 백업된 xml파일을 열어보지만, 오래된 블로그 일수록 그 xml파일의 크기와 라인수는 엄청나기 때문에, 오랫동안 작성한 포스트를 손도 못써보고 날려야한는 결과를 초래하기도 합니다.

텍스트큐브의 슬로건 중,
'TTXML' 포멧을 통해 이용자가 블로그에 올린 모든 데이터들을 클릭 한번으로 PC에 백업할 수 있고, 이를 다시 문서파일이나 인터넷 게시판, 혹은 다른 블로그 서비스에 쉽게 옮길 수 있다
가 있습니다.

물론 이전에 태터툴즈초기부터 있던 기능이긴하나 정말로 아무런 문제를 범하지 않고 정상작동 할수 있도록 하는 부분에서도 많은 노력을 필요하지않나 싶습니다.

---

오픈소스 참여의 길

즐거운 이야기 2007/07/05 02:05 by hojin.choi

제가 텍스트큐브의 커미터가 되기까지 있었던 일을 적어 보는 것이 오픈소스 프로젝트에 어떻게 참여 할 수 있는지에 대한 하나의 예가 될 수 있을 것 같아서 적어봅니다.

먼저, 저는 제 블로그를 만들기 위해 태터툴즈 0.9x 버전을 사용하고 있었던 블로거였습니다. 2005년 당시 수정 블로그와 태터툴즈가 거의 비슷한 선택상황에 있었지만, 왠지.. 아무 이유없이 태터툴즈를 선택했고, 남들 다 하는(?) 블로그를 열었습니다.

그러다가 1.0이 나온다더군요. 아무 생각없이 1.0을 설치했고, 스킨이나 플러그인들을 조금씩 내려 받아 설치 해봤습니다. 거 재밌더군요.

아무 생각없이 또한 블로그 API라는 것을 알게 되었습니다. RSS가 외부에서 읽기 전용이라면, 블로그 API는 외부에서 쓰기까지 가능한 것이었고, 전 이것이 태터툴즈에는 아직 구현되지 않았으나, 로드맵을 보니 곧나올 1.1인가 1.2인가에 들어 있는 것을 확인하였습니다. 6월인가에 나온다더군요. 그러다가 요거 함 개발해보자하고, 플러그인만 손대면 될 것 같아서 남들 소스를 분석하면서 BlogAPI를 플러그인으로 개발하였습니다.

당시 블로그 API를 위해서 XMLRPC를 처음 봤고, 굥장히 흥미로워서 Blogger API, MetaWeblog API, 최근에 MovableType API까지 조금씩 채워넣기 시작했습니다. 이렇게 릴리즈한 것들이 태터툴즈 기본 기능으로 넣으면 어떻게냐는 제안이 와서 흔*쾌*히 그러죠라고 했습니다. 소스의 sandbox에 커밋권한이 주어졌고, 다른것은 어떻게 돌아가는지 전혀 모르지만, 플러그인과 컴포넌트들을 알게 되었습니다.

그러다가 OpenID가 나올때도 비슷했고, 니들웍스가 만들어질때도 그러했습니다. 흥미를 느끼고 플러그인으로 시작한 것이 태터툴즈 전반을 알게 되는 일들로 이어져갔습니다.

누구나 오픈 소스를 시작할 때, 평소에 자주 사용하는 툴을 자기 입맛에 맞게 고치다가 덜컥하게 됩니다. 거창하게 오픈소스에 기여할 뭔가를 찾으면서 시작하는 사람은 없고, 모두 재미로 고치다가 적절한 권한이 주어지게 됩니다.

오픈소스 태터툴즈(텍스트큐브)가 주는 매력은 PHP를 알면 쉽게 플러그인을 만들 수 있고, PHP를 알지 못해도 스킨을 만들 수 있도록 진입장벽을 아주 낮췄다는 것에 있는 것 같습니다. 참여가 쉬워지면, 재미는 두 배가 됩니다. 자신이 재밌게 되면 많은 사람들이 재밌게 됩니다.

쉽게 접근해서 발 뺄 수 없게 만드는, 어딘선가 어떤 방식으로든 이 툴들로 인해 중독되는 사람들을 보면, 태터툴즈는 "향정신성 오픈소스 프로젝트"입니다.

---

혼란 / 태터툴즈 프로젝트를 회고하며

머리아픈 이야기 2007/06/07 00:34 by inureyes

지나가는 이야기.

어떤 일이든 시간이 지나면 역사가 생긴다. 태터툴즈도 돌아보면 3년이 넘은 프로그램이고 프로젝트이다. (위키백과에 정리되어 있는지 모르겠지만) 정재훈님이 시작한 프로그램이 '태터앤 컴퍼니'라는 회사를 탄생시키고, 이후에 다시 GPL로 공개되면서 '태터앤 프렌즈'라는 사용자 커뮤니티가 개발에 참여하게 되고, 얼마 지나지 않아  데이터 형태의 개인 창조물이 창조자가 아닌 기업에 일방적으로 종속되는 것을 반대하는 '태터 네트워크 재단'이라는 개념이 이야기 되며 개발의 대부분을 담당하게 되고, '태터 네트워크 재단'의 주장을 펼치기 위한 구심점이 약한 점을 개선하고자 니들웍스가 구성될 때 까지 거의 쉬지 않고 달리고 있는 중이다.


태터툴즈가 한 단계에서 다음 단계로 넘어가는 과정을 들여다보면 재미있는 현상들을 발견할 수 있다. 그 중 한가지는 단지 3년간의 변화가 '오픈소스 소프트웨어 업계'의 기나긴 역사를 굉장히 압축해서 보여주고 있는 점이다. 개인의 "필요"가 소프트웨어가 되고, 그러한 "필요성"을 공유하는 사람들이 많아지고, 사용자가 늘어나게 되면 회사가 생기게 된다. 이후 사용자 참여와 우군을 확보하기 위하여 GPL을 선택하게 되고, 자발적으로 사용자 중 개발에 참여하는 사람들이 생기게 된다. 이후 기업은 엔터프라이즈 사업, 서비스 사업 또는 기존의 기술에 기반한 새로운 사업에 진출하며, 오픈 소스 프로젝트는 커뮤니티에 맡겨지고 기업과 공생관계를 맺게 된다.

저 과정의 중간 단계에서 사라지거나 지지부진해지는 오픈소스 프로젝트들이 많다. 필요성을 공유하는 사람들이 많지만 개발을 전담하는 기업 또는 조직이 생기지 않을 경우, 사용자의 필요성을 계획성있게 적당한 시기에 반영하지 못하게 된다. GPL을 선택하지 않고 소스 단계에서 공개될 수 밖에 없는 스크립트 언어 기반의 프로그램을 공개할 경우 사용자 참여 대신 소스를 다른 기업등에 넘겨주기만 하는 자선단체가 된다. 프로그램이 공개된다는 특징 때문에 적당한 시기에 이를 기반으로 할 새로운 사업을 찾지 못할 경우 기업의 존폐가 영향을 받게 된다. 오픈 소스 진행 주체가 명확해지지 않으면 새로운 사업에 집중하는 기업의 리소스 부족과, 사용자가 늘어날수록 그에 비례하여 늘어나는 요구사항을 컨트롤하기가 힘들어지게 되고, 적어지는 사용자 참여로 인하여 프로젝트가 죽게 된다.

그 과정을 태터툴즈는 훌륭하게 넘어왔고, TNF/니들웍스, TNC는 그 다음을 향해 달려가고 있다.

초창기부터 태터툴즈를 사용해왔고, GPL과정을 흥미롭게 바라보고 처음 불만을 터뜨렸었고, 지금은 태터툴즈/텍스트큐브가 삶의 한 부분이 된 사람으로서 지난 3년 (그리고 그 중 15개월) 은 여러 의미가 있다. 태터툴즈의 개발 과정과 주체, 변화가 저렇게 속도감을 가지고 달려온 저변을 생각해본다.

'타산지석'이라는 말이 있다. 많은 오픈 소스 프로젝트들의 명멸이 태터툴즈의 방향을 정해 나가는 것에 도움이 되었다. 많은 프로젝트들이 있지만 로드맵을 세워 나가며 많이 고려했던 프로젝트는 '페도라', '모질라' 와 '베릴'  프로젝트였다. 그 셋은 각기 다른 굉장한 개성을 가지고 있다. 구태여 설명하는 것이 사족일 정도이다.

수많은 프로젝트들이 도움이 되지만 특히 그 세 프로젝트들의 생성과 진행, 역사는 '거대한 목표를 가진 프로젝트' 가 어떠한 시점에 어떠한 결단이 필요한지에 대한 통찰의 재료가 된다. 프로젝트들의 실패나 느려짐이 어떠한 상황에서 발생했었는지, 어떨 때 프로젝트가 '바람직한 방향'으로 흘렀는지에 대한 예는 찾아보면 끝이 없다. (역시 이야기하는 것이 사족이 될 것이다.) 적당한 타이밍에 다음 단계로 나가야 한다고 생각했고 태터툴즈를 '도구를 넘어선 어떤 것'으로 사랑하는 분들과 함께 계속 앞으로 나아가고 있다.

이제 얼마 후면 공식적으로 태터툴즈는 텍스트큐브의 모태가 되며 텍스트큐브 1.5가 태터툴즈를 대체하게 될 것이다. 그 결단을 내리기 위해서 고려해야 했던 수많은 시나리오와 가능성이 있다. 수많은 이름 상의 혼란, 기존에 만들어진 브랜드의 포기, 개발 주체들의 관계에 대한 수많은 억측의 가능성등, 어떤 시나리오도 부작용이 없는 경우가 없었다. 하지만 수많은 다른 프로젝트의 예들에서 얻은 결론이 그래야 할 순간이라고 말하고 있기 때문에 그렇게 결정했다.

텍스트큐브로 이름을 바꾸는 것은 단순히 이름의 변경을 의미하는 것은 아니다. 혼란을 충분히 감내해야 할 이유가 뒤에 자리잡고 있다. 간단하게는 외국인들에게 '태터툴즈'가 가지는 영어 어감이 좋지 않음에 대한 지적이 여러번 있어왔다거나 하는 실질적인 이유가 있다. 그렇지만 네이밍의 변경이 의도하는 것은 개발 주체와 상표의 재정의, 그리고 그로 인한 의미가 정확히 전달되는 것이다.

태터툴즈는 TNC의 상표이다. 로고는 상표권이 있고, 엄밀하게 로고와 트레이드 마크는 GPL은 아니다. 설사 TNC가 해당 상표를 자유롭게 사용하도록 하더라도 전체 소스 코드의 얼굴이 되는 상표는 소속이 있는 상태이다. 텍스트큐브로 전환하며 그 부분에 대한 메세지를 내부에 담으려고 하고 있다.

텍스트큐브 로고는 GFDL로 배포될 것이다. (국내 상표의 경우 자유로운 상표 사용을 위하여 TNC를 통해 등록 할 수 밖에 없었다. 이 나라는 개인이 '리눅스'를 상표등록해서 소송 걸기도 하는 나라 아닌가.) 공개되는 소스는 이제 상표까지 온전히 GPL을 따르게 될 것이다. 지금까지 데비안 패키징을 시도해보지 못했던 이유[footnote]GPL 하에서 데비안 패키징을 하기 위해서는 GPL의 결격 사항이 없어야 한다.[/footnote]가 사라지게 될 것이다.

그 과정을 통해서, 그 다음 단계로 나아가기 위한 시작을 밟아 나가려고 한다. 당장은 복잡해 보이는 과정이겠지만 실은 더 간단해 지기 위한 시작이며, 태터툴즈-이젠 텍스트큐브-라는 프로그램을 사용하는 것만이 아니라 프로그램에 대한 소유감과 함께 애정과 책임을 느끼는 사람들이 많아지는 세상을 꿈꾸고 있다.



지나가는 이야기라 하고서 너무 오래 머물렀다. 이제 그만 저장하고 안녕~

---

텍스트큐브 접근제어 (ACL)

머리아픈 이야기 2007/06/06 00:10 by hojin.choi

머리아픈 얘기입니다만, 텍스트큐브(구 태터툴즈)는 다음과 같은 종류의 접근하는 세력이 있습니다. 자격이라 말할 수 있겠지요.

• 블로그 관리자
• 글 쓸 수 있는 사람
• 손님

또한, 이들의 접근을 당하는 개체는 다음과 같은 종류들이 있습니다.

• 글
• 댓글
• 블로그 설정

접근하는 세력(Access Request Object)과 접근당하는 개체(Access Control Object)간의 관계를 모아 놓은 것을 접근제어목록(Access Control List; ACL)이라고 말할 수 있습니다.

태터툴즈의 공식적인 코드에는 다중 사용자에 대한 지원이 있습니다. 이것은 팀블로깅과는 다릅니다. 하나의 데이터베이스를 둘 이상이 각자의 블로그를 운영하는 것입니다. 티스토리도 어찌보면, 다중 사용자 모델로 운영되는 태터툴즈라고 생각할 수 있습니다.

이제 새로이 나올 1.5에서는 팀블로깅이 지원되는데, 따로 운영되는 블로그 여럿이 아닌, 하나의 블로그에 대한 글쓰기, 자기글에 대한 수정/삭제 기능이 지원됩니다. 게다가 오픈아이디를 통해서 접근하는 세력도 비슷한 범주에 넣어 구별할 수 있게 됩니다.

예상되는 시나리오는 다음과 같군요.

철수는 "멋진 블로그"에 글쓰기 권한을 가진 블로거입니다. 자신의 ID로 로그인을 하여 글을 쓰고 공개하였습니다. 그리고, 영희가 그 글에 댓글을 남겼습니다. 아차 싶어 댓글을 수정합니다.

이런 기본적인 동작에 대해서 다음과 같은 접근권한이 동작합니다.

1. 철수는 멋진 블로그에 접근하여 "손님"이란 자격을 얻습니다.
2. 철수는 로그인하면서 "글을 쓸 수 있는 사람" 이란 자격을 얻게 됩니다.
3. 철수는 글 쓰기 메뉴를 선택합니다.
4. 철수는 글을 쓰고 저장후 공개하기를 선택합니다.
5. 영희는 멋진 블로그에 접근하여 기본적인 "손님"이란 자격을 얻게 됩니다.
6. 영희는 글을 읽고 댓글을 씁니다.
7. 영희는 자신이 쓴 글을 수정합니다.
   

간단히 텍스트큐브에서 사용될 ACL에 대해서 끄적여봤습니다. 여기에 OpenID가 살짝 올라탑니다.

---

호환성 유지하기

머리아픈 이야기 2007/05/31 13:54 by daybreaker

좀 규모가 되는 프로그램들을 짜보신 분들은 알겠지만 하위 호환성을 잘 지원한다는 건 정말 어려운 일입니다. 이 일은 프로그램 자체 기능들의 하위 호환성을 유지하는 것과, 프로그램이 돌아가는 환경과 프로그램의 하위 호환성을 유지하는 것으로 나눠볼 수 있는데, 전자는 사실 그렇게 어려운 건 아닙니다. (물론 그 프로그램이 Windows 정도 되는 OS라면 또 얘기가 달라집니다만..)

문제는 후자의 경우입니다. 사실 태터툴즈가 굉장히 많은 버그를 떠안게 된 것도 그런 연유이죠. 사실 이 문제는 모든 '배포형 웹프로그램'에서 나타나는 현상입니다. 서버 환경 자체가 워낙 다양하기 때문에, 또 같은 환경(같은 php 버전, 같은 mysql 버전, ...)이더라도 설정을 어떻게 했느냐에 따라 동작이 달라지기도 하죠. (특히 php의 경우 그것이 두드러집니다)

PHP 5와 MySQL 4.1 이상 환경이 사실 처음 태터툴즈 소스를 만지게 된 우리가 가장 이상적으로 봤던 환경입니다. OOP도 좀더 제대로 사용할 수 있고, UTF-8 문자열도 문제없이 처리할 수 있고 등등요. (참고로 말하자면 MySQL 4.0과 4.1에서 꽤 많은 변화가 있었습니다. utf-8 지원도 그렇고, password 함수의 알고리즘 변경 등이 있었는데, 특히 password 함수가 바뀐 덕분에 제로보드와 호환성 문제가 발생하게 되어 많은 호스팅업체가 4.1 이상으로 넘어가지 않는 결과를 초래하고 말았죠. 사실 mysql 데몬을 띄울 때 옵션을 줄 수 있긴 합니다만..)

한때 내부에서는 태터툴즈를 Python으로 만드는 게 어떻겠냐는 의견도 나왔었습니다. PHP 언어의 한계나 인터프리터 구현의 버그 등으로 인해 우리 입맛에 맞게 쓰는 게 매우 힘들었죠. (특히나 OOP 방향으로 개발하면서 더욱 php에 실망을 많이 했습니다.) 제가 Python을 본격적으로 접하게 된 건 그보다 뒤의 일입니다만, 현재 만드는 사이트는 웬만하면 Python + Django 프레임웍 조합을 사용할 정도로 그 편리함과 깔끔함에 빠져 있습니다. (needlworks.org도 Django 기반입니다. 물론 아직 기능은 별 것 없지만...-_- 참고로 구글도 Python으로 많은 수의 웹페이지를 구성하고 있습니다. Django를 쓴다거나 그런 건 아니고 자체적으로 Python 및 웹서버 구조를 커스터마이징했을 거라고 추측됩니다.)
언어의 깔끔함이나 그런 걸 제쳐두고라도, Python의 경우 상당히 오랫동안 안정화가 되었기 때문에, 더 이용하려고 했던 점도 있습니다. (근본적인 언어 설계의 차이에서 오는 것도 크지요.)

그러나 Python의 Django, PHP의 CakePHP, Ruby의 Rails 등을 쓸 경우 가장 큰 문제는 배포입니다. 사이트 하나를 구축하기 위해서 사용할 때는 매우 편리한 환경을 제공하지만, 그 환경을 설정할 때 root 권한이 필요한 경우도 있고 웹서버의 설정을 건드려야 하는 경우도 있어서 배포용 프로그램에는 적합하지 않죠. 그 점에서만큼은 아직 PHP를 따라올 만한 것이 없습니다. (가장 많은 웹호스팅에서 지원하고 있기도 하구요.)

요즘 학교에서 Key 인증서버 구축을 완료한 덕분에 Windows Vista Enterprise 64bit용을 써보고 있는데, Microsoft가 독점이니 뭐니 해도 하위호환성만큼은 정말 잘 지켜내고 있다는 생각을 금할 수 없습니다. (물론 일반사용자 입장에서 보면 아니라고 할 수 있겠지만, 개발자의 입장에서 보면 정말 대단합니다.) 64비트 환경에서 32비트 프로그램을 실행할 수 있도록 모든 시스템 dll들을 32/64비트 버전을 따로 제공하고 있는 점, 기본으로 접근할 수 있는 Internet Explorer 7을 일부러 32비트용으로 해놨다는 점(Flash player 등은 아직 64비트에서 동작하지 않습니다) 등은 정말 Microsoft 급의 규모가 아니면 하기 힘든 일입니다. Windows 3.1에서 95로 넘어올 때 심시티 2000이 제대로 실행되게 하기 위해서 메모리 해제 함수를 특수 모드로 동작하게 했다는 이야기도 있죠.

Windows의 그 막강한 하드웨어 호환성도 Linux를 여러 번 설치해본 사람이라면 매우 부러워할 만한 부분입니다. 역설적으로 거의 독점하다시피 하는 Microsoft이기에 가능한 부분이기도 하죠. 얼마 전 동아리 서버가 뻑나서 새 CPU와 메인보드를 구입해 Linux를 설치하다가 호환성 문제로 3일 내내 삽질하고 쥐쥐쳤던 걸 생각하면 정말...ㅠ_ㅠ;

아무튼, 웹 환경에서 배포용 프로그램을 개발할 때의 가장 난점이 호환성입니다. 상위호환성은 거의 불가능하다 치더라도 하위호환성을 맞추는 것도 쉽지 않습니다. 태터툴즈의 경우는 PHP와 MySQL 버전이 낮은 환경에서도 잘 실행될 수 있도록 하기 위해 성능을 희생한 부분이 꽤 많습니다. (티스토리의 경우는 서비스이기 때문에 서버 환경을 마음대로 정할 수 있으므로 이런 부분에서 꽤 많은 성능을 끌어올린 것으로 알고 있습니다.) 개인적으로는 제로보드가 그 막강한 시장 영향력(?)을 잘 행사해서 웹호스팅 환경의 꾸준한 업그레이드를 유도해왔다면 훨씬 개발이 편했을 거라는 생각도 해봤지요.

개인사용자용 TextCube에서는 크게 고려할 만한 부분은 아니지만, 요즘 겐도님의 글과 최재훈님의 글을 보면서, 또 Vista를 쓰기 시작하면서 아키텍처와 호환성에 관해 이런저런 생각이 많이 듭니다. (Flickr가 PHP 4와 MySQL 4를 이용하고 있다는 점이 특히 놀라웠습니다. ^^;)

---

플러그인 생각

머리아픈 이야기 2007/05/17 10:45 by J.Parker

태터툴즈 에서의 플러그인 개념이 나타나게 된 것은 아마도 작년 초쯤 태터툴즈 1.0이 배포되면서 활성화 되었습니다. 처음에는 그리 보이지 않게 움직였던 플러그인 들이 지금은 플러그인 게시판 기준 용도에 따른 다양한 플러그인이 420건 정도 됩니다. 현재 플러그인 게시판에 처음 등록되어 있는 것은TENMA님의 '댓글RSS 플러그인'이고, 최근 등록되어있는 것은 팀블로그로 유명하신 차칸아이님의 '포스트 부분 비밀글 만들기 플러그인'입니다. 이렇듯 많은 플러그인이 배포되고 사용되고 있습니다.

사실상 플러그인을 만든다고 하는 것이 스킨 만드는 것 보다 어렵게 생각할 수도 있습니다. 스킨은 html 구조로 속한 치환자만 잘 배치하면 된다고 쉽게 여기십니다. 하지만, 제가 생각하기엔 스킨 만드는 것이 더 어려운 것 같습니다. 뭐랄까 디자인 요소도 배제할 수도 없기 때문이 아닐까 합니다. 플러그인 텍스트큐브 기반 프로그래밍이 PHP입니다. PHP를 배우거나 독학하지 않았다면 플러그인 역시 어렵게 생각 될 수 있습니다. 하지만, 기 배포된 플러그인을 보거나, 플러그인 관련 설명문을 참고 하신다면 크게 어렵게 생각 안 해도 될 것입니다.
처음부터 어렵다고 생각하는 부분이 있기 때문에 막상 만든다는 것이 어려울 수도 있지만, 설치형 블로그의 강점 이기도 한 플러그인을 내가 원하는 것으로 만들어 보는 것도 재밌는 도전입니다.

요즘은 플러그인에 대한 여러 가지 아이디어들을 메모하고 있습니다. 워드프레스에는 있고 텍스트큐브에는 없는 것, 여러 사이트를 서핑 하다가 재밌을 것 같아 보이는 것, 간혹 흘려듣는 블로거분들이 하시는 이런 플러그인이 있으면 좋겠다고 하는 것 등.. 여러 아이디어를 모으고 있습니다. 생각 날 때마다 하나씩 만들다가 개인 업무에 치어 한 동한 잊혀진 대기 중인 플러그인도 많이 있고, 생각은 넘쳐나는데 역량 부족으로 아직 손도 못되고 있는 플러그인도 많이 있는 것 같습니다.

가끔 이런 생각을 자주 하곤 합니다. "어찌하면 플러그인으로 하여금 텍스트큐브가 유용하게 사용 될 수 있을까?"라는.. 혼자 생각한다고 해결될 것은 아니지만, 태터툴즈에서 텍스트큐브로 넘어오면서 뭔가 큰 변화를 줘야 한다는 생각이 뇌리에 자주 남고 있습니다. 생각해보면 아무 것도 아니라고 단정 지으면 될 것 같은데, 그게 잘 안되는 듯 합니다.
아마도 needlworks에서의 역할이 있어서 일지도 모른다는 생각이 듭니다. 오픈소스에 참여하게 된 것은 이번이 처음이지만 잘 헤쳐나 갈수 있을지... 앞으로 부딪혀야 할 난관들이 더 많을 것인데 힘찬 마음보다는 근심이 앞섭니다.

---