운영 가이드 12. 배포와 권한: www-data, storage, rsync, cron 기본 구조

웹 운영에서 가장 자주 겪는 문제 중 하나가 권한 꼬임입니다. 소스는 배포 계정이 넣었는데 업로드는 `www-data` 가 쓰고, 백업은 root가 만든 파일이라 다음 배포에서 막히는 경우가 자주 생깁니다.

그래서 초기부터 소유권, 그룹, 업로드 저장소, 심볼릭 링크, cron 실행 계정을 정해 두는 편이 좋습니다.

기본 디렉터리 예시

• /var/www/html/site/current : 현재 서비스 코드
• /var/www/html/site/shared/storage : 업로드와 로그
• /var/www/html/site/releases : 배포 이력
• /backup : 데이터베이스와 파일 백업

권한과 소유권 예시

코드 전체를 무조건 `www-data` 로 덮는 방식보다, 업로드와 캐시처럼 웹서버가 실제로 써야 하는 경로만 분리하는 쪽이 더 관리하기 편합니다.

sudo chown -R deploy:www-data /var/www/html/site
sudo find /var/www/html/site -type d -exec chmod 775 {} \;
sudo find /var/www/html/site -type f -exec chmod 664 {} \;
sudo mkdir -p /var/www/html/site/shared/storage
sudo chown -R www-data:www-data /var/www/html/site/shared/storage

rsync 배포 예시

운영 서버에서 직접 편집하기보다 로컬 또는 CI에서 정리한 파일을 rsync 또는 배포 툴로 반영하는 방식이 흔들림이 적습니다.

rsync -avz --delete ./ deploy@example.com:/var/www/html/site/current/

cron 작업 예시

crontab -e

*/5 * * * * /usr/bin/php /var/www/html/site/artisan schedule:run >> /var/www/html/site/shared/storage/logs/cron.log 2>&1
0 3 * * * /usr/bin/mysqldump -u appuser -p'StrongPasswordHere!' appdb | gzip > /backup/appdb-$(date +\%F).sql.gz

비밀번호를 cron에 직접 넣는 방식은 장기적으로는 별도 설정 파일이나 백업 전용 계정으로 분리하는 편이 좋습니다.

마무리 메모

배포와 권한 구조가 안정되면 새 코드 반영, 업로드 보존, 로그 기록이 훨씬 예측 가능해집니다.

다음 글에서는 실제 오픈 전에 무엇을 점검하고, 장애가 나면 어떤 로그부터 보는지 운영 관점에서 정리합니다.