워드프레스에 불평 몇 가지

03 Sep 2007

나는 2004년부터 워드프레스라는 블로그 도구를 쓰고 있다. 1.5판 때부터 썼는데 어느 날 보니 2.2까지 판올림 돼있더라. 내 주변 몇 몇 사람은 알다시피 난 워드프레스 지지자였다. 상당히 열렬했다. 그 많은 확장기능들과 겉모습 껍데기들(template)은 정말 대단하다. 더구나 확장기능이나 껍데기를 만들 때 확장하기 참 좋은 구조를 가지고 있어서, 워드프레스로 이것 저것 시도할 수 있는 것도 참 많다. 워드프레스 몸통은 작은 편인데, 그 몸이 참 실한데다 무슨 일이든 해낼 수 있을만큼 유연해서 참 좋아했다. (쉽게 말해서 안정성 좋고 확장성 좋다는 말)

그런데 몇 개월 전부터 나는 워드프레스가 불편하다고 느끼고 있다. 첫째는 자동 광고 등록기 때문이고, 둘째는 자잘한 오류나 문제점들 때문이다. 워드프레스는 이용자가 무척 많다. 그래서인지 워드프레스로 날아오는 광고 글은 무척 많다. 많은 것들을 akismet 이라는 거름기(filter)가 걸래내고 있지만, 그래도 제법 이 거름기를 뚫고 무사히(?) 광고 댓글이 달리곤 한다. 뭐, 이건 워드프레스만 안고 있는 문제가 아니라고 치고.

두 번째 불편함은 워드프레스의 강점이 문제가 된 상황이다. 이 글에서 도마 위에 올리려는 내용도 바로 이 부분이다. 워드프레스는 그 자체를 최대한 작게 만들었다. 요즘엔 기본 기능처럼 쓰이고 있는 꼬리표(tag) 기능도 워드프레스엔 아직도 없다. 워드프레스만 깔면 썰렁한 느낌이 들 정도로 기능이 아주 적다.

대신 여러 확장도구를 만들어 쉽게 붙여 쓸 수 있게 구조를 아주 잘 만들었다. 어지간한 거의 모든 것은 워드프레스에서 확장기능(도구)과 껍데기로 만들 수 있다. 놀라울 정도로 확장성 있는 구조 덕에 이용자들은 자신이 원하는 기능만 가져다 붙여서 쓸 수 있다. 확장 도구는 전 세계에 있는 수 많은 사람들이 만들어서 공개하고 있기 때문에 아주 다양하고 그 수도 많다. 바로 이 점에 내가 반해서 3년 가까이 써온 것이다.

그런데, 문제는 워드프레스 구조가 확정되어 고정된 상태가 아니라는 데에 있다. 워드프레스 구조는 지금도 꾸준히 조금씩 바뀌고 있으며 가끔 중요 정책이 바뀌기도 한다. 이렇게 구조나 정책이 바뀌면 예전 판에 호환되는 일부 확장도구는 호환성에 문제가 생기기도 한다. 예를 들면, 워드프레스에서 꼬리표(tag) 기능으로 널리 쓰이는 Ultimate Tag Worrior 3.x판은 워드프레스 2.1과 잘 어울리질 못했다. 그래서 글을 쓸 때마다 예전 글에 쓴 꼬리표들이 홀라당 날아가곤 했다. 물론, 이런 저런 문제점을 해결한 Ultimate tag worrior 최종판(final)이 나오긴 했지만, 한동안 이 문제로 괴로워했다.

즉, Wordpress를 개발하고 배포하는 곳에서는 그 작은(?) Wordpress만 보완할 뿐, 본체인 Wordpress에 붙어서 움직이는 확장 도구는 건드리지 않는다. 그래서 Wordpress가 기침이라도 한 번 하면 여러 확장도구들이 몸살을 앓는 경우도 있다.

또 다른 문제는, Wordpress 정책이나 구조 변화가 오래 전부터 Wordpress를 써오던 이용자에게 독이 되는 경우이다. 확장도구 문제가 아니라 바뀐 Wordpress 정책이 예전 Wordpress 정책과 충돌해서 Wordpress 안에서 문제가 발생하는 경우이다.

