채택률은 높지만 측정항목이 중요합니다.
Stack Overflow의 2025년 설문조사에 따르면 응답자의 84%가 개발 프로세스에서 AI 도구를 사용했거나 사용할 계획인 것으로 나타났습니다. 전문 개발자 중 51%가 매일 사용한다고 보고했습니다. 질문은 일반적인 AI 도구를 다루고 있습니다. 해당 비율이 코드를 생성한다는 것을 증명하지도 않고 QA 팀을 구체적으로 설명하지도 않습니다.
흐름의 다른 측면을 살펴보기 위해 DeviQA는 2026년 7월 300명의 QA 전문가, SDET 및 테스트 리더를 대상으로 한 자체 설문조사를 발표했습니다. 52%는 AI를 사용하여 개발을 시작한 이후 버그가 증가했다고 인지했으며, 58%는 더 많은 테스트 부하를 인지했습니다. 이는 해당 부문을 대표하는 추정치가 아니라 조사해야 할 관련 신호입니다. 자체 보고된 응답 및 경험을 바탕으로 한 내부 공급업체 샘플입니다.
DeviQA의 설문조사에서는 참가자가 AI 채택과 일시적으로 연관되는 변화에 대해 묻습니다. AI가 있는 것과 없는 동일한 리포지토리를 비교하지 않으며 변경 크기, 경험, 전달 속도 또는 검토 정책을 제어하지도 않습니다. 또한 더 많은 결함이 감지되거나 보고되는 데 영향을 미칠 수도 있습니다. 따라서 AI 자체가 전반적인 버그 증가를 가져온다고 결론짓는 것은 적절하지 않습니다.
DORA 2025는 AI를 기존 작업 시스템의 증폭기로 읽을 것을 제안합니다. 빠른 피드백, 내부 플랫폼 및 명확한 우선순위가 도움이 됩니다. 검토하기 어려운 취약한 프로세스와 변경 사항도 증폭됩니다. 연구 보고서 연관성은 보편적 인과 규칙이 아닙니다. 실질적인 메시지는 변화를 단일 도구에 귀속시키는 것이 아니라 전체 흐름을 측정하는 것입니다.
프로세스를 변경하기 전에 측정해야 할 사항
몇 번의 반복을 통해 변경된 횟수와 크기를 기록합니다. 게시 전후에 얼마나 많은 결함이 나타나는지; 그 심각성; 사건이 재개된 횟수; QA가 수신하고 응답하는 데 걸리는 시간 얼마나 많은 작업이 반복되는지. 각 사람을 모니터링하지 않고 팀이 일관되게 식별할 수 있는 경우에만 AI의 도움으로 변경 사항을 개별화합니다.
기간을 주의 깊게 비교하십시오. 동일한 정의를 사용하고, 제품 또는 장비 변경 사항을 기록하고, 테스트에서 감지한 내용과 거짓으로 판명된 경고를 모두 검토하십시오. 더 많은 변경 사항이 릴리스되면 각 변경 사항이 더 적더라도 총 결함 수가 증가할 수 있습니다. 결함을 변경 횟수 및 크기와 비교하면 무슨 일이 일어났는지 이해하는 데 도움이 됩니다.
팀이 매주 10개의 변경 사항을 릴리스하고 4개의 결함을 발견하기 전에 상상해 보십시오. 어시스턴트를 추가한 후 그는 20개의 변경 사항을 게시하고 6개를 찾습니다. 총계는 증가했지만 비율은 변경당 0.4에서 0.3으로 감소했습니다. 분모가 없으면 "버그가 더 많습니다"라는 제목은 배송량과 단위당 품질을 혼합합니다. 테스트가 추가되거나, 로그가 개선되거나, 검토가 더욱 강화되어 탐지율이 높아질 수도 있습니다. 이 경우 더 많은 실패를 보면 제품이 더 나빠졌다는 것이 아니라 시스템이 더 잘 작동하고 있다는 것을 알 수 있습니다.
네 가지 측정값을 분리하는 것이 편리합니다. 게시 전에 발견된 결함; 생산에 도달한 결함; 심각도와 영향; 그리고 이를 조사하고 수정하는 데 드는 비용. 테스트 중에 사소한 문제를 더 많이 발견한다고 해서 사용자 사고가 더 많이 발생하는 것은 아닙니다. 반대로, 변경 횟수가 증가하거나 실패가 결제, 허가 또는 데이터에 집중되는 경우 안정적인 비율은 더 큰 위험을 숨길 수 있습니다. 비교하기 전에 무엇을 말할 것인지 결정하십시오.
테스트 실행 외에 생성된 코드를 검토하면 무엇이 추가되나요?
모든 테스트를 통과했다고 해서 그 자체로 변경 사항이 유지 관리하기 쉽고, 프로젝트 규칙을 준수하며, 충분한 테스트가 이루어졌음을 입증하는 것은 아닙니다. 2026년 조사에서 METR은 3개 프로젝트의 4명의 유지관리자에게 에이전트가 준비하고 자동화된 평가를 통해 승인된 296개의 변경 사항을 검토하도록 요청했습니다. 평균적으로 책임자는 평가자보다 더 적은 수의 변경 사항을 승인했습니다. 그 차이는 24% 포인트였습니다. 샘플이 제한되어 있어 에이전트는 의견을 받은 후에도 제안을 수정할 수 없었습니다. 결과를 보면 차이가 명확해집니다. "테스트를 통과했습니다"와 "팀이 변경 사항을 통합할 의향이 있습니다"는 같은 의미가 아닙니다.
따라서 함수가 예상한 대로 작동하는지 확인하는 것 외에도 변경 사항이 다른 기능에 영향을 미치는지, 오류를 처리하는 방법, 보안을 존중하는지, 새 테스트에서 실제로 문제를 감지하는지 확인하세요. 생성된 테스트는 코드와 동일한 오류를 반복할 수 있습니다. 이는 각 테스트에 요구 사항과 관련되도록 요청하고 보호하려는 기능이 제거될 때 실패하는지 확인합니다.
4~6주 동안 안정적인 정의로 기준선을 기록하고 규모, 위험 및 구성 요소별로 비교 가능한 변경 사항을 선택합니다. 팀이 AI를 사용한다면 개인 수준이 아닌 직무 수준에서 자발적으로 변화에 라벨을 붙인다. 가능한 경우 그룹이나 기간을 비교하고, 새로운 적용 범위, 리팩터링, 팀 교체 등 동시 변경 사항을 기록하고, 변경 사항, 수정된 라인 또는 노출을 기준으로 정규화합니다. 단일 비율을 목표로 사용하지 마십시오. 결함을 숨기거나 적용 범위를 줄이는 것을 장려할 수 있습니다.
유용한 대시보드는 나타나는 결함 수, 심각도, 감지된 단계를 보여줍니다. 얼마나 많은 제품이 생산에 도달했거나 다시 문을 열었는지; 팀이 응답을 받는 데 걸리는 시간 개인이 확인하는 자동 알림 수. 문제가 어디서 발생하는지 이해하기 위해 예를 유지하세요. 팀이 더 빠르게 작업하지만 생산 과정에서 더 심각한 결함이 발생하거나 재작업이 늘어나면 프로세스가 개선되지 않은 것입니다. 게시하기 전에 더 많이 포착하고 제작에 덜 사용한다면 이제 문제를 더 잘 발견할 수 있습니다.
QA 업무량 증가를 보여주는 최근 설문
2026년 9월에 발표되고 4,000명의 QA 전문가가 답변한 DeviQA의 별도 설문조사는 흐름의 반대쪽 끝을 설명하는 데 도움이 됩니다. 65%는 기능이 더 빨리 테스트에 도달한다고 말했습니다. 64%는 더 많은 기능이 동시에 도착한다고 밝혔습니다. 55%는 더 긴 QA 꼬리를 관찰했습니다. 52%는 테스트-올바른-재테스트 주기가 더 많다고 보고했습니다. 이 수치는 300명을 대상으로 한 이전 설문조사와 혼동되어서는 안 됩니다. 이는 서로 다른 도구, 샘플 및 질문입니다. 또한 변경당 결함을 측정하거나 AI가 원인임을 증명하지도 않습니다. 이는 팀이 확인할 수 있는 구체적인 긴장감을 보여줍니다. 더 빠르게 배포한다고 해서 검토, 회귀 또는 조정이 제거되는 것은 아니며 QA가 받는 작업에 집중할 수 있습니다.
실질적인 결과는 더 많은 블라인드 테스트를 할당하지 않는 것입니다. 환경 대기, 불완전한 요구 사항, 늦은 검토, 준비하기 어려운 데이터, 간헐적인 오류 또는 너무 많은 승인되지 않은 경고 등 대기열이 형성되는 위치를 물어볼 가치가 있습니다. 원인마다 다른 대응이 필요합니다. 배송이 언제 도착할지, 무엇이 변경되었는지 팀이 알지 못하는 경우 두 번째 AI 도구가 소음을 추가할 수 있습니다. 차이점, 위험 및 예상 결과를 알면 우선 순위를 더 잘 지정할 수 있습니다. 이는 유효 테스트 시간과 분리된 대기 시간을 측정합니다. 이것이 용량 문제와 흐름 문제를 구별하는 방법입니다.
절대 개수는 발견된 결함 수에 대한 답입니다. 각 변화가 더 나쁜지 여부를 단독으로 나타내는 것은 아닙니다. 팀이 10개의 변경 사항을 검토하고 4개의 결함을 발견한 다음 20개를 검토하여 6개를 발견했다고 가정해 보겠습니다. 총액은 늘었지만 환율은 떨어졌다. 새로운 변경 사항이 더 크거나, 다른 구성 요소를 건드리거나, 더 많은 적용 범위를 받는 경우 해당 비율도 오해의 소지가 있을 수 있습니다. 결정에 따라 다양한 분모를 사용합니다. 노출을 비교하기 위한 분류 로드, 크기 및 위험에 대한 수정된 변경 사항, 안정성을 위한 실행, 영향을 추정하기 위한 사용자 또는 트랜잭션 등이 있습니다. 코드 줄을 품질의 보편적인 척도로 바꾸지 마십시오. 코드는 기능적 위험을 대체하는 것이 아니라 컨텍스트 역할을 합니다.
또한 심각도, 탐지 시기 및 비용을 구분합니다. 출시 전에 감지된 차단 결함은 테스트가 작동하고 있다는 신호일 수 있습니다. 둘 다 "버그"로 간주되더라도 프로덕션에서의 사소한 문제는 권한 실패보다 덜 심각할 수 있습니다. 문제가 요구 사항, 구현, 통합, 데이터 또는 환경에 있는지 기록합니다. 이 분류는 프로세스를 수정하는 역할을 하며 작성자나 도구를 비난하지 않습니다. 대표적인 예를 유지하고 기간 사이에 변경된 사항을 검토합니다. 사례에 대한 설명이 없는 측정항목은 팀이 잘못된 수치를 최적화하도록 강요할 수 있습니다.
도구를 폐기하는 기준으로 도구를 평가하는 방법
주기에 AI를 추가하기 전에 부정적인 대답을 허용하는 질문을 정의하십시오. 예를 들어 "스토리 기반 테스트는 검토 시간을 늘리지 않고 누락을 줄입니까?" 제한된 흐름을 선택하고 기준을 설정하고 건너뛰기, 중복, 유효한 경고 및 재작업으로 간주되는 항목에 동의합니다. 유사한 위험의 여러 반복 및 변경 사항을 비교합니다. 가능하다면 대체 작업 또는 팀 그렇지 않은 경우 차이를 설명할 수 있는 적용 범위, 인력, 릴리스 및 도구의 변경 사항을 기록해 두십시오. 동시에 다른 변경사항이 있는 경우 이전/이후 비교에 인과관계를 부여하지 마세요.
통제된 테스트에도 중지 규칙이 필요합니다. 도구에 충분한 컨텍스트가 없거나, 승인 없이 실제 데이터를 사용하거나, 격리되지 않은 환경을 수정하거나, 누구도 재현할 수 없는 결과를 생성하는 경우 도구를 중지하고 실행을 보류해야 합니다. 인적 검토는 모델이 생성하는 모든 것을 받아들이는 것이 아니라 관련 위험에 중점을 둡니다. 종료 시에는 샘플 제한, 거짓 긍정, 탈출된 결함 및 검토 시간 비용과 함께 결과가 표시됩니다. 데이터가 결론을 뒷받침하지 않는다면 이는 유효한 결론입니다. 다음 단계는 성공을 선언하는 것이 아니라 측정을 개선하는 것입니다.
자동 경고는 아직 분류되지 않은 관찰입니다. 이는 새로운 결함, 알려진 회귀, 영향을 주지 않는 시각적 차이, 환경 문제 또는 더 이상 예상되는 동작을 나타내지 않는 테스트를 가리킬 수 있습니다. 대시보드가 모든 것을 "버그"로 추가하면 도구는 대부분 중복되거나 노이즈가 있는 문제라도 더 많은 문제를 찾는 것처럼 보입니다. 발견 항목 수신, 검토, 재현 가능, 확인, 복제 및 폐기에 대한 고유한 상태를 유지합니다. 또한 폐기 이유도 기록합니다. 이렇게 하면 팀은 유효한 신호를 평균 이하로 숨기지 않고도 분류 정확도와 비용을 측정할 수 있습니다.
분석에서는 시간도 살펴봐야 합니다. 몇 분 안에 감지된 오류는 야간 제품군 끝에 표시되는 보고서와 비용이 동일하지 않습니다. 릴리스가 완료될 때까지 아무도 볼 수 없는 올바른 경고는 예방 기능도 향상시키지 않습니다. 시스템이 보고하는 데 걸린 시간, 누군가 검토한 시간, 시스템이 닫힌 시간을 기록해 두십시오. 원시 알림 수가 증가하지만 확인된 비율이 떨어지고 검토 시간이 늘어나면 다음 실험에서는 더 많은 사례를 생성하는 것이 아니라 선택과 컨텍스트를 개선해야 합니다. 관련 결함의 조기 발견이 증가하고 후속 재작업이 감소하면 유용성에 대한 신호가 더 강력해집니다.