메인 콘텐츠로 건너뛰기

소개

도구를 “현실 세계”에서 사용하는 경우, 그 도구가 어떻게 동작하는지를 이해하고 있으면 더 자신감을 갖고 사용할 수 있습니다. 애플리케이션 개발에서도 마찬가지입니다. 개발 도구가 어떻게 기능하는지를 이해하면 더 편안하게, 자신감을 갖고 애플리케이션을 구축할 수 있습니다. 이 페이지에서는 Laravel 프레임워크가 어떻게 동작하는지에 대해 고수준의 개요를 설명합니다. 프레임워크 전체를 잘 이해함으로써 모든 것이 “마법”처럼 느껴지지 않게 되고, 애플리케이션 구축에 대한 자신감이 높아집니다.

HTTP 요청의 라이프사이클

전체 흐름

첫 단계

Laravel 애플리케이션에 대한 모든 요청의 진입점은 public/index.php 파일입니다. 모든 요청은 웹 서버(Apache / Nginx)의 설정에 따라 이 파일로 전달됩니다. index.php 파일 자체는 거의 코드를 포함하고 있지 않습니다. 프레임워크의 나머지 부분을 로드하기 위한 출발점입니다. index.php 파일은 Composer가 생성한 오토로더 정의를 로드하고, bootstrap/app.php에서 Laravel 애플리케이션의 인스턴스를 획득합니다. Laravel이 처음 수행하는 처리는 애플리케이션/서비스 컨테이너의 인스턴스를 생성하는 것입니다.

HTTP 커널

다음으로 받은 요청은 HTTP 커널(Illuminate\Foundation\Http\Kernel)로 전송됩니다. 애플리케이션 인스턴스의 handleRequest 메서드를 통해 처리됩니다. HTTP 커널은 요청이 실행되기 전에 실행되는 부트스트래퍼 배열을 정의하고 있습니다. 이 부트스트래퍼들은 다음 처리를 수행합니다. HTTP 커널은 요청을 애플리케이션의 미들웨어 스택으로 통과시키는 책임도 가집니다. 이 미들웨어들은 HTTP 세션의 읽기/쓰기, 애플리케이션이 유지 보수 모드인지의 확인, CSRF 토큰 검증 등을 처리합니다. HTTP 커널의 handle 메서드의 시그니처는 단순합니다. Request를 받고 Response를 반환합니다. 커널을 애플리케이션 전체를 나타내는 큰 블랙박스라고 생각해 주세요. HTTP 요청을 전달하면 HTTP 응답이 돌아옵니다.

서비스 프로바이더

커널의 부트스트래핑에서 가장 중요한 처리 중 하나가 애플리케이션의 서비스 프로바이더를 로드하는 것입니다. 서비스 프로바이더는 데이터베이스, 큐, 유효성 검증, 라우팅 등 프레임워크의 다양한 컴포넌트를 부트스트랩하는 책임을 가집니다. Laravel은 프로바이더 목록을 이터레이트하고 각 프로바이더를 인스턴스화합니다. 인스턴스화 후 모든 프로바이더의 register 메서드가 호출됩니다. 그다음 모든 프로바이더가 등록되면 각 프로바이더의 boot 메서드가 호출됩니다. 이를 통해 서비스 프로바이더는 boot 메서드가 실행되는 시점에 모든 컨테이너 바인딩이 등록·이용 가능한 상태가 되어 있습니다.
사용자 정의 또는 서드파티 서비스 프로바이더는 bootstrap/providers.php 파일에서 등록합니다.

라우팅

애플리케이션이 부트스트랩되고 모든 서비스 프로바이더가 등록되면 Request는 라우터로 전달되어 디스패치됩니다. 라우터는 요청을 라우트나 컨트롤러로 디스패치하고, 라우트 고유의 미들웨어도 실행합니다. 미들웨어는 애플리케이션에 들어오는 HTTP 요청을 필터링하거나 검사하는 편리한 구조를 제공합니다. 예를 들어 Laravel에는 사용자가 인증되어 있는지 확인하는 미들웨어가 포함되어 있습니다. 사용자가 인증되지 않은 경우 미들웨어는 로그인 화면으로 리다이렉트합니다. 인증된 경우에는 요청을 애플리케이션 내부로 진행시킵니다. 요청이 매칭된 라우트에 할당된 모든 미들웨어를 통과하면 라우트나 컨트롤러 메서드가 실행되고 응답이 반환됩니다.

