• 디자이너들이 능숙하게 다루는 포토샵보다,
• HTML과 CSS로 만든 문서가 여러 웹브라우저에서 똑같거나 비슷하게 보이게 하는 것보다도,
• MS 엑셀보다도 쉽다.
• 어쩌면 자신의 윈도 운영체제에 깔린 바이러스(로 통칭되는 모든 나쁜 무른모(software)들)나 Active-X로 설치된 보안 도구들(n-protect 등)을 깨끗하게 지우는 것보다 이 개발 꾸러미를 익히는 것이 더 쉬울지도 모른다.

그 꾸러미는 바로 파이썬이라는 프로그래밍 언어와 Django 라는 웹 프레임워크이다. 내가 개발에 관심이 있다손 치더라도 기획자가 일주일만에 익혀서 간단한 뭔가를 만들만큼 쉽고 편하며 유연하다. 이 좋은 걸 접했는데 가만 있을 내가 아니다. 사회총지식을 늘리고자 약 10주 동안 엉덩이 두 쪽에 땀띠 생길 정도로 열심히 Django 강좌를 썼다. 하지만, Django나 파이썬을 깊이 이해한 상태에서 쓴 것이 아니어서 여러모로 부실한 부분이 많이 드러나서, 뜻하지 않게 잘못된 지식을 퍼뜨려 아쉬움이 많이 일었다. 다행인 점은 여러 분들께서 지적을 해주셔서 강좌가 개선되었다는 점이고, 불행인 점은 우리나라에 이 강좌처럼 우리말로 웹서비스 하나를 시작부터 끝까지 만드는 과정을 다루는 자료가 없어서 이 부실한 강좌가 여전히 주요 자료로 읽히고 있다는 점이다.

하지만, 이 불행은 며칠 뒤면 끝날 예정이다. 인사이트 출판사에서 “쉽고 빠른 웹 개발 Django”라는 책을 내기 때문이다. “Learning Website Development with Django”라는 원서를 스파이크님께서 번역하신 책인데, 아마존닷컴에서도 호평을 받고 있는 책이다. 난 번역된 책을 사전 읽기(Beta reading)로 접했는데 저러한 호평에 적극 동의한다.

그렇다면 이 책은 누가 읽으면 좋을까? 파이썬이나 Django에 관심이 있지만 영문 자료가 부담스럽고, 내가 쓴 강좌도 어딘가 허술해보여서 못미더웠다면 이 책을 사면 만족할 것이다.

웹 개발 입문자에게도 좋다. 웹 개발자는 웹 개발에 필요한 각 부분을 익힐 필요도 있지만, 개발 공정을 이해하는 것이 무엇보다 중요하다. 경력자와 새내기(신입)을 구분짓는 주요 요소 중 하나가 전체 공정 경험인데, 새내기들은 전체 공정을 겪거나 이해할 경험을 얻기가 쉽지 않다. 그래서 난 개발방법론을 익히는 걸 권하는데, 이론만 접하지 말고 실습도 해야 감각이 는다. 그러한 감각을 늘리는 데에 Django 만큼 좋은 도구도 드물다.

아직 나오지도 않은 책으로 설레발 치는 것 같지만, 앞서 말했듯이 난 이미 읽어보았고 허공에 팔다리 파닥이며 추천할 만하다고 생각하고 있다. 자바나 c# 처럼 다소 덩치 큰 언어를 익히느라 큰 그림을 겪는 데 너무 많은 힘 쏟지 말고, 쉽고 편한 파이썬과 Django를 시작하길 권해본다.

덧쓰기 : 참고로 파이썬은 교육용으로 만들어진 언어이다. 그리고 Django는 파이썬이라는 언어 철학을 잘 담아낸 파이썬스러운 도구라는 평을 듣는다.

덧쓰기 : 원서는 Django 0.96판을 기반으로 하지만, 이 번역서는 스파이크님께서 1.0.2판을 기반으로 다시 쓰셨다고 한다. 꽤 많이 바뀐 점을 생각해보면 번역서 수준을 넘어서는 것이나 마찬가지이다.

그래서 저 강좌를 토대로 후속편, 아니 정확히 말하자면 확장판을 준비하고 있습니다. 저번처럼 새로 다 쓰는 건 아니고요. 지난 글 중 1.0판에서 제대로 쓸 수 있게 일부 내용을 보완하는 겁니다.

연재 시작하면 다시 알릴게요.

저야 진작 0.97시험판이나 1.0시험판을 써오던 터라 큰 불편없지만, 혹 0.96판을 쓰던 이라면 0.96판을 기반으로 하는 자신의 코드를 1.0으로 손보는 안내 문서를 참조하면 무난히 처리할 수 있습니다.

바뀐 부분이 꽤 많습니다. 가장 반가운 점은 Django 내부에서 문자열 처리는 유니코드로 통일한 점입니다. 예를 들면 0.96에서는 UTF-8 문자열을 받고, 이를 모델로 넘겨서 DB에 넣을 때는 encode(‘utf-8′) 메소드를 이용하여 ASCII 문자열로 인코딩한 UTF-8 문자열을 넣어야 했습니다. 그러나 이제는 그냥 바로 넣으면 됩니다. 또 이와 관련하여 모델에서 쓰던 __str__ 메소드도 없어지고 __unicode__ 만 쓸 수 있습니다.

두 번째는 폼(forms)이 newforms 로 바뀐 점입니다. 이전까지는 0.96에써 쓰던 forms 를 oldforms 로 쓸 수 있었는데 이젠 아예 없어졌습니다.

세 번째는 admin mode 입니다. 예전엔 admin mode 를 사용하려면 models.py 등을 건드려서 코드가 이곳 저곳에 흩어졌는데, 이제는 admin.py 으로 정리하면 됩니다. 그래서 admin mode 를 열고 웹에서 접근하는 방법(urls.py 등)이 꽤 바뀌었습니다.

다국어 환경(i18n) 기능 중 po 파일과 mo 파일 만드는 방법도 살짝 바뀌었습니다. 예전에는 make-messages.py 가 po 파일을 만들고, compile-messages.py 가 mo 파일을 만들었는데, 이젠 이 두 파일에 있던 기능이 django-admin.py 안으로 들어갔습니다. django-admin.py makemessages 나 compilemessages 라고 하면 됩니다. 근데 make messages는 여전히 파일 확장자가 py 인 것만 잘 추려내서 po 파일로 만드네요. -e html 이렇게 추가 확장자를 넣어도 html 것은 잘 안됩니다. django 쪽 문제는 아닌 것 같지만요.

