웹 서버에서 동적인 페이지를 보여 주기 위해 임의의 프로그램을 실행할 수 있도록 하는 기술 중 하나. 간혹 동적인 페이지는 다 CGI라고 생각하는 사람들이 있는데 CGI 말고도 이런 역할을 하는 기술은 여럿 있다. 단지 CGI가 맨 처음 나온 기술일 뿐.
원래 웹 서버는 서버에 저장되어 있는 고정된 문서를 보여 주는[1] 역할을 했다. 하지만 웹 서버에서 정보를 찾거나 기록을 하려면 웹 서버를 고쳐서 그런 기능을 넣어야 하는데 버틸 수 없으니, 대신 웹 서버가 특정한 URL로 들어가면 요청을 원하는 프로그램에 적절히 넘겨 주는 기술이 필요해졌는데 CGI가 그런 역할을 한다.
1 구조
- (보통은 웹 브라우저 안에서, HTML의 폼을 통해) 요청이 웹 서버로 전달되면,
- 웹 서버는 요청에 들어 있는 주소가 CGI 프로그램에 대응되는지 확인해서,
- 대응되면 그 프로그램을 실행해서 환경 변수와 표준 입력의 형태로 요청을 전달한다. 어떻게 전달되는지는 표준이 있다.
- 웹 서버는 CGI 프로그램이 표준 출력으로 돌려 보낸 내용을 그대로 응답으로 돌려 준다.
참고로 좀 오래된 사이트에서 종종 /cgi-bin/으로 시작하는 주소를 볼 수 있는데, 이는 2번 과정에서 웹 서버가 해당 디렉토리에 들어 있는 프로그램을 모두 다 CGI 프로그램으로 인식하도록 되어 있는 경우이다. 요즘은 보안 문제 때문에 막무가내로 이런 식으로 하는 경우는 흔치 않고 웹 서버에서 설정할 수 있도록 해 놓는다.
맨 처음에 CGI 프로그램은 C언어 같은 컴파일 되는 언어를 이용해서 만들어졌으나, 유지보수가 불편하다는 단점이 있었다. 그런데 웹 서버가 흔히 동작하는 유닉스 환경에서는 스크립트 언어를 마치 보통의 실행 파일처럼 실행하는 기능(#!로 시작하는 파일들)이 있기 때문에, CGI 프로그램 또한 이러한 스크립트 언어를 통해 컴파일 없이 동작하는 방법으로 넘어가게 되었다. Perl이 사실은 딱히 웹 환경을 위해 만들어진 언어가 아님에도 한동안 인기를 끈 이유도, 사실 Perl이 CGI 라이브러리가 있는 (당시) 얼마 안 되는 스크립트 언어였기 때문이다.
2 단점
이런 막강한 확장성을 가진 기술임에도 불구하고 CGI는 현재는 널리 쓰이지 않는데, 가장 큰 문제로 요청이 하나 들어 올 때마다 프로세스가 하나씩 실행된다는 것이 있다. 이는 특히 스크립트 언어에서 치명적이었는데 스크립트 언어에서는 보통 코드를 실행할 때마다 코드를 매번 해석해야 하기 때문이다. 물론 코드를 해석한 걸 캐싱하면 이 문제는 좀 나아지지만, 설령 C 언어 같은 언어로 미리 CGI 프로그램을 컴파일했다 하더라도 어지간한 환경에서는 프로세스 하나 실행하는데 몇 밀리초는 걸린다! 초당 수십건의 요청이 들어 오면 프로세스 실행하는 데만 시간을 다 소모할 것이다. 필요한 부분만 CGI로 만든다는 절충안을 쓴다 해도 요즘의 웹에는 동적인 것처럼 보이지 않아도 동적인 부분이 많기 때문에 적합하지 않다.
CGI를 대체하는 대부분의 기술들은 CGI의 이 단점을 해결하기 위해서 나온 게 보통이다. 몇 가지 예를 들면,
- 웹 서버가 직접 스크립트 언어를 해석하고 그 결과를 캐싱해서 빠르게 실행할 수 있도록 하는 경우가 있다. 특히 웹 서버 모듈로 확장 가능한 웹 서버에서 흔히 쓰이는데, 이 기술로 흥한 대표적인 언어가 바로 PHP이다(아파치 HTTP 서버의 mod_php 모듈). 근데 웃기게도 PHP 자체가 느려서[2] CGI를 안 쓰는 이득 중 상당수를 까먹는다(...). 그래도 CGI보다는 훨씬 빠르기 때문에 흥했다.
- CGI 프로그램이 한 요청만 처리하고 종료되는 게 아니라 요청을 계속 처리할 수 있도록 CGI를 개량한 경우가 있다. 이 중 언어와 상관 없는 기술로는 FastCGI와 이의 개량판 SCGI가 대표적이며, 내부적으로 이런 식으로 돌게 만들어진 언어별 솔루션들도 아주 많다. 대표적으로 PHP를 윈도우에서 IIS로 돌릴 경우 FastCGI 모듈을 이용해서 돌린다.
- 그냥 원하는 언어로 웹 서버를 짠다! 이 경우 해당 프로그램은 항상 실행되어 있고, 웹 서버는 그 내부 서버를 중개하는 역할만 하게 된다. 이 쯤 되면 웹 서버의 존재 의의가 없어질 것 같지만, 이러한 내부 웹 서버들은 전용 웹 서버들에 비해서 보안이나 설정 편의성 면에서 한계가 있게 마련이니 나쁜 건 아니다.