예를 들면, UTF-8를 지원하지 않는 mysql이 두루 쓰이던 Wordpress 1.5판 시절엔 Wordpress는 문자열을 어거지로 UTF-8 상태로 DB에 넣었다. 당연히 문자열은 깨져서 들어갔다. 그런데 시대는 변해서 요즘엔 UTF-8를 지원하는 mysql 깔린 곳이 많다. 무심코 옛 Wordpress 내용을 utf-8 를 지원하는 mysql로 옮기면 글을 검색하지 못하는 문제가 생긴다. 글자형이 다르기 때문에 일치하는 문자열을 찾는 Wordpress 검색 기능으로는 분명 존재하는 글인데도 찾지 못하는 문제가 생기는 것이다. 게다가 Wordpress는 아직도 DB 테이블을 만들 때 utf-8로 글자형을 지정하지 않고, mysql에서 설정한 기본 글자형을 그대로 쓰고 있다. T_T 만약 호스팅 업체에서 mysql 기본 글자형을 latin1 처럼 utf-8로 안할 경우 방금 얘기한대로 DB에는 글자가 깨져서 들어가게 된다. ㅜㅜ 범용성 때문에 이러는 것 같은데, 사실 이건 mysql 환경 설정 변수를 검색해서 utf-8가 아니면 set names utf8; 이라는 mysql 명령어 한 번 실행해주면 해결되는 문제이다! ㅜㅜ

물론, 정책이 바뀐다고 해서 언제나 안좋은 것은 아니다. 문자열 거름 정책이 바뀌어서 예전엔 쓸 수 없었던 > _ < 같은 글자(정확히는 < 이것)를 이젠 쓸 수 있다. 하지만, 크건 작건 정책이나 구조가 바뀌면서 혼란이 일어날 수 밖에 없다.

이외에도 글 낱장주소 구조를 /%postname%/ 으로 하고 글 slug(낱장주소 이름)를 숫자로 할 경우 999까지만 쓸 수 있고 1000부터는 워드프레스가 글을 찾지 못하는 증상도 문제이며, 이 문제는 아직 해결되지 않고 있다. 예를 들면, http://blog.hannal.com/999 는 접근이 되는데 http://blog.hannal.com/1000 엔 그런 것 없다는 오류를 만나게 된다. 숫자로 된 주소 앞이나 뒤에 문자를 넣어줘야 한다. /blog/a1000 나 /blog/1000a , 혹은 /blog/entry/1000 이런 식으로 말이다. 아마도 RewriteRule 과 관련된 충돌인 듯 하다. (물론, 몇 개월 전에 오류 보고를 했지만 답을 아직 받지 못했다)

정리하면 워드프레스의 강점인 작은 몸체와 유연한 확장 도구 구조가 여러 정책 변화나 상황에 맞물려 오히려 독이 되는 경우가 생기는 점이다. 그래서 나는 </a>텍스트큐브로 옮기는 걸 고민하고 있다. 기존 낱장주소(permalink)를 보존하고 보장할 방법이 아직 마땅지 않아서 갈아타고 있진 않지만, 예전 주소를 보존할 수 있는 방법을 찾는다면 망설임 없이 텍스트큐브로 갈아타려 한다. 태터툴즈 시절엔 무겁고 느려서 쓸 생각도 안했는데(분석 차원에서 깔아다 끄적대긴 했지만), 태터툴즈부터 쌓인 개발자들의 개발/운영 경험이나 한결 가볍고 빨라진 구조를 보면 이제는 마음 놓고 쓸 수 있겠다.

언제쯤 예전 낱장주소를 보존할 수 있는 방법을 제시해줄 것인지 알 수는 없지만, 예전 낱장주소를 보존할 방법이 나온다면 바로 텍스트큐브로 갈아타련다.

덧쓰기 : 어째 글 마무리는 얼른 해결 방법 제시해달라고 떼 쓰는 것 같네? 히히.