LLM 비판론자들이 옳다. 그래도 나는 LLM을 쓴다

• 저작권·환경·윤리 문제와 저품질 산출물, 오픈소스 신뢰 붕괴, 주니어 육성 약화, 지정학적 종속을 인정하면서도 LLM을 사고의 품질을 높이는 도구로 계속 활용함
• LLM은 기존의 생각·의견·구조를 증폭하므로, 사람의 판단이 없으면 유창한 쓰레기를 대량 생산하지만 충분한 생각과 책임이 있으면 더 적고 더 나은 결과물을 만드는 데 도움을 줌
• 외부에서는 사람이 실제로 고민했는지 확인하기 어려워 결과물의 가치는 결국 신뢰와 평판에 좌우되며, 공개적으로 한 글자도 부끄럽지 않게 읽을 수 있는지가 AI slop을 가르는 기준이 됨
• /grill-me, Basecamp의 Pitch, 비판 전담 하위 에이전트, Ralph Wiggum loop, 예상 API·UX를 먼저 환각하게 하는 방법으로 LLM의 동조성과 환각을 역이용함
• 좋은 결과와 나쁜 결과를 구분할 사용자의 전문성이 필수이며, 정답을 검증하기 어려운 영역에서 전문가와 인간의 판단 없이 LLM을 쓰면 대규모 slop 생산으로 이어짐

비판과 사용이 공존하는 현장

• Berlin의 Local-First Conf에서는 LLM을 비판하는 발표에 큰 박수가 나오는 동시에 청중 다수가 Claude Code를 열어두고 있었음
• Flask를 만들고 Sentry 초기 팀에 참여했던 Armin Ronacher는 Earendil을 설립해 오픈소스 코딩 에이전트 하네스인 Pi.dev를 개발함
  • 머신 엔티티 구축 발표 후 Pi.dev의 LLM 생성 PR 범람에 관한 질문을 받자, 거의 모든 PR과 이슈를 자동으로 닫는다고 답함
  • 다만 PR을 여는 일을 포기해서는 안 되며, 결국 사람의 개성이 드러난다고 덧붙임
  • Earendil의 목적 페이지는 AI로 돌진하는 세계에서도 인간이 최고의 에이전트라고 밝힘
• 컨퍼런스 참가자들과의 대화에서도 LLM을 비판하면서 사용하는 불일치가 반복됐으며, 이는 개인만의 경험이 아니었음

LLM 비판이 타당한 이유

• LLM에는 저작권 자료, 환경 부담, 윤리 문제가 얽혀 있음
• NVIDIA와 OpenAI를 중심으로 돈이 순환하는 구조는 지속되기 어렵고, 현재의 거품은 결국 터질 것으로 봄
• 가장 흔한 비판인 “LLM이 많은 slop을 만든다”는 현실과 일치함

• 오픈소스의 신뢰 붕괴

  • 오픈소스 저장소들은 모든 기여를 거부하거나 LLM 생성물을 걸러내는 장치를 도입하기 시작함
  • LLM 이전에는 제대로 작성된 PR과 설명 자체가 최소 몇 시간의 인간 노력을 뜻했으며, 관리자는 신규 기여에도 일정 수준의 시간과 관심이 투입됐다고 보고 검토할 수 있었음
  • 트롤이나 저품질 제출물도 몇 초 안에 비교적 쉽게 식별할 수 있었음
  • 이제는 누구나 새 GitHub 계정을 만들고 LLM을 작동시킬 수 있어, 많은 시간을 들인 PR인지 OpenClaw 머신이 자율 생성한 제출물인지 구분하기 어려움
  • Zig와 Gentoo는 LLM 생성 PR을 거부하고 있지만, 실제 생성 여부를 판별하기 어렵다는 한계가 있음
  • 신뢰를 복원하지 못하면 LLM이 오픈소스를 심각하게 훼손할 가능성이 있음
  • 가능한 대응책으로 소수의 검증된 사람만 기여하도록 하고, 실제 모임 참석 등을 검증 요건으로 두는 방식이 있음