응답 반환

라우트나 컨트롤러 메서드가 응답을 반환하면, 그 응답은 라우트의 미들웨어를 통과해 바깥쪽으로 돌아가면서 애플리케이션이 전송할 응답을 변경하거나 검사할 기회를 얻습니다. 최종적으로 응답이 미들웨어를 통과하면 HTTP 커널의 handle 메서드는 응답 객체를 애플리케이션 인스턴스의 handleRequest로 반환하고, 이 메서드가 반환된 응답의 send 메서드를 호출합니다. send 메서드는 응답의 내용을 사용자의 웹 브라우저로 전송합니다. 이것으로 Laravel의 요청 라이프사이클 전체의 여정이 완료됩니다.

Console 명령의 라이프사이클

전체 흐름

artisan 진입점

콘솔 명령의 진입점은 프로젝트 루트의 artisan 파일입니다. HTTP 요청과 마찬가지로 Composer의 오토로더와 Laravel 애플리케이션의 인스턴스가 생성됩니다. 다음으로 애플리케이션 인스턴스의 handleCommand 메서드를 통해 콘솔 커널로 처리가 전달됩니다.

콘솔 커널과 명령 실행

콘솔 커널도 HTTP 커널과 마찬가지로 서비스 프로바이더를 로드합니다. 모든 프로바이더가 등록·부트스트랩된 후, app/Console/Commands 디렉터리의 명령이 로드되고, 지정된 명령이 실행됩니다.
php artisan make:controller UserController
이 명령은 다음과 같이 처리됩니다.
  1. artisan 파일이 Composer 오토로더를 로드
  2. bootstrap/app.php에서 애플리케이션 인스턴스 생성
  3. 콘솔 커널이 서비스 프로바이더를 로드
  4. make:controller 명령을 검색해서 실행
  5. 종료 코드를 반환

서비스 프로바이더에 주목한다

서비스 프로바이더는 Laravel 애플리케이션을 부트스트랩하기 위한 진정한 열쇠입니다. 애플리케이션 인스턴스가 생성되고, 서비스 프로바이더가 등록되고, 요청이 부트스트랩된 애플리케이션에 전달된다. 그것뿐입니다. 서비스 프로바이더를 통해 Laravel 애플리케이션이 어떻게 구축·부트스트랩되는지를 확실히 파악하는 것은 매우 가치가 있습니다. 애플리케이션의 사용자 정의 서비스 프로바이더는 app/Providers 디렉터리에 저장됩니다.
기본 AppServiceProvider는 거의 비어 있는 상태입니다. 이 프로바이더는 애플리케이션 고유의 부트스트래핑이나 서비스 컨테이너의 바인딩을 추가하기에 최적의 장소입니다. 대규모 애플리케이션에서는 애플리케이션에서 사용하는 특정 서비스의 부트스트래핑을 세밀하게 나눈 여러 서비스 프로바이더를 만드는 것을 권장합니다.

register와 boot의 차이

서비스 프로바이더에는 두 가지 주요 메서드가 있습니다.
메서드타이밍용도
register모든 프로바이더의 인스턴스화 후 모두 호출됨서비스 컨테이너로의 바인딩 등록만
boot모든 프로바이더의 register 완료 후에 호출됨뷰 컴포저, 이벤트 리스너, 그 외 초기화
register 메서드 내에서 이벤트 리스너, 라우트, 그 외 기능을 등록하지 마세요. 아직 로드되지 않은 서비스 프로바이더가 제공하는 서비스를 실수로 사용해 버릴 가능성이 있습니다.

다음 단계

서비스 컨테이너

의존성 주입과 서비스 컨테이너의 구조를 이해합니다.

서비스 프로바이더

서비스 프로바이더를 사용해 애플리케이션을 부트스트랩하는 방법을 배웁니다.
마지막 수정일 2026년 7월 13일