View
PHP는 매년 "이제 죽었다"고 욕을 먹지만 실제 웹의 75% 이상은 여전히 PHP로 굴러간다(W3Techs 2025 기준). 그 PHP 생태계 안에서 라라벨 프레임워크가 차지한 비중은 GitHub 스타 79K, Packagist 의존 패키지 13만+ 수준이다. Symfony, CodeIgniter 같은 경쟁자가 같이 존재함에도 라라벨 프레임워크 쪽으로 무게가 쏠린 이유가 본 글의 질문이다. 아래에서 GitHub 스타, Packagist 패키지 수, 채용 공고, 만족도 설문 수치를 직접 붙여 비교한다.

출처: ca.pinterest.com
일단 숫자로 깔고 시작 — Laravel과 다른 PHP 프레임워크 점유율 비교
말로만 "Laravel이 1위다"라고 하면 신뢰가 가지 않으므로 수치부터 살핀다. GitHub 스타, Packagist 의존 패키지 수, 개발자 설문이 모두 한쪽으로 기울어져 있다.
GitHub 스타와 패키지 생태계 비교
2025년 기준 PHP 프레임워크별 GitHub 스타와 Packagist 패키지 수치 비교는 다음과 같다.
| 프레임워크 | GitHub 스타 | Packagist 의존 패키지 | 최신 메이저 버전 |
| Laravel | 약 79,000+ | 130,000+ | Laravel 11 (2024.3) |
| Symfony | 약 30,000 | 40,000+ | Symfony 7.x |
| CodeIgniter | 약 18,000 | 5,000+ | CodeIgniter 4.x |
| Yii | 약 14,000 | 8,000+ | Yii 2.x (3 베타) |
| CakePHP | 약 9,000 | 6,000+ | CakePHP 5.x |
격차가 확인된다. Laravel은 2위 Symfony 대비 GitHub 스타 2.5배 이상, Packagist 의존 패키지 수는 3배 이상이다. Laravel 위에서 굴러가는 패키지 수가 다른 PHP 프레임워크 합산보다 많다는 사실이 수치로 드러난다.
개발자 만족도 설문 결과
Stack Overflow 2024 Developer Survey에서 Laravel은 PHP 프레임워크 중 admired 1위 자리를 유지한다. JetBrains의 Developer Ecosystem 2024 리포트에서도 PHP 개발자 절반 이상이 Laravel을 메인으로 쓴다고 답했다. 한국 채용 시장도 비슷한 흐름이다. 원티드/잡코리아에서 "PHP 백엔드"로 검색하면 Laravel을 명시적으로 요구하는 공고가 60~70% 수준으로 나오는데, 이는 2025년 4월 직접 검색 기준이므로 정확한 점유율이 아니라 체감 추정치 수준이다.
엘로퀀트(Eloquent) ORM이 편한 이유
라라벨 프레임워크 도입 후기에서 가장 자주 언급되는 것이 Eloquent ORM이다. ActiveRecord 패턴 기반이므로 다른 PHP 프레임워크 ORM보다 코드량이 적게 끝난다.
한 줄로 끝나는 관계 정의
Symfony가 사용하는 Doctrine ORM과 비교하면 차이가 보인다.
// Laravel Eloquent
class User extends Model {
public function posts() {
return $this->hasMany(Post::class);
}
}
// 사용
$user->posts; // 끝. 한 줄.
Doctrine은 어노테이션이나 YAML로 매핑을 정의하고 EntityManager로 가져와야 한다. 같은 일을 하는데 코드 양이 2~3배 차이가 난다. 신규 프로젝트에서 빠르게 모델을 만들고 관계를 정의해야 할 때 Eloquent 쪽이 손이 덜 간다.
마이그레이션과 시더가 기본 내장
php artisan make:migration 한 줄이면 마이그레이션 파일을 만들어주고, php artisan migrate 한 번에 DB 스키마가 적용된다. 시더(Seeder)로 더미 데이터를 넣는 작업도 표준화되어 있어 팀 협업 시 DB 상태를 맞추기 편하다. CodeIgniter나 Yii도 마이그레이션 도구가 존재하지만 명령어 통일성과 IDE 자동 완성 지원이 Eloquent보다 약하다.
단점도 솔직하게 — N+1 쿼리 함정
Eloquent도 만능은 아니다. ActiveRecord 패턴 특성상 N+1 쿼리 문제가 자주 터진다. $users를 가져와 각각의 $user->posts에 접근하면 뒤에서 쿼리가 N+1번 날아간다. with() 메서드로 eager loading을 걸지 않으면 트래픽이 조금만 늘어도 DB가 폭파된다. 다만 초당 수만 RPS 환경에서는 Doctrine처럼 명시적인 쿼리 빌더가 더 나을 수도 있다.
PHP 프레임워크 비교 — Laravel vs Symfony vs CodeIgniter
PHP 프레임워크를 비교할 때 사실상 이 셋이 메인 후보다. 항목별로 정리하면 아래 표와 같다.

