최근 수정 시각 : 2023-04-10 02:33:47

Common Gateway Interface

1. 개요2. 구조3. 단점

1. 개요

웹 서버에서 동적인 페이지를 보여 주기 위해 임의의 프로그램을 실행할 수 있도록 하는 기술 중 하나. 간혹 동적인 페이지는 다 CGI라고 생각하는 사람들이 있는데 CGI 말고도 이런 역할을 하는 기술은 여럿 있다. 단지 CGI가 맨 처음 나온 기술일 뿐.

원래 웹 서버는 서버에 저장되어 있는 고정된 문서를 보여 주는[1] 역할을 했다. 하지만 웹 서버에서 정보를 찾거나 기록을 하려면 웹 서버를 고쳐서 그런 기능을 넣어야 하는데 버틸 수 없으니, 대신 웹 서버가 특정한 URL로 들어가면 요청을 원하는 프로그램에 적절히 넘겨 주는 기술이 필요해졌는데 CGI가 그런 역할을 한다.

2. 구조

  1. (보통은 웹 브라우저 안에서, HTML의 폼을 통해) 요청이 웹 서버로 전달되면,
  2. 웹 서버는 요청에 들어 있는 주소가 CGI 프로그램에 대응되는지 확인해서,
  3. 대응되면 그 프로그램을 실행해서 환경 변수와 표준 입력의 형태로 요청을 전달한다. 어떻게 전달되는지는 표준이 있다.
  4. 웹 서버는 CGI 프로그램이 표준 출력으로 돌려 보낸 내용을 그대로 응답으로 돌려 준다.

참고로 좀 오래된 사이트에서 종종 /cgi-bin/으로 시작하는 주소를 볼 수 있는데, 이는 2번 과정에서 웹 서버가 해당 디렉토리에 들어 있는 프로그램을 모두 다 CGI 프로그램으로 인식하도록 되어 있는 경우이다. 요즘은 보안 문제 때문에 막무가내로 이런 식으로 하는 경우는 흔치 않고 웹 서버에서 설정할 수 있도록 해 놓는다. 2000년대 전후로 대한민국에도 인터넷 익스플로러를 통해 웹 브라우저로 접속이 가능해졌고, 그때쯤 붐이 일었던 개인 홈페이지 만들기에서 만든 홈페이지를 다른 사람과 교류하기위해 bbs프로그램을 계정에 설치해서 게시판 용도로 활용했는데, 이 극초창기때는 cgi가 개인 홈페이지 게시판 프로그램에 가장 널리 활용되었다. PHP는 개발 시기가 살짝 늦었고, 제로보드같은 php기반 게시판을 구동하려면 MySQL서버가 필요해서 유료로 서비스를 사용하기 때문에, 무료였던 cgi가 초창기의 주류였다. /cgi-bin/은 purybbs같은 무료 게시판 프로그램을 돌릴때 쓰던 디렉토리 지정 방식이었다.

