에이전트형 AI에는 테스터가 더 많이 필요하다, 더 적게가 아니라

에이전트형 AI가 소프트웨어 출시 방식을 새롭게 바꾸고 있다. 보조 도구는 풀 리퀘스트 초안을 작성하고, 에이전트는 마이그레이션을 시작하며, 코드 리뷰 봇은 사람이 커피를 다 마시기도 전에 변경 사항이 안전하다고 단언한다. 업계에서는 이를 품질 담당 인력을 줄이는 방향으로 나아가는 길로 보는 경우가 많다. 이는 잘못된 관점이다. 기계가 코드베이스의 더 많은 부분을 작성할수록 희소해지는 역량은 코드 생성이 아니다. 독립적인 검증이다.

2025년 Stack Overflow 개발자 설문조사에 따르면 응답자의 84%가 개발에 AI 도구를 사용하고 있거나 사용할 계획이며, 전문 개발자의 51%는 매일 AI 도구를 사용한다. 긍정적인 평가는 60%로 떨어졌고, AI의 정확성을 신뢰하는 개발자(33%)보다 적극적으로 불신하는 개발자(46%)가 더 많았다. 응답자의 66%가 꼽은 가장 큰 불만은 거의 맞지만 완전히 맞지는 않은 해결책이었다. Google Cloud의 2025년 DORA 조사 결과에 따르면 소프트웨어 개발 전문가의 AI 도입률은 90%였고, 80% 이상이 AI가 생산성을 높였다고 답했지만, AI를 상당히 또는 매우 신뢰한다고 답한 비율은 24%에 불과했다. 유용하지만 신뢰할 수 없는 상황이야말로 테스터의 업무를 줄이는 게 아니라 늘리는 조건이다.

속도는 증거가 아니다

저는 에이전트형 테스트와 AI가 작성한 코드의 CI 게이트를 주로 다루는 소프트웨어 품질 엔지니어입니다. 사내에서는 PR 리뷰 도구와 테스트 케이스 생성기를 출시했습니다. 둘 다 초안을 만드는 도구입니다. 어느 쪽도 자기 숙제를 스스로 채점하지는 않습니다. 에이전트는 확신에 찬 어조로 말하기 때문에 이 원칙이 중요합니다. 확신이 있다고 해서 정확한 것은 아닙니다.

우리는 값비싼 대가를 치르고서야 그 사실을 배웠습니다. AI로 만든 PR 리뷰 도구의 시범 운영에서 한 변경 사항은 4분도 안 돼 CI를 통과했습니다. 이틀 뒤, 후속 대시보드에 불가능한 온도가 표시됐습니다. 섭씨를 화씨로 환산하는 배율이 뒤바뀐 부분이 테스트 스위트에서 한 번도 실행하지 않은 코드 경로에 있었습니다. 파이프라인은 초록색이었습니다. 제품은 잘못됐습니다. 중요한 질문을 한 번도 던지지 않은 채 CI가 초록색으로 표시되는 것은 연극에 불과합니다.

이 사건은 더 광범위한 양상의 한 사례입니다. CodeRabbit의 AI와 인간의 코드 생성 현황 보고서는 오픈 소스 GitHub 풀 리퀘스트 470건(AI와 공동 작성한 PR 320건, 인간만 작성한 PR 150건)을 분석했습니다. AI가 작성한 변경 사항에서는 전체 문제가 약 1.7배 더 많이 발생했고, 논리 및 정확성 문제는 75% 더 흔했으며, 보안 문제는 최대 2.74배 더 많았습니다. Veracode의 2026년 생성형 AI 코드 보안 보고서는 보안 관련 작업에서 여러 모델을 테스트한 결과 평균 보안 통과율이 56%로 나타났다고 밝혔습니다. 이는 이전 보고서의 55%에서 거의 달라지지 않은 수치이며, AI 코드 생성 작업의 약 44%에서 알려진 취약점이 발생했습니다. 구문 문제는 거의 해결됐습니다. 안전하고 올바르게 작동하는 동작은 아직 그렇지 않습니다. 테스터는 이 둘을 혼동하지 않는 사람들입니다.

환각으로 만들어낸 종속성도 테스트 문제다

코드 생성 과정에서는 존재하지 않는 패키지도 만들어낸다. USENIX Security 2025 연구인 패키지를 준비했습니다!는 코드 생성 LLM 16개와 샘플 576,000개를 대상으로 패키지 환각을 평가했습니다. 상용 모델은 평균적으로 최소 5.2%의 비율로 존재하지 않는 패키지를 만들어냈고, 오픈 소스 모델의 평균은 21.7%였으며, 환각으로 만들어진 고유한 패키지 이름은 205,474개에 달했습니다. 유령 패키지가 계속 남아 있으면 슬롭 스쿼팅의 표적이 되기 쉽습니다. 공격자가 만들어낸 이름으로 패키지를 등록한 뒤 개발자나 에이전트가 이를 설치하기를 기다리는 방식입니다.

