품질보증(QA)·소프트웨어 테스트의 AI 전환 — 버그 탐지 자동화는 얼마나 믿을 만한가

소프트웨어 개발에서 가장 먼저 AI 코딩 도구의 혜택을 본 영역은 코드 작성 자체지만, 그 코드가 실제로 맞는지 확인하는 테스트와 품질보증(QA) 영역은 사정이 다르다. 생성형 AI가 코드를 빠르게 쏟아내는 만큼 검증해야 할 양도 함께 늘어나기 때문에, 테스트 자동화는 AI 도입의 보조 수단이 아니라 병목을 좌우하는 변수로 떠올랐다. 그런데 AI가 테스트를 자동으로 만들어준다는 약속과 그 테스트가 실제 버그를 잡아낸다는 결과 사이에는 아직 뚜렷한 간극이 있다.

유닛테스트 생성에서는 실제 성과가 쌓였다

메타(Meta)가 2024년 소프트웨어공학 학회(FSE) 산업트랙에 공개한 연구에서, 자체 개발한 테스트젠엘엘엠(TestGen-LLM)은 기존에 사람이 작성한 테스트 클래스를 확장하는 방식으로 작동했다. 기존 테스트를 전부 유지한 채 새 테스트 케이스를 추가하기 때문에 회귀를 일으키지 않는다는 점이 설계의 핵심이다. 인스타그램과 페이스북 안드로이드 코드베이스를 대상으로 진행한 테스트어톤(test-a-thon)에서 전체 테스트 대상 클래스의 11.5퍼센트가 개선됐고, 이 가운데 73퍼센트는 메타 엔지니어가 검토해 실제 운영 코드에 반영했다. 릴스·스토리 제품에 한정한 평가에서는 생성된 테스트의 75퍼센트가 정상적으로 빌드됐고, 57퍼센트가 안정적으로 통과했으며, 25퍼센트는 실제로 테스트 커버리지를 늘렸다.

기업용 테스트 생성 도구를 판매하는 디프블루(Diffblue)가 공개한 사례에서는, 골드만삭스(Goldman Sachs)가 디프블루 커버(Diffblue Cover)를 도입해 레거시 애플리케이션의 자바 유닛테스트 커버리지를 36퍼센트에서 72퍼센트로 끌어올렸다고 밝혔다. 회사 측은 이 작업이 사람이 수작업으로 했다면 1년이 걸릴 분량이었다고 설명했다. 다만 이 수치는 벤더가 직접 공개한 고객 사례이고, 같은 도구를 썼지만 성과를 못 본 고객의 사례는 공개되지 않는다는 한계가 있다. 그럼에도 반복적이고 정형화된 유닛테스트 작성이라는 좁은 영역에서는, 사람이 밑바닥부터 쓰는 것보다 AI가 기존 테스트를 확장하거나 변형하는 방식이 더 빠르고 안전하다는 방향성 자체는 독립된 두 사례에서 공통적으로 나타난다.

파일럿은 넘치는데 프로덕션은 아직이다

이 성과가 산업 전반으로 퍼졌는지는 다른 질문이다. 캡제미니(Capgemini)가 오픈텍스트(OpenText), 소제티(Sogeti)와 함께 발표한 17번째 월드 퀄리티 리포트(World Quality Report 2025, 2025년 11월 발표)는 33개국 1,775명의 품질 담당 임원을 조사했다. 응답 조직의 89퍼센트가 생성형 AI 기반 테스트를 파일럿 단계로라도 도입했거나 배포하고 있다고 답했지만, 실제로 운영 환경(프로덕션)에서 쓰고 있다고 답한 비율은 약 37퍼센트에 그쳤다. 확장을 가로막는 장애요인으로는 데이터 프라이버시 위험(67퍼센트), 기존 시스템과의 통합 복잡성(64퍼센트), 조직 내 역량 격차(50퍼센트)가 꼽혔다. 파일럿에서 본 성과를 조직 전체의 테스트 체계로 옮기는 단계에서 대부분의 조직이 멈춰 있다는 뜻이다.

커버리지 숫자는 안심의 근거가 아니다

더 근본적인 의문은 통과율이나 커버리지 같은 지표 자체가 품질을 보장하는지다. 업계에서 반복적으로 제기되는 지적은, AI가 생성한 테스트가 코드가 실행되는지는 확인하지만 코드가 의도한 대로 동작하는지는 확인하지 못하는 경우가 많다는 것이다. 커버리지 수치는 테스트가 코드의 어느 줄을 지나갔는지를 세는 지표일 뿐, 그 줄에서 올바른 결과가 나왔는지를 검증했다는 보장은 아니다. 실제로 AI가 생성한 테스트에서는 선택자(selector)가 화면 요소의 작은 변화에도 쉽게 깨지는 취약한 구조, 그리고 사소한 변경에도 과민하게 실패를 신고하는 어설션(assertion) 때문에 실패가 늘어나는 현상이 자주 보고된다. 한 줄의 로직을 의도적으로 틀리게 바꿔도 테스트가 그대로 통과한다면 그 테스트는 실제로 아무것도 검증하지 않은 것과 같다는 뮤테이션 테스트(mutation testing) 식의 점검이 이런 맥락에서 제안되는 이유다. 독립된 평가 사례들 역시 같은 방향을 가리킨다. 깃허브 코파일럿(GitHub Copilot)의 코드 리뷰 기능을 실제 버그 50건으로 검증한 한 벤더의 비교 평가에서는 코파일럿이 27건, 54퍼센트를 찾아냈는데, 이는 평가를 수행한 경쟁 벤더 자체 도구의 82퍼센트보다 낮은 결과였다. 벤더 간 비교라는 한계는 있지만, AI 기반 코드 검토·테스트 도구 사이에서도 탐지 성능의 차이가 상당히 벌어진다는 점은 분명하다.

한국 기업에 주는 시사점

한국 기업이 QA·테스트 업무에 AI를 들일 때 가장 먼저 가를 질문은 테스트를 얼마나 빨리, 많이 만들 수 있는가가 아니라 그 테스트가 실제로 틀린 코드를 잡아내는가다. 커버리지 증가율이나 생성된 테스트 건수만 보고 도입 효과를 판단하면, 메타와 디프블루 사례가 보여준 좁지만 실질적인 성과와 캡제미니 조사가 보여준 확장의 벽 사이에서 착시가 생기기 쉽다. 실무적으로는 AI가 생성한 테스트를 사람이 검토하고 프로덕션에 반영할지 판단하는 승인 단계를 처음부터 설계에 넣어야 하고, 뮤테이션 테스트처럼 테스트 자체의 유효성을 주기적으로 점검하는 절차도 함께 둬야 한다. QA 담당자의 역할은 테스트 코드를 한 줄씩 작성하는 일에서, AI가 만든 테스트의 신뢰도를 판정하고 검증 기준을 설계하는 일로 옮겨가는 중이다.

참고한 자료

• Automated Unit Test Improvement using Large Language Models at Meta (arXiv 2402.09171, FSE 2024)
• Goldman Sachs: a year's worth of Java unit test writing overnight with Diffblue Cover
• World Quality Report 2025: AI adoption surges in Quality Engineering but enterprise-level scaling remains elusive
• Greptile AI Code Review Evaluation