QA 엔지니어가 이력서 대신 AI 자동화 플랫폼을 직접 만들기로 한 이유 (1탄)

채용 공고마다 등장하는 Agentic Testing이라는 낯선 단어 앞에서, 몇 년차 QA 엔지니어가 직접 AI 테스트 자동화 플랫폼을 만들어보기로 결심하기까지의 고민을 담았다.

 

최근 몇 달 사이 QA 채용 공고를 훑어보면 예전과 확실히 결이 달라졌다는 걸 느낀다. Jira와 Postman, Playwright 같은 익숙한 이름들 사이에 Cursor, Claude Code, ChatGPT, GitHub Copilot이 자연스럽게 끼어 앉아 있다. 우대사항 한 줄로 지나가던 것이 이제는 담당 업무 항목에 "TC 자동 생성", "결함 예측 분석", "Agentic Testing 도입"이라는 문장으로 못 박혀 있는 공고도 심심치 않게 보인다.

처음에는 이걸 그냥 트렌드 키워드 정도로 넘겼다. 그런데 여러 회사의 공고를 나란히 놓고 읽다 보니 패턴이 보이기 시작했다. 어떤 커머스 플랫폼의 공고는 "자연어 기반 테스트 생성과 자동 복구 흐름 도입"을 요구했고, 다른 서비스 회사는 "명세와 PR 변경사항, 장애 이력을 입력받아 테스트를 생성하고 우선순위를 매겨 실행하는 에이전트형 테스트 체계 구축"을 담당 업무로 명시했다. 더 이상 AI 도구를 써봤는지 묻는 수준이 아니라, AI가 테스트를 설계하고 고치는 구조 자체를 설계할 수 있는지를 묻고 있었다.

 

자격증이나 강의 대신 직접 돌아가는 시스템을 만들어보기로 한 배경

이력서에 "Claude Code 사용 경험 있음"이라고 한 줄 적는 것과, 실제로 그 도구를 엮어서 요구사항 문서 변경을 감지하고 테스트 케이스를 뽑아내는 파이프라인을 굴려본 것 사이에는 메울 수 없는 간극이 있다. 채용 담당자 입장에서도 포트폴리오에 "AI로 테스트를 짜봤습니다"라는 문장보다, 실제로 며칠간 돌아간 자동화 대시보드 링크 하나가 훨씬 설득력 있게 읽힐 것이다.

그래서 방향을 바꿨다. 강의를 결제하거나 자격증을 준비하는 대신, 평소 업무에서 반복되던 세 가지 작업, 그러니까 테스트 시나리오와 케이스 작성, 자동화 테스트 환경 구축과 실행, 배포로 인한 변경이 생겼을 때 깨지는 자동화 스크립트를 스스로 고치는 셀프힐링 흐름을 하나의 개인용 플랫폼으로 엮어보기로 했다. 조건은 하나였다. 유지 비용이 들지 않아야 한다는 것.

 

Agentic Testing이라는 말이 실제로 가리키는 네 단계의 작업

Agentic Testing이라는 용어를 검색하면 추상적인 설명만 잔뜩 나온다. 그래서 직접 채용 공고와 실무 사례를 뜯어보며 이 개념을 네 개의 구체적인 동작으로 정리해봤다.

가장 먼저 오는 것은 AI가 요구사항 문서나 코드 변경사항, 즉 PR의 diff를 스스로 읽고 어떤 부분을 검증해야 하는지 판단하는 단계다. 예를 들어 결제 모듈의 할인율 계산 로직이 수정된 PR이 올라오면, 사람이 일일이 알려주지 않아도 AI가 diff를 읽고 "이 변경은 할인 적용 순서와 최소 결제 금액 검증에 영향을 준다"는 식으로 영향 범위를 스스로 좁혀나간다.

이어서 그 판단을 바탕으로 테스트 케이스를 자동으로 생성하고, 어떤 케이스를 먼저 돌려야 할지 우선순위를 매기는 단계로 넘어간다. 여기서 중요한 건 단순히 케이스 개수를 늘리는 게 아니라, 변경 영향도가 큰 시나리오와 과거 장애 이력이 있었던 영역을 가중치 있게 배치하는 판단력이다.

특히 인상적인 부분은 세 번째 단계인데, AI가 실제로 앱이나 웹 화면을 탐색하면서 사람이 미처 문서화하지 못한 엣지 케이스를 스스로 찾아낸다는 점이다. Playwright의 접근성 트리 기반 실행 방식이 여기서 힘을 발휘하는데, 화면의 구조를 좌표가 아니라 역할과 속성으로 이해하기 때문에 버튼 위치가 바뀌거나 레이아웃이 변경돼도 어떤 요소가 무슨 기능을 하는지 스스로 추론할 수 있다.

마지막 단계는 실패했을 때 원인을 분석하고, 필요하면 테스트 스크립트 자체를 수정하거나 복구하는 셀프힐링이다. 마이크로소프트가 공개한 벤치마크에 따르면 셀렉터 관련 실패의 75퍼센트 이상을 AI가 자동으로 고쳐낸다고 하는데, 이는 배포 주기가 빨라질수록 QA 엔지니어의 야근을 줄여주는 실질적인 수치이기도 하다.

 

시나리오를 뽑아내는 도구를 무엇으로 정했는지

플랫폼의 첫 단추는 테스트 시나리오와 케이스를 뽑아내는 두뇌 역할을 할 도구를 고르는 일이었다. Cursor는 실시간 코드 편집에 강하고, Claude Code는 터미널에서 코드베이스 전체를 캐싱해두고 반복 질문에 답하는 구조라 저장소 전체를 훑으며 테스트 케이스를 뽑아내는 용도에는 더 잘 맞았다. 실제로 서비스 레이어 코드를 읽힌 뒤 "이 함수의 유닛 테스트를 엣지 케이스 포함해서 작성해줘"라고 요청하면, 경계값과 예외 흐름까지 포함한 테스트 초안이 꽤 쓸만한 수준으로 나온다.

다만 이 결과물을 그대로 신뢰하고 커밋하는 건 다른 문제다. AI가 만들어낸 테스트가 실제로 검증하려는 로직의 핵심을 짚고 있는지, 아니면 그럴듯해 보이기만 하는 껍데기인지 구분하려면 결국 코드를 읽을 줄 알아야 한다. 이 부분은 다음 글에서 자동화 환경 구축과 함께 조금 더 깊이 다뤄보려 한다.

 

무료로 이 구조를 유지하기 위해 어떤 도구들을 조합했는지, 배포가 일어날 때마다 자동화 스크립트가 스스로 복구되는 흐름을 어떻게 붙였는지, 그리고 매일 아침 결과를 메일로 받아보게 만든 과정은 2탄에서 이어간다.