• 주니어 엔지니어 육성 약화

  • 주니어가 코드에 투입한 노력을 신뢰하기 어려워짐
  • 시니어는 나쁜 코드가 10분 만에 바이브 코딩된 결과인지, 몇 시간 동안 고민했지만 통찰이 부족한 결과인지 알 수 없음
  • LLM 이전에도 주니어는 좋지 않은 코드를 작성했고 시니어가 이를 검토하고 수정했지만, 이제는 노력과 학습 과정이 보이지 않음
  • 이 불확실성은 시니어가 주니어를 가르칠 동기를 줄임
  • 과거에는 주니어가 단순 업무를 맡고 시니어가 함께 검토하면서 성장시키는 균형이 있었음
  • 단순 업무를 LLM에 완전히 맡길 수 있다면 기업이 주니어를 채용할 이유도 약해짐

• 지정학적 종속과 의견의 동조

  • 미국이나 중국이 특정 지역을 관련 기술에서 갑자기 차단할 가능성을 무시할 수 없음
  • 미국 정부는 2026년 6월 수출 통제 명령을 통해 미국 외 고객이 Anthropic의 최신 모델에 접근하지 못하도록 할 의사와 능력이 있음을 보였음
  • Anthropic은 2026년 6월 12일 지침에 따라 모든 고객에게 Fable 5와 Mythos 5를 갑자기 비활성화했다고 밝힘
  • Martin Kleppmann은 불안정한 세계의 local-first 발표에서 유럽과 미국의 충돌 가능성은 여전히 매우 낮지만, 전년에는 0이었다고 말함
  • LLM을 조사 도구로만 사용해도 훈련 자료의 다수 의견이나 모델 제작자의 정치적 신념이 결과에 조용히 스며들 수 있음
  • 인간들이 대화하면서 특정 단어나 의견을 공유하게 되는 현상과 비슷하지만, 대화 상대 중 하나가 인간이 아니라는 차이가 있음

로컬 모델과 오픈 웨이트의 역할

• LLM을 완전히 없애기는 어려우므로 흐름을 거부하기보다 직접 통제하고 형성하는 접근이 필요함
• 노트북에서 실행되는 모델은 프로그래머를 대형 기업에 대한 의존에서 벗어나게 함
  • 로컬 모델은 계속 개선되고 있음
  • 보조금이 끝나고 가격이 오르면 오픈 웨이트 모델이 대형 공급자의 가격과 영향력을 견제할 수 있음
  • 자체 하드웨어에서 실행되는 모델은 정부가 하룻밤 사이 접근을 차단할 수 없음
• AI 거품 붕괴가 세계 경제와 기업들에 큰 손상을 주더라도 오픈 웨이트 모델은 남아 프로그래머가 대안으로 사용할 수 있음
• Local-First Conf의 AI 관련 발표들도 로컬 모델을 진지하게 다뤘으며, 언제든 질문하면 답하는 SF 속 상시 AI와 같은 환경을 가능하게 함

인간의 생각을 증폭하는 도구

• 여러 발표자는 작업 일부를 Claude Code에 맡겼다고 공개적으로 밝혔지만 발표가 채택됐고, 시니어와 존경받는 참석자들을 포함한 청중의 박수를 받았음
• 차이는 결과물에 자신의 평판과 신뢰성을 거는 인간이 존재한다는 점임
  • AI slop을 발표하면 그 사람은 신뢰를 잃음
  • 책임을 지는 사람은 LLM에 생각 자체를 맡기기보다 자신의 생각을 더 빠르고 강하게 구현하는 데 사용함
• LLM은 이미 가진 의견·구조·프레임워크를 증폭함
  • 생각이 있으면 더 선명하고 빠르게 드러남
  • 생각이 없으면 내용은 비어 있지만 매우 유창한 결과가 나옴
• 브레인스토밍, 문법 검사, 문장 반복 개선, 대안 생성, 러버덕 디버깅, 악마의 변호인 역할에 유용함
• 많은 결과물을 만드는 대신 더 적은 결과물을 더 높은 품질로 만드는 방식을 택함
  • 사람이 읽을 몇 문장을 준비하기 위해 매우 많은 토큰을 사용함
  • LLM은 사고 과정을 지원할 수 있지만 생각 자체를 대체하지는 못함

AI slop을 가르는 신뢰의 기준

• 글은 인간이 인간에게 쓰는 것이어야 하지만, LLM을 활용해 모든 글을 작성하는 일과 모순되지는 않음
• AI slop과 좋은 글의 차이는 뒤에 인간의 생각이 존재하는지에 달려 있으며, 생각은 외주화할 수 없음
• 문제는 사람이 실제로 생각했는지를 외부에서 확인할 수 없다는 데 있음
  • “AI를 사용해 더 잘 생각한다”는 말은 신중한 사용자와 무책임한 AI 옹호자에게서 똑같이 나올 수 있음
  • 증폭된 허튼소리도 천재적인 결과처럼 들릴 수 있어 결국 남는 것은 신뢰뿐임
