▲

지금 많은 기업이 AI 집단 광기에 빠져 있다고 믿는다

 (twitter.com/mitchellh)
2P by GN⁺ 2시간전 | ★ favorite | 댓글 1개
  • 미첼 하시모토: "지금 많은 기업이 심각한 AI 집단 광기에 빠져 있으며, 그들과 이성적인 대화를 나누는 것은 불가능하다"
  • 클라우드 인프라 자동화 시대의 MTBF vs MTTR 논쟁이 이제 소프트웨어 개발 산업 전체로 확산되고 있으며, AI 에이전트에 대한 맹신이 새로운 형태의 집단적 광기를 만들어내고 있음
  • "에이전트가 빠르게 버그를 고칠 테니 버그를 출시해도 괜찮다"는 MTTR 만능주의가 횡행하고 있으며, 이는 인프라 시대에 이미 실패로 검증된 사고방식
  • 시스템이 국지적 지표상으로는 건강해 보이면서도 전체적으로는 이해 불가능한 상태로 변질될 수 있으며, 버그 리포트 감소와 테스트 커버리지 증가가 실제 안전성을 보장하지 않음
  • 이 문제를 직접 제기하면 "테스트 커버리지 100%다", "버그 리포트가 줄고 있다" 같은 즉각적 반박으로 대화가 차단되며, 전체 그림을 보지 못하는 상황
  • 변화 속도가 너무 빨라 아무도 기저 아키텍처의 부식을 인지하지 못한 채, 자동화된 "회복력 있는 재앙 기계"를 만들어가고 있음

핵심 주장: AI 집단 광기(AI Psychosis)

  • 현재 많은 기업이 심각한 AI 집단 광기 상태에 있으며, 이들과 이성적인 대화를 나누는 것 자체가 불가능함
  • 구체적인 인물을 거명할 수 없는 이유는 개인적으로 깊이 존경하는 친구들이 포함되어 있기 때문
  • 이 상황이 어떻게 전개될지에 대한 깊은 우려를 표명함

인프라 시대의 교훈: MTBF vs MTTR

  • 클라우드 전환 및 클라우드 자동화 시기에 겪었던 MTBF(평균 고장 간격) vs MTTR(평균 복구 시간) 논쟁이 다시 부상
  • 당시에는 인프라 영역에 국한되었으나, 지금은 소프트웨어 개발 산업 전체(나아가 전 세계)로 확대
  • AI 맹신론자들은 거의 절대적인 "MTTR이면 충분하다" 사고방식으로 움직임
    • "에이전트가 인간이 할 수 없는 속도와 규모로 버그를 고칠 테니 버그를 출시해도 괜찮다"는 논리
  • 인프라 시대에 배운 교훈: MTTR은 훌륭하지만, 회복력 있는 시스템 자체를 완전히 버릴 수는 없음

대화 차단과 반박 패턴

  • 이 문제를 개인적으로 아는 사람들에게 제기하면 즉각적인 무시로 이어짐
    • "아니야, 테스트 커버리지가 완전해" 또는 "버그 리포트가 줄고 있어" 같은 반응
    • 이러한 반박은 전체 그림을 보여주지 못함
  • 직접 개인적으로 우려를 전달했으나 듣지 않았으며, 더 넓은 범위에서 공유하는 것이 중요하다고 판단

자동화된 재앙 기계

  • 인프라에서 이미 한 번 배운 교훈: 자동화를 통해 "매우 회복력 있는 재앙 기계"를 만들 수 있음
  • 시스템이 국지적 지표로는 건강해 보이면서 전체적으로는 이해 불가능해지는 현상 발생
  • 버그 리포트는 줄어들지만 잠재적 위험은 폭증
  • 테스트 커버리지는 올라가지만 의미론적 이해는 하락
  • 변화가 너무 빠르게 일어나 아무도 기저 아키텍처의 부식을 인지하지 못함

