이 블로그에도 굉~장히 많이 늦었지만 subversion 소스 트리를 사용하기로 하였다. 지뢰밭이나 다름없는 trunk는 이미 별도 테스트용으로 블로그를 만들어놓고 있으니, 이곳은 정식 배포를 위한 버전들을 관리하는 branches의 최신 버전용 소스 트리를 이용하기로 하였다. 즉, 앞으로 정식 배포를 위해 대기 중인 버전에서 문제가 발견되었을 때 이 블로그에서 재현된다면 여기서 바로 고쳐서 반영할 수 있게 되었다는 이야기고, 또한 새로운 버전으로 보다 쉽게 갈아탈 수 있게 된 것이기도 하다.

요즘 텍스트큐브 API 서비스--원하는 사람은 있지만 수요가 적어서 기업들이 하지 않는 그런 종류 + 공공성을 지닌 것들을 모아서, 각 블로그에 부하를 주기에 부담스러울 때 텍스트큐브 플러그인 형태로 중앙 서버에서 받아오는 서비스--를 개발하기 위해 CakePHP를 써보면서, 텍스트큐브 2.0 프레임웍은 절대 이런 느낌이 나지 않게(!) 해야 겠다는 생각을 하고 있다. -_-;

그 유명한 Ruby on Rails는 사실 설치조차 해본 적이 없고(ruby 언어만 조금 깨작거려봤다), Django가 나한테는 처음으로 제대로 써본 웹프레임웍이다. 0.96과 1.0 사이의 긴 기간 동안 개발 버전을 쓰면서 문서화가 덜 되어 있는 관계로 직접 소스코드를 뜯어보기도 하는 등의 불편함이 조금 있었지만, Python 언어 자체가 워낙 깔끔하고 특히 코딩스타일이 거의 똑같이 나올 수밖에 없게 되어 있어 프레임웍 소스를 이해하는 데 시간이 얼마 걸리지 않았다. 또한 프레임웍은 거의 라이브러리 같은 느낌으로 내가 필요하면 불러다(from django.x import y) 쓰면 되는 것이고, 프레임웍의 틀에 맞춰서 짜야 하는 부분은 url routing하는 것, db 연결을 위한 환경설정, view handler¹ 함수가 존재하게 하는 것뿐이었다.

그런데 CakePHP를 써보니, 일단 view 템플릿이 있어야만 controller가 동작했고 이 템플릿은 HTML을 기본 가정으로 깔고 있어서 디버그용 모드에서는 자동으로 request 수행 시간을 나타내는 HTML 주석이 붙는다. 문제는 동적으로 생성할 json 응답과 같은 곳에서도 붙기 때문에 이때는 강제로 디버그 모드를 꺼줘야 한다든지 하는 것이 일단 가장 처음에 했던 삽질이고, 하나의 컨트롤러 메소드에서 여러 형식(XML, JSON 등등)으로 출력을 낼 수 있게 하려고 각각마다 템플릿 파일명을 다르게 하려고 했더니, 기본 템플릿 파일이 없다면서 404 Not Found 에러가 뜬다든지 하는 것 또한 골때렸다.;; 게다가 DB 스키마도 직접 생성해주어야 했다. (뭐 경우에 따라 이건 장점일수도.)

사실 이런 기본 동작들을 재정의하거나 별도의 옵션 변수를 두거나 뭐 이런 식으로 해결할 수는 있긴 한데(혹자는 이걸 장점으로 표현하기도-_-), 문제는 Python에서, Django에서 할 수 있는 것보다 훨씬 귀찮고 더럽게 보인다는 점이다.

Model을 사용하는 것도 object와 record가 거의 1:1 매핑이 되는 Django와 달리 현재 컨트롤러의 인스턴스에 들어있는 모델 인스턴스 변수를 통해서 stateful하게 조작해야 하다보니 코드가 별로 깔끔하지 않았다. Django는 계속해서 model 부분은 재작성·리팩토링해왔기 때문에 지금은 상당히 복잡한 쿼리도 잘 추상화가 이루어져있기 때문에 대조적인 부분이라 할 수 있겠다.

CakePHP가 Django와 비교했을 때 가지는 장점이라면, 프레임웍을 다운받아서 압축 푼 디렉토리 자체에서 어플리케이션을 개발하고 이걸 다시 묶으면 그대로 배포 가능한 패키지가 된다는 것 정도인데, 이건 사실 프레임웍의 설계가 뛰어나서라기보다는 php 자체의 특성에 기인한 바가 크다. Python은 lib/site-packages라는 별도의 시스템 디렉토리에 각종 라이브러리와 모듈들을 넣고 이를 불러다 쓰는 방식이라면, php는 php 자체가 그냥 모든 기능을 함수로 다 가지고 있기 때문이다. 따라서 사실 배포용 프로그램을 만들 때 python이 좀더 고려해야 할 것이 많고, django의 경우도 웹호스팅에서 사용하려면 django가 사용하는 패키지들이 설치된 서버에서 fast-cgi로 돌리는 방법밖에 없다. 대신 Java와 같은 패키지 import 지시어가 있으므로 php처럼 autoload 함수를 작성하거나 일일이 include하지 않아도 되는 편리함이 있다.

사실, 현재 베타 단계인 PHP 5.3만 좀더 일찍 출시·대중화되었더라도 이런 불만의 많은 부분을 잠재울 수 있었을 것이다. namespace 지원, lambda 지원, static 메소드의 동적 바인딩 지원 등 이미 다른 OOP 언어에서는 기본적으로 지원되는 것들이 이제서야 도입되고 있기 때문이다. (하지만 수천개에 이르는 단일 네임스페이스 안의 기존 라이브러리 함수들은 어쩔;;...orz)

하여간 이래저래 웹프로그램을 가장 배포하기 편한 환경이 PHP이면서 제대로 된 규모있는 개발을 하기엔 가장 안 좋은 환경이 PHP이다보니 성가신 점이 많다. ㅠ_ㅠ