한 프로젝트서 유효 판정된 결함 30건 중 AI가 21건 발견…PRD 미갱신이 드러낸 협업 공백

DEV Community 계정 xulingfeng의 작성자는 한 지식베이스 프로젝트에서 AI 테스트 에이전트가 최종 유효 판정을 받은 결함 30건 가운데 21건을 발견했다고 보고했습니다. 제품·개발팀이 대화로 조정한 요구사항을 공식 제품 요구사항 문서(PRD)에 반영하지 않아 일부 AI 결함 보고가 무효로 분류된 사례도 전했습니다. 2026년 11월 5일 열린 사내 발표에서 테스트 자동화 논의는 요구사항 정렬과 부서 간 협업으로 이어졌습니다. 작성자는 회사명을 밝히지 않았으며, 수치와 조직 계획은 본인이 전한 프로젝트와 내부 논의에 관한 내용입니다.

테스트 실행부터 수정 검증까지 잇는 에이전트

작성자가 만든 다중 에이전트 테스트 시스템은 요구사항 이해부터 테스트 설계·실행, 결함 보고와 수정 확인까지 연결합니다. 시스템은 PRD와 시제품을 읽어 업무 흐름과 인수 기준을 파악한 뒤 테스트 사례를 작성합니다. 여러 에이전트가 사례를 검토하고, 브라우저와 모바일 앱을 조작해 사용자 행동을 모사합니다. 문제를 찾으면 이슈 추적 시스템에 결함 보고를 제출하고, 추가 검토와 사람의 확인을 거쳐 담당 개발자에게 전달합니다. 개발자가 수정하면 에이전트가 회귀 테스트를 돌려 수정 여부를 확인하며 사람의 감독도 유지합니다.

작성자는 기존 UI 자동화에서 초기 스크립트 작성보다 화면이 바뀔 때 요소 선택자와 페이지 객체, 상호작용 코드를 다시 맞추는 유지보수 부담이 컸다고 설명했습니다. 에이전트는 현재 페이지의 요소와 상호작용 상태를 살펴 시험 목표에 맞게 동작해, 반복적인 수작업의 상당 부분을 맡을 수 있습니다. 화면 변화와 실행 실패를 처리하는 일은 여전히 남습니다.

요구사항에 정의된 검사를 마친 뒤에는 미리 작성한 사례 밖의 빈 값, 경계값, 작업 중단 같은 상황도 탐색하도록 했습니다. 작성자는 탐색 범위와 테스트 환경, 계정 권한 및 운영 위험을 통제하고 보안 시험은 허가된 범위에서 진행해야 한다고 밝혔습니다. 실서비스에서 에이전트를 자유롭게 실행하는 방식과는 다른 조건입니다.

작성자는 보통 퇴근 전에 시험을 예약해 밤새 실행합니다. 다음 날에는 보고서를 하나씩 검토해 실제 결함인지, 현재 요구사항에 맞는지 판단합니다. 검토와 검증을 거쳐 재사용할 수 있다고 확인한 경험은 Skill로 정리해 다음 시험에 활용합니다.

유효 판정 결함 30건 중 AI 발견 21건

한 지식베이스 프로젝트에서 작성자가 기록한 결함 보고는 모두 47건입니다. AI가 발견한 보고는 36건, 사람이 발견한 보고는 11건이었고, 최종 유효 판정을 받은 결함 30건 가운데 AI 발견분은 21건으로 집계됐습니다. 21건은 유효 판정된 결함의 70%입니다. 이 비율은 해당 프로젝트의 시험 범위에서 최종 유효 판정을 받은 결함 30건을 분모로 삼습니다.

작성자는 초기에 AI가 만든 보고서가 실행 기록을 빽빽하게 담아 개발자가 문제를 빠르게 파악하기 어려웠다고 썼습니다. 여러 차례 형식을 고쳐 발생 위치, 실제 동작과 기대 동작의 차이, 재현·검증 방법이 드러나게 했습니다. 작성자에 따르면 이후 보고서는 읽기 쉬워졌고 개발자가 문제를 다루는 데 필요한 정보도 분명해졌습니다.

PRD와 팀의 합의가 어긋난 원인

AI가 제출한 보고 일부가 무효로 분류되자 작성자는 처음에 요구사항 해석이나 테스트 로직을 의심했습니다. 이후 확인한 사례에서는 제품·개발팀이 대화로 요구사항을 조정했지만 공식 PRD를 갱신하지 않았습니다. QA와 AI는 문서에 적힌 기준으로 시험했고, 제품·개발팀은 대화로 조정한 기준이나 실제 구현을 토대로 판단했습니다. 그 결과 문서 기준으로 확인한 불일치가 팀의 현재 판단과 맞지 않아 무효 처리됐습니다.

작성자는 과거 테스터들이 구두 확인과 임시 설명, 경험으로 문서와 실제 합의의 차이를 메웠다고 설명했습니다. 에이전트는 전달받은 요구사항과 정보에 따라 시험하므로 비공식 대화를 자동으로 반영하지 않습니다. 이 사례에서 자동화는 사람이 메워 온 요구사항의 간극을 결함 보고와 그에 대한 팀의 판단 차이로 드러냈습니다.

테스트 자동화 논의가 조직 계획으로

작성자는 AI가 코드 생산 비용을 낮추더라도 사람 간 조정 비용은 같은 속도로 줄지 않는다는 점이 사내 논의의 배경이었다고 전했습니다. 작은 요구사항도 여러 역할을 거치면 전달과 조율에 드는 부담이 실제 수정 작업보다 커질 수 있습니다. 이에 각자의 전문성을 살리면서 AI를 활용해 역할 경계를 넘어 문제를 해결하는 방안이 제안됐습니다.

제품 담당자는 AI를 활용해 작은 요구사항의 코드를 수정하고 검증할 수 있고, 개발자는 요구사항 분석에 일찍 참여하며, 테스터는 결함을 조사하고 코드 수정까지 맡을 수 있다는 구상입니다. 작은 업무는 불필요한 인계를 줄이고 큰 과제에는 전체 진행을 책임질 담당자를 두는 방향도 포함됐습니다. 테스터가 코드를 수정할 때는 개발자의 검토와 확인을 유지합니다.

이를 위해 제품·개발·QA가 요구사항 초기에 함께 정렬하고, 구조화된 PRD 양식을 쓰며, 변경이 생기면 공식 문서를 바로 갱신하는 방안이 나왔습니다. 스마트 배지로 녹음한 대화에서 요구사항 변경 신호를 찾아 PRD 수정을 돕고, 변경안을 관련자가 검토·승인하는 아이디어도 제시됐습니다. 이 기능은 아직 검토할 구상으로 남아 있습니다.

테스트 환경도 제약으로 언급됐습니다. 작성자에 따르면 당시 테스트 환경은 하나여서 여러 요구사항을 병렬 개발할 때 코드 변경이 충돌하거나 배포가 다른 시험을 중단시킬 수 있었습니다. 추가 테스트 환경과 성능 시험 전용 환경은 검토 대상입니다. 작성자는 조직 변화 계획이 시작돼 매주 진행 상황을 조율한다고 전했습니다.