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