종속성 출처 검증은 기능 테스트와 같은 수준의 필수 절차로 다뤄야 합니다. 에이전트가 NuGet 패키지나 npm 패키지를 지어낸 경우, 단위 테스트가 충분했는지를 논하기도 전에 병합을 막아야 합니다. 출처 검증은 선택적인 위생 관리가 아닙니다. AI가 작성한 변경 사항에 필요한 품질 게이트입니다.

에이전트의 규모에 맞춰 확장되는 게이트

AI 지원 자동화를 활용해 조직 전체의 .NET 8에서 .NET 10으로의 업그레이드를 약 2주 만에 진행했을 때, 저는 품질 게이트를 맡았습니다. 속도는 분명 빨라졌습니다. 에이전트의 요약을 곧이곧대로 믿지 않는 검사가 필요하다는 점도 분명했습니다. 변경된 코드에 적용하는 게이트는 다음과 같습니다.

• 수정된 로직의 변이 점수 목표를 60%~70%로 설정해 테스트 스위트가 단순히 코드 줄을 실행하는 데 그치지 않고 실제 변이를 잡아내도록 합니다
• 예시만으로는 동작을 충분히 규정할 수 없는 고위험 로직에 속성 기반 테스트를 적용합니다
• 슬롭 스쿼팅과 환각으로 만들어낸 패키지에 대비해 종속성 출처를 검증합니다
• 에이전트의 복사·붙여넣기식 반복 작업을 포착하기 위해 중복과 코드 변경량을 나타내는 신호를 확인합니다
• “마이그레이션 완료”와 같은 에이전트의 주장을 독립적으로 검증합니다. 증거가 나오기 전까지 주장은 가설일 뿐입니다

변이 점수는 보여주기 위한 지표가 아닙니다. 의도적으로 결함을 심었을 때 테스트가 이를 알아차리는지 확인하는 지표입니다. 코드 커버리지가 올라가도 테스트 스위트가 섭씨 경로를 놓칠 수 있습니다. 속성 기반 검사는 하나의 순조로운 경로만이 아니라 여러 범위에서 시스템 모델이 성립하는지 확인합니다. 출처 검증은 패키지가 마구 들어오는 통로를 막습니다. 코드 변경량과 중복을 살피면 에이전트가 같은 아이디어를 세 가지 방식으로 다시 작성하는 습관을 포착할 수 있습니다. 이 모든 검사가 함께 하나의 원칙을 이룹니다. 테스트 스위트가 반대 증거를 입증하기 전까지 에이전트가 틀렸다고 가정하는 것입니다. 저는 리뷰에서도 이 기준을 지킵니다.

이 가운데 어느 것도 API 테스트, 인증 테스트, 스모크 테스트 또는 UI 자동화를 대체하지 않습니다. FlaUI와 PowerShell은 여전히 API 테스트가 놓치는 문제를 잡아냅니다. NuGet, MSI, MSM을 통한 패키징에도 설치 및 무인 설치 경로 검증이 필요합니다. 에이전트형 워크플로는 처리량을 늘립니다. 하지만 이러한 테스트 분야를 없애지는 않습니다.

테스터는 더 많이, 업무 방식은 다르게

에이전트가 테스트를 작성하고 인간은 선택 사항이 될 수 있다는 우려가 있다. 에이전트는 테스트 사례를 초안으로 작성할 수 있다. 하지만 자신이 작성한 초안을 스스로 인증해서는 안 된다. 향후 테스트에 AI를 활용할 계획인 Stack Overflow 응답자들도 여전히 인간의 불신을 핵심에 두었다. 다른 사람에게 도움을 요청하는 경우를 생각했을 때 가장 큰 이유는 AI의 답변을 신뢰하지 못한다는 것이었다. 그런 본능이야말로 이 직업군의 자산이다.

비전통적인 경로를 거쳐 온 사람을 채용하고 역량을 발휘할 수 있도록 지원하는 일이 중요하다. 나는 HR 운영과 데이터 분야에서 일하다 품질 분야로 전환했고, 2024년 5월 UMBC에서 정보 시스템 석사 학위를 마쳤으며, 지금은 에이전트형 AI의 검증 관문을 실용적으로 만드는 일을 하고 있다. 에이전트형 AI는 특정한 하나의 경력 경로만을 기다려 주지 않는다. 빌드가 성공했다는 표시를 무비판적으로 승인하는 사람이 아니라, 근거를 설계할 수 있는 사람이 더 많이 필요하다.

제품과 관련한 질문은 간단하다. 에이전트가 검증 체계가 판단할 수 있는 속도보다 빠르게 배포된다면 생산성이 향상된 것이 아니다. 나중에 터질 사고를 미뤄 둔 것뿐이다. 모든 에이전트의 주장을 의심하고, 변이 테스트와 출처 추적을 CI에 통합하며, 모델이 가장 유창하지만 신뢰성은 가장 낮은 영역에서도 독립적인 판단을 유지하는 테스터에게 투자해야 한다. 에이전트형 AI에는 테스터가 더 많이 필요하다. 더 적게 필요한 것이 아니다.