설명할 수 없는 실패가 일상이 되는 문제

AI 요약

저자는 문 앞에 장애물이 있어 문이 열리지 않는 장면을 예로 들며, 소프트웨어가 제대로 작동하지 않을 때 “고장 난 물건이 원래 그렇다”고 넘기는 태도를 비판합니다. 글의 중심 사례는 입력을 분류하고 확률 점수를 반환하는 AI 모델 Jev입니다. Jev는 빠르고 저렴하며 빠르게 제품에 붙일 수 있다고 홍보하지만, 모델이 제대로 작동하는지 확인하려면 평가 데이터(evals)와 정답 데이터(ground truth)를 마련해야 합니다. 저자는 그 정도 검증 체계를 이미 갖췄다면 자체 모델을 미세 조정하는 작업에도 상당히 가까이 와 있다고 지적합니다.

확률 점수는 검증을 대신하지 않습니다

Jev가 반환하는 신뢰도 점수(confidence score)를 받았다고 해서 그 숫자를 바로 의사결정에 써도 되는 것은 아닙니다. 점수를 합리적으로 활용하려면 먼저 점수가 실제 정답률과 얼마나 잘 맞는지, 즉 보정(calibration) 상태를 확인해야 합니다. 이어서 불확실한 결과가 틀렸을 때 발생하는 비용도 따져야 합니다. 그런데 실제 사용에서는 “0.9 이상이면 괜찮겠지”처럼 근거 없이 임곗값을 정하는 일이 생깁니다. Jev 문서도 위험도가 높은 작업에 0.9, 아무것도 하지 않을 작업에 0.5라는 예시를 들지만, 적절한 임계값은 분야와 사용 사례에 따라 달라진다고 덧붙입니다.

평가 없이 점수만 믿으면 실패를 설명하는 말도 바뀝니다. “모델이 73% 확신했으니 27% 오류는 어쩔 수 없다”는 식으로 실패율을 정당화할 수 있습니다. 저자는 신뢰도 점수를 검증 없이 받아들이는 태도를 경계합니다. 점수를 믿으려면 실제 사용 사례에 맞춘 평가와 오류 비용 분석이 먼저 필요합니다.

실패 원인을 추적할 책임

일반적인 웹 버튼이 작동하지 않으면 DNS, JavaScript 오류, 예외 처리 누락 등 어딘가에서 기대한 동작의 계약이 깨졌다고 생각할 수 있습니다. 사용자가 직접 원인을 찾기 어렵더라도, 원인을 파악하고 고칠 담당자가 있다는 기대는 남습니다. 반면 여러 사용자는 소프트웨어가 실패해도 “그냥 별로인 물건”이라고 받아들이며 더는 이유를 묻지 않습니다. 저자는 이런 태도가 설명할 수 없는 실패의 정상화로 이어진다고 봅니다.

저자가 가장 우려하는 점은 LLM 기반 개발로 실패가 늘어나는 사실 자체가 아닙니다. 새로운 방식으로 시스템을 만들면 실패가 생길 수 있지만, 그 실패를 조사하고 원인을 좁히는 과정까지 포기하는 일이 문제입니다. 평가 체계나 자동 QA를 만드는 데도 엔지니어링 시간이 들지만, LLM은 그런 작업을 돕는 데도 쓸 수 있습니다. 결국 사용자는 물론 제작자까지 문 뒤에 무엇이 있는지 확인하지 않는 시스템을 만들고 있다는 것이 글의 비판입니다.

Hacker News 반응

• @hyperhello — 제품을 오래 사용하면 실패하거나 불편했더라도 다시 선택할 가능성이 커집니다. 이미 들인 시간과 자원을 정당화하려고 “이제는 내가 유리하다”고 생각하기도 합니다. 시선을 오래 붙잡는 선명한 상자일수록 슈퍼마켓 진열대에서 선택될 가능성이 높습니다. 남의 시간과 자원을 낭비시키는 건 권력의 표시지만, 자기 시간과 자원을 스스로 낭비하게 만드는 건 지배입니다.
  • @Xirdus — 실패율을 의도적으로 높이면 사용자 유지율이 좋아질 리는 없겠죠? 제발 그렇지 않다고 말해주세요.
