지난 금~토요일에는 무려 제주도를 다녀왔다. 원래는 NHN DeView 컨퍼런스를 가려고 일찌감치 등록까지 해놓은 상태였는데 니들웍스를 통해 다음커뮤니케이션 쪽에서 급히 연락이 와서 제주대학교에서 강의(...)를 하게 된 것이다. 다음에서 제주대학교에 오픈소스 개발방법론 강의를 개설했다는 소식은 예전부터 알고 있었지만, 실제로 내가 거기에 가게 될 줄은 전혀 몰랐다. 내가 맡은 부분은 실습 세션으로, 학생들이 기말프로젝트(...)로 텍스트큐브나 제로보드 쪽에 참여하도록 했기 때문에 좀더 익숙해질 수 있도록 도와주기 위한 것이었다.

그래서 가게 된 인원은 총 4명으로 TNF 리더이신 신정규님 외에 최호진님, 고재필님 그리고 나였다. 사전에 듣기로는 주로 3~4학년 컴퓨터공학 전공 학생들이 수강하는 수업이라고 했는데 그럼 나와 동갑이거나 한 살 많은 사람들을 두고 '초청 강사'로 강의를 하게 된 셈이다.;

'텍스트큐브 프로젝트에 참여해보기'라는 과제를 수행해야 하는 학생들을 두고 도대체 어떤 내용의 실습을 진행해야 하나 고민했는데, 결국은 플러그인에 대해 알려주는 쪽으로 결정했다. 텍스트큐브 코어 구조는 엄청난 내부 공사를 거치고 있는 중이라 1.8 버전을 거치며 크게 변할 것이기 때문에 지금 가르쳐준다고 해서 나중에 별로 도움이 될 것 같지는 않았고, 구조가 안 바뀐다고 하더라도 짧은 시간에 수만 줄에 이르는 방대한 코드의 구조를 파악하고 자기가 기여할 만한 부분까지 찾는다는 것은 쉽지 않은 일이기 때문이다. 따라서 정말 자기가 뭔가 '만지고 있다'라는 느낌을 주는 데 가장 적합한 것이 플러그인이라고 생각한 것이다. 혹시나 수업을 들은 학생들 중에 좀더 코어에 깊이 관여해보고 싶은 열정적인(...) 학생이 있었다면 조금 실망했을지도 모르겠다.

교통의 발달 덕분에 요즘엔 그런 큰 거리를 이동하는 것도 훨씬 쉬워진 것 같다. 제주공항에 내리자 우선 훨씬 따뜻하다는 것을 느낄 수 있었다. 전에도 제주도에는 2번이나 왔었지만 한겨울에도 길거리에 있는 푸른 잎들의 야자수를 보면 같은 나라인가 싶다. 택시를 타고 제주대학교로 향하는 길에 다음 글로벌미디어센터도 볼 수 있었는데, 입구에 노트북을 펼치고 앉아있는 돌하르방이 아주 폐인(...)스러워보이는 게 재밌었다;; 제주대학교는 약 해발 200미터 높이의 한라산 북쪽 자락의 경사진 땅에 지어져 있다. 우리가 강의할 건물은 위쪽의 새로 지은 새 건물이었는데, 강의하기 위해 3층인가 4층인가 올라가니 복도 전면 유리창으로 멀리 바다와 푸르른 초목이 보이는 것이 아주 가슴이 뻥 뚫리는 듯 시원했다. 공기도 좋고 전망도 끝내주는 이런 학교에서라면 왠지 공부가 더 잘 될 것 같은 느낌? ㅋㅋ

어쨌든 세미나와 수업은 무사히 끝났고, 초청강사로 강의한 것에 대한 증빙자료(?) 준비 때문인지 신분증 확인 후 수업을 들었던 10명 내외의 학생들과 다음의 윤석찬님과 함께 흑돼지 삼겹살로 저녁을 먹었다. 석찬님이 친히 구워주시는 고기를 먹으면서 이런저런 이야기를 했는데 나도 그렇고 재필님도 그렇고 아쉬워했던 것은 왜 카이스트나 포항공대에는 이런 수업이 없을까 하는 점이었다.

