CGI, WSGI, ASGI는 웹 서버와 웹 애플리케이션 간의 통신을 위한 프로토콜이다. 각각의 기술은 특정한 요구사항과 사용 사례에 맞춰 발전해왔다. 이 문서에서는 각 기술의 정의, 동작 방식, 장단점을 설명한다.

CGI (Common Gateway Interface)

CGI는 웹 서버와 웹 애플리케이션 간의 표준 인터페이스이다. 사용자가 웹 서버에 요청을 보내면, 서버는 CGI를 통해 해당 요청을 웹 애플리케이션으로 전달한다. 이때 웹 애플리케이션은 요청에 따라 동적으로 생성된 HTML을 반환한다. 하지만 CGI의 가장 큰 단점은 요청이 들어올 때마다 새로운 프로세스를 생성해야 한다는 점이다.

이러한 프로세스 생성은 많은 자원을 소모하고, 동시에 많은 요청이 들어올 경우 성능 저하를 초래한다. 특히 파이썬과 같은 스크립트 언어에서는 C와 같은 컴파일된 언어보다 훨씬 더 많은 시간이 필요하므로 비효율성이 더욱 두드러진다.

WSGI (Web Server Gateway Interface)

WSGI는 CGI의 단점을 보완하기 위해 만들어진 파이썬 전용 인터페이스이다. WSGI는 요청을 처리하기 위해 새로운 프로세스를 생성하는 대신, callable object(함수나 객체)를 통해 요청을 처리한다. 서버는 요청에 대한 정보와 Callback 함수를 전달하며, 애플리케이션은 이 정보를 사용하여 요청을 처리하고 Callback 함수를 실행한다.

WSGI의 주요 장점은 요청 처리 속도가 빠르다는 점이다. 서버와 애플리케이션 간의 연결이 지속적이기 때문에 요청이 올 때마다 프로세스를 새로 시작할 필요가 없다. 또한, 인증이나 쿠키 관리와 같은 기능을 수행하는 WSGI Middleware를 통해 기능 확장이 용이하다.

ASGI (Asynchronous Server Gateway Interface)

ASGI는 WSGI의 정신적 계승자로, 비동기적인 요청 처리를 지원하는 인터페이스이다. WSGI가 동기적인 요청 처리만 지원하는 반면, ASGI는 동기성과 비동기성 모두를 지원한다. 이로 인해 ASGI는 웹 소켓과 같은 장기 연결을 필요로 하는 애플리케이션에 적합하다.

ASGI는 비동기 요청 처리를 가능하게 하여, 서버와 클라이언트 간의 연결이 길어질 때도 효율적으로 데이터를 주고받을 수 있도록 한다. ASGI 서버로는 Uvicorn 등이 널리 사용된다.

왜 CGI가 필요한가.

웹 서버가 CGI와 같은 인터페이스를 통해 WAS(Web Application Server)로 가야하는 이유는 다음과 같다:

  1. 표준화된 통신: CGI는 웹 서버와 애플리케이션 간의 표준화된 방법을 제공한다. 이를 통해 다양한 서버와 언어에서 호환성 있게 동작할 수 있다. WAS와의 통신을 위한 공통의 프로토콜을 제공함으로써, 서버와 애플리케이션의 결합도를 낮추고 유연성을 높인다.

  2. 동적 컨텐츠 생성: 정적인 웹 페이지가 아닌 동적인 콘텐츠를 생성하기 위해 웹 서버는 CGI를 통해 요청을 애플리케이션으로 전달해야 한다. 애플리케이션은 요청을 처리한 후 동적으로 생성된 HTML을 반환하여 사용자에게 적절한 응답을 제공한다.

  3. 요청 처리의 분리: 웹 서버는 정적인 파일 요청을 처리하고, 동적인 요청은 CGI를 통해 WAS에 전달하여 처리하도록 함으로써, 요청 처리 로직을 분리할 수 있다. 이를 통해 웹 서버는 더 간단한 역할만 수행하게 되고, 애플리케이션 로직은 WAS에서 처리되도록 할 수 있다.

  4. 확장성과 유지보수성: 웹 서버와 WAS 간의 명확한 경계를 설정함으로써, 시스템의 확장성과 유지보수성을 높일 수 있다. 애플리케이션을 변경하거나 확장할 때, 웹 서버와의 연결이 일정하게 유지되므로 시스템 전체에 미치는 영향을 최소화할 수 있다.

  5. 미들웨어 사용: CGI는 미들웨어를 사용하여 인증, 세션 관리, 데이터 처리 등의 기능을 수행할 수 있는 유연성을 제공한다. 이러한 미들웨어는 WAS와의 통신을 통해 다양한 기능을 추가할 수 있도록 해준다.

