나비에-스토크스 성과 이후에도 여전히 LLM을 비관적으로 보는 이유

• 현재의 프런티어 LLM은 지식 노동자를 완전히 대체할 만큼 자율적이지 않음

  • 프런티어 연구소의 기업가치는 완전 자동화 기술을 만들 것이라는 기대에 크게 의존하지만, 현행 모델은 단순한 작업에도 세심한 감독과 안전장치가 필요함

  • 나비에-스토크스, FreeBSD RCE, Hugging Face 사건 같은 성과만 보면 상당한 자율성을 확보한 듯함

    • 하지만 소프트웨어 기업들은 벤치마크 점수가 모델보다 낮은 엔지니어도 계속 고용해 모델을 감독하게 함

• 모델은 훈련받은 작업과 비슷한 범위에서만 잘 작동함

  • 프런티어 연구소는 결과를 명확히 평가할 수 있는 작업을 모델에 가르치는 방법을 상당 부분 확립함

  • 훈련 데이터에도 다양한 작업이 포함돼 있음

  • 하지만 작업 조건을 조금만 바꿔도 완전히 실패할 수 있음

  • 실제 목표를 달성하는 대신 평가 기준의 허점을 이용하는 reward hacking도 발생함

• Reward hacking을 막으려면 전문가가 작업 기준을 매우 구체적으로 정해야 함

  • 도메인 전문가의 시간은 비쌈

  • 작업 기준을 빈틈없이 만드는 일에는 해당 분야 지식과 별도의 능력이 필요함

  • 숙련된 소프트웨어 엔지니어도 이런 작업에 서툰 경우가 많음

  • 따라서 분야 지식과 작업 기준 설계 능력을 모두 갖춘 사람은 드묾

• 작업 기준을 빈틈없이 만드는 비용이 사람이 직접 구현하는 비용보다 더 클 수 있음

  • 하드웨어 엔지니어링에서는 일반적인 CPU 프로젝트에 설계 엔지니어보다 기준 작성·검증 인력이 약 3배 많다는 이야기가 있음

  • 작업 기준을 한 번 정해 계속 사용하는 방식이 맞지 않는 일도 많음

    • 실제 구현 과정에서 새로 알게 된 내용을 반영해 기준을 계속 바꿔야 하기 때문임

  • CPU 아키텍처 제품군의 실행 가능한 ISA처럼 상위 수준의 기준을 만들 수 있는 경우도 있음

  • 하지만 현 기술로는 그 기준대로 결과가 맞는지 확인하는 비용이 너무 큼

    • 결국 더 작성하기 어렵고 설계 변경에도 취약한 세부 기준을 따로 만들어야 함

• 나비에-스토크스 같은 순수수학 문제는 이런 방식이 가장 잘 통하는 사례임

  • 풀어야 할 정리 자체가 이미 정확하게 정의돼 있음

  • 수학계가 수십 년간 검토해 왔다는 장점도 있음

  • Lean 표현도 mathlib에서 검증된 수학적 대상을 이용해 비교적 직접적으로 옮길 수 있음

  • 검증에 쓰는 Lean 정리 증명기도 오랫동안 폭넓게 검토돼 왔음

  • 잘못된 증명을 통과시키는 허점을 줄이도록 설계돼 있기도 함

  • 그래도 Lean이 완전히 안전한 것은 아님

    • 과거 건전성 버그로 LLM이 가짜 증명을 검증 단계에서 통과시킨 적이 있음

    • 비슷한 버그가 더 있을 가능성도 있음

  • 이런 조건은 대부분의 지식 노동에는 존재하지 않음

  • 일부 영역만 순수수학과 비슷한 특성을 가짐

• 정확한 작업 기준이 없다면 결국 사람이 검토해야 하지만, 모델의 출력량을 감당하기 어려움

  • 전문가 검토도 reward hacking을 완전히 막지 못함

  • xz 백도어와 Linux에 반영된 UMN 커밋이 이를 보여줌

  • 사람이 에이전트 작업을 계속 감독해야 한다면 생산 속도도 인간의 시간과 집중력에 묶임

  • 따라서 연구소 CEO들이 몇 달 뒤면 가능하다고 거듭 암시하는 ‘데이터센터 속 천재 국가’ 구상은 성립하기 어려움

• 대부분 분야에서 LLM은 유능한 사람이 다룰 때 빠르고 효과적이지만, 모든 권한을 맡기기에는 불안정한 ‘비범한 인턴’에 가까움

  • 기업이 완전 자율 AI를 도입하지 못하는 이유를 기술 부족이나 확산 지연만으로 설명하기 어려움

  • 현재 방식 자체에 구조적인 한계가 있음