주요 답글에서의 논점

  • @adamhjk: "순수 바이브 코딩이 가장 먼저 파괴하는 것이 아키텍처 자체"이며, 애초에 아키텍처가 있어야 부식을 감지할 수 있음
  • 미첼 하시모토의 추가 설명: 인프라에서는 온라인 시스템을 업데이트해 합리적인 시간 내에 모든 사용자에게 MTTR을 적용할 수 있지만, 라이브러리·데스크톱 소프트웨어·모바일 앱 등 타인이 통합하거나 직접 실행하는 소프트웨어에서는 이 방식이 통하지 않음
  • @tinygrad: AI가 말한 것이 완전히 잘못된 정보인지 판별하는 데 10초가 아닌 20분이 걸리는 시대에 진입했으며, 조직이 현실과의 접점을 유지해야 함
  • @beyang: 현재 에이전트 UX가 "LGTM(Looks Good To Me)"을 가장 저항이 적은 경로로 만들고 있으며, 에이전트가 생성하는 그럴듯해 보이는 코드의 속도가 코드 리뷰의 검증 문제를 즉각적 위협으로 격상시킴
  • @beh_zod: 출시의 보상 함수는 짧고, 사람들이 축적하고 있는 부채를 인식하는 데 걸리는 시간은 대부분의 주의 집중 범위를 넘어섬
  • @shipwithjay: 엔지니어링 리더십이 반사실적 질문(이걸 멈추려면 무엇이 사실이어야 하는가)에 답하지 못하고 침묵할 때가 증상
  • @chadfowler: 이 문제에 대한 책을 집필 중이며, 핵심은 엄격함(rigor)을 아키텍처와 평가 체계로 재배치하는 것, 지금이 그동안 시간과 비용 부족으로 실천하지 못했던 모범 사례를 실행할 기회

사람들의 질문과 의견에 대한 Mitchell Hashimoto의 답변들

  • Q: "대신 무엇을 해야 하는가?"
    • A: "생각하라 (AI를 사용하되, 생각하라)"
  • Q: "AI는 과대평가됐다"는 생각이 오히려 더 정신병적인 증상일 가능성이 높다고 봄
    • A: 모든 세속적 트렌드는 과대평가되지만, 그것이 일괄적으로 무시할 이유는 아님
  • Q: "지금 가진 것을 지키는 것과 위험 속으로 뛰어드는 것 중 하나를 선택해야 한다면, 나는 두 번째 선택을 할 것"
    • A: 이건 이분법적 스위치가 아님

함께 보면 좋은 글 β