• @voidhorse — “고객이 원하는 건 뭐든 한다”는 서비스는 제공자가 약속과 보장을 정하기 어렵습니다. 기능이 좁을수록 무엇이 일어나야 하고 실패했을 때 왜 그랬는지 명확해집니다. 확률을 계산의 토대로 삼으면 예측 가능성과 기대의 대가를 치릅니다. 비결정성은 유연하지만, 결정론은 복잡한 문제를 반복 가능한 동작으로 줄여 이해하기 쉽게 만들기 때문에 기술의 기본 선택지였습니다.
  • @solenoid0937 — 비결정론적 기계가 요구사항을 결정론적 기계로 바꾸는 일에서 인간보다 뛰어나지면 어떻게 될까요?
• @Sharlin — 소프트웨어 “공학”이 전통적인 공학에서 더 멀어지고 있습니다. 고장 형태 분석이나 근본 원인 분석은요? 잘 모르겠습니다. 저는 그냥 이 마법 상자와 대화합니다.
• @theamk — 글쓴이는 클라우드 서비스를 많이 쓰지 않는 것 같습니다. 개발자도 “그냥 별로인 물건”을 경험합니다. GitHub가 5xx 오류를 내거나 AWS 서비스가 작동하지 않거나 이메일이 전달되지 않으면 개발자도 할 수 있는 일이 없습니다.
  • @simoncion — 개발자이면서 동시에 사용자일 수 있습니다. 분산 시스템은 5년 전에 생긴 게 아닙니다. “우리가 올바르게 작동하는 데 의존하는 이 부분은 GitHub가 소유하고, 실패하면 우리는 아무것도 못 합니다”도 책임 소재가 명확한 구조입니다.
  • @ryandrake — 소프트웨어에서 “버그는 피할 수 없다”는 태도를 자주 봅니다. 그렇지 않습니다. 버그는 선택입니다. 거의 모든 회사가 “버그가 없는 상태는 너무 비싸다”고 판단해 버그를 받아들입니다. 때로는 합리적인 선택이지만, 자연법칙이 아니라 선택이라고 인정해야 합니다. 다리나 비행기를 만드는 사람이 붕괴와 추락은 피할 수 없다고 생각한다고 상상해보세요.
• @perching_aix — 설명할 수 없는 실패가 지금에서야 일상화됐다고 말하는 이유가 뭔가요? “껐다 켜보세요”라는 오래된 조언과 실제로 그 방법이 통하는 사례만 봐도 업계가 생긴 때부터 늘 흔했습니다.
  • @prerok — “빠르게 움직이고 망가뜨리자”를 말하는 건가요? 20년 넘게 프로그래밍한 사람에게는 비교적 새로운 일입니다. 예전에는 폭포수 개발이 표준이었고, CD나 DVD로 배포한 뒤에는 고장 난 제품을 내보낼 여유가 없었습니다. 인터넷이 보편화된 뒤 배포 주기가 빨라졌습니다. 요즘 설계에서 앞날을 생각하지 않거나 하위 호환성을 무시하는 일이 훨씬 잦아진 것도 사실입니다.
• @teraflop — 새 전기차에서 “EV 시스템 확인” 경고가 계속 떴지만 정비소에 도착했을 때는 사라졌습니다. 정비사는 “가끔 그러는 것 같다”고 했습니다. 하드웨어 고장인지 소프트웨어 버그인지 알 수 없었습니다. 내비게이션도 대체로 잘 작동하지만 가끔 연결이 끊기거나 경로 안내 시작 버튼이 계속 빙글빙글 돕니다. 서로 관련된 문제인지, 공통 원인이 있어 고칠 수 있는지 알 수 없습니다. 보증은 소프트웨어나 펌웨어가 제대로 작동하지 않는 문제를 보장하지 않습니다.
  • @swiftcoder — 제 Kia Niro EV도 가끔 원인을 알 수 없이 시동이 약 15분 동안 막힙니다. 예약 출발 기능이 에어컨을 켤 때 나타나곤 하지만 항상 그런 것도 아닙니다. Kia의 답변은 어깨를 으쓱하는 것이었습니다.
  • @sam1714 — 현대차는 텔레매틱스를 통해 고장 코드를 제조사에 올립니다. 다만 코드 하나만으로 원인을 알 수는 없습니다. 스택 추적, 레지스터, 당시 사용자 동작, 재현 여부가 필요합니다. OBD2는 고장 당시 여러 측정값을 저장하고, 다른 고장 코드와 발생 빈도, 이력도 함께 봐야 합니다. 진단에 필요한 데이터는 다섯 페이지에 이를 수 있습니다.
