PHP를 선택할 때

PHP는 특별한 언어이다.

빠른 개발을 위해서는 Perl CGI

빠른 성능을 위해서는 C CGI

고가용성을 위해서  FastCGI를 선택할 당시에,

HTML이 중심이 되는 웹 개발 전문 언어로써 나타났다.

당시에는 HTML은 문자열 데이터로 처리하는 것이 대부분이었고,

템플릿 라이브러리 등을 이용하여 분리되어 개발하다 보니,

웹 개발의 생산성은 지금에 비해 형편없었다.

소스코드는 코드와 HTML을 역전시켜, 

HTML을 그냥 작성하고, 필요한 코드를 <?php ... ?> 영역에 가두는 

획기적인 방식을 채택하였고 이는 곧 생산성의 비약적인 향상을 가져왔다.

그 이후 같은 방식의 ASP, JSP가 등장하였고 당시의 대세가 되었다.

그리고 Apache 웹서버에 인터프리터를 내장하여, 

"인터프리터 기동 -> 코드 컴파일 ->  작동"의 3단계를

"코드 컴파일 -> 작동" 2단계로 줄여서 응답속도를 현저히 향상시켰으며

Zend의 등장으로 컴파일한 코드를 캐싱하여 이마저도 더욱 빠르게 만들었다.

하지만 데몬 프로그램 작성에 취약한 단점 때문에 

굉장한 고가용성을 자랑하는 FastCGI나 서블릿과 같은

WAS(Web Application Server) 구조를 구현하기에 어려움이 있다.

(서블릿으로 해도 가용성을 개판으로 만드는 경우가 허다하지만..)

추억 돋는 소개는 이 정도로 하고..

PHP는 이런 경우 선택하면 된다.

- 기능이 자주 바뀔 때

자주 바뀌는 것은, 배포된 상태에서 수정이 가능해야 하는 경우가 많다.

이럴 때에는 당연히 인터프리팅 언어를 써야 한다.

- 빠르게 많이 찍어내야 할 때

빠르게 많이 찍어내야 한다면, 

리눅스에서 지원하는 패키지 매니저로 한방에 서비스 환경이 갖추어지는 PHP가 제격이다. 

- 아키텍처가 탄탄할 때

필요할 때 필요한 만큼 서버를 늘리고 줄일 수 있다면, PHP는 괜찮은 선택이다.

코드의 구성을 단순히 하고, 아키텍처에서 응답을 보장하는 것은 꽤 남는 장사이다.

PHP는 이런 경우 피해야 한다.

- 단독 데몬을 작성해야 하는 경우

서버 소켓을 쓰기 어렵고, 스레드가 없기 때문에 다중 접속 처리를 스스로 하기는 어렵다.

- 여러 사람이 동시에 작업하는 경우

전역 변수의 scope 경계가 모호하고, 이를 제한하기 위해 OOP를 활용할 자신이 없다면

피하는 것이 좋다.

- WebSocket 등 long-polling 서비스의 경우

이런 경우는 비동기 소켓을 사용하기 수월한 플랫폼을 선택해야 한다.

대표적인 것으로 node.js 가 있다.

PHP를 오랜만에 다시 해보려 한다면?

- PhpStorm 또는 IntelliJ + PHP 지원

프로그래밍의 생산성을  극대화하기 위해서는 IDE가 필수이다.

PHP도 예외는 아니며, 아래 소개하는 composer와의 궁합도 굉장히 좋다.

- composer

PHP에도 이제 세련된 패키지 매니저가 있다. 

프로젝트 자체의 크기는 줄이고, 배포/개발환경의 일관성을 유지하기를 원한다면 반드시 사용할 것.

이후 소개하는 2개의 라이브러리도 composer로 설치할 수 있다.

- PHP Slim Framework

한때 코드 이그니터가 유행한 적이 있었지만 비대하고 과한 구조로 부담이 컸다.

요즘 Slim은 유행하는 Routing 설정 방식의 웹 프레임웍이며, 간단하고 강력하다.

RESTful API에 적합하며, 다양한 플러그인과 Hook 등의 작성이 간편하다.

- MeekroDB

믿고 쓰는 러시아산(?) 라이브러리이다.(아닐지도 모르지만 러시아산 같다..)

더 이상의 SQL라이브러리는 없다고 생각한다.