자동화 첫걸음: 실험과 실패, 그리고 성장

QA 자동화의 출발점은 외주 인력 중심의 수동 테스트가 너무 많은 리소스를 잡아먹는다는 문제였다. E2E 테스트는 전체 흐름을 검증하지만 유지보수가 무겁고, API 테스트는 변동성이 낮아 상대적으로 빠르게 자동화할 수 있어 먼저 이 방향을 선택했다.

초기에는 사내 자동화 히스토리를 따라 Jenkins 기반으로 구조를 잡았다. Zephyr에서 테스트 항목을 받아 Postman Script를 실행하고, 결과를 Slack으로 공유하는 흐름이었다.

다만 직접 Jenkins 서버를 구축하고 운영해야 했고, AWS EC2 환경 이해도 필요했으며, 설정 복잡도도 높았다. 이런 이유로 기존 웹 E2E 자동화 경험을 바탕으로 GitHub Actions로 구조를 바꿔 PoC를 진행했다.

PoC에서는 다음 흐름을 검증했다.

• 로그인, 회원가입 관련 Postman API Script 작성
• 정상 입력 시 200, 잘못된 ID/PW 입력 시 400 응답 확인
• feat/slack-api 브랜치의 스크립트를 main에 merge
• GitHub Actions용 YAML 파일 생성
• cloud runner에서 newman 실행
• 실행 결과를 Slack 채널로 알림

비교 결과 Jenkins는 서버 관리, 플러그인 호환성, 백업과 유지보수 부담이 컸고, GitHub Actions는 별도 서버 없이 저장소 안에서 CI/CD를 관리할 수 있어 훨씬 단순했다. 팀 설득을 위해 구조를 다시 정리하고 PoC를 공유했으며, Git과 GitHub Actions 사용이 익숙하지 않은 팀원을 위해 온보딩 세션도 직접 진행했다.

도입 성과도 분명했다. 새 환경 구축 예상 기간이 4개월에서 1개월로 줄었고, 작업 기간을 약 75% 단축했다. 그 결과 API 테스트 자동화 기반과 배포 주기에 맞춘 정기 실행 체계를 마련할 수 있었다.

하지만 한계도 드러났다. 적용하려던 도메인은 gRPC와 REST API가 섞인 구조였고, Postman 중심 스크립트는 REST 호출에 최적화되어 있어 전체 플로우와 상태 전이 검증까지 담기 어려웠다. 결국 전 구간 자동화보다 테스트 데이터 생성, 사전 조건 세팅, 반복 작업 자동화처럼 효과가 큰 영역부터 점진적으로 확장하는 방향으로 전환했다.