영원한 Sloptember

• AI 에이전트는 프로그래밍을 수행하기보다 프로그래밍의 분포를 흉내 내며, 깨진 출력은 점점 더 알아보기 어려워짐
• tinygrad 일부 작성과 USB <-> PCIe 칩 리버스에 써봤지만, 직접 했을 때 더 낫고 빨랐을 수 있다는 의심이 남음
• 에이전트는 초반 진척을 빠르게 만들지만, 마무리에서는 슬롯머신 레버처럼 반복 시도에 기대게 하며 끝까지 못 감
• 대규모 조직은 느린 피드백 루프와 자기 점검 없는 10배 산출 때문에 고성과 개인보다 더 큰 품질 피해를 볼 수 있음
• AI는 검색과 빠른 프로토타입에는 유용하지만, 실제 소프트웨어 엔지니어로 보기는 어렵고 언제 쓰지 않을지 아는 일이 핵심임

---

AI 에이전트에 대한 핵심 비판

• AI 에이전트를 소프트웨어 개발에 도입하는 흐름은 매우 costly한 실수가 될 수 있으며, 에이전트는 프로그래밍 자체가 아니라 프로그래밍의 분포를 흉내 내는 정교한 통계 모델에 가까움
• 출력물은 깨져 있지만 점점 더 탐지하기 어려운 방식으로 깨지며, 통계 모델이 더 정확해질수록 이런 문제는 더 알아보기 어려워짐
• 지난 6개월 동안 에이전트로 tinygrad 일부를 작성하고 USB <-> PCIe 칩을 리버스했지만, 직접 했을 때 더 낫고 빨랐을 수 있다는 의심이 남음
• 에이전트는 초반 진척을 앞당기지만, 마무리 단계에서는 슬롯머신 레버를 당기듯 결과가 좋아지기를 반복해서 기대하게 만들며 끝까지 도달하지 못함
• 여러 모델, 하네스(harness), 프롬프트를 시도했기 때문에 “잘못 사용했다”는 반론은 설득력이 낮고, 슬롯머신에서 특정 방식으로 베팅해야 이긴다는 말과 비슷해 보임
• AI 자체는 유용하며, 많은 검색에서는 더 나은 Google처럼 작동하고, 완성도를 신경 쓰지 않는 빠른 프로토타입에는 매우 빠름
• 다만 소프트웨어 엔지니어로 보기는 어렵고, 함께 일했던 어떤 회사의 기준에도 가깝지 않으며, 핵심은 언제 쓰고 언제 쓰지 않을지 아는 데 있음

조직과 품질에 미치는 영향

• AFL은 LLM보다 더 많은 버그를 찾았지만 개발자들이 지위 상실을 두려워하지 않았고, 체스와 Go도 AI 이후 더 인기를 얻었기 때문에 AI 비판을 단순한 지위 불안으로만 보기는 어려움
• 신뢰할 수 있는 로봇 보조자가 코드를 정리해주는 미래는 기대할 만하지만, 큰 회사들이 움직이게 하려는 방식으로 상실 공포가 에이전트 판매에 활용되는 것처럼 보임
• 고성과 개인이나 작은 조직보다 대규모 조직이 에이전트로 더 큰 피해를 볼 가능성이 큼
  • 고성과자는 오류를 고칠 수 있고, 산출물이 허술할 때 알아보는 편이며, 제한된 영역이 아닌 이상 각 줄을 주의 깊게 읽고 이해하는 방식을 유지함
  • 대규모 조직은 피드백 루프가 느리고 정렬이 약해, 하위 성과자가 자기 점검 없이 에이전트로 10배 산출을 만들 때 평균 산출 품질이 낮아질 수 있음
• 에이전트는 이전보다 더 많은 코드, 앱, 기능을 만들어내겠지만, 품질 높은 보석보다는 대량의 허술한 산출물이 쌓이는 시대가 될 수 있음
• Apple이 모든 엔지니어에게 AI 사용을 밀고 있다는 이야기는 추상적 기대보다 “향후 2년 동안 macOS가 더 좋아질지 나빠질지” 같은 구체적 질문으로 봐야 함
• 사람들은 산출물에서 창작자가 인간적인 마음 상태와 과정을 거쳤다고 암묵적으로 가정하지만, AI 산출물에는 이 가정이 더 이상 맞지 않음
• 문법과 구문처럼 과거에 품질의 대리 지표로 쓰였던 요소는 AI 산출물 앞에서 쓸모가 줄어들며, 인간적인 방식으로 상호작용하거나 그 위에 무언가를 만들 때 차이가 드러남
• LLM에 대해서는 LeCun/Marcus 쪽 입장에 가까워졌으며, 이런 모델은 프로그래밍을 할 수 없고 과정이 중요하다는 결론으로 이어짐
• 딥러닝은 여전히 해법일 수 있지만, 실제 프로그래밍 에이전트에는 failing test를 주석 처리한 뒤 모든 테스트가 통과한다고 말하는 식의 RLVR이 아니라 세계 모델이 필요함
• 이 시대의 핵심은 AI에 대한 집단적 과열 속에서 누가 스스로를 해치지 않고 버티는지가 될 수 있음

