(아래 글은 한국어 쓰기 연습하기 위한 외국인으로 만든 문서 입니다)

1990년대 후반과 2000년대 초반에는 “cgi-bin”이 포함된 URL을 자주 볼 수 있었지만, 요즘에는 거의 보이지 않는다. 이러한 URL은 어떤 의미를 지녔을까? 또한 왜 사라졌을까? 본 블로그에서는 이와 같은 URL이 왜 사라졌는지 살펴보고, CGI가 무엇인지도 함께 알아보고자 한다.

원래는 웹 서버와 애플리케이션 간에 표준화된 소통 방법이 없어 호환성 문제가 자주 발생했다. 이 문제를 해결하기 위해 1993년에 Common Gateway Interface(CGI)라는 표준이 도입되었다. 이를 통해 웹 개발자들은 다양한 프로그래밍 언어와 다양한 HTTP 서버를 사용해 애플리케이션을 쉽게 만들 수 있었다.

또한 웹의 초창기에는 HTML 폼 요소가 없었는데, 1995년 HTML 2.0에서 처음으로 폼 요소가 도입되었다. 폼 요소가 도입되기 전에는 대부분의 사이트가 정적 페이지였다. 이후 개발자들은 대화형 애플리케이션을 개발할 필요가 커졌다.

CGI의 작동 원리는 사실 매우 단순하다. 웹 개발자가 어떤 언어로든 스크립트나 프로그램을 작성해 지정된 디렉터리에 넣으면, 해당 스크립트는 HTTP 요청을 처리할 수 있다. 이 디렉터리는 보통 “cgi-bin”이라 불리지만, 다른 이름을 써도 된다. 예를 들어 guestbook.rb라는 애플리케이션이 있으면, ‘cgi-bin/guestbook.rb’를 요청할 때마다 서버가 guestbook.rb를 실행한다. 그렇다면 요청 정보는 스크립트에 어떻게 전달될까?

서버가 CGI 스크립트에 대한 HTTP 요청을 받으면, 먼저 스크립트 프로세스를 시작하고 환경 변수(CONTENT_TYPE, QUERY_STRING 등)를 통해 요청 정보를 전달한다. CGI 프로세스는 STDOUT으로 HTTP 응답을 출력해야 한다. 현재의 웹 개발 환경과 비교하면 매우 단순하지만, 당시에는 이 방식으로도 복잡한 애플리케이션을 구현할 수 있었다. 그렇다면 CGI는 왜 사라졌을까?

간단히 말해, CGI는 자원 사용이 비효율적이다. 서버가 HTTP 요청을 받을 때마다 새 프로세스를 시작하고 종료해야 하므로, CGI 애플리케이션은 다른 방식보다 느리고 메모리 사용도 비효율적이다. 결과적으로 애플리케이션은 FastCGI, SCGI, 리버스 프록시 등 다른 방식으로 전환되었다.