설명할 수 없는 실패의 일상화

AI 기반 소프트웨어에서 더 우려스러운 문제는 실패 증가 자체보다, “가끔은 그냥 안 된다”가 원인 조사의 종착점으로 받아들여지는 것임 TypeSafe AI의 Jev는 타입이 지정된 값과 확률 추정치를 빠르고 저렴하게 반환하지만, 제대로 작동하는지 확인하려면 여전히 평가와 정답 데이터 파이프라인이 필요함 신뢰도 점수를 합리적으로 활용하려면 점수가 실제 정답률과 얼마나 일치하는지, 불확실성에 따른 비용이 얼마인지 알아야 하며 임의의 임계값만으로는 부족함 평가 없이 출시하고 “AI도 실수한다”며 넘어가면 오류 예산과 실패율 검증이 뒤로 밀리고, 사용자가 실패율을 직접 발견하게 됨 LLM을 활용한 개발은 인력 부족으로 만들지 못했던 자동화 QA와 평가를 구현하는 데도 도움이 될 수 있지만, 사용자와 개발자 모두 실패 원인을 확인하지 않는 시스템을 만들고 있음 문이 안 열리는 데는 이유가 있음 President Curtis의 한 에피소드에서 대통령은 두 차례 문을 열지 못하고 “이 멍청한 물건, 형편없네”라고 중얼거림 첫 번째에는 시신, 두 번째에는 약 10억 달러어치 금이 문을 막고 있음 문이 이유 없이 형편없이 작동하는 것이 아니라, 열리지 않는 구체적인 원인이 있음 “어떤 때는 엘리베이터를 타고, 어떤 때는 승강로에 빠진다”는 말 역시 엘리베이터 작동에 대한 합리적인 이해와는 거리가 있음 Jev의 속도와 가격이 없애주지 않는 검증 작업 TypeSafe AI의 Jev는 타입이 지정된 값과 확률 추정치를 반환하는 AI 모델이며, 빠른 속도와 낮은 비용, 신속한 제품 개발이 강점임 기술 채택은 신뢰성만으로 결정되지 않음 Slack의 고착 효과와 네트워크 효과는 이해할 수 있지만, 메시지 전달조차 안정적이지 않은 제품이 표준으로 자리 잡았다는 데 의문이 있음 무료, 유료, 기업용 환경에서 누락된 메시지가 몇 주 뒤에야 나타난 경험이 있음 Jev는 FTP 계정을 curlftpfs로 로컬에 마운트하고 그 위에서 SVN이나 CVS를 쓰면 된다는 식의 대안과 달리, 도입 후에도 어려운 검증 작업이 남음 제대로 작동하는지 알려면 평가와 정답 데이터 파이프라인을 구축해야 함 이를 갖췄다면 자체 솔루션을 파인튜닝하는 데 필요한 작업도 이미 상당 부분 마친 셈임 평가 없이 불투명한 질문을 보내고 불투명한 응답을 받아 “AI 기반” 제품을 서둘러 출시하는 관행이 문제임 후속 로직이 망가지면 “AI도 실수한다”며 넘어갈 수 있음 오류 예...