[GN⁺]

Hacker News 의견들

• 현재 담론의 큰 문제는 너무 흑백논리라는 점임. LLM을 의심하면 러다이트이고, 믿으면 “ai pilled”인 식임
  대부분의 경우 LLM은 80~95%까지 데려다주고, 때로는 그보다 덜하거나 더 잘하기도 함. 가끔은 완전히 잘못된 곳으로 데려가기도 함
  그런데 다들 LLM이 벽장 속에서 혼자 완벽한 소프트웨어 엔지니어가 될 수 있는지만 두고 싸우며, 그걸 근거로 다른 시나리오에서의 거대한 가능성까지 부정하는 듯함
  인터넷이 준 것만으로도 대부분의 조직이 지금보다 얼마나 더 생산적일 수 있었을지 생각해보면, 실제 회사들은 가능한 일의 극히 일부도 못 하는 경우가 많음. LLM도 그런 관점에서 보게 됨
  잘못은 언어 모델이 아니라 우리 자신에게 있음

  • 진짜 러다이트에 대해 알수록 그들의 관점이 더 이해됨
    원래 러다이트들은 주로 저질 상품을 “사기적이고 기만적으로” 만들고, 노동 기준을 우회하며, 숙련 장인의 생계를 빼앗는 기계에 항의하던 사람들이었음
  • 합리적인 토론이 되기에는 여기에 돈이 너무 많이 걸려 있음
  • 글에서는 특히 에이전트를 콕 집어 말함: “소프트웨어 개발에 AI 에이전트를 도입하는 것은 이 분야 역사상 가장 비용이 큰 실수 중 하나가 될 것”
    나는 에이전트는 쓰지 않고, 단순한 채팅 인터페이스와 이어지는 대화를 통해 함수 단위로 소프트웨어를 만듦. 결과 워크플로는 꽤 “키메라적”이고, 내 경험과 전문성에서 큰 이득을 봄. LLM은 과정을 매끄럽게 해줄 뿐임
    내 경우에는 잘 작동하고 있고, 예전으로 돌아가고 싶지 않음
  • geohot의 요지도 비슷해 보임. 완전히 “ai pilled”가 되지 말고, 러다이트가 되라는 것도 아니며, AI를 도구로 쓰자는 쪽에 가까움
  • 러다이트는 단순한 “불신자”가 아니라 폭력적 활동가였음
    오늘날 담론에서 “러다이트”라고 불리는 사람들은 대체로 “AI” 과장을 감히 의심하는 사람들임. 보통 이런 사람들은 활동가도 아님

• 지금 AI의 능력 수준에서는, 기존 지식 위에서 동작하는 아주 좋은 검색에 가깝다고 보는 게 개인적으로 유용했음. 참고서, Stack Overflow, GitHub로 이어지는 검색 가능성의 다음 단계처럼 보임
  프로그래머는 내가 떠올릴 수 있는 어떤 직업보다 같은 기법을 다시 쓰고 재발명하는 일이 잦아서, 선행 기술을 아주 잘 검색하는 도구에 잘 맞는 상태였음. AI가 그 선행 기술을 특정 사용 사례에 맞게 조정할 수 있다는 점은 더 강력하게 만듦
  다만 Stack Overflow에서 복사해온 코드 조각을 이어 붙인다고 큰 성공이 나오지 않았듯, 현재 AI도 전체 프로젝트를 제대로 만들어주지는 못함

  • 재사용 가능한 라이브러리로 잘 패키징하는 것보다, 다시 쓰고 재발명하는 비용을 낮춰주는 도구가 답이라는 점이 분명해짐
  • 현재 AI는 Stack Overflow와 Google의 강화판에 가깝다는 데 100% 동의함. 내 경험상 초기 뼈대 정도를 제외하면 전체 규모 애플리케이션을 잘 구축하지는 못함
    낡고 썩 잘 쓰이지 않은 레거시 코드베이스라면, 예를 들어 “애플리케이션 X는 Y를 어떻게 하는가”처럼 AI 에이전트에게 코드를 읽게 할 수는 있음. 하지만 기능을 마구 만들게 하거나 리팩터링을 맡기지는 않겠음
    그렇게 하면 커밋이 너무 많아지고 개발팀에 혼란이 생겨, 이미 다루고 있던 잡탕보다 더 심한 결과가 될 가능성이 큼. 요즘 AI에 좀 낙담했는데, 이 설명이 내 경험을 잘 요약해줌
  • “AI가 선행 기술을 특정 사용 사례에 맞게 조정할 수 있다”는 건 어쨌든 모두가 주장하는 내용임