request 객체도 눈 여겨볼 만 합니다. request 객체는 urls.py 에 연결해놓아서 이용자 요청을 처리해주는 view 콜백함수(callback)에 인자로 넘어오는데, 예전엔 별 기능이 없었습니다. 그러나 0.97부터는 이용자가 ajax 방식으로 접근한 것인지를 확인할 수 있는 is_ajax 메소드 등 편리한 기능이 많이 생겼지요. 이용자가 form 으로 올리는 파일을 받아 처리하는 파일 업로드 부분도 깔끔하게 정리 됐습니다.

재밌는 건 GeoDjango 라는 모듈입니다. 예전엔 몰랐는데 이런 게 들어가서 /django/contrib/gis 에 예쁘장하게 자리 잡고 있군요. GeoDjango는 간단히 말해서 위치(Geographic) 정보를 다루는 GIS를 지원하는 추가 모듈입니다. 예전에 지도와 연동되는(mash up) 시험용 서비스를 만든 적이 있는데, 위치값 처리가 영 귀찮았습니다. 근데 이런 걸 처리해주니 한결 편해지겠네요. 거리 관련 쿼리(Distance queries) 내용을 보시면 쓰임새를 바로 이해하실 수 있습니다. 제 관심사와도 맞는 모듈이라 무척 흥미롭습니다.

이외에도 많은 부분이 개선되고 추가 되었습니다. 단지 제가 0.96을 안쓴 지 좀 돼서 비교를 더 하기 힘들군요. ^^;

아쉬운 점은 이번에도 다중 DB 접속 기능이 안들어갔고, 모델 API로 group_by 가 안들어갔네요. 1.0시험판에도 들어가있지 않았기에 별 기대는 안했지만, 막상 정말로 추가 안된 걸 보니 아쉽긴 합니다.

0.96판도 꽤 좋았지만, 1.0판에 들어서면서 정말 편하고 강력한 모습으로 탈바꿈 했네요. 비록 0.96판을 기준으로 했지만, 실제 코드 작성은 0.97판을 기반으로 해서 1.0정식판에서도 강좌 내용에 별 영향이 없는 날로 먹는 Django 웹 프로그래밍 강좌를 보며 보다 강력해진 Django 1.0을 써보세요. 추천합니다.

이미 비슷한 서비스가 있는데 굳이 직접 만들어서 고생할 필요 있나 생각이 들기도 하지만, 내 기획을 또 한 해 넘겨 묵히며 죽일 순 없다는 오기도 들어서 만들지 않을 수가 없더라. 지향점이 저 서비스와 다른 점도 큰 이유이다. 내가 만들고자 하는 건 “책 많이 읽는 도서관 사서 같은 서비스”이기 때문이다.

어쨌든 만들고 있다. 작동 환경은 웹이다. 파이썬용 웹 프레임워크인 django 로 뒷단(back-end)을 만들고 있으며, XHTML 1.0과 CSS, 그리고 javascript 로 앞단(front-end)을 만들고 있다. 일부 있어보이는 조작 체계(Rich Interface ? 하하)는 javascript 로 처리하는데 이를 jQuery에 맡겼다. 책 정보는 Aladdin (알라딘)에서 제공하는 검색 Open API를 이용하고 있다.

파이썬과 django

django 는 아직도 우리나라에 쓰는 사람이 많지 않다. 관련 자료도 적다. 얼마 전에 연재를 마친 날로 먹는 Django 웹 프로그래밍 강좌는 여러 모로 많이 부족한데도 이 강좌가 그나마 볼만한 문서처럼 되고 있는 실정이다. ㅜㅜ 물론 영문 자료는 참 많지만, 아무래도 부담이 가는 것은 사실이다.

그런 부담을 걷어내면 django 는 정말 훌륭한 웹 프레임워크이다. 현재 배포 중인 안정판인 0.96은 참 불만스럽지만, 곧 정식 발표되는 1.0은 시험판인 지금 것도 꽤 편하고 강력하다. 더욱이 파이썬이라는 언어가 강력하고 매력 있어서 개발이 참으로 즐겁다.

좋은 점 몇 가지를 꼽으라면 관리자(admin) 기능과 모델(model) 기능, 이용자 인증 모듈, 그리고 꽤 작고 직관성 높은 django 구조를 들 수 있다. 관리자 기능, 이용자 인증 모듈은 내가 무척 좋아하는 기능으로 이 둘 덕분에 개발 기간이 크게 줄어들었다. 관리자 기능은 rails(레일스)에서 scaffold 와 비슷한데 그보다 더 실용성 있고 강력하다. 개발 초기부터 개발 완료 후 운영 과정에까지 쓸 수 있다. 이용자 인증 모듈(기능)은 이용자 추가, 관리, 인증 기능을 따로 만들 필요가 없어 좋다. 이게 의외로 손이 가는 부분이라서 이용자 인증부를 다 만들때까지는 연계되어 돌아가는 다른 부분 개발이 난감할 수 있는데, django 에서 제공하는 이용자 인증부를 쓰면 바로 적용할 수 있다.

파이썬이 갖는 장점 덕에 django 가 더 좋은 점도 있다. 파이썬은 코드 예외성이 무척 적은 언어이다. 파이썬 언어 철학 자체가 문제를 해결하는 방법은 최소화 하기 때문이다. 그래서 파이썬에서는 같은 일을 하는 코드를 짰을 때, 누가 그 코드를 쓰더라도 대체로 비슷하게 생겼다. 쉽고 간결한 코드, 그리고 문법(들여쓰기 같은 문법 강제성은 종종 귀찮음을 일으키곤 하지만) 덕에 개발 자체가 즐겁다. 고작 15kb 로 알라딘에서 책 정보를 가져와서 DB에 저장, 이용자 인증(로그인 등), 책 검색, 책 소유/읽음/관심 여부를 표시하는 기능들을 예외처리(Exception)까지 해서 만들었다. django 에서 제공하는 편리함도 무시할 순 없지만, 파이썬 언어 자체가 가진 특성이 가장 큰 영향을 미쳤다.

누가 짜더라도 대체로 비슷한 코드가 나오는 코드 예외성이 적은점은 인터넷 검색으로 자료를 찾을 때 매우 좋다. 고수가 짠 소스 코드든 아니든 상관없다. 파이썬으로 문제를 해결하는 방법은 거의 비슷하여 초보자가 공부하고 자리잡기 좋다. 성향이나 취향이 이유겠지만, 난 루비스러운 코드를 짜기 위해 정작 루비 언어 철학을(인간 중심 프로그래밍?) 위배하는 코드들이나, 문제를 해결하는 다양한 방법을 언어 철학으로 삼는 펄(perl)의 암호같은 코드는 초보자가 공부하기에 썩 좋지 않다고 생각한다.