▲
GN⁺ 2시간전  [-]
Hacker News 의견들

  • AI 구조 컨설팅이 보안 침해 대응이나 데이터 복구 전문가처럼 고가치 컨설팅의 큰 형태가 될 것 같음
    순수하게 AI가 작성한 시스템은 인간이 이해할 수 없는 복잡도까지 커지고, 결함 수정률은 줄어드는 반면 결함당 토큰 소모는 늘어나며, 결국 AI 변경이 고치는 결함보다 더 많은 결함을 만들면서 전체가 불안정해질 수 있음
    그런 난장판을 클린룸처럼 정리하고 핵심 설계 원칙을 추출한 뒤, 아마 여전히 AI를 써서 새로 재구축하는 특수한 절차가 필요해질 것임
    미래의 소프트웨어 공학은 애초에 이런 일을 피하는 원칙이 중심이 되겠지만, 기존 소프트웨어 공학도 안정된 설계 원칙에 도달하는 데 예상보다 오래 걸렸듯이 그걸 배우는 데 20년은 걸릴 듯함

    • “순수 AI 작성 시스템이 인간이 이해할 수 없는 복잡도까지 커지고…”라는 대목을 보면, AI가 정말로 크고 복잡한 소프트웨어 시스템에서 인간 수준 성능에 도달하려는 모양이라는 농담이 가능함
    • 비기술자 친구가 Claude로 재고 관리 솔루션을 바이브 코딩해서 병원 계약을 따냈음
      병원 측이 IT 부서 서버 접근권까지 줬는데, Claude를 연결할 수 없어 배포 방법을 몰라 크게 헤매며 연락해 왔고, 앱에는 흥미로운 데이터/상태 관련 문제도 있는 듯함
    • 그 복잡도는 필요 없는 장황한 복잡도일 것 같음
      마치 Amazon 물건을 무제한 무료로 집에 배송받는 사람처럼, 이론상으론 풍요로운 삶이지만 실제로는 번영이 아닌 무언가에 파묻히게 되는 모습이 떠오름
    • 원작 Westworld 영화의 대사가 떠오름: “이것들은 매우 복잡한 장비입니다… 거의 생명체만큼 복잡하죠. 어떤 경우에는 다른 컴퓨터가 설계했습니다. 우리는 정확히 어떻게 작동하는지 모릅니다.”
      그 결과가 어땠는지는 다들 알 것임
    • 최근 비슷한 고객을 만났는데, 전체 인프라와 CI/CD가 바이브 코딩되어 있었음
      수천 줄짜리 Github Actions 안에 Kubernetes를 반쯤 구현해 놓았고 이해가 불가능했음
      AI 마케팅은 싫지만, 경험 있는 사람이 더 빨리 움직이게 해주는 도구로는 유용하다고 봄
      다만 전문가가 아니면 AI는 하려는 일마다 복잡한 해법을 만들어내는 듯함

  • 그는 AI 자체 사용보다는, 회사와 사람들이 의사결정과 사고를 AI에 외주 주는 현상을 말하는 것 같음
    AI로 코드를 쓰는 게 AI 정신증이거나 나쁜 건 아니지만, 그냥 프롬프트를 넣고 AI가 말하는 걸 믿어버리면 AI 정신증에 가깝다고 봄
    Twitter의 금융권 사람들과 VC들이 주제에 대해 조금만 스스로 생각하면 될 일을 ChatGPT 스크린샷으로 사고와 추론을 대체하는 모습을 자주 봄
    이런 도구는 아이디어, 사고, 조언에는 형편없고 패턴 매칭으로 보이는 패턴을 내놓을 뿐이라, 아이디어를 얘기해 보면 대개 가장 일반적인 헛소리를 뱉음
    반면 코드 작성처럼 패턴 매칭이 실제로 도움이 되는 작업에는 꽤 유용하지만, 사고와 의사결정까지 맡기면 안 됨

    • 맞음. AI를 엄청 많이 쓰고 있고, 덕분에 예전보다 매일 더 재미있게 일하고 있음
      대체로 고점은 더 높고 저점은 더 낮아졌으며, 위의 묘사는 매우 정확함
      관련해서 쓴 글은 다음과 같음: https://mitchellh.com/writing/my-ai-adoption-journey, https://mitchellh.com/writing/building-block-economy, https://mitchellh.com/writing/simdutf-no-libcxx
      마지막 글은 AI 덕분에 한 복잡한 변경이며, 내가 어떻게 합리적으로 접근하는지도 보여줌
    • AI는 “맞는 정답”과 “틀린 정답”을 모두 준다고 생각함
      거의 항상 논리적으로 맞아 보이는 텍스트를 만들지만, 그 텍스트 안에는 해당 사용 사례에 맞지 않을 수 있는 잘못된 암묵적 가정과 결정들이 들어갈 때가 있음
      진짜 맞는 해법을 만들려면 문제 정의가 제대로 되어야 하고, 그게 해법을 만드는 것보다 더 어려울 수도 있음
    • 회사들이 Fortune이나 Inc 같은 잡지에 사고를 맡기던 것과 얼마나 다른지 궁금함
      아니면 임의의 컨설턴트에게 맡기는 것과도 비슷함
      “AI가 좋은 아이디어라고 했다”가 “업계 흐름을 따라갔다”보다 정말 더 나쁜가 싶음
    • 주변의 여러 사람이 이미 이런 단계를 겪었음
      혼자 그러는 경우에는 친구와 가족이 이상한 행동이나 말을 지적하면서 어느 정도 제동이 걸림
      하지만 고용주가 리더십 차원에서 그렇게 하기 시작하면 얼마나 나빠질지 상상하기 어려움
      동참하라는 압박을 받거나 해고를 두려워하게 되고, 생각을 조절해 줄 사람은 반대하는 동료뿐인데 그런 사람들은 떠나거나 해고될 가능성이 큼
      직장을 지키려면 맞춰서 행동해야 함
    • 사고를 AI에 외주 주면 마법 같은 속도 향상이 생김
      에이전트가 대신 결정을 내리기 때문에 에이전트 속도로 일이 움직이고, 종종 말도 없이 결정을 내린 뒤 “계획은 이렇다”는 최종 출력만 줌
      그걸 제대로 검토하려면 문제를 깊이 이해해야 해서 다시 인간 속도로 돌아가야 하니, 결국 대충 훑고 승인하게 됨
      핵심은 어떤 결정을 외주 줄지 의식적이고 신중하게 정하는 것임
      그러려면 속도를 늦춰야 하고, 과장된 10배 바이브 코딩 이득은 줄어들지만, 대신 더 많이 개입하고 인지 부채도 덜 쌓임
      배열을 어떻게 순회할지, 한 호출의 출력을 다른 호출의 입력으로 어떻게 맞출지 같은 지루한 결정은 에이전트에게 맡기면 됨
      진짜 결정은 미리 하고 명세에 담아야 함: 경계, API, 핵심 자료구조, 시스템과 책임, 오류 처리, 보안과 개인정보의 강한 제약을 정의해야 함
      모호하면 멈추라고 에이전트에게 지시해야 하며, 좋은 엔지니어라면 부작용 없이 2~3배 속도 향상을 얻을 수 있음

  • 어쩌면 이 일이 소프트웨어 공학을 진짜 공학 분야로 바꿀지도 모름
    지금은 프롬프터들이 회사 전체 인프라를 세우고 있음
    개인적으로 아는 한 사람은 회사 데이터베이스를 더 새 Postgres 버전으로 마이그레이션했고, 결국 성공하긴 했지만 과정을 설명하는 걸 들으며 이를 갈았음
    “서버에 휘발유를 붓고 담배를 피웠지만 걱정 마, 지하실에서 소화기를 찾았어. 게이지는 비었다고 나오지만 흔들면 아직 액체 소리가 나” 같은 느낌이었음
    그가 회사를 떠나면, 그 DB 인프라를 유지할 더 자신감 넘치는 프롬프터가 필요해질 것임

  • 이 글은 “버그를 배포해도 괜찮다, 에이전트가 인간이 못 하는 속도와 규모로 고칠 수 있다”고 말하는 사람들과는 논쟁할 수 없다고 짚음
    그런데 최상위 답글이 바로 “하지만 에이전트는 엄청 빠르다”고 주장하는 예시임

    • 도구가 출시 전에 버그를 고칠 만큼 충분히 좋고 빠르지 않다면, 출시 후에는 어떻게 그렇게 쉽게 따라잡을 수 있다고 믿는지 모르겠음
      코드베이스와 기능이 두 배가 되는 이득이 버그가 두 배가 되는 피해보다 크다고 가정하는 것일 수도 있음
      적어도 이번 분기 투자자 뉴스에는 좋아 보이겠지만
    • 수정에도 버그가 없다는 걸 어떻게 아는지 모르겠음
      계속 더 많은 쓰레기를 배포하게 될 수도 있는데, 피드백 루프는 고객인가?
    • 그렇게 빠르다면 배포 전에 버그를 빨리 고치면 됨
    • AI 붐 초기에 친구와 이야기하면서, AI에 과도하게 의존하면 온갖 참사가 생길 거라고 했음
      돌아온 답은 “게임 이론이야. 누군가는 할 거고, 너도 할 수밖에 없어. 그렇게 나쁠 리 없어”였음
      논리는 유용하지만 위험을 무시하는 건 별개임
      엄청 빠르게 움직이며 모든 걸 박살 내면 결국 좋은 결과가 나온다고 가정하는 건 위험함
      이 AI 흐름은 잘 진행되고 있지 않고 마음에 들지 않음
    • 현실적으로 내 사업은 버그가 있어도 더 높은 효율로 계속 운영되고 있음
      정신증이 있는 쪽이 꼭 “우리 쪽”이라고는 생각하지 않음

  • 아주 큰 회사에 다니는데, 우리 회사는 언제나 현대화와 기술 도입이 빙하처럼 느렸음
    그런데 이상하게도 이제 그게 경쟁 우위가 될 수도 있음

    • 말 그대로 Battlestar Galactica 줄거리임
      삶이 예술을 따라감
    • 독일에서 일하는 게 이렇게 기뻤던 적이 없음
      예전에는 아직도 팩스가 남아 있다는 식으로 농담했지만, 이런 열풍이 없는 문화권에서 일하는 게 이렇게 다행일 줄 몰랐음
      HN을 읽으면 토큰 극대화주의자와 AI 정신증 환자의 Alice's Wonderland에 들어가는 느낌임
      여기서는 이런 식으로 일하라고 강요받는 사람을 진짜 한 명도 모름

  • 이런 느낌이라면 새 CLI 도구 Burn, Baby, Burn (those tokens) 가 마음에 들 수도 있음: https://github.com/dtnewman/burn-baby-burn/tree/main
    Show HN은 여기 있음: https://news.ycombinator.com/item?id=48151287

  • Rich Hickey의 Simple Made Easy와 Clojure를 만들 때의 접근이 떠오름
    LLM이 전체 프로그램을 생성하기 전에도, 복잡한 프레임워크는 개발자가 프로그램의 초기 버전을 매우 빨리 만들게 해줬지만 이해하기 어렵고 그래서 디버그와 수정도 어려워지는 대가가 있었음
    어떤 사람들은 AI가 아무리 뒤얽히고 복잡한 프로그램을 작성하더라도, AI가 항상 충분히 똑똑해서 디버그하고 유지보수하고 수정할 수 있을 거라고 베팅함
    나는 그렇게 확신하지 못하겠음

  • AI 정신증은 AI 사용에 반대하는 입장이 아님
    AI 코딩 도구를 매일 쓰지만, AI 도구에는 미래라는 개념이 없음
    “이게 운영에서 깨지면 내가 못 고칠 텐데, 새벽 3시에 나를 호출하겠지”라고 생각하는 엔지니어의 이기적인 사고에 우리는 안정적인 시스템 구축을 의존해 왔음
    CPAN에서 완벽한 라이브러리를 찾아 직접 일하지 않으려는 일반적인 게으름도 있었고, 때로는 직접 쓰는 것보다 라이브러리를 못 찾는 데 더 오래 걸렸음
    AI 도구로 수천 줄의 코드를 작성해 운영에 넣었고 대체로 자연스럽게 느껴졌는데, 2017년부터 사람들에게 코드를 전부 직접 타이핑하지 말고 작성하라고 말하며 테스트에서 나쁜 코드를 잡는 함정을 설치해 왔기 때문임
    하지만 AI가 하지 않는 한 가지는 코드를 덜 쓰는 것임: https://xcancel.com/t3rmin4t0r/status/2019277780517781522/

    • 프롬프트 때문인지 모르겠지만, 내 코딩 에이전트는 Opus 4.7 기반이고 “이런 게 6개월 뒤 새벽 2시에 터질 종류” 같은 말을 자주 함

  • 버그 보고는 사람들이 고쳐질 거라는 믿음을 잃어도 줄어듦
    버그를 보고하는 일은 꽤 큰 시간 투자가 필요한 경우가 많기 때문임
    어떤 그룹이나 회사에 대한 신뢰가 무너질 때 이런 일이 꽤 자주 일어남

    • 여기에 실제로 접수되는 보고서의 상당 부분이 AI가 생성하거나 다시 쓴 것일 가능성도 더해짐
      그 때문에 잘못 보고될 가능성이 높고, 일부 내용이 틀릴 수도 있음
      여러 방향에서 공격받는 셈임
      적대적 전술까지는 아직 들어가지도 않았음
      도덕이 없다면 에이전트로 경쟁사에 가짜 버그 보고를 쏟아붓는 것보다 좋은 방법이 뭐가 있겠나
    • 그냥 AI가 버그를 보고하게 하면 됨
      문제 해결임
    • 맞음. 다만 이 문제는 AI 주도 프로젝트에만 있는 건 아님
      Mitchell이 관찰한 것의 상당수, 어쩌면 전부는 AI가 없어도 충분히 일어날 수 있음

  • 정말 이상한 위치에 있다고 느낌
    AI가 코드 작성의 경험과 실천에 가져오는 변화가 너무 싫어서, 컴퓨터를 쓰는 일 말고는 뭐든 하고 싶을 정도이지만, 동시에 이 도구들이 매우 강력하고 계속 좋아지고 있다고도 생각함
    Mitchell의 요지는 타당함. 이런 도구가 썩은 기초를 들여와도 전체 구조가 무너진 뒤에야 발견될 수 있음
    그때 책임져야 하는 자리에 있으면서 예전처럼 코드베이스를 깊이 이해하지 못하는 상황은 피하고 싶음
    하지만 인간도 오래전부터 미묘하면서도 치명적인 버그를 코드에 넣어 왔음
    그래서 많은 부분은 아직 열려 있는 경험적 질문처럼 느껴짐
    예전에는 없던 방식으로 끔찍하게 무너지는 시스템을 많이 보게 될까? 일부는 그럴 수 있음
    동시에 명세와 검증 쪽으로 더 이동해야 한다는 걸 배우게 되지 않을까? 잘 모르겠음
    어쨌든 이 방식의 시스템 구축은 중간에 충돌이 있더라도 피할 수 없어 보임
    반AI 진영에도 나름의 반동적 정신증이 있는 것 같음
    AI와 엮이고 싶지 않지만, 이 도구를 써 본 경험도 부정할 수 없음
    이런 현실적이지만 부정적인 AI 논의를 할 공간이 더 많았으면 함
    Mitchell이 좋은 개발자인 이유도 여기에 있음

답변달기