AI 테스트 실패에 있어서의 신뢰 문제

Stack Overflow의 2025년 개발자 설문조사에서설문조사에 따르면 개발자의 84%가 워크플로우에서 AI 도구를 사용하거나 사용할 계획이라고 답했는데, 이는 전년도의 76%에서 증가한 수치입니다. 같은 조사에서 응답자의 46%는 AI 도구가 생성하는 결과의 정확성을 적극적으로 불신한다고 답했고, 33%는 신뢰한다고 답했습니다.  

입양률은 증가했지만, 신뢰도는 동시에 하락했습니다. 

그것은 일시적인 현상이 아닙니다. 숙련된 사람들이 오랫동안 도구를 사용하여 도구를 최적화했을 때 나타나는 현상입니다. 

신뢰의 역설은 합리적인 반응이다 

구글의 2025 DORA 이 보고서는 다른 관점에서도 동일한 의견 차이를 발견했습니다. 개발자의 80% 이상이 AI가 생산성을 향상시켰다고 응답한 반면, 30%는 AI가 생성한 코드에 대해 거의 또는 전혀 신뢰하지 않는다고 응답했습니다. 유용함과 신뢰성 부족은 양립할 수 없으며, 개발자들은 둘 다에 대한 가치를 부여해 왔습니다. 

경험이 가장 많은 사람들이 가장 회의적이다. Stack Overflow의 데이터에 따르면 경험이 가장 많은 개발자일수록 높은 신뢰도를 보이는 비율이 가장 낮고, 높은 불신도를 보이는 비율이 가장 높습니다. 이는 매우 중요한 결과입니다. 왜냐하면 엔지니어링 조직에 제시되는 모든 AI 기능을 평가할 주체는 바로 이러한 개발자들이며, 그들은 확신에 찬 답변만으로는 쉽게 설득되지 않을 것이기 때문입니다. 

실패 분석은 값싼 회의론이 값비싼 대가를 치르게 되는 지점이다. 

개발자 워크플로에서 AI를 활용하는 많은 부분은 검증 비용이 저렴합니다. 코드 제안이 잘못된 경우 빠르게 발견할 수 있으며, 소요 시간도 몇 분에 불과합니다. 

테스트 실패 분류는 그런 식으로 작동하지 않습니다. 무언가 실패했을 때, 무엇이 고장 났는지뿐만 아니라 어떤 계층에서 고장 났는지(애플리케이션, 자동화 스크립트, 장치 또는 환경)를 파악하는 것이 중요합니다. 이 질문에 대한 답을 알아야 누가 작업을 맡을지 결정할 수 있습니다. 잘못 판단하면 몇 분을 허비하는 것이 아니라, 결함을 잘못된 팀에 배정하여 한 사이클을 허비하고 결국 실패를 처음 발생했던 곳으로 되돌려 보내는 결과를 초래할 수 있습니다. 

신호는 이미 나타나고 있습니다. 실패 원인을 설명하는 데 필요한 모든 정보는 실행 과정에서 캡처됩니다. 스크립트, 장치 로그, 서버 측 로그 등 앱이 종료되는 동안 기록된 모든 데이터가 포함됩니다. 증거는 부족하지 않지만 분석이 필요한 것입니다. 따라서 결국 사람이 직접 해당 파일을 열어 중요한 몇백 줄을 골라내어 붙여넣어야 하는 것입니다. 

소프트웨어가 분석을 대신 수행한다면, 기준은 "대체로 정확하다"는 것보다 훨씬 높아야 합니다. 신뢰할 수 있어야 한다는 뜻입니다. 핵심은 모델의 정확성이 아니라, 시스템이 분석 결과를 충분히 명확하게 보여주어 사용자가 스스로 판단할 수 있도록 하는 것입니다. 

신뢰도 점수는 증거를 측정해야 합니다. 

대부분의 AI 제품에서 신뢰도 점수는 잘못된 것을 측정합니다. 바로 모델이 얼마나 확신 있게 들리는가 하는 점입니다. 언어 모델은 확신에 찬 어조를 내는 데 매우 능숙합니다. 이 수치는 답변이 얼마나 유창한지를 보여줄 뿐, 정답인지 아닌지를 알려주는 것이 아닙니다. 

더 나은 점수는 증거를 측정하는 기준이 됩니다. 여러 개의 서로 다른 출처에서 동일한 오류를 지적할 때 점수가 올라가야 합니다. 타임아웃에 기반한 추측이 아닌 실제 오류 메시지가 표시될 때, 그리고 오류 발생 원인부터 최종 오류 발생까지의 과정을 추적할 수 있을 때 점수가 올라가야 합니다. 

로그 소스가 누락되었거나, 결론을 뒷받침하는 소스가 하나뿐이거나, 다른 설명을 배제할 수 없는 경우에는 값이 감소해야 합니다. 

 

확신도는 검증의 척도로서, 점수를 높이는 요인과 낮추는 요인, 그리고 밴드의 연주가 어떤지 등을 분석합니다. 

그 숫자가 줄어드는지 여부가 중요한 지표입니다. 