카이스트는 컴퓨터공학과가 아니라 전산학과이기 때문에 아무래도 이론의 비중이 좀더 높고 '프로그래밍 언어는 알아서 배워라' 식의 배짱이 있어서인지 SP와 OS 및 DB개론을 제외하고는 실무와 직접적으로 관련된 내용은 수업에서 거의 가르치지 않는다. (아마도 학생들 머리가 좋으니까 기초를 잘 가르쳐놓으면 알아서 잘 하겠지... 뭐 이런 생각인 것 같다) 하지만 오픈소스 개발은 소위 전통적인 소프트웨어공학으로 달성하지 못한 다른 방향을 보여주고 있기도 하고, 어렸을 때부터 프로그래밍을 접해보지 않은 학생들이 전산과에 왔을 때 겪는 어려움을 극복할 수 있도록 흥미와 동기를 유발하는 효과도 있기 때문에 나는 카이스트에서도 이런 수업을 적극적으로 제공해야 한다고 생각한다.

한 가지 재밌었던 것은 그곳 학생들도 문제의 소프트웨어공학개론 덕분에 꽤나 고생한 경험이 있더라는 것. UML 다이어그램으로 점철된 300장짜리 보고서 이야기를 해주니 '역시...'라며 다들 끄덕끄덕. -_-;;; 윤석찬님께서는 이미 전통적인 개발방법론을 지나 오픈소스를 모델로 하는 방법론들이 연구되어 있고 기업에서도 이를 많이 도입하고 있다면서 학교에서도 그런 방향의 교육이 있으면 더 좋겠다는 말씀을 해주셨다.

저녁 먹고 학생들과 헤어진 후 어둑해진 해안으로 나가 고등학교 수학여행 시절에 보았던 용연과 용두암 야경을 보며 산책한 후 다음 쪽에서 제공한 숙소인 그랜드호텔로 갔다. (나중에 알고보니 여기가 우리 부모님 신혼여행 숙소였다고 한다. -_-) 1층 커피샵에서 윤석찬님과 함께 좀더 심도있는 여러 이야기들을 나눌 수 있었다.

프론트에 물어보니 호텔방에서 유선인터넷을 사용할 수 있다고 해서 좋아라(...) 올라갔는데 접속해보니 하루 만오천원. 역시 호텔은 돈쓰는 곳이야...라면서 adhoc 네트워크로 공유하면 되지 하고 인터넷에 연결했다. 그러나 맥의 인터넷 공유와 우분투하고는 뭔가 상성이 안 맞았는지 호진님은 먼저 쥐쥐치고 주무시고, 재필님도 조금 인터넷을 쓰시다가 자러 가시고, 정규님과 내가 남아서 2.0 프레임웍 구조를 도입하느라 지뢰밭이 되어버린 trunk를 일단 돌아가게 만드는 작업을 했다. 간만의 여행으로 인한 피로와 싸우며 새벽 4시가 되어가고 로컬호스트 주제에 로딩에 5초씩 걸리는 텍스트큐브를 보면서 쥐쥐 선언. -_-;;