이러한 이유들로 인해 웹 서버는 CGI와 같은 인터페이스를 통해 WAS로 요청을 전달하여 동적인 웹 애플리케이션을 효과적으로 운영할 수 있다.

Web Framework로 보는 CGI의 사용

node.js, Spring과 같은 애플리케이션 모두 CGI, ASGI, WSGI가 필요한가?

  • node.js는 비동기 이벤트 기반의 서버 환경을 제공하며, 자체적으로 HTTP 요청 처리 방식이 내장되어 있다. 따라서 CGI, WSGI, ASGI와 같은 별도의 프로토콜 없이 동작할 수 있다. Spring은 주로 WSGI와 유사한 방식으로 동작하지만, Java 기반이기 때문에 Java Servlet API를 사용하여 HTTP 요청을 처리한다. 따라서 CGI는 필요하지 않으며, WSGI 또는 ASGI에 해당하는 방식이 필요할 수 있다. 하지만 각 언어와 프레임워크에 맞는 웹 서버와 인터페이스를 사용하는 것이 일반적이다.

Django

Django는 Python 기반의 웹 프레임워크로, WSGI(Web Server Gateway Interface) 표준을 사용하여 웹 서버와 애플리케이션 간의 통신을 처리한다. WSGI는 동기적인 요청-응답 모델을 제공하는 표준으로, Django는 이를 통해 HTTP 요청을 처리하고 적절한 응답을 반환하는 구조를 갖추고 있다.

Django의 요청 처리 과정에서, 웹 서버는 들어오는 HTTP 요청을 WSGI 애플리케이션에 전달하고, 이 애플리케이션은 요청을 처리한 후 HTTP 응답을 다시 웹 서버로 반환한다. 이 과정에서 Django는 URL 라우팅, 뷰 로직 처리, 데이터베이스 접근 등을 통해 동적인 웹 페이지를 생성한다.

Django는 또한 MIDDLEWARE 개념을 사용하여 요청과 응답 사이에서 추가적인 처리를 수행할 수 있도록 한다. 이는 인증, 세션 관리, 쿠키 처리와 같은 다양한 기능을 손쉽게 통합할 수 있게 해준다.

Django는 WSGI를 통해 안정적이고 효율적인 웹 애플리케이션 개발을 가능하게 하며, RESTful API와 같은 비즈니스 로직을 처리하는 데에도 유용하다. Django는 이러한 구조 덕분에 대규모 웹 애플리케이션에서 높은 성능을 발휘할 수 있다.

node.js

Node.js는 전통적인 의미의 CGI(Common Gateway Interface)를 직접적으로 사용하지 않지만, CGI의 개념과 비슷한 방식으로 작동할 수 있는 여러 기능과 모듈을 제공합니다. Node.js는 비동기 I/O와 이벤트 기반 아키텍처를 사용하여 높은 성능을 자랑하며, HTTP 서버를 쉽게 구축할 수 있도록 해줍니다.

CGI는 기본적으로 웹 서버가 애플리케이션 스크립트를 실행하여 동적인 콘텐츠를 생성하는 방식이지만, Node.js에서는 웹 서버 자체가 JavaScript 코드로 작성되므로, 동적인 콘텐츠를 생성하는 과정이 더 직접적이고 효율적입니다.

