피에이치피
| 필독 사항 | 유닠스 계열 | 저작물, 성인물, 도박 | 웹 써버 보안 | 프로그래밍 | 그래핔 | 파싱 |
|---|---|---|---|---|---|---|
| 필독 사항 | 고스트BSD | 표면 웹 싸이트 제작 | 리눅스 마스터 | 파이썬 | 트킨터 | 뷰티펄 숲 |
| 수학 | 아이투피 | 마약, 아청물, 해킹 | 웹 싸이트 보안 | 웹 프로그래밍 | 데이터 분석 | 게임 제작 |
| 통계학 | 뮤와이어 | 다크넽 싸이트 제작 | 정보 보안 기사 | 쟁고우 | 팬더즈 | 파이게임 |
개요
<?php
echo "Hello, World!";
?>
PHP. 프로그래밍 언어 중 하나. 2014년 8월 28일자로 PHP 5.6이 공개된 상태이다. 2015년 12월 3일에 새로운 버전인 [7 정식 버전이 릴리즈]되었다.
대표적인 서버 측 스크립트 언어로 한국을 비롯한 전 세계 웹 시스템의 근간이 되는 언어. 워드프레스나 미디어위키 등이 바로 PHP로 만들어진 것이다. 우리나라 한정으로 엄청난 점유율을 보이는 XpressEngine 역시 PHP로 된 것. PHP라는 이름은 원래 Personal Home Page Tools이나, 지금은 PHP: Hypertext Preprocessor라는 재귀 약자를 사용하고 있다. C언어와 유사한 문법을 사용하며, 소규모 페이지 제작시 손쉽고 빠르다는점으로 인해 사용 가능 인력이 많다. 프로그래머가 많으므로 당연히 압도적으로 사용처가 많다.
비슷한 용도의 기술로는 ASP, JSP, CGI, 루비 온 레일즈 등이 있지만 개발상 편의, 생산성 때문에 개인적인 용도나 소규모 사이트계는 PHP가 사실상 독점한 상태. ASP는 윈도우 서버에서만 돌아가고, JSP는 톰캣 등의 복잡한 기술이 추가적으로 들어가는 등의 문제점이 있지만, PHP는 PHP 모듈만 설치하면 되고, 이 PHP 모듈은 리눅스와 윈도우 둘 다 지원하기 때문이다. 퍼포먼스 향상을 위해 PHP-FPM을 이용해 실행하는 경우들이 많다.
PHP 설치
우분투에서는
php -v
로 PHP 버전 확인. 안 깔려 있으면
apt install php
을 입력하여 php 설치. 중간에 이 패키지는 얼마의 크기이며, 설치시 얼마의 추가 공간이 필요하다고 뜨고
Do you want to continue? [Y/n]
라고 계속 설치할 거냐고 물어보면 y를 눌러 계속 진행.
센트OS에서 PHP 7을 설치할 경우, 첫번째로 너의 센트OS 버전에 맞는 Webtatic EL yum 저장소(repository) 정보를 yum에 더해야 한다.
rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm
그리고
yum install php71w
해서 PHP 7.1을 설치한다.
특징
다른 서버 사이드 스크립트 언어와 마찬가지로 {{{<?php ... ?>}}}로 이루어진 스크립트 실행 영역이 있다. {{{<? ... ?>}}}로도 줄여 쓸 수 있고, 변수 하나만 출력할 경우에는 {{{<?=$var?>}}}[* 제로보드 스킨을 만져봤다면 많이 봤을 것이다.]같은 형식으로도 줄일 수 있다. 그러나 이렇게 줄여 쓰는 방식은 기본적으로 꺼져 있으므로 쓰려면 php.ini에서 short_open_tags의 설정을 바꿔줘야 한다. 이 줄여 쓰는 방식이 꺼져 있는 이유는 XML의 {{{<? xml version="1.0" ?>}}}과 같은 구문과 충돌하기 때문이다. 원래 PHP가 처음 나왔을 때는 HTML만 있어서 줄여 쓰는 방식도 문제가 없었지만, HTML에 XML의 문법을 도입한 XHTML 1.0이 나오면서 충돌이 일어났고 결국 저 옵션이 기본적으로 꺼져 있는 것으로 변경된 것. 다행히 HTML5에서는 XML 문법이 도로 빠졌다.
상기했듯 PHP는 그 형태가 C언어와 매우 유사한데, 몇 가지 상수와 변수 선언이 필요 없다는 것을 제외하면 큰 차이가 없다. 따라서 C언어를 할 줄 아는 사람은 PHP도 할 수 있다고 봐도 무방하다.[* 물론 언어와는 별개로 웹과 HTTP가 동작하는 방식을 알아야 제대로 개발이 가능하다. 이건 JSP나 ASP등을 하더라도 마찬가지.] 사실 C를 어느정도 다룰줄 안다면 PHP로 1주안에 간단한 쇼핑몰 만든다!
프리프로세서가 오픈소스이다보니 이식성이 좋아서 거의 모든 웹 서버에서 실행할 수 있다. Microsoft의 IIS에서도 실행할 수 있다! 윈도우용은 그 특성상 실행파일(바이너리)로 만들어서 제공한다. 그 동안 윈도우용은 32비트 버전밖에 안 나왔지만, 최신 버전인 5.5부터는 64비트 버전도 나오고 있다. 물론 윈도우용 소스를 다운받아 64비트용으로 컴파일해도 된다. 윈도우용의 경우 동작 방식의 차이 때문에 IIS에서 돌리는 PHP는 Non-Thread Safe 버전으로, Apache에서 돌리는 PHP는 Thread-Safe 버전으로 따로 나온다. 쓰는 웹 서버 프로그램을 잘 보고 다운받아야 한다.[* 다운로드 받는 페이지 옆에 보면 영어긴 해도 잘 설명되어 있다.]
현황
한때 포털사이트나 기업이 운용하는 웹사이트에서도 PHP를 사용하긴 하였는데, 보안적 취약성으로 인하여 현재는 Java 계열의 JSP나 C\# 계열의 ASP.NET으로 옮겨갔다. 참고로 JSP나 ASP.NET은 로드 밸런싱 기능이 포함되어 있어서 상대적으로 웹 서버의 부하를 줄여주는 효과가 있으며, PHP에 비해 보안기능이 훨씬 강력하다. 상기한 보안문제[* Stefan Esser 라는 보안 전문가(iOS Jailbreak 로도 유명하다)가 만든 패치인 수호신 (진짜 이름이 Suhosin 이다.) 으로 인해 어느 정도 개선되었다.~~그의 여자친구가 한국인이다~~] 및 대량의 트래픽이 발생할 경우의 문제 등으로 인해 기업 사이트 혹은 상업적 목적의 대형 사이트는 PHP를 쓰는경우가 거의 없다. IT관련 기업 외부노출 페이지를 PHP로 짠다면 제대로 된 회사가 아니라는 얘기까지 있을 정도. 페이스북마저도 2014년도 부터 PHP쓰지 않고 hack 언어를 사용한다. [[1]] [* hack 언어는 힙합 VM에 최적화 되어있는 언어다. 자체 컴파일러 '힙합'으로 컴파일한다.] [* '페이스북도 쓴다'라는 것은 많은 PHP 옹호자들이 말하는 것 중 가장 설득력이 없는 것이기도 하다. 왜냐하면 PHP의 단점을 보완하기 위해 Hack이란 언어를 개발했기 때문이다. 페이스북이 PHP 구현체의 문제를 해결하기 위해서 HHVM이라는 새 구현체를 만드는 엄청난 고생을 했다는 것을 잊어선 안된다.] [* 페이스북이 개발한 PHP 구현체인 HHVM은 PHP와 Hack 두 언어에 호환하므로 페이스북이 PHP를 버렸다는 말은 엄밀히 따져 틀린 말이다.] PHP의 보안문제는 크게 두가지 측면에서 기인한다. 하나는 PHP 인터프리터에 오류나 허술한[* 웹에서 오가는 html속에 표현가능한 여러 정보들을 쉽게 처리하려다보니까 태생적으로 들어오고 나가는 정보를 느슨하게 취급한다. 이 성질을 응용한 것이 XSS공격.] 점이 많은 것이고, 또 하나는 개발자 중 허술한 개발자들이 섞여있다는 것이다. --어찌보면 더 큰 문제다.-- 이 중 PHP 인터프리터의 허술함은 Codeigniter나 Laravel과 같은 프레임웍에서 제공하는 기능들을 이용해서 보완이 가능해져서 요즘은 나아진 상태다.
개인 웹호스팅 쪽으로 내려오면 여전히 PHP가 강세이다.[* 대부분의 웹호스팅이 PHP를 기본적으로 지원하고 있다. 그리고 상대적으로 가격이 저렴한 편이다. 왜냐하면 한 서버에 수용할 수 있는 사용자가 더 많기 때문이다.] JSP의 경우에는 아파치나 IIS말고도 톰캣이란 별도의 서버툴을 설치해야 되는데 설치는 둘째치고 코드가 갱신될 때마다 톰캣 서버쪽에도 반영을 해줘야한다. 이게 서버 관리자 입장에서는 은근히 귀찮다(…). ASP.NET은 일단 .NET이 기반이라 마이크로소프트의 운영체제와 IIS를 설치해야 되는데 문제는 이게 다 라이센스비 깨지는 것들이다(…).[* Windows Server 2008 R2가 가장 싼 것이 60만원부터 시작한다.] [* 값싸게 .NET을 돌리려면 모노로 돌리면 되지만 MS API가 완전히 구현되어있지는 않으므로 실행이 안 되는 경우도 있을 수 있다.] 본인이 꼭 필요하다면 지원하는 곳을 찾을 수는 있는데 비용이 꽤 많이 든다는 점을 염두에 두자.
웹 개발 시장에서 현재 많이 사용되고 또 경쟁 관계에 있는 언어는 Java, 즉 JSP라고 할 수 있는데 가장 큰 차이점은 '협업'이라고 할 수 있다. 상기한대로 개인 웹 분야에서는 PHP가 매우 강세인데, 도리어 그것이 PHP의 큰 단점이 되기도 한다. PHP는 여럿이서 동시에 같은 프로젝트를 진행하는 협업의 준비가 되어있지 않은 경우가 매우 많다. 아무래도 1인개발자가 혼자서 처음부터 끝까지 만드는 경우가 많은 PHP의 현실에 의한 결과일 것이다. 특히 PHP만 해온 개발자가 여러가지 이유로 JAVA/JSP에 도전할 때 가장 먼저 느끼는것 중 하나가 파일들이 ~~쓸때없이~~잘게 쪼개져 있어서 귀찮다는 것이다. 예를들어 PHP로 웹페이지 한개를 만들때는 보통 PHP파일 한개로 끝나거나 기껏해야 css, js 정도에다 공통부분을 include하는 PHP파일 등으로 구성되지만, JAVA의 경우 MVC패턴을 사용하는게 대세인데 그 경우 위에 추가로 jsp(HTML), sql(XML), Controller, ControllerImpl, Service, ServiceImpl, Dao, DaoImpl 등등 같은 수많은 파일을 생성해야만 간신히 페이지 하나가 만들어지는 경우가 많다. 특히 이중에서도 가장 중요한 것은 논리적 연산, 디자인, 데이터 입출력의 세 부분이 서로 분리되어 있다는 점인데 이는 웹개발자가 디자이너나 DBA등의 해당분야 전문가들과 동시에 작업할 수 있도록 하는데 매우 큰 역할을 한다. 물론 PHP로도 해당 부분을 분리하는것 자체는 어렵지 않으나, 실제로 분리하는 경우가 거의 없다는것이 가장 문제다. PHP언어적 특성이 아니라, 주로 사용하는 사람들의 취향이나 상황적인 문제로 인해 PHP로 작성된 프로그램은 협업이 힘들다는 선입견이 있고, PHP자체 문제는 아니지만 결과적으로는 그 선입견은 어느정도 사실이다.
현재 해외에서 인기를 끌고 있는 Laravel 등의 프레임워크는 MVC 패턴을 따르기 때문에, 최신의 유행(?)을 잘 따른다면 이러한 문제는 자연스럽게 어느 정도 해결할 수 있다. 그러나 여기에서조차 문제가 발생하는데 자바의 스프링에 해당하는 독점적인 프레임워크가 아직 없다는 점이다.[* Laravel말고도 Codeigniter, Yii, Phalcon, Zend, CakePHP등등 수많은 프레임워크가 존재한다.] 자바에서도 마찬가지로 스트럿츠를 거쳐서 스프링으로 대동단결하기 전까지는 MVC패턴 자체의 장단점과 필요성부터 시작해서 수많은 논란을 거치며 제각각 다른 수 많은 프레임워크의 난립 때문에 위의 협업과 같은 장점들도 조차도 제대로 누리지 못했던 시기가 존재했다. 각각의 개발자들이 일부는 프레임워크를 사용하고, 일부는 사용안하고, 또 사용한다해도 각자가 사용해본 프레임워크가 모두 제각각이라 큰 틀에서 MVC패턴을 따른다고 해도 기껏 개발자를 데려왔는데 개발 시작은 커녕 프레임워크 사용방법부터 가르쳐야하는 현재의 PHP와 유사한 문제가 발생했던 시기가 자바에도 있었던 것이다. 하지만 스프링 프레임워크가 등장하여 다른 거의 모든 프레임워크를 몰락시키고 (정확히는 몰락이라기 보단 흡수에 가깝다.) 시장 전반을 독점하다 시피 장악하여 위의 수많은 문제를 해결해 버렸던 것이다.
그러므로 PHP에서도 자바의 스프링 프레임워크에 해당하는 독점적 프레임워크가 등장하면 자연히 문제가 해결될 것 같아 보이지만, 현실적으로는 매우 어렵다. 크게 두 가지 문제가 있는데 먼저 스프링 프레임워크가 성장하던 시기는 JAVA웹 분야가 그리 크지 않았던 시기였다. 아무리 스프링이 좋은것이라고 해서 퍼져나갔다고 해도, 시장이 너무 크면 기존 구조를 갈아엎는건 어렵기 마련이기 때문이다. 그러나 JAVA는 웹언어가 아닌 웹은 그 일부일 뿐인 일반 어플리케이션 언어였기에 당시만해도 웹 비중이 그리 크지 않았으며 당시만 해도 ASP클래식/ASP.NET 마저도(...) 경쟁상대로써 점유율을 깎아먹었던 시기인지라[* 현재 ASP분야는 거의 없다시피하는 상황이다. 물론 있긴 하지만 마이크로소프트의 지원을 등에 업은것 치고는 너무 처참한 성적이다. 윈도우즈라는 운영체제의 도움을 받아서 간신히 명맥을 잇는 수준이고 그마저도 웹서버분야에선 x눅스에 밀려 점유율 높지 않다.] 자바웹 분야는 전체가 스프링으로 갈아엎어지기에 충분한 크기였다. 두번째 문제는 스프링프레임워크는 자바 자체의 특성을 매우 적극적으로 활용하고 있다는 것이다. 스프링의 모티브 중 하나는 최대한 아무것도 건들지 않는다는 것이다. 일반적으로 프레임워크라는 단어는 유용한 함수들을 모아놓은 라이브러리보다 한단계 더 높은 차원의 취급을 받는데 (실제론 틀린 말이지만, 개념적으로 이해하는데는 도움된다.) 덕분에 매우 거대하고 복잡하고 사용방법이 어려운것으로 인식되곤 한다. 그런데 스프링 프레임워크는 최대한 적극적으로 도입하면 도입하더라도 코드가 거의 아무것도 변하지 않는 특성이 있다. POJO라는 개념을 사용해서 자바 클래스의 기초중의 기초의 모습을 원형 그대로 유지하려는 노력을 하고 있으며 심지어 객체지향 언어에서 상속조차도 거의 사용하지 않으려는 모습을 보인다. 기껏해야 코드에 @으로 시작하는 Annotation이 한 단어에서 한 줄 정도 추가되는데 그치며, AOP를 사용하여 기존코드를 전혀 건들지 않고 작업하는 요소도 등장한다. 덕분에 사람에 따라서는 스프링은 프레임워크로 분류하지 않고 다른 프레임워크를 만들수 있게 해주는 도구의 일종으로 보는 사람도 있고, 실제로 다른 프레임워크들을 몰락시킨 이유중 하나가 다른 프레임워크와 스프링을 결합시켜 하나의 프레임워크로 만들어버리기 쉬운 특성이 있었기 때문이다. 실제로 자바에도 다른 여러 유명 프레임워크가 존재했지만, 버전업을 시키면서 스프링을 도입해 버리는 형태로 실제로는 스프링으로 대동단결 했지만 각각의 이름들과 자잘한 특성들은 그대로 남아있다. 이와 같은 스프링의 기능은 자바 언어 자체의 특성을 매우 적극적으로 사용한 결과물이기 때문에 [* 대표적으로 소스코드가 스스로 코드 다른 부분을 참조하고 그 정보를 토대로 원하는 동작을 할 수 있게 하는 기능으로 자기자신 을 본다는 뜻의 거울. 즉, 자바 리플렉션이라는 기능을 사용한다. PHP는 클래스로 구조화 하는것을 강제하지 않고 데이터형이 느슨하며 컴파일을 하긴 하지만 스크립트 언어적 특성이 많이 남아있어 리플렉션 비슷한 기능은 구현하기 어렵다.][* 이러한 언어 특성들 중 상당수는 최근버전 PHP에 도입 되었다. 하지만 정식으로 배우는 사람들도 많지만, 개인적으로 공부를 시작하는 사람들이 꽤 많은 PHP의 환경적인 특성때문에 아직도 저버전 특성만 알고있는 PHP개발자들이 시장에 많고, 원본 코드 자체가 서버로 올라가서 직접 해석되어야 하는 특성때문에 PHP에 저런 최신요소들을 사용하려면 서버 PHP버전이 최신버전으로 강제되어버려 큰 장벽이 되어버린다. JAVA는 일단 컴파일을 거쳐서 올리기 때문에 최신버전을 사용해 개발했더라도 서버가 구버전이면 구버전에 맞추어 컴파일 하는 방식으로 일부나마 커버가 가능한 특징이 있다.(물론 완벽커버는 어렵다)] 언어 자체가 완전히 다른 PHP에서 스프링과 유사한 프레임워크가 등장하기는 매우 어렵다고 볼 수 있다.
이러한 협업의 문제는 생각보다 큰 문제를 야기하는데 전체 사업의 규모를 한정짓게 된다는 것이다. 결과적으로 PHP프로젝트는 극소수의 인원이 진행할 수 밖에 없고 사업의 규모가 커지면 더 이상 혼자서는 감당이 되지 않지만, 그렇다고 그때가서 분리와 같은 협업을 위한 준비를 하기에는 프로젝트 전체를 갈아업는 수준의 작업이 필요해 지는 상황이 되어버린다. 그런데 PHP개발자들은 높은 확률로 협업의 경험이 없는 경우가 많다보니, PHP로 처음부터 재개발하는 수준의 작업을 거쳐 협업준비를 하는것보다는 차라리 JAVA/JSP로 전면 재개발을 결정하는 경우가 많아진다. 이런상황이 반복되다 보니, 소규모 사업은 PHP로, 대규모 사업은 JAVA/JSP로 하는것이 거의 암묵의 룰 같은 수준이 되어있다. 아무래도 대형사업이 될 수 밖에 없는 국가나 공공기관 SI사업들은 전부 JAVA/JSP로만 발주가 나오는데, 밀어주기 논란도 있기는 하지만 이러한 특성도 무시 못한다.
그런데 경제논리상 사업의 규모는 수익성과 비례하는 경우가 많다는 것이 문제다. 사업이 클수록 매출과 순이익이 큰 것은 어느정도 당연한 논리이다 보니 결과적으로 PHP개발자는 혼자서 수많은 분야를 전부 다 하면서 월급이 적고, JAVA/JSP는 협업으로 자기가 맡은 분야 하나밖에 하지 않으면서도 월급이 많아지는 상황이 되어버린다. 웹 개발자라는 분야는 개인이 취미처럼 시작해서 직업이 되는 경우와, 처음부터 개발자라는 직업을 목표로 전문 교육기관을 거쳐 취업하게 되는 경우로 나뉘는 경우가 많은데 전자의 경우는 PHP, 후자의 경우는 JAVA/JSP가 선택되는 경우가 절대 다수라고 할 수 있다. 반대로 사업주의 입장에서 보아도 개발자들의 임금수준을 비롯한 여러가지 이유로 JAVA/JSP의 진입장벽이 높은 편이다 보니 개인사업이나 소규모의 스타트업 수준이라면 매우 높은 확률로 JAVA/JSP가 아닌 PHP가 선택된다. 이러한 특성은 PHP의 명맥을 잇는데는 매우 도움이 되지만 반대로 PHP로 고수익을 얻는데는 큰 장애가 된다. 물론 PHP로도 고수익을 올리는 사람도 찾아보면 생각보다 굉장히 많지만, 전체 평균으로 따지면 굉장히 차이가 날 수 밖에 없고, 애초에 찾아봐야 한다는 것 자체가 낮다는 증거다. 또한 소규모 개인사업자들이 노동법규를 잘 지키지 않는것도 한몫한다.
이런 상황이 중첩되다 보니 취미처럼 PHP를 시작했다가 취업률 등의 문제로 자신의 의지와 다르게 어느세 직업이 되어있고[* 아무리 취업난이 극심해도 기술직은 그 영향이적다. 경제가 악화돼도 기술직은 월급만 낮아 질 뿐, 수요는 계속 있다. 그래서 학창시절 취업걱정에 물불 안가리고 일단 취업부터 하고 보잔식으로 구직을 하다보면 의외로 아주 쉽게 취업이 되어 어리둥절하게 되는 경우가 있다. 그리고 그 경우 막장급 대우를 받으면서도 잘 모르고 감수하기 쉽다.] 시간이 지나다 보니 한계를 느끼고 자바 전향을 노리게 되는 경우가 꽤 있는 편이다. 그리고 경우에 따라서는 굉장히 상이한 언어특성 탓에[* 특히 한쪽은 객체지향적 이해가 필수고 다른쪽은 옵션이며, 한쪽은 거의 웹 전용 언어라고 할 수 있지만 다른쪽은 웹은 극히 일부일 뿐이다.] 적응하지 못하거나 전향 자체를 실패하여 최초에 PHP를 선택한 것을 후회하기까지 한다. 그리고 웹 분야의 시장 특성상 규모 차이로 인해 일의 수 자체는 PHP자체가 많기 때문에 초기에는 한계를 잘 느끼지 못하다가 막상 단가가 높은것만 추리다 보면 자바밖에 없는것을 뒤늦게 실감하게 되어있는 구조다. 그리고 보통은 그때는 이미 늦은경우가 많다.
기타
PHP4까지는 클래스를 지원하기는 하는데 좀 시원찮아서(...) 아직 객체지향 프로그램을 만들기 어려웠지만 5에서는 많이 개선됐다. 그 덕분에 PHP4까지는 정말 순수하게 스크립트 형태로 작성된 코드들이 많았는데, PHP5 적용 이후로는 점점 객체지향 프로그래밍에 가까운 코드들이 나오고 있다. 덕분에 프로그래밍 언어를 정식으로 배우지 않은 사람들 입장에서는 코드 해독하기가 난해해지고 있다(…). PHP의 최대 장점이었던 진입장벽이 높아지고 있다고 우려하는 사람들도 있을 정도.[* 그런데 루비 온 레일즈 등의 영향을 받은 다양한 MVC 패턴을 지원하는 웹 개발 프레임워크들이 개발되었기 때문에 어떻게 보면 오히려 난이도가 더 낮아졌다고 할 수 있다. 2015년 현재 대세로 떠오르고 있는 Laravel 프레임워크 같은 경우에는 github에서 파이썬의 대표적인 웹 개발 프레임워크인 django의 star 수를 뛰어넘었다.]
사실 전체적으로 '뭔가 잘 설계된' 언어는 결코 아니다. 예를 들어 내장 함수나 인자 이름 명명에 일관성이 부족하다. 이는 필요할 때마다 그 기능을 그때그때 추가하는 방식으로 개발되었기 때문이다. [밖에도 여러 가지로 까인다.] 역으로 많은 부분을 개발자에게 맡기는 특성 때문에, [웹 프로그래밍에는 그만인 언어라는 평가도 있다.]
현재 웹상에 공개된 많은 웹 관련 어플리케이션들이 PHP로 작성되었기 때문에 간단하게 필요한 부분을 고칠 수 있을 정도로 배워두면 상당한 도움이 된다.
종종 일부 사이트에서 php 파일을 다운로드받는 경우가 있는데 이게 php 스크립트가 아니라 스크립트의 실행 결과물로써 나오는 php라는 확장자를 가진 html 파일이라는 사실을 아는 이는 그다지 많지 않다. 아무리 허술해도 서버의 소스 코드를 그냥 내뱉을 정도로 허술하지는 않다. --어디 가서 php 다운받는다고 말하지 말자. 컴공 있으면 개쪽난다-- 단, 진짜 php 소스가 다운로드 되는 경우가 있는데, 이 경우는 서버 세팅하면서 PHP 모듈을 설치하지 않거나 모듈 설정이 잘못된 경우다. 이런 경우는 php 파일을 서버에서 스크립트로 인식 못하기 때문에 일반 파일로 간주하고 다운로드시키기 때문이다. 주로 관리가 안 되고 오랫동안 방치된 사이트가 이런 경우가 많다. 아니면 테스트용 서버이거나.
라이센스를 보면, 일단 프리프로세서는 3.x[* PHP License/GPL 듀얼 라이센스를 채택했다.]를 제외한 모든 버전이 PHP License라 불리는 독자적 라이센스를 따른다. MIT 라이센스 비스무리한 형태이나 프리프로세서를 재배포할 때 (내용 수정 여부에 관계없이)패키지명에 PHP라는 단어를 넣지 못하게 하고 'This product includes PHP software, freely available from http://www.php.net/software'라는 문구를 코드에 삽입할 것을 강제하는 내용이 있어 GPL과는 호환이 되지 않는다.
컴파일러?
PHP는 스크립트 언어고 인터프리터가 소스 코드를 매번 일일이 해석해서 실행하는 방식이라 아무래도 퍼포먼스에 한계가 있다. 그래서 PHP 소스코드를 최대한 그대로 재활용하되 컴파일링을 통해 퍼포먼스를 향상시키는 소프트웨어들이 몇 개 개발돼 왔다.
페이스북은 자사 서비스를 개발하다가 PHP의 퍼포먼스 문제를 해소하기 위해 오픈소스로 HipHop for PHP와 HipHop Virtual Machine(HHVM)을 개발했다. 전자는 PHP 코드를 C++ 코드로 변환한 뒤 컴파일하는 방식이고, 후자는 Java와 비슷하게 JIT 컴파일링을 하는 방식이다. 페이스북은 현재 전자의 개발을 중단하고 후자만 개발하여 내놓고 있다. 참고로 페이스북은 HHVM을 개발하면서 hack 언어라는 프로그래밍 언어도 만들었는데, HHVM에서 hack 언어로 작성된 코드도 실행할 수 있다. 2015년 11월에 나올 예정인 PHP 7에서는 HHVM 못지 않은 수준으로 PHP의 퍼포먼스가 향상될 것으로 예상된다. ~~HHVM 설치하기 귀찮다면 그때까지 버티면 된다~~
다른 툴에 대한 설명은 추가바람.
업데이트
2012년 3월 현재 5.4버전이 배포되었다! 다만 업데이트된 기능[* 배열을 ［］로만 선언하기, 배열을 리턴하는 함수를 곧바로 접근하기 등. 이것은 이미 오래 전부터 JavaScript에서 구현된 것들이다. 이외에도 JavaScript에서 유래한 일부 기능이 추가되었다.]이 다른 언어에서 이미 지원되고 있으나, 제작진들의 모르쇠로 인해서 환호성과 탄식이 교차하고 있다. [소개]
2013년 6월에 5.5가 배포되었다. yield, finally 키워드 지원 ~~결국 또 뒷북~~, 보안성 강화, 배열 지원 강화 등을 골자로 하고 있다. 대신 MySQL의 지원은 축소되어, mysqli 프로토콜을 제외한 연결이 비권장(deprecate) 요소로 들어갔다. PHP7에서 완전히 삭제될 예정이다.
2014년 8월에 5.6이 배포되었다. $HTTP_RAW_POST_DATA가 비권장 요소가 되었고, 2기가 이상 파일 업로드가 가능해졌다. 또한 지수 표현을 위해 별도의 함수를 사용했었으나 **라는 연산자가 추가되었다. ~~결국 이제야?~~
PHP 5가 처음 나온 것이 2004년으로 거의 10년이 넘었는데, 사실 2005년부터 PHP 6에 대한 개발이 시작되었다. 하지만 이게 취소되는 바람에 PHP 5로 근 10년간 우려먹게 된 것이다. PHP 6은 처음부터 유니코드를 기반으로 작동되도록 설계가 되었고, 이 때문에 대단히 많은 변경점이 예고되어 있는 버전이었다. 그러나 하필 인코딩으로 UTF-16을 선택한 것이 발목을 잡았다. 이미 이 때부터 웹에서의 유니코드 인코딩은 UTF-8이 대세가 되어가는 중이었기 때문이다. 이 실책은 개발자들의 참여 저조로 이어졌고, 개발에 난항을 겪다가 2010년 5월 PHP 6 프로젝트는 취소되었다. 그리고 PHP 6에서 논의되던 상당수의 기능은 PHP 5.4 버전으로 흡수되었다.
하지만 PHP 5로 장기간 버티는 것은 아무래도 무리가 많았다. 엔진이 10년간 바뀌지 않은 채 유지되다보니 다른 스크립트 언어에 비해 속도 차이가 많이 나게 된 것이다. 그나마 계속 버전업을 통해 속도를 개선해 나갔지만 근본적인 개선은 무리였다. 결국 2014년 PHP 6을 건너뛰고 차기버전으로 PHP 7의 개발을 발표한다. PHP 7은 PHP NG (Next Generation)라는 새로운 구현체가 도입될 것이며, 덕분에 2015년 6월 배포된 PHP 7 알파1 버전은 PHP 5.6에 비해 약 70%, PHP 5.5에 비해서는 거의 2배의 성능 향상을 보이고 있어, HHVM 못지 않은 성능을 보여준다. 또한 새로운 기능을 추가하는 것과 동시에 기존 PHP 5의 호환성을 최대한 유지한 상태로 넘어가기 때문에 혼란은 많지 않을 듯하다.
PHP 7 발표 행보는 상당히 빠르다. 2015년 6월 11일에 알파1이 나온 이후 한 달 만인 7월 10일에 베타1이 나오고, 또다시 한 달 만인 8월 18일 릴리즈 후보안 1(RC1)이 나왔다. 11월 26일에 RC 8이 나왔으며, 12월 3일에 일반 이용자용(GA)이 나왔다. PHP 7은 PHP 5.6보다도 2배 빠른 성능을 보인다고 한다.