• 신뢰는 얻기 어렵고 잃기 쉬우며, LLM 시대에는 em dash 하나만으로도 전체 글이 AI slop처럼 보일 수 있음
• Local-First에 정치적 관심이 있는 사람 중 상당수가 강한 반(反)LLM 성향을 보여, LLM으로 만든 소프트웨어가 커뮤니티에서 거부될까 우려하는 분위기도 있었음
  • 컨퍼런스 안에서도 LLM 사용 사실을 공개적으로 말하기 두려워하는 사람이 있었음
• 2026년 6월 토큰 비용으로 약 1만 달러를 지출함
  • 이후 Fable은 너무 비싸 선택적으로만 사용함
  • 순수 코드 실행에는 OpenRouter와 GLM 5.2 같은 저렴한 모델을 활용함
• 결과물을 청중 앞에서 그대로 읽을 수 있는지가 slop을 판단하는 실용적 기준임
  • 의미를 별도로 해명해야 한다면 slop에 가까움
  • 한 글자도 부끄럽지 않게 그대로 읽을 수 있다면 좋은 글로 볼 수 있음

이해를 강제하는 /grill-me

• LLM은 실제 문제와 요구사항을 이해하지 못하면 나쁜 소프트웨어를 작성하며, 필요한 기술과 도구가 있으면 상당히 괜찮은 결과도 만들 수 있음
• 괜찮은 결과를 가로막는 핵심 장애물은 동조성임
  • LLM은 이해하지 못했다는 사실을 알리지 않고 곧바로 무언가를 수행하려 함
• Matt Pocock의 “grill me” 기법을 변형한 /grill-me는 실행 전에 공동 이해를 형성하도록 강제함
  • 모든 측면을 집요하게 질문하고 의사결정 트리의 각 분기를 순서대로 검토함
  • 각 질문에는 권장 답을 함께 제공함
  • 한 번에 하나씩 질문하고 사용자 답을 기다림
  • 파일 시스템이나 도구에서 확인할 수 있는 사실은 직접 조사함
  • 의사결정은 사람에게 하나씩 묻고, 공동 이해에 도달했다는 확인 전에는 실행하지 않음
• 질문을 하나씩 받는 과정에서 사용자는 자신의 생각을 직접 형성하게 됨
• 글쓰기에도 같은 방식을 적용해 먼저 생각을 혼란스럽게 적은 뒤, 문장마다 LLM의 비판을 받으며 다듬음
• 단일 문장을 위해 극단적으로 많은 토큰을 쓰는 단계별 접근이 결과의 품질을 높임

짧은 명세와 검토 가능한 범위

• 작은 코딩 작업에도 Basecamp의 Pitch를 따라 세 가지를 짧게 작성함

  • Problem

  • What we are shipping

    • What we are not shipping
    • 문제 정의는 세 문장으로 제한함
    • LLM으로 형식을 채우기는 쉽지만 좋은 세 문장을 만드는 일은 어려움
    • 인간을 위해 설계된 짧은 형식이므로 작성자가 실제로 읽을 수 있고 다른 사람도 검토할 수 있음
    • 대부분의 LLM 출력은 자세히 읽기보다 빠르게 훑지만, 세 문장의 문제 정의는 강하게 사실 확인함
    • 검토량이 지나치게 많으면 품질이 떨어짐
    • 코드 1,000줄짜리 리뷰에는 LGTM만 달리기 쉬움
    • 100줄짜리 리뷰에는 15개의 의견을 남길 수 있음
    • PR 설명에도 같은 수준의 주의를 적용함
    • 읽기 쉽고 간결하게 유지함
    • 실제 문제, 제공할 것, 제공하지 않을 것을 명확히 적음
    • 작동 화면을 첨부해 검토할 가치와 실제 동작 여부를 즉시 보여줌
    • Claude는 PR 설명에 불필요한 내용을 계속 추가하려 하므로 지속적으로 줄여야 하며, 중요하지 않은 PR에서는 이를 충분히 억제하지 못하기도 함

비판 에이전트와 환각의 역이용