맨 처음에 CGI 프로그램은 C언어 같은 컴파일 되는 언어를 이용해서 만들어졌으나, 유지보수가 불편하다는 단점이 있었다. 그런데 웹 서버가 흔히 동작하는 유닉스 환경에서는 스크립트 언어를 마치 보통의 실행 파일처럼 실행하는 기능(#!로 시작하는 파일들)이 있기 때문에, CGI 프로그램 또한 이러한 스크립트 언어를 통해 컴파일 없이 동작하는 방법으로 넘어가게 되었다. Perl이 사실은 딱히 웹 환경을 위해 만들어진 언어가 아님에도 한동안 인기를 끈 이유도, 사실 Perl이 CGI 라이브러리가 있는 (당시) 얼마 안 되는 스크립트 언어였기 때문이다.

3. 단점

이런 막강한 확장성을 가진 기술임에도 불구하고 CGI는 현재는 널리 쓰이지 않는데, 가장 큰 문제로 요청이 하나 들어 올 때마다 프로세스가 하나씩 실행된다는 것이 있다. 이는 특히 스크립트 언어에서 치명적이었는데 스크립트 언어에서는 보통 코드를 실행할 때마다 코드를 매번 해석해야 하기 때문이다. 물론 코드를 해석한 걸 캐싱하면 이 문제는 좀 나아지지만, 설령 C 언어 같은 언어로 미리 CGI 프로그램을 컴파일했다 하더라도 어지간한 환경에서는 프로세스 하나 실행하는데 몇 밀리초는 걸린다! 초당 수십건의 요청이 들어 오면 프로세스 실행하는 데만 시간을 다 소모할 것이다. 필요한 부분만 CGI로 만든다는 절충안을 쓴다 해도 요즘의 웹에는 동적인 것처럼 보이지 않아도 동적인 부분이 많기 때문에 적합하지 않다.

CGI를 대체하는 대부분의 기술들은 CGI의 이 단점을 해결하기 위해서 나온 게 보통이다. 몇 가지 예를 들면,
  • 웹 서버가 직접 스크립트 언어를 해석하고 그 결과를 캐싱해서 빠르게 실행할 수 있도록 하는 경우가 있다. 특히 웹 서버 모듈로 확장 가능한 웹 서버에서 흔히 쓰이는데, 이 기술로 흥한 대표적인 언어가 바로 PHP이다( 아파치 HTTP 서버의 mod_php 모듈). 근데 웃기게도 PHP 자체가 느려서[2] CGI를 안 쓰는 이득 중 상당수를 까먹는다(...). 그래도 CGI보다는 훨씬 빠르기 때문에 흥했다. 그리고 PHP 8에 JIT 컴파일이 도입된 2021년 기준으로는 느리다는 것도 옛날 이야기가 되었다.
  • CGI 프로그램이 한 요청만 처리하고 종료되는 게 아니라 요청을 계속 처리할 수 있도록 CGI를 개량한 경우가 있다. 이 중 언어와 상관 없는 기술로는 FastCGI와 이의 개량판 SCGI가 대표적이며, 내부적으로 이런 식으로 돌게 만들어진 언어별 솔루션들도 아주 많다. 대표적으로 PHP를 윈도우에서 IIS로 돌리거나 리눅스에서 NGINX로 돌릴 경우 FastCGI 모듈을 이용해서 돌린다.
  • 그냥 원하는 언어로 웹 앱 서버를 짠다![3] 이 경우 해당 프로그램은 항상 실행되어 있고, 웹 서버는 그 내부 서버를 중개하는 역할만 하게 된다. 이 쯤 되면 웹 서버의 존재 의의가 없어질 것 같지만, 이러한 내부 웹 서버들은 전용 웹 서버들에 비해서 보안이나 설정 편의성 면에서 한계가 있게 마련이니 나쁜 건 아니다.

다만 임의의 프로그램을 웹 서버에서 실행할 수 있다는 이유 때문에 오늘날에도 CGI는 이런 저런 용도로 종종 쓰이며, 어지간한 웹 서버는 CGI를 다 지원한다고 해도 과언이 아니다.

[1] 그보다 좀 더 옛날에는 마치 위키같이 문서를 바꾸는 기능도 있었다! HTTP의 PUT 메소드가 그 흔적. 하지만 트롤링을 못 견디고 당연히 얼마 안 가 사라졌다. [2] 오늘날 많은 주요 스크립팅 언어는 코드를 읽어서 바로 해석하는 게 아니라 내부적으로 어느 정도의 컴파일을 거치는데, PHP는 이 과정이 있으나 마나 할 정도로 느린 주제에 이걸 캐싱하는 솔루션을 최적화 솔루션이랍시고 팔아 먹는 어이를 상실하게 만드는 전략을 가지고 있었다! PHP 6이 개발에 난항을 겪으면서 PHP 5로 10년 넘게 버티는 바람에 엔진이 옛날 방식에 머무른 것이 가장 큰 문제였다. 이 문제는 PHP 7에서 차세대 엔진을 도입하면서 상당히 나아진 편이고, PHP 8에서는 JIT 방식의 컴파일을 도입했다. [3] Python, Ruby on Rails 등이 대표적.

분류