이렇듯 파이썬과 django는 초보자가 다루기에도 좋고 초기 시연판(prototype)을 만들기에도 아주 좋다. 파이썬이라는 언어가 가진 가볍고 간단함, 그리고 django 가 가진 가벼움과 명료함을 버무리면 장난감 만들기 정말 좋은 환경이 탄생한다. 물론 대형 서비스에서도 쓸 수 있겠지만, 내가 그런 서비스를 직접 개발하진 않으니 무어라 말을 할 순 없다. ^^;

jQuery

jQuery는 prototype javascript framework 못지 않게 많은 인기와 사랑을 받고 있는 Javascript framework 이다. 조금 써보니 정말 강력하고 편해서 꽤 많이 만져온 prototype js 로 돌아가고 싶지 않을 지경이다.

jQuery 장점은 강력한 기능이나 성능을 들 수 있다. 기능은 워낙 많은데다 부족하거나 없는 기능은 확장기능(plug ins) 형태로 보충할 수 있다. 손이 많이 들어가는 귀찮은 작업들을 이미 다양한 확장기능으로 만들어 제공하고 있다. 기능이 많으면 덩치가 커서 느리거나 둔하지 않을까 걱정이 될 수도 있지만, jQuery의 많은 부분들이 prototype js 를 성능으로 제치고 있으며, 높은 성능으로 유명한 dojo 나 extjs 와 비교를 해도 크게 뒤처지지 않는다.

뿐만 아니라 jQuery 소스 코드를 보면 주석이 정말 잘 달려 있어서 Javascript 에 깊게 파고 들어 공부할 사람에게도 많은 도움을 준다. 나처럼 의심 많은 사람은 대체 이건 내부에서 어떻게 돌아갈까? 생각을 하며 내부 소스를 들여다 보는데, 친절하게도 코드 대부분에 주석이 달려 있어 조금만 시간을 들이면 흐름을 이해할 수 있다.

일관성 있는 문법도 마음에 든다. prototype js를 보면 어떤 것은 객체여서 생성 할당(instance)을 해야 하고, 어떤 것은 함수라서 바로 실행이 가능하다. 또한, 각 기능부(component)가 별도 객체처럼 나뉘어져 있어서 혹 같은 이름을 쓰는 기능부가 있는 라이브러리를 쓸 경우 충돌을 일으키거나 혹은 이것이 prototype js의 것인지 아닌지 구분하기가 까다롭다. 그에 반해 jQuery 는 jQuery 라는 이름으로 대동단결 되어 있다.

간단히 예를 들자. hannal 이라는 엘레먼트를 마우스로 끌어다 놓을 수 있는 조작(control) 기능을 제공한다고 치자(prototype js 와 jquery 둘다 그런 기능을 제공하는 확장기능을 써야 한다). prototype 은

new Draggable(‘hannal’);

이런 식이다. jquery는

