워드프레스 프로젝트에 CI 를 붙이려 하면 대개 “테스트가 없는데 무엇을 돌리나” 에서 멈춥니다. 그런데 테스트 스위트가 없어도 자동으로 잡을 수 있는 것이 꽤 있습니다. 그리고 그것들은 대체로 가장 창피한 종류의 사고 — 문법 오류가 프로덕션에 올라가거나, 빌드를 잊고 배포하거나, 플러그인 하나가 부팅을 막는 — 를 막아 줍니다.
① 문법 — 가장 싸고 가장 확실하다
php -l 은 파싱만 하므로 매우 빠릅니다. 다만 파일을 하나씩만 받습니다 — 여러 개를 넘기면 첫 번째만 검사하고 끝납니다. xargs -n1 이 필수인 이유입니다.
find wp-content/themes wp-content/plugins -name '*.php' -not -path '*/vendor/*' -print0 | xargs -0 -n1 -P4 php -l이 한 줄이 “치명적 오류로 흰 화면” 사고의 상당수를 막습니다. 파싱 오류는 파일이 로드되기만 하면 터지므로, 관리 화면 한 곳에서만 쓰이는 파일이라도 예외가 없습니다.
② 코딩 표준 — 리뷰에서 다투지 않기 위해
PHPCS 와 워드프레스 코딩 표준 규칙을 붙이면 들여쓰기 · 이스케이프 누락 · 접두사 규약을 사람이 아니라 도구가 지적합니다.
composer require --dev squizlabs/php_codesniffer wp-coding-standards/wpcs dealerdirect/phpcodesniffer-composer-installer
vendor/bin/phpcs --standard=phpcs.xml.dist규칙 파일(phpcs.xml.dist)을 저장소에 두는 것이 중요합니다. 텍스트 도메인과 함수 접두사를 여기 적어 두면 번역 도메인 오타나 접두사 없는 전역 함수를 자동으로 잡습니다. 처음부터 모든 규칙을 켜면 경고 수천 건에 압도되므로, 바뀐 파일만 검사하도록 시작해 점차 넓히는 편이 실제로 굴러갑니다.
③ 빌드 산출물 대조 — “다시 빌드하는 걸 잊었다”
2회차에서 빌드 산출물을 커밋하기로 했다면, 그 산출물이 소스와 맞는지 확인하는 것은 사람이 아니라 CI 의 일입니다. 잊는 사고가 반드시 일어나고, 증상은 “왜 스타일이 안 바뀌지” 로 나타납니다.
npm ci
npm run build
git diff --exit-code assets/dist--exit-code 는 차이가 있으면 실패로 끝냅니다. 다시 빌드한 결과가 커밋된 것과 다르면 그 자리에서 파이프라인이 멈춥니다.
④ 부팅 스모크 — 사이트가 실제로 뜨는가
가장 값어치 있는 검사입니다. 임시 DB 에 워드프레스를 설치하고, 우리 테마와 플러그인을 켜고, 홈이 200 으로 응답하는지 봅니다.
wp core install --url=http://127.0.0.1:8080 --title=CI --admin_user=ci --admin_password=ci --admin_email=ci@example.com --skip-email
wp theme activate our-theme
wp plugin activate --all
test "$(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8080/)" = "200"wp plugin activate --all 이 통과하는 것만으로도 활성화 시점의 치명적 오류가 걸러집니다. 함수 중복 선언이나 없는 클래스 참조가 여기서 드러납니다.
CI 가 말해 주지 않는 것
마지막으로 하나 — CI 로그에 비밀값이 남지 않게 합니다. 배포 키 · DB 비밀번호는 반드시 마스킹된 시크릿으로 주입하고, 디버그 출력에 환경변수를 통째로 찍는 스텝을 남겨 두지 않습니다. 3회차의 결론이 여기에도 그대로 적용됩니다.
자동화 전반은 개발 워크플로우 아카이브에 이어지고, 우리가 실제로 어떤 순서로 검증하고 배포하는지는 작업 과정에 공개돼 있습니다.
다음 회차
연재의 마지막 회차는 되돌리기입니다. 코드를 되돌린다고 DB 가 되돌아오지 않는다는 사실이 그 전부이고, 그래서 순서를 정해 두어야 합니다.