최근 AI 기반 소프트웨어에서 '가끔은 그냥 안 된다'는 설명할 수 없는 실패가 일상화되는 현상이 우려를 낳고 있습니다. AI가 판단과 확률을 빠르게 제공하지만, 그 결과가 제대로 작동하는지 확인할 평가와 정답 데이터 구축은 여전히 개발자의 몫입니다. 신뢰도 90%라는 숫자만으로 결과를 맹신해서는 안 되며, 잘못된 판단이 어떤 손실을 일으키는지 파악해야 합니다.
문제는 개발자들이 평가를 미루고 'AI도 실수한다'며 제품을 서둘러 출시하는 관행에 있습니다. 이는 사용자가 직접 실패율을 발견하게 만들고, 개발자가 원인을 추적하고 고칠 것이라는 기대를 약화시킵니다. 예를 들어, 타입이 지정된 값과 확률 추정치를 반환하는 AI 모델인 Jev(제브)를 도입하더라도, 실제 업무에서 제대로 작동하는지 확인하려면 평가 및 정답 데이터 파이프라인을 구축해야 합니다. 신뢰도 점수가 실제 정답률과 얼마나 일치하는지, 그리고 불확실성이 초래하는 비용을 계산하는 모델이 없다면, '0.9 이상이면 받아들이자'는 식의 임계값 설정은 위험한 결과를 초래할 수 있습니다.
이러한 '설명할 수 없는 실패'의 일상화는 소프트웨어 개발의 책임감 부족과 직결됩니다. 웹사이트 버튼이 작동하지 않을 때 개발자는 DNS 문제, 자바스크립트 오류 등 구체적인 원인을 추적할 책임이 있습니다. 하지만 AI 소프트웨어에서는 'AI 탓'으로 돌리며 책임 소재가 모호해지는 경향이 있습니다. 이는 사용자들이 소프트웨어가 원래 변덕스럽다고 느끼게 만들고, 실패를 구체적인 원인까지 추적할 가능성을 잃어도 큰 손실로 느끼지 않게 만듭니다.
그러나 LLM(대규모 언어모델) 같은 AI 개발 도구는 이러한 검증 부족을 해소하는 데도 활용될 수 있습니다. 엔지니어링 시간 부족으로 구현하지 못했던 자동화된 QA(품질 보증) 작업 흐름이나 평가 시스템을 몇 번의 프롬프트(명령어)만으로 구축할 수 있습니다. 즉, AI는 실패를 당연하게 받아들이기보다, 오히려 검증을 강화하는 데 쓸 수 있는 강력한 도구인 셈입니다.
결국, AI 기반 소프트웨어의 품질을 높이려면 속도보다 품질에 보상이 돌아가는 환경이 조성되어야 합니다. 은행이나 금융권처럼 거래의 완벽성과 반복 가능성을 중시하는 업계에서는 AI 도입 시에도 특정 업무 영역에서 엄격한 검증을 요구합니다. AI가 만든 코드도 결정적으로 실행되며 실패 원인을 고칠 수 있다는 점을 인지하고, '버그는 불가피하다'는 숙명론 대신 '버그는 선택'이라는 인식을 가져야 합니다. 신뢰할 수 없는 소프트웨어가 만연하면 결국 모든 작업과 사람의 속도가 느려지므로, 개발자와 사용자 모두 문 뒤에 시신이 있는지 확인하는 시스템을 적극적으로 구축해야 할 것입니다.