개발일지01. 개발 골조

  처음에는 앞서 적은대로 Codeigniter 3(이하 CI)를 기반으로 작업하고자 하였다. 굳이 개발자가 아니라도 편하게 다를 수 있는 프레임워크로는 러닝커브가 낮은 CI가 제격이라 보았다. 광고 하나 달지 않는 비영리 사이트이기 때문에 리펙토링 후 기본적인 운영은 선별된 유저가 관리할 것이기 때문이다. 그렇지만 개발자의 욕심이랄까, CI에 Autoloader를 적용할 수 있는 방법을 찾아보았고, 발견할 수 있었다.(링크) 해당 패키지를 이용한다면 CI에서도 손쉽게 namespace를 지정할 수 있었다. 하지만 단 하나, My_model에는 사용할 수 없었다. 고심 끝에 반 쪽짜리 PSR-4를 도입하는 것은 이도저도 아닌 결과를 초래한다는 판단을 내렸다.

  그 후 정해야만 하였다. 모던함을 포기하고 CI를 고수할 것인가, 아니면 다른 프레임워크를 쓸 것인가? 다른 프레임워크를 쓴다면 어떤 프레임워크를 쓸 것인가? 그동안 써본 프레임워크는 CI와 Laravel, 그리고 Zend Framework였다. 리펙토링을 하는 이유는 취업 후 미뤄왔던 약속을 지키기 위해서도 있지만, 개발자의 역량을 쌓기 위한 것도 있었으므로 CI 도입은 결국 포기하였다. CI는 원한다면 퍼포먼스를 금방 끌어올릴 수 있기 때문이다. 한편으로는 CI4 dev도 생각해보았으나, 이내 그만두었다. CI를 좋아하지만, dev는 dev일 뿐이다. 적지 않은 기간 동안 고민하다가 정한 프레임워크는 바로 Phalcon이다.

  국내는 물론 해외에서조차 사용빈도가 높지 않은 Phalcon을 선택한 이유는 두 가지다.

1. Phalcon만큼 가벼운 프레임워크는 찾을 수 없다.
     코어가 C 확장 Module로 이루어져 있어 노출되지 않음은 물론이며, 속도 또한 빠르다. 코어가 코드에서 빠짐으로써 비개발자에게 노출되는 코드가 적으며, 그들에게는 굳이 알 필요가 없는 부분이다. 물론 C 확장 모듈을 서버에 직접 설치를 해야하기 때문에 일반적인 웹호스팅으로는 Phalcon를 쓸 수 없으나, 어차피 웹호스팅을 이용할 생각은 1mm도 없으므로 상관없었다.
2. Modern PHP는 물론이거니와, 러닝커브가 높지 않다.
     Laravel과 Zend는 어떠한가? 두 프레임워크 모두 러닝커브가 높으며, 상당히 무거운 프레임워크다. 리펙토링 대상이 해당 프레임워크를 써야할 정도로 복잡한 기능을 요구하지도 않고, 두 프레임워크 모두 관리를 맡길 비개발자에게는 용이하지 않다. 'Lumen에 필요한 기능을 추가로 올려서 개발해볼까?' 라는 생각도 해보았지만, 결국 Lumen도 Laravel 기반일 뿐이다. 대세로 떠오른건 Laravel이지만, 그건 어디까지나 개인 성향과는 상관없는 일이다. Laravel은 분명 좋은 프레임워크지만, 필자가 추구하는 프레임워크와는 거리가 있다. (C 확장 모듈을 설치해야하기 때문에 초기세팅까지는 다른 프레임워크보다 까다롭다.)
   

  프레임워크와 별개로 다음과 같은 스탠드를 취한다.

1. Composer 기반으로 구성한다.
     다양한 패키지를 활용하기 위해서는 Composer와 같은 의존성 관리자가 필요하다. Composer를 쓰지 않을 이유도 없을 뿐더러, 편의성을 포기할 당위성도 찾을 수 없다. Composer 기반은 당연한 선택이다.
   
2. PSR-1, PSR-2 그리고 PSR-4 convention을 적용한다.
     팀 내에 합의된 convention이 존재한다면 PSR을 반드시 지켜야 한다는 생각을 가지고 있지 않는다. convention이란 결국 의사소통을 원할하게 하기 위한 도구일 뿐이다. 그럼에도 불구하고 다양한 사람이 쓰게 될 코드는 권고안을 지키는 것이 커뮤니케이션에 유리하게 작용하기에 특별한 convention을 만들 필요는 없다.
   
3. 기본적으로 파일 당 500Line을 넘기지 않으며, 특이 케이스는 1000Line까지 허용한다.
     프로그래밍은 사람이 하기 때문에 한 번에 많은 코드를 머릿속에 넣을 수 없다. 해당 사이트는 15000Line이 넘는 파일도 있었으나(5년 전쯤에 10000Line 이하로 줄였다.), 유지보수에는 문제가 없었다. 물론 그 모든 것을 머릿속에 넣기까지 엄청난 시간이 필요했던건 함정이다. '리펙토링하는 마당에 굳이 그래야만 할까?' 라면 당연히 No. 사람에 따라 300Line을 넘지 말라고 이야기하지만, 300Line을 기준으로 할 경우 파일을 지나치게 많이 쪼개야만 하기 때문에 이와 같은 기준을 잡았다.
   
4. 1Line 당 기본 120자 이내, 특이케이스는 160자까지 허용한다.
     3번과 같은 사유다.
5. MVC 패턴에 SOA 아키텍처 모델을 적용한다.
     독학으로 프로그래밍을 처음 배울 때 고민하던 것이 있다. 어디까지가 Controller가 수행할 역할인가? 사실 지금도 내 코딩방식이 옳은 방식인지는 의문이지만, 그래도 일부는 정리하였다. Controller는 가교 이상 역할을 수행하지 않으며, 비즈니스 로직은 Service를 통해 수행한다. 규모가 커질 수록 이 방식이 유용하다. Model은 순수하게 데이터 관리를 해야하기 때문에, 비즈니스 로직을 Service로 관리하고자 한다.  개인적으로 Controller가 비대해지는게 싫어 선택한 방법이기도 하며, Spring을 처음 배웠을 때 이와 같은 설계가 유용하다는 것을 느꼈다.
   
6. view template은 Blade을 기반으로 한다.
     Phalcon도 view template이 존재하지만, 국내에서는 사용할 일이 0에 수렴한다. 굳이 view template까지 Volt를 쓰고 싶지는 않았다. Balde가 가진 단점을 찾을 수 없었기에 Laravel과 동일한 Blade로 결정하였다.
7. 마지막으로 PHP와 Mysql은 최신 버전을 유지한다.
     PHP7에서 추가된 type hinting은 유용하다. PHP는 typeless language이기 때문에 type hinting을 쓰지 않아도 되지만, IDE의 강력한 기능을 조금 더 활용하기 위함이다. 5.6과 비교하여 3배 빨라지는건 덤이다. Mysql8은 JSON에 대한 지원이 강화되어 언젠가는 도입될 실무에 앞서 미리 체험해보고자 한다.

  지금까지 Phalcon Docs에 의존하며 프레임워크를 익혔고, 목적에 맞게 기본적인 커스텀은 마친 상태다. Phalcon의 경우 middleware는 micro만 지원해서 아쉽지만, 이 또한 추가 패키지로 해결할 수 있는 문제다. 찾아보니 Phalcon4에서는 기본적으로 middleware를 지원한다고 한다.