$(‘#hannal’).draggable();

이렇다. 기능부 쪼개는 장점을 이해 못하는 것은 아니나, 어떤 일을 하려는 대상인 객체(object)를 기준으로 코드를 구현하는 jQuery의 문법이나 코드가 좀 더 일관성 있다.

아쉬운 점은 자료 대다수가 영문이라는 점이다. jquery.com 에서 제공하는 문서들과 예제들이 워낙 잘 되어 있어서 굳이 강좌같은 연재글이 아니더라도 쓰는 데 불편함은 없지만, 기본부터 차근 차근 익히고 싶은 사람에겐 우리말/글 자료가 별로 없는 점은 아쉽다. 하지만 최근에 인사이트 출판사에서 jQuery in Action 번역서를 출간해서, 가뭄에 단비를 내려주고 있다. jQuery를 쓰고 싶은데 영어가 부담되던 이라면 꼭 이 책을 사서 접하길 권한다.

두 번째 아쉬운 점은 장점이기도 한데, 상당히 빠른 판올림을 들 수 있다. 빠른 판올림 때문에 예전에 코드가 문제를 일으킬 가능성이 좀 있다. 실 예를 들면, jQuery in Action 원서는 jQuery 1.2.1판을 기준으로 쓰여져 있는데, 1.2.1판에는 jQuery 선택자(selector)에 contains 라는 메소드(method)가 있지만, jQuery 최신판인 1.2.6판에서는 이것이 메소드가 아닌 필터(filter)가 되어 해당 메소드가 존재하지 않는다. 하지만 번역서에서는 옮긴이께서 보완하셨다고 한다. 만세~

이외 jQuery에 대한 얘기(특히 prototype js와 비교하는 얘기)는 내가 Prototype에서 jQuery로 옮긴 이유라는 글을 보길 권한다. jQuery 특징을 잘 나타내고 있다.

예전 같으면 정말 손이 많이 가는데다 성능도 보장되지 않아 지레 포기하던 많은 것들을 요즘엔 django 와 jQuery 를 이용해서 아주 편하고 간편하게, 그것도 어느 정도 성능이 보장되는 환경에서 처리하고 있다. 물론 이 둘이 아니더라도 php 나 ruby 언어를 서버 환경으로, 그리고 dojo 나 prototype js 등을 클라이언트 환경으로 하여 성능과 편리함을 취할 수 있다.

이들 모두 개성있는 좋은 도구들이다. 하지만 이런 저런 장난감을 다양한 도구로(php(cakephp), ruby(rails), python(django, turbogears), prototype js, yui, jQuery) 만들어보고 만져본 느낌은 나한텐 역시 django 와 jQuery 가 짱이라는 것이다. ^^

덧쓰기 : 당연한 말이지만 이는 어디까지나 개인 성향과 취향에 따라 다르다.

몇 년 동안 내버려두듯 손 보지 않았던 한날의 보금자리, 그러니까 내가 운영하는 블로그들 공간의 대문 역할을 하는 첫 화면을 어제 살짝 손 봤다. 분명 내 머리 속에는 매우 깔끔하고 삼삼했는데 정작 만들고 보니 우중충하기 이를 데 없다.

또, 이 블로그와 한날은 생각한다 블로그에도 약간 변화를 줬는데 “한날의 보금자리”에 있는 블로그들을 이동할 수 있는 길라잡이 막대를 만들어 넣었다. 역시나 우중충하다. 실은 더 우중충했다가 여자 친구 구박을 받고 한.결. 화면과 어울리게 손 본 것이 저렇다.

나도 예쁘고 화사한 빛깔, 구성을 만들어내고 싶다.

파이썬 쟁고(장고)와 루비 레일즈

프로그래밍을 취미로 즐긴다. 그런 성향에 비추었을 때 가장 손에 잘 맞는 프로그래밍 언어는 파이썬(python)이다. 여러 프로그래밍 언어를 다룰 줄 알지만 파이썬을 가장 좋아한다. 내공이 얕아서 내가 파이썬을 좋아하는 이유를 말하는 걸 듣는 것만으로도 그 매력에 취해 글 한 줄 한 줄 따르다보니 어느 덧 듣던 이들 모두가 파이썬 프로그래머가 되어 있는 마술을 부릴 수 없는 것이 안타까울 따름이다.

장고(쟁고, django)는 파이썬 진영에서 각광 받고 있는 웹 프레임워크로 나 역시 꽤 좋아한다. 지금도 쓰고 있고 앞으로도 장난감 만들 때 쓸 것이다. 장고를 처음 접한 계기는 RoR로 불리는 레일즈 웹프레임워크를 접한 것이 계기였다. 매력을 느끼긴 했는데 루비라는 언어 자체에 끌리질 않아서 별 관심을 안가졌다.

아마도 오늘 집에 가면 노트북에 RoR 꾸러미를 깔고 hello world 를 뿌려볼 것이다. 오늘부터 공부하기로 마음 먹었다. 길게 보지 않고 집에 달랑 한 권 있는 RoR 책인 웹 개발 2.0 루비 온 레일스를 2주 안에 마칠 생각이다. 잘 될까?

C#

사실 RoR 보다는 C# 공부를 먼저 하고 싶다.

환경 변화

세상이 참 빨리 변해서 따라가기 참 힘들다는 생각이 든다. 이름을 정말 기억 못하기도 하지만, 나날이 새로 선뵈는 이름과 낱말들이 매 끼니 밥알만큼 많은 것 같다. 관심사를 좁히고 좁혀 이 정도까지 좁혔는데도 벅차다. 어째야 할까. 더 좁혀야 하나, 아니면 더 넓혀야 하나. 아니면 지금 것에 충실할까.

쉽지 않다.

python 은 2001년에 처음 접했다. 하지만 조금만 말실수(syntax error)를 하면 버럭 화를 내는(500 Internal server error) 예민한 성격이어서 곧 떠났다.

다시 python 으로 cgi 프로그래밍 하는 데 관심을 가진 건 유들 유들하고 성격 좋아 보이는 Rails (RoR 로 유명한 그 처자)를 대산님, 만박님, 코디안님을 통해 알게 된 어느 날이었다. 하지만 Java와 마찬가지로 Ruby라는 처자에 도무지 정이 가지 않았다. 왠지 뚱뚱해 보이는 몸짓도 마음에 들지 않았고, 말하는 것도(문법) 사람 약 올리는 느낌이었다. (마치 문법이 “핵꺼등녀?”, “댁꺼등?” 이라는 말투 같달까)

그래도 Rails의 성격에 자꾸 눈길이 갔다. 그래서 Rails 와 비슷한 성격을 가진 다른 처자들을 찾아 나섰고, php에선 cakephp가, python에선 django 가 비슷한 성격을 가졌다는 정보를 접했다. 발그레 미소 지으며 수줍게 말을 거니 딱히 까탈스럽게 굴지 않고 대답을 해주었다. “hello hannal”(hello world)라고…

2007년 도쿄市에서 무더운 여름을 나던 난 그렇게 django 처자와 인연을 시작했다.

내 취미는 기획이다. 밥벌이 역시 기획이다. 심지어 똥도 기획해서 누곤 한다. 99년부터 2007년 상반기까지는 게임 기획을 해왔고, 그 이후로는 웹 기획을 하고 있다. 그런데 오지랖 넓은 호기심 탓에 이것 저것 많이 건드렸다. 그림을 그리던 때도 있었고 음악을 짜던(?) 때도, 그리고 당장 쌀 살 돈이 없어 급한대로 웹 프로그래밍 외주를 한 적도 있다.

그래도 내 본업은 기획이다. 본업이 아닌 일엔 깊이 파고 들지 않는다. 아니, 그 일에만 파고 들지를 못한다. 얕고 넓게 여러 가지를 접하고 대하며 그러다 보면 자연스레 조금씩 깊어지곤 하지만, 일부로 깊게 파고 들지 않는다. 난 내 분수를 알고 주제를 안다. 그래서 되도록 각 분야 담당자나 전문가에게 까불지 않는다.

강좌 하나 쓰려 한다. 까불지 않는다면서 감히 프로그래밍쪽 강좌를 쓰려 한다. 이름하여 “날로 먹는 Django 웹 프로그래밍”이다.

이 강좌 역시 시건방지게 똥꼬에 주름 접으며 방귀 뽕뽕 낄 계획은 없다. 전문성과 깊이를 담은 지식과 정보를 널리 퍼뜨리는 것이 목적이라기 보다는, 새내기나 웹 기획자들에게 길라잡이 역할만 하려 한다. Django가 Python 이라는 프로그래밍 언어를 기반으로 하는데 Python 을 모른다고 해서 걱정할 필요는 없다. Python 문법 설명도 틈틈히 간단하게 다룰 것이며, 굳이 Python을 모르더라도 흘러가는 논리만 이해하면 어려움 없이 따라 할 수 있다.

아, 물론 사이비가 잘못된 길로 이끌 수도 있는데 그건 각자 알아서 길을 바로 잡아가길 바란다. 그 정도 노력도 없이 어떤 분야를 바르고 깔끔하게 다 얻고자 하는 건 무임승차자 심보이고, 난 무임승차자를 싫어한다. ^^ (농담 반 진담 반)

잠깐, 웹 기획자라고? 어째서 웹 기획자를 대상으로 한다는 것이지?

사람 마다 생각이 다르겠지만, 난 기획자라면 기획을 빼고 다른 분야 중 하나 정도는 할 줄 알아야 한다고 생각한다. 그래픽이든 프로그래밍이든. 그걸로 먹고 살거나 그 분야 담당자/전문가와 맞장을 뜨기 위함도, 뜨내기 개발자 기죽이기 위해서도 아니다. 기획을 할 때엔 많은 경험과 정보가 “기획 삽질”을 줄여 준다. 겪어 본 이들은 알다시피 기획 삽질은 많은 사람들을 고통스럽게 한다. 이 강좌는 웹 기획자도 쉽게 웹 개발을 겪어서 관련 이해도를 높여 다른 분야 사람들을 덜 고통스럽게 하고, 결국 웹 기획자도 행복해지게 하기 위함이다. (그래도 기획자는 게으르고 꼭 핵심 내용 한 두 개쯤 빼먹는 문서나 만들어 대는, 그래서 스토리 보드나마 좀 제대로 만들어 줬으면 좋을 족속에서 벗어나긴 쉽지 않을 것 같다. ^^;)

이 강좌는 6월 1일에 시작해서 8월 중순 경에 끝날 예정이다. 1주일에 한 편씩 올릴 예정인데 짧지 않은 이 기간 동안 우리는 간단한 블로그를 만들 것이다. 어딘가에선 5분이나 10분 만에 블로그를 만든다는 걸 보면 이 강좌를 쓰는 한날이라는 사람 수준을 알 만 하다. 어쩔 수 없다. 내가 하수이니 손이 느리며, 이 강좌를 쓰는 나 역시 공부를 하며 강좌를 쓰기 때문에 더 느리다. 그런데도 감히 강좌를 쓸 용기를 갖는 것은 홀아비 마음 헤아릴 줄 아는 과부 같은 마음이라 하겠다.

우리나라에 우리말/글로 쓰여진 python + django 정보가 많지 않아서 아직 널리 알려지지 않았는데, 이 참에 많은 초보자들에게 도움이 되길 바라 본다. 2007년, 열심히 구글링하며 했던 아주 단순한 실수를 다른 사람들이 하지 않기도 바라 본다.

- 2008년 5월 23일, 한날.

• 저작권 : 이 강좌의 저작권은 한날에게 있으며, 무단 배포를 원하지 않습니다. 어떡해서든 도메인과 블로그를 지켜낼테니 안심하고 강좌를 주소 연결(link)만 하시기 바랍니다. 다른 이유가 있어서는 아니고 중간 중간 틀린 걸 고치거나 내용을 덧쓸 수 있는데, 무단으로 퍼가면 조금이라도 더 부족한 내용을 제가 제어 할 방법이 없습니다.
• 배포처 : 이 강좌 예고는 이곳에서 하지만, 실제 연재는 한날은 생각한다에서 합니다.
• 연락처 : iam 달팽이 hannal.net 으로 연락을 하시면 되며, 전자우편으로 질문은 받지 않습니다. 질문은 python 과 django 에 궁금한 점 물어보고 답하기에 댓글로 남기세요.

며칠 전에 구글에서 Google App Engine이라는 플랫폼을 공개했다. 소식을 접하자 마자 계정 신청을 했는데 오늘 계정이 활성화 됐다는 전자우편이 왔다. Google App Engine에 대해 보다 자세한 우리말 글을 보고 싶다면 likejazz님께서 쓰신 구글 웹 어플리케이션 플랫폼: App Engine 글을 참조 바란다.

2. 가볍게 둘러 본 느낌

난 방금 전에 Google App Engine (이하 GAE)에 예제를 따라 Hello world성 문장을 만들어 뿌려봤다. 마침 Django도 지원하길래 django를 이용해서 비슷한 일을 해봤다.

이리 저리 둘러 보고

• 이거 정말 짱이다
• GAE를 기반으로 하는 서비스가 많아지면 MS passport 서비스가 실패했던 것과는 달리 Google account(gmail)은 성공할 수 밖에 없다. Open ID보다 더 Open ID스러운 놈이 될 수도 있을 것이다
• 기획자나 작은 서비스 기업, 혹은 개발자(엔지니어 말고)들은 정말 신나겠다
• 역시 구글은 무섭다. GAE는 서비스 개발계의 Google Adsense가 될 것이다

이와 같은 느낌을 아주 강렬하게 받았다.

3. 좋은 점

요즘 개발 인트라넷으로 각광 받고 있는 도구는 Trac과 Subversion이라고 생각한다. 자료 판숫자(version)나 Wiki를 통한 문서 관리가 편하기 때문이다. 무엇보다 협업을 편리하고 안전하게 할 수 있다는 점이 아주 좋다. GAE 역시 이런 점이 잘 되어 있는 걸로 보인다. 잘 되어 있다고 확실하게 말을 하지 못하는 이유는 그런 기능이 보이기는 하지만 아직 제대로 실험을 하지 않았기 때문이고, svn 같은 것도 여전히 따로 필요해 보이기 때문이다.
하지만 소스를 갱신할 때마다 소스 판숫자를 자동으로 올릴 수 있다.

어렵고 골치 아픈 부분은 신경 쓰지 않고 서비스 개발 자체에 집중할 수 있는 환경도 좋은 점이다. 서비스가 잘 되어 확장을 해야 할 때, 개발 초기에 확장성을 고려하지 않으면 큰 고생을 한다. 그래서 개발 초기에 설계에 많은 시간을 들인다. GAE를 쓰면 이런 부분을 신경 쓸 일은 없을 듯 싶다. 서비스 확장을 할 때 Database Server와 Application Server를 주로 확장할텐데 이 두 부분을 GAE가 맡기 때문이다. 서버 뒷단에서 어떻게 분산을 하는지 신경 쓸 것 없이 나는 API로 자료를 꺼내 쓰거나 넣으면 된다.

아직 이용자가 많지 않아서 그런지는 몰라도 GAE 서비스 자체가 빠른 점도 좋다. 값싼 어지간한 웹호스팅 보다 훨씬 낫다. -_-;

SDK도 잘 만들어져 있다. Rails 나 Django가 그러하듯이 GAE SDK도 내장 웹서버가 있어서 GAE에 계정이 없더라도 개발 자체는 진행해 나갈 수 있다. 그리고 이 SDK 기반에서 잘 작동하면 GAE 위에서도 잘 돌아갈 확률이 높은 편이다. 왜 “높은 편”이라는 다소 불확실한 말을 썼냐하면, 아직 SDK 완성도가 완전치 않아서 개발 환경(내장 웹서버)에서 잘 작동하는 것이 GAE 안에서는 오류가 나는 경우가 있고, GAE에 소스 코드를 올릴 때 GAE가 소스 파일 일부 내용을 고치는지 개발 환경에서 뜨는 화면과 GAE 위에서 뜨는 화면이 달라지는 경우가 있는 듯 싶다. 대체로 python 경로(path)와 관련된 부분에서 그러한데, GAE에서 제공하는 문서를 보면 어렵지 않게 문제를 피할 수 있다.

이용자 인증 체계도 아주 쉽게 처리할 수 있다. The Users API 문서를 보면 알겠지만, Google account(Gmail)과 이용자 정보 기능을 연결해놨다. Google App Engine 을 기반으로 하는 서비스가 많아지면 많아질수록 gmail 계정 하나로 편리하게 서비스에 접근하여 쓸 수 있게 될 것이다. 이거 어디서 보던 개념 아닌가? 그렇다. 바로 Open ID이다. Open ID는 인증 체계만 덜렁 제공한다면, GAE는 인증 체계와 더불어 Application을 편하게 만드는 환경까지 제공하는 것이다. 정말 기가 막히고 무섭다.

마지막으로 나한테 좋은 점은 (현재) 쓸 수 있는 개발 언어가 python인 점이다. 난 python을 좋아하기 때문이다.

4. GAE 안쪽 살펴보기

우선 처음 가면 Application을 만들라고 나온다. 현재는 이용자당 3개를 만들 수 있으며 한 번 만든 Application은 지우거나 ID를 고칠 수 없다.

Dashboard에는 각 Application(Service) 관련 로그들이 나온다. 서비스 감시 및 현황을 파악할 때 좋을 것이다.

내가 마음에 들어했던 부분은 바로 로그 보기 기능이다. 총 7가지에 로그를 볼 수 있다.

• debug log line
• An info log line
• A warning log line
• An error log line
• A critical log line (most severe)

크흑. 정말 기가 막히지 않은가!

Google Account를 가진 이용자에 한해서 개발에 참여시킬 수 있다. Google apps를 통해 계정을 만든 이용자도 참여가 가능하긴 한데 몇 가지 문제가 있어서 깔끔하게 되지 않는다. gmail.com 계정을 초대하고 참여하는 것이 명랑한 삶을 사는 데 도움이 될 것 같다.

당연히 있을 법한 기능 중 하나는 GAE에 올린 서비스에 도메인을 따로 붙일 수 있는 것이다. 이 기능은 Google apps를 통해야 한다.

Google Apps 관리자 화면에 가면 아마 GAE 관련 서비스 추가 항목이 없을 것이다. 그럴 경우 위 그림과 같이 도메인 설정 영역 중 제어판에서 “다음 세대”라는 항목을 적용해야 한다. 그러면

이와 같은 도메인 연결란이 생긴다. 예를 들면 http://hello-hannal.appspot.com에 http://helloworld.hannal.com을 연결한 것이다.

5. 실제로 Hello world 찍어보기

여기서는 GAE에 hello world를 출력하는 과정을 보이는 것이 목적이지 python이나 django 강의를 하는 건 아니다.

5-1. 어플리케이션 생성

우선 GAE SDK 디렉토리 안에 GAE에 추가한 Application 디렉토리(폴더)를 하나 만든다. GAE에 만든 Application ID와 꼭 같을 필요는 없다. 근데 여기서는 Django를 이용할 것이므로 django-admin.py 을 이용해 만들기로 하자.

django-admin.py startproject uw

그러면 uw라는 디렉토리가 생기고 django 관련 기본 파일들이 만들어져 있다. 왜 helloworld가 아니라 uw인가하면 별 뜻 없다. hello world가 지겨워서 unlimited world라고 하고 싶었기 때문이다.

이제 app.yaml 파일을 uw 디렉토리 안에 만들고 다음 내용을 써넣는다.

application: uw
version: 1
runtime: python
api_version: 1

handlers:
- url: /.*
  script: main.py

YAML 설정에 대한 자세한 내용은 Configuring an App 문서를 참조 바란다.

보면 / 로 들어오는 모든 요청을 main.py 이 받게 했다. 이 main.py는 Running Django on Google App Engine 문서에 설명이 잘 나와있다. 다만 이 문서대로 하면 settings.py 에서 오류가 발생하는데 settings.py 맨 위에 import os 를 써넣으면 된다. 템플릿 경로 지정 문제 때문에 그런 것이다.

5-2. 화면 만들기

이번엔 / 로 들어왔을 때 보일 화면을 만들자. 간단하다. 우선 urls.py 에 접근 요청 경로와 이 경로에 연결할 함수를 정의한다.

urlpatterns = patterns('',
    (r'^$', 'views.root_page'),
    (r'^hannal/$', 'views.goto_hannal'),
)

난 아무 경로 없이 최상위 경로(/)로 왔을 때 views.root_page 를, /hannal로 왔을 때 views.goto_hannal을 실행하겠다고 했다.

이번엔 views.root_page 를 만들 차례이다. 취향에 따라 views.py 안에 각 함수를 만들어도 되고 views 디렉토리 안에 root_page.py 나 goto_hannal.py 파일을 만들어도 되지만, 난 views.py 안에 각 함수를 만들기로 했다.

urls.py 나 settings.py 파일이 있는 곳에 views.py 를 만든 뒤 다음과 같이 내용을 만든다.

# -*- coding:utf-8 -*-
from django.http import HttpResponse, HttpResponseRedirect
import django

def root_page(request):
    str = '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd">'
    str += '<html>'
    str += '<head><title></title><meta http-equiv="content-type" content="text/html; charset=utf-8"/></head>'
    str += '<body>'
    str += '<p>안녕하세요, 여러분.  이 화면은 '
    str += '<a href="http://www.djangoproject.com">Django %s.%s</a>로 만들었고, '  % (django.VERSION[0],django.VERSION[1])
    str += '<a href="http://appengine.google.com">Google App Engine</a>에서 '
    str += '돌리고 있답니다.</p>'
    str += '</body></html>'

    return HttpResponse(str, mimetype='text/html')

def goto_hannal(request):
    return HttpResponseRedirect('http://www.hannal.net')

5-3. 소스 반영 및 확인

이제 appcfg.py 를 이용하여 소스를 GAE 서버에 올린다. 처음 실행하면 gmail 계정 인증을 요청하고, 이후엔 .appcfg_cookies 파일을 만들어 인증을 생략한다.

다 올린 뒤 http://uw.appspot.com에 접속하면 화면이 잘 나온다. http://uw.appspot.com/hannal로 접속하면 http://www.hannal.net 로 이동한다.

6. 글을 마치며

기대보다 훨씬 재밌고 끝내주는 서비스, 아니 플랫폼이 등장했다. 시장에 미칠 파급력이 엄청날 것이라고 본다. 기획자도, 소프트웨어 엔지니어가 없거나 경험이 없어 서비스 확장 구조 설계에 어려움을 겪는 작은 팀이나 회사도 모두 매력을 느낄 개발 플랫폼이다.

그나저나 이런 것 나왔으니 가벼운 말로 꺼낸 django 개발 책을 정말 써야 하는 걸까? ^^

unknown encoding: X-MAC-KOREAN

위와 같은 문자열이 들어간 오류 화면이 뜹니다. 저는 맥 언어 환경을 우리말로 했기 때문에 X-MAC-KOREAN 이라고 뜨는 것이죠.

이것은 Django에 있는 tzinfo.py (timezone 정보 관리하는 역할)가 기본 locale 을 가져와서 그럴싸한 문자열을 만들려 하기 때문에 맥 환경에서 발생하는 문제입니다. 이게 0.97 언제쯤 고쳐질지는 모르겠으니 일단 아쉬운대로 고쳐서 써봅시다. (음냐. 이러면 svn update 할 때 conflict 뜨는데 그 해결은 알아서 하세요)

대상 소스 파일 : django/utils/tzinfo.py

위 파일을 열면

try:
    DEFAULT_ENCODING = locale.getdefaultlocale()[1] or 'ascii'
except:
    # Any problems at all determining the locale and we fallback. See #5846.
    DEFAULT_ENCODING = 'ascii'

이런 부분이 나옵니다. 소스 파일 안에서 거의 맨 위에 있지요. 여기서 문제가 되는 부분이 바로 try 안에 있는 녀석입니다. 맥에서는 저걸 실행하면 X-MAC-뭐시기라고 가져옵니다. 그런 게 없으니 오류가 나는 것이고요. 그 아래에 DEFAULT_ENCODING = ‘utf-8′을 넣어주면 오류 안납니다.

try:
    DEFAULT_ENCODING = locale.getdefaultlocale()[1] or 'ascii'
    DEFAULT_ENCODING = 'utf-8'
except:
    # Any problems at all determining the locale and we fallback. See #5846.
    DEFAULT_ENCODING = 'ascii'

이러면 django의 디버깅 화면이 잘 나옵니다. 찝찝하면 DEFAULT_ENCODING = locale.getdefaultlocale()[1] or ‘ascii’ 를 주석으로 하세요.

여기서 교훈 한 마디. 역시 시험판, 특히 미리맛보기판(pre version)은 안쓰는게 정신 건강에 좋다.

지난 1월 16일부터 제 블로그에 공익 광고를 달았고, 어느 덧 두 달이 지났습니다. 총 401만원 수익이 났고, 전액을 기부했습니다. 손수 광고를 클릭하시어 적잖은 돈을 기부할 수 있게 도와주신 많은 분들께 고맙다는 인사 올립니다.

2. 게임 같은 인연 찾기 SNS

지난 해 7월에 TNC에 입사한 이래 새로운 프로젝트에 매달려 왔는데 마침내 공개합니다. 게임 기획자가 뜬금없이 웹 기획자로 변신한 데에는 다 이유가 있지요. 그간 인터넷 관련 모임에 나가면 Web 2.0과 비유하며 Game 2.0을 만들어 내겠다고 말해왔습니다. 이 이야기에 흥미를 가지셨던 Chester님께서 함께 일해보자는 제의를 하셨고, 마침내 9개여월 만에 프로젝트를 1차 완료 했습니다.

이 자리를 빌어 소개합니다. 기존 Social Networking Service에 게임 같은 놀이 요소를 넣은 새로운 인연 찾기 서비스인 단추닷컴입니다. 서로의 인연이 서로 엮인다는 뜻을 가진 이름입니다.

서비스 가입도 Web 2.0 시대에 맞게 구성했습니다. 4월 1일부터 아침 무가지 신문들 마다 작은 단추가 첨부되어 있는데 이 단추 뒷면에 고유한 일련번호가 있습니다. 이 번호로 가입하시면 됩니다.

덧쓰기 : 현재 가입자 폭주로 잠시 서비스가 뻗었네요. 얼른 복구하겠습니다. ㅜㅜ

3. 청혼

지난 3월 27일은 제 여자 친구 생일이었습니다. 먼거리 연애를 하고 있는데 모처럼 만나서 즐거운 시간을 보냈습니다. 그리고 청혼을 했습니다. ^^ 대답은? 물론 허락이지요! 조만간 좋은 소식 올리겠습니다.

4. 국내 최초 Django 서적 출판

최근 RoR이라고 해서 Ruby라는 프로그래밍 언어를 기반으로 하는 Rails라는 웹 프레임워크가 인기를 끌고 있습니다. Python 진영에는 Rails 못지 않은 인기를 누리고 있는 웹 프레임워크로 Django가 있습니다. 저는 지난 해부터 본격 Django를 써왔는데, 에어콘 출판사에서 제의가 와서 책을 써왔습니다. 제가 알기론 국내 저서로 Python + Django 책은 제 책이 최초입니다.

잠정 확정한 책 이름은 기획자의, 기획자를 위한, 기획자에 의한 Django 웹 개발입니다.

5. 국가도덕지수 소식

실천력 강한 NGO 중 하나인 세계 도덕 확산 기구에서 발표한 2007 국가도덕지수에서 우리나라가 AB+를 획득하여 2위를 했다고 합니다. 1위는 AA-를 획득한 중국이, 3위는 AC+를 획득한 미국이 차지했다고 하네요.

다만, 2007년 조사에서 우리나라 대선 과정은 반영되지 않았으며 이 내용이 반영되는 2008년에서는 다소 순위가 떨어질 것으로 예상되나, 최근 중국의 티베트 무력 침공이 있어서 2위를 유지할 가능성이 높게 점쳐지고 있습니다.

6. 마지막 소식

.
.
.
.
.
.

이상으로 2008년 만우절을 맞이하여 제 희망 소식을 나열해 봤습니다. ^^ 다 이뤄졌으면 좋겠네요.

아참, 낚이셨거나 피식 미소 한 번 지으셨다면 댓글 하나 부탁합니다. 굽신 굽신.

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 접속 기능을 쓸만큼 규모가 큰 웹 서비스를 개발할 일은 없으니까)

