공용 게이트웨이 인터페이스

3. 사양

1993년 NCSA 팀은 www-talk 메일링 리스트를 통해 명령 줄 실행 파일을 호출하는 방식에 대한 사양을 처음 작성했다.^{[12][1][2][3]} 비록 NCSA는 더 이상 이 초기 사양을 호스팅하지 않지만,^[13][14] 다른 웹 서버 개발자들이 이를 채택하면서 CGI는 웹 서버의 표준적인 기능으로 자리 잡게 되었다.

1997년 11월, 켄 코어(Ken Coar)가 주도하는 워크 그룹은 NCSA의 CGI 정의를 보다 공식적으로 확립하기 위한 작업을 시작했다.^[15][4] 이 노력의 결과로 2004년 RFC 3875 사양이 탄생했으며, 이는 CGI 버전 1.1을 기술한다.^[16][17] RFC 3875는 다음과 같은 인물들의 기여를 명시적으로 언급하고 있다:

역사적으로 CGI 프로그램은 C 프로그래밍 언어로 작성되는 경우가 많았다. RFC 3875 "공용 게이트웨이 인터페이스(CGI)"는 환경 변수가 "C 라이브러리 루틴 getenv() 또는 변수 environ에 의해 접근된다"고 언급하며 C 언어를 사용한 구현을 일부 예시하고 있다.

CGI라는 이름은 웹 초창기에 웹마스터들이 데이터베이스와 같은 기존 정보 시스템을 웹 서버에 연결하고자 했던 시도에서 유래했다. CGI 프로그램은 웹 서버와 이러한 기존 시스템 사이의 공통적인 게이트웨이 역할을 수행하도록 설계되었다.

CGI 사양은 빠르게 채택되어 아파치, 마이크로소프트 IIS 등 널리 사용되는 대부분의 HTTP 서버에서 계속 지원되고 있다. CGI는 웹 서버가 동적인 웹 페이지를 생성하기 위해 외부 프로그램을 실행하고 그 결과를 클라이언트에게 전달하는 표준화된 방법을 제공한다.

3. 1. CGI 프로그램의 동작 방식

• 환경 변수: 웹 서버는 CGI 프로그램을 호출할 때 여러 환경 변수를 정의한다.
• 클라이언트가 요청한 URI의 쿼리 문자열(Query String) 부분은 QUERY_STRING 환경 변수에 저장된다. 이는 HTML 폼에서 GET 메서드를 통해 전달된 데이터를 처리할 때 유용하다.
• 만약 QUERY_STRING에 등호(=) 문자가 포함되어 있지 않다면, 서버는 QUERY_STRING의 내용을 명령줄 인수로 CGI 프로그램에 전달할 수도 있다. 이는 과거 HTML의 ISINDEX 요소를 처리하기 위한 방식이었다.
• 클라이언트가 보낸 HTTP 요청의 본문(body) 데이터는 CGI 프로그램의 표준 입력으로 전달된다. 이때 데이터의 길이는 CONTENT_LENGTH 환경 변수에 저장된다. 이는 HTML 폼에서 POST 메서드를 통해 전달된 데이터를 처리할 때 주로 사용된다.
• 요청된 URI에서 CGI 프로그램 경로 뒤에 추가적인 경로 정보가 붙는 경우, 이 추가 경로는 PATH_INFO 환경 변수에 저장된다. 그리고 이 가상 경로(PATH_INFO)에 해당하는 실제 서버 상의 물리적 경로는 PATH_TRANSLATED 환경 변수에 저장된다. 이 방식 역시 사용자로부터 CGI 프로그램에 정보를 전달하는 데 사용될 수 있다.
• 표준 입력: 위에서 언급했듯이, 주로 POST 방식으로 전송된 데이터가 표준 입력을 통해 CGI 프로그램에 전달된다.
• 명령줄 인수: QUERY_STRING에 =가 없는 경우 등 특정 상황에서 사용될 수 있다.

4. 배포

