CI/CD 개념과 파이프라인

5. 자주 하는 실수 (Tip)

❌ 실수 1. 로컬에서 안 돌려 보고 바로 커밋해 파이프라인 실패를 반복 확인

파이프라인은 커밋 후 몇 분이 지나야 결과를 알 수 있습니다. ci.sh 처럼 같은 단계를 로컬에서 먼저 돌리면 이 왕복을 줄일 수 있습니다.

❌ 실수 2. 실패 처리 없이 스크립트를 짜서 다음 단계가 그냥 실행됨

set -e 도 없고 종료 코드 검사도 없으면 앞 단계가 실패해도 뒤 단계가 이어서 실행됩니다. 실패한 빌드 위에서 테스트를 돌리면 결과를 신뢰할 수 없습니다.

❌ 실수 3. 테스트 실패를 무시하고 배포까지 진행하게 파이프라인을 짬

테스트 단계의 종료 코드를 확인하지 않으면 실패한 코드가 그대로 배포됩니다. run_step 처럼 실패 시 즉시 exit 하는 장치가 반드시 필요합니다.

❌ 실수 4. 정적 검사 경고를 쌓아 두고 나중에 몰아서 처리하려 함

경고가 수백 개 쌓이면 -Werror 를 켜는 순간 파이프라인이 통째로 막힙니다. 경고는 생기는 즉시 처리하거나, 처음부터 -Werror 로 쌓이지 않게 막아야 합니다.

❌ 실수 5. 빌드 시각을 jar 에 그대로 남겨 매번 해시가 달라짐

기본 jar 명령은 파일마다 압축 시각을 기록해 내용이 같아도 jar 파일 해시가 실행마다 바뀝니다. 재현성을 확인하려면 jar 자체가 아니라 안의 클래스 파일 해시를 비교합니다.

❌ 실수 6. 로그 전체를 보고 첫 에러를 못 찾아 헤맴

실패한 파이프라인 로그는 보통 수백 줄입니다. 아래로 스크롤하며 훑기보다 grep -n 으로 error·FAIL 같은 단어를 먼저 찾는 편이 빠릅니다.

❌ 실수 7. 테스트 클래스까지 그대로 배포 산출물에 포함시킴

이 레슨 예제도 jar 에 CalcTest.class 를 함께 담았습니다. 실무에서는 테스트 산출물 폴더를 따로 두고 패키징 단계에서 제외합니다.

❌ 실수 8. 단계 이름을 의미 없이 지어 실패 지점을 알기 어려움

step1·step2 처럼 지으면 실패 로그만 보고 무엇이 실패했는지 알 수 없습니다. run_step 의 이름 인자에는 "build"·"test" 처럼 하는 일을 그대로 씁니다.

❌ 실수 9. 로컬 재현 스크립트와 실제 워크플로 파일의 순서를 따로 관리함

ci.sh 와 GitHub Actions 워크플로 파일의 단계 순서가 어긋나면 로컬에서는 통과해도 원격에서는 실패하는 일이 생깁니다. 두 파일의 단계 이름과 순서를 맞춰 둡니다.

❌ 실수 10. 배포 단계 실패 뒤 이전 버전으로 돌아갈 방법이 없음

배포 스크립트가 실패했을 때 되돌릴 방법이 없으면 서비스가 그대로 멈춰 있습니다. 롤백(rollback) 경로는 배포 자동화를 만들 때 함께 설계합니다.