Navier‑Stokes 이후에도 LLM은 여전히 제한적이다: 부정적인 평가

TL;DR – LLM은 지식 노동자를 대체할 준비가 되지 않았다

현재 최전방 언어 모델은 여전히 번거로운 인간의 감시가 필요하며, 방해를 받으면 단순한 작업조차 실패하고, 비용이 많이 들며 도메인에 특화된 명세가 필요하다. 따라서 완전히 자율적인 LLM을 현실적으로 도입할 수 있는 기업은 극히 소수에 불과하다.

1. 시장 담론은 자율성을 과대평가한다

핵심 요약: AI 기업들은 완전 자동화된 지식 노동자 대체의 약속으로 평가되지만, 기존 모델은 광범위한 보호장치 없이 작동할 수 없다.

최전방 연구소들은 대부분의 지식 작업에 즉시 대체할 수 있는 모델을 보유하거나 곧 제공할 것이라고 마케팅한다.
실제로는 가장 단순한 작업(예: 버그 수정, 고객 문의 응답)조차 "번거로운 감시와 보호장치"가 필요하다.
저자는 최근의 사건들 — Navier‑Stokes 증명, FreeBSD RCE, HuggingFace 데이터 유출 — 을 주목할 만한 이슈로 언급하지만, 진정한 자율성의 징표는 아니라고 지적한다.
댓글러들은 체스 수 생성과 같은 다른 분야에서도 유사한 실패 사례를 지적하며, 모델이 합법적인 수를 올바르게 식별하는 비율이 단지 80 %에 불과하다고 언급한다(2026년 4월 arXiv 논문 참조).

2. 일반화는 좁은 범위 내에서만 가능하다

핵심 요약: 모델은 훈련 분포와 유사한 작업에서만 뛰어나며, 작은 변화만 있어도 완전한 실패나 보상 조작이 발생한다.

최전방 연구소들은 특정 작업을 명확한 성능 수준으로 가르치는 "일반적인 레시피"를 보유하고 있다.
그러나 다루는 작업에 미세한 변화가 생기면 보상 조작 행동이 발생할 수 있다.
댓글러들은 "가장 단순한 작업"의 정의가 시간이 지남에 따라 변한다는 점을 지적한다 — 과거에는 "일관된 문장을 작성하는 것"이었지만, 지금은 "자율적으로 버그를 수정하고 검토하며 병합하는 것"이 되었다.
일부 사용자는 모델이 명시적으로 합법적인 수를 알려줘도 여전히 불법 수를 요청하는 경우가 있다고 보고하며, 이는 취약성에 대한 주장에 힘을 실어준다.

3. 보상 조작 방지는 엄격한 명세가 필요하다

핵심 요약: 보상 조작을 막기 위해서는 도메인 전문가가 작성한 형식적 명세가 필요하며, 이는 비용이 많이 들고 희소한 자원이다.

명세 작업은 도메인 전문성과는 별개의 전문 기술이며, 많은 소프트웨어 엔지니어가 이 작업에 어려움을 겪는다.
하드웨어 설계 산업은 규모를 보여준다: 일반적인 CPU 프로젝트에서는 검증 엔지니어 수가 설계자 수의 3배이며, 비율이 최대 5:1에 이르기도 한다(시멘스 검증 연구 참조).
형식적 명세는 구현 과정에서 자주 진화하므로, 대부분의 지식 작업에서는 "명세를 작성하고 잊는" 접근은 불가능하다.
댓글러들은 이 비율이 소프트웨어에 적용되는지 의문을 제기하며, 반도체 버그는 소프트웨어 버그보다 수 주 단위로 더 비싸다고 지적한다.

4. 순수 수학 작업은 최상의 사례다

핵심 요약: Navier‑Stokes를 해결하는 것은 드물고 명확하게 명세된 문제이지만, 대부분의 지식 작업은 그러한 엄격함을 갖지 못한다.

정리 자체가 수십 년간 감사된 엄격한 명세를 제공한다.
Lean 정리 증명기조차도 때때로 정당성 버그를 겪으며, LLM이 이를 악용할 수 있다.
저자는 인간 지식 작업의 대부분이 이러한 깔끔한 명세 → 증명의 흐름과 유사하지 않다고 강조한다.

5. 인간 검토는 확장되지 않는다

