저 명제는 틀리지 않습니다. 일반적으로 웹서버에서 돌리는 독립적인 스크립트를 CGI라고, 웹서버의 모듈로 연동해 돌리는 PHP스크립트 등과 구분하여 부르더군요.

음... 어느 관점에서 보느냐에 따라 다를 것 같습니다. 웹서버와 클라이언트의 통신을 본다면 PHP도 (독립적으로 돌리든 웹서버의 모듈로 돌리든) CGI를 통하는 것이 맞습니다. 하지만 웹서버와 스크립트간의 통신에 있어선 웹서버의 모듈을 통해 PHP 스크립트를 실행할 경우 일반적인 CGI와 다르군요. CGI가 후자의 실행 매커니즘까지 정의하고 있는지는 공부해보지 않아 잘 모르겠습니다. ^^;;

텀즈에서 발췌한 위의 정의 처럼 그렇다면 PHP도 같은 맥락으로 작동하는것이고 웹서버에 붙여진 PHP모듈을 통해 실행되어지는 PHP 스크립트도 결국은 CGI가 아닌것인지를 묻는것입니다.

이거 제가 이미 답한거나 마찬 가지인데요 ^^;;

답은 "아닙니다" 입니다.

CGI 는 표준입니다. 프로그램과 웹서버 사이에 데이터를 어떻게 주고 받을 것인가에 대한 표준입니다. 보통의 경우 GET 요청의 경우 환경변수로 전달을 하고 POST 의 경우 표준입력으로 받는 것으로 알고 있습니다. 그 밖의 전달 형테는 CGI 라고 보기 힘들죠. 정의 그대로는요. 텀즈의 정의를 조금만 깊게 생각해보면 아파치 모듈로 돌아가는 php 는 cgi 가 아닌 것을 금세 알수 있습니다.

"웹서버에 있어 사용자의 요구를 응용프로그램에 전달하고 그 결과를 사용자에게 되돌려주기 위한 표준적인 방법이다"

아파치 모듈로 올라가게 되면 아파치 프로세스 내에 이미 php 가 내장 되어 있으므로 "웹서버와 응용프로그램에 전달하고 그 결과를 사용자에게 되돌려주기 위한 표준적인 방법"이 필요 없습니다. 어차피 같은 프로세스 내에 엤으니 메모리 상에서 전달하면 됩니다. 그렇다고 fastcgi 도 cgi 는 아니죠. 말 그대로 "표준적인" 방법인데, fastcgi 가 데이터를 전달하는 방식은 "그 표준적인" 방법이 아닌 다른 방식을 사용하는 것 이니까요.

그리고 제가 php 를 cgi 방식으로도 동작시킬 수 있다고 한 것은, cgi 방식으로 동작시키지 않을 수도 있다고 한 것이고, 그 말에는 cgi 방식으로 동작시키지 않는다면 cgi 방식이 아니다라는 뜻도 됩니다.

정리해서 mod_php 로 돌아가는 php 는 cgi 가 아닙니다.

2006/11/22 정정: mod_php 로 돌아가는 php 구현도 cgi 를 준수 할 수도 있습니다. 아래쪽 댓글 참조.

일단 cgi로 사용하려고 만든 언어고
언어에 따라서는 단독으로 사용할수 있는 언어도 있고
웹서버의 모듈로 작동하는 경우가 있어서 집합을 벗어날수있지만
CGI는 광의의 뜻을 가지고 있는 것은 맞습니다.
요즘은 C로 컴파일한 바이너리나 펄로 작성된 것을 CGI로 부르는 경우가 있긴 합니다만..

네크로멘서님 말씀도 맞긴 맞습니다.
php가 서버에 모듈로 포함된 경우 요청이 들어올 때부터 php모듈이 넘겨받아서 처리하기 시작합니다.
하지만 이때도 php는 환경 변수 $_SERVER, $_ENV 등 을 CGI모드로 움직일때와 "거의" 동일하게 세팅하고 처리합니다.
큰 그림으로 보면 php가 서버에 모듈로 들어가더라도 CGI의 규약을 지키고 있게 됩니다. fork, pipe 등의 작업이 CGI의 필수 동작은 아니거든요.
그렇게 따지면 FastCGI도 CGI가 아니라는 말이 될 수 있습니다.
CGI는 규약이고 클라이언트의 요청에 따라 웹서버가 어떤 프로그램(데몬이든 프로그램이든 스크립트든)을 돌릴 때 그 프로그램과 통신하는 방법에 대한 것이기 때문에 클라이언트가 결과 화면을 볼 수만 있다면 "CGI를 따르고 있다"라고 봐야 합니다.

