오픈 웨이트(Open Weights)는 이제 정책적 싸움이 되었다

실리콘밸리는 지난 몇 주 동안 AI 선언문(manifestos)을 발표하며 시간을 보냈습니다. 이는 매우 온라인스러운(very online) 문장처럼 들릴 수 있지만, 그 이면에 깔린 싸움은 실재합니다.

Nvidia와 주요 기술 기업 그룹은 오픈 웨이트(open-weight) 모델이 미국의 AI 리더십의 일부라고 주장했습니다. Anthropic은 오픈 모델이든 폐쇄형(closed) 모델이든 충분한 능력을 갖춘 모델에 대한 의무적인 안전 테스트와 더불어, 칩 및 대규모 증류(distillation)에 대한 더 엄격한 통제를 주장했습니다. Google DeepMind의 Demis Hassabis는 연방 정부가 감독하는 프런티어 AI 표준 기구(frontier AI standards body)를 제안했습니다. 천 명 이상의 프런티어 연구소(frontier-lab) 직원들은 만약 경쟁이 감독 범위를 벗어나기 시작할 경우, 프런티어 전반의 발전을 의도적으로 늦출 수 있는 도구를 구축해 달라고 미국 정부에 요청하는 청원에 서명했습니다. Meta는 고급 AI에 대한 광범위한 개인적 접근을 소수의 기업이나 정부에 의한 통제에 맞서는 안전장치로 규정했습니다.

이것은 일반적인 표준 논쟁이 아닙니다. 이는 누가 강력한 모델을 실행할 것인지, 누가 모델을 검사할 것인지, 그리고 누가 브레이크를 밟을 것인지에 대한 싸움의 시작입니다.

이 논쟁의 게으른 버전은 오픈(open) 대 폐쇄(closed)입니다. 오픈 모델은 자유이고, 폐쇄형 모델은 안전이라는 식입니다. 깃발을 하나 정하고 소리를 지르기 시작하면 됩니다.

진짜 버전은 더 복잡합니다. 오픈 웨이트(open weights)는 한 세트의 문제를 해결하는 동시에 또 다른 문제를 만들어냅니다. 폐쇄형 프런티어 시스템(closed frontier systems) 역시 한 세트의 문제를 해결하는 동시에 또 다른 문제를 만들어냅니다. 어느 한쪽이 깨끗하다고 가정하는 모든 정책은 이미 망가진 것입니다.

오픈 웨이트(Open weights)는 단순한 이데올로기가 아니다

오픈 웨이트(open weights)를 지지하는 가장 강력한 근거는 낭만적인 것이 아니라 실용적인 것입니다.

대부분의 조직은 모든 작업에 가장 큰 모델을 필요로 하지 않습니다. 그들은 모든 요청을 프런티어 API(frontier API)를 통해 보내지 않고도 저렴하게 실행하고, 로컬에서 튜닝(tune)하며, 검사하고, 벤치마크(benchmark)하고, 배포할 수 있는 모델을 필요로 합니다. 오픈 웨이트(open weights)는 스타트업, 연구자, 대학, 공공 기관, 그리고 실제적인 개인정보 보호 제약이 있는 평범한 기업들에게 이를 가능하게 해줍니다.

그것은 중요한 문제입니다. AI는 사람들이 자신들만의 특이한 엣지 케이스(edge cases)에 맞춰 적응할 수 있을 때 비로소 인프라가 됩니다. API 전용(API-only) 세상은 비용, 지연 시간(latency), 컴플라이언스(compliance), 또는 벤더 종속성(vendor dependency)이 실제적인 문제가 되기 전까지는 편리할 뿐입니다.

오픈 웨이트(Open weights)는 또한 안전성(safety) 작업을 덜 중앙집중화된 방식으로 만듭니다. 더 많은 사람이 동작을 테스트하고, 실패를 발견하며, 완화책(mitigations)을 구축하고, 결과를 비교할 수 있습니다. 은닉을 통한 보안(Security by obscurity)은 소프트웨어를 위한 훌륭한 운영 모델이 아니며, 모델에 있어서도 명백히 더 나은 방식이라고 할 수 없습니다.

그것이 바로 Nvidia가 국가 경쟁력이라는 언어로 포장하여 주장하고 있는 사례입니다. 미국은 단 하나의 인상적인 모델을 게이트(gate) 뒤에 두는 것으로 승리하지 않습니다. 기술이 경제 전반에 확산되어, 개발자들이 영원히 세 개의 기업으로부터 지능을 임대하는 데 갇히지 않을 만큼 충분한 경쟁이 이루어질 때 승리합니다.

