1991년, CERN의 한 연구자: "문서에 주소를 붙이면 안 될까?"
1980년대 말, CERN(유럽 입자물리 연구소)에는 문제가 하나 있었습니다.[^22-1] 전 세계에서 모인 수천 명의 연구자들이 각자 다른 컴퓨터에 자기 연구 자료를 저장해뒀는데, 그걸 찾으려면 어느 컴퓨터에 로그인해야 하는지부터 알아야 했죠.[^22-1] 더 나쁜 건, 각 컴퓨터마다 다른 프로그램을 배워야 한다는 거였습니다.[^28-1]
Tim Berners-Lee는 영국인 컴퓨터 과학자로, 부모님도 컴퓨터 과학자였습니다.[^21-1] 그는 이 문제를 보면서 생각했죠. "문서에 주소를 붙이고, 링크로 연결하면 안 될까?"[^25-1]
사실 그는 이미 1980년, 처음 CERN에 6개월 계약직으로 왔을 때 비슷한 시도를 했었습니다.[^21-1] "ENQUIRE"라는 프로그램을 만들었는데, 하이퍼텍스트 개념으로 정보를 연결하는 거였죠.[^21-1] 하지만 그때는 때가 아니었어요. 그는 CERN을 떠났고, 1984년에야 다시 돌아왔습니다.[^21-1]
1989년 3월, 그는 "Information Management: A Proposal"이라는 제안서를 썼습니다.[^24-1] 그의 상사 Mike Sendall은 이렇게 써놨어요: "Vague but exciting..."[^26-1] 모호하지만 흥미롭다.
1990년, Sendall은 NeXT 컴퓨터를 사 주었습니다.[^26-1] Steve Jobs가 디자인한, 당시로서는 혁신적인 컴퓨터였죠.[^28-1] Tim은 벨기에 엔지니어 Robert Cailliau와 함께 작업을 시작했습니다.[^22-1]
그리고 1990년 말까지, 그는 세 가지를 만들어냈습니다.[^23-1][^29-1]
1.
WorldWideWeb - 웹 브라우저이자 동시에 에디터[^23-1]
2.
CERN httpd - 웹 서버[^23-1]
3.
HTML, HTTP, URL - 기본 프로토콜들[^25-1]
1990년 12월 20일, 세계 최초의 웹사이트가 그의 NeXT 컴퓨터에서 공개됐습니다.[^23-1] 주소는 info.cern.ch.[^22-1] 그 컴퓨터에는 빨간 펜으로 손으로 쓴 라벨이 붙어 있었어요: "This machine is a server. DO NOT POWER IT DOWN!!"[^22-1] 이 기계는 서버입니다. 끄지 마세요!
웹의 작동 방식은 정말 단순했습니다. 서버 컴퓨터의 하드디스크에 HTML 텍스트 파일이 있고, 누군가 요청하면 그 파일을 읽어서 보내주는 거였죠.[^23-1] 이게 웹의 시작이었습니다. 그리고 이게 당연한 거였어요. 파일은 서버에 있으니까 서버가 보내주는 게 맞죠. 달리 방법이 있었나요?
1991년 8월 6일, Tim은 인터넷 뉴스그룹 alt.hypertext에 짧은 공지를 올렸습니다.[^23-1][^28-1] "WorldWideWeb 프로젝트에 협력해주실 분을 찾습니다."
이게 웹이 세상에 공개된 순간이었습니다.
1993년, 일리노이 대학의 학부생들: Mosaic와 "상호작용"의 탄생
2년 후인 1993년, 웹은 여전히 작았지만 빠르게 성장하고 있었습니다.[^34-1] 일리노이 대학의 National Center for Supercomputing Applications (NCSA)에서는 젊은 학부생들이 뭔가 새로운 걸 만들고 있었어요.
Marc Andreessen과 Eric Bina가 만든 Mosaic.[^23-1] 이건 게임 체인저였습니다. 이전 브라우저들은 텍스트만 보여줬는데, Mosaic는 이미지를 텍스트와 함께 보여줬거든요.[^23-1] 마우스로 클릭하기도 쉬웠고요. 사람들은 충격을 받았습니다. "와, 웹이 잡지처럼 생겼어!"
같은 건물에서, Rob McCool이라는 다른 학부생은 다른 문제를 풀고 있었습니다.[^35-1] Tim의 원래 웹 서버는 동시에 여러 사용자를 제대로 처리하지 못했거든요. 학생들이 Mosaic로 막 접속하기 시작하니까 서버가 버틸 수 없었어요. McCool은 더 강력한 웹 서버를 만들었습니다. NCSA HTTPd.[^35-1]
그런데 McCool이 더 중요한 걸 깨달았습니다. 사람들이 정적 문서만 보고 싶어 하지 않을 거라는 거죠. 상호작용을 원할 거예요. 방명록을 남기고, 폼을 제출하고, 검색하고...
당시 웹에는 그런 게 없었습니다. 모든 페이지가 그냥... 거기 있었어요. 하지만 사람들은 벌써 물어보고 있었죠. "내 사이트 방문자가 몇 명인지 어떻게 알아요?" "사용자가 뭔가 입력하게 할 수 있나요?"
1993년 11월 14일, McCool은 www-talk 메일링 리스트에 글을 올렸습니다.[^32-1][^32-2]
"I have spent some time writing up a formal specification for the Server-gateway interface. I invite any and all comments and suggestions."
서버와 외부 프로그램 사이의 인터페이스 스펙을 썼으니 의견 달라는 거였죠. 처음엔 "Common Gateway Protocol (CGP)"라고 불렀는데,[^32-2] 며칠 후 그는 다시 글을 올렸어요: "이건 프로토콜이 아니라 인터페이스인 것 같은데, CGI/1.0으로 이름 바꾸는 게 어때요?"[^32-2]
누군가 "gateway"라는 용어에 대해 투덜댔고, McCool은 설명했습니다: "게이트웨이는 일반적으로 접근할 수 없는 서비스에 접근할 수 있게 해주는 인터페이스를 의미합니다."[^32-2] 더 구체적으로는, 웹 서버를 데이터베이스 같은 레거시 시스템에 연결하는 거였죠.[^32-2]
1993년 12월 초까지, McCool은 CGI 스펙을 HTML 문서로 작성해서 공개했습니다.[^32-1] 위치는 http://hoohoo.ncsa.uiuc.edu/cgi/. (지금은 사라졌지만 Internet Archive에 1997년 버전이 남아있어요.[^32-1])
그의 정의는 이랬습니다:[^32-1]
"The Common Gateway Interface, or CGI, is a standard for external gateway programs to interface with information servers such as HTTP servers."
CGI는 정보 서버(HTTP 서버 같은)와 외부 프로그램 사이의 표준 인터페이스다.
작동 방식은 이랬습니다:
1. 브라우저가 폼 제출 → POST /cgi-bin/guestbook.cgi
2. 웹 서버가 CGI 프로그램 실행
3. 프로그램이 데이터베이스 읽고 HTML 생성
4. 서버가 브라우저로 HTML 전송
Plain Text
복사
보안을 위해 CGI 스크립트는 특별한 폴더에 넣었습니다.[^32-2] McCool이 제안한 이름이 cgi-bin이었고,[^32-2] 이게 곧 표준이 됐죠. 1990년대 후반엔 http://www.example.com/cgi-bin/helloworld.pl 같은 URL을 흔하게 볼 수 있었습니다.
이게 "서버 사이드 렌더링"의 시작이었습니다.[^31-1] 물론 당시엔 그런 말을 안 썼죠. 그냥 "CGI 프로그래밍"이라고 불렀습니다. 그리고 이게 웹을 개발하는 유일한 방법이었어요.
왜? JavaScript는 아직 존재하지도 않았으니까요.
CGI 스펙은 빠르게 채택됐습니다.[^31-1] CERN httpd, GN 서버, Plexus 서버... 모두가 CGI를 지원하기 시작했고,[^31-1] 이건 웹 서버의 표준이 됐습니다.
[^21-1]: Wikipedia - Tim Berners-Lee
[^22-1]: CERN - A short history of the Web
[^23-1]: Wikipedia - History of the World Wide Web
[^24-1]: CERN - Web@30: Web History
[^25-1]: World Wide Web Foundation - History of the Web
[^26-1]: Google Arts & Culture - Original NeXT computer
[^28-1]: HISTORY - The World's First Web Site
[^29-1]: Internet Hall of Fame - Official Biography: Tim Berners-Lee
[^31-1]: Wikipedia - Common Gateway Interface
[^32-1]: Cybercultural - 1993: CGI Scripts
[^32-2]: Cybercultural - 1993: CGI Scripts (McCool quotes)
[^34-1]: Common Gateway Interface (en-academic)
[^35-1]: Wikipedia - Robert McCool
1994년 가을, 우연히 만들어진 언어: "프로그래밍 언어를 만들 생각이 전혀 없었어요"
1994년 가을 어느 날,[^50-1] 캐나다 토론토에 사는 Rasmus Lerdorf는 짜증이 났습니다.[^43-1] 그는 덴마크에서 태어나 캐나다로 이민 온 프로그래머였는데,[^43-1] 자기 온라인 이력서를 웹에 올려놨거든요.[^48-1] 그런데 문제가 있었어요. 누가 내 이력서를 보는지 알 수가 없었습니다.[^45-1]
방문자를 추적하려면 CGI 스크립트를 짜야 했는데, Perl로 매번 새로 짜는 게 너무 귀찮았죠.[^42-1] 그래서 Rasmus는 C 언어로 작은 유틸리티 프로그램들을 몇 개 만들었습니다.[^44-1] 방문자 카운터, 로그 뷰어, 폼 데이터 처리... 이런 것들이요.[^46-1]
그는 이걸 "Personal Home Page Tools"라고 불렀습니다.[^44-1] 개인 홈페이지를 위한 도구들. 줄여서 PHP Tools.
1995년 6월 8일, Rasmus는 Usenet 뉴스그룹 comp.infosystems.www.authoring.cgi에 글을 올렸습니다.[^44-1][^46-1]
"Announcing the Personal Home Page Tools (PHP Tools) version 1.0. These tools are a set of small tight cgi binaries written in C."
C로 작성된 작고 빠듯한 CGI 바이너리 모음이라고 소개했어요. 그의 공지에는 이런 기능들이 나열돼 있었습니다: 접속 로그 기록, 실시간 로그 보기, 비밀번호 보호 페이지, 폼 정보를 다음 문서에서 사용하기...[^46-1]
그리고 중요한 건, 이걸 쓰는 데 필요한 게 거의 없다는 거였습니다:[^46-1]
"You do not need root access... You do not need server-side includes... You do not need Perl or Tcl... You do not need access to the httpd log files. The only requirement is that you have the ability to execute your own cgi programs."
루트 권한도 필요 없고, SSI도 필요 없고, Perl도 필요 없고, 로그 파일 접근 권한도 필요 없어요. 그냥 CGI 프로그램만 실행할 수 있으면 됐죠.
Rasmus는 자기가 뭘 만들고 있는지 몰랐습니다. 나중에 그는 이렇게 말했죠:[^42-1]
"The announcement talks only about the tools that came with PHP, but behind the scenes the goal was to create a framework to make it easy to extend PHP and add more tools. The business logic for these add-ons was written in C—a simple parser picked tags out of the HTML and called the various C functions. It was never my plan to create a scripting language."
프로그래밍 언어를 만들 계획이 전혀 없었다고요. 그는 2002년에 농담처럼 말했습니다: "1995년에 나는 웹에 C API를 풀어놓았다고 생각했어요. 분명히 그렇게 안 됐죠. 그랬다면 우리 모두 C 프로그래머가 됐을 테니까."[^42-1]
그런데 사람들이 이상하게 쓰기 시작했다
반응은 의외였습니다. 사람들이 PHP Tools를 Rasmus가 의도하지 않은 방식으로 쓰기 시작한 거예요. 방문자만 세는 게 아니라, 거기다가 데이터베이스 쿼리를 넣고, 장바구니를 만들고, 게시판을 만들었습니다.[^42-1]
1995년 9월, Rasmus는 PHP를 확장했습니다.[^41-1] 그는 잠깐 PHP라는 이름을 버리고 "FI (Forms Interpreter)"라고 불렀어요.[^41-1] Perl 스타일의 변수, 폼 변수 자동 해석, HTML 내장 문법... 이제 진짜 언어처럼 보이기 시작했죠.[^41-1]
1995년 10월, Rasmus는 코드를 완전히 다시 썼습니다.[^41-1] PHP라는 이름을 되찾아왔고, 이제는 "Personal Home Page Construction Kit"이라고 불렀어요.[^41-1]
1996년 4월 16일, 그는 다시 공지를 올렸습니다:[^46-1]
"PHP/FI is a server-side HTML embedded scripting language... It is most likely the fastest and simplest tool available for creating database-enabled web sites."
"서버 사이드 HTML 내장 스크립팅 언어"라고 불렀습니다.[^42-1] 이제 mSQL과 Postgres95 데이터베이스를 지원했고, 접속 로깅, 비밀번호 보호, SQL 쿼리 내장 같은 기능들이 있었어요.[^46-1]
PHP는 템플릿 언어로 시작했습니다. Rasmus의 원래 비전은 "비즈니스 로직은 C로 쓰고, HTML 생성만 PHP로 하자"였어요.[^42-1] 하지만 커뮤니티는 그 반대로 갔죠. 모든 걸 PHP에 때려박았습니다.
왜? 쉬웠으니까요. C 컴파일하고 CGI 바이너리 만드는 것보다, 그냥 PHP 파일에 코드 쓰는 게 훨씬 빨랐거든요.
Rasmus 본인도 나중에 인정했습니다:[^42-1]
"I did not develop the PHP we know today. Dozens, if not hundreds of people, developed PHP. I was simply the first developer."
오늘날 우리가 아는 PHP를 개발한 건 내가 아니다. 수십 명, 아니 수백 명이 PHP를 개발했다. 나는 단지 첫 번째 개발자였을 뿐이다.
1994년 중반, 패치 모음이 세계 1위 서버가 되기까지: "a patchy server"
같은 시기, 다른 문제가 터지고 있었습니다. Rob McCool—CGI를 만들고 NCSA HTTPd를 만들었던 그 학부생—이 1994년 중반에 NCSA를 떠났습니다.[^51-1][^52-1] Marc Andreessen이 Netscape를 만들면서 그를 데려갔거든요.[^53-1]
McCool이 떠나자 NCSA HTTPd 개발이 멈췄습니다.[^51-1] 이게 큰 문제였어요. 왜냐면 1995년 초, 전 세계 웹사이트의 90%가 NCSA HTTPd를 쓰고 있었거든요.[^53-1]
하지만 버그가 있어도 고쳐지지 않았습니다. 보안 구멍이 발견돼도 패치가 안 나왔죠.[^51-1] 웹마스터들은 각자 패치를 만들어 쓰기 시작했습니다. 어떤 사람은 가상 호스트 기능을 추가했고, 어떤 사람은 성능을 개선했고, 어떤 사람은 보안 버그를 고쳤어요.[^51-1] 하지만 이 패치들은 서로 공유되지 않았습니다. 이메일로 돌아다닐 뿐이었죠.[^55-1]
Brian Behlendorf는 당시 Wired 잡지의 온라인 버전인 HotWired에서 일하고 있었습니다.[^53-1] 그는 HotWired의 첫 웹마스터이자 "수석 엔지니어"였죠.[^53-1] HotWired는 NCSA 웹 서버로 돌아가고 있었는데, 문제가 있었어요. 비밀번호 인증을 HotWired가 필요로 하는 규모로 처리하지 못했습니다.[^53-1]
서버가 오픈소스였기 때문에, Behlendorf는 직접 패치를 코딩했습니다.[^53-1] 그리고 WWW-Talk 메일링 리스트에서 다른 웹마스터들과 얘기하다가 깨달았죠. 다들 똑같은 짓을 하고 있더라고요. 각자 NCSA 서버에 패치를 작성하고 있었던 겁니다.[^53-1]
1995년 2월, Behlendorf와 Cliff Skolnick는 "new-httpd"라는 메일링 리스트를 만들었습니다.[^55-1] 개인 이메일을 통해 연락한 작은 그룹의 웹마스터들이 모였어요. 목적은 하나였습니다: 각자의 변경사항들을 조율하는 것.[^51-1]
Behlendorf와 Skolnick는 캘리포니아 Bay Area에 있는 머신에 메일링 리스트, 공유 정보 공간, 그리고 핵심 개발자들을 위한 로그인을 마련했습니다.[^55-1] 대역폭과 디스크 공간은 HotWired와 Organic Online이 기부했죠.[^55-1]
2월 말까지, 8명의 핵심 기여자가 모였습니다:[^55-1][^51-1]
•
Brian Behlendorf
•
Roy T. Fielding (나중에 REST를 정의하는 그 사람)
•
Rob Hartill
•
David Robinson
•
Cliff Skolnick
•
Randy Terbush
•
Robert S. Thau
•
Andrew Wilson
이름을 뭐라고 할까 고민하다가, 처음 며칠 만에 정해졌습니다.[^59-1] Apache.
이름의 유래에는 두 가지 설명이 있습니다. Apache Foundation의 공식 설명은 "Apache 부족에 대한 존경"이라고 하지만,[^57-1] 실제로는 "a patchy server"—패치 모음 서버—라는 말장난이었죠.[^57-1] Brian Behlendorf는 2000년 인터뷰에서 둘 다 맞다고 인정했습니다.[^60-1]
Behlendorf 본인은 나중에 이렇게 말했어요:[^53-1]
"Building our own server was more an act of self-preservation than an attempt to build the next great web server."
우리 자신의 서버를 만드는 건 다음 위대한 웹 서버를 만들려는 시도라기보다는 자기 보존 행위였다.
NCSA httpd 1.3을 기반으로
그들은 NCSA httpd 1.3을 기반으로 삼았습니다.[^55-1] 찾을 수 있는 모든 공개된 버그 수정과 가치 있는 개선사항들을 추가했죠. 자기 서버에서 테스트하고, 1995년 4월 27일, Apache 0.6.2를 공개적으로 발표했습니다.[^51-1][^53-1]
Randy Terbush가 comp.infosystems.www.servers.unix 뉴스그룹에 공지를 올렸습니다:[^53-1]
"Folks, we in the Apache Group are happy to announce a new public-domain HTTP server based on patches to NCSA's 1.3 httpd called 'Apache'."
초기 Apache 서버는 대박이었습니다.[^51-1] 하지만 모두가 알고 있었죠. 코드베이스는 전반적인 점검과 재설계가 필요했어요.[^51-1]
1995년 5-6월, Robert Thau가 새로운 서버 아키텍처를 설계했습니다.[^51-1] 코드명은 "Shambhala". 모듈식 구조와 API, 풀 기반 메모리 할당, 적응형 사전 포킹 프로세스 모델을 포함했죠.[^51-1]
그룹은 7월에 이 새 서버 기반으로 전환했고, 8월에 Apache 0.8.8이 나왔습니다.[^51-1]
광범위한 베타 테스트, 수많은 플랫폼 포팅, 새로운 문서 세트, 그리고 표준 모듈 형태로 많은 기능 추가 후... 1995년 12월 1일, Apache 1.0이 릴리즈됐습니다.[^51-1][^59-1]
그리고 1년도 안 돼서, 1996년 4월, Apache는 NCSA httpd를 추월하여 인터넷 1위 서버가 됐습니다.[^51-1]
왜 Apache가 이겼을까?
커뮤니티의 힘이었습니다.[^51-1] 한 회사, 한 대학이 아니라, 실제로 웹 서버를 운영하는 사람들이 모여서 만든 거였어요. 그들은 자기가 겪는 문제를 정확히 알았고, 그 문제를 직접 해결했습니다.
그리고 여기서 패턴이 하나 생깁니다. 오픈소스 + 실용주의 = 승리.[^51-1]
이 패턴은 PHP에서도, Apache에서도 나타나고, 나중에 Linux, MySQL, 그리고 훨씬 나중엔 Node.js와 React에서도 나타날 겁니다.
다음 섹션(1995-1999 LAMP 스택과 "당연함")으로 이어질까요?
[^41-1]: PHP Manual - History of PHP
[^42-1]: Cybercultural - 1995: PHP Launches As Server-Side CGI Scripts Toolset
[^43-1]: Wikipedia - Rasmus Lerdorf
[^44-1]: O'Reilly - A Brief History of PHP (Programming PHP Book)
[^45-1]: Diseño Web Akus - How PHP started
[^46-1]: O'Reilly - Programming PHP, 2nd Edition
[^48-1]: Testbook - Father of PHP Language
[^50-1]: PHP History (ifj.edu.pl)
[^51-1]: Apache HTTP Server Project - About Apache
[^52-1]: ASF History Project - Timeline
[^53-1]: Cybercultural - 1995: Apache and Microsoft IIS
[^55-1]: Tech-Insider - The Apache HTTP Server Project
[^57-1]: Wikipedia - Apache HTTP Server
[^59-1]: ASF - 15th Anniversary Announcement
[^60-1]: Wikibooks - Apache/Introduction/History
1995년 5월, 스웨덴에서 태어난 데이터베이스: "딸 이름을 따서 MySQL"
1995년은 참 바쁜 해였습니다. PHP가 나왔고, Apache가 나왔고... 그리고 5월 23일, 스웨덴에서 또 하나의 중요한 조각이 등장했습니다.[^68-1]
MySQL.
이야기는 사실 1979년으로 거슬러 올라갑니다.[^67-1] 핀란드 출신 스웨덴 프로그래머 Michael Widenius—사람들은 그를 "Monty"라고 불렀어요—는 TcX라는 스웨덴 회사에서 일하고 있었습니다.[^61-1] 그는 UNIREG이라는 데이터베이스 시스템을 만들었죠.[^67-1] Unix 터미널용 인터페이스 빌더로, ISAM 스토리지 엔진과 인덱싱을 지원했습니다.[^67-1]
1994년, TcX는 웹 기반 애플리케이션을 개발하기 시작했습니다.[^66-1] UNIREG을 데이터베이스로 쓰려고 했는데, 문제가 있었어요. 동적인 웹 페이지를 생성하기엔 오버헤드가 너무 컸습니다.[^67-1] 느렸거든요.
그래서 TcX는 대안을 찾기 시작했습니다. 그들이 발견한 게 **mSQL (miniSQL)**이었어요.[^67-1] 저렴하고, 소스 코드도 함께 줬죠—거의 오픈소스였습니다.[^67-1] 하지만 치명적인 결함이 있었습니다. 인덱스를 지원하지 않았어요.[^67-1] 그래서 성능이 형편없었죠.
Monty는 mSQL의 제작자 David Hughes에게 연락했습니다.[^67-1] "mSQL을 UNIREG의 B+ ISAM 핸들러에 연결해서 인덱싱을 지원하게 할 생각 있으세요?"
Hughes는 거절했습니다.[^66-1] 그는 이미 mSQL 2를 작업 중이었고, 자기만의 인덱싱 인프라를 만들고 있었거든요.[^67-1]
TcX는 결정했습니다. "우리가 직접 만들자."[^67-1]
하지만 똑똑하게 접근했어요. 바퀴를 다시 발명하려 하지 않았습니다.[^67-1] UNIREG과 mSQL(소스 코드는 자유롭게 쓸 수 있었던)을 결합했죠.[^66-1]
1995년 5월, MySQL이 탄생했습니다.[^66-1][^68-1]
이름이 재밌습니다. 여러 출처에서 "My"가 Monty의 딸 이름이라고 하지만,[^61-1] Monty 본인은 이렇게 말했어요:[^66-1]
"It is not perfectly clear where the name MySQL derives from. TcX's base directory and a large amount of their libraries and tools have had the prefix 'My' for well over ten years."
MySQL이라는 이름이 정확히 어디서 왔는지는 완전히 명확하지 않다. TcX의 기본 디렉토리와 많은 라이브러리, 도구들이 10년 넘게 "My" 접두사를 가지고 있었다.
하지만 딸 이야기도 맞습니다. Monty는 세 자녀가 있었는데—My, Max, Maria—이들의 이름이 MySQL, MaxDB, MariaDB의 이름이 됐거든요.[^61-1]
David Axmark가 흥미로운 비즈니스 모델을 제안했습니다:[^66-1] "MySQL을 무료로 개발하고 배포하자. 그리고 '지원 서비스'를 팔아서 돈을 벌자."
이건 나중에 많은 오픈소스 회사들이 채택하게 될 모델이었습니다.
하지만 1995년 당시, MySQL은 완전히 오픈소스가 아니었어요.[^62-1] 처음엔 TcX 내부 시스템이었고, 1996년에 부분적으로 오픈소스가 됐습니다.[^62-1] 완전한 GPL 라이선스로 공개된 건 2000년이었죠.[^62-1]
그제야 MySQL의 사용이 폭발적으로 증가했습니다.[^62-1]
1995-1999: LAMP 스택의 완성, 그리고 "이게 유일한 방법"
1995년 말까지, 모든 조각이 모였습니다:[^62-1]
•
Linux (1994년 버전 1.0 릴리즈, Red Hat과 SUSE 같은 상용 배포판 시작)
•
Apache (1995년 4월 첫 공개, 12월 1.0)
•
MySQL (1995년 5월, 하지만 2000년까지는 완전 오픈소스 아님)
•
PHP/Perl/Python (PHP 1995년 6월, Perl은 이미 웹의 주력)
"LAMP"라는 용어 자체는 몇 년 뒤에야 만들어집니다. 하지만 기술 스택은 이미 완성됐어요.[^62-1]
왜 이 조합이었을까?
간단합니다. 전부 무료였고, 전부 작동했고, 전부 배우기 쉬웠습니다.
다른 선택지는?
•
Microsoft IIS + ASP? Windows 서버가 필요했고, 돈을 내야 했어요. 그리고 1995년엔 막 나왔을 때였죠.
•
Oracle Database? 너무 비쌌습니다. 중소 회사나 개인은 엄두도 못 냈어요.
•
Java Servlets? 1997년에나 나왔고, 너무 복잡했습니다. 설정만 며칠 걸렸죠.
그래서 대부분의 웹 개발자들은 LAMP로 시작했습니다. 그리고 그들에게 "서버 사이드 렌더링"은... 그냥 "웹 개발"이었어요. 다른 방법이 있다는 생각 자체를 안 했죠.
1998년, 어느 웹 개발자의 하루
1998년을 상상해보세요. 당신은 작은 웹 에이전시에서 일합니다. 고객이 전자상거래 사이트를 만들어달라고 했어요.
당신은 products.php 파일을 만듭니다:
<?php
// 데이터베이스 연결
$db = mysql_connect('localhost', 'user', 'pass');
mysql_select_db('shop', $db);
// 상품 가져오기
$result = mysql_query("SELECT * FROM products ORDER BY name");
// HTML 생성
echo "<html><head><title>우리 상품</title></head>";
echo "<body><h1>상품 목록</h1>";
while ($row = mysql_fetch_array($result)) {
echo "<div class='product'>";
echo "<h2>" . htmlspecialchars($row['name']) . "</h2>";
echo "<p>" . htmlspecialchars($row['description']) . "</p>";
echo "<p>가격: ₩" . number_format($row['price']) . "</p>";
echo "<form action='cart.php' method='POST'>";
echo "<input type='hidden' name='product_id' value='" . $row['id'] . "'>";
echo "<button type='submit'>장바구니에 추가</button>";
echo "</form>";
echo "</div>";
}
echo "</body></html>";
?>
PHP
복사
이게 전부입니다. 데이터베이스에서 읽고, HTML 문자열로 만들고, 브라우저로 보내는 거죠.
사용자가 "장바구니에 추가" 버튼을 누르면?
1.
폼 제출
2.
POST 요청이 cart.php로
3.
서버가 데이터베이스에 저장
4.
리디렉션
5.
페이지 전체가 다시 로드됩니다
느렸을까요? 네, 느렸습니다.
짜증났을까요? 네, 짜증났습니다.
다른 방법이 있었을까요? 아니요.
당시의 "당연함"들
1990년대 말 웹 개발자들에게 이런 것들은 의문의 여지가 없었습니다:
당연 1: 서버가 HTML을 만든다
•
왜? 브라우저엔 계산 능력이 없으니까
•
JavaScript? 1995년에 막 나왔고, 간단한 폼 검증이나 알림창 띄우는 "장난감"
당연 2: 매 요청마다 전체 처리
•
CGI는 요청마다 프로그램을 실행
•
PHP도 매번 스크립트 파싱
•
느림? 어쩔 수 없음. 다른 방법이 없음
당연 3: Full Page Reload
•
링크 클릭 → 전체 페이지 새로고침
•
폼 제출 → 전체 페이지 새로고침
•
이게 "웹이 작동하는 방식"
당연 4: 서버가 모든 걸 안다
•
세션: 서버에 저장 (파일이나 데이터베이스)
•
인증: 서버에서 확인
•
비즈니스 로직: 당연히 서버
•
클라이언트는 그냥... 보여주기만
그런데 문제가 생기기 시작했다
1999년경, 웹은 느렸습니다. 정말 느렸죠.
사용자가 버튼 클릭
→ 서버로 요청 (느린 28.8k 모뎀, 잘해봐야 56k)
→ 서버에서 DB 쿼리
→ PHP가 HTML 생성
→ 응답 전송 (또 느린 모뎀)
→ 브라우저가 HTML 파싱
→ 이미지들 다운로드
→ 전체 페이지 다시 그림
→ 깜빡!
→ 5-10초 경과
Plain Text
복사
Gmail 같은 건 상상도 할 수 없었습니다. 이메일 하나 읽을 때마다 전체 페이지가 새로고침되고, 목록 보려면 또 전체 페이지 새로고침... 말이 안 됐죠.
사람들은 불평하기 시작했습니다. "왜 이렇게 느려?" "왜 깜빡여?" "왜 매번 전부 다시 로드해야 해?"
그리고 1998년, Microsoft가 뭔가 이상한 걸 Internet Explorer 5에 몰래 넣었습니다. XMLHttpRequest라는 ActiveX 컨트롤이었죠. 아무도 주목하지 않았어요. 당시엔.
하지만 몇 년 후, 이게 모든 걸 바꿀 겁니다.
다음 장 예고:
2004년, Google이 Gmail을 공개합니다. 사람들은 충격을 받죠. "이게 어떻게 가능하지? 페이지가 새로고침되지 않는데 이메일 목록이 업데이트돼!"
이게 혁명의 시작이었습니다.
[^61-1]: Wikipedia - Michael Widenius
[^62-1]: Cybercultural - 1995: MySQL Debuts and Web Databases
[^66-1]: Matob News - The History and the Future of MySQL
[^67-1]: O'Reilly - Managing & Using MySQL, 2nd Edition
[^68-1]: History of Computers - History of MySQL
