자동화는 처음이라: 실험과 실패, 그리고 성장

쏘카 QA팀이 외주 수동 테스트 의존에서 벗어나 API 테스트 자동화를 구축한 과정을 담았다. Jenkins EC2 구축 실패 후 GitHub Actions로 전환하고 Postman+newman 조합으로 CI/CD 파이프라인을 완성했지만, gRPC 아키텍처에서 한계를 발견해 전략을 재수립했다.

핵심 포인트

E2E vs API 테스트 선택: E2E는 UI 변동성 높아 유지보수 부담 크고, API는 변동성 낮아 한번 구현으로 안정적 운용 가능
Jenkins 실패: EC2 서버 직접 구축·관리, 플러그인 업데이트·호환성 문제, 복잡한 설정 → 환경 구축 4개월 예상
GitHub Actions 채택: 별도 서버 없이 코드와 CI/CD를 하나의 저장소에서 관리, cloud runner 활용 → 1개월 구축 완료(75% 단축)
Postman+newman+GitHub Actions 구조: Postman 컬렉션 GitHub 저장 → cloud runner에서 newman 실행 → Slack 알림
gRPC 한계 발견: 특정 도메인이 gRPC+REST 혼합 아키텍처, Postman은 REST만 지원 → 전체 플로우 자동화 불가
전략 재수립: 전구간 자동화 포기, 테스트 데이터 생성·사전 조건 세팅·반복 작업부터 점진적 자동화 적용

상세 정리

자동화 동기: 외주 수동 테스트 리소스 과다, 실행 속도 느림, 인력 관리 어려움 → 자동화로 효율화 목표
초기 Jenkins 구조: Zephyr(테스트 항목) → Postman Script → Jenkins → Slack 결과 공유, EC2에 직접 구축 시도
PoC 구현: 로그인·회원가입 API 정상/비정상 케이스 스크립트 → main 머지 → cloud runner newman 실행 → Slack 알림
GitHub Actions 도입 전략 1: 기존 Jenkins 스크립트를 YAML로 수정·이식, 반복 검증 후 점진적 반영
GitHub Actions 도입 전략 2: 스케줄 기능으로 정기 자동 실행, 수동 테스트 부담 감소
팀 온보딩: Git·GitHub Actions 기초 실습 세션, Postman 환경변수·GitHub Secrets 오류 해결법 공유 → 팀원 독립 자동화 역량 확보
gRPC 문제: Postman 기반 REST 스크립트로 gRPC 호출 포함 전체 시나리오 구현 불가, 상태 전이 테스트도 한계
현재 방향: 도메인별 소단위부터 점진적 확장, 즉각 효과를 줄 수 있는 영역 우선 자동화