AI가 만든 소프트웨어 실패, 이제 '그냥 별로야'로 끝내나

The Normalization of Inexplicable Failures

▲ 272pxx116 HN 토론

TypeSafe AI의 Jev는 빠르고 저렴하며 신뢰도 점수를 제공하지만, 그 점수의 보정이나 불확실성 비용 모델 없이는 무의미하다. 개발자들은 평가 없이 AI를 도입하고, 실패하면 'AI는 실수한다'며 넘어간다. 저자는 LLM 가속 개발이 오히려 QA 자동화를 가능하게 함에도, 사용자와 빌더 모두 실패 원인을 추적하지 않는 현상을 '설명 불가능성의 정상화'라 비판한다.

오늘날 소프트웨어 공학의 비극은 우리가 사용자와 빌더 모두 문 뒤에 시체가 있는지 확인할 관심이 없는 시스템을 적극적으로 설계하고 있다는 점이다. 우리는 그저 어깨를 으쓱이며 결론 내린다: 멍청한 게 별로야.
원문 읽기 →HN 토론RSS

HN 토론

116
  1. pmarreck

    저는 재현성(nix 애호가)과 결정성(테스트 실패 플래그는 제 세계에서는 빨간 경보, 전원 비상 소집 상황) 그리고 정확성에 아주 진심인 사람입니다.

    저는 또한 (올바른 것들에 대한) 테스트에도 진심입니다. 그리고 나인나인(nine-nines)에도요 (Elixir에 진심).

    그리고... 저는 에이전트 지원 개발에도 진심입니다. 그러려면 생산성을 유지하기 위해 책에 나오는 거의 모든 검사를 수행해야 하죠. 그리고 저는 그게 괜찮습니다. 제가 직접 만들지 않았을 버그들을 봤습니다. 그리고 제 자신의 버그가 고쳐지는 것도 봤습니다. 모두 단시간에 고쳐졌습니다. 이게 왜 문제인지 모르겠습니다.

    개인적인 기준을 높이세요.

    문제는, 신뢰할 수 없는 소프트웨어 상황은 (형편없는 손에 들어간) 에이전트가 더 악화시키기 전에도 이미 감당할 수 없을 지경이었습니다.

  2. adamddev1

    훌륭한 글입니다. 사람들은 항상 에이전트/LLM 기반 개발을 옹호하면서 "뭐, 충분히 괜찮아", 또는 "대부분의 경우 작동해"라고 말합니다.

    일부 사용자 대상 앱에서는 그게 용인될 수도 있습니다. 하지만 우리가 라이브러리, 인프라, 컴파일러에서의 실패를 정상화하기 시작하면 어떨까요? 모든 것이 신뢰할 수 없는 혼란으로 전락하고, 그것은 모든 것과 모든 사람을 느리게 만듭니다.

  3. theamk

    > 웹사이트에서 버튼이 고장 나면, 저는 무슨 일이 일어났어야 하는지에 대한 모델을 가지고 있습니다. 어딘가에서 계약이 깨진 겁니다. [...] HTTP 상태 500 하나만으로 디버깅할 권한이 없을 수도 있지만, 그 엔드포인트가 왜 500을 내는지 이해하는 것이 누군가의 일이기를 기대합니다. 소유권은 불투명하지만³ 잘 정의되어 있습니다.

    > 그러나 많은 사용자에게 실제 경험은 대략 "바보 같은 게 짜증나" 정도입니다. 소프트웨어는 이미 변덕스럽게 느껴집니다. 실패가 더 많아지면 좌절의 빈도만 바뀔 뿐입니다.

    저자는 클라우드 서비스를 많이 사용하지 않을 거라고 장담합니다. "사용자"만이 아니라 개발자도 마찬가지입니다. Github이 5xx를 반환한다고? AWS 서비스가 작동하지 않는다고? 이메일이 전달되지 않았다고? 우리(개발자)가 할 수 있는 일은 아무것도 없습니다. "바보 같은 게 짜증나".

  4. layer8

    > 이것은 설명 불가능성의 정상화로 이어집니다.

    이는 책임의 부재 정상화와도 밀접하게 연결되어 있습니다.

    > 이건 "FTP 계정을 받아서 curlftpfs로 로컬에 마운트한 다음, 마운트된 파일 시스템에서 SVN이나 CVS를 사용하는 것"이 아닙니다 -- 어려운 부분은 여전히 직접 해야 합니다.

    이쯤에서 아마 젊은 독자층은 떠나고 있을 겁니다. ;)

  5. WorldMaker

    "신뢰도 점수"는 항상 존재하지 않는 인간 중심적 의미를 함축해 왔습니다. 알고리즘은 사람이 신뢰를 가지는 방식으로 "신뢰"를 가지지 않지만, 그런 이름이 붙은 것을 비즈니스 사람 앞에 내놓는 순간 그 숫자가 항상 의미 있는 "문자 등급 곡선"이나 "보편적 백분율"이라고 가정합니다. 저는 "거짓말, 빌어먹을 거짓말, 그리고 통계"라는 옛말이 ML이 과대광고 대신 멍청한 결과로 이어지는 이유를 이해하는 열쇠라고 여전히 굳게 믿습니다. 사람들은 통계를 이해하지 못하므로, 통계만을 생산하는 기계는 특히 사람들을 혼란스럽게 합니다. (이것은 LLM에도 적용된다고 느낍니다.)

  6. teraflop

    "설명 불가능성의 정상화"는 정말 분노를 일으킵니다. 컴퓨터 소프트웨어에서는 항상 나빴고, 이제는 임베디드 소프트웨어에 의존하는 다른 소비자 제품으로 점점 스며들고 있습니다.

    저는 최근에 새 전기차를 샀습니다. 대체로 꽤 만족하고 있습니다. 차를 산 직후, 시동을 걸 때마다 "check EV system"이라는 경고 메시지가 뜨기 시작했습니다. 딜러십에 가져갔을 때는 경고가 사라져 있었고, 기술자는 "어, 가끔 그런가 보네요, 다시 발생하면 알려주세요" 정도로 말했습니다. 하드웨어 결함? 소프트웨어 버그? 누가 알겠습니까?

    대부분의 현대 자동차처럼, 인포테인먼트 시스템에 연결성과 Google Maps가 내장되어 있습니다. 대부분의 경우 잘 작동합니다. 때로는 주행 내내 연결성이 없다고 말합니다(교통 데이터 없음, 최적이 아닌 경로를 의미). 평소 잘 작동하는 강한 휴대폰 신호 지역에서도 그렇습니다. 때로는 차가 연결성이 있다고 말하는데 Google Maps는 여전히 오프라인이라고 생각합니다. 때로는 Maps가 실제로 경로를 로드하고 표시하지만, "내비게이션 시작" 버튼이 마치 무언가를 기다리는 것처럼 영원히 돌기만 합니다. 이것들이 관련된 문제일까요? 고칠 수 있는 공통 원인이 있을까요? 누가 알겠습니까?

    (편리하게도, 보증은 소프트웨어나 펌웨어가 올바르게 작동하지 않는 모든 실패를 구체적으로 보장하지 않습니다.)

  7. benjaminsky2

    저는 Jev의 신뢰도 점수를 검증했습니다. 제가 테스트한 3가지 사용 사례에서 정확도는 신뢰도에 따라 선형적으로 증가했습니다. >.9에서는 인간 라벨러와 일치했습니다. 약 $3로 예상치 못한 사용자 행동을 즉시 발견했습니다. 낮은 비용과 지연 덕분에 이제 실시간으로 완화할 수 있습니다. 이는 모든 고객에게 재정적으로 큰 긍정적 영향을 미칠 수 있습니다.

    실제 실패 사례를 보여주지 않고 왜 이걸 깎아내릴 필요를 느끼는지 모르겠습니다.

  8. hyperhello

    제품에 더 많은 시간을 쏟으면, 실패나 짜증 때문이라도 다시 선택할 가능성이 더 높아집니다. 어떻게든 정당화하겠죠(이제 내가 우위에 있다든가). 이는 사물을 보는 것에도 실제로 적용됩니다. 슈퍼마켓 진열대의 밝은 색 상자는 단지 먼저 그리고 더 오래 보기 때문에 선택될 가능성이 더 높습니다.

    당신의 시간과 자원을 낭비하게 만드는 것은 권력의 표시지만, 당신이 스스로의 시간과 자원을 낭비하게 만드는 것은 헤게모니입니다.

이 날의 다른 글

2026-09-27