다음은 Node.js와 CGI의 비교입니다:

  1. 동적 콘텐츠 생성: CGI는 서버가 스크립트를 실행하고 그 결과를 클라이언트에 반환하는 구조인 반면, Node.js는 애플리케이션이 웹 서버와 동일한 프로세스에서 실행되므로 동적 콘텐츠 생성을 위한 오버헤드가 적습니다.

  2. 비동기 처리: Node.js는 비동기 이벤트 기반 모델을 사용하여 요청을 처리하므로, 여러 요청을 동시에 처리하는 데 유리합니다. 반면, 전통적인 CGI는 각 요청에 대해 별도의 프로세스를 생성하므로 성능 저하가 발생할 수 있습니다.

  3. 표준화된 인터페이스: CGI는 표준화된 인터페이스를 제공하지만, Node.js는 HTTP 모듈을 사용하여 더 많은 제어와 유연성을 제공합니다. 이는 개발자가 HTTP 요청 및 응답을 더 세밀하게 다룰 수 있게 해줍니다.

결론적으로, Node.js는 CGI의 필요성을 줄이고, 더 효율적인 방법으로 동적 웹 애플리케이션을 구현할 수 있는 도구를 제공합니다.

Spring

Spring 프레임워크에서는 전통적인 의미의 CGI(Common Gateway Interface)를 사용하지 않지만, CGI의 개념을 기반으로 한 여러 가지 기능을 제공한다. Spring은 Java 기반의 웹 애플리케이션 개발을 위한 프레임워크로, MVC 패턴을 따르며, Servlet API를 통해 HTTP 요청을 처리한다.

Spring에서 HTTP 요청은 Servlet을 통해 처리되며, 이 과정에서 JSP, Thymeleaf와 같은 템플릿 엔진을 사용하여 동적인 콘텐츠를 생성한다. 이는 CGI가 웹 서버가 외부 스크립트를 실행하여 동적 페이지를 생성하는 방식과 유사하지만, Spring은 더 높은 성능과 확장성을 제공한다.

Spring은 또한 Spring Boot와 같은 추가 기능을 통해 RESTful 웹 서비스 개발을 더욱 간편하게 만들어준다. Spring의 이러한 구조는 여러 요청을 동시에 처리할 수 있는 비동기 처리를 지원하며, 더 나아가 Spring WebFlux를 통해 비동기 및 논블로킹 프로그래밍 모델을 제공한다.

결론적으로, Spring은 CGI의 필요성을 줄이면서도 동적인 웹 콘텐츠 생성을 위한 다양한 기능을 제공하는 현대적인 웹 프레임워크이다.

왜 WAS는 비동기적으로 요청을 처리해야하는가

웹 애플리케이션 서버는 비동기적으로 요청을 처리해야 하는 이유는 여러 가지가 있다.

첫째, 비동기 처리는 동시에 많은 요청을 효율적으로 처리할 수 있게 해준다. 이는 특히 사용자 수가 많거나 요청 처리 시간이 긴 경우에 유용하다. 비동기 방식은 서버가 요청을 기다리는 동안 다른 작업을 수행할 수 있도록 하여 자원의 활용도를 극대화할 수 있다.

둘째, 비동기 처리는 실시간 기능을 요구하는 애플리케이션에 유리하다 예를 들어 채팅 애플리케이션이나 온라인 게임, 실시간 데이터 스트리밍 서비스 등에서 매우 중요하다. 이러한 애플리케이션은 사용자와 서버 간의 지속적인 연결을 필요로 하며, 비동기 처리를 통해 서버는 각 사용자와의 연결을 유지하면서도 다른 작업을 동시에 수행할 수 있다.

셋째, 비동기 요청 처리는 시스템의 응답성을 향상시킨다. 사용자가 요청을 보내고 응답을 기다리는 동안 서버가 다른 요청을 처리할 수 있기 때문에, 전체 시스템의 대기 시간이 줄어들고 사용자 경험이 개선된다.

마지막으로, 비동기 처리는 자원 낭비를 줄이고, 서버의 성능을 최적화하는 데 도움을 준다. 요청이 블로킹(blocking) 상태에 빠지지 않고 다른 요청을 처리할 수 있으므로, 서버의 부하를 효과적으로 관리할 수 있다. 이러한 점들 때문에 웹 애플리케이션 서버는 비동기적으로 요청을 처리하는 것이 필요하다.

참조