범용과 특수의 긴장

범용이라는 편에 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, 언어의 버전에 따른 특유의 장점을 살려야할 때가 있다. 어떤 일을 할때에도 그 종말이 이런 범용과 특수의 긴장상태에서의 선택이 되는 것은 늘 개발자에게 지리할 정도로 끊임없이 다가온다. 노련해지려면, 이런 상황에서 분위기를 맡고, 의연하게 다음과 같이 되뇌어야한다.

완벽해, 모습을 완벽하게 바꾸어 다시 나한테 왔어, 감쪽같이 속았잖아. 이 상황까지 나를 몰고 온 네 노력이 가상하다. 좋은 시나리오야, 좋아.

그리고는 아무 일 없었다는듯이 범용 라이브러리가 모든 것을 일반화 시키는 유혹(?)을 간단하게 물리쳐버리고, 범용이 미치지 못하는 틈새는 그냥 임시 방편, 땜빵으로 넘기고, 시간 낭비했다는 자괴감 따위는 느끼지 않는 자세가 더 중요하다.