웹 서버는 CGI를 지원하도록 설정될 수 있으며, 특정 URL을 CGI 스크립트에 대한 참조로 해석한다. 일반적인 관례 중 하나는 웹 서버의 디렉토리 구조 내에 `cgi-bin/`이라는 특정 디렉토리를 두는 것이다. 이 디렉토리 안에 있는 실행 파일들은 웹 서버에 의해 CGI 스크립트로 취급된다. 예를 들어, 웹 브라우저가 `cgi-bin/` 디렉토리 내의 파일을 가리키는 URL(예: `http://example.com/cgi-bin/printenv.pl/with/additional/path?and=a&query=string`)을 요청하면, HTTP 서버는 해당 파일을 단순히 전송하는 대신 지정된 스크립트를 실행하고 그 결과를 웹 브라우저로 전달한다. 즉, 스크립트가 표준 출력으로 보내는 모든 내용은 웹 클라이언트로 전달된다.^[6]

또 다른 일반적인 관례는 특정 파일 확장자를 사용하는 것이다. 예를 들어, CGI 스크립트에 일관되게 `.cgi` 확장자를 부여하면, 웹 서버는 이 확장자를 가진 모든 파일을 CGI 스크립트로 해석하도록 구성할 수 있다. 이는 편리하며 많은 기존 스크립트에서 요구되지만, 만약 원격 사용자가 적절한 확장자를 가진 실행 가능한 코드를 서버에 업로드할 수 있다면 보안상 취약점이 될 수 있다.^[6]

CGI 사양은 웹 서버가 스크립트에 추가 정보를 전달하는 방법을 정의한다. 웹 서버는 요청과 관련된 HTTP 환경 정보를 포함한 환경 변수를 생성하여 스크립트에 전달한다. 예를 들어, URL 경로에서 스크립트 이름 뒤에 추가 경로 정보(예: `/with/additional/path`)가 오면, 이 정보는 `PATH_INFO` 환경 변수에 저장된다. HTTP GET 요청을 통해 URL의 물음표 뒤에 매개변수(예: `?and=a&query=string`)가 전달되면, 이 매개변수들은 `QUERY_STRING` 환경 변수에 저장된다. HTTP POST 요청과 같이 HTTP 메시지 본문을 통해 데이터가 전송되는 경우, 이 데이터는 스크립트의 표준 입력으로 전달된다. 스크립트는 이러한 환경 변수나 표준 입력의 데이터를 읽어 웹 브라우저의 요청에 맞게 동작할 수 있다.^[6]

5. 용도

CGI는 사용자로부터 입력받은 정보를 처리하고 그에 맞는 적절한 결과물을 만드는 데 자주 사용된다. 초창기 CGI 스크립트의 주요 사용 사례 중 하나는 HTML 폼을 처리하는 것이었다. 당시 HTML 폼에는 일반적으로 "action" 속성과 "submit" 버튼이 있었는데, 사용자가 제출 버튼을 누르면 "action" 속성에 지정된 URI로 폼 데이터가 쿼리 문자열 형태로 서버에 전송되었다. 만약 "action" 속성에 CGI 스크립트가 지정되어 있다면, 해당 스크립트가 실행되어 결과적으로 새로운 HTML 페이지를 생성했다.

CGI 프로그램의 구체적인 예시로는 위키 시스템 구현을 들 수 있다. 사용자가 특정 위키 항목의 이름을 요청하면, 웹 서버는 해당 요청을 받아 CGI 프로그램을 실행시킨다. CGI 프로그램은 요청된 항목의 페이지 원본 데이터(소스)를 찾아 HTML 형식으로 변환한 뒤 결과를 출력한다. 웹 서버는 이 출력 결과를 받아 사용자에게 다시 전송한다. 사용자가 페이지 편집 버튼을 클릭하면, CGI 프로그램은 해당 페이지의 내용을 담은 HTML 텍스트 영역(textarea)이나 다른 편집용 컨트롤을 화면에 표시한다. 마지막으로 사용자가 페이지 게시 버튼을 클릭하면, CGI 프로그램은 수정된 내용을 다시 해당 항목 페이지의 원본 데이터 형식으로 변환하여 저장하는 방식으로 작동한다.

6. 보안