신뢰도가 낮다고 절대 보고하지 않는 채점 시스템은 장식에 불과하다. 모든 분석 결과가 높게 나온다면 그 점수는 아무런 의미가 없습니다. 데이터가 부족할 때, 즉 로그 소스가 누락되었을 때 점수가 떨어지는 것이 진정한 의미의 점수입니다. 누락된 로그 소스는 채워 넣는 대신 누락되었다고 표시합니다. 

누구도 도구가 확신하지 못한다고 표시하는 화면을 시연하고 싶어하지 않습니다. 하지만 엔지니어들은 실제 조사 과정과 일치하기 때문에 그 화면이 그대로 표시되어야 한다고 생각합니다. 확신하지 못할 때 솔직하게 인정하는 도구는 한계가 있음을 보여주는 것이며, 그 한계 내에서는 신뢰할 수 있다는 뜻입니다. 

저희를 포함한 모든 판매업체에 꼭 물어봐야 할 세 가지 질문 

테스트 자동화 분야의 모든 업체는 이제 자사의 AI가 오류를 설명할 수 있다고 주장합니다. 하지만 이러한 주장은 차별화 요소가 아니라, 그 주장을 뒷받침하는 증거가 핵심입니다. 다음 세 가지 질문을 통해 두 업체를 빠르게 구분할 수 있습니다. 

• “분석이 틀렸을 경우, 어떻게 알 수 있을까요?” 만약 유일한 답변이 "직접 조사해 보시겠어요?"라면, 그 도구는 조사를 도와준 것이 아니라 오히려 단계를 하나 추가한 것뿐입니다. 

• “신뢰도가 낮은 결과를 보여주세요.” 선별된 것이 아닙니다. 데모 환경에서 낮은 점수를 받은 항목이 없다면, 데모 환경을 구축하는 데 필요한 것이 무엇인지 문의해 보세요. 

• “실제 분석 결과는 뭐라고 나왔나요?” 이것이 가장 중요한 부분이며, 범용 모델에 로그를 붙여넣는 데 한계가 있는 이유입니다. 해당 모델은 사용자가 내보낸 데이터만 인식합니다. 분석은 입력값에 의해 제한되므로, 어떤 입력값이었는지 알아야 합니다. 

교대 

테스트에서 AI에 대한 유용한 질문이 바뀌었고, AI가 수행해야 하는 역할도 달라졌습니다. 핵심은 엔지니어를 의사 결정 과정에서 배제하는 것이 아니었습니다. 레이어 이름을 정하는 것은 실질적인 결과를 수반하는 판단이며, 그 판단은 인간이 담당해야 하는 부분입니다. 

인간의 손이 닿지 않아야 할 부분은 바로 읽는 행위입니다. 문서를 열어보고, 중요한 몇백 줄을 추려내고, 순서를 재구성하는 작업은 소프트웨어가 처리해야 합니다. 그래야 결정을 내리는 사람이 증거를 수집하는 데 시간을 허비하는 대신, 이미 수집된 자료를 바탕으로 판단을 내릴 수 있습니다. 

점수가 떨어지는 것이 중요한 이유도 바로 이 때문입니다. 로그 소스가 누락되었을 때 신뢰도 수치가 떨어지는 것은 시스템이 "이 문제는 사람의 개입이 필요합니다"라는 결정을 내리는 것입니다. 반대로, 그런 신호를 전혀 보내지 않는 도구는 사람의 개입을 차단하고, 아무도 확인하지 않기를 바라는 것과 같습니다. 

누구도 모델이 신뢰할 만하다고 묘사되었기 때문에 신뢰하는 것이 아닙니다. 사람들은 스스로 판단할 수 있을 만큼 충분한 정보를 접했기 때문에 신뢰하는 것입니다.  

이것이 우리가 만드는 것과 어떻게 연결되는지 설명해 드리겠습니다. AI 기반 근본 원인 분석 Digital.ai 테스팅 도구는 실행 과정에서 생성된 아티팩트를 기반으로 iOS 및 Android 환경에서 Appium 테스트 실패를 분석하고, 가능한 원인, 증거 일치도를 기반으로 산출된 신뢰도 점수, 그리고 실패의 원인이 된 특정 로그 라인 또는 단계를 반환합니다. 데이터가 부족할 경우 신뢰도 점수가 낮아지는데, 이는 의도적인 설정입니다. 

둘러보기 Digital.ai 프리미엄 테스트.

출처 및 참고자료 

스택 오버플로, 2025년 개발자 설문조사 - AI 부문 — 84%가 AI 도구를 사용하거나 사용할 계획이라고 답했으며, 이는 76%에서 증가한 수치입니다. AI 출력의 정확성에 대해 불신하는 응답자는 46%인 반면, 신뢰하는 응답자는 33%입니다. 불신하는 비율은 경험이 많은 개발자들 사이에서 가장 높게 나타났습니다(20.7%가 "매우 불신한다"). 

구글 클라우드 / DORA, 2025년 인공지능 기반 소프트웨어 개발 현황 — 80% 이상이 AI 덕분에 생산성이 향상되었다고 응답했고, 30%는 AI가 생성한 코드를 거의 또는 전혀 신뢰하지 않는다고 응답했습니다.