PHP에서 내가 좋아하는 점이 뭘까?
PHP는 실행후 죽도록 설계됐다.
우리는 코드 중복, 혹은 나쁜 코드 정렬(formmating), 나쁜 변수명 등을 두려워해선 안 된다. 코드 냄새를 풍기는 이런 결함들은 물론 나쁜 것이지만, 코드를 오염하는 데에선 상태 있음(statefulness)에 비할 바가 안 된다.
PHP에 상태가 없다는 특징은 많은 이들이 싫어하는, PHP의 가장 큰 제약 중 하나인 동시에 신입 개발자가 짠 형편 없는 PHP코드를 관리 가능하게 만드는 매우 중요한 요인이다. 대개 상태(state)는 PHP 프로세스와 완전히 분리돼 있다. 상태는 DB에 저장되기 때문에 가장 더러운 부류의 코드에서도 데이터베이스는 믿을 만한 진리의 원천이 된다. 그래서 버그 재연이 (대개) 쉽고, 점진적인 코드 재작성(같은 데이터베이스 — 즉, 상태 — 를 사용하는 옛 코드와 새 코드[가 공존하는 것])이 가능하다. 그리고 배포가 아주 쉽다. 그냥 스크립트를 업로드하면 된다! 개발은? 아, 그냥 이 줄을 고치고 파일을 저장하면 … 된다! 생각해 보자.
- 상태없음(Stateless) (이게 지금 유행이다. OK?)
- 배포하기 쉽다
- 개발하기 쉽다
- 디버깅하기 쉽다
- 이 모든 행복의 비결이 거저 주어진다. PHP는 매번 [실행 후 프로세스가] 죽기 때문이다.
언어 설계에서 이 선택에 대해 말하자면, 난 심지어 이게 의도한 건지도 모르겠다(업데이트: OK, 라스무스 러도프[PHP 창시자]가 이 글에 대한 해커뉴스 토론에서 이건 의도한 거라고 확인해 줬다). 그냥 어쩌다 보니 그렇게 설계했을지도 모른다. 하지만 이 제약은 PHP가 더러운 코드와 기이한 설계로 얼룩진 역사에도 불구하고 인기를 얻고 여전히 기술로서 살아 있는 비결이지 싶다.
엄격하게 상태를 분리하는 이 단순한 개념은 JS 세계에선 낯선 것이다. JS 설계에는 그런 것이 없기 때문이다. 이것이 대부분의 (앵귤러1 같은) 1세대 프론트엔드 프레임워크가 (물론, 복잡한 jQuery 코드도) 그렇게 졸라 짜증났던 이유다. 인터페이스에서 상태를 분리하고 결국 상태를 관리할 수 있도록 해 주는 Redux와 다른 해결책들이 만들어지기 전까지 말이다. JS에서 우리는 상태를 분리할 수 있다. PHP에서 우리는 상태를 분리해야만 한다.
‘오랫동안 살아있는(long-living)’ 프로세스를 이용하는 Node.js의 웹소켓 채팅 코드 샘플을 볼 때마다 나는 공포에 떨 수밖에 없다. 모든 웹소켓 커넥션을 담는 글로벌 “subscriber” 변수 때문이다. 이 비동기적이고 장기간 실행되는 복잡성이 미숙하고 성마른 개발자의 손에서 폭발하는 모습이 눈에 선하다.
이것이 아작스가 처음 소개됐을 때, 최종사용자에게 엄청난 장점을 제공했음에도, PHP 개발자의 삶이 그렇게 복잡해진 이유다. 상태(state)가 갑자기 프론트엔드에 나타났고, 우리는 이것이 우리를 어디로 이끌지 상상조차 할 수 없었다. jQuery, 그리고 백본, 그리고 앵귤러, 그리고 리액트, 그리고 등등등. 이제 우리는 프론트엔드 개발 전문가 — 프론트엔드에서 상태와 상태가 있는 인터페이스를 다루는 사람들을 따로 둔다.
이것이 우리가 큐(Que)와 데몬(Daemon)을 사용할 때 조심해야 하는 이유다. (그리고 특정 중간 규모 PHP 프로젝트에서 여전히 큐와 데몬이 필요하다.) 나쁜 코드가 제품에 들어가면, 그들[큐와 데몬]은 무자비하다 — 디버그하기 힘들고, 메모리 누수가 발생하며, OS는 가끔 프로그램을 죽인다. 그러나 일반적인 PHP 스크립트는 자비를 베푼다. 그러니 지금 쓰는 낡은 PHP 프레임워크가 비동기적 코드와 장기 실행 스레드를 잘 지원하게 해달라고 빌고 있다면, 도커를 상태가 없다고 찬양하고 있다면 이 점을 기억하고 감사하라. PHP도 상태가 없다는 것을 말이다 :)
업데이트:
HackerNews 토론: https://news.ycombinator.com/item?id=17853755