• LLM이 대량으로 생성하는 내용에 대응하기 위해 코딩 워크플로에 비판 역할의 소형 에이전트를 배치함
• Ralph Wiggum loop 또는 Claude의 ultracode는 텍스트·계획·명세·코드를 고정한 뒤, 새로운 컨텍스트를 가진 하위 에이전트들을 반복 투입해 결함을 찾게 함
  • 하위 에이전트는 주어진 컨텍스트를 공격하는 일만 맡음
  • 더 이상 실제 문제를 찾지 못해 문제를 환각할 때까지 반복함
• 문제를 환각하는 단계에 도달하면 LLM의 약점을 검증 신호로 쓸 수 있음
  • LLM은 문제가 있다는 사용자 기대에 동조하려 하지만 더는 실제 문제를 발견하지 못함
  • /grill-me와 함께 사용하면 사람이 가진 사소한 의문까지 검토하고 자신의 생각을 형성하도록 압박할 수 있음
• 환각 자체를 디자인 검증에 활용할 수도 있음
  • Anselm Eickhoff는 실제 제품을 보여주기 전에 LLM이 기대하는 API나 UX를 환각하게 하는 방법을 소개함
  • LLM이 추측하는 형태는 다수의 인간이 예상할 형태와 비슷할 수 있어, 디자인이 사용자 기대와 일치하는지 확인하는 저렴한 테스트가 됨
  • 이를 자동화한 intuition-probe skill은 블라인드 에이전트가 실제 디자인을 보기 전에 예상안을 먼저 확정하도록 함

전문성과 검증 가능성의 한계

• 모든 활용 패턴에는 사용자가 결과의 품질을 판별할 수 있어야 한다는 전제가 있음
• LLM 사용 범위가 익숙하지 않은 분야로 넓어질수록 전문가의 도움이 필요함
  • 기본 원리와 좋은 결과의 기준을 이해할 때만 팀원에게 업무를 위임할 수 있듯 LLM도 동일함
• 잘 아는 분야에서는 좋은 결과와 형편없는 결과를 빠르게 구분할 수 있음
• 잘 모르는 분야에서는 학습 보조로만 사용해야 함
  • 품질을 판별하지 못한 상태에서 결과 생성까지 맡기면 대규모 slop 생산으로 이어짐

• 정답을 확인할 수 있는 분야

  • 결과의 성공과 실패가 명확한 분야에서는 LLM과 함께 학습할 수 있음
  • 검증 기준에는 코드가 컴파일되는지, 테스트 모음이 통과하는지, 프로토콜이 디코딩되는지 등이 포함됨
  • 컨퍼런스의 한 참가자는 Opus 4.6으로 바이너리와 프로토콜을 역공학함
  • 필요한 출발점은 역공학의 기본 지식이었음
  • 패치된 바이너리가 작동하거나 기기를 망가뜨리는 식으로 결과의 정오가 명확해, 작업하면서 자체 기법도 찾을 수 있었음

• 의견이 개입되는 분야

  • 프로그래밍처럼 의견이 많은 영역에서는 LLM이 해당 상황에 가장 적합한 방법보다 가장 대중적인 기법을 답할 수 있음
  • 한 팀에서는 특정 코드를 AI slop이라고 비판했지만, 논의를 이어가자 실제 쟁점은 TDD에 대한 반대였음
  • 팀에는 LLM 이전부터 TDD를 적극적으로 사용한 사람도 있었음
  • 문제는 AI 자체가 아니라 인간들이 가진 서로 다른 의견이었음
  • LLM은 사용자의 의견까지 증폭하므로, 초반에는 인간이 대략적인 방향과 좋은 출발점을 제공해야 함
  • 충분한 판단력을 갖춘 뒤에야 스스로 LLM 활용을 이어갈 수 있음

대체가 아닌 사고의 강화

• 비판과 활용 사이의 불일치는 혼자만 겪는 현상이 아니며, 컨퍼런스 Discord와 대면 대화, 최근 Hacker News 글에서도 비슷한 경험이 확인됨
• LLM으로 만든 결과를 신뢰하려면 실제 결과물과 지속적으로 상호작용해야 하지만, 그 자체에 많은 시간이 필요함
• 과장된 홍보와 별개로 LLM에는 인간의 사고를 풍부하게 만드는 유용한 도구로서의 가치가 있음
• LLM은 생각을 강화할 수 있지만 인간의 생각을 대신할 수는 없음