TNF Needlworks

Django Webframework

거의 한 달 가까이 이 블로그가 죽어있었습니다. 다시 시작하는 첫 타를 끊어봅니다. :)

제가 요즘 주로 쓰는 언어는 PHP가 아니라 Python입니다. 텍스트큐브 자체는 PHP로 만들어져 있지만 블로그가 아닌 좀더 일반적인 웹사이트를 만들 경우엔 그보다 자유도가 높은 CMS를 쓴다거나 자체 사이트 구축을 해야 하지요.

Needlworks 홈페이지와 Textcube 홈페이지를 만들면서 어떤 프로그래밍 언어와 어떤 툴(프레임웍 혹은 라이브러리)을 쓰는 것이 좋을까 생각하다가 Django[footnote]보통 "장고"라고 읽습니다.[/footnote]를 생각했습니다.

Django를 처음 알게 된 것은 작년 겨울에 동아리에서 한 후배(지금은 구글에서 인턴 중이지요.)가 세미나 형태로 15분만에 블로그 만들기-_-를 하면서부터였습니다. 제가 Python을 쓰기 시작한 것은 작년 초였고, Django를 접하기 전까지는 쉘스크립트 대용으로 쓰는 게 거의 전부였죠. (어떤 디렉토리 안에서 모든 하위 디렉토리와 파일을 돌며 인코딩 변환을 한다든가 하는 종류의 스크립트를 짤 때 썼습니다.)

Django를 보고 Python의 매력에 흠뻑 젖어들게 되었습니다. 아주 깔끔한 Object Relational Mapping, 자체적인 Template 시스템과 유연한 문법 체계, Python의 깔끔한 module namespace의 활용, lambda (anonymous function) 문법을 활용한 연산자와 오브젝트의 동적 생성, 그리고 Python이 제공하는 수많은 라이브러리를 자유자재로 활용할 수 있다는 점, Django에서 제공하는 방법이 아닌 다른 방법으로도 구현할 수 있게 자유도가 높고 중간중간 customizing을 위해 끼어들 여지를 많이 남겨둔 점 등이 마음에 들었지요.

사실 이 대부분은 Ruby와 Ruby on Rails에도 있는 특징들이긴 합니다만, Python에 이미 익숙해지기 시작한 터라 Django를 써보기로 했죠. Django가 다른 웹프레임웍에 비해 가지는 장점이라면 자체적인 Cache framework이 마련되어 있어 성능이 월등하다는 것 정도입니다.(...마는 아직 니들웍스나 텍스트큐브 홈페이지 자체가 별로 규모가 크지 않은지라 얼마나 좋은지는 잘 모르겠습니다..-_-) 아, 하나 더 좋은 점이라면 관리자 모드를 아주 깔끔하게 자동으로 만들어주기 때문에 웹개발시 가장 귀찮은 부분인 테스트 데이터 생성이 간편하다는 점도 있군요.

아직 Django가 국내에는 그다지 잘 알려지지 않은 프레임웍이라서, 제가 알기로는 국내 커뮤니티 같은 것이 전무합니다. 구글링해보면 몇몇 블로그에서 부분적으로 소개하거나 몇몇 컨퍼런스에서 이런 것이 있다 하고 소개된 정도지요. Django가 국내에 알려지게 된 결정적인 계기는 바로 The Django Book의 등장입니다. Django 그 자체보다도 출판될 책의 내용을 온라인에 미리 공개하고 문단별로 코멘트를 달 수 있도록 한 UI 덕분에 유명해졌지요.

Django 프로젝트 위키를 보면 꽤 많은 상용 사이트들이 이 프레임웍을 사용하고 있음을 알 수 있습니다. 하지만 제가 직접 써본 결과, 0.96 stable release 버전은 기능이 좀 부족하고 subversion 개발 버전은 개발 버전 치고는 상당히 안정적이기는 하나 드물게 이상한 버그가 발생하기도 합니다. (다행히 제가 만든 니들웍스/텍스트큐브 홈페이지는 아주 복잡한 기능을 쓰지는 않아서인지 별 문제 없습니다.) 텍스트큐브 홈페이지를 만들다보니 매뉴얼이 비교적 잘 나온 프레임웍임에도 결국 내부 소스를 들여다보지 않을 수 없더군요.; 약간의 삽질과 더불어 결국 몇몇 티켓을 올리거나 제가 관여한 패치가 반영되기도 했습니다. (제가 텍스트큐브 개발자인지 Django 개발자인지.... -_-)

현재 제가 있는 SPARCS 동아리에서는 CakePHP 및 JSP를 사용하려는 움직임과, Django 혹은 RoR을 사용하려는 움직임이 있습니다. 사람들이 취향이 다양해서 그런지 여러가지로 갈리고 있지만, 분명한 건 웹프레임웍의 필요성을 다들 절감하고 있다는 사실입니다. 동아리에서 운영하는 Ara 게시판과 수강지식인 LKIN[footnote]학교 외부에서는 접속이나 사용에 일부 제한이 있을 수 있습니다.[/footnote]의 소스코드를 보고 경악하지 않은 사람이 별로 없었지요. (....) 어찌어찌해서 돌아는 가고 있지만 소스코드는 완전 스파게티.. (....) 그래서 동아리 사람들 중에는 웹개발에 대해 부정적인(?) 이미지를 가진 사람들도 있었습니다.

웹개발이 과거처럼 단순 노가다 코딩이 되지 않기 위해서 웹프레임웍 도입이 절실합니다. 다만 웹프레임웍의 단점이라면 해당 프레임웍을 사용한 프로그램을 배포할 때 그 프레임웍이 같이 포함되든지 별도로 서버에 설치되어 있어야 한다는 것입니다. 그래서 일반 웹호스팅에서 사용하기는 어렵죠. (사실 과거에 태터툴즈를 Python으로 만들자는 의견이 나왔으나 성사되지 못한 것도 같은 맥락입니다. Python을 지원하는 곳이 많지 않고, 있더라도 Python에 MySQLDb나 sqlite adapter 같은 부가 패키지들이 같이 깔려있어야 하기 때문입니다.)

현재 텍스트큐브 2.0에서는 DB 백엔드를 싹 갈아치우려는 계획을 가지고 있습니다. (...다만 언제 될지가...OTL) Django처럼 자체적인 Object-relational mapper를 구현하고 이를 통해 lazy evaluation을 사용함으로써 SQL 쿼리 수를 줄이고 caching을 용이하게 할 생각입니다. PHP의 언어적인 제약이 얼마나 영향을 줄지는 아직 잘 모르겠네요. 하지만 일단 완료되기만 하면 MySQL 4.0 이전, MySQL 4.1/5.0 이상을 별도로 지원하여 성능을 크게 끌어올리고 DB 구조를 보다 고도화시킬 수 있으리라 생각합니다. 더 나아가서는 Oracle이나 MS-SQL 등에 대한 대비도 가능해지겠지요.

자아- 화이팅입니다 ㅠ_ㅠ;

필자

Daybreaker(아침놀)입니다. 현재 KAIST 전산학과에 재학 중이며 전산 외에도 물리, 음악, 건축 등에 관심이 많습니다. Needlworks 내에서는 각종 홈페이지 제작 및 서버 관리 등과 함께 Textcube 개발에 참여하고 있습니다.

홈페이지 : http://daybreaker.info

Django, Webframework, 웹, 웹개발, 웹프레임웍, 웹프로그래밍

(0)(2)