요청 라이프사이클 (Request Lifecycle)
소개
현실 세계에서 어떤 도구를 사용할 때, 그 도구가 어떻게 동작하는지 이해하면 더욱 자신감 있게 다룰 수 있습니다. 애플리케이션 개발도 다르지 않습니다. 개발 도구가 어떻게 작동하는지 알면, 작업할 때 훨씬 편안하고 자신감을 가질 수 있습니다.
이 문서의 목적은 라라벨 프레임워크가 어떻게 동작하는지에 대해 높은 수준에서 개괄적인 이해를 제공하는 것입니다. 전체적인 구조를 알게 되면, 모든 것이 ‘마법처럼’ 느껴지는 순간이 줄어들고, 여러분의 애플리케이션을 만들 때 더 큰 자신감을 가질 수 있습니다. 처음 보는 용어나 개념이 당장 모두 이해되지 않아도 괜찮으니, 전체 흐름만 먼저 파악할 수 있도록 노력해보세요. 다른 문서들을 살펴보다 보면 점차 이해가 깊어질 것입니다.
라이프사이클 개요
첫 단계
라라벨 애플리케이션으로 들어오는 모든 요청의 진입점은 public/index.php 파일입니다. 여러분의 웹 서버(Apache / Nginx) 설정에서 모든 요청이 이 파일로 전달됩니다. index.php 파일에는 복잡한 코드가 거의 없습니다. 오히려 이 파일은 프레임워크의 나머지 부분을 불러오는 시작점 역할을 합니다.
index.php 파일은 Composer에서 생성된 오토로더 정의를 불러오고, 그 다음 bootstrap/app.php에서 라라벨 애플리케이션 인스턴스를 가져옵니다. 라라벨이 처음으로 수행하는 동작은 애플리케이션(혹은 서비스 컨테이너) 인스턴스를 만드는 것입니다.
HTTP / 콘솔 커널
그 다음으로, 들어온 요청은 애플리케이션 인스턴스의 handleRequest 또는 handleCommand 메서드를 통해 HTTP 커널 또는 콘솔 커널로 전달됩니다. 즉, 애플리케이션에 어떤 종류의 요청이 들어오느냐에 따라 알맞은 커널로 요청이 전송됩니다. 이 두 커널은 애플리케이션으로 들어오는 모든 요청의 중심적인 역할을 하는 위치입니다. 여기서는 HTTP 커널에 집중하겠습니다. HTTP 커널은 Illuminate\Foundation\Http\Kernel의 인스턴스입니다.
HTTP 커널은 요청이 실행되기 전에 실행할 bootstrappers 배열을 정의합니다. 이 부트스트래퍼들은 에러 처리 설정, 로깅 설정, 애플리케이션 환경 감지, 그 외 요청을 실제로 처리하기 전에 필요한 여러 작업들을 수행합니다. 일반적으로 이 클래스들은 라라벨 내부 설정을 처리하며, 여러분이 직접 신경 쓸 필요는 거의 없습니다.
HTTP 커널은 또한 요청을 애플리케이션의 미들웨어 스택을 통해 전달하는 역할도 합니다. 미들웨어는 HTTP 세션 읽기와 쓰기, 애플리케이션이 유지보수 모드인지 확인, CSRF 토큰 검증 등 다양한 처리를 담당합니다. 이 미들웨어에 대해서는 아래에서 좀 더 자세히 설명하겠습니다.
HTTP 커널의 handle 메서드는 매우 단순하게 구성되어 있습니다. Request를 받아 Response를 반환합니다. 커널을 하나의 거대한 블랙박스라고 생각해보세요. HTTP 요청을 넣으면 HTTP 응답이 나옵니다.
서비스 프로바이더
커널 부트스트랩 동작 중 가장 중요한 것 중 하나는 애플리케이션의 서비스 프로바이더를 불러오는 것입니다. 서비스 프로바이더는 데이터베이스, 큐, 유효성 검증, 라우팅 등 프레임워크의 다양한 구성 요소를 부트스트랩하는 역할을 합니다.
라라벨은 이 프로바이더 목록을 순회하며 각 프로바이더를 인스턴스화합니다. 프로바이더 인스턴스가 만들어진 후에는 모든 프로바이더의 register 메서드가 호출됩니다. 모든 프로바이더가 등록되고 나면, 각 프로바이더의 boot 메서드가 호출됩니다. boot 메서드가 실행될 때쯤이면, 모든 서비스 컨테이너 바인딩이 등록되고 사용할 수 있는 상태가 되기 때문입니다.
라라벨의 거의 모든 주요 기능은 서비스 프로바이더를 통해 부트스트랩되고 설정됩니다. 즉, 프레임워크의 다양한 기능을 초기화하고 연결하는 핵심적인 역할을 서비스 프로바이더가 담당합니다. 그렇기 때문에 서비스 프로바이더는 라라벨 부트스트랩 과정에서 가장 중요한 부분이라고 할 수 있습니다.
프레임워크 내부적으로 수많은 서비스 프로바이더를 사용하지만, 여러분도 직접 자신만의 프로바이더를 만들 수 있습니다. 애플리케이션에서 사용하는 사용자 정의 또는 서드파티 서비스 프로바이더의 목록은 bootstrap/providers.php 파일에서 확인할 수 있습니다.
라우팅
애플리케이션이 모두 부트스트랩되고, 서비스 프로바이더가 등록되면, Request 객체가 라우터에 전달되어 디스패치(dispatch)됩니다. 라우터는 요청을 라우트 또는 컨트롤러에 연결하고, 해당 라우트에 할당된 미들웨어도 실행합니다.
미들웨어는 애플리케이션에 들어오는 HTTP 요청을 필터링하거나 검사할 수 있는 편리한 방법을 제공합니다. 예를 들어, 라라벨에는 사용자가 인증되었는지 확인하는 미들웨어가 포함되어 있습니다. 사용자가 인증되지 않은 경우, 미들웨어는 로그인 화면으로 리다이렉트합니다. 반면, 인증이 완료된 경우에는 요청이 애플리케이션의 다음 단계로 진행됩니다. 일부 미들웨어는 PreventRequestsDuringMaintenance처럼 모든 라우트에 적용되고, 어떤 미들웨어는 특정 라우트나 라우트 그룹에만 할당됩니다. 미들웨어에 대해서는 미들웨어 문서 전체에서 더 자세히 알아보실 수 있습니다.
요청이 해당 라우트에 할당된 모든 미들웨어를 통과하면, 라우트나 컨트롤러의 메서드가 실행되고, 그 메서드에서 반환된 응답이 다시 라우트의 미들웨어 체인을 따라 전달됩니다.
마무리 단계
라우트나 컨트롤러 메서드가 응답을 반환하면, 이 응답은 다시 한 번 라우트 미들웨어를 거쳐 나가면서, 애플리케이션이 최종적으로 응답을 수정하거나 검사할 기회를 갖게 됩니다.
마지막으로, 응답이 모든 미들웨어를 거치고 나면 HTTP 커널의 handle 메서드는 이 응답 객체를 애플리케이션 인스턴스의 handleRequest로 돌려주고, 이 메서드는 응답 객체의 send 메서드를 호출합니다. send 메서드는 응답 내용을 사용자의 웹 브라우저로 전송합니다. 이렇게 해서 라라벨 요청 라이프사이클의 전 과정을 모두 살펴봤습니다!
서비스 프로바이더 집중 탐구
서비스 프로바이더는 라라벨 애플리케이션의 부트스트랩 과정에서 진정한 핵심 역할을 합니다. 애플리케이션 인스턴스가 생성되고, 서비스 프로바이더가 등록된 다음, 준비된 애플리케이션에 요청이 전달됩니다. 전체 과정은 이처럼 간단합니다.
서비스 프로바이더를 통해 라라벨 애플리케이션이 어떻게 만들어지고 부트스트랩되는지에 대해 확실하게 이해하는 것은 매우 귀중합니다. 여러분의 애플리케이션에서 직접 만든 서비스 프로바이더는 app/Providers 디렉터리에 저장됩니다.
기본적으로, AppServiceProvider는 비어있는 상태로 제공됩니다. 이 프로바이더는 여러분의 애플리케이션에서 직접 부트스트랩 작업이나 서비스 컨테이너 바인딩을 추가하기에 좋은 장소입니다. 규모가 큰 애플리케이션이라면, 여러 개의 서비스 프로바이더를 만들어 각기 더 세분화된 부트스트랩이나 서비스를 담당하도록 구성하는 것이 좋습니다.