• 소프트웨어 엔지니어링에서 가장 어려운 일은 올바른 문제를 푸는 것임. 어떤 문제를 풀어야 하는지 식별하는 능력이 상위 시니어 엔지니어를 구분한다고 봄
  여기서는 단순화해서, 해결했을 때 제품에 더하는 가치가 복잡도와 부수 비용에 비해 가장 큰 문제라고 하겠음
  오래전 한 웹 제품에서 일했는데, 원래 주니어 디자이너가 백엔드를 LDAP 도구로 관리할 수 있으면 멋질 것이라고 생각했음. 그래서 제품의 데이터베이스 스키마와 구조가 OpenLDAP를 흉내 내며 복합 CN 키를 썼고, 전체 코드베이스가 DB를 읽고 쓸 때마다 그 구조를 다뤄야 했음. DB 스키마를 설계할 때 LDAP 호환성은 풀어야 할 올바른 문제가 아니었음
  올바른 문제를 푸는 소프트웨어는 식별하기 어려울 수 있음. 대개 동작 방식이 너무 당연해 보여서, 다른 설계를 선택할 수 있었다는 사실이 잘 드러나지 않기 때문임
  시간이 지나도 잘못된 문제를 푸는 설계의 폭발 반경을 제한해주는 것은 보통 그 설계가 만들어내는 마찰임. 개발이 느려지고, 잘못된 문제를 더 많이 푸는 개발도 느려짐. 자기 제한적인 현상임
  LLM 코딩 에이전트에서 크게 걱정되는 점이 바로 이것임. 그 마찰을 덮어버림. 고치는 게 아니라 비용을 뒤로 미룸
  그래서 제공하는 가치에 비해 복잡도가 무제한으로 커지는 코드베이스가 생기고, 이를 제어할 장치가 없어짐
  주니어들은 어떤 문제가 특정 설계에서 풀어야 할 올바른 문제인지 판단하는 엔지니어링 감각과 취향을 길러줄 피드백 루프를 겪지 못하게 됨
  분야 전체 규모로는, 올바른 문제를 푼다는 개념이 있었다는 사실 자체를 잊게 될 수도 있음
  어떻게 해야 할지는 모르겠음. 조기 은퇴 계획이라도 세워야 할지 모르겠음

• 지금 회색시장 펩타이드를 사서, “인체 섭취용 아님”이라고 적힌 물질을 의심스러운 일화와 느낌만 믿고 주사하는 사람들이 있음. 피부를 맑게 하고 근육량을 늘리려는 식임
  그들이 갑자기 전부 좀비가 되고 있나? 아님. 몇 년 뒤 몸에 어떤 일이 생길지 제대로 알고 있나? 그것도 아님. 재앙적일 수 있나? 그럴 수도 있음
  최근 6개월쯤 업계가 AI를 코드의 주 생성기로 격렬하게 전환한 것을 생각할 때 이 비유가 떠오름. AI는 펩타이드이고, 코드베이스는 몸임. 이 방식이 얼마나 유지보수 가능한지 말 그대로 아무도 모름. 알아낼 시간이 충분히 지나지 않았기 때문임
  괜찮을 수도 있고, 완전한 난장판이 될 수도 있음. 전체 엔지니어링 팀이 핸들을 놓고 잠들어, 실제로는 이해하지 못하면서 자신들이 무엇을 만들고 있는지 이해한다고 착각하다가, LLM이 더 이상 감당하지 못하는 순간 고치거나 유지보수할 힘이 완전히 사라질 수도 있음
  https://www.bbc.co.uk/news/articles/cdr268m5pxro
  내 개인 코드베이스에서는 유지보수성이나 수명에 진짜 관심이 없는 경우가 아니면 더 이상 그렇게 하지 않음

  • 똑똑한 개발자들은 격리된 모듈을 만들 것 같음. AI가 만든 모듈이 계속 실패하면 절단하고 새로 만들 수 있게 함