CGI 프로그램은 기본적으로 웹 서버의 보안 컨텍스트에서 실행된다. 초기 CGI가 도입될 때, NCSA, 아파치, CERN 웹 서버 등의 참조 배포판에는 쉘 스크립트나 C 프로그램을 이용해 CGI를 활용하는 방법을 보여주는 여러 예제 스크립트가 포함되어 있었다. 그중 하나가 간단한 전화번호부 기능을 구현한 PHF라는 CGI 프로그램이었다.

당시 다른 여러 스크립트처럼 PHF 스크립트도 사용자 입력을 검증하고 이를 유닉스 쉘에 전달하기 위해 `escape_shell_cmd()` 함수를 사용했다. 이 함수는 웹 서버의 보안 컨텍스트에서 명령이 실행되도록 설계되었으나, 모든 사용자 입력을 올바르게 검증하지 못하는 취약점이 있었다. 공격자는 입력값에 새 줄 문자를 삽입하는 방식으로 여러 개의 쉘 명령을 실행할 수 있었고, 그 결과는 웹 서버를 통해 그대로 노출되었다. 웹 서버가 가진 권한 내에서 악의적인 명령 실행이 가능했던 것이다.

이 사건은 검증되지 않은 웹 사용자 데이터가 웹 서버에서 코드 실행으로 이어질 수 있음을 보여준 최초의 광범위한 코드 삽입 공격 사례였다. 문제가 된 예제 코드가 기본적으로 설치되는 경우가 많았기 때문에 공격은 광범위하게 이루어졌고, 1996년 초에는 여러 관련 보안 권고가 발표되었다.^[7] 이러한 CGI 보안 취약점은 한국에서도 초기 웹 해킹의 주요 원인 중 하나로 지적되었으며, 이에 대한 주의와 대응이 중요하게 요구되었다.

7. CGI 이외의 대안

CGI는 HTTP 요청이 들어올 때마다 새로운 프로세스를 생성하고 요청 처리가 끝나면 파괴하는 방식으로 동작한다. 이 과정, 특히 프로세스를 생성하고 파괴하는 작업은 상당한 계산 오버헤드를 유발하며, 이는 웹 서버의 성능에 부담을 줄 수 있다. 특히 인터프리터 언어로 작성된 스크립트의 경우나 HTTP 요청 수가 많을 때 이 문제는 더욱 심화되어 웹 서버를 빠르게 압도할 수 있다.^[5]

이러한 CGI의 비효율성을 개선하기 위해, 각 요청마다 프로세스를 새로 만드는 대신 더 효율적으로 동적 콘텐츠를 처리할 수 있는 다양한 대안 기술들이 개발되었다. 이러한 기술들은 웹 서버의 부하를 줄이고 응답 속도를 향상시키는 것을 목표로 한다. 구체적인 대안 기술들에 대해서는 이어지는 하위 섹션들에서 자세히 설명한다.

7. 1. 웹 서버 확장

• 아파치 웹 서버의 모듈: `mod_perl`, `mod_php`, `mod_python`과 같은 모듈을 사용하여 각각 펄, PHP, 파이썬 스크립트를 아파치 프로세스 내에서 직접 실행할 수 있다.
• NSAPI 플러그인: 과거 넷스케이프 웹 서버에서 사용된 확장 인터페이스이다.
• ISAPI 플러그인: 마이크로소프트의 IIS 웹 서버에서 사용하는 확장 인터페이스이다.

7. 2. 외부 애플리케이션 프로세스

7. 3. 기타 대안

