비용 한 푼 없이 셀프힐링 자동화와 매일 아침 보고까지 완성한 QA 플랫폼 (2탄)

1탄에서 Agentic Testing의 개념과 테스트 케이스를 뽑아내는 두뇌를 정하는 과정을 다뤘다면, 이번 글은 그 결과물을 실제로 돌아가는 파이프라인으로 엮고 비용 없이 유지하는 방법을 담았다.

 

플랫폼을 설계하면서 세운 원칙은 단순했다. 서버 비용도, 라이선스 비용도 들이지 않으면서 배포가 일어날 때마다 자동으로 테스트가 돌고, 화면 구조가 바뀌어도 스크립트가 스스로 고쳐지고, 그 결과를 매일 아침 눈뜨자마자 메일로 받아보는 것. 처음에는 욕심이라고 생각했는데, 하나씩 뜯어보니 이미 있는 무료 서비스들을 이어 붙이는 것만으로도 충분히 가능한 구조였다.

 

실행 환경을 GitHub Actions에 통째로 맡긴 이유

자동화 테스트를 돌리려면 어딘가에서 코드를 실행할 서버가 필요한데, 개인 프로젝트에 별도 서버를 띄우는 순간 비용 문제가 시작된다. GitHub Actions는 public 저장소라면 완전히 무료고, private 저장소로 운영해도 월 2000분의 실행 시간이 기본으로 주어진다. 하루에 한두 번 배포 트리거로 도는 테스트 스위트 정도라면 이 한도 안에서 여유 있게 굴러간다.

워크플로 파일 하나에 브라우저 설치와 의존성 설치, npx playwright test 실행까지 담아두면, 커밋이나 PR이 올라올 때마다 별도의 서버 없이 임시 가상 머신에서 테스트가 돌고 결과만 남는다. 여기에 결과 아티팩트를 저장하는 정도까지는 무료 저장 용량 500메가바이트 안에서 충분히 감당된다.

 

셀렉터가 깨질 때 스크립트가 스스로 자신을 고치는 구조

배포 주기가 빨라질수록 QA를 가장 지치게 만드는 건 새로운 버그를 찾는 일이 아니라, 버튼 위치 하나 바뀌었다고 자동화 스크립트 전체가 빨갛게 실패하는 상황이다. 이 문제를 풀기 위해 Playwright의 접근성 트리 기반 실행 방식을 축으로 삼았다.

구조는 이렇다. 테스트를 설계하는 플래너 역할, 실제로 시나리오를 실행하는 실행자 역할, 그리고 실패가 발생했을 때 원인을 분석해서 스크립트를 고치는 힐러 역할을 세 개의 AI 에이전트로 나눠 맡긴다. 힐러 에이전트는 테스트가 실패하면 좌표나 CSS 클래스명이 아니라 접근성 트리 스냅샷을 읽고, 역할과 라벨을 기준으로 새로운 셀렉터를 찾아내 다시 실행한다. 이 방식으로 셀렉터 관련 실패의 상당수가 사람 손을 거치지 않고도 복구된다.

모바일 쪽은 Appium을 붙여서 같은 흐름을 웹과 앱 양쪽에서 굴리도록 맞췄다. API 계층은 Postman과 Swagger 문서를 기준으로 명세가 바뀌면 그 차이를 감지해 회귀 테스트 케이스를 다시 생성하도록 설계했다.

 

k6로 성능까지 챙기되 무료 한도 안에서만 굴린 이야기

기능 테스트만으로는 배포 리스크를 다 잡아낼 수 없다. 특히 트래픽이 몰리는 이벤트 직후 응답 지연이나 타임아웃은 기능 테스트 통과와는 별개의 문제라서, 오픈소스 부하 테스트 도구인 k6를 파이프라인 뒤쪽에 붙였다. k6는 자바스크립트로 시나리오를 작성하고, 가상 사용자 수와 지속 시간을 지정해 API나 마이크로서비스에 부하를 걸어본 뒤 응답 시간의 평균과 중앙값, 95백분위수 같은 지표를 리포트로 뽑아준다.

결과를 CSV나 JSON으로 내보낼 수 있어서 별도 비용 없이 파일 형태로만 쌓아두거나, Grafana 무료 티어와 연결해 그래프로 확인하는 방식을 택했다. 매번 대규모 부하를 걸 필요는 없기 때문에, 배포 직후 한 번씩 짧게 도는 시나리오로 제한해 GitHub Actions의 무료 실행 시간을 아끼는 것도 중요한 선택이었다.

 

눈뜨자마자 메일함에 보고서가 와 있게 만든 방법

밤사이 돌아간 테스트 결과를 출근해서야 확인하는 게 아니라, 눈을 뜨자마자 메일로 받아보고 싶었다. GitHub Actions의 스케줄 트리거를 cron 표현식으로 설정해 매일 정해진 시각에 워크플로가 실행되도록 하고, Node.js 스크립트에서 nodemailer로 그날의 테스트 통과율과 셀프힐링이 일어난 항목, k6 부하 테스트 요약을 정리해 메일로 발송하도록 붙였다. 발신 계정은 구글 앱 비밀번호를 발급받아 Gmail의 무료 SMTP를 그대로 활용했기 때문에 여기서도 추가 비용은 들지 않았다.

 

결국 AI가 고친 부분을 사람이 다시 읽어야 하는 순간

여기까지 오면서 가장 많이 부딪힌 벽은 도구를 연결하는 기술적인 부분이 아니라, AI가 내린 판단을 어디까지 믿을 것인가였다. 힐러 에이전트가 셀렉터를 스스로 바꿨다고 해서 그게 항상 옳은 수정이라는 보장은 없다. 실제로 버튼이 사라진 게 진짜 버그인데도, AI가 근처의 비슷한 요소를 새로운 타겟으로 잡아버려서 테스트를 억지로 통과시킨 사례를 몇 번 마주쳤다.

이런 순간을 걸러내려면 결국 코드와 DOM 구조, API 명세를 읽을 줄 아는 최소한의 개발 지식이 필요하다. PR의 diff를 보고 이 변경이 정말 셀렉터 교체만으로 해결될 문제인지, 아니면 로직 자체가 깨진 건지 구분하는 감각, SQL로 데이터베이스를 직접 조회해서 API 응답값이 실제 저장된 값과 일치하는지 대조하는 습관, 이런 것들이 AI의 자동 복구를 맹신하지 않고 교차검증할 수 있는 최소한의 방어선이 됐다.

지금 이 플랫폼은 여전히 다듬어가는 중이고, 힐러 에이전트가 잘못된 판단을 내렸을 때 이를 사람에게 다시 물어보도록 하는 확인 절차를 추가하는 작업을 이어가고 있다. 채용 공고에 적힌 한 줄짜리 자격요건을 눈으로 읽는 것과, 그 요건이 실제로 왜 필요한지 손으로 부딪혀보며 이해하는 것 사이의 거리를 조금씩 좁혀가는 과정이라고 느낀다.