다음날은 느지막히 일어나 호텔 근처의 유명하다는 모이세해장국집에서 아침을 먹고 바로 공항으로 향했다. 주말이라 하루 정도 더 묵으면서 제주도를 즐길 수도 있었지만 니들웍스 분들이 전국에 흩어져있어 자주 얼굴보기가 힘들기 때문에 4명이나 한 곳에 모였으니 오프라인 모임을 한번 하기로 했던 것이다. 와이브로를 무선랜으로 공유하여 공항버스 안에서 인터넷을 즐기며 서울 강남으로 향했다. 그라피티에님과 합류하여 trunk 소스를 어떻게 할지, 빨리 처리해야 할 각종 사안들에 대한 논의가 이루어졌고 결국 지난 일주일간 dispatcher 중심으로 개편 중이던 trunk 소스는 암흑의 역사로 이동이 결정되었다. 또한 프레임워크를 도입하면 캐시가 중요하다고 강조하신 실무 유경험자 호진님의 의견을 따라 캐시 부분도 재작성하기로 했는데, 옆에서 듣다보니 '아, django라면 이 삽질 안 해도 되는데...'라는 생각만...ㅠ_ㅠ; 이런저런 이야기들을 하고 숨가쁜(?) 1박2일 동안의 남에 번쩍 북에 번쩍 스케줄을 마무리할 수 있었다.

내 또래 학생들을 놓고 정식 수업으로 초청 강의한다는 게 좀 생경한 경험이긴 했지만 간만에 콧바람도 좀 쐬고 사람들과 여러 발전적인 이야기들을 나눌 수 있어서 좋았다. 점점 갈수록 이번 학기 휴학하길 잘했다는 것과, 구글 인턴에 떨어진 것이 어쩌면 오히려 나에게 더 큰 기회를 주고 있는 걸지도 모르겠다는 생각과 함께 말이다.

ps. 주임교수님 아니랄까봐(?) 나와 재필님이 강의하는 수업에 출석까지 부르시는 윤석찬님을 보니 똑같은 학부생 입장에서 참... 그래도 금요일 오후 수업인데...ㅋㅋㅋ

뭐, 아주 오래 전부터 나온 떡밥이라 더 이상 새로울 것도 없지만 정말 너무 열받아서 써본다. (웹표준이니 오픈웹 소송이니 이런 거 아시는 분들은 읽을 필요 없음.)

아버지가 오래된 골프채 하나를 새로 장만하신다며 인터넷에 봐둔 것이 있다고 하셔서 사려고 했다. 원래는 회사 노트북을 쓰시지만 오늘은 집에 가져오지 않으셔서 내 데스크탑에서 하게 되었다.

1. 우선 네이버에서 검색어 입력 후 쇼핑 가격비교를 통해 신세계몰의 상품 페이지에 들어갔다.
2. 상품 유형 선택하고 설명을 보니 제휴 카드로 하면 5% 할인이 된다고 한다. 주문서 작성 화면에서 카드 할인을 적용하라고 되어 있다.
3. 결제하기 들어가서 비회원 주문 선택. 약관 동의 체크.
4. 결제 플러그인 설치 안 되었다고 궁시렁해서 설치 허용 후 2번부터 반복.
5. 주문서 작성 화면을 아무리 눈씻고 찾아봐도 카드 할인 적용에 관한 문구도 없고, 결제 금액은 할인 안 된 금액으로 그대로 나와 있다. 해당 카드로 선택해도 안 바뀜.
6. 주소 등 주문서 작성.
7. 그냥 할인 포기하고 사려고 결제 시도하자, 카드 번호 입력칸에 입력이 안 된다. 한참 삽질하다가 메모장에서 복사-붙여넣기 하면 된다는 걸 발견.
8. 해당 카드사의 플러그인 설치해야 한다고 궁시렁해서 다시 2번부터 반복.
9. 원래 결제하려던 카드는 어머니 꺼였는데 인터넷 뱅킹을 하신 적이 없으시기 때문에 공인인증서가 없다는 사실을 깨닫고 다시 7번부터 반복.
10. 카드 비밀번호 등을 입력하는 화면으로 넘어갔는데 이젠 붙여넣기도 안 되고 전혀 입력 불가능. 비스타 64비트에서 결제하는 것은 포기.
11. 가상머신으로 윈도 XP 부팅.
12. 다시 1번부터 반복하여 중간에 결제 플러그인 설치하느라 한 번 더 반복 후 7번까지 진행.
13. nProtect 깔라길래 끝까지 설치 안 하려고 했더니 8번에서 걸린다. 설치했는데 다행히 입력은 문제 없었음.
14. 안심클릭 비밀번호를 입력하는 화면에 넘어왔는데, 아버지가 인터넷 결제를 잘 안 하시는 분이라서 예전에 만들어둔 비밀번호가 맞지 않는다. 공인인증서로 하려고 해도 회사에 있으니 못 가져옴. 비밀번호 재설정도 공인인증서 요구.
15. 결국 옆에서 보다 못한 아버지께서 그냥 낼 노트북 가져오든지 회사가서 할께..하시고 포기. OTL

