CI/CD·지속적 테스팅

학습 목표

이 모듈 한 줄 요약 — "사람이 기억해서 돌리는 시험은 곧 안 돌게 된다". 자동화 시험을 만들어도 누군가 기억해서 실행해야 한다면 몇 주 안에 멈춘다. 코드가 올라올 때마다 자동으로 돌고, 통과하지 못하면 배포가 막히는 구조를 만드는 것이 이 모듈이다.

이 모듈을 마치면 CI/CD가 무엇이고 QA에게 왜 중요한지 이해하고, GitHub Actions로 자동화 테스트가 자동으로 실행되는 워크플로를 읽고 구성할 수 있다. Docker로 "내 컴퓨터에서는 되는데" 문제를 해결하는 원리를 이해하고, 배포를 막아야 할 기준(품질 게이트)을 설계할 수 있다. CI에서 신뢰할 수 없는 실패(False Alarm)를 줄이는 법과, 관측성 도구로 실패 패턴을 추적하는 법을 다룬다. 마지막으로 그 지표를 품질 목표로 승격시켜, 배포 시점의 통과율을 넘어 사용자가 실제로 겪는 품질 을 SLI·SLO와 에러 버짓으로 관리하는 법까지 익힌다.

완료 후 할 수 있는 것

• CI/CD의 개념과 QA에게 중요한 이유를 설명할 수 있다
• GitHub Actions 워크플로 파일을 읽고 구조를 이해할 수 있다
• Docker가 테스트 환경 재현성 문제를 어떻게 해결하는지 설명할 수 있다
• 무엇이 배포를 막아야 하는지 품질 게이트 기준을 설계할 수 있다
• CI에서 False Alarm을 줄이는 전략을 설명할 수 있다
• 관측성 도구로 실패 패턴을 추적하고 원인을 분석할 수 있다
• 핵심 사용자 여정별로 SLI를 정의하고 SLO·에러 버짓을 설계해, 릴리즈 판단에 운영 품질을 근거로 끌어들일 수 있다

채용시장에서의 위치

"CI/CD 파이프라인 경험"은 자동화 QA·SDET 채용에서 UI·API 자동화 경험과 거의 항상 함께 요구된다. 아무리 잘 짠 자동화 테스트라도, 사람이 수동으로 실행해야 한다면 그 가치가 절반으로 줄어든다 — 이 모듈은 모듈 11~13에서 짠 자동화 테스트가 사람의 개입 없이 스스로 도는 시스템의 일부가 되는 마지막 단계를 다룬다. CI 파이프라인 설계·운영 경험은 QA를 "테스트를 실행하는 사람"에서 "품질 시스템을 설계하는 사람"으로 끌어올리는 역량이다.

여기에 SLO를 더하면 발언권이 릴리즈 이후로 확장된다. "품질이 중요하다"와 "일정이 급하다"의 감정적 대립을, 에러 버짓이라는 공통 숫자 위의 계산 문제로 바꾸는 능력 이다. SRE 문화를 도입한 조직에서 테스트 결과와 운영 지표를 함께 말할 수 있는 QA는 아직 드물다.