2025년 10월 11일·7분
라스무스 레르도프와 PHP: 개인 도구에서 웹 필수 요소로
라스무스 레르도프와 PHP의 이야기 — 개인용 스크립트 모음이 어떻게 널리 쓰이는 플랫폼이 되었는지, 그리고 왜 오늘날까지 많은 사이트가 PHP로 구동되는지에 관한 설명입니다.
라스무스 레르도프와 PHP의 이야기 — 개인용 스크립트 모음이 어떻게 널리 쓰이는 플랫폼이 되었는지, 그리고 왜 오늘날까지 많은 사이트가 PHP로 구동되는지에 관한 설명입니다.
PHP는 거대한 플랫폼이나 정교하게 설계된 언어로 시작하지 않았습니다. 시작은 라스무스 레르도프가 반복적인 수작업 없이 개인 웹사이트를 유지하고자 한 아주 구체적인 문제를 해결하려는 데서였습니다.
이 점은 오늘날에도 PHP가 가진 여러 특성을 이해하는 데 중요합니다.
레르도프는 초기 웹을 위해 개발하던 사람으로, 당시에는 페이지가 대부분 정적이었고 HTML 이상의 무언가를 업데이트하는 일은 금세 귀찮아졌습니다. 그는 방문자를 추적하고 공통 페이지 요소를 재사용하며 콘텐츠를 동적으로 생성할 수 있는 간단한 스크립트를 원했습니다.
다시 말해: 그는 변경 사항을 더 빨리 배포하도록 도와주는 도구를 원했습니다.
“개인 도구”는 브랜드명이 아니라 사고방식이었습니다. 초기 웹 제작자들은 종종 지루한 부분을 자동화하기 위해 작은 유틸리티를 작성했습니다:
PHP의 초기 버전들은 그런 실용적이고 ‘일단 움직이게’ 만드는 접근방식에 의해 형성되었습니다.
PHP의 뿌리를 알면 많은 특성이 더 이해됩니다: HTML에 직접 코드를 끼워넣는 데 초점이 맞춰진 점, 흔한 웹 작업을 겨냥한 방대한 표준 라이브러리, 그리고 학구적 완성도보다 편의성을 우선한 선택들.
이 선택들은 PHP가 빠르게 확산되도록 도왔지만, 이후 다뤄볼 트레이드오프도 낳았습니다.
이 글은 레르도프의 스크립트가 어떻게 커뮤니티 중심의 언어로 성장했는지, 왜 호스팅과 LAMP 스택에 잘 맞았는지, WordPress 같은 생태계가 어떻게 이를 증폭했는지, 그리고 현대의 PHP(7 및 8+)가 무엇을 바꿨는지를 살펴봅니다 — 그래서 PHP를 향수나 과대선전이 아닌 현실에 기반해 판단할 수 있게 됩니다.
1990년대 중반의 웹은 대부분 정적 HTML이었습니다. 폼을 처리하거나 히트 카운터를 표시하거나 방문자별로 페이지를 맞춤화하려면 보통 CGI 스크립트(대개 Perl)를 사용했습니다.
그 방식은 작동했지만 매끄럽지는 않았습니다.
CGI 프로그램은 요청마다 별도 프로세스로 실행되었습니다. 간단한 작업이라도 스크립트 파일의 권한 설정, 서버 구성, 그리고 “웹 페이지 작성”과는 다른 사고 모델이 필요했습니다. HTML에 약간의 로직을 섞는 대신 HTML을 텍스트로 출력하는 작은 프로그램을 만드는 식이었습니다.
취미 사이트나 소규모 업체의 공통 필요사항은 반복적이고 실용적이었습니다:
많은 사람들은 제한된 CPU, 메모리, 서버 설정 제어권이 적은 공유 호스팅을 사용했습니다. 커스텀 모듈을 설치하거나 장기 실행 서비스를 운영하는 것은 현실적이지 않았습니다. 업로드하고 간단한 스크립트를 실행하는 것만 가능했습니다.
이런 제약은 다음과 같은 도구를 밀어붙였습니다:
그 격차 — 정적 페이지와 무거운 스크립팅 사이 — 를 PHP가 해결하려 했습니다.
레르도프는 프로그래밍 언어를 발명하려 한 것이 아니라, 자신의 사이트를 더 잘 운영할 방법을 원했습니다.
초기 "PHP" 작업은 온라인 이력서의 방문자를 추적하기 위해 그가 사용하던 작은 C 프로그램 모음과, 페이지를 수시로 손으로 편집하지 않기 위한 몇 가지 유틸리티로 시작되었습니다.
당시에는 누가 얼마나 사이트를 방문하는지 아는 것이 지금처럼 간단하지 않았습니다. 레르도프의 스크립트는 요청을 기록하고 요약해 트래픽 패턴을 이해하기 쉽게 했습니다.
그와 더불어 간단한 템플레이팅, 작은 동적 출력 조각, 폼 처리 같은 공통 작업을 위한 헬퍼도 만들었습니다 — 사이트를 전체 맞춤형 앱으로 만들지 않고도 '살아있는' 느낌을 줄 수 있게요.
요청 추적, 폼 처리, 페이지 구성요소 재사용 도구가 생기면, 그건 다른 사람들이 사용하기에도 충분히 일반적인 도구가 됩니다.
핵심 순간은 기능이 특정 레이아웃이나 한 페이지에 묶여 있지 않을 때입니다. 다른 사이트 소유자들도 같은 접근법을 자신의 프로젝트에 적용할 수 있다고 상상하게 됩니다.
도구상자로 시작했기 때문에 사용감은 실용적이었습니다: 흔한 일을 빨리 하고, 과설계하지 않으며, 진입 장벽을 낮추는 것.
그 태도 — 유용성 우선, 다듬기는 나중 — 가 처음부터 PHP를 친근하게 만들었습니다.
요점은 간단합니다: PHP의 뿌리는 학구적이거나 이론적이지 않았고, 실제 웹사이트를 friction 없이 작동시키려는 문제 중심적 접근에서 나왔습니다.
PHP는 오늘날 사람들이 생각하는 방식의 ‘언어’로 시작하지 않았습니다. 최초의 공개 이정표는 PHP/FI로, 이는 **"Personal Home Page / Forms Interpreter"**의 약자였습니다.
이 이름은 의미심장합니다: 모든 것을 하려던 것이 아니었습니다. 동적 페이지를 돕고 웹 폼을 처리하게 하는 것이 목적이었습니다.
PHP/FI는 몇 가지 실용적인 아이디어를 묶어 초기 웹 개발을 훨씬 덜 고통스럽게 만들었습니다:
세련되지는 않았지만, 페이지를 작동시키기 위해 사람들이 써야 했던 접합 코드의 양을 줄여주었습니다.
초기 웹사이트는 곧 벽에 부딪혔습니다: 피드백 폼, 방명록, 가입, 기본 검색 같은 걸 원하면 사용자 입력을 수락하고 처리해야 했습니다.
PHP/FI는 폼 처리를 핵심 사용 사례로 만들었습니다. 폼을 고급 기능으로 취급하는 대신, 제출된 값을 읽고 응답 페이지를 생성하는 일을 더 쉽게 했습니다.
이 집중은 일상적인 사이트 소유자들이 만들고자 하는 것과 정확히 맞아떨어졌습니다.
PHP/FI의 가장 영향력 있는 아이디어 중 하나는 템플레이팅 스타일입니다: HTML을 주 문서로 유지하고 작은 서버 로직을 끼워 넣는 방식입니다.
\u003c!-- HTML-first, with small dynamic pieces --\u003e
\u003cp\u003eHello, \u003c?php echo $name; ?\u003e!\u003c/p\u003e
디자이너와 취미 개발자에게 이 방식은 자연스럽게 느껴졌습니다: 페이지를 편집하고 ‘딱 필요한’ 동작만 추가할 수 있어서 완전히 별도의 시스템을 채택할 필요가 없었습니다.
PHP/FI는 우아하지도, 그렇게 보이려 한 것도 아닙니다. 사람들이 채택한 이유는:
그 ‘킬러 기능’들은 화려하진 않았지만 초기 웹에 꼭 필요한 것들이었습니다.
레르도프의 초기 PHP 스크립트는 그의 개인 문제를 해결하기 위해 만들어졌습니다: 방문자 추적, 공통 페이지 요소 재사용, 반복 작업 회피.
그것이 대부분의 사람들이 아는 ‘PHP’가 되도록 만든 건 단일 대규모 재작성 한 번이 아니라, 동일한 편의를 원하는 다른 개발자들의 지속적인 참여였습니다.
PHP가 공개되자 사용자는 수정, 작은 기능, 아이디어를 보내기 시작했습니다. 그 피드백 루프가 중요했습니다: 프로젝트는 한 사람의 필요를 반영하는 대신 여러 웹마스터의 필요를 반영하게 되었습니다.
문서가 개선되고, 엣지 케이스가 패치되며, 익숙해지기 쉬운 관행들이 생겼습니다.
중요한 분기점은 PHP 3로, 코어 엔진을 재작성하고 “PHP: Hypertext Preprocessor”라는 이름을 도입했습니다. 단순한 브랜딩 이상의 의미였습니다.
재작성으로 언어가 더 일관되고 확장하기 쉬워져 PHP가 막무가내로 늘어나는 스크립트 더미가 되는 것을 막을 기반을 마련했습니다.
커뮤니티는 자신들이 의존하는 도구와 통합을 요구했습니다. 다양한 데이터베이스와 서비스에 연결하는 확장이 등장하면서 한 가지 설정에 묶이지 않게 되었습니다.
단순히 “HTML을 출력하는 스크립트”였던 PHP는 데이터 기반 웹사이트(방명록, 포럼, 카탈로그, 초기 전자상거래)를 구축하는 실용적 수단으로 바뀌었습니다.
핵심 변화는 기능 추가뿐 아니라 PHP의 역할 자체가 바뀌었다는 점입니다: 사람들이 실제 프로젝트에 의존할 수 있는 공유·확장 가능한 플랫폼이 된 것입니다.
PHP가 많은 웹사이트의 기본 선택지가 된 건 단지 배우기 쉬웠기 때문만은 아닙니다. 큰 부분은 내부 엔진이 심각하게 업그레이드되었다는 점입니다 — 더 빠르고 일관되며 확장하기 쉬운 런타임이 된 것입니다.
Zend(안디 구트만스와 지브 수라스키가 창립)는 PHP의 새로운 코어인 Zend Engine을 도입했습니다. 차를 유지하면서 엔진을 교체한 것과 비슷합니다.
개발자는 익숙한 PHP 코드를 계속 쓸 수 있었지만 런타임은 내부적으로 더 잘 구조화되었습니다.
그 구조는 다음을 가능하게 했습니다:
PHP 4( Zend Engine 1 기반)는 공유 호스팅 모델의 전성기에 등장했습니다.
공유 호스팅 제공업체들은 PHP를 광범위하고 저렴하게 제공할 수 있었고, 많은 업체가 그랬습니다. 이런 가용성은 성장의 선순환을 낳았습니다: 더 많은 호스트가 PHP를 지원하니 더 많은 사람이 사용했고, 더 많은 사용은 호스트가 계속 지원하도록 만들었습니다.
실무적으로 PHP 4는 “어디서든 쓸 수 있을 만큼 충분히 좋았다.” 그 보급성이 어떤 기능보다도 중요했습니다.
PHP 5( Zend Engine 2 기반)는 더 큰 코드베이스를 만드는 팀을 위해 PHP를 진전시켰습니다. 핵심 변화는 향상된 객체지향 프로그래밍: 더 나은 클래스 처리, 가시성 규칙 개선, 현대적 패턴을 위한 기반 제공입니다.
목표는 PHP를 학구적으로 만드는 게 아니라, 실제 프로젝트를 조직하고 코드 재사용과 유지보수를 쉽게 만드는 것이었습니다.
PHP가 확산되면서 새로운 압력이 생겼습니다: 사람들은 오래된 코드가 계속 실행되기를 기대했습니다. 호스팅 회사, CMS 플랫폼, 에이전시들은 안정성에 의존했습니다.
이 시점부터 PHP의 진화는 단순한 기능 추가가 아니라 ‘인터넷을 망가뜨리지 않기’라는 책임을 포함하게 되었습니다.
PHP는 종이 위에서 가장 우아한 언어였기 때문에 성공한 것이 아닙니다. 유용한 웹 페이지를 즉시 만드는 경험을 제공했기 때문에 성공했습니다.
초기 웹 개발자들 — 종종 디자이너, 취미 개발자, 소규모 비즈니스 — 에겐 PHP가 아이디어에서 동작하는 결과물까지의 시간을 다른 어떤 대안보다도 단축시켜주었습니다.
PHP로 피드백 루프는 거의 마찰이 없었습니다: 파일을 업로드하고 새로고침하면 결과를 봤습니다. 사소해 보이지만 세대를 통해 웹 제작 방식을 형성했습니다.
사람들은 단일 동적 페이지(연락 폼, 방명록, 카운터)로 시작해 점진적으로 확장할 수 있었습니다.
초기 웹 프로젝트는 대규모 엔지니어링 조직이 아닌 한두 명의 개발자로 이루어진 경우가 많았습니다. PHP는 그 현실에 맞았습니다: 배포 절차를 단순화하고 점진적 변경을 쉽게 했습니다.
PHP는 저렴한 공유 호스팅의 물결을 탔습니다. 많은 제공업체가 미리 설치해두었고, 별도의 인프라나 고가의 서버가 필요 없었습니다.
배포는 종종 ‘파일을 복사하면 끝’이었고, 이는 사람들이 이미 HTML을 게시하던 방식과 일치했습니다.
PHP 채택이 늘어나면서 튜토리얼, 코드 스니펫, 포럼, 복사-붙여넣기 예제가 넘쳤습니다.
그 커뮤니티 기억 덕분에 PHP는 복잡한 웹 문제에도 접근 가능하게 느껴졌습니다.
PHP가 성공한 건 언어 자체가 배우기 쉬웠기 때문만이 아니라 초기 웹에서 ‘기본 집’이 있었기 때문입니다.
그 집은 LAMP 스택이었습니다: Linux + Apache + MySQL + PHP. 수년간 이 조합은 동적 웹사이트를 운영하는 표준 레시피였고, 특히 소규모 비즈니스와 개인 프로젝트에 널리 쓰였습니다.
Linux와 Apache는 널리 사용 가능하고 저렴했습니다. PHP는 Apache의 요청/응답 모델에 자연스럽게 맞았고, 방문자가 URL을 요청하면 Apache가 PHP로 요청을 넘기고 PHP는 HTML을 생성해 응답하는 흐름이었습니다.
별도의 애플리케이션 서버를 관리할 필요가 없었기에 배포가 단순하고 저렴했습니다.
MySQL은 그림을 완성했습니다. PHP의 내장 데이터베이스 확장으로 MySQL에 연결해 쿼리를 실행하고 결과를 웹페이지에 렌더링하는 일이 간단해졌습니다.
이 긴밀한 통합은 데이터베이스 기반 사이트의 상당 부분이 같은 익숙한 도구로 구축되게 만들었습니다.
가속화 요소는 공유 호스팅과 원클릭 설치기였습니다. 많은 호스트가 PHP와 MySQL을 미리 구성해두었고(cPanel 등), 사용자는 MySQL 데이터베이스를 만들고 phpMyAdmin으로 테이블을 관리하며 FTP로 PHP 파일을 업로드해 빠르게 서비스할 수 있었습니다.
원클릭 설치기는(워드프레스, 포럼, 쇼핑카트 등) “웹사이트 = PHP 앱 + MySQL 데이터베이스”라는 개념을 대중화했고, 수백만 사이트 운영자가 PHP를 가장 쉬운 선택으로 여기게 했습니다.
스택은 실용적 워크플로우를 장려했습니다: .php 파일을 편집하고, 브라우저를 새로고침하고, SQL을 조정하고, 반복하는 식입니다.
또한 템플릿과 include, 폼 처리, 세션, CRUD 페이지 같은 익숙한 패턴을 만들며 공유된 웹 제작의 사고 모델을 형성했습니다.
PHP가 곳곳에 퍼진 건 문법 때문만이 아니라 완전한 설치형 제품들이 그 위에 형성되었기 때문입니다 — 최소한의 설정으로 실제 비즈니스 문제를 해결하는 도구들입니다.
콘텐츠 관리 시스템은 PHP를 원클릭 결정으로 만들었습니다. WordPress, Drupal, Joomla 같은 플랫폼은 관리 패널, 로그인, 권한, 테마, 플러그인을 묶어 코드 작성 없이도 페이지를 게시할 수 있게 했습니다.
각 CMS는 자체적인 중력을 만들었습니다: 디자이너는 테마를 배우고, 에이전시는 반복 가능한 상품을 만들며, 플러그인 시장이 성장했습니다.
클라이언트 사이트가 그런 생태계에 의존하게 되면 종종 클라이언트가 모르는 사이에 PHP가 다시 선택됩니다.
온라인 상점과 커뮤니티 사이트는 초기 웹의 필수 요소였고, PHP는 공유 호스팅 현실에 잘 맞았습니다.
Magento(나중엔 WordPress의 WooCommerce 포함)와 같은 소프트웨어, phpBB 같은 포럼 앱은 카탈로그, 장바구니, 계정, 운영 도구를 제공해 즉시 사용할 수 있는 솔루션을 제시했습니다.
이들 프로젝트는 브라우저에서 앱을 설치하고 구성하며 모듈로 확장하는 워크플로우를 표준화했습니다 — 바로 PHP가 번성하는 방식입니다.
모든 PHP가 공공 인터페이스를 갖는 건 아닙니다. 많은 팀이 내부 대시보드, 관리자 도구, 결제·인벤토리·CRM·분석을 연결하는 간단한 API에 PHP를 사용합니다.
이런 시스템은 “이 무슨 CMS냐?” 스캔에 잘 드러나지 않지만 PHP를 일상에서 계속 사용하게 합니다.
웹의 큰 비중이 몇몇 대형 제품(특히 WordPress)에 의해 차지되면, 그 아래의 언어는 그 영향권을 상속받습니다. PHP의 도달 범위는 언어 자체의 결과라기보다 그 위에 구축된 생태계의 결과입니다.
PHP의 성공은 언제나 실용성과 연결되어 왔고 — 실용성은 종종 거친 면들을 남깁니다.
많은 비판은 실제 역사에 뿌리를 두고 있지만, 모두 현대 PHP 사용 방식(혹은 코드 품질)을 반영하는 것은 아닙니다.
자주 제기되는 불만은 불일치입니다: 함수 이름 규칙이 제각각이고 매개변수 순서가 달라져 있으며 오래된 API가 새 API 옆에 공존한다는 점입니다.
이건 사실입니다 — PHP가 빠르게 성장하면서 웹의 변화에 맞춰 기능을 추가했고, 수백만 사이트의 호환성을 위해 오래된 인터페이스를 유지했기 때문입니다.
PHP는 다양한 프로그래밍 스타일을 지원합니다. 단순한 ‘일단 작동시키기’ 스크립트를 쓸 수도 있고, 더 구조화된 객체지향 코드를 쓸 수도 있습니다.
비평가들은 이를 ‘혼합 패러다임’이라 부르고, 지지자들은 ‘유연성’이라 부릅니다. 단점은 팀이 표준을 정하지 않으면 코드 품질이 들쭉날쭉해질 수 있다는 점입니다.
“PHP는 안전하지 않다”는 지나친 일반화입니다. 대부분의 PHP 보안 사고는 애플리케이션 오류에서 옵니다: 사용자 입력을 과신하거나, 문자열 연결으로 SQL 쿼리를 작성하거나, 파일 업로드를 잘못 구성하거나, 접근 제어를 깜빡하는 경우입니다.
PHP의 초기 기본값이 초보자에게 안전한 패턴을 강제하지는 않았고, 사용이 쉬웠기에 초보자가 공개 코드를 배포하기 쉬웠습니다.
정확한 관점은 이렇습니다: PHP는 웹 앱을 쉽게 만들고, 웹 앱은 기본적인 보안 수칙을 지키지 않으면 쉽게 망가질 수 있습니다.
PHP는 ‘웹을 깨뜨리지 않기’라는 큰 책임을 지고 있습니다.
이 하위 호환성은 오래된 앱을 수년간 실행 가능하게 하지만, 그 결과 레거시 코드가 더 오래 남아 때로는 최적 기한을 훨씬 넘겨 유지되는 일이 생깁니다. 기업은 더 나은 패턴을 채택하기보다 오래된 패턴을 유지보수하는 데 더 많은 노력을 들일 수 있습니다.
공정한 비판: 불일치, 레거시 API, 들쭉날쭉한 코드베이스는 현실입니다.
구시대적 비판: 현대 PHP 프로젝트가 2000년대 초의 PHP처럼 보여야 한다고 가정하거나, 언어 자체가 주된 보안 취약점이라고 보는 견해는 사실과 다릅니다.
대부분의 경우 차이는 도구가 아니라 팀의 실천 관행입니다.
PHP의 평판은 종종 수년 전 작성된 코드에 묶여 있습니다: 한 파일에 HTML과 로직이 섞여 있고, 일관성 없는 스타일과 환경 의존적 배포가 난무하던 시절 말입니다.
PHP 7과 8+는 단순히 기능을 추가한 것만이 아니라 생태계를 더 깔끔하고 빠르며 유지보수하기 쉬운 방향으로 밀어붙였습니다.
PHP 7은 핵심 내부를 재설계해 큰 성능 향상을 가져왔습니다.
같은 애플리케이션이 같은 하드웨어에서 더 많은 요청을 처리하거나 동일한 트래픽에서 비용을 낮출 수 있게 되었습니다.
이건 공유 호스팅, 바쁜 WordPress 사이트, 그리고 ‘페이지 로드 시간’이 매출에 영향을 미치는 비즈니스에 중요했습니다. 또한 PHP가 최신 서버사이드 옵션들과 경쟁할 수 있게 했습니다.
PHP 8은 대형 코드베이스를 이해하기 쉽게 만드는 기능을 도입했습니다:
현대 PHP 프로젝트는 보통 Composer를 의존성 관리자 표준으로 사용합니다.
라이브러리를 수동으로 복사하는 대신 팀은 의존성을 선언 파일에 적고, 예측 가능한 버전을 설치하고, 자동 로딩을 이용합니다. 이 때문에 현대 PHP는 구시대적 복사-붙여넣기 시대보다 훨씬 전문적으로 느껴집니다.
구 PHP는 종종 애드혹 스크립트를 의미했지만, 현대 PHP는 버전 관리된 의존성, 프레임워크, 타입 지정 코드, 자동화된 테스트, 실 트래픽을 견디는 성능을 갖춘 경우가 많습니다.
PHP는 향수를 불러일으키는 선택이 아니라 많은 웹 작업에 여전히 잘 맞는 실용적 도구입니다.
핵심은 이념이 아닌 제약 조건에 맞추는 것입니다.
PHP는 다음과 같은 경우 빛을 발합니다:
이미 많은 개발자가 알고 있고 호스팅이 어디서나 가능한 점은 마찰을 줄여줍니다.
다음 상황에선 대체 스택을 고려하세요:
새 제품을 처음부터 만들고 현대적 아키텍처(타입 지정 API, 구조화된 서비스, 명확한 관심사 분리)를 위한 강력한 기본값을 원한다면 다른 선택이 맞을 수 있습니다.
선택 전에 다음을 물어보세요:
PHP 기원 이야기에서 얻을 수 있는 교훈은 변하지 않습니다: 이기는 도구는 아이디어와 작동하는 소프트웨어 사이의 간격을 좁힙니다.
PHP에 계속 투자할지 새 서비스를 병행해 구축할지(예: React 프론트엔드 + Go API) 평가할 때, 빠른 프로토타입은 많은 추측을 제거해줍니다. Koder.ai 같은 플랫폼은 그런 ‘먼저 배포하고 개선하기’ 워크플로우를 위해 설계되어 있습니다: 채팅으로 앱을 설명하면 동작하는 웹/백엔드 프로젝트(React + Go + PostgreSQL)를 생성하고, 계획 모드·스냅샷·롤백 같은 기능으로 빠르게 반복하며 준비되면 소스 코드를 내보낼 수 있습니다.
더 실무적인 가이드를 보려면 /blog를 둘러보세요. 배포나 서비스 옵션을 비교 중이라면 /pricing이 비용을 가늠하는 데 도움이 됩니다.
라스무스 레르도프는 개인 사이트를 관리하기 위해 작고 C로 작성된 유틸리티들을 만들었습니다 — 방문자 추적, 페이지 구성요소 재사용, 간단한 동적 출력 처리 등이 목적이었습니다.
목표가 반복적인 작업을 줄이는 것이었기 때문에(‘완벽한’ 언어를 설계하려던 게 아님) PHP는 실용성을 우선한 느낌을 유지했습니다: 배포가 빠르고, HTML에 쉽게 삽입할 수 있으며, 웹 중심의 유틸리티를 많이 담고 있었습니다.
1990년대 중반에는 대부분의 페이지가 정적 HTML이었습니다. 폼 처리나 카운터, 방문자별 맞춤 콘텐츠 같은 동적 기능을 원하면 보통 CGI 스크립트(주로 Perl)를 사용했습니다.
그 방식은 작동했지만 일상적인 사이트 업데이트에선 불편했습니다. 보통 HTML 문서에 작은 서버 로직을 섞는 대신, HTML을 텍스트로 출력하는 별도의 프로그램을 작성해야 했기 때문입니다.
CGI 프로그램은 보통 요청마다 별도 프로세스로 실행되었고, 설정(권한, 서버 구성 등)이 더 많았으며, 웹 페이지를 ‘작성하는’ 느낌과는 다른 사고방식을 요구했습니다.
PHP는 동적 출력을 ‘웹 페이지 편집에 가깝게’ 느껴지도록 했습니다: HTML을 쓰고, 작은 서버측 스니펫을 추가한 뒤 업로드하고 새로고침하면 결과를 볼 수 있었습니다.
PHP/FI는 “Personal Home Page / Forms Interpreter”의 약자로, 초기 공개 버전이었습니다. 이 버전은 동적 페이지 생성과 폼 처리를 중심으로 설계되었습니다.
가장 강력한 아이디어는 서버측 코드를 페이지에 직접 삽입할 수 있게 한 점과, 특히 폼과 기본적인 데이터베이스 액세스 같은 흔한 웹 작업을 위한 내장 편의 기능을 제공한 점입니다.
장벽을 낮춰 비전문가도 쉽게 접근할 수 있게 했습니다: HTML을 문서의 주체로 유지하고, 이름 출력이나 결과 반복 같은 작은 동적 조각을 삽입할 수 있었습니다.
이 접근법은 공유 호스팅 환경에서 점진적으로 사이트를 확장하는 방식에 잘 맞았고, 처음부터 완전히 분리된 템플릿 시스템을 도입할 필요를 줄였습니다.
PHP가 공개되자 다른 개발자들이 수정과 기능 추가, 통합을 보내기 시작했습니다.
그 피드백 루프는 중요했는데, 프로젝트가 한 사람의 도구 상자에서 여러 웹마스터의 요구를 반영하는 커뮤니티 중심 프로젝트로 바뀌기 시작했기 때문입니다.
PHP 3는 코어 엔진을 대대적으로 재작성했고, 'PHP: Hypertext Preprocessor'라는 이름을 도입했습니다.
이 재작성은 언어를 더 일관성 있게 하고 확장하기 쉽게 만들었으며, PHP가 단순한 모음 스크립트 집합이 아니라 안정적이고 확장 가능한 플랫폼으로 성장하는 전환점이었습니다.
Zend Engine(안디 구트만스와 지브 수라스키가 만든)은 PHP 런타임 내부를 개선했습니다 — 더 나은 구조, 향상된 성능, 확장 기능을 추가하기 쉬운 기반을 제공했습니다.
이로 인해 호스팅 제공업체는 PHP를 널리 저비용으로 제공할 수 있었고, 팀들은 더 큰 코드베이스를 예측 가능하게 구축할 수 있었습니다.
LAMP( Linux, Apache, MySQL, PHP )는 특히 공유 호스팅 환경에서 동적 사이트의 기본 조합이 되었습니다.
PHP는 Apache의 요청/응답 모델에 잘 맞았고, MySQL과의 데이터베이스 연결도 쉬워서 MySQL 기반 페이지들을 PHP로 만들기 간단했습니다. 이 결합은 수백만 사이트가 같은 도구를 표준으로 삼게 하는 중력을 만들어냈습니다.
현대의 PHP(PHP 7 및 8+)는 큰 성능 향상과 유지보수성을 높이는 언어 기능을 도입했습니다. 또한 Composer 같은 도구로 의존성 관리가 표준화되었습니다.
선택 전에 고려할 점:
기존 PHP 시스템을 확장하는 경우 점진적 현대화가 전체를 재작성하는 것보다 비용 효율적인 경우가 많습니다.