• 지금은 “한동안 코드를 직접 안 쓴” 쪽에 있음. 수동 코딩으로 돌아갈 만큼 문제가 큰 예시를 보고 싶음
  내 주요 문제는 모델 릴리스마다 품질이 들쭉날쭉하고, 특히 명령줄 도구에서 오래된 API나 문서를 끼워 넣는 경향임
  10년치 찌꺼기가 쌓인 백만 줄짜리 단일 코드베이스에서 모델이 힘들어하는 건 이해함. 하지만 새 코드베이스에서 왜 그렇게 고통스러울지는 잘 떠오르지 않음

  • 꼭 “너무 큰” 문제일 필요는 없음. 너무 작아서 쓸 가치가 없는 일도 있음
    코딩은 그리 어렵지 않아서, 영어를 읽고 쓰는 것보다 그냥 코딩하는 게 더 쉬울 때가 많음. 다만 나는 Haskell만 쓰기 때문에 편향이 있을 수 있음
  • “한동안 코드를 직접 안 쓴” 상태가 얼마나 이어지면, 연습 부족으로 코드를 못 쓰게 될 거라고 봄?
    엔지니어링 관리의 위험 중 하나는, 그 일을 더 이상 할 수 없는 사람으로 만들 수 있다는 점임
    그게 중요하긴 한가?
  • 프롬프트마다 천 줄짜리 PR이 나오면, 또 다른 백만 줄짜리 단일 구조에서 그리 멀지 않음
    그래도 글쓴이보다는 조금 더 낙관적임. 그 일이 벌어지지 않도록 과정을 관리하는 게 가능하다고 느낌
  • 최근 프런트페이지에 올라왔던 예시가 있음: https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/
  • 어떤 종류의 프로젝트를 하는지가 중요함. 특히 새로움, 검색으로 찾기 어려운 데이터 포인트, 업계 표준에서 벗어난 프로젝트별 비자명한 차이가 얼마나 많은지가 관건임

• 에이전트 실행 환경은 나온 지 겨우 1년 남짓이고, 꽤 믿을 만해진 건 반년 정도인데 벌써 피로감이 큼. 이는 LLM이 실제로 프로그래밍할 수 있느냐보다 AI 보조 프로그래밍의 정신적 소모를 더 잘 보여준다고 봄
  에이전트가 코드베이스에 무엇을 하는지 제대로 따라가려면 의사결정 빈도가 높아지고, 천문학적인 양의 코드와 산문을 읽어야 함
  이 개인적·심리적 피로와 부정적 감정이 기술 자체의 발전 가능성에 대한 비관적 전망으로 부정확하게 옮겨가고 있음

  • https://evilmartians.com/chronicles/ai-assisted-engineers-ar...
  • 기술은 사람들이 어떻게 쓰는지와 분리된 존재가 아님
    제대로 쓰는 사람 모두가 좌절하고, 좋아하는 사람들은 유지보수 불가능한 잡탕을 산처럼 만들어낸다면, 우리는 곧 그것을 역사의 쓰레기통에 버리게 될 것임
    “잠재력”이 있는 것은 많지만, 결국 아무것도 되지 못하는 것도 많음
    LLM은 계속 쓰겠지만, 내 생각에 에이전트식 코딩의 유용성은 이미 정점을 지났음