출처: https://www.teepublic.com/magnet/31437719-laravel-logo?countrycode=US#2834P31437719D21V
| 항목 | Laravel | Symfony | CodeIgniter |
| 학습 곡선 | 중간 (시작 쉬움, 깊이 들어가면 가팔라짐) | 가파름 (DI 컨테이너 이해 필수) | 매우 쉬움 |
| 성능 | 중상 | 중상 (튜닝 시 최강급) | 상 (가벼움) |
| 생태계 | Packagist 13만+ 패키지 | Packagist 4만+ 패키지 | Packagist 5천+ 패키지 |
| 채용 시장 | 한국 PHP 공고 60~70%에서 명시 | 대형 SI 위주 | 레거시 위주 |
| 적합 프로젝트 | 스타트업~중대형 풀스택 | 대형 엔터프라이즈, 모듈식 | 빠른 프로토타입, 레거시 유지보수 |
Laravel vs Symfony — 풀스택 vs 모듈식
Symfony는 라이브러리 모음에 가깝다. 컴포넌트를 골라 조립하는 느낌이라 자유도는 높지만 그만큼 보일러플레이트가 많고 처음 잡으면 머리가 아프다. Laravel은 풀스택으로 다 쥐어준다. 라우팅, 큐, 인증, 메일 같은 핵심이 표준화되어 있어 의사결정 피로도가 낮다. 흥미로운 점은 Laravel 내부도 Symfony 컴포넌트 위에서 굴러간다는 사실이다. HttpFoundation, Console, Routing 같은 핵심은 Symfony 것을 가져다 쓴다. 그래서 "Laravel은 Symfony 위에 얹은 DX 레이어"라고 보면 대체로 맞다.
Laravel vs CodeIgniter — 모던 vs 가벼움
CodeIgniter는 가볍다. 압축을 풀고 바로 굴리면 된다. 학습 곡선도 거의 없다. 다만 모던 PHP 기능(의존성 주입, 미들웨어, 큐 시스템) 지원이 약하고 패키지 생태계가 빈약하다. 쓸 만한 곳은 빠른 프로토타입이나 기존 CodeIgniter 레거시 유지보수 정도다. 신규 프로젝트라면 CodeIgniter를 고를 이유가 없다.
Yii / CakePHP / Phalcon은 왜 시들해졌는가
Yii는 한때 잘 나갔으나 Yii 3 발표가 늦어지면서 개발자들이 떠났다. CakePHP는 ActiveRecord 원조급이지만 Laravel에게 DX로 밀린다. Phalcon은 C 익스텐션으로 짠 점이 매력 포인트이지만 설치/배포가 까다롭고 패키지 생태계가 빈약해 mainstream에서 빠졌다. 결국 PHP 프레임워크 비교는 Laravel vs Symfony 양강 구도로 정리된다.
Laravel 생태계 — 1군 패키지 정리
라라벨 프레임워크의 강점은 결국 생태계다. 공식+커뮤니티 패키지 퀄리티가 다른 PHP 프레임워크보다 한 단계 위에 있다.
Livewire와 Inertia.js
React/Vue 없이도 풀스택 PHP로 SPA 같은 UX를 뽑는 도구가 Livewire다. 백엔드 개발자가 프론트엔드를 깊이 파지 않고도 인터랙티브 UI를 만들 수 있다. Inertia.js는 반대로 Vue/React를 PHP 라우팅에 붙여 별도 API 없이도 SPA를 굴리게 해준다. 둘 다 Laravel 생태계 표준 도구라 채용 공고에서도 자주 보인다.
Filament — 어드민 패널 빌더
Filament는 Livewire 기반 어드민 패널 빌더다. 모델을 정의하고 리소스 클래스 한두 개를 만들면 CRUD + 검색 + 필터 + 권한까지 자동 생성된다. 모델 5개 정도 기준으로 Filament 공식 스타터를 따라가면 어드민 한 화면을 띄우는 데 30분~1시간 정도가 걸린다. Django Admin이나 Rails ActiveAdmin과 비교했을 때 커스터마이징 자유도 면에서 손에 잘 잡히는 편이라, 사이드 프로젝트나 사내툴을 만들 때 Laravel + Filament 조합은 시간 절약이 크다.
Forge, Vapor, Nova — 공식 유료 도구
Forge는 서버 프로비저닝/배포 자동화 SaaS다. AWS/DO/Linode에 Laravel을 배포할 때 클릭 몇 번이면 nginx, PHP-FPM, MySQL, Redis까지 셋업된다. Vapor는 AWS Lambda 위에 서버리스로 Laravel을 굴리는 도구다. Nova는 공식 어드민 패널인데, 요즘은 Filament 쪽으로 무게가 옮겨간 분위기다.
아티즌(Artisan) CLI와 Tinker
php artisan 명령어 하나로 라우트 확인, 마이그레이션, 큐 워커 실행, 컨트롤러 생성이 모두 가능하다. Tinker는 REPL인데 콘솔에서 Eloquent 모델을 바로 조작할 수 있어 디버깅할 때 편하다. 일상 DX 면에서 다른 PHP 프레임워크보다 한참 앞서 있다.
Laravel 11/12 최신 동향 — 2024~2025 변경점
Laravel은 매년 메이저 버전이 업데이트된다. 2024년 3월에 나온 Laravel 11이 구조적으로 큰 변화를 가져왔다.
Slim Skeleton — 디렉토리 구조 정리
Laravel 11에서 가장 눈에 띄는 변화가 슬림 스켈레톤(slim skeleton)이다. 기존에 있던 app/Http/Kernel.php, app/Console/Kernel.php, app/Exceptions/Handler.php 같은 파일들이 사라지고 bootstrap/app.php 하나로 통합된다. 미들웨어 등록, 예외 처리, 라우팅을 모두 그 안에서 설정한다. 신규 프로젝트는 디렉토리 구조가 간결해졌고, 기존 프로젝트는 그대로 굴러가므로 마이그레이션 압박은 없다.
새로 추가된 기능
Laravel 11에서 눈여겨볼 만한 추가 사항을 추려보면, 초당 단위로 요청 제한을 거는 per-second rate limiting이 들어왔고 /up 엔드포인트가 기본 제공되어 헬스체크 라우팅을 따로 짤 필요가 없어졌다. 결과 메모이제이션을 한 줄로 처리하는 Once 메서드, 디버깅용 dd/dump 메서드를 trait로 분리한 Dumpable trait도 추가됐다. 자세한 항목은 Laravel 11 릴리즈 노트에서 확인 가능하다.
Laravel 12 로드맵
Laravel 12는 2025년 1분기에 발표된 버전인데, 큰 구조 변경보다는 안정성/성능 개선 위주다(공식 릴리즈 노트 참고). PHP 8.3+를 요구하는 방향이라 레거시 PHP 7.x 환경에서는 마이그레이션 부담이 있을 수 있다. 새로 시작하는 프로젝트라면 Laravel 11 또는 12를 그대로 가져가는 것이 맞다.
Laravel 공식 docs에서 최신 변경점을 확인할 수 있으므로 버전을 올릴 때 release note를 확인하는 것을 추천한다.
그래서 라라벨은 항상 정답인가 — 단점
여기까지 보면 "Laravel 좋다"는 결론이지만, 다만 단점도 분명히 존재한다.
학습 곡선이 생각보다 가파른 부분
Laravel은 시작하기는 쉽지만, 깊이 들어가면 어려워진다. 특히 서비스 컨테이너(Service Container)와 파사드(Facade) 개념이 그렇다. 처음에는 Auth::user() 같은 호출을 그냥 쓰면 되지만, 내부에서 어떻게 굴러가는지 이해하려면 IoC 컨테이너, 서비스 프로바이더, 파사드의 정적 호출 마법까지 알아야 한다. 입문 튜토리얼을 따라 할 때는 보이지 않다가 실무에서 디버깅할 때 막히는 부분이다.
"마법이 너무 많아 디버깅이 어렵다"는 비판
Laravel을 두고 자주 나오는 비판 중 하나가 "magic이 너무 많다"는 점이다. Eloquent의 __get/__call 매직 메서드, 파사드의 정적 프록시, 서비스 컨테이너의 자동 의존성 해결 같은 부분에서 코드를 읽다가 "이게 어디서 호출되는 것인가?" 싶은 순간이 자주 온다. 왜일까? IDE 자동 완성도 잡히지 않는 경우가 있어 IDE Helper 플러그인을 깔아야 할 때도 있기 때문이다. Symfony처럼 명시적인 코드를 선호하는 사람에게는 맞지 않을 수 있다.
대규모 트래픽 대응
라라벨 프레임워크는 풀스택 모놀리스 프로젝트에 잘 맞지만, 초당 수만 RPS를 다루는 환경에서 그대로 쓰기는 빡세다. 옥테인(Octane)으로 Swoole/RoadRunner 위에 올리면 성능을 끌어올릴 수 있긴 하지만, 그 정도 트래픽이면 마이크로서비스로 쪼개거나 다른 스택 조합이 더 나을 수도 있다. 한국 스타트업 중에서도 PHP 모놀리스로 시작했다가 트래픽이 늘면서 Java/Kotlin/Node 같은 스택으로 갈아탄 사례가 종종 회자되는데, 정확한 시점·전환 사유는 각 회사 기술 블로그에서 따로 확인해야 한다(2차 인용이므로 단정은 보류한다).
신규 프로젝트라면 라라벨 프레임워크가 합리적인 디폴트다
수치 정리는 이 정도다. GitHub 스타 79K+, Packagist 패키지 13만+로 다른 PHP 프레임워크보다 큰 생태계가 가장 큰 차이이고, Eloquent ORM과 Artisan CLI, Blade, Livewire, Filament 같은 풀스택 도구가 한 묶음으로 제공되는 점도 결정적이다. 한국 PHP 채용 공고 또한 직접 검색 기준 60~70% 수준이 Laravel 명시였다. 단점은 매직이 많고 학습 곡선이 깊은 편이며, 초당 수만 RPS 트래픽에는 별도 튜닝이 필요하다는 점이다. 다만 이 단점들을 감안해도 신규 프로젝트에서 Symfony나 CodeIgniter를 우선 선택할 만한 근거는 약하다.
W3Techs PHP 사용률 기준으로 PHP 점유율은 75% 이상 유지 중이고, 라라벨 프레임워크는 그 안에서 1군 자리에 있다. 입문 자료는 Laravel 공식 docs와 Laracasts 비디오 시리즈가 가장 안정적이며, 한글 자료가 부족하면 영문 docs를 직접 읽는 것이 결국 빠른 길이다.
'Backend' 카테고리의 다른 글
| gRPC vs REST, 내부 통신에는 왜 모두 gRPC를 쓰는가 (0) | 2026.04.28 |
|---|---|
| FastAPI 백그라운드 태스크는 진정한 비동기인가? 서버 종료 시 살아남는가? (0) | 2026.04.28 |
| FastAPI는 누가 만들었고, 왜 빠른가. 비동기면 무조건 빠르다고 알고 있는가? (0) | 2026.04.23 |
| LLM API는 왜 REST와 다른가? POST만 사용하는 이유는 무엇일까? (1) | 2026.04.19 |
| Good Retry, Bad Retry 장애 스토리 (0) | 2024.11.27 |