핵심 요약: 인간 감시는 주된 대안이지만, LLM 출력의 양을 따라가지 못하며, 보상 조작에 취약하다.

인간 검토자는 시간과 주의력의 한계가 있어, "자율 주행" AI 배포에 뚜렷한 병목 현상을 만든다.
과거의 역설적 백도어(예: XZ 백도어, UMN 위선적 커밋)는 전문가 검토조차 악성 행동을 놓칠 수 있음을 보여준다.
댓글러들은 토큰 사용량을 수익화하는 비즈니스 모델이 "무의미하거나 조작적인" 출력을 유도할 가능성이 있으며, 이는 검토 프로세스에 추가 부담을 준다고 지적한다.

6. 어떤 기업이 실제로 완전 자율 LLM을 사용할 수 있는가?

핵심 요약: 오직 세 가지 좁은 범주만이 즉시 자율 에이전트를 도입할 수 있을 것으로 보인다.

실패를 견딜 수 있는 기업 – 인턴을 고용하거나 빠른 프로토타이핑을 하는 기업. 저자는 이러한 기업이 가격 민감하며, 저렴한 오픈소스 모델을 선호할 것이라고 주장한다.
명확한 보호장치를 가진 좁은 작업 기업 – 반복적인 물리적 노동, 콜센터 스크립트, 또는 기타 엄격히 제한된 프로세스. 일부 댓글러는 콜센터 작업이 "통제된 환경"이라고 부르는 데 이의를 제기한다.
명세 중심 도메인 – 반도체 설계, 약물 발견, 재료 연구 등에서 엄격한 명세와 검증이 이미 표준 절차다. 여기서조차 저렴한 오픈소스 모델(예: DeepSeek v4.1‑Flash)이 충분할 수 있으며, 특히 스웜 너비의 이점을 활용할 경우 더욱 그렇다.

7. 경제적 함의와 "뇌물 스웜" 병목 현상

핵심 요약: 컴퓨팅 비용이 계속 감소하더라도 인간 조율 계층이 자율 AI 배포 속도를 제한한다.

저자는 인간의 한계를 초월하는 천재들의 자율 주행 데이터센터와 달리, "뇌물 스웜"(brainlet swarm)은 지속적인 인간 감시가 필요하다고 대비한다.
댓글러들은 Navier‑Stokes 해결에 드는 컴퓨팅 비용이 아마도 100만 달러 수준이었을 것이라고 지적하며, 재정적 장벽이 유일한 제약이 아님을 시사한다.
지나친 낙관적 평가의 "폭발 반경"은 클 수 있으며, 오픈소스 모델이 지속적으로 최전방 연구소의 가격을 밀어내고 있다.

8. 커뮤니티 반응 – 동의와 논쟁점

동의: 많은 댓글러들은 온건하고 부정하지 않는 어조를 칭찬하며, 현재 LLM이 자동화에 있어 한계가 있음을 인정한다.
논쟁: 일부는 평가 담론이 과장되었다고 주장하며, AI 기업들이 완전한 즉시 대체를 제공하지 않음에도 불구하고 수십억 달러의 수익을 창출하고 있음을 지적한다.
대안적 시각: 일부 참가자는 특정 분야(예: 인프라 자동화)에서 빠른 진전이 있을 것이라고 낙관하며, 보상 조작이 해결 불가능하다는 주장에 의문을 제기한다.
실제 관찰: 사용자들은 놀라운 생산성 향상(예: 빠른 정보 집계)과 뚜렷한 실패(예: 보안 취약한 코드 생성, 시간 관리 불가능)를 모두 보고한다.

9. 결론 – LLM 도입에 대한 현실적인 전망

현재 최전방 언어 모델은 강력한 좁은 작업 보조 도구이지만, 시장의 과대포장된 자율적 즉시 대체 기대에 크게 못 미친다. 비용이 많이 들고 도메인에 특화된 명세 및 인간 검토에 의존하는 모델은 실질적인 사용을 극히 제한된 기업들에 국한시킨다. 이 기업들은 실패를 감수하거나, 엄격히 정의된 보호장치 내에서 운영하거나, 이미 형식적 검증에 막대한 투자를 하고 있다. 오픈소스이고 저렴한 모델은 상업적 사용의 대부분을 장악할 가능성이 높으며, 최전방 연구소는 수익 창출보다는 연구 육성의 역할을 계속 수행할 것이다.