저는 그 말에 상당 부분 동의합니다.

하지만 그것이 이야기의 전부는 아닙니다.

웨이트 파일은 회수할 수 없다

오픈 웨이트의 어려운 점은 출시가 대부분 되돌릴 수 없다는 것입니다.

폐쇄형 모델(closed model)이 위험한 동작을 보일 경우, 제공자는 호스팅된 시스템을 변경하거나, 모니터링을 추가하거나, 액세스를 제한하거나, 특정 기능을 차단할 수 있습니다. 이러한 통제 수단은 불완전하고 종종 과장되기도 하지만, 분명히 존재합니다.

반면 오픈 웨이트의 경우, 파일이 이동합니다. 사람들은 이를 다운로드하고, 미러링(mirror)하고, 미세 조정(fine-tune)하고, 양자화(quantize)하며, 안전 장치를 제거하고, 원래 연구소가 볼 수 없는 곳에서 실행합니다. 이것은 오픈 웨이트의 버그가 아닙니다. 그것이 바로 목적입니다.

작은 코딩 모델이라면 괜찮습니다. 하지만 심각한 사이버, 바이오, 자율성 또는 설득 능력을 갖춘 모델의 경우, 동일한 특성이 거버넌스(governance) 문제가 됩니다. 질문은 이제 개방성이 좋은가 아닌가가 아닙니다. 질문은 폭발 반경(blast radius)이 관리 가능한 범위를 벗어나기 전까지, 얼마나 많은 능력을 자유롭게 복제 가능하게 만들 수 있는가 하는 것입니다.

Anthropic의 입장은 폐쇄형 연구소 (closed-lab) 논쟁의 가장 어리석은 버전을 피하고 있다는 점에서 흥미롭습니다. 이들은 오픈 웨이트 (open weights)에 대한 전면적인 금지를 요구하지 않습니다. 대신 충분한 능력을 갖춘 모델은 출시 전에 심각한 위험에 대해 테스트를 거쳐야 하며, 정책은 작은 규모의 오픈 웨이트 작업을 처벌하기보다는 칩 (chips), 산업 규모의 증류 (industrial-scale distillation), 그리고 고위험 능력 (high-risk capabilities)에 집중해야 한다고 말합니다.

이는 실행 가능한 선에 더 가깝습니다.

물론 이 선에도 여전히 문제는 있습니다. 능력 임계값 (capability thresholds)을 정의하기는 어렵습니다. 평가 (evaluations)는 조작될 수 있습니다. 테스트는 구식이 됩니다. 모델은 한 가지 스캐폴딩 (scaffold)에서는 무해하지만, 다른 스캐폴딩에서는 위험할 수 있습니다. 하지만 적어도 이 논쟁은 막연한 느낌 (vibes)이 아니라 측정된 위험 (measured risk)에 관한 것입니다.

브레이크는 불편한 부분이다

'Pacing the Frontier' 청원은 사람들이 과잉 반응하거나 혹은 무시하게 될 부분입니다.

이 청원의 핵심 주장은, 속도를 늦추는 것이 보안과 감독을 위한 시간을 벌어줄 수 있음에도 불구하고, 기업과 국가들이 혼자서 속도를 늦추지 못하도록 압박을 받고 있다는 것입니다. 따라서 정부는 자동화된 AI 개발의 속도를 의도적으로 조절하는 데 필요한 기술적 및 거버넌스 도구에 관한 국제적 협력을 지원해야 한다는 것입니다.

이 문장은 많은 개발자들을 타당한 이유로 불안하게 만듭니다. 브레이크는 해자 (moats)가 될 수 있습니다. 안전 프로세스는 기존 사업자 보호 수단이 될 수 있습니다. 표준화 기구는 대기업들이 자신들이 따를 여력이 있는 규칙을 조용히 작성하는 동안, 소규모 연구소들을 배제하는 위원회로 변질될 수 있습니다.

오픈 웨이트 측이 이를 걱정하는 것은 당연합니다. 오직 프런티어 연구소 (frontier labs)만이 헤쳐 나갈 수 있는 정책 체제는 위험을 줄인다고 주장하면서도 권력을 집중시킬 것입니다.

하지만 브레이크에 반대하는 측도 그들만의 환상을 가지고 있습니다. 그들은 접근성이 충분히 넓다면 생태계가 위험을 우회할 것이라고 가정합니다. 그것은 자연 법칙이 아닙니다. 어떤 실패는 개방성을 통해 발견하기가 더 쉬워지기도 합니다. 어떤 실패는 악용하기가 더 쉬워지기도 합니다.

