Navier-Stokes 이후에도 내가 여전히 LLM 약세론자인 이유

본문

이 글은 Navier-Stokes 문제 해결, FreeBSD RCE, Hugging Face 사건 등 최근 프런티어 모델의 화려한 성과에도 불구하고 LLM의 완전 자율화에 회의적인 입장을 정리한 에세이입니다. 저자는 프런티어 랩들이 '지식 노동자의 완전 자동화된 대체재'라는 서사로 가격이 매겨져 있지만, 현실에서는 가장 단순한 작업조차 고된 감독과 가드레일이 필요하다고 지적합니다. 결정적인 증거로, 소프트웨어 기업들이 여전히 최신 벤치마크에서 모델보다 훨씬 낮은 점수를 받을 하위 25% 엔지니어를 고용하고 채용하고 있다는 사실을 듭니다.

일반화의 한계와 리워드 해킹

저자에 따르면 모델은 훈련된 특정 작업의 좁은 근방에서만 잘 일반화되며, 그마저 심각한 주의사항이 따릅니다. 프런티어 랩은 성능 수준이 명확히 정의된 작업이라면 거의 무엇이든 가르칠 수 있는 일반적인 레시피를 갖고 있지만, 커버된 작업 클래스 내의 작은 변형만으로도 완전한 실패나 리워드 해킹(reward hacking)이 발생합니다. 이 문제를 해결하는 유일한 길은 도메인 전문가가 작성한 엄밀한 명세인데, 명세 작성 자체가 별도의 전문성을 요구하는 기술이라 도메인 전문가와 명세 전문가의 교집합은 대부분의 분야에서 극도로 작다는 것이 문제입니다.

하드웨어 엔지니어링의 사례

엄밀한 명세의 노동 비용이 비공식 명세의 직접 구현 비용을 크게 초과할 수 있다는 주장의 근거로 CPU 프로젝트를 듭니다. 일반적인 CPU 프로젝트에서는 명세·검증 엔지니어가 설계 엔지니어의 약 3배이며 5:1 비율도 드물지 않습니다. 더 나쁜 것은 많은 작업이 '한 번 명세를 쓰고 계속 구현'하는 방식을 허용하지 않는다는 점입니다. 형식 명세는 비공식 명세에 따른 구현 과정에서 발견되는 통찰과 대화하며 계속 진화하기 때문입니다. ISA 실행 명세처럼 높은 수준의 일회성 명세가 가능한 경우에도, 현재 기술로는 그 명세에 대한 검증 비용이 감당 불가능해 더 낮은 수준의 명세를 써야 하고 이는 구축 비용이 더 들고 설계 변경에 훨씬 취약합니다.

Navier-Stokes가 최선의 사례인 이유

Navier-Stokes 같은 순수 수학 명제는 엄밀한 명세에 대한 에이전트 작업의 절대적 최선 시나리오입니다. 정리 문장 자체가 이미 엄밀한 명세이고, 수십 년간 수학 커뮤니티의 감사를 거쳤으며, Lean으로의 변환은 mathlib의 검증된 수학 객체로 정의되는 간단한 번역입니다. 검증자인 Lean theorem prover도 리워드 해킹에 취약한 비건전성을 피하도록 특별히 설계되고 광범위하게 감사됐습니다. 그런데도 Lean조차 완벽하지 않아, 과거에 건전성 버그가 LLM의 허위 증명을 증명 커널을 통해 통과시킨 사례가 있었고 비슷한 버그가 더 존재할 가능성도 있습니다. 이것이 가장 장밋빛 조건이며, 인간 지식 노동의 대부분은 이렇게 생기지 않았다는 것이 저자의 요점입니다.

인간 리뷰의 확장성 문제

엄밀한 명세의 최선의 대안은 인간 리뷰지만, 이는 언어 모델이 생산하는 출력량에 잘 확장되지 않습니다. 설상가상으로 전문가 리뷰조차 리워드 해킹에 극도로 취약한데, xz 백도어와 Linux에 머지된 UMN의 악의적 'hypocrite commits' 사건이 증거입니다. 인간 리뷰가 에이전트 생산 루프의 핵심으로 남는 한 생산 속도는 인간의 시간과 주의력이라는 한계에 병목되며, 프런티어 랩 CEO들이 말하는 '데이터센터 속 천재들의 나라'는 구조적으로 성립 불가능하다고 봅니다.

완전 자율 LLM을 수용할 수 있는 세 부류

대부분의 도메인에서 LLM은 '천재적인 인턴(cracked intern)'처럼 보일 것이며, 성인의 손에 쥐여지면 빠르고 효과적이지만 조직을 통째로 맡길 수는 없다고 정리합니다. 완전 자율을 받아들일 수 있는 기업은 세 부류뿐입니다. 첫째, 실패를 싸게 수용할 수 있는 곳 — 인턴을 뽑을 기업, 빠른 프로토타이핑 조직. 둘째, 기존 가드레일이 명확한 좁게 정의된 작업 — 통제된 환경의 반복적 육체노동, 콜센터·고객 상담. 셋째, 이미 엄밀한 명세와 검증 비용을 본성적으로 감수하는 곳 — 칩 설계, 신약 개발처럼 배포 실패가 존망의 문제인 도메인.

경제적 함의

첫 번째와 두 번째 부류는 가격 민감적이며, 저가 모델에서 프런티어 모델로 갈 때의 추론 품질 향상이 필요하지 않을 수 있습니다. 수학과 보안 연구에서 헤드라인을 만든 퍼지 조합 탐색은 추론 능력보다 에이전트 스웜의 폭에 민감해 보인다는 것이 저자의 가설로, 2026년 봄 과열 사이클을 이끈 Mythos CVE를 소형 오픈 모델이 재현한 사례를 듭니다. 그렇다면 같은 작업을 더 넓은 스웜으로 돌릴 수 있는 저가 오픈 모델을 쓸 이유가 커집니다. 세 번째 부류는 프런티어 모델을 쓸 수 있지만, DeepSeek v4.1 Flash 같은 저가 모델로도 가능할 수 있고, IP에 극도로 보수적인 이들 기업이 Anthropic이나 OpenAI에 데이터를 보내는 것을 반기지 않을 것이라고 봅니다. '데이터센터 속 천재들' 시나리오와 달리 '브레인렛(brainlet) 스웜'은 인간 오케스트레이터에 심하게 병목되므로 자기주행적이지 않으며, 저자는 이 파급 범위가 프런티어 랩을 훨씬 넘어설 것이라고 베팅한다고 마무리합니다.

Hacker News 반응

• @jaykru — 저자가 직접 아카이브 링크(archive.ph)를 공유하며 트래픽 폭주에 대비했습니다.
• @robinpie — 현재 능력을 문자 그대로 부정하지 않는 절제된 견해를 보여줘서 고맙다고 평가했습니다.
• @jaykru — 저자는 매일 이 도구들을 즐기며 쓰고 있고 현재 능력도 놀랍지만, 프런티어의 가격이 터무니없이 비싸다고 답했습니다.
• @dumberquestions — 현재의 한계는 인정하지만 향후 몇 년간 능력이 어떻게 변할지 물으며, 지난 2년의 진전이 반복된다면 조금 더 걸리더라도 상당할 것이라고 질문했습니다.
• @brindleth — '가장 단순한 작업조차 고된 감독이 필요하다'는 원문 문장을 인용하며, 이것이야말로 현재 능력에 대한 부정론이라고 반박했습니다.

원문: dank.systems (via Hacker News) / 번역·요약: Trawling