난 도대체 왜 이런 모든 삽질을 해야 하는지 이해할 수가 없다.

대한민국 정부와 금융결제원은 각성하라! 각성하라!

내가 전산과에 들어가서 알게 된 것 중 하나는 전산과 학생들이 누구나 다 프로그래밍을 잘 하는 건 아니라는 사실이다. 그것도 국내에서 나름 가장 수준높은 학생들을 모아놓은 카이스트임에도 말이다. (사실 나는 전부 다 괴짜에 전부 다 초천재적으로 엄청난 알고리즘들을 쏟아내며 코딩하는 줄 알았다.) 대개 프로그래밍을 어렸을 때부터 해왔던 아이들이 잘 하는데, 자세히 보면 뭔가 스스로 삽질을 많이 해본 아이들이 습득 속도도 빠르고 응용력도 더 높은 걸 볼 수 있었다. (가장 대표적인 예는 토끼군. ㅋㅋ)

나는 프로그래밍을 초등학교 5학년 때 처음 접했는데, 당시 시작한 것이 Q-BASIC이었다. 집에 있던 시리즈 과학책 중에 GW-BASIC으로 프로그래밍하는 것을 예제 중심으로 다룬 책이 있었는데, 그걸 보고 혼자 따라하다가 곧 내가 만들어보고 싶은 프로그램을 만드는 것으로 바뀌기 시작했다. 6학년 때 Visual Basic을 접했고 이때부터 본격적인 삽질의 나날이 시작되었다. 프로그래밍을 접하기 전에 내가 가장 관심있었던 것 중 하나는 각종 전략시뮬레이션 게임(스타나 커맨드앤컨커 같은)들의 맵에디터를 빠삭하게 꿰차는 것이었다. 과연 이 게임들은 내부가 어떻게 돌아가는 걸까에서 출발한 호기심이 결국 지금의 나를 만들었다고 하겠다.¹

당시 만든 것 중 지금까지도 기억에 남는 프로그램들이 몇 가지 있는데, 당시 유행하던 레드얼럿의 커스텀 미션을 만들 수 있도록 해주는 레드얼럿 미션에디터와 탭브라우징이란 개념이 널리 퍼지기 이전에 한 창에 여러 웹페이지를 보여줄 수 있는 방법이 없을까 고민하다가 만든 MDI 형식의 웹브라우저가 있다. (물론 HTML 해석기를 구현한 건 아니고 IE 컴포넌트를 쓴 거였지만. 뭐, XML/HTML 파서를 만들려고 시도해본 적은 있다.)

중학교 1학년이 지나면서부터는 비주얼 베이직에서 제공하는 모든 기본 기능과 라이브러리들에 대해 익힐 수 있었고, 미약하게나마 객체지향을 터득하면서 인터페이스 개념을 알게 되었다. (비주얼 베이직은 상속이 안 되지만 나름대로 객체지향적 특징을 가지고 있었다.) 중학교 2학년 때가 가장 절정을 이루었는데 비주얼 베이직의 끝을 본 건 분명 언어는 비주얼 베이직이지만 비주얼 베이직 런타임에 의존하지 않고 순수 윈도 API만으로 윈도 어플리케이션 만드는 방법을 완전히 이해했고--물론 실제 구현하려면 수많은 삽질이 필요하겠지만 어쨌든 원리는 이해했다--인터넷에 올라온 글을 보고 알게 된 것이긴 하나 비주얼 베이직의 특정 함수를 어셈블리 코드로 대치해서 실행한다든지, 또 정식으로 공부한 건 아니지만 재귀를 어떻게 루프만으로 구현할 것인지 등에 대한 어렴풋한 이해를 가지기 시작했다. 이와 함께 어지간한 프로그램을 보면 내가 아직은 잘 모르는 C/C++ 언어로 만들었겠지만 대충 이러이러하게 구현했겠구나라는 정도의 감각이 생겼다.