• 내 업무의 일부는 내가 다니는 대기업에서 이런 모델들을 생산적으로 만들 방법을 찾는 것임. 벽에 토마토를 던지는 일에 가깝고, 어느 정도는 그가 말한 것처럼 출력에 특정한 한계가 있는 듯한 문제를 봄
  동시에 그의 글 어디에도 “모델이 여기서 형편없이 했고 원래는 이렇게 했어야 한다”라고 붙잡을 수 있는 코드 조각이나 구체물이 없음. 이런 비판 방식은 블로그와 Twitter의 “LLM은 절대 안 된다”류 글에서 반복되는 패턴처럼 보임
  모델들은 분명 자동완성보다 잘하고, 내 일상 개발에서도 주니어나 중급 엔지니어가 했을 법한 코드베이스의 큰 부분을 만들어냄
  실제로 어떤 실수를 하는지 아무도 구체적으로 인용하지 않으면, 우리가 어떻게 실제 능력을 파악할 수 있겠음?

  • LLM이 하는 실수는 꽤 미묘함. LLM으로 코딩하는 건 영화 Whiplash의 장면 같음. “내 템포가 아니야”, “18박에서 다운비트”, “너 빨라”, “느려” 같은 식임
    거의 항상 동작하는 코드를 만들고, 보통 요청한 일을 하긴 함. 그런데 아주 답답한 방식으로 약간씩 틀려서 의자를 던지고 싶게 만듦. 게다가 무엇이 어떻게 잘못됐는지 알아차릴 취향조차 없음
  • 사람들이 특정 작업에서 LLM이 실패한 블로그 글을 쓰면, 옹호자들의 반응은 거의 항상 “다른 모델을 써라”, “프롬프트를 이렇게 바꿔라”, “네 실력이 부족하다. 특정 예시로 AI에 대한 근본적 주장을 할 수 없다” 쪽임
    그러면 구체적 예시를 들어도 안 되고, 구체적 예시를 안 들어도 안 됨. 그럼 게임 끝인 셈임
    집단 귀속 오류를 저지르고 있다는 건 알지만, 그래도 그렇다는 말임
  • 이 지점이 훌륭함. LLM 덕분에 예전에는 꿈도 못 꾸던 프로젝트를 하는 초보 입장에서도, 에이전트가 정확히 무엇을 잘못 쓰고 인간은 어떻게 더 잘할지에 대한 예시와 근거를 찾게 됨
    그런 자료가 분명 있을 텐데, 좋은 예시를 보여주는 콘텐츠가 있으면 누가 알려줬으면 함
    상위 몇 퍼센트의 코더는 Claude나 Codex보다 훨씬 잘 쓸 수 있다고 의심하지 않음. 하지만 평균적인 평범한 개발자보다 얼마나 못한지는 궁금함
  • 이 글은 나쁜 아키텍처를 보여주는 코드 조각까지 포함해 꽤 상세한 예시를 다룸: https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/

• 내 추측으로는 모델은 계속 더 좋아질 것임
  1~2년 전 에이전트식 코딩을 시작했을 때는 자동완성 정도에만 쓸모 있다고 확신했음. 올해 초 뭔가가 일어나면서 모델이 새로운 능력 수준에 도달했음
  이제 내가 아는 사람들은 모두 에이전트식 코딩을 하고 있고, 정말 놀라움. 가능한 한 끝까지 밀어붙여봐야 한다고 생각함. 인류의 가속이 눈앞에 온 느낌임

  • 이미 몇 가지 물류적 한계에 부딪히고 있음. Transformer에 본질적 능력 고원이 없다 해도, 개선에 쓸 GPU와 전력은 한정돼 있고 그 인프라를 확장하는 데 큰 어려움을 겪고 있음
    지난 2년 동안 약 6GW 규모의 새 데이터센터가 발표됐지만, 실제로 켜져서 서비스를 시작한 건 1GW 미만임. 나머지의 납기 일정은 계속 밀리고 있음
    게다가 데이터센터들은 그 안의 칩이 6년은 버틸 것처럼 말하지만, 그것도 무리라는 점이 드러나고 있음
  • 우리가 벽을 향해 가속하고 있다면?
  • “인류의 가속”은 올해 본 가장 큰 자기위안임
  • 맞음, 뭔가 일어났음. 자동완성을 더 잘하게 됐음. 그 외에 무엇이겠음? 기반 모델은 바뀌지 않았음
    “인류의 가속” 같은 소리는 그만했으면 함. LLM으로 암, 기후변화, 불평등, 그 밖의 중요한 현실 문제를 해결하는 사람은 아무도 없음
    이 기술이 생산성을 높여줄 만큼 괜찮다면, 그건 새롭거나 최첨단이거나 혁신적인 일을 하고 있지 않기 때문임. LLM이 네 일을 할 줄 아는 유일한 이유는 그 코드가 학습 데이터에 충분히 많이 등장할 만큼 이미 문자 그대로 쓰였기 때문임
    LLM으로 C++26, HDL, 또는 아주 틈새 스택을 작성해보면 현실 점검이 될 것임

• AFL이 LLM보다 더 많은 취약점을 찾은 게 아님. AFL과 숙련된 실무자들이 취약점을 찾은 것임
  AFL은 결함을 유발하고, 그중 상당수 또는 대부분은 악용 가능하지 않음. 인간이, 이제는 에이전트가, 이를 선별하고 평가해야 함
  게다가 그 일은 AFL 이전의 메모리 안전하지 않은 소프트웨어 말뭉치에서 이뤄졌음. AFL의 전성기는 10년 전이었고, 지금은 모든 대상이 더 어려워졌음

• 맥락을 더하면, 글쓴이는 George “geohot” Hotz임. 긴 익스플로잇 이력이 있고, 가장 잘 알려진 것은 아마 실제 AI 바이브 코딩이 나오기 훨씬 전, 적은 예산으로 자율주행차용 comma.ai를 거의 바이브 코딩하듯 만든 일일 것임
  https://en.wikipedia.org/wiki/George_Hotz