Composer Guardian으로 Composer 패키지 최신 상태 유지하기: 왜 필수적인가
오래된 Composer 패키지는 조용히 불어나는 보안 부채다. Composer Guardian으로 업데이트 점검을 스크립트화해 아무도 기억하지 않아도 돌게 만드는 방법.

PHP 개발자로서 PHP의 의존성 관리자인 Composer에 이미 익숙할 것이다. 이는 패키지 관리, 업데이트 간소화, 프로젝트의 원활한 실행을 보장하는 필수 도구다. Composer 사용의 중요한 측면 중 하나는 패키지를 최신 상태로 유지하는 것이다. 이 블로그 글에서는 Composer 패키지를 최신 상태로 유지하는 것의 중요성과, 오픈소스 스크립트인 Composer Guardian이 어떻게 이를 도와줄 수 있는지 논의한다.
Composer 패키지를 최신 상태로 유지해야 하는 이유:
- 보안: 오래된 패키지는 새 버전에서 해결된 취약점을 포함할 수 있어 애플리케이션을 보안 위험에 노출시킬 수 있다.
- 성능: 새 버전의 패키지는 종종 성능 개선과 최적화를 포함하여 더 빠르고 효율적인 애플리케이션을 만든다.
- 호환성: PHP와 다른 패키지가 발전함에 따라 호환성 이슈가 발생할 수 있다.
- 버그 수정: 패키지 업데이트는 종종 애플리케이션에서 겪을 수 있는 문제를 해결하는 버그 수정을 포함한다.
- 새로운 기능: 업데이트된 패키지는 애플리케이션에 도움이 될 수 있는 새로운 기능을 도입한다.
Composer Guardian이라는 제공된 스크립트는 패키지 업데이트를 계속 파악할 수 있도록 설계되었다. composer.json 파일을 읽고, 업데이트를 확인하며, 어떤 패키지를 업데이트해야 하는지 자세히 설명하는 보고서를 생성한다.
자동화하기: 스케줄 기반 CI/CD 검사
스크립트를 손으로 실행하는 방식은 잊어버리는 그 주까지만 동작한다. 이 검사는 누군가 기억하지 않아도 스케줄에 따라 실행될 때 비로소 값어치를 한다. Composer Guardian은 업데이트가 있으면 0이 아닌 종료 코드로 끝나므로, 어떤 CI 시스템이든 오래된 의존성을 정식 결과로 다룰 수 있다: 보고하거나, 파이프라인을 실패시키거나.
GitHub Actions에서는 주간 cron과 수동 트리거면 충분하다. 아래 내용을 PHP 프로젝트의 .github/workflows/composer-guardian.yml로 복사하고, Slack webhook URL을 SLACK_WEBHOOK_URL이라는 리포지토리 secret으로 추가한다:
name: Composer Guardian
on:
schedule:
- cron: “0 9 * * 1” # every Monday at 09:00 UTC
workflow_dispatch: {}
jobs:
check-dependencies:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-python@v4
with:
python-version: "3.11"
- name: Get Composer Guardian
run: |
git clone --depth 1 https://github.com/flightlesstux/Composer-Guardian.git /tmp/composer-guardian
pip install -r /tmp/composer-guardian/requirements.txt
- name: Check Composer packages
env:
COMPOSER_FILE_PATH: ${{ github.workspace }}/composer.json
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
run: |
python3 /tmp/composer-guardian/composer_guardian.py || true
마지막의 || true가 유일하게 내려야 할 결정이다. 유지하면 잡은 항상 초록색이다: 보고서는 Slack으로 가고, 밤사이 패치 릴리스를 낸 패키지 때문에 배포가 막히는 일은 없다. 제거하면 오래된 의존성이 파이프라인을 실패시키는데, 의존성 드리프트를 알림이 아니라 빌드 오류로 다루는 팀이라면 그게 맞는 선택이다. 모두에게 맞는 기본값은 없다. 감당할 수 있는 실패 모드를 골라라.
GitLab에서는 같은 패턴이 스케줄된 파이프라인이다: 리포지토리의 examples/gitlab-ci.yml에 파이프라인 스케줄로 트리거될 때만 실행되도록 설정된 잡이 준비되어 있다. 두 파일 모두 리포지토리의 examples/ 디렉터리에 있으며, 프로젝트에 바로 복사해 쓸 수 있다.
결론
Composer 패키지를 최신 상태로 유지하는 것은 PHP 애플리케이션의 보안, 성능, 전반적인 상태를 유지하는 데 매우 중요하다. Composer Guardian은 패키지 업데이트를 최신 상태로 유지하기 위한 사용하기 쉬운 솔루션을 제공한다. 한번 사용해보고 프로젝트에 어떤 도움이 되는지 확인하길 바란다.
이어서 읽기
- CI/CD 파이프라인과 개발 흐름에서 자동화된 테스트가 필수적인 이유: 같은 원칙을 테스트에 적용한 글. 잊어버릴 규율을 파이프라인이 대신 실행한다.
- AWS에서 PHP 애플리케이션 확장하기: 애플리케이션이 서버 한 대를 넘어설 때 그 의존성들이 실제로 돌아가는 곳.
참고 자료
Ercan의 다른 글
같은 저자, 다른 영역의 사이트 두 개.