당시 SQL이나 DBMS에 대한 개념이 없었기 때문에 ADO 관련된 컴포넌트만 안 써봤고, 그 외에는 비주얼 베이직을 거의 극한까지 다루어봤다고 할 수 있겠다. 이 정도 단계에 다다르면 어떤 의문점이 생겼을 때 레퍼런스를 잘 찾아보든지 스스로 설계를 얼마나 더 잘하느냐가 해결의 성패를 좌우하게 되는 것 같다. (물론 고등학교 때 친구 토끼군인 비주얼 베이직으로 즉석에서 디자인한 스크립트 언어의 인터프리터를 구현해내는 걸 보고 또 다른 차원이 있다는 걸 깨닫게 되었지만, 지금은 그에 필요한 이론 지식들을 어느 정도 알고 있으므로 다시 내가 한다면 가능할 것 같다.)

중학교 3학년때와 고등학교 때는 학업 때문에 프로그래밍을 깊게 팔 기회가 없었고, 고등학교 때 수박 겉핥기 식으로 C++의 아주 극히 일부만 조금 배웠다. 대학에 와서는 학교 커리큘럼을 따라 Java를 익히기 시작했는데 사실 처음으로 다뤄본 완성도 있는 객체지향 언어였음에도 처음 프로그래밍을 접하던 친구들에 비해 훨씬 빠르게 익힐 수 있었으며 2, 3학년을 거치면서 PHP, Python, Javascript 등 다른 언어들도 상대적으로 손쉽게 두려움 없이 접근·터득할 수 있게 되었다.

특히 중학교 시절 쌓은 수많은 삽질 경험은 전산과 최고의 로드를 자랑하는 시스템 프로그래밍과 운영체제 과목에서 진가를 발휘했다. 매뉴얼(MSDN)을 보고 이 함수가, 이 컴포넌트가 어떤 방식으로 동작하는지 이해하고 실제로 사용해보고, 또 내가 그걸 이용해서 뭔가 만들어볼 수 있지 않을까 하면서 머리 굴려가며 시도해본 온갖 잡다한 미니프로젝트들은 결과적으로 거대한 시스템의 내부를 들여다보고 남들보다 빠르게 이해하는 능력을 키워준 것 같다.

시스템 프로그래밍 과목은 1번 프로젝트부터 5번 프로젝트까지 계속 기존 코드에 기능을 덧입히는 식으로 진행되었는데, 상당수의 학생들이 초기 명세에만 대응된 설계를 했다가 갈아엎는 일이 많았지만 나는 한 번도 갈아엎지 않고 꽤 깔끔하게 마지막 프로젝트까지 커버할 수 있었다. 이런 건 누가 가르쳐준 것도 아니고 누군가의 도움을 받은 것도 아니지만, 스스로 크고 작은 규모의 프로그램을 만들면서 왜 이렇게 설계하면 안 좋은지 좋은지를 깨달았기 때문이라고 할 수 있겠다. (이에 대한 보다 구체적인 지식은 소프트웨어 공학을 접하면서 배우게 되었지만, 나름의 내재된 감각이 생겼던 것이다.)

