27 Feb 2008
2003년 11월부터 개인 누리집을 버리고 블로그를 시작했다. 햇수로 어느 덧 5년차 블로거(Blogger)인 셈인데, 티스토리와 Adsense 조합으로 일어난 요즘 흐름과 소위 파워 블로거나 전업 블로거가 국내에서도 제법 많이 나오고 있는 요즘 흐름은 참 생소하면서도 신기하다.
요즘은 장난감(mash up service) 만드느라 블로그를 많이 챙기지도 않고 다른 블로그도 잘 돌아다니지 않는다. 자연스레 블로그 모임에도 나가지 않는다. 따지고 보면 한참 열심히 블로그를 관리하고 다른 블로그에 돌아다닐 때에도 열심히 돌아다니진 않았다. 몇 번 나가긴 했는데 대부분 아쉬울 때가 많아서 안나가다 보니 어느 새 난 잊혀졌더라. 엉엉.
블로그라는 낱말이 들어가거나 혹은 그런 냄새가 물씬 나는 모임이나 행사에 나갈 지 말 지 결정하는 기준이 있다. 이를테면 블로그 축제 같은 행사나 모임엔 나가지 않는다. 영화 괴물 번개 모임엔 나갔다. 아마도 시간이 된다면 대한민국 블로거 컨퍼런스에 나갈 것이다. 모임을 가리는 기준은 간단하다. 만나는 이유나 목적이 “블로그를 하는 사람, 즉 블로거끼리 만나는 것 자체”인지 아닌지이다.
블로그 축제는 주제나 성격이 애매하게 느껴질 만큼 대놓고 사람과 사람이 만나자는 모임이다. 이런 모임엔 어지간해서는 나가지 않는다. 저렇게 뚜렷한 주제 없이 사람끼리 만나는 것이 주제인 모임은 아무리 좋게 봐도 세력화 느낌이 강하게 들고, 난 그런 모임을 좋아하지 않기 때문이다. 무리를 별로 좋아하지 않는 성격 탓도 있지만, 1인 혹은 개인 매체(media) 블로그라는 놈 성격상 무리화, 세력화가 어울리지 않다고 생각한다. 그런 게 싫어서 까페나 동호회 활동도 잘 안하는데 블로그 공간에 와서 똑같은 경험을 하고 싶지 않다.
블로그는 개인 매체이니 혼자 놀아야 한다고 말하는 것은 아니다. 목소리를 합쳐야 한다면 기꺼이 함께 합칠 수 있다. 주제를 중심으로 뭉칠 수 있고 그 과정이 건전하고 납득할 수 있다면, 그러한 움직임은 실로 환영할 만 하다. 개개인이 원자화 되어 자신의 개성과 생각을 가장 잘 나타낼 수 있게 움직이다가 어떤 주제에 대해 뭉쳐 마치 분자처럼 하나된 모습을 보이면 그 얼마나 아름다운가.
하지만 그러한 주제 없이 단순히 만나고 뭉치는 세력화는 자칫 주제를 위한 무리가 아니라 주제에 폭력 같은 힘을 싣거나 주장을 내기 위한 권력이 되기 쉽상이다. 실제로 그런 모습을 쉽게 볼 수 있고 블로그 축제를 불편해 하는 사람들 상당 수가 그런 상황을 우려한다. 어떤 주제를 위한 모임이 아니라 사람과 사람이 만나기 위한 모임이기 때문이다.
블로거 한 명이 기획하고 준비한 블로그 관련 모임이 기업이나 정부 기관에서 후원을 받는 현상은 좋은 흐름이다. 그만큼 개인 매체가 가진 힘과 목소리에 기업과 정부가 귀를 기울이고 있고 관심을 지대하게 갖고 있다는 반증이며, 이런 자리는 앞길을 닦는 데 많은 도움이 되기 때문이다. 다만, 블로거들 싸잡아 무리짓고 세력화 하면 그만한 힘을 얻기도 하지만, 그만큼 외부 세력에 휘둘리기도 쉽다. 숙달된 게릴라 요원처럼 개개인으로 쪼개진 원자화 된 작은 매체들이 주제(issue, content, agenda, ...) 단위로 뭉쳐 목소리를 내면 개개인을 분류하고 통제하고 싶어하는 기업이나 기관 입장에선 아주 까다로울 것이다.
뭐... 너무 앞서 나가는 듯 싶다. 혜민아빠님이 그럴 요량으로 저런 행사를 연 것도 아니며 앞서 말한 현상은 그럴 수도 있는 상황, 그러니까 결과이지 그런 상황에 대한 의도가 아니다. 더 써봐야 같은 말 되풀이 하는 셈이고. 부디 블로그 축제가 블로그를 통해 자신이 가진 향기를 퍼뜨릴 수 있는 이 강한 사회 흐름에 건전하게 힘이 더 실어주길 바랄 뿐이다. 비록 나는 현 블로그 축제에 공감하지 않기에 지금까지 그래왔듯이 변방에서 조용히 글이나 쓰련다.
18 Feb 2008
최근에 웹 프레임워크 두 가지를 이래 저래 쓰며 찔러보고 있다. 하나는 Python으로 구현된 Django이고, 또 하나는 PHP로 구현된 Cakephp이다. Django로는 미투데이용 장난감 서비스인 그림자놀이를 만들어서 서비스 중이고, Cakephp로는 회사에서 내가 주도하며 쓰고 있다.
Django를 쓴 기간은 길긴 한데 집에서 취미로 만지며 써서 집중도가 좀 떨어진다. Cakephp는 얼마 안되지만 밥벌이로 만지다보니 아무래도 집중도가 좀 더 높다. 어쨌건 이 글을 쓸 만큼 좀 익숙해지고 구조나 흐름을 이해한 상태이다.
두 프레임워크는 RoR이라고도 불리며 인기를 끌고 있는 Rails 프레임워크에 많은 영향을 받았다. 그래서 쓰는 법이나 흐름이 비슷하다. 물론, Rails는 Ruby용, Django는 Python용, Cakephp는 Php용이라서, 언어 특유한 정책이나 철학에 영향을 받아 좀 파고 들다보면 차이가 생길 수 밖에 없다. 그래도 “Hello world” 찍는 방법이나 웹 프로그래밍 할 때 들어가는 잔손질을 많이 줄여주는 방법도 비슷하다.
Django는 Python 언어 특성 덕에 참 간결하고 빠르게, 그리고 편하게 적응하며 쓸 수 있다. Rails는 제대로 쓴 적 없이 가벼이 둘러 본 정도라서 비교를 할 순 없지만, Cakephp와 비교하면 정말 쉽고 간편하다. Cakephp도 따로 프레임워크를 쓰지 않고 php로 웹 개발을 하는 것보다 훨씬 편하긴 한데, Django와 비교하면 “왜 이런 것까지 내가 코딩하고 있어야 하지?”라는 생각이 절로 든다.
개발자와 운영자 입장에서 간결하고 편하고 쉽다는 건 무슨 말일까. 사람마다 다른 생각이 있겠지만, 내 생각엔 서비스 중 cgi 문제가 생겼을 때 그 문제를 찾아가 고치거나, 혹은 기능을 추가할 때 어디를 어떻게 건드리면 되는지 금방 찾을 수 있는 것이라 본다. 그런 점에서 Django로 개발을 하다보면 서비스 흐름이나 구조를 이해하고 추적하기 매우 편하다. 아주 큰 서비스를 만든다면야 그 많은 부분을 머리 속에 다 담을 수 없을테니 당연히 추적하는 데 시간이나 노력이 많이 들겠지만, Django는 소스 자체가 간결하고 프레임워크 흐름 자체가 명료해서 그런 개발/운영 비용이 적게 든다고 본다.
Django는 물론, Python 자체가 상당히 빠른 장점도 있다. Python 자체가 선처리저장소(Caching, 캐쉬)와 비슷한 기능을 가진데다(*.py를 실행하고 나면 컴파일 된 *.pyc 을 만드는데 이게 좀 더 실행이 빠르다), Fast-cgi 로 돌리면 정말 반응이 빨라진다. 여기에 Django에 내장된 선처리저장소 기능을 쓰면 응답 화면이 “팍” 뜬다. php도 fast-cgi로 돌려봤지만 Django 속도에 비할 바가 못된다.
내장 웹서버가 있는 점도 큰 장점이다. 굳이 덩치 큰 아파치 웹서버를 띄워 거기서 개발을 할 필요 없이 아주 작고 가벼운 내장 웹서버로 소스를 웹서버에 재적재(reload)하거나 다국어 기능용 문자열 변환 저장소(gettext에서 쓰는 mo 파일)도 그때 그때 반영할 수 있다. fast-cgi 로 개발할 경우 소스를 변경할 때마다 웹서버를 재실행하여 소스를 웹서버에 재적해야 하기 때문에, 이런 내장 웹서버는 개발에 많은 도움을 준다.
문제가 없는 건 아니다. Django 자체는 좋은 편이지만 이걸 개발하고 관리하는 측이 참 아쉽다. 하위 판(version) 호환성 유지를 위한 노력도 부족해보이고(무심코 Django를 판올림 하다가는 오류 나서 고생하기 쉽상이다), 기능 갱신도 느린 편이다. 재작년인가 작년 초에 Django 0.9x를 봤는데 아직도 0.96.1 이다.
두 번째 불만은 다중 Database를 지원하지 않는 점이다. Django는 아직 다중 DB 접속을 정식으로 지원하지 않는다. 무슨 말인가 하면, MVC 구조로 예를 들면 각 모델(Model)마다 연결할 DB를 따로 지정할 수 없다는 말이다. Scaling up (확장형 서비스 확대)이라면 모르겠지만, Scaling out(분산형 서비스 확대) 방식을 한다면 Django가 참 불편하다. 물론, 아직 정식판에 적용이 안된 다중 DB 접속 기능이 있긴 한데, 저 기능 개발을 시작한 때가 2006년 1월인데도 아직 정식 반영 안된 걸 보면 답답할 따름이다. Django가 판올림하면서 정책을 또 확 뒤엎으면 저 기능을 쓰다 뒤통수 맞을 수 있기 때문이다.
그래서 요즘 Turbogears라는 또 다른 웹 프레임워크에 관심을 두고 있다. Turbogears는 앞서 언급한 Django 장점을 거의 그대로 가진데다, 내가 Django에서 불만스러워 했던 다중 DB 접속 기능도 제공한다. 인터넷 돌아다니다가 Python Web Frameworks: Are Template Languages Worth using, or is Python enough?라는 글을 공감하며 읽었는데, 이 글에서 권하는 PythonPaste 나 CherryPy 중 CherryPy를 Turbogears에서 채택하고 있어서 더 관심이 가기도 했다.
아직 Turbogears를 써보지 않아 두 프레임워크의 차이점을 세세히 꼽을 순 없지만, Django는 기능들을 자체 개발하여 Django라는 이름으로 제공한다면, Turbogears는 기존에 만들어져 있던 모듈들을 Turbogears라는 이름으로 조합한 점이다(표현이 좀 이상한데 주소 연결한 글 참조 바람). 장점이야 각 부문별로 기능이나 성능이 검증된 모듈(module, library)를 쓰고 쉽게 갈아 끼울 수 있다는 점이고, 단점이라면 이게 혹시라도 Turbogears라는 이름으로 일관된 정책으로 잘 묶여 있지 않으면 개발이나 학습에 비용이 많이 깨질 수 있다는 점이다.
Cakephp는 꽤 인기 좋은 Php 웹 프레임워크로 보인다. 무엇보다 가장 큰 장점은 한글 문서가 꽤 잘 구비되어 있다는 점이고, Cakephp API 문서도 잘 준비되어 있어서 좀 막연한 클래스나 메소드가 있을 때 참조하기 좋다.
Rails와 닮은 프레임워크들이 보통 그렇듯이, Cakephp도 오류 상황에 대해 꽤 친절한 편이다. 모델과 연결되는(mapping) DB 테이블이 없으면 그거 없다고 안내하고, 컨트롤러가 이상하거나 없으며 그에 대해 안내하고. 따로 문서를 보지 않고 Cakephp가 뿌려주는 오류 안내문만 따라가도 Hello world 는 아주 손쉽게 출력할 수 있다.
Cakephp의 좋은 점 중 하나는 웹 개발할 때 많이 쓸 법한 메소드나 기능은 아예 클래스에 기본 실행으로 탑재를 해놨다는 점이다. 예를 들면, 컨트롤러에서 화면 출력을 하는 기능이 render 라는 메소드인데, 굳이 이걸 넣지 않아도 알아서 저 함수를 실행해준다. Django는 언어 자체 특성상 소스 코드가 간결하다면, Cakephp는 Php 자체가 소스 코드를 지저분하게 하는 마력이 있다보니 아예 자주 쓸 법한 소스 문장을 쓰지 않아도 해버렸다. 뭐, 그래도 어쨌건 소스 코드가 지저부 해지는 건 어쩔 수 없다.
Cakephp에서 기본으로 탑재하여 쓰고 있는 템플릿 엔진은 사실 템플릿 엔진이라 부르기 민망한 놈이다. 그냥 템플릿 파일 안에 Php로 코딩을 하는 것이다. 몇 번이나 재차 말하듯이 php의 소스 코드는 놀라울만큼 지저분해지기 쉬운 편이라서(난 Perl이나 C 소스보다 php소스를 더 싫어한다), 웹 디자이너가 만지작 거릴 템플릿 파일도 php 코드로 지저분해지기 쉽다.
이 문제는 템플릿 엔진을 Template_같은 녀석으로 갈아 끼우면 쉽게 해결된다. 바로 이 점도 Cakephp 장점 중 하나이다. vendor 라는 정책(?)을 통해 꽤 쉽게 Cakephp 요소 요소를 다른 걸로 갈아 끼우거나 보완할 수 있게 해놨다.
Cakephp는 Django와는 달리 다중 DB 접속 기능을 지원한다. 사실 원하는 만큼 깔끔하고 멋지게 제공하진 않지만, 어쨌건 되긴 된다. 좀 석연치 않은 부분은 Cakephp의 기본 흐름대로 다중 DB에 접근을 할 때 DB마다 따로 지정한 전구분자(prefix)를 제대로 처리하지 못하거나, 모든 DB에 모델에 연결될 테이블이 있어야 한다는 점이다. Hannal 모델은 db1 에 연결하고, peculiarday 모델은 db2에 연결할 때, db1 과 db2 모두 Hannal과 peculiarday 모델용 DB 테이블이 있어야 한다. 이건 아직 확신을 못하는 게 내가 아직은 Cakephp 전체 흐름에 아주 능숙하지 않기 때문이다.
대체로 Cakephp 기능들은 만족스럽다. Cakephp 뿐 아니라 php 자체에 함수들이 워낙 많은데다, 많은 사람들이 쓰는 언어이다 보니 쓸만한 라이브러리가 정말 많다. 그래서 검증되고 쓸만한 기능을 찾지 못해 시간 낭비할 일은 별로 많지 않다.
다만, Cakephp 자체가 좀 느린 편이다. php 반응 속도는 빠른 편이라고 생각하는데, Cakephp는 좀 멈칫하는 것이 느껴진다. 전처리저장소(Caching) 기능을 쓰면 낫긴 하지만, 여러 단계를 거치는 과정 자체가 좀 느리다. Django와 비교하면 많이 답답하다. 둘 다 Fast-cgi 로 돌렸는데 화면 반응은 확실히 Django가 빠르다.
요즘이야 컴퓨터 부품 값이 워낙 싸서 좀 된다 싶은 서비스라면 저렴하게 웹 서버 여러 대 열면 어느 정도 속도는 보장 될테고, 어느 정도 안정된 반응 속도만 보여준다면, 그러니까 아주 빠르지도 않지만 그렇다고 아주 느려지는 현상도 별로 없는 일정함만 보장된다면 대형 서비스에선 아주 빠른 속도가 꼭 필요하지 않을 수는 있다. 즉, Cakephp가 살짝 느린 응답을 보인다고 해서 속상해 할 일은 없다고 본다. 게다가 슬쩍 보건데 Cakephp가 Rails 보다는 빠른 것 같다. 이 정도면 좋지 뭐.
아마 요즘 회사에서 하는 일 중 내 역할이 끝나면 난 다시 Cakephp를 만질 일은 없을테고(php 자체를 별로 좋아하지 않으니까), Turbogears가 마음에 든다면 Django도 다시 건드리진 않을 것 같다. 둘 다 괜찮은 프레임워크이긴 하지만, 이리 저리 써보니 내 성향에 꼭 들어 맞진 않는다. 웹 개발을 주업이 아닌 취미로 해서 내가 이놈들을 내 입맛에 맞게 고쳐가며 쓰는 상황을 애써 피하려다 보니 입맛에 안맞으면 안쓰게 된다. 현재까지는 그래도 Django가 가장 낫긴 하지만 말이다. :) (내가 다중 DB 접속 기능을 쓸만큼 규모가 큰 웹 서비스를 개발할 일은 없으니까)