AI도 틀린다는 말이 실패 조사의 끝이 되어서는 안 된다

TL;DR

• 원문의 걱정은 AI 시스템이 실패한다는 사실에만 있지 않다. AI는 원래 가끔 틀린다는 말로 원인과 책임을 찾는 일을 끝내는 문화가 더 큰 문제다. 개발 속도의 향상이 설명 가능한 실패와 검증의 필요를 없애지는 않는다.
• 빠르고 저렴한 API를 연결해도 실제로 잘 작동하는지 확인할 일은 남는다. 평가와 정답 데이터가 없으면 사용자가 제품의 실패율을 대신 발견하게 된다. 저자는 Jev를 사례로 이런 검증 부담의 전가를 비판한다.
• 신뢰도 점수가 높다는 것과 그 값만큼 정확하다는 것은 다르다. 점수의 보정 상태와 틀렸을 때의 비용을 함께 알아야 행동 기준을 정할 수 있다. 임의의 임계값은 오류 예산이나 안전 보증을 대신하지 못한다.
• TypeSafe 문서도 임계값을 도메인과 실제 성능에 맞춰 검증하라고 안내한다. 높은 점수의 고위험 예시에도 확인 절차가 포함돼 있다. 비판의 핵심은 점수 자체를 금지하는 데 있지 않고 점수로 검증과 책임을 생략하지 말라는 데 있다.

문이 안 열릴 때 문 자체를 탓하고 끝낸다

patrickxia는 『President Curtis』에서 인물이 막힌 문을 열지 못하고 문이 형편없다고 투덜대는 장면으로 글을 시작한다. 실제로는 문 뒤에 장애물이 있어 열리지 않는 상황이다. 인물은 이유를 찾는 대신 물건 자체가 불가해하게 작동하지 않는다고 받아들인다. 저자는 이 장면을 소프트웨어 사용자가 실패를 경험하는 방식에 겹쳐 놓는다.

일반 사용자에게 웹사이트 오류는 이미 원인을 알 수 없는 불편으로 느껴질 수 있다. 하지만 개발자는 DNS 문제나 특정 코드 경로의 예외처럼 조사할 대상이 있다고 생각한다. 사용자가 직접 원인을 찾을 수 없다는 것과 시스템을 만든 사람도 조사할 필요가 없다는 것은 다르다. 글이 경계하는 변화는 두 상황을 같은 것으로 취급하게 되는 데 있다.

빠른 API가 평가까지 대신해 주지는 않는다

Jev는 타입이 정해진 값과 확률 정보를 빠르고 저렴하게 얻는 도구로 소개된다. 원문은 API 연결의 편리함보다 그 결과를 업무에 써도 되는지 판단하는 과정에 주목한다. 작동 여부를 알려면 평가와 정답 데이터를 마련해야 하고 그 준비는 여전히 개발자의 몫이다. 저자는 그런 기반을 갖추고 나면 자체 모델을 조정하는 작업에도 상당히 가까워져 있다는 관점에서 제품의 가치를 묻는다.

원문의 구매자들은 평가를 하지 않는다는 표현은 조사로 입증된 전체 고객 행동이 아니라 저자의 강한 비판이다. 출시를 서두르며 실패 양상과 테스트 세트, 허용 가능한 오류를 나중 문제로 미루는 관행을 겨냥한다. 이런 상황에서는 실제 사용자가 잘못된 판단과 망가진 후속 처리를 겪으며 한계를 발견한다. 외부 모델을 썼다는 이유로 그 제품의 검증 책임까지 외부로 넘길 수는 없다.

확신의 점수와 행동의 안전을 구분한다

신뢰도 점수를 유용하게 쓰려면 적어도 점수가 실제 정답 여부와 어떤 관계인지 알아야 한다. 점수 보정은 비슷한 점수를 받은 사례들이 실제로 얼마나 맞는지와 연결된다. 또 오답을 허용했을 때와 맞는 답을 보류했을 때의 비용도 업무마다 다르다. 원문은 그 두 조건 없이 그럴듯한 임계값을 정하는 일이 숫자로 불확실성을 가리는 방식이 될 수 있다고 비판한다.

TypeSafe의 실제 문서에서 confidence는 선택지나 점수 수준에 대한 확률 분포를 하나의 값으로 요약한 통계다. 분포가 한쪽에 몰렸는지와 여러 후보에 퍼졌는지를 나타내지만 그 설명만으로 현실의 정답률과 일치한다고 보장되지는 않는다. 분류 cookbook은 불확실한 세부 분류 대신 상위 범주를 반환하는 활용 사례를 다룬다. 이런 활용 가능성과 모든 사용 환경에서 점수가 잘 보정돼 있다는 주장은 분리해서 읽어야 한다.

임계값 예시에도 생략하면 안 되는 조건이 있다

원문은 TypeSafe 문서의 0.5와 0.9 같은 기준이 충분한 근거 없이 따라 쓰일 가능성을 지적한다. 다만 문서에는 올바른 기준이 도메인과 모델의 실제 성능에 달려 있으며 자체 데이터로 시험하고 조정하라는 안내도 있다. 고위험 작업의 높은 점수 분기 역시 confirm_then_execute를 호출한다. 그러므로 해당 예시를 점수만 높으면 확인 없이 위험한 작업을 해도 된다는 권고로 옮기면 문서의 조건을 잃는다.

그 조건이 있다는 사실만으로 원문의 걱정이 사라지지는 않는다. 개발자가 편리한 숫자와 예제만 가져가고 자신이 감당할 실패의 종류와 비용을 정하지 않을 수 있기 때문이다. 모델이 출력한 확신 정도를 시스템의 오류 예산으로 바로 바꿔 부르는 것도 같은 혼동이다. 판단 기준에는 실제 평가 결과와 업무의 위험, 보류하거나 사람이 확인하는 경로가 함께 들어가야 한다.

실패를 설명하려는 책임을 포기하지 않는다

저자는 기존 소프트웨어의 책임 구조가 완벽했다고 주장하지 않는다. 각주에서 Bill Gates가 Movie Maker를 내려받으려다 겪은 문제와 담당 조직을 정하기 어려웠던 사례를 떠올린다. 그 사례에서도 적어도 고쳐야 할 문제와 책임을 맡을 사람이 있다는 기대는 남아 있었다. 문제를 겪은 사람이 유명한 고객이어야만 조사가 시작되는 구조 역시 이상적인 상태는 아니다.

LLM을 이용한 개발은 오히려 그동안 시간이 부족해 만들지 못한 자동 QA와 평가를 작성하는 데 도움을 줄 수 있다. 저자가 반대하는 것은 새로운 개발 방식에서 실패가 생기는 사실 자체가 아니다. 실패를 발견하고 설명하려는 노력을 그만두는 태도다. AI도 틀린다는 말은 검증과 조사를 시작하는 전제가 될 수 있지만 그것들을 끝내는 답으로 쓰여서는 안 된다.

참고 자료

patrickxia — the normalization of inexplicable failures

TypeSafe — Confidence — 신뢰도 정의, 임계값의 조건과 확인 절차를 대조했다.

TypeSafe — Classification using confidence — 분류의 세부 수준을 조정하는 활용 사례를 확인했다.

Internal Tech Emails — Bill Gates tries to install Movie Maker — 원문이 연결한 과거 이메일 기록이다. 현재 AI 제품의 실패율을 입증하는 자료로 사용하지 않았다.