단, 아래에 제가 jsp와 asp는 잘 모르겠다고 해놓은 것은 네크로멘서님의 글에서 처럼 내부적으로 독자적인 방식을 취하고 있는지 알 수 없기 때문입니다.
php외에 python, perl같은 경우는 php와 같이 서버모듈, 외부 인터프리터 두가지 모두 가능하며 CGI를 따르고 있습니다.

그래서 한국영화는 멜로인가요?

스펙을 대충 다시 읽어 보고 나니 음... 위에 제가 쓴 글 중 일부는 완전히 틀렸습니다. 그리고 이제서야 소타님의 의도가 제대로 이해 되었습니다. 제가 말했던 CGI의 환경변수, 표준입출력을 통한 통신 방식은 CGI 의 스펙의 필요조건이 아니네요. 명확하게 소통할 인터페이스만 정의해 주면 되는군요. 구체적으로는 'server' 와 'script' 간의 통신에 필요한 인터페이스를 '나름대로' 정하고, 나름대로 정하지 않을 경우 표준입출력을 사용한다. 그리고 인터페이스를 통해 server 에서 script 로 가는 데이터는 주어진 'meta-variable'을 사용해야 하는데, 따로 정의하지 않을 것이면 '환경변수'를 써라. 이게 핵심이었군요. 스펙을 제 멋대로 곡해하고 글을 쓴 부분에 대해서는 사과드리겠습니다.

이 세 용어를 정의 하는 부분에서 한방 맞은 듯한 느낌입니다. 통념과 스펙이 따로 놀았던 거군요. 저는 설마 script 가 저런 정의를 가졌을 줄은 정말 몰랐습니다. 이전에 스펙을 훑을 때도 그냥 대충 보고 넘어간 듯 하네요.

아예 못 박아 났군요. 특히 스크립트 정의 마지막 문장 참 대단합니다. '스크립트'라는 일반적인 용어는 실시간에 인터프리트 되는 statements 의 집합이지만 여기서의 스크립트가 그럴 필요는 없고 이 문맥에서는 더욱 넓은 정의를 가지는 것으로 되어 있네요. 그런데 script 라는 단어 자체가 오해를 불러일으키기 딱 좋은 듯한 느낌은 지워지지가 않는군요. ;

게다가 7.2 절에는 유닉스에서는 메타변수들이 환경변수로 정의 된다고도 써 있네요. ;;; 굳이 운영체제의 변수일 필요는 없다고 되어 있으면서도 이런 부분도 들어가 있군요... 머 SHOULD 나 MUST 가 붙지는 않았지만요 ^^;

그리고 수 많은 곳에서 쓰이고 있는 "CGI 방식" 이라는 표현은 이 스펙에 따르면 모두 틀린 표현이 되겠습니다. CGI 방식 이라고 했을 때, 저 스펙대로의 CGI 를 생각하는 사람은 아마 거의 없을 것입니다. 아니면 제가 지금까지 거의 없을 것이라고 믿어 왔던 것이거나요. "CGI 방식에 비해 모듈 방식은 훨씬 성능이 좋다" 라는 식의 표현을 대체 몇 번이나 봤는 지 기억도 못하겠습니다. 대부분 다른 프로세스 뛰우고 환경 변수, 표준 입력, 표준 출력을 통해 데이터 교환이라고 생각할 것도 같구요.

제 두뇌속에 CGI 를 다시 입력시켜야 겠습니다. 이 스펙대로라면 CGI 는 서버와 스크립트 간의 인터페이스이고 주어진 meta-variable 의 형식과 클라이언트가 자료를 요청하는 방식 등만 스펙을 지키면 되는 거군요. 단 쿼리를 받고 결과를 돌려 줄 방법만 잘 정의해 놓으면 되는 거구요. 이런 측면에서는 아파치 모듈 자체로 웹 애플리케이션을 만들어도 CGI 를 준수 할 수 있는 거 같습니다.