사실, 아직은 나 자신이 정말 프로페셔널한 '업계'에서 일해본 경험이 없어서 겐도님처럼 자신있게 "한 달의 기간이 있으면 아키텍처 설계를 포함해 그 언어를 습득·활용할 수 있고 1년이 지나면 전문가라고 말할 수 있다" 정도의 수준인지 아닌지는 나도 잘 모르겠다. 스스로 검증해본 적이 없기 때문이다. 학교 프로젝트를 통해 언어나 개발 환경을 접하게 되면 딱 그 프로젝트를 해결하기 위한 내용만을 익히게 되는 경우가 많고--더군다나 언어는 가르치지 않는다는 카이스트의 풍토 덕분에--실제 회사에서 풀타임으로 일하면서 온 신경을 그것에만 집중하며 배울 때와는 많이 다르기 때문인 것도 있다. 아직 회사에서 일해보질 않았으니까. 게다가 나는 전문 학원을 다니면서 프로그래밍을 배운 것도 아니요, 알고리즘 문제 해결을 위한 공부를 별도로 진행했던 것도 아니라 순수하게 내 호기심과 내 필요를 충족시키기 위해 프로그래밍을 배워왔기 때문에 정말 내가 전문가의 수준에 도달했는지 안 했는지 객관적으로 판단할 근거가 없어 자신없는 부분도 있다. 학부 전공을 하면서 보다 체계적으로 배우면서 단순 호기심과 필요만으로는 채워지지 않은 빈구멍들을 많이 메꿀 수 있었지만 이게 충분한지는 실무에 부딪혀보기 전에는 모를 것 같다.

어쨌든 나한테는 새로운 언어와 개발환경을 익히는 것이 더이상 두렵지 않다. 내가 새로운 환경을 접할 때 더 많이 고려하는 것은 이것이 과연 나의 삽질을 줄여줄 수 있는가, 그리고 오랫동안 지속 가능한 티핑 포인트를 넘었는가, 설계가 개발자의 가능성과 역량을 제한하는 부분은 없는가 등이다. 물론 대부분 일장일단이 있기 때문에 단순 가치 비교는 힘들지만, 어쨌든 필요하다면 배워서 쓸 수는 있다는 것이다.

비주얼 베이직 하나를 깊게 팜으로써 결국 다른 객체지향 언어들을 보다 쉽게 익힐 수 있었고, 하나를 익힐 때마다 그 다음 것을 익히는 데에 걸리는 시간은 점점 줄어들었다. 마치 기존의 지식과 새 체계를 diff 뜨듯 학습한다고나 할까. 물론 단순 diff는 곤란하고 그 안에 내재된 본질을 알고 있어야만 진정 효과가 있을 것이겠지만.

이런 접근 방식은 프로그래밍 말고 중고등학교 시절의 학업에도 큰 영향을 끼쳐, 게임 중독에 가까울 만큼 판판이 놀아가며 학원이나 과외도 받아보지 않고 참고서도 본 경험이 없는 채로 초등학교를 졸업한 후 단 한 학기만에 공부 요령을 터득함으로써 학년이 오를수록 더 적은 시간과 노력을 투자하여 비슷하거나 더 나은 성적을 거두는 결과를 얻기도 하였다. (1학년 1학기 중간고사는 한달을 공부했지만, 3학년 2학기 기말고사는 딱 4일 공부했다. 하지만 결과는 동일하게 전교 10등이었다.)

자기만의 지식 재조직화 과정을 통해 본질을 이해한다면 그 어떤 종류의 학문이라도 초기 문턱만 넘는다면 훨씬 능률적으로 일할 수 있을 것이라 생각한다. 다만 개인적으로 한 가지 아쉬운 점은, 현재의 한국 공교육·사교육을 통틀어 이러한 지식 재조직화 능력을 길러주는 곳이 거의 없다는 것이다. 대학에서 프로그래밍을 처음 접하는 많은 학생들이 어려움을 겪는 이유도 이런 곳에 있는 것이 아닐까?

이 블로그에도 굉~장히 많이 늦었지만 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이다보니 성가신 점이 많다. ㅠ_ㅠ