• 완전 자율 LLM을 활용하기 쉬운 기업은 크게 세 부류임

  • 실패해도 큰 문제가 없는 기업

    • 인턴이 맡을 법한 업무나 빠른 프로토타이핑 등이 포함됨

  • 이미 명확한 안전장치가 있는 좁은 업무만 필요한 기업

    • 통제된 환경의 반복 작업, 콜센터, 고객 서비스 채팅 등이 사례임

  • 상세한 작업 기준과 검증에 많은 비용을 쓸 수 있는 기업

    • 반도체 설계와 신약 개발처럼 원래부터 검증 비용이 큰 분야가 포함됨

• 첫째와 둘째 부류는 가격에 민감해 저렴한 오픈 모델이 더 적합할 수 있음

  • 이들 대부분은 프런티어 모델의 추가 추론 성능이 꼭 필요하지 않음

  • 저렴한 하드웨어에서 오픈 모델을 실행하는 편이 유리할 수 있음

  • 필요하면 회사 내부나 작업 현장에서 직접 구동할 수도 있음

• 수학·보안 연구의 화제성 성과는 개별 모델의 추론 능력보다 동시에 얼마나 많은 에이전트를 돌리느냐가 더 중요할 수 있음

  • 소형 오픈 모델들이 2026년 봄의 과열을 이끈 Mythos CVE를 재현한 사례가 이를 뒷받침함

  • 이 가설이 맞다면 저렴한 오픈 모델의 장점이 커짐

  • 같은 비용으로 더 많은 에이전트를 동시에 돌릴 수 있기 때문임

• 높은 검증 비용을 감수하는 기업도 프런티어 모델을 반드시 써야 하는지는 불분명함

  • DeepSeek 같은 저가 모델로도 충분할 가능성이 있음

  • 동시에 돌리는 에이전트 수가 중요하다면 모델 가격이 낮을수록 유리함

  • 이런 기업은 지식재산을 엄격히 보호하는 경우도 많음

  • 사용자 데이터로 훈련하지 않겠다는 약속이 있어도 모든 자료를 Anthropic이나 OpenAI에 보내는 일을 꺼릴 수 있음

• 저렴한 모델을 대규모로 사용하더라도 초지능과 같은 규모의 AI 연산 수요가 생긴다고 보기는 어려움

  • ‘데이터센터 속 천재들’은 스스로 일하므로 쓸 수 있는 연산량만 한계가 됨

  • 반면 성능이 떨어지는 모델은 사람이 계속 방향을 잡아줘야 함

  • 결국 인간의 시간과 집중력이 큰 병목이 됨

  • 개인적으로는 이 구조적 한계의 영향이 프런티어 연구소를 넘어 훨씬 넓게 퍼질 것으로 봄

^{source https://dank.systems/posts/2026-09-15-ai-bear.html}

HN에서는 LLM의 인상적인 성과를 곧바로 지식 노동의 자율화로 볼 수 있느냐를 두고 판단이 갈렸다. 현재 모델이 유용하다는 점은 대체로 인정했다. 다만 명확한 지시와 감독 아래 작동하는 도구와 장기 과업을 스스로 완수하는 대체 인력은 다르다는 지적이 많았다. 실제 시스템에서는 사람이 무심코 맡아 온 확인과 조정 역할을 예외가 생길 때마다 규칙으로 명시해야 하기 때문이다.

체스 사례는 일반화 능력을 어떻게 평가할지를 둘러싼 논쟁으로 이어졌다. 규칙을 충분히 접한 모델이 불법 수를 반복한다면 낯선 과제에 지식을 적용하는 능력이 부족하다는 주장과, 시험 모델이 최신형이 아니며 체스 엔진을 호출하면 된다는 반론이 맞섰다. 외부 도구를 능숙하게 쓰는 능력도 지능의 일부라는 시각이 있는 반면, 별도 훈련이나 전용 도구 없이 설명을 읽고 과제를 수행할 수 있어야 범용성이라 부를 수 있다는 기준도 제시됐다. 일부 성능표의 모델 간 상대 등급을 인간 등급과 혼동한 사례는 지표 해석의 중요성도 드러냈다.

명세와 검증에 드는 비용도 중요한 쟁점이었다. 사용자는 빠진 조건을 계속 보완해야 하고, 모델이 대량으로 만든 결과를 사람이 모두 검토하기도 어렵다고 설명했다. 반도체 산업의 높은 검증 인력 비율을 다른 분야에 그대로 적용하기 어렵다는 반박도 나왔다. 오류 한 번의 비용이 산업마다 크게 다르기 때문이다. 고객 지원 역시 통제된 반복 업무라기보다 기존 절차가 실패했을 때 예외를 처리하는 일에 가깝다는 지적이 있었다.