• 미리 컴파일된 프로그램: C나 C++처럼 기계어로 미리 컴파일된 프로그램을 사용하면 인터프리터를 사용하는 스크립트보다 빠르게 실행될 수 있다.
• 웹 서버 확장: 아파치의 모듈(예: `mod_perl`, `mod_php`, `mod_python`)이나 NSAPI, ISAPI 플러그인처럼 웹 서버 내에서 직접 코드를 실행하여 프로세스 생성 오버헤드를 줄인다. 이 방식은 여러 요청을 처리하는 장기 실행 애플리케이션 프로세스를 허용한다.
• 장기 실행 외부 프로세스: FastCGI, SCGI, AJP와 같은 기술은 웹 서버 외부에 별도의 애플리케이션 프로세스를 두고 여러 요청을 처리하게 한다. 웹 서버는 정적 콘텐츠는 직접 처리하고, 동적 콘텐츠 요청만 이 외부 프로세스에 전달한다. 이 방식은 웹 서버 확장 방식보다 메모리를 적게 사용하고 웹 서버와 애플리케이션을 분리할 수 있다는 장점이 있다.
• 자카르타 EE: 웹 컨테이너에서 서블릿 애플리케이션을 실행하여, 프로세스 생성/파괴 대신 훨씬 가벼운 스레드 생성/파괴 오버헤드로 동적 콘텐츠를 처리한다. Java SE 라이브러리 활용도 가능하다.
• 독립형 HTTP 서버: 애플리케이션 자체에 HTTP 서버 기능을 내장하는 방식이다.
• 언어별 게이트웨이 인터페이스: 웹 서버와 특정 프로그래밍 언어로 작성된 애플리케이션 간의 통신을 위한 표준화된 방법을 제공한다.
• WSGI (Web Server Gateway Interface): 파이썬을 위한 표준 인터페이스로, PEP 3333^[8]에 정의되어 있다. `mod_wsgi` (아파치 모듈), Gunicorn, uWSGI 등 다양한 구현체가 있다.
• PSGI: 펄을 위한 인터페이스이다.
• 이 외에도 PHP의 `mod_php` 등 언어 인터프리터를 웹 서버에 통합하는 방식이 널리 사용된다.

• Nginx: https://www.nginx.com/resources/wiki/start/topics/examples/fcgiwrap/ FCGI Wrap을 통해 FastCGI로 동작시킨다.
• H2O: https://h2o.examp1e.net/configure/cgi.html fastcgi-cgi를 통해 FastCGI로 동작시킨다.
• OpenBSD httpd: https://man.openbsd.org/slowcgi.8 slowcgi를 통해 FastCGI로 동작시킨다.

8. CGI에 관한 오해

이름에서 알 수 있듯이, CGI는 어디까지나 인터페이스이며, 특정 플랫폼에 의존하지 않고 웹 서버 등으로부터 외부 프로그램을 호출하는 조합을 가리킨다.

그러므로 그 조합을 사용하여 실행되는 프로그램 본체를 CGI라고 부르는 것은 잘못된 것이다. 또한, 1990년대 후반 CGI를 사용한 프로그램은 펄(Perl)이 대부분이었기 때문에 CGI와 펄, 또는 특정 프로그래밍 언어를 동일시하는 인식도 널리 퍼져 있으나, 이것도 잘못된 인식이다.

참조

_[1] 간행물 Server Scripts http://1997.webhisto[...] 2019-05-15
_[2] 웹사이트 The Common Gateway Interface http://hoohoo.ncsa.u[...] National Center for Supercomputing Applications (NCSA)
_[3] 웹사이트 CGI: Common Gateway Interface http://www.w3.org/CG[...] World Wide Web Consortium 2019-05-15
_[4] 웹사이트 Common Gateway Interface RFC Project Page http://ken.coar.org/[...]
_[5] 웹사이트 Mapping URLs to Filesystem Locations Apache HTTP Server Version 2.2 http://httpd.apache.[...] 2014-07-16
_[6] 서적 Building Electronic Commerce with Web Database Constructions Addison Wesley
_[7] 웹사이트 phf CGI Script fails to guard against newline characters https://www.kb.cert.[...] 2019-11-21
_[8] 웹사이트 PEP 3333 – Python Web Server Gateway Interface v1.0.1 https://peps.python.[...] 2024-04-05
_[9] 문서 CGI 【Common Gateway Interface】 https://e-words.jp/w[...]
_[10] 문서 CGI https://xtech.nikkei[...]
_[11] 문서 CGIプログラミング(1) http://www.rsch.tuis[...]
_[12] 문서 Server Scripts http://1997.webhisto[...]
_[13] 인용 The Common Gateway Interface http://hoohoo.ncsa.u[...]
_[14] 문서 CGI: Common Gateway Interface http://www.w3.org/CG[...]
_[15] 웹인용 Common Gateway Interface RFC Project Page http://ken.coar.org/[...]
_[16] 웹인용 보관된 사본 http://hoohoo.ncsa.u[...] 2007-08-09
_[17] 웹인용 보관된 사본 http://www.ietf.org/[...] 2009-07-16