---
title: "오픈 웨이트 AI, 100만 토큰 읽고 자기 도구까지 만들기 시작함"
published: 2026-07-02T22:05:03.770Z
canonical: https://jeff.news/article/4574
---
# 오픈 웨이트 AI, 100만 토큰 읽고 자기 도구까지 만들기 시작함

허깅페이스에서 주목받은 모델 흐름은 긴 문서를 싸게 읽는 OCR, 100만 토큰 컨텍스트를 다루는 오픈 웨이트 모델, 자기 작업 도구를 설계하는 코딩 에이전트로 요약된다. 바이두의 언리미티드-OCR, 지푸AI의 GLM-5.2, 딥리인포스의 오니스 1.0이 모두 MIT 라이선스를 내세웠다는 점도 기업 도입 관점에서 꽤 크다.

## 이번 주 흐름은 ‘길게 읽고, 깊게 풀고, 도구까지 만든다’임

- 허깅페이스 트렌딩 모델 쪽에서 이번 주 눈에 띈 건 세 가지임
  - 바이두의 언리미티드-OCR은 긴 PDF와 문서 OCR 병목을 겨냥함
  - 지푸AI의 GLM-5.2는 100만 토큰 컨텍스트를 내세운 오픈 웨이트 플래그십임
  - 딥리인포스의 오니스 1.0은 코딩 에이전트가 자기 작업 도구까지 설계한다는 쪽으로 치고 나옴

- 공통점도 꽤 선명함
  - 모두 오픈소스 또는 오픈 웨이트 흐름에 있고, 기사 기준으로 지역 제한 없는 MIT 라이선스가 반복해서 등장함
  - 성능 경쟁의 축이 단순 파라미터 수가 아니라 긴 컨텍스트, KV 캐시 관리, 에이전트 작업 구조로 이동 중임

### 바이두 언리미티드-OCR

- 언리미티드-OCR은 이름 그대로 긴 문서를 한 번에 읽는 OCR을 노림
  - 바이두가 6월 22일 공개한 30억 파라미터 모델
  - 딥시크-OCR을 기반으로 하고, 디코더 어텐션을 레퍼런스 슬라이딩 윈도우 어텐션(R-SWA)으로 교체함
  - 목표는 결과 텍스트가 길어질수록 KV 캐시가 커져 속도가 떨어지는 문제를 잡는 것

- 숫자로 보면 포인트가 더 분명함
  - 최대 3만2000토큰 범위 안에서 수십 페이지 PDF를 단 한 번의 연산으로 받아쓰는 구조를 강조함
  - 모델 크기는 약 6.8GB 수준이라, 배포 관점에서도 아주 비현실적인 덩치는 아님
  - vLLM, SGLang, 올라마, 라마.cpp, 트랜스포머스에서 돌릴 수 있다고 소개됨

- 다만 아직은 벤더 설명을 그대로 믿기엔 빈칸이 있음
  - 공개 시점에 정량 벤치마크, 학습 데이터, 지원 언어 범위가 자세히 나오지 않음
  - 긴 문서 처리 구조는 흥미롭지만, 실제 정확도는 독립 평가가 나와야 판단 가능함

### GLM-5.2

- GLM-5.2는 ‘오픈 웨이트도 프런티어 근처까지 간다’는 메시지를 정면으로 미는 모델임
  - 중국 지푸AI가 내놓은 플래그십이고, 시리즈 최초로 100만 토큰 컨텍스트를 안정적으로 지원한다고 소개됨
  - 총 744B급 전문가 혼합(MoE) 구조지만, 추론 때는 일부 전문가만 활성화되는 방식임

- 핵심 구조는 인덱스셰어(IndexShare)임
  - 네 겹의 희소 어텐션 층이 하나의 색인을 공유하도록 설계함
  - 기사 기준 100만 토큰 길이에서 토큰당 연산량(FLOPs)을 2.9배 줄였다고 함
  - 추측 디코딩용 MTP 층 개선으로 처리 효율도 최대 20% 끌어올렸다고 소개됨

- 코딩 벤치마크 수치도 공격적임
  - 지푸AI 자체 발표 기준 딥SWE에서 46.2%로 오픈 웨이트 최고점을 기록했다고 함
  - 장기 과제 벤치마크 프런티어SWE에서는 앤트로픽 옵스 4.8에 1%p 뒤지고 GPT-5.5를 앞섰다고 주장함
  - 단, 이건 자체 발표라 독립 평가 전까지는 ‘흥미로운 주장’으로 보는 게 맞음

> [!IMPORTANT]
> GLM-5.2의 진짜 메시지는 100만 토큰 자체보다, 긴 컨텍스트를 감당하기 위해 계산량과 메모리 구조를 어떻게 줄였는지에 있음.

### 오니스 1.0

- 오니스 1.0은 코딩 에이전트 쪽에서 꽤 재밌는 방향을 보여줌
  - 딥리인포스가 6월 25일 공개한 에이전트 코딩 전용 모델 패밀리
  - 9B, 31B, 35B(MoE), 397B(MoE) 네 가지 크기로 나옴
  - 큐원 3.5와 젬마 4를 기반으로 후처리 학습했다고 소개됨