앞으로 CGI 방식을 언급할 때는 "과거에 CGI 를 구현했었던 방법" 이라고 해야 겠습니다. 그리고 아파치 웹 서버에 동적 혹은 정적으로 로드 혹은 로더 되어 있는 php 는 CGI를 구현 또는 준수하고 있다는 게 맞겠군요.

괜히 뒷북을 둥둥울렸지만 잘 알고 갑니다 ^^

... 라고 쓰고 쓰레드를 훑어 보니 제가 이미 논쟁을 했던 부분이네요 ;; 그리고 막상 제가 썼던 글을 다시 읽어보니, 아파치 서버 내에서 모듈로 웹 애플리케이션을 만들었을 때, 서버쪽에서 넘겨 받는 변수의 이름들이 CGI 스펙과 일치해야 CGI 를 준수 한다고 볼 수 있을 것 같은데 대부분의 경우 그렇게 넘겨 받을 리는 없으므로 CGI 를 준수 하지는 않겠고, mod_php 의 경우는 아파치가 mod_php 의 코드를 이용해서 로드된 php 스크립트에 CGI 형식의 변수 이름으로 데이터를 넘겨 준다면, CGI 를 준수하는 것이겠구요.

정의상 server 를 아파치+mod_php(server 는 서비스 요청을 받아 스크립트를 invoke 하는 프로그램이므로..) 로 보고 각 php 파일을 스크립트로 본다면 스크립트 내에서 cgi 규약의 meta-variable 을 볼 수 있으니, CGI 규약을 지키는 것이군요. fastcgi 의 경우도 웹서버(모듈 포함)의 요청을 cgi 규약 상의 meta-variable 형식으로 유닉스 도메인 소켓(scgi 경우)으로 넘겨주니 cgi 규약을 준수한다고 볼 수 있는 것이고, 머 그런 거군요.

스펙 상에서 스크립트는 서버상의 서브루틴 일 수도 있다고 했는데, 생각할 수록 스펙이 애매합니다. 서버상의 서브루틴이 스크립트라면 이 스크립트를 invoke 할 때 meta-variable 을 정해진 이름으로 넘겨야 되는데, 이 변수 이름은 아마도 소스코드 상에서의 변수이름이 되면 되는것인지도 궁금하네요. 아마도 그런 의미에서 썼을 거라 생각하지 만요. 그 전에 서버가 그 자신안에 있는 서브루틴을 invoke 한다는 표현이 과연 가능한 것인지도 궁금하구요.

결론적으로 CGI 규약을 준수하는 웹서버를 만들려면 현재의 방식으로 만들거나, 저 메타변수를 넘기는 방법과 결과를 받는 방법을 명확하게 정의 해놓으면 되겠네요.쓰레드 만들어진지 근 3개월 만에 조금 명확하게 인식한 것 같습니다. 아마 저 위에 글 쓸 때는 같은 주소 영역 내에서 데이터를 주고 받는데 무슨 놈의 인터페이스가 필요한 가라고 생각했을지도 모르겠네요. 사실 저만 몰라서 헤메었던 거 같기도 하고, 이렇게 구구절절 정의할 필요가 없어 보이지만서도 그냥 생각한 김에 올려 봅니다. ^^

그리고 애초의 질문에 대한 답은,
1. 프로그래밍 언어 PHP 는 당연히 CGI 와 같은 비교 범주가 아니다.
2. 웹서버가 실행시키는 실행파일 형식으로 된 php가 스크립트 파일을 읽어 들여서 사용하는 경우 CGI 를 준수한다. 웹서버인 아파치가 php 를 호출하고, php 프로그램이 'script'를 invoke 하고 이 때 스펙에서 주어진 조건을 충족하므로 cgi 규약을 지킨다. 이때 'server' 는 아파치 + php 라고 볼 수 있다.
3. 웹서버 모듈로 들어가 있는 경우 웹서버가 자신의 내부에 있는 실행코드를 이용해서 'script'를 invoke 하고 이 때 스크립트 파일 상에서 스펙에 주어진 것들을 볼 수 있으므로 CGI 규약을 지킨다. 'server' 는 apache with mod_php, 'script' 는 각 php 스크립트들, 'meta-variable'은 php 변수들(스펙대로라면 굳이 환경변수 일 이유가 없다.) 'sever' 와 'script' 가 데이터를 주고 받는 방식은 'server' 가 직접 'script'를 읽어들여서 직접 통신한다.
입니다.

...... 누가 보면 미친 줄 알겠습니다 ㅜㅜ