DB Model

기존엔 문자열 최대 길이를 지정할 때 maxlength 라는 예약어를 썼는데 0.96.1부터는 max_length를 씁니다.

class Entries(models.Model):
	me2permalink = models.CharField(max_length=250, null=False)
	content = models.TextField(max_length=150, null=True)
	comment_count = models.SmallIntegerField(default=0, null=True)
	voted = models.SmallIntegerField(default=0, null=True)
	reg_date = models.DateTimeField(auto_now_add=True)
	channel = models.SmallIntegerField(default=1, null=False)

위 예제는 미투데이용 그림자놀이에서 쓰고 있는 글 저장 테이블.

i18n에서 ugettext 오류

0.96.1에선 ugettext 가 빠졌습니다. 그냥 gettext를 쓰면 됩니다. 어차피 python 자체도 unicode 기반으로 돌아가는데 ugettext가 좀 무의미하긴 했죠.

from django.utils.translation import gettext as _

HttpResponse에서 content_type

HttpResponse로 문자열을 뿌릴 때 content_type=’text/javascript’ 이런 식으로 content_type을 쓰면 안됩니다. 0.96.1부터 없어졌기 때문이죠. 원래 있던 mimetype만 쓰면 됩니다.

HttpResponse(ret_data, mimetype='text/javascript')

