Laravel 운영 Do Not Do List¶
운영 서버에서 Laravel 서비스를 운용할 때 절대 사용하면 안 되는 패턴을 정리함.
아래 항목들은 실제로 장애, 보안 사고, 복구 실패를 반복적으로 유발함.
0. 전제 (중요)¶
- 운영 서버는 "일단 되게"가 아니라 "항상 같은 방식으로 복구"가 기준임
- 임시 편의는 대부분 다음 장애의 원인이 됨
1. 운영 서버에서 php artisan serve 실행¶
잘못된 패턴¶
php artisan serve --host=0.0.0.0 --port=8000
왜 문제인가¶
- 개발용 내장 서버를 운영에 사용
- 재부팅 복구/장애 대응/성능 기준 미충족
운영 기준¶
운영 HTTP 처리는 반드시
nginx + php-fpm으로 수행함.
2. /var/www/.../current에서 composer install 직접 수행¶
잘못된 패턴¶
cd /var/www/[ProjectName]/current
composer install
왜 문제인가¶
- 운영 상태 오염
- 동일 버전 재현 어려움
- 롤백 복잡도 급증
운영 기준¶
의존성 변경은
/home/[User]/[ProjectName]에서 수행 후 배포함.
3. APP_DEBUG=true 상태로 운영¶
잘못된 패턴¶
APP_ENV=production
APP_DEBUG=true
왜 문제인가¶
- 에러 페이지를 통한 민감정보 노출
- 내부 경로/구조 노출
운영 기준¶
운영 서버는
APP_DEBUG=false고정.
4. 프로젝트 전체에 777 권한 부여¶
잘못된 패턴¶
chmod -R 777 /var/www/[ProjectName]/current
왜 문제인가¶
- 권한 과다로 보안 사고 위험 상승
- 감사 기준 위반 가능성 증가
운영 기준¶
- writable 경로는
storage,bootstrap/cache로 제한 - 최소 권한 + SELinux 정책 적용
5. SELinux를 끄거나 임시 우회로 종료¶
잘못된 패턴¶
sudo setenforce 0
# 또는
SELINUX=disabled
# 또는
sudo chcon -R -t httpd_sys_rw_content_t /var/www/[ProjectName]/current
왜 문제인가¶
- 보안 모델 붕괴
- 재부팅/재배포 후 동일 장애 반복
- 정책 추적 불가
운영 기준¶
semanage fcontext + restorecon으로 필요한 경로만 영구 반영함.
6. Queue worker를 수동/임시 세션에서 실행¶
잘못된 패턴¶
php artisan queue:work
왜 문제인가¶
- 세션 종료 시 worker 소멸
- 재부팅 후 자동 복구 불가
운영 기준¶
Queue는 Supervisor 또는 systemd로 관리함.
7. Scheduler(cron) 등록 없이 운영¶
잘못된 패턴¶
schedule:run을 수동으로만 실행- cron 등록 누락
왜 문제인가¶
- 예약 작업 누락
- 배치/정산/알림 기능 장애
운영 기준¶
운영 계정에 cron을 등록하고
crontab -l로 상시 점검함.
8. 운영 중 즉흥 설정 변경 후 문서 미반영¶
잘못된 패턴¶
- 서버에서 즉석 수정
- 문서/체크리스트 미반영
왜 문제인가¶
- 재현 불가
- 동일 장애 반복
- 운영 지식 단절
운영 기준¶
모든 변경은 "문서 기준 확정 → 적용" 순서로 진행함.
9. 정리¶
- Laravel 운영에서 가장 위험한 패턴은 "임시조치의 영구화"임
- 운영 품질은 기능이 아니라 재현성/복구 가능성/추적 가능성으로 결정됨