범용이라는 편에 MVC 프레임웍인 CakePHP를 놓아보겠다. CakePHP에서 제공하는 Schema 기능은 SQL 표준적인 것 위주로 다루어져있다. 예를 들면, MySQL의 integer type의 필드에 unsigned 속성을 줄 수 있는데, CakePHP의 Schema에서는 그것을 표현하지 못한다.

CakePHP에서 unsigned로 검색되는 글 중 하나에서도 범용적이지 못하다는 이유로 그러한 것이 채택되지 않는 것을 볼 수 있는데, mysql 함수인 crc32 를 저장하기 위해서는 적어도 int(10) unsigned 형식을 사용해야한다.

signed int32 버전의 CRC32를 사용한다거나  CakePHP가 unsigned 를 지원하게 한다거나로 해결해 보려고 MySQL의 CAST, CONVERT 함수를 알아 봤고, CakePHP의 Schema Class의 패치도 생각해 보았으나, 모두 현실적인 시간 낭비라는 생각으로 결론을 내리게 되었다.

이러저러한 이유로, 만일 MySQL 특유의 튜닝이 들어가는 field 값이나 index 들이 존재하게 된다면, CakePHP가 지원하는 매끄러운 Schema 버전 관리기능은 포기해야하는 상황이 생길 수 있다. (내부적으로 cake schema  류를 console을 재작성해야 할 정도로 포기했다).

범용 프레임웍을 사용하는 것은 다른 무엇보다 빠른 구현에 목적이 있다. 그 프레임웍이 제공하는 괜찮은 라이브러리들, 그 프레임웍을 지지하는 많은 3rd party 컴포넌트들, 효과들... 이런 것들이 한 번 도입하여 익숙해지면 비슷한 개발에서는 쉽게 개발할 수 있는 장점이 된다.

하지만, 프로젝트의 어느 한 부분에서는 선택한 DB, 언어의 버전에 따른 특유의 장점을 살려야할 때가 있다. 어떤 일을 할때에도 그 종말이 이런 범용과 특수의 긴장상태에서의 선택이 되는 것은 늘 개발자에게 지리할 정도로 끊임없이 다가온다. 노련해지려면, 이런 상황에서 분위기를 맡고, 의연하게 다음과 같이 되뇌어야한다.
완벽해, 모습을 완벽하게 바꾸어 다시 나한테 왔어, 감쪽같이 속았잖아. 이 상황까지 나를 몰고 온 네 노력이 가상하다. 좋은 시나리오야, 좋아.
그리고는 아무 일 없었다는듯이 범용 라이브러리가 모든 것을 일반화 시키는 유혹(?)을 간단하게 물리쳐버리고, 범용이 미치지 못하는 틈새는 그냥 임시 방편, 땜빵으로 넘기고, 시간 낭비했다는 자괴감 따위는 느끼지 않는 자세가 더 중요하다.

신고
  1. daybreaker 2009.05.19 06:24 신고

    Django가 좋은 점은 상대적으로 그런 부분의 커스터마이징을 쉽게 할 수 있도록 되어 있고 심지어는 장려하기도 한다는 점이죠. (말씀하신 정도의 예는 5줄 정도면 땜빵되고 완벽한 validation까지 한다면 10줄 정도 더 필요할까 싶습니다. 한번 dev.tattersite.com에 제가 최근 작업하고 있는 Textcube API 서비스 코드를 보심이...) CakePHP를 처음 며칠 써보고 나서 도저히 못쓰겠다하고 버렸던 이유가 프레임웍에 내 자신이 너무 지나치게 종속된다는 점이었는데, Django도 그런 부분이 아주 없지는 않지만 그래도 자유도가 굉장히 높은 편입니다. 불과 수십줄의 코드만으로 database server replication을 핸들링하는 DB 백엔드 확장을 만들 수 있을 정도니까요.

  2. ElegantCoder 2009.05.21 18:12 신고

    음.. 냉소적으로 말씀하신 건지 진심으로 말씀하시는 건지 잘 모르겠습니다 -_-

    • 최호진 2009.05.21 20:26 신고

      이글의 대상은 CakePHP가 아닙니다. 단지 예로든 것입니다. 제가 전달을 잘 못했나 봅니다.

      중요한것은 "범용적인 것과 특수한 상황에 대한 선택"은 정말 종종 만나는 상황이라는 것을 말할 뿐입니다.

+ Recent posts