• @nikanj — 많은 문제의 최선의 해결책이 “내일 다시 해보세요”라는 점이 답답합니다. Azure의 사무실에서 여섯 시간대 떨어진 곳에 있는 백엔드 서비스가 고장 났다고 믿고, 며칠 뒤 Microsoft가 고치기를 기다립니다.
• @adamddev1 — 에이전트나 LLM 기반 개발을 옹호하는 사람들은 “이 정도면 충분하다”, “대부분 작동한다”고 말합니다. 사용자 앱 일부라면 참을 수 있을지 모릅니다. 하지만 라이브러리, 인프라, 컴파일러에서 실패를 정상화하면 모든 것이 신뢰할 수 없는 엉망이 되고 모두의 속도가 떨어집니다.
  • @gr_norm — 맞습니다. 신뢰할 수 있는 추상화가 어느 때보다 중요합니다. 나머지 사람이 바이브 코딩을 감당하려면 그 비용을 치러야 합니다.
• @WorldMaker — “신뢰도 점수”라는 이름은 사람의 확신과 같은 뜻을 암시하지만 알고리즘의 점수에는 그런 의미가 없습니다. 그 이름을 본 사업 담당자는 숫자가 언제나 의미 있는 성적이나 보편적인 백분율이라고 생각합니다. 사람은 통계를 잘 이해하지 못하기 때문에 통계만 내놓는 기계는 사람을 더 혼란스럽게 합니다.
• @benjaminsky2 — Jev의 신뢰도 점수를 검증했습니다. 제가 시험한 세 가지 사례에서는 정확도가 신뢰도에 선형적으로 비례했고 0.9를 넘으면 사람 라벨러와 같은 결과를 냈습니다. 약 3달러를 들여 예상하지 못한 사용자 행동을 발견했고, 낮은 비용과 지연 시간 덕분에 실시간으로 대응할 수 있습니다. 실제 실패 사례를 보여주지도 않고 왜 이 도구를 깎아내리는지 모르겠습니다.
  • @avianlyric — Jev의 점수를 검증했다면 평가를 만들고 실행한 겁니다. 글쓴이가 Jev를 쓰려면 해야 한다고 주장한 바로 그 작업입니다. 비판 대상은 검증 없이 점수를 믿어도 된다는 생각입니다.
• @oli5679 — 운영 자동화용 AI 시스템을 만드는데 글쓴이의 비관론은 이해하기 어렵습니다. 평가는 드뭅니다. 기업은 무엇이 좋은 결과인지 정의해야 하는데, 이 과정은 번거롭고 때로는 정치적으로 민감합니다. 적절한 평가가 있으면 최신 LLM은 작업을 자동화하고 사람 운영팀보다 정확하게 처리하는 훌륭한 도구입니다. Jev는 속도, 비용, 품질의 균형을 넓히겠다고 주장합니다. 실제로 그런지 시험해보고 싶습니다.
  • @avianlyric — 평가 없이 마법처럼 잘 작동한다는 걸 어떻게 아나요? 사람들이 AI를 쓰고, AI가 스스로 매긴 성능 점수를 검증하지 않는다는 것이 글의 요지입니다. 흥미로운 데모가 실제 환경에서는 평범한 결과로 이어지는 경우를 봤습니다. 검증이 없으면 시스템이 제대로 작동하지 않는 사실을 늦게 알아차리고, 만든 팀도 개선에 필요한 지식과 이해가 부족해집니다.

원문: I Hate the Future / 번역·요약: Trawling