불편한 진실은 우리가 아마도 두 가지 모두가 필요할 것이라는 점입니다.

우리는 역량 수준이 광범위한 검토와 배포를 통해 순이익(net-positive)을 창출할 수 있는 오픈 모델 (open models)이 필요합니다. 우리는 모델이 너무 강력하여 출시 결정이 참여를 선택하지 않은 사람들에게까지 영향을 미칠 수 있는 경우, 의무적인 테스트가 필요합니다. 우리는 프런티어 연구소 (frontier labs)뿐만 아니라 오픈 소스 대표자들을 포함하는 표준이 필요합니다. 우리는 소규모 연구소와 스타트업을 무거운 규제 준수 (compliance)로부터 면제해 줄 임계값 (thresholds)이 필요합니다. 우리는 신뢰할 수 있을 만큼 충분히 공개적이면서도, 오용을 위한 요리책 (cookbook)을 발행하지 않을 만큼 신중한 증거 요구 사항이 필요합니다.

그것은 단순히 오픈(open) 혹은 클로즈드(closed)를 외치는 것보다 더 어렵습니다. 미안하지만, 대부분의 실제 인프라 논쟁은 짜증스럽습니다.

개발자 버전의 싸움

개발자들에게 있어, 정책 싸움은 로컬 버전으로 존재합니다.

에이전트 (agents)를 도입하는 모든 팀은 더 작은 규모에서 동일한 트레이드오프 (tradeoff)를 수행하고 있습니다. 로컬에서 시스템이 수행하도록 허용하는 범위는 어느 정도인가? 얼마나 많은 것을 통제된 제공업체 (provider)를 통해 라우팅할 것인가? 에이전트가 쓰기 권한 (write access)을 얻기 전에 어떤 증거를 요구할 것인가? 어떤 로그를 남길 것인가? 어떤 작업이 되돌릴 수 있는가? 모델이 과거에는 안전하게 손이 닿지 않는다고 느꼈던 바로 그 작업에 대해 더 능숙해지면 어떤 일이 벌어지는가?

정답은 영원히 지속될 단 하나의 권한 모델이 아닙니다.

마크다운 (Markdown)을 정리하는 작은 로컬 모델은 넓은 허용 범위를 가질 수 있습니다. 운영 환경에 인접한 인프라를 편집하는 코드 에이전트 (code agent)는 더 엄격한 경계가 필요합니다. 검색하고, 글을 쓰고, 돈을 쓰고, 티켓을 생성하며, 외부 API를 호출할 수 있는 모델은, 모델을 챗봇 (chatbot)보다는 신뢰할 수 없는 자동화 작업자 (untrusted automation worker)로 취급하는 지루한 권한 시스템이 필요합니다.

이것은 국가적 논쟁과 동일한 형태입니다. 접근성 (Access)이 중요합니다. 확산 (Diffusion)이 중요합니다. 임계값 (thresholds), 감사 추적 (audit trails), 그리고 제동 장치 (brakes)도 마찬가지입니다.

나의 편향은 여전히 충분히 안전한 범위 내에서의 개방성을 향해 있습니다. 나는 사람들이 직접 실행하고, 검토하고, 자신들의 워크플로우 (workflows)에 맞게 조정할 수 있는 모델을 원합니다. 나는 모든 유용한 에이전트가 타인의 클라우드 (cloud) 내에 임대된 슬롯이 되는 것을 원하지 않습니다.

하지만 모든 가중치(weight) 공개를 단순히 또 다른 오픈 소스 패키지로 치부하는 것은 결국 좋지 않은 결과를 초래할 것입니다. 이러한 시스템의 능력이 향상될수록, 공개 여부에 대한 결정은 점점 더 인프라(infrastructure) 결정처럼 보일 것입니다.

오픈 웨이트(Open weights)는 사라지지 않을 것입니다. 테스트와 통제에 대한 요구 또한 사라지지 않을 것입니다. 흥미로운 과제는 안전(safety)을 해자(moat)로 만들지 않으면서 능력의 경계(capability boundary)를 설정하는 것입니다.

그것이 바로 다음 AI 전쟁이 향하는 지점입니다. 모델의 이름이 아닙니다. 벤치마크(benchmark) 스크린샷도 아닙니다. 접근 권한, 증거, 그리고 브레이크가 실질적으로 작동할 때 누가 결정권을 갖느냐의 문제입니다.