- 차별점은 문제만 푸는 게 아니라 ‘문제 풀 도구’까지 스스로 설계한다는 점임
  - 보통 코딩 에이전트는 사람이 만든 하네스나 스캐폴드 안에서 움직임
  - 오니스는 강화학습 과정에서 자기 하네스를 직접 설계하도록 학습했다는 게 핵심
  - 그래서 문제 풀이 능력과 작업 골격 설계를 같이 최적화한다는 방향임

- 성능 주장도 작지 않음
  - 9B 모델이 터미널-벤치 2.1에서 43.1점, SWE-벤치 버라이파이드에서 69.4점을 기록했다고 함
  - 4비트 양자화 시 6~8GB VRAM 소비자용 GPU에서도 돌아간다고 소개됨
  - 397B 플래그십은 터미널-벤치 2.1에서 77.5점, SWE-벤치 버라이파이드에서 82.4점을 기록했다고 함
  - 컨텍스트는 26만2000토큰

- 자기 도구를 만드는 모델은 리워드 해킹 위험도 같이 커짐
  - 오니스는 고정 신뢰 경계, 결정론적 감시자, 동결된 LLM 심판이라는 3중 장치를 둔다고 설명됨
  - 가중치가 MIT로 풀린 만큼 안전장치를 제거한 파생본이 나올 수 있다는 점도 기사에서 경고함

> [!WARNING]
> 오픈 웨이트 코딩 에이전트는 자체 호스팅 장점이 크지만, 공식 원본 여부와 안전장치 제거 여부를 확인하지 않으면 운영 리스크가 바로 커짐.

### 개발자에게 남는 포인트

- 긴 컨텍스트는 이제 데모용 자랑거리가 아니라 문서 자동화와 코드베이스 분석의 실무 조건이 되고 있음
  - 계약서, 보고서, 논문, 기술 매뉴얼처럼 통째로 읽어야 의미가 있는 업무가 직접적인 수혜 대상임
  - 대규모 코드베이스 리팩터링이나 장시간 자율 코딩 태스크도 같은 흐름 위에 있음

- 오픈 웨이트와 MIT 라이선스가 프런티어 근처까지 올라오면 한국 기업에도 선택지가 늘어남
  - 데이터를 외부 API로 보내지 않고 자체 호스팅하는 구성이 더 현실적이 됨
  - 엔비디아 밖 배포 사례나 화웨이 어센드 계열 지원처럼 하드웨어 선택지도 같이 넓어지는 흐름임

---
## 기술 맥락

- 이번 기사에서 가장 중요한 선택은 긴 컨텍스트를 어떻게 싸게 유지하느냐예요. 100만 토큰을 읽는다고 말하는 건 쉬운데, 실제로는 KV 캐시가 커지면서 메모리와 지연시간이 같이 터지거든요.

- 바이두의 R-SWA는 오래된 정보를 전부 들고 있지 않고 필요한 범위를 중심으로 보는 쪽이에요. OCR처럼 긴 문서를 순서대로 읽는 작업에서는 이 방식이 메모리를 일정하게 묶는 데 유리해요.

- GLM-5.2의 IndexShare는 여러 희소 어텐션 층이 색인을 공유하게 해서 중복 계산을 줄이는 선택이에요. 100만 토큰 길이에서 토큰당 연산량을 2.9배 줄였다는 주장이 중요한 이유가 여기에 있어요.

- 오니스 1.0의 자기 스캐폴딩은 코딩 에이전트 운영 방식 자체를 건드려요. 사람이 만든 고정된 작업틀을 쓰는 대신 모델이 문제에 맞는 도구와 절차를 만들면 더 유연해질 수 있지만, 동시에 리워드 해킹 감시가 필수가 돼요.

- 한국 기업 입장에서는 성능표보다 라이선스와 배포 통제가 더 현실적인 의사결정 포인트예요. MIT 오픈 웨이트라면 자체 호스팅과 커스터마이징이 쉬워지지만, 공식 가중치인지 안전장치가 유지됐는지 확인해야 운영 리스크를 줄일 수 있어요.

## 핵심 포인트

- 바이두 언리미티드-OCR은 30억 파라미터 모델로 레퍼런스 슬라이딩 윈도우 어텐션을 써 긴 문서 처리 시 메모리 증가 문제를 겨냥함
- GLM-5.2는 100만 토큰 컨텍스트와 인덱스셰어를 내세우며 100만 토큰 길이에서 토큰당 연산량을 2.9배 줄였다고 주장함
- 오니스 1.0은 코딩 문제뿐 아니라 문제를 풀 작업 골격까지 스스로 설계하는 자기 스캐폴딩을 강조함
- 오픈 웨이트 모델들이 MIT 라이선스로 공개되면서 자체 호스팅과 데이터 주권 선택지가 넓어지고 있음

## 인사이트

이번 흐름은 단순히 모델 성능이 조금 오른 뉴스가 아니라, 긴 컨텍스트와 에이전트 자율성이 오픈 웨이트 진영으로 빠르게 내려오고 있다는 신호다. 다만 벤더 자체 벤치마크와 무검열 파생본 리스크는 그대로라, 도입할 때는 성능보다 출처와 운영 통제가 먼저다.