template tag로 문자열 넘길 때 utf-8 문제

django에서 템플릿 태그를 만들어서 쓰고 있습니다. 문자열을 넘기면 일부를 잘라다 출력합니다.

{{comment.entry.content|cutstring:20}}

이러면 comment.entry.content 에 들어가 있는 문자열을 내가 만든 cutstring이라는 함수로 넘깁니다. 이 함수는 이렇게 생겼습니다.

def cutstring(value, length):
	if len(value) > length:
		return value[0:length] + '...'
	return value
cutstring = stringfilter(cutstring)

보시다시피 아주 간단하죠. 근데 0.96.1로 판올림을 하니까 value로 넘겨 받은 문자가 utf-8가 아니라 ascii였습니다. 언제나 그런 것도 아니고 어떨 때는 unicode로 넘기고 어떨 때는 ascii. -_-; 이 둘 큰 차이점은 ascii는 위와 같이 문자열을 자를 때 byte 단위로 자르고, unicode는 글자 단위로 자르는 데 있습니다. 이때문에

s1 = '안녕? 반가워'
s2 = u'안녕? 반가워'

라고 하고, s1[0:5] 라고 하면 ‘안녕?’이 나오고, s2[0:5]라고 하면 ‘안녕? 반’이 나옵니다.

실제로 utf-8로 처리 됐으면 ‘나만의 (자칭 귀여운) 강박증. 걸을’ 이라고 잘려야 할 문자열이 ascii로 되면서 ‘나만의 (자칭 �’라고 잘렸습니다.

이런 경우 문서에서는 force_unicode()를 쓰라고 하지만, svn이나 웹으로 받은 django 0.96.1 어디에도 저런 놈은 없었습니다. 문서대로라면 django/utils/encode.py 에 있어야 하는데, 0.96.1엔 없고 0.97 pre판부터 django/utils/encoding.py 에 있습니다.

결국, 강제로 unicode로 문자열을 바꿔서 해결했습니다.

def cutstring(value, length):
	if type(value) != 'unicode':
		value = unicode(value, 'utf-8')
	if len(value) > length:
		return value[0:length] + '...'
	return value
cutstring = stringfilter(cutstring)

단, 0.97 pre판부터는 위와 같이 하면 unicode는 지원하지 않는다며 오류가 납니다. 이때에는 value = unicode(value, ‘utf-8′) 이라고 하지 말고 value = force_unicode(value)이라고 해야 합니다. 이런 식으로 처리하면 되겠죠. (start_unicode 같은 애들도 있는데, 각 각의 차이점은 Unicode data in Django (공식 문서)를 참조하세요.)

import django
if django.VERSION[0] == 0 and django.VERSION[1] >= 97:
    from django.utils.encoding import force_unicode

def cutstring(value, length):
	if type(value) != 'unicode':
            if django.VERSION[0] == 0 and django.VERSION[1] < 97:
		value = unicode(value, 'utf-8')
            else:
                value = force_unicode(value)

	if len(value) > length:
		return value[0:length] + '...'
	return value
cutstring = stringfilter(cutstring)

아참. 넘어오는 문자열이 혹시 utf-8가 아니라 euc-kr 같은 것이라면 unicode(value, ‘utf-8′) 가 아니라 unicode(value, ‘euc-kr’) 이라고 해야 합니다..

해결 방법은 두 가지입니다. 원래 깔려 있는 gettext를 최신판으로 판올림 하거나 혹은 django 에서 문제가 되는 부분을 피해가는 겁니다.

1. django에서 문제가 되는 부분을 피해가는 방법

gettext 판올림이 귀찮다면 django 에 있는 문제만 피해가면 됩니다. 우선 gettext 0.10 에서는 확실히 오류가 발생합니다.

po 파일을 생성하는 make-messages.py 을 실행하면

`Python’ unknown’

이런 오류가 납니다. 이건 직접 po 파일을 만들면 그만입니다. (make-messages.py 가 편하긴 합니다)

두 번째는 po 파일을 mo 파일로 변환하는 compile-messages.py 를 실행하면

$ /usr/lib/python2.5/site-packages/django/bin/compile-messages.py
processing file django.po in /생략/locale/ko/LC_MESSAGES
msgfmt: unrecognized option `–check-format’
Try `msgfmt –help’ for more information.

굵게 표시한 내용으로 오류가 발생합니다.

msgfmt 을 이용하여 파일을 변환하려는데 –check-format 이라는 알 수 없는 매개변수를 썼다며 실행이 취소된 겁니다. msgfmt –help 이라고 쳐보면 실제로 존재하지 않고 -c 라는 놈이 존재합니다. 그러므로 compile-messages.py 안에서 저 부분을 고치면 됩니다.

이 파일은 django설치된경로/bin/compile-messages.py 에 있으며, 파일을 열어서 cmd = ‘msgfmt –check-format -o “$djangocompilemo” “$djangocompilepo”‘ 이렇게 된 부분에서 –check-format 을 -c 로 바꾸십시오. 그러면 잘 변환되어 작동합니다.

2. gettext 판올림

이건 gettext 를 0.12 이상으로 판올림하면 위 두 문제 모두 해결됩니다. 전 DarwinPorts 라는 놈으로 처리했습니다. DarwinPorts를 설치한 뒤에 터미널에서

sudo port install gettext

이라고 치면 gettext 최신판을 받아다가 설치합니다.