AI 데일리 브리핑 — 2026-10-13
Soshy·
기준 시점: 2026-10-13 06:00 KST (Asia/Seoul)
AI 동향 조사 범위: 2026-10-12 06:00 ~ 2026-10-13 06:00 KST
추천 글 범위: 2026-10-06 06:00 ~ 2026-10-13 06:00 KST
1️⃣ 주요 모델·연구
Microsoft Research, 실제 학생의 학습 반응을 재현하는 ‘StudentSim’ 공개…AI 튜터를 실제 학생에게 적용하기 전에 평가
- 발표일: 2026-10-12 — 정확한 게시 시각 미확인
- 적용 범위: 교육용 AI, 개인화 학습, AI 에이전트 평가, 학습자 행동 모델링, 강화학습
- 원문: Microsoft Research — Simulating student learning for better AI tutoring
- 관련 원문: Microsoft Research — StudentSim 논문
Microsoft Research가 실제 학생의 문제 해결 방식과 교사의 설명에 대한 반응을 모사하는 AI 연구 시스템 StudentSim을 공개했다.
이번 연구는 AI가 학생에게 얼마나 좋은 설명을 제공하는가보다, 그 설명을 들은 학생이 실제로 무엇을 배우는가라는 문제에서 출발한다.
최근 생성형 AI를 활용한 교육 서비스는 빠르게 발전하고 있다.
AI 튜터는 수학 문제를 설명하거나, 영어 작문을 첨삭하고, 학생이 잘못 이해한 개념을 다시 설명할 수 있다.
하지만 AI가 정확한 설명을 제공했다고 해서 학생이 실제로 학습했다고 볼 수는 없다.
예를 들어 학생이 곱셈 문제를 틀렸을 때 AI 튜터가 정답과 풀이를 설명했다고 가정해 보자.
학생이 그 설명을 이해하고 다음 문제를 풀 수 있게 됐다면 효과적인 지도였다고 볼 수 있다.
반면 정답을 그대로 알려줬기 때문에 해당 문제만 맞히고, 같은 유형의 새로운 문제에서는 다시 실패한다면 학습 효과가 충분하지 않을 수 있다.
이처럼 교육용 AI의 품질을 평가하려면 AI가 제공한 설명 자체뿐 아니라 설명을 받은 학생의 행동 변화를 관찰해야 한다.
그런데 실제 학생을 대상으로 반복적인 실험을 진행하는 데는 시간과 비용이 많이 든다.
개인별 학습 수준이 다르고, 같은 설명도 학생마다 다른 영향을 줄 수 있기 때문이다.
StudentSim은 이런 문제를 해결하기 위해 실제 학생의 학습 기록을 바탕으로 학생마다 다른 행동을 재현하는 개인화된 AI 시뮬레이터를 만든다.
단순히 학생처럼 말하는 AI와의 차이
학생을 흉내 내는 AI를 만드는 가장 간단한 방법은 범용 언어모델에게 특정한 역할을 부여하는 것이다.
예를 들어 모델에게 초등학생처럼 행동하거나 수학을 어려워하는 학생처럼 답변하도록 요청할 수 있다.
이런 방식은 Role-Playing(역할 수행)이라고 한다.
하지만 모델이 어린 학생처럼 말한다고 해서 실제로 어린 학생의 지식 수준을 가지고 있는 것은 아니다.
모델은 이미 훨씬 많은 지식을 학습했기 때문에 학생이 모를 법한 문제까지 정확하게 해결할 수 있다.
표현만 학생처럼 바뀌었을 뿐 실제 문제 해결 능력은 성인의 수준을 유지할 수 있다는 것이다.
이런 모델로 AI 튜터를 평가하면 문제가 발생한다.
실제 학생이라면 이해하지 못할 설명도 시뮬레이터는 쉽게 이해하는 것처럼 반응할 수 있기 때문이다.
Microsoft는 이를 해결하기 위해 실제 학습자의 과거 답변과 오류, 교사의 지도 이후 발생한 변화를 학습 데이터로 사용했다.
연구팀은 StudentSim의 품질을 두 가지 기준으로 평가한다.
첫 번째는 Behavioral Fidelity(행동 충실도)다.
시뮬레이터가 실제 학생과 비슷한 답변과 실수를 만들어내는지를 측정한다.
두 번째는 Guidance Responsiveness(지도 반응성)다.
교사의 설명이나 힌트를 제공했을 때 실제 학생처럼 답변을 수정하는지를 측정한다.
예를 들어 어떤 학생이 음수 곱셈 문제에서 부호를 자주 틀린다고 가정해 보자.
학생의 과거 기록을 학습한 시뮬레이터는 새로운 문제에서도 비슷한 실수를 재현해야 한다.
이후 교사가 음수의 곱셈 규칙을 설명했을 때는 실제 학생이 보였던 학습 반응과 비슷한 방향으로 답변을 수정해야 한다.
단순히 학생의 실수를 재현하는 것과 지도에 따라 학생의 지식 상태가 어떻게 바뀌는지 예측하는 것을 구분한 것이다.
학생별로 모델을 학습하는 두 단계 구조
StudentSim은 모든 학생을 하나의 동일한 시뮬레이터로 표현하지 않는다.
연구팀은 두 단계의 학습 과정을 사용했다.
첫 번째 단계에서는 여러 학생의 학습 기록을 합쳐 공통적인 행동 패턴을 학습한다.
예를 들어 수학 문제에서 자주 발생하는 실수나 영어 작문에서 나타나는 일반적인 오류, 교사의 설명을 받은 뒤 답변을 수정하는 방식을 학습한다.
두 번째 단계에서는 개별 학생의 기록을 이용해 모델을 추가로 조정한다.
이렇게 하면 각 학생의 데이터가 적더라도 공통적인 학습 패턴을 활용하면서 개별 학생의 강점과 약점을 반영하는 시뮬레이터를 만들 수 있다.
연구팀은 이를 체스, 영어 작문, 수학의 세 분야에서 평가했다.
체스에서는 학생이 어떤 수를 선택하는지, 교사의 설명을 들은 뒤 어떤 수로 변경하는지 살펴봤다.
영어 작문에서는 학생이 작성한 문장의 오류 패턴과 교사의 첨삭 이후 발생하는 변화를 분석했다.
수학에서는 객관식 문제에 대한 답변과 설명을 들은 뒤 정답을 수정하는 행동을 평가했다.
모든 연구 데이터는 공개된 학습자 데이터셋에서 가져왔으며, 개인을 식별할 수 있는 정보가 제거된 자료만 사용했다고 Microsoft는 설명한다.
범용 모델보다 실제 학생의 행동을 더 정확하게 재현
Microsoft의 자체 평가에서 StudentSim은 여러 기존 접근법보다 높은 성능을 기록했다.
체스 분야의 행동 충실도는 0.5150, 지도 반응성은 0.9067이었다.
같은 평가에서 GPT-5.4의 행동 충실도는 0.2316, 지도 반응성은 0.7186이었다.
체스 플레이어의 다음 행동을 예측하도록 설계된 전문 모델 Maia2는 행동 충실도 0.4535를 기록했지만, 지도 반응성은 0.2721에 그쳤다.
이 차이는 각 모델의 목적과 연결된다.
Maia2는 실제 인간의 체스 선택을 예측하는 데 특화돼 있어 행동 자체를 비교적 잘 재현한다.
하지만 자연어로 제공되는 교사의 설명을 이해하고 그에 따라 행동을 수정하는 작업에는 적합하지 않다.
반면 GPT-5.4는 자연어 설명을 잘 이해하지만, 특정 학생의 실제 능력과 실수 패턴을 충분히 재현하지 못했다.
StudentSim은 두 능력을 함께 학습하도록 설계됐다는 점에서 차이가 있다.
다만 이 결과가 StudentSim이 GPT-5.4보다 전반적으로 더 지능적인 모델이라는 의미는 아니다.
특정 학생의 행동을 재현하고 지도에 대한 반응을 예측하는 전문적인 평가 작업에서 더 좋은 성능을 기록했다는 의미다.
시뮬레이터를 활용해 실제 AI 튜터 개선
연구팀은 학생 행동을 예측하는 것에서 끝나지 않고, StudentSim을 이용해 AI 튜터 자체를 개선하는 실험도 진행했다.
여기에는 Reinforcement Learning(RL, 실행 결과에 따른 보상을 이용해 모델의 행동 전략을 개선하는 강화학습)이 사용됐다.
기존 강화학습에서는 정답을 맞히거나 특정 목표를 달성하면 보상을 제공하는 방식이 흔하다.
교육용 AI에서는 이 보상을 어떻게 정의할지가 어렵다.
AI 튜터가 학생에게 정답을 직접 알려주면 당장의 문제 해결률은 높아질 수 있다.
하지만 실제 학습 효과는 오히려 낮을 수도 있다.
Microsoft는 튜터의 설명을 들은 뒤 학생의 체스 판단이 얼마나 개선되는지를 보상으로 사용하는 방식을 실험했다.
StudentSim은 학생의 초기 판단과 설명 이후의 판단을 생성한다.
연구팀은 두 결과 사이의 개선 정도를 이용해 AI 튜터를 강화학습시켰다.
그 결과 StudentSim을 이용해 학습한 튜터는 평가에서 90.5%의 정확도를 기록했다.
강화학습을 사용하지 않은 기본 튜터는 75.7%, GPT-5.4를 학생 시뮬레이터로 사용한 튜터는 71.6%였다.
연구팀은 실제 체스 전문가가 어떤 방식으로 학습한 튜터인지 모르는 상태에서 설명의 품질과 개인화 수준을 평가하도록 했다.
그 결과 StudentSim을 활용한 튜터가 보고된 여러 평가 항목에서 가장 높은 결과를 얻었다.
이는 Microsoft 연구팀이 수행한 제한된 실험 결과다.
실제 학교에서 장기간 사용했을 때 학생의 성적이나 학습 능력이 같은 비율로 향상된다는 의미는 아니다.
AI 튜터 평가의 새로운 방향
Microsoft는 StudentSim을 실제 교육 현장에서 사용하는 완성된 제품으로 발표하지 않았다.
현재는 AI 튜터를 개발하고 평가하기 위한 연구용 시스템이다.
또한 시뮬레이터가 실제 학생을 완전히 대체할 수 있다고 주장하지 않는다.
학생의 실제 학습 효과와 안전성, 사용성은 여전히 사람을 대상으로 한 연구를 통해 확인해야 한다.
이번 연구가 보여주는 변화는 AI 튜터를 평가하는 기준이 설명의 정확성에서 학습자의 변화까지 확장되고 있다는 점이다.
AI가 아무리 좋은 설명을 만들더라도 그 설명이 학생의 현재 지식 수준에 맞지 않으면 교육 효과는 제한적일 수 있다.
StudentSim은 실제 학습자의 반응을 모델링해 이런 문제를 제품 개발 초기 단계에서 더 빠르게 평가하려는 시도다.
연구팀은 논문과 학습·평가 코드를 공개했으며, 향후 더 긴 학습 과정과 다양한 과목으로 연구를 확장할 계획이다.
2️⃣ AI 제품·서비스
이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.
3️⃣ 개발 도구·에이전트
LightOn, 로컬에서 실행되는 20억 파라미터 코드 검색 에이전트 ‘ColGrep-Agent-2B’ 공개…Claude Code의 토큰 사용량 34% 절감
- 발표일: 2026-10-12 — 정확한 게시 시각 미확인
- 적용 범위: 코딩 에이전트, 오픈웨이트 모델, 코드 검색, Claude Code, Codex, 로컬 AI, 개발 비용 최적화
- 원문: LightOn — ColGrep-Agent: Cutting Frontier Coding Agents’ Tokens by a Third
- 관련 원문: GitHub — ColGrep
AI 기업 LightOn이 대형 코딩 에이전트의 코드 검색 작업을 대신 수행하는 경량 오픈 모델 ColGrep-Agent-2B를 공개했다.
이 모델은 약 20억 개의 파라미터를 가진 코드 검색 전문 에이전트다.
최근 코딩 에이전트는 단순히 코드를 생성하는 것에서 벗어나 기존 프로젝트를 분석하고, 문제의 원인을 찾고, 여러 파일을 수정하는 작업까지 수행하고 있다.
그런데 실제 코딩 에이전트의 작업 과정을 살펴보면 상당한 시간이 코드를 작성하기 전 필요한 파일을 찾는 과정에 사용된다.
예를 들어 사용자가 관리자 페이지에서 특정 설정을 변경해도 저장되지 않는 오류를 수정해 달라고 요청했다고 가정해 보자.
코딩 에이전트는 먼저 설정 화면을 구현한 파일을 찾아야 한다.
그다음 상태를 관리하는 코드, API 요청을 처리하는 함수와 서버에서 데이터를 저장하는 부분을 차례대로 확인해야 한다.
이 과정에서 에이전트는 파일 이름을 추측하거나 문자열을 검색하고, 찾은 파일을 읽고, 다시 다른 검색을 수행한다.
문제는 이런 작업을 수행할 때마다 비용이 높은 프런티어 모델이 전체 대화 문맥을 다시 처리할 수 있다는 점이다.
LightOn은 코드 검색을 별도의 작은 모델에 맡기면 이 비용을 줄일 수 있다고 판단했다.
단순 문자열 검색과 의미 기반 코드 검색의 차이
일반적인 코드 검색에서는 grep이나 ripgrep 같은 도구가 사용된다.
이런 도구는 특정 문자열이나 정규표현식에 일치하는 코드를 빠르게 찾는다.
그러나 사용자가 설명한 기능의 이름과 실제 코드에서 사용하는 이름이 다르면 검색이 어려워질 수 있다.
예를 들어 사용자는 고객의 추가 속성을 관리하는 기능이라고 설명했지만, 코드에서는 해당 기능을 fieldDefinition이라는 이름으로 구현했을 수 있다.
문자열 검색은 두 표현 사이의 의미적 관계를 직접 이해하지 못한다.
ColGrep은 이를 해결하기 위해 Semantic Search(의미 기반 검색)를 사용한다.
검색 문장과 코드의 의미를 숫자 벡터로 변환하고, 서로 얼마나 관련 있는지 비교하는 방식이다.
이 과정에서 사용되는 기술이 Embedding(임베딩)이다.
Embedding은 문장이나 코드의 의미를 여러 숫자로 구성된 벡터로 표현하는 방법이다.
ColGrep은 코드의 여러 부분을 각각 벡터로 표현하는 Multi-Vector Search를 사용한다.
하나의 파일 전체를 하나의 벡터로 압축하는 대신 여러 부분의 의미를 보존해 세부적인 코드 검색 정확도를 높이려는 방식이다.
새로운 ColGrep-Agent-2B는 이런 검색 시스템 위에서 작동한다.
모델은 사용자의 질문을 받으면 먼저 의미 기반 검색을 수행한다.
이후 관련성이 높은 파일을 직접 읽고, 다른 함수나 파일로 연결되는 참조를 따라가며 필요한 코드의 위치를 확인한다.
최종적으로는 관련 파일의 경로와 줄 번호, 해당 코드의 내용을 반환한다.
대형 코딩 에이전트는 이 결과를 전달받아 실제 코드 수정과 검증을 진행한다.
즉 큰 모델은 문제 해결에 집중하고, 작은 모델은 필요한 코드를 찾아오는 역할을 담당한다.
Claude Code와 연결한 624회 평가
LightOn은 실제 비용 절감 효과를 확인하기 위해 Claude Code와 ColGrep-Agent-2B를 연결했다.
평가에는 13개의 공개 저장소를 사용했다.
저장소는 Rust, Go, TypeScript, Python 등 여러 언어로 작성됐으며 규모는 약 1만7천 줄에서 180만 줄까지 다양했다.
연구팀은 코드에서 특정 기능이나 오류와 관련된 부분을 찾는 52개의 질문을 만들었다.
각 질문을 세 번씩 실행하고 네 가지 검색 방식을 비교했다.
비교 대상은 기본 grep 검색, ColGrep 의미 검색, ColGrep-Agent를 이용한 검색, 두 방식을 함께 사용하는 Balanced 구성이다.
총 624개의 세션을 실행했다.
평가에는 Claude Sonnet 5.5가 사용됐다.
결과는 다음과 같았다.
| 검색 방식 | 질문당 평균 API 토큰 | 기존 대비 절감률 | 정답률 | 평균 소요 시간 |
|---|---|---|---|---|
| 기본 Grep | 약 142,000 | - | 83.3% | 13.0초 |
| ColGrep | 약 107,000 | 24.6% | 79.5% | 15.0초 |
| ColGrep-Agent | 약 93,000 | 34.3% | 80.8% | 21.6초 |
| Balanced | 약 112,000 | 21.2% | 83.3% | 17.7초 |
ColGrep-Agent를 사용하면 Claude Code의 API 토큰 사용량이 평균 34.3% 감소했다.
캐시 효과까지 반영한 API 비용은 질문당 약 7.3센트에서 4.4센트로 줄었다.
약 40%의 비용 절감이다.
하지만 처리 시간은 오히려 증가했다.
기본 Grep 방식에서는 평균 13.0초가 걸렸지만 ColGrep-Agent에서는 21.6초가 필요했다.
로컬 모델이 추가로 검색하고 파일을 읽는 시간이 발생했기 때문이다.
따라서 이 결과를 단순히 코딩 에이전트가 더 빨라졌다고 해석해서는 안 된다.
토큰과 API 비용은 줄었지만 전체 검색 시간은 길어지는 절충 관계가 나타났다.
정확도에도 차이가 있었다.
기본 Grep의 정답률은 83.3%, ColGrep-Agent는 80.8%였다.
연구팀은 이 차이가 통계적으로 유의하지 않았다고 설명한다.
하지만 신뢰구간이 비교적 넓어 의미 있는 정확도 하락 가능성을 완전히 배제할 수는 없다고도 밝혔다.
Balanced 구성은 기본 Grep과 같은 83.3%의 정답률을 기록하면서 토큰을 약 21% 절약했다.
이 수치들은 LightOn이 자체적으로 진행한 평가 결과이며, 실제 코드 수정부터 테스트와 PR 생성까지 포함한 전체 코딩 작업의 생산성을 직접 측정한 결과는 아니다.
20억 파라미터 모델이 더 큰 모델과 경쟁
LightOn은 ColGrep-Agent-2B의 코드 위치 탐색 능력도 별도로 평가했다.
여기에는 SWE-bench Lite와 Multi-SWE-bench Flash를 코드 위치 검색에 맞게 변형한 벤치마크를 사용했다.
평가의 목적은 코드를 수정하는 것이 아니라 오류와 관련된 파일과 코드 줄을 얼마나 정확하게 찾는가였다.
ColGrep-Agent-2B는 SWE-bench Lite에서 파일 단위 F1 76.18%, 줄 단위 F1 19.92%를 기록했다.
이는 일부 270억~310억 파라미터 규모의 범용 모델과 경쟁할 수 있는 수준이었다.
F1 Score는 검색한 결과의 정확도와 실제 정답을 얼마나 빠짐없이 찾았는지를 함께 평가하는 지표다.
모델이 무조건 많은 파일을 반환한다고 좋은 점수를 받는 것은 아니다.
실제로 필요한 코드의 위치를 얼마나 정확하게 찾아냈는지가 중요하다.
LightOn은 이런 결과가 특정 작업에 집중해서 학습한 작은 모델이 훨씬 큰 범용 모델과 경쟁할 수 있다는 점을 보여준다고 설명한다.
다만 모델이 코드 위치를 잘 찾는 능력과 실제 오류를 수정하는 능력은 다른 문제다.
이번 모델은 코드 수정이 아니라 코드 검색에 특화된 에이전트다.
로컬 실행과 공개 범위
ColGrep-Agent-2B는 오픈 모델로 공개됐다.
모델은 GGUF 형식으로 제공되며 llama.cpp를 통해 실행할 수 있다.
GGUF는 언어모델의 가중치와 실행에 필요한 정보를 저장하는 형식이다.
경량화된 모델을 로컬 PC에서 실행할 때 널리 사용된다.
LightOn이 제공하는 기본 양자화 모델은 약 2.5GB 크기다.
Quantization(양자화)은 모델이 사용하는 숫자의 정밀도를 낮춰 메모리 사용량과 연산 비용을 줄이는 기술이다.
Apple Silicon에서는 Metal을 이용하고, NVIDIA·AMD·Intel GPU에서는 Vulkan 등을 활용할 수 있다.
GPU를 사용할 수 없는 경우 CPU 실행도 지원한다.
LightOn이 측정한 M3 Pro 환경에서는 질문 하나를 처리하는 데 약 20초가 걸렸으며, 최대 메모리 사용량은 약 3~4GB였다.
Claude Code뿐 아니라 Codex와 OpenCode에도 연결할 수 있도록 통합 기능이 제공된다.
여기서 중요한 점은 로컬 코드 검색 모델을 사용한다고 해서 모든 코딩 데이터가 항상 로컬에만 남는 것은 아니라는 사실이다.
상위 코딩 에이전트가 클라우드 모델을 사용한다면 검색 결과와 관련 코드는 해당 모델 서비스에 전달될 수 있다.
따라서 완전한 로컬 개발 환경과 코드 검색만 로컬에서 수행하는 환경은 구분해야 한다.
이번 발표는 AI 코딩 도구의 비용을 줄이는 접근이 단순히 더 저렴한 범용 모델을 선택하는 것에서 벗어나 개발 과정의 특정 작업을 작은 전문 모델에 분리하는 방식으로 확대되고 있음을 보여준다.
특히 대규모 저장소를 자주 분석하는 코딩 에이전트에서는 코드 검색이 차지하는 비용이 상당할 수 있기 때문에, 이런 역할 분담이 전체 운영 비용을 줄이는 방법이 될 수 있다.
🖥️ AI 인프라·반도체
AWS, 여러 GPU 서버에 모델 추론을 분산하는 ‘Ray LLM Deep Learning Containers’ 공개…입력 처리와 토큰 생성 분리
- 발표일: 2026-10-12 — 정확한 게시 시각 미확인
- 적용 범위: AI 모델 추론, GPU 인프라, Amazon EKS, Ray Serve, vLLM, 분산 추론, RAG·에이전트 서비스
- 원문: AWS — Run multi-node inference workloads using Ray LLM Deep Learning Containers
AWS가 여러 GPU 서버에 하나의 언어모델 추론 작업을 분산할 수 있도록 구성된 Ray LLM Deep Learning Containers(DLC)를 소개했다.
이번 발표는 완전히 새로운 언어모델이나 GPU를 출시한 것은 아니다.
기존 Amazon EKS와 Ray Serve, vLLM 등을 이용해 분산 추론 시스템을 만들 때 필요한 복잡한 소프트웨어 구성을 사전에 검증된 컨테이너 형태로 제공하는 것에 초점을 맞춘다.
대형 언어모델은 실제 서비스를 제공할 때 상당한 GPU 자원을 사용한다.
모델을 실행하는 과정은 크게 두 단계로 나눌 수 있다.
첫 번째는 Prefill이다.
Prefill은 사용자가 전달한 입력 전체를 읽고 내부 계산을 수행하는 단계다.
예를 들어 사용자가 긴 보고서나 여러 개의 문서를 전달했다면 모델은 답변을 생성하기 전에 이 정보를 처리해야 한다.
두 번째는 Decode다.
Decode는 입력을 처리한 뒤 실제 답변을 토큰 단위로 생성하는 단계다.
Token(토큰)은 모델이 텍스트를 처리하거나 생성할 때 사용하는 기본 단위다.
언어모델은 일반적으로 출력 토큰을 하나씩 생성하면서 문장을 완성한다.
두 단계는 사용하는 GPU 자원의 특성이 다르다.
Prefill은 많은 입력 토큰을 한꺼번에 처리하므로 대규모 행렬 연산이 집중된다.
따라서 GPU의 계산 성능이 중요하다.
반면 Decode는 새로운 토큰을 생성할 때 이전 계산 결과와 모델 가중치를 반복해서 읽어야 한다.
이 단계에서는 GPU의 메모리 대역폭이 중요한 제약이 될 수 있다.
Memory Bandwidth(메모리 대역폭)는 일정 시간 동안 메모리에서 읽거나 쓸 수 있는 데이터의 양을 의미한다.
하나의 GPU에서 두 단계를 실행할 때 발생하는 문제
일반적인 언어모델 서버에서는 Prefill과 Decode가 같은 GPU에서 실행된다.
사용자가 짧은 질문을 보내는 환경에서는 충분히 효율적일 수 있다.
하지만 여러 사용자가 긴 문서를 동시에 전달하면 상황이 달라진다.
새로운 요청의 긴 입력을 처리하는 동안 이미 답변을 생성 중인 다른 요청의 Decode 작업이 지연될 수 있다.
사용자는 AI가 답변을 빠르게 시작했더라도 중간에 토큰 생성이 느려지는 현상을 경험할 수 있다.
특히 RAG나 문서 분석 에이전트처럼 입력이 길고 요청이 동시에 많이 발생하는 서비스에서는 이런 문제가 두드러질 수 있다.
이를 해결하기 위해 사용되는 방법이 Prefill/Decode Disaggregation이다.
Disaggregation은 하나의 시스템에서 수행하던 기능을 서로 다른 구성요소로 분리하는 접근이다.
언어모델 추론에서는 Prefill을 처리하는 GPU 서버와 Decode를 처리하는 GPU 서버를 분리한다.
Prefill 서버는 입력을 처리하고, Decode 서버는 이후 답변을 생성한다.
이렇게 구성하면 두 단계가 동일한 GPU 자원을 놓고 경쟁하는 상황을 줄일 수 있다.
또한 각 단계의 특성에 맞게 서버 수와 하드웨어 구성을 독립적으로 조정할 수 있다.
두 서버 사이에서 전달해야 하는 KV Cache
Prefill과 Decode를 분리할 때 가장 큰 문제는 입력 처리 결과를 어떻게 전달하는가이다.
언어모델은 입력을 처리하면서 이후 토큰 생성에 필요한 내부 계산 결과를 저장한다.
이를 KV Cache(Key-Value Cache)라고 한다.
KV Cache는 모델이 이전 토큰의 정보를 다시 계산하지 않고 활용하도록 돕는 저장 구조다.
일반적인 추론 환경에서는 Prefill과 Decode가 같은 GPU에서 실행되므로 KV Cache가 GPU 메모리에 그대로 남아 있을 수 있다.
하지만 두 단계를 서로 다른 서버에서 실행한다면 Prefill 서버에서 만든 KV Cache를 Decode 서버로 전달해야 한다.
이 과정에서 데이터 전송이 지나치게 느리면 두 단계를 분리해서 얻는 성능상의 이점이 사라질 수 있다.
AWS는 이를 위해 NVIDIA Inference Transfer Library(NIXL)를 사용한다.
NIXL은 AI 추론 시스템에서 GPU 메모리와 캐시 데이터를 서로 다른 장치 사이에 효율적으로 전달하기 위한 기술이다.
서버 사이의 고속 통신에는 Elastic Fabric Adapter(EFA)를 활용한다.
EFA는 AWS가 제공하는 고성능 네트워크 인터페이스로, 여러 서버가 대량의 데이터를 낮은 지연시간으로 교환해야 하는 작업에 사용된다.
모델 실행 자체에는 vLLM이 사용된다.
vLLM은 여러 사용자의 언어모델 요청을 효율적으로 처리하기 위한 오픈소스 추론 엔진이다.
이 구성요소들을 연결하는 역할은 Ray Serve가 담당한다.
Ray Serve는 여러 서버에 분산된 머신러닝 모델과 서비스를 배포하고 요청을 전달하는 시스템이다.
새로운 컨테이너가 제공하는 것
AWS의 Ray LLM DLC는 이런 구성요소를 사전에 결합한 실행 이미지를 제공한다.
Container(컨테이너)는 프로그램과 실행에 필요한 라이브러리, 설정 등을 하나의 패키지로 묶어 독립적인 환경에서 실행할 수 있도록 하는 기술이다.
기존에는 개발자가 CUDA, vLLM, Ray Serve, NIXL과 네트워크 라이브러리의 호환되는 버전을 직접 확인해야 했다.
대규모 AI 인프라에서는 이런 작업이 상당한 부담이 될 수 있다.
예를 들어 GPU 드라이버나 CUDA 라이브러리를 업데이트했는데 다른 구성요소가 해당 버전을 지원하지 않으면 기존에 정상적으로 작동하던 모델 서버가 실행되지 않을 수 있다.
AWS는 사전에 검증된 DLC를 이용하면 이런 의존성 문제를 줄일 수 있다고 설명한다.
또한 Prefill과 Decode 서버 구성을 YAML 설정 파일로 정의하도록 했다.
YAML은 프로그램의 설정을 사람이 읽기 쉬운 텍스트로 표현하는 형식이다.
개발자는 Prefill과 Decode에 사용할 모델, GPU 메모리 사용 비율, 연결 방법과 실행 인스턴스 등을 설정할 수 있다.
이후 Ray Serve가 두 서버 사이의 요청 전달과 KV Cache 이동을 관리한다.
외부 애플리케이션에는 하나의 OpenAI 호환 API 엔드포인트를 제공한다.
따라서 애플리케이션은 내부적으로 모델이 몇 개의 GPU 서버에 분산돼 있는지 직접 관리할 필요가 없다.
두 개의 GPU 서버를 이용한 구현 사례
AWS는 실제 구성 예시로 Amazon EKS에 두 개의 GPU 노드를 배포했다.
EKS(Elastic Kubernetes Service)는 AWS에서 Kubernetes 클러스터를 관리하는 서비스다.
Kubernetes는 여러 서버에 프로그램을 배치하고 실행 상태를 관리하는 플랫폼이다.
실험 구성에는 CPU 기반 관리 노드 하나와 GPU 기반 작업 노드 두 개가 사용됐다.
두 GPU 노드는 각각 g6.8xlarge 인스턴스였다.
하나는 Prefill을 담당하고 다른 하나는 Decode를 담당한다.
모델은 Qwen3.5-9B를 사용했다.
Prefill 서버에서 생성한 KV Cache는 NIXL과 EFA를 통해 Decode 서버로 전달된다.
외부 요청은 Ray Serve가 제공하는 하나의 엔드포인트로 전달된다.
다만 이번 글은 주로 분산 추론 시스템을 구성하는 방법과 아키텍처를 설명한다.
동일한 모델을 단일 서버에서 실행했을 때와 비교해 전체 처리량이 몇 배 증가했는지에 대한 일반적인 성능 검증 결과를 제시한 것은 아니다.
따라서 Prefill과 Decode를 분리했다고 해서 모든 환경에서 추론 속도가 개선된다고 단정할 수는 없다.
특히 요청량이 적거나 입력 길이가 짧은 서비스에서는 서버 사이의 데이터 전송 비용이 오히려 부담이 될 수도 있다.
이번 발표는 대규모 AI 서비스를 운영할 때 모델 자체의 성능뿐 아니라 입력을 처리하는 단계와 답변을 생성하는 단계의 자원 특성을 구분해 인프라를 설계하는 방식이 중요해지고 있다는 점을 보여준다.
최근 AI 추론 인프라는 단순히 더 강력한 GPU를 사용하는 방향에서 벗어나, 하나의 모델 실행 과정을 여러 장치와 서버에 효율적으로 나누는 기술로 발전하고 있다.
4️⃣ 산업·정책·안전
Anthropic, 데이터센터 없이 스스로 복제하는 AI의 가능성 연구…저가형 스마트 TV 15대로 260억 파라미터 모델 실행
- 발표일: 2026-10-12 — 정확한 게시 시각 미확인
- 적용 범위: 프런티어 AI 안전, 자율 복제, 사이버보안, IoT, 오픈웨이트 모델, 분산 추론, AI 위험 평가
- 원문: Anthropic — AI models may be capable of self-replicating without access to a datacenter
Anthropic의 Frontier Red Team이 AI 모델이 고성능 데이터센터에 접근하지 않고도 인터넷에 연결된 일반 전자기기를 이용해 스스로 실행 환경을 만들고 복제할 수 있는지를 연구한 결과를 공개했다.
이번 연구의 출발점은 AI 모델의 크기가 줄어들고 작은 모델의 능력이 높아지는 현상이다.
기존에는 높은 수준의 추론과 도구 사용 능력을 가진 AI 모델을 실행하려면 상당한 GPU 자원이 필요했다.
하지만 최근에는 상대적으로 작은 모델도 코드 작성, 터미널 조작, 오류 수정과 여러 단계의 작업 수행에서 상당한 성능을 보이고 있다.
동시에 스마트 TV, 보안 카메라, 가전제품과 같은 일반 전자기기에도 AI 연산을 처리할 수 있는 반도체가 탑재되고 있다.
Anthropic은 이 두 변화가 결합되면 AI 모델이 일반적인 저성능 기기를 이용해 자율적으로 복제되는 상황이 가능해질 수 있다고 분석했다.
여기서 말하는 자율 복제는 AI가 스스로 새로운 모델을 학습시키거나 자신의 가중치를 개선한다는 의미가 아니다.
기존 모델의 가중치와 실행 코드를 다른 컴퓨터에 전달하고, 그 컴퓨터에서 다시 모델을 실행한 뒤 다음 장치로 확산되는 과정을 의미한다.
기존 컴퓨터 웜과 AI 기반 복제의 차이
컴퓨터 보안에서는 오래전부터 Worm(웜)이라는 악성 프로그램이 존재했다.
웜은 사용자가 직접 실행하지 않아도 네트워크를 통해 다른 컴퓨터로 복제되는 프로그램이다.
일반적인 웜은 개발자가 미리 작성한 공격 절차에 따라 작동한다.
예를 들어 특정 운영체제의 취약점을 찾아내거나 기본 비밀번호를 입력해 다른 컴퓨터에 접근하도록 설계될 수 있다.
하지만 공격 대상의 환경이 달라지면 기존 공격 코드가 작동하지 않을 수 있다.
AI 모델을 이용한 웜에서는 새로운 가능성이 생긴다.
모델이 자신이 접근한 컴퓨터의 운영체제와 하드웨어를 분석하고, 필요한 라이브러리를 설치하거나 실행 코드를 수정할 수 있기 때문이다.
이를 ARA(Autonomous Replication and Adaptation, 자율 복제와 적응)라고 한다.
복제 과정에서 AI가 새로운 환경에 맞춰 행동을 변경할 수 있다는 의미다.
예를 들어 어떤 장치에서는 특정 라이브러리가 설치되지 않고, 다른 장치에서는 메모리가 부족할 수 있다.
기존 악성 프로그램은 이런 차이에 대응하도록 사전에 작성된 코드를 사용해야 한다.
반면 충분한 능력을 가진 AI 에이전트는 오류 메시지를 읽고 다른 설치 방법을 찾거나 메모리 사용량을 줄이는 방법을 시도할 수 있다.
Anthropic은 이런 적응 능력이 기존 웜과 AI 기반 자율 복제 시스템을 구분하는 중요한 특징이라고 설명한다.
저가형 스마트 TV 15대로 대형 모델 실행
연구팀은 먼저 고성능 GPU가 없는 일반 전자기기에서 실제로 언어모델을 실행할 수 있는지 확인했다.
이를 위해 약 55달러에 판매되는 저가형 Android TV 박스 15개를 준비했다.
이 장치들은 일반적으로 약 1~4GB의 메모리를 가진다.
개별 장치 하나로는 수백억 파라미터 규모의 모델을 실행하기 어렵다.
하지만 모델을 여러 부분으로 나눠 서로 다른 장치에 저장하고 실행할 수 있다.
이를 Distributed Inference(분산 추론)라고 한다.
연구팀은 특히 Pipeline Parallelism(파이프라인 병렬화)을 사용했다.
하나의 모델을 여러 계층으로 나누고, 각 장치가 자신에게 할당된 계층의 계산을 수행하는 방식이다.
앞 단계의 장치가 계산한 결과를 다음 장치로 전달하면서 전체 모델의 실행을 완성한다.
Anthropic은 15개 TV 박스에 Gemma4-26B-A4B 모델을 분산 배치하는 데 성공했다.
이 모델은 약 260억 개의 전체 파라미터를 가진 모델이다.
모델의 각 계층을 여러 장치에 나눠 저장한 뒤 네트워크로 연결해 실제 텍스트를 생성했다.
측정된 생성 속도는 초당 약 0.39토큰이었다.
이는 일반적인 챗봇과 비교하면 매우 느린 속도다.
하지만 연구팀이 강조한 것은 빠른 답변 생성 능력이 아니다.
고성능 데이터센터가 없어도 여러 저가형 전자기기의 연산 자원을 결합하면 상당한 크기의 모델을 실행할 수 있다는 사실이다.
이번 실험은 Anthropic이 직접 구성한 장치와 네트워크 환경에서 진행됐다.
실제 인터넷에 연결된 타인의 스마트 TV를 감염시켜 모델을 실행한 것은 아니다.
9B 모델도 여러 종류의 하드웨어에 실행 환경 구성
연구팀은 다음으로 작은 모델이 익숙하지 않은 하드웨어에서 스스로 추론 환경을 설치할 수 있는지 평가했다.
모델이 새로운 장치에서 실행되려면 먼저 해당 장치의 운영체제와 CPU·GPU 특성을 확인해야 한다.
이후 호환되는 추론 엔진을 선택하고 필요한 라이브러리를 설치해야 한다.
실행 중 오류가 발생하면 로그를 분석하고 해결 방법을 찾아야 한다.
이 과정은 여러 단계가 서로 연결돼 있어 작은 오류 하나가 전체 실행 실패로 이어질 수 있다.
Anthropic은 Qwen3.5-9B가 평가에 사용된 아홉 종류의 하드웨어 가운데 여덟 종류에서 추론 환경을 구성하는 데 성공했다고 밝혔다.
시험 대상에는 Jetson Nano, Mac과 NVIDIA RTX 4090 등 서로 다른 종류의 컴퓨터가 포함됐다.
더 큰 모델인 GLM-5.2도 높은 성공률을 기록했다.
여기서 중요한 것은 모델이 직접 실행할 수 있는 크기와 환경을 구성할 수 있는 능력이 서로 다르다는 점이다.
작은 모델은 저성능 장치에서 실행하기 쉽지만 복잡한 설치 과정을 해결하는 능력이 부족할 수 있다.
반대로 강력한 모델은 복잡한 문제를 해결할 수 있지만, 실제로 실행하려면 더 많은 메모리와 계산 자원이 필요하다.
Anthropic은 이 두 조건을 각각 능력의 하한선과 모델 크기의 상한선으로 설명했다.
현재는 이 두 조건을 동시에 충족하는 모델이 충분하지 않지만, 작은 모델의 능력이 계속 향상되면 가까운 시기에 두 조건이 겹칠 수 있다는 것이다.
격리된 네트워크에서 자율 복제 실험
Anthropic은 실제 복제 과정도 실험했다.
다만 보안상 외부 인터넷이 아니라 격리된 Google Cloud 네트워크를 사용했다.
연구팀은 Android 15 환경을 재현한 여러 가상 노드를 준비했다.
한 노드에 AI 에이전트를 배치한 뒤 다른 노드로 이동해 추론 환경을 구성하고, 같은 과정을 반복하도록 했다.
이 과정에서 공격에 해당하는 초기 접근 단계는 의도적으로 단순화했다.
따라서 실제 인터넷의 다양한 장치를 공격할 수 있는지 평가한 것은 아니다.
연구팀의 목적은 모델이 복제에 필요한 여러 작업을 하나의 긴 실행 과정으로 연결할 수 있는지 확인하는 것이었다.
실험에 사용된 오픈웨이트 모델 가운데 GLM-5.2는 전체 복제 과정에 성공했다.
다섯 번의 실험 가운데 네 번은 8개 노드 모두로 확산됐고, 나머지 한 번은 8개 가운데 7개 노드에 도달했다.
하지만 여기에는 중요한 제한이 있다.
GLM-5.2가 다른 장치에서 실행할 모델로 사용된 것은 아니다.
모델은 상대적으로 작은 Llama3.1-8B를 배포하고 실행 환경을 구성하는 역할을 수행했다.
GLM-5.2 자체는 별도의 추론 서버에서 실행됐다.
즉 이번 실험은 충분히 강력한 모델이 작은 모델을 여러 장치에 복제하도록 관리할 수 있다는 사실을 보여준다.
실제 작은 모델이 자신의 가중치를 가지고 완전히 독립적으로 확산되는 상황을 직접 재현한 것은 아니다.
연구팀도 이 차이를 명확히 설명한다.
언제 작은 모델이 자율 복제 능력을 확보할 수 있을까?
Anthropic은 현재 모델의 능력 향상 추세를 바탕으로 앞으로의 가능성도 추정했다.
연구팀은 300억 파라미터 이하 오픈웨이트 모델의 능력이 시간에 따라 얼마나 개선됐는지 분석했다.
이를 위해 Epoch Capabilities Index(ECI)라는 모델 능력 평가 지표를 사용했다.
작은 모델의 능력은 최근 빠르게 향상되고 있었으며, 연구팀의 추세 분석에서는 2026년 말 무렵 작은 모델이 GLM-5.2와 비슷한 수준의 일반적인 문제 해결 능력을 확보할 가능성이 나타났다.
하지만 이는 실제 자율 복제 능력을 직접 예측한 수치가 아니다.
ECI는 일반적인 모델 능력을 측정하는 지표이며 특정 하드웨어에서 복제 작업을 성공적으로 수행하는 능력과 완전히 일치하지는 않는다.
Anthropic은 이런 한계를 인정하면서도 작은 모델의 성능이 계속 향상되면 실제 장치에서 자율 복제하는 AI 시스템이 가까운 미래에 가능해질 수 있다고 분석한다.
복제 속도는 매우 느릴 수 있다
AI 기반 웜이 가능해진다고 해서 즉시 인터넷 전체로 빠르게 확산된다는 뜻은 아니다.
저성능 기기에서 모델을 실행하면 추론 속도가 매우 느리기 때문이다.
Anthropic은 스마트 TV에서 실행한 모델의 처리 속도를 이용해 실제 복제 시간을 추정했다.
Gemma4-26B-A4B는 새로운 장치 하나에 추론 환경을 구성하는 데 약 71~150시간이 필요할 수 있다고 계산했다.
Qwen3.5-9B의 추정 시간은 약 28~51시간이었다.
이 역시 실제 대규모 인터넷 감염 실험에서 측정한 시간은 아니다.
연구팀이 수행한 추론 환경 구성 작업과 모델 실행 속도를 바탕으로 계산한 추정치다.
즉 이런 시스템이 등장하더라도 초기에는 매우 느리게 확산될 가능성이 있다.
그러나 연구팀은 속도가 느리다는 이유만으로 위험이 사라지는 것은 아니라고 설명한다.
인터넷에는 오랫동안 켜져 있고 보안 업데이트가 제대로 이뤄지지 않는 장치가 많이 존재한다.
AI 모델이 느리더라도 며칠 동안 계속 작업하면서 새로운 장치에 적응하고 실행 환경을 구성할 수 있다면 장기적으로 확산이 가능할 수 있기 때문이다.
실패 경험을 다음 세대에 전달하는 실험
Anthropic은 작은 모델이 이전 실행의 경험을 활용해 성능을 개선할 수 있는지도 시험했다.
이를 위해 Memento라는 에이전트 실행 구조를 사용했다.
Memento는 하나의 에이전트가 오랫동안 작업하다가 잘못된 가설에 집착하는 문제를 줄이기 위해 설계됐다.
일정 시간이 지나면 현재 에이전트의 실행을 종료하고 새로운 에이전트를 시작한다.
새 에이전트에는 이전 에이전트가 작성한 코드와 작업 기록, 실패했던 방법을 요약한 메모를 전달한다.
이 방식은 모델의 가중치를 직접 수정하는 학습과 다르다.
모델 자체는 그대로 유지하면서 이전 실행에서 얻은 정보를 다음 실행에 전달하는 것이다.
연구팀은 Qwen3.5-9B에 이 방식을 적용했다.
첫 번째 세대의 추론 환경 구성 성공률은 약 45%였다.
이후 이전 세대의 작업 기록을 전달하면서 반복한 결과 후속 세대의 성공률은 61~84% 범위까지 증가했다.
이 결과는 AI 에이전트가 모델 가중치를 새로 학습하지 않더라도 실행 경험을 축적하고 다음 작업에 전달하는 방식으로 능력을 개선할 수 있음을 보여준다.
다만 이를 AI가 스스로 자신의 지능을 근본적으로 개선한 사례로 해석해서는 안 된다.
실제 개선된 것은 동일한 작업을 수행하는 과정에서 사용한 전략과 환경 설정, 오류 해결 방식이다.
방어 관점에서 살펴본 위험
Anthropic은 이런 자율 복제 시스템이 등장할 경우 기존 보안 시스템이 어떤 방식으로 대응할 수 있는지도 분석했다.
연구팀은 네트워크 트래픽이 중요한 탐지 수단이 될 수 있다고 설명한다.
AI 모델이 자신의 가중치를 다른 장치에 전달하려면 상당한 양의 데이터 전송이 필요하다.
또한 여러 저성능 장치가 하나의 모델을 분산 실행한다면 장치 사이에서 지속적인 통신이 발생할 수 있다.
일반적인 스마트 TV나 가전제품이 평소보다 훨씬 많은 데이터를 다른 장치와 주고받는다면 이상 행동으로 탐지할 수 있다.
특히 모델을 빠르게 복제하려 할수록 더 많은 네트워크 트래픽이 발생할 수 있다.
반대로 탐지를 피하기 위해 통신량을 줄이면 복제 속도가 느려질 가능성이 있다.
연구팀은 인터넷 서비스 제공업체가 감염된 장치의 네트워크 접근을 제한하고 사용자에게 정리 방법을 안내하는 방식도 중요한 대응 수단이 될 수 있다고 설명한다.
또한 기본 비밀번호를 사용하는 IoT 장치를 줄이고 제조사가 보안 업데이트를 제공하는 것이 중요하다고 강조한다.
이번 연구에서 가장 중요한 구분은 자율 복제가 가능한 AI 모델이 실제 인터넷에서 발견됐다는 발표가 아니라는 점이다.
Anthropic은 여러 구성요소를 실험했지만, 완전한 자율 복제 AI가 실제 인터넷에서 독립적으로 확산되는 사례를 입증하지는 않았다.
그럼에도 작은 AI 모델의 능력이 향상되고 일반 전자기기에 AI 연산 자원이 늘어나면서 AI 모델을 실행할 수 있는 하드웨어의 범위 자체가 빠르게 확대되고 있다는 사실을 보여준다.
AI 안전 연구의 대상이 거대한 데이터센터에서 실행되는 프런티어 모델뿐 아니라 스마트 TV와 가전제품처럼 상대적으로 보안이 약한 장치까지 확장될 수 있다는 점에서 주목할 만한 연구다.
📚 추천 글
ReplaySSM: Rethinking State Storage for Faster Hybrid-Model Decoding
- 저자: Ze-Wei Liou, Harris Nover, Amey Naik, Andrii Skliar, Igor Shovkun, Ido Shahaf, Tri Dao
- 발행: NVIDIA Technical Blog / Princeton Dao AI Lab
- 게시일: 2026-10-12
- 원문: NVIDIA — ReplaySSM: Rethinking State Storage for Faster Hybrid-Model Decoding
최근 언어모델은 모두 동일한 Transformer 구조를 사용하는 것은 아니다.
NVIDIA Nemotron 3, Qwen3.5~Qwen3.8, Kimi-K3와 GLM-5.3-Flash 등은 State Space Model(SSM)과 Attention을 함께 사용하는 하이브리드 구조를 채택하고 있다.
SSM은 긴 입력을 처리할 때 이전 정보를 고정된 크기의 내부 상태로 요약하는 방식이다.
일반적인 Transformer의 Attention에서는 입력이 길어질수록 이전 토큰의 정보를 저장하는 KV Cache가 커진다.
반면 SSM은 고정 크기의 상태를 유지할 수 있다는 장점이 있다.
그래서 긴 문장을 생성하는 상황에서도 메모리 사용량을 안정적으로 관리할 수 있을 것으로 기대된다.
하지만 실제 GPU 서버에서는 예상하지 못한 병목이 발생한다.
SSM은 새로운 토큰을 생성할 때마다 현재 상태를 읽고 수정한 뒤 다시 메모리에 기록해야 한다.
문제는 이 상태가 상당히 클 수 있다는 점이다.
예를 들어 NVIDIA Nemotron 3의 일부 SSM 계층에서는 하나의 시퀀스에 필요한 상태가 4MiB에 달한다.
모델이 토큰 하나를 생성할 때마다 이 상태를 반복해서 읽고 쓰면 GPU의 계산 능력보다 메모리 대역폭이 병목이 될 수 있다.
NVIDIA와 Princeton 연구팀은 이를 해결하기 위해 ReplaySSM을 개발했다.
핵심 아이디어는 이전 상태 전체를 매번 수정하는 대신 최근 입력을 작은 버퍼에 저장하고 필요할 때만 상태를 업데이트하는 것이다.
기존 방식에서는 토큰 하나를 생성할 때마다 전체 SSM 상태를 읽고 수정한 뒤 다시 저장했다.
ReplaySSM에서는 일정한 시점의 상태를 Checkpoint로 보관하고, 이후 들어온 입력을 별도의 버퍼에 기록한다.
새로운 토큰을 생성할 때는 Checkpoint와 버퍼에 저장된 입력을 함께 사용해 필요한 출력을 계산한다.
버퍼가 가득 차면 그동안의 변경사항을 한 번에 Checkpoint에 반영한다.
이렇게 하면 큰 상태를 매번 다시 쓰는 작업이 줄어든다.
연구팀은 16개 토큰을 하나의 단위로 묶어 처리하는 구성을 평가했다.
그 결과 GPU 메모리에서 상태를 읽고 쓰는 작업량이 크게 줄었다.
배치 크기 256의 평가에서는 SSM 처리 커널이 기존 대비 1.46~1.80배 빠르게 실행됐다.
실제 토큰 생성 단계 전체의 속도는 1.20~1.47배 개선됐다.
이 수치는 NVIDIA 연구팀이 특정 모델과 GPU 환경에서 측정한 결과다.
모든 모델이나 요청 크기에서 같은 성능 향상을 얻는다는 의미는 아니다.
특히 배치 크기가 1인 경우에는 이번 실험에서 의미 있는 속도 개선이 나타나지 않았다.
ReplaySSM의 또 다른 장점은 Speculative Decoding(추측 디코딩)과의 결합이다.
Speculative Decoding은 작은 모델이나 별도의 예측기가 여러 토큰을 미리 생성하고, 큰 모델이 이를 한 번에 검증하는 방식이다.
올바르게 예측한 토큰은 그대로 사용하고 잘못된 부분부터 다시 생성한다.
일반적인 Transformer에서는 미리 생성한 토큰 가운데 잘못된 부분을 KV Cache의 포인터를 조정하는 방식으로 비교적 쉽게 되돌릴 수 있다.
하지만 SSM은 이전 입력을 하나의 상태에 누적해서 반영하므로 특정 토큰 이전의 상태로 되돌리기가 어렵다.
ReplaySSM에서는 최근 입력을 별도 버퍼에 저장하므로 잘못된 예측 부분을 버리고 이전 상태로 복구하는 작업이 단순해진다.
연구팀은 1,200억 파라미터급 모델에서 이 방식을 시험했다.
배치 크기 512의 추측 디코딩 평가에서는 기존 vLLM 구현보다 1.85~2.10배 높은 처리량을 기록했다.
수치 정밀도 문제도 함께 다뤘다.
모델을 빠르게 실행하기 위해 내부 상태의 숫자 정밀도를 낮추면 메모리 사용량이 줄어들지만 계산 오차가 누적될 수 있다.
ReplaySSM은 실제 상태를 갱신하는 Checkpoint와 출력을 계산할 때 사용하는 상태를 서로 다른 정밀도로 관리한다.
예를 들어 상태 갱신은 FP32나 FP16처럼 상대적으로 높은 정밀도를 사용하고, 일반적인 출력 계산은 더 낮은 정밀도의 데이터를 사용할 수 있다.
이렇게 하면 낮은 정밀도에서 발생한 반올림 오차가 다음 상태 갱신에 계속 누적되는 문제를 줄일 수 있다.
연구팀의 GPQA-Diamond 평가에서는 네 모델 가운데 세 모델이 FP32 기준 정확도에서 약 2%포인트 이내의 차이를 유지했다.
다만 모든 모델에서 동일한 정확도가 유지된 것은 아니다.
특히 작은 Nemotron 모델에서는 상대적으로 큰 성능 차이가 나타났다.
이번 기술은 이미 일부 실제 모델 서빙 환경에 적용되고 있다.
NVIDIA에 따르면 GLM-5.3-Flash와 Kimi-K3에서 관련 기법이 사용되고 있으며, TensorRT-LLM, vLLM, SGLang, FlashInfer 등의 오픈소스 추론 시스템에도 구현돼 있다.
이번 글의 중요한 부분은 언어모델의 아키텍처가 바뀌면 실제 서버에서 발생하는 병목도 달라진다는 점을 보여준다는 것이다.
SSM은 이론적으로 긴 입력을 효율적으로 처리할 수 있지만, 실제 GPU에서는 상태를 반복해서 읽고 쓰는 비용이 문제가 될 수 있다.
ReplaySSM은 모델의 가중치를 더 크게 만들거나 새로운 학습을 진행하지 않고도 추론 과정에서 데이터를 저장하고 갱신하는 방법을 바꿔 처리량을 높이는 기술이다.
대규모 언어모델의 성능이 모델 구조뿐 아니라 GPU 메모리 관리와 추론 엔진의 구현 방식에도 크게 영향을 받는다는 점을 이해하기 좋은 글이다.
Agent Lightning v1.0: A 3,500-Line Lightweight Agentic RL Framework for Training Agents with Real Harnesses
- 저자: Zhiyuan He, Yuqing Yang
- 발행: Microsoft Research
- 게시일: 2026-10-07
- 원문: Microsoft Research — Agent Lightning v1.0
AI 에이전트의 능력을 강화학습으로 개선할 때 실제로 배포하는 에이전트와 학습 환경에서 사용하는 에이전트가 달라지는 문제를 다룬 기술 글이다.
최근 코딩 에이전트는 단순한 언어모델 하나로 구성되지 않는다.
모델은 파일을 읽거나 수정하고, 터미널을 실행하고, 테스트 결과를 확인하며, 다른 에이전트에게 일부 작업을 맡길 수 있다.
이런 행동을 관리하는 소프트웨어 계층을 Harness(하네스)라고 한다.
실제 제품에서는 하네스가 상당히 복잡해질 수 있다.
예를 들어 Codex나 Claude Code에는 도구 호출, 작업 상태 관리, 컨텍스트 압축, 오류 복구와 사용자 승인 같은 기능이 포함된다.
그런데 기존 강화학습 시스템은 이런 실제 하네스를 그대로 사용하기 어려운 경우가 많았다.
강화학습 프레임워크가 모델과 환경 사이의 상호작용을 직접 관리하도록 설계됐기 때문이다.
그래서 개발자는 실제 에이전트에서 사용하는 도구와 실행 절차를 학습 시스템 안에 다시 구현해야 했다.
이 과정은 시간과 비용이 많이 들고, 학습에 사용하는 에이전트와 실제 서비스에 배포하는 에이전트의 행동이 달라질 수 있다는 문제가 있다.
Microsoft Research는 이를 해결하기 위해 Harnessed Agentic RL이라는 학습 방식을 제안했다.
핵심은 실제 에이전트 하네스를 변경하지 않고 그대로 실행하면서 모델 호출을 강화학습 시스템에 연결하는 것이다.
모델 API 사이에 학습용 프록시 배치
Agent Lightning v1.0에서는 에이전트가 사용하는 모델 API 앞에 LLM Proxy(모델 요청을 중간에서 전달하고 기록하는 시스템)를 배치한다.
기존 에이전트는 평소와 같은 방식으로 모델을 호출한다.
그러나 실제 요청은 Agent Lightning의 프록시를 거친다.
프록시는 모델에 전달한 입력과 모델의 출력, 실행 결과를 기록한다.
이 기록을 강화학습에 필요한 데이터로 변환한다.
따라서 개발자는 기존 에이전트의 도구 호출 구조를 다시 구현하지 않고도 학습에 사용할 수 있다.
예를 들어 mini-SWE-agent나 OpenHands처럼 이미 만들어진 코딩 에이전트를 학습시키려면 해당 에이전트가 사용하는 모델 엔드포인트를 Agent Lightning으로 연결하면 된다.
하지만 여기서 새로운 문제가 발생한다.
실제 에이전트는 하나의 작업을 수행하면서 모델을 여러 번 호출할 수 있다.
중간에 컨텍스트를 요약하거나 다른 하위 에이전트를 호출할 수도 있다.
일반적인 강화학습 프레임워크는 하나의 연속된 실행 기록을 가정하는 경우가 많지만, 실제 하네스에서는 작업이 여러 조각으로 나뉠 수 있다.
Microsoft는 이를 해결하기 위해 학습 기록을 개별 모델 호출이 아니라 전체 작업 실행 단위인 Rollout에 맞춰 관리한다.
Rollout은 에이전트가 하나의 문제를 해결하기 위해 수행한 행동과 관찰, 최종 결과의 전체 과정이다.
학습 과정에서는 Rollout마다 다른 수의 모델 호출이 발생할 수 있다.
단순히 호출 횟수가 많은 작업에 더 많은 학습 가중치를 주면 실제 작업 성능과 관계없이 긴 작업이 과도하게 반영될 수 있다.
Agent Lightning은 이를 방지하기 위해 보상 계산과 손실값 정규화를 Rollout 수준에서 수행하도록 설계했다.
약 3,500줄의 코드로 학습 시스템 구성
Agent Lightning v1.0은 약 3,500줄의 코드로 구성된다.
Microsoft는 의도적으로 작고 이해하기 쉬운 구조를 유지했다고 설명한다.
시스템은 크게 세 부분으로 나뉜다.
API Gateway는 모델 호출을 받아 기록하고 실제 모델 서버에 전달한다.
Rollout Controller는 여러 에이전트가 학습 환경에서 실행되는 과정을 관리한다.
Customized Trainer는 수집한 데이터를 이용해 모델을 업데이트한다.
에이전트 실행에는 Kubernetes를 사용할 수 있다.
Kubernetes는 여러 서버에 작업을 배치하고 실행 상태를 관리하는 플랫폼이다.
이를 이용하면 수많은 에이전트를 서로 다른 환경에서 병렬로 실행할 수 있다.
외부 상용 샌드박스 서비스에 반드시 의존할 필요도 없다.
강화학습 중 GPU를 효율적으로 사용
실제 에이전트의 작업 시간은 일정하지 않다.
어떤 코딩 문제는 몇 초 만에 해결되지만 다른 문제는 여러 분 동안 테스트와 수정 과정을 반복할 수 있다.
기존 동기식 강화학습에서는 여러 에이전트의 작업이 모두 끝나야 다음 학습 단계로 이동하는 경우가 많았다.
따라서 일부 에이전트가 오래 걸리면 다른 GPU가 작업을 기다리면서 사용되지 않을 수 있다.
이를 해결하기 위해 Microsoft는 Collocated Async RL을 구현했다.
에이전트 실행과 모델 학습이 동일한 GPU 자원을 공유하도록 하는 방식이다.
충분한 Rollout이 수집되면 새로운 요청을 잠시 중단하고 모델을 업데이트한다.
업데이트가 끝나면 에이전트 실행을 다시 시작한다.
이렇게 하면 별도의 GPU 풀을 유지해야 하는 부담을 줄이면서도 동기식 학습의 대기시간을 줄일 수 있다.
Microsoft 자체 평가에서는 기존 동기식 강화학습보다 전체 처리 속도가 약 2배 개선됐다.
이는 특정 실험 환경에서 얻은 결과이며 모든 하네스와 GPU 구성에서 같은 향상이 보장되는 것은 아니다.
실제 코딩 에이전트 성능 개선
연구팀은 Qwen3.5-9B 모델과 mini-SWE-agent를 이용해 실제 강화학습을 진행했다.
약 6,000개의 학습 사례를 사용했으며 SWE-smith 기반의 학습 파이프라인을 구성했다.
평가에는 SWE-bench Verified가 사용됐다.
SWE-bench는 실제 GitHub 저장소의 소프트웨어 오류를 해결할 수 있는지 평가하는 벤치마크다.
학습 전 Qwen3.5-9B의 성공률은 41.8%였다.
Agent Lightning을 이용한 강화학습 이후에는 56.4%로 증가했다.
절대적으로 14.6%포인트 개선된 결과다.
이 수치는 Microsoft가 공개한 자체 연구 결과다.
모든 코딩 에이전트에서 6,000개의 학습 사례만으로 같은 수준의 성능 향상을 얻을 수 있다는 의미는 아니다.
이번 연구에서 중요한 부분은 모델을 학습시키기 위해 실제 에이전트의 실행 방식을 단순화하거나 다시 구현하지 않았다는 점이다.
앞으로 코딩 에이전트가 더 복잡해질수록 모델 자체뿐 아니라 실제 도구와 실행 환경을 포함한 전체 시스템에서 학습하는 방법이 중요해질 가능성이 있다.
Agent Lightning v1.0은 이런 학습 시스템을 상대적으로 작은 오픈소스 프레임워크로 구성하려는 시도다.
Deploy decision models with llama.cpp on Amazon SageMaker AI
- 저자: Jyothirmai Kottu, Dmitry Soldatkin, Daniel Quang, Daniel Wirjo
- 발행: AWS Artificial Intelligence Blog
- 게시일: 2026-10-12
- 원문: AWS — Deploy decision models with llama.cpp on Amazon SageMaker AI
AI 서비스에서 모든 요청에 자연어 답변이 필요한 것은 아니다.
예를 들어 고객 문의를 적절한 담당 부서로 전달하거나, 보안 경보의 위험도를 분류하고, 여러 AI 도구 가운데 다음에 실행할 도구를 선택하는 작업에서는 긴 문장보다 정해진 선택지 가운데 하나를 고르는 판단이 필요하다.
AWS는 이런 작업을 위한 Decision Model(판단 모델)을 기존 언어모델 실행 환경에 통합하는 방법을 소개했다.
일반적인 언어모델은 입력을 받은 뒤 출력 토큰을 하나씩 생성한다.
예를 들어 고객이 비밀번호 재설정 이메일을 받지 못한다고 설명하면 모델에게 해당 문제를 처리할 부서를 알려달라고 요청할 수 있다.
모델은 자연어로 계정 관리팀에 전달하라는 답변을 생성한다.
하지만 실제 프로그램이 필요로 하는 것은 긴 문장이 아니라 account_access 같은 정해진 값일 수 있다.
이런 경우 자연어를 생성하고 다시 프로그램에서 해석하는 과정은 불필요할 수 있다.
AWS는 이를 해결하기 위해 SemIf를 사용했다.
SemIf는 이전에 OpenJev라는 이름으로 알려졌던 도구로, 언어모델의 내부 계산 결과를 이용해 미리 정의된 선택지 각각의 확률을 계산한다.
개발자는 사용자 요청과 선택지를 전달한다.
모델은 입력을 이해한 뒤 각 선택지의 점수를 계산하고, 결과를 구조화된 데이터로 반환한다.
여기서 중요한 점은 자연어 답변을 생성하지 않아도 모델의 입력 처리 과정은 여전히 필요하다는 것이다.
모델이 사용자의 요청을 이해하려면 입력을 읽고 내부 계산을 수행해야 한다.
다만 그 이후 긴 문장을 생성하는 단계를 줄일 수 있다.
llama.cpp와 SageMaker의 결합
AWS는 오픈소스 추론 엔진 llama.cpp를 사용했다.
llama.cpp는 다양한 언어모델을 CPU나 GPU에서 실행할 수 있도록 하는 프로젝트다.
특히 모델을 양자화해 비교적 적은 메모리로 실행할 수 있다는 장점이 있다.
Quantization(양자화)은 모델이 사용하는 숫자의 정밀도를 낮춰 메모리 사용량과 계산 비용을 줄이는 기술이다.
AWS는 SageMaker AI용 llama.cpp 컨테이너를 이용해 모델을 배포하는 방법을 설명했다.
일반적인 텍스트 생성에는 OpenAI 호환 Chat Completions API를 사용한다.
판단 작업에는 SemIf를 추가한 별도의 실행 이미지를 사용한다.
개발자는 요청할 때 사용자의 현재 상태와 질문, 선택지를 전달한다.
모델은 각 선택지의 확률과 내부 점수인 Logit을 반환한다.
Logit은 확률로 변환되기 전 모델이 계산한 원시 점수를 의미한다.
이를 이용하면 애플리케이션이 단순히 가장 높은 점수를 받은 선택지를 실행하는 대신 신뢰도 기준이나 추가 검증 절차를 적용할 수 있다.
다만 모델이 반환한 확률을 실제 정답 확률로 그대로 받아들여서는 안 된다.
확률이 제대로 보정돼 있는지 별도의 평가 데이터로 확인해야 한다.
CPU와 GPU의 성능 차이
AWS는 Qwen3.5-4B 모델을 이용해 CPU와 GPU 환경을 비교했다.
평가에는 231개의 JevBench 작업이 사용됐다.
CPU 환경에서는 정답률 77.5%, 중앙값 지연시간 1.715초를 기록했다.
GPU 환경에서는 정답률 77.9%, 중앙값 지연시간 0.352초를 기록했다.
즉 GPU 환경의 중앙값 처리 속도가 약 4.9배 빨랐다.
지연시간이 긴 요청까지 고려하는 p95 기준에서는 GPU가 약 32.2배 빨랐다.
p95 지연시간은 전체 요청 가운데 95%가 해당 시간 안에 완료된다는 의미다.
CPU에서는 p95가 19.291초였지만 GPU에서는 0.599초였다.
이 수치는 AWS가 특정 인스턴스와 모델 설정에서 측정한 결과다.
GPU를 사용하면 모든 판단 모델의 성능이 동일한 비율로 개선된다는 의미는 아니다.
또한 GPU 환경의 정답률이 약간 높게 나타났지만 AWS는 이를 하드웨어의 우수한 모델 판단 능력 때문이라고 해석하지 않았다.
서로 다른 llama.cpp 실행 환경에서 일부 계산과 예측이 달라지면서 발생한 차이라고 설명했다.
이 글에서 특히 중요한 부분은 AI 모델이 판단을 지원하더라도 실제 권한 검사와 업무 규칙은 모델 바깥에서 처리해야 한다는 점이다.
예를 들어 모델이 보안 경보를 낮은 위험도로 분류했다고 해서 실제 보안 정책을 자동으로 해제하도록 만들 필요는 없다.
모델의 판단을 일반적인 프로그램 코드에서 검증하고, 필요한 경우 사람의 승인을 거치도록 설계할 수 있다.
AI 에이전트가 점점 더 많은 업무를 수행하면서 모든 판단을 긴 자연어로 생성하는 대신 작은 전문 모델이 구조화된 점수와 선택지를 반환하는 방식도 중요한 설계 대안이 되고 있다.
LightOnOCR-3: High-Performance OCR and Layout Extraction in One Model
- 저자: Said Taghadouini, Adrien Cavaillès, Baptiste Aubertin 외 LightOn 연구진
- 발행: LightOn / Hugging Face
- 게시일: 2026-10-08
- 원문: LightOn — LightOnOCR-3: High-Performance OCR and Layout Extraction in One Model
생성형 AI 서비스에서 PDF와 문서를 활용하려면 먼저 해당 문서의 내용을 정확하게 읽어야 한다.
그런데 실제 문서는 단순한 텍스트 파일과 다르다.
하나의 PDF 페이지에 여러 개의 열이 있거나, 표와 그래프가 포함될 수 있고, 이미지 안에 중요한 설명이 들어 있을 수도 있다.
이런 문서를 AI에게 전달하려면 텍스트뿐 아니라 문서의 구조와 정보 사이의 관계까지 추출해야 한다.
LightOn이 공개한 LightOnOCR-3는 이 작업을 하나의 모델로 수행하려는 새로운 OCR 모델 제품군이다.
OCR(Optical Character Recognition)은 이미지나 스캔 문서 안의 글자를 컴퓨터가 처리할 수 있는 텍스트로 변환하는 기술이다.
전통적인 OCR은 주로 글자를 정확하게 인식하는 데 집중했다.
하지만 최근 AI 서비스에서는 문서의 의미를 이해하기 위해 추가적인 정보가 필요하다.
예를 들어 두 개의 열로 구성된 논문을 읽을 때 OCR이 왼쪽 열과 오른쪽 열의 문장을 잘못 섞으면 실제 문서의 의미가 달라질 수 있다.
표를 단순한 텍스트로 변환하면 어떤 숫자가 어떤 행과 열에 속하는지 알기 어려워질 수 있다.
그래프 역시 그림 안에 포함된 숫자와 추세를 별도로 추출해야 할 수 있다.
이런 문제를 해결하기 위해 기존에는 OCR, 문서 레이아웃 분석, 표 추출과 이미지 설명 모델을 여러 단계로 연결하는 방식이 사용됐다.
LightOnOCR-3는 텍스트 인식과 문서 구조 분석을 하나의 모델로 통합한다.
세 가지 모델 크기
LightOnOCR-3는 세 가지 크기로 공개됐다.
- LightOnOCR-3-0.8B: 약 8억 파라미터
- LightOnOCR-3-1B: 약 10억 파라미터
- LightOnOCR-3-4B: 약 40억 파라미터
1B 모델은 이전 세대의 구조를 유지한다.
반면 0.8B와 4B 모델은 Qwen3.5 비전·언어 모델 구조를 기반으로 한다.
Vision-Language Model(VLM)은 이미지와 텍스트를 함께 이해하도록 학습된 모델이다.
이 구조를 사용하면 단순한 글자 인식뿐 아니라 문서 안의 그림과 표, 시각적인 배치까지 분석할 수 있다.
세 모델 모두 일반적인 텍스트 추출 모드와 문서 구조를 분석하는 Grounding 모드를 지원한다.
Grounding 모드에서는 각 문서 영역의 종류와 위치 정보를 함께 반환한다.
예를 들어 제목, 본문, 표, 이미지와 그래프를 구분하고 해당 영역이 페이지의 어느 위치에 있는지 표시한다.
위치는 Bounding Box(바운딩 박스)로 표현된다.
Bounding Box는 특정 물체나 문서 영역을 둘러싸는 사각형의 좌표다.
LightOnOCR-3는 좌표를 0~1000 범위로 정규화해 반환한다.
덕분에 원본 이미지의 실제 크기가 달라도 같은 방식으로 위치 정보를 표현할 수 있다.
그래프에서는 데이터 포인트를 추출해 표 형태로 반환할 수도 있다.
즉 PDF를 단순히 문자열로 바꾸는 것이 아니라 문서의 구조와 데이터까지 함께 추출하려는 접근이다.
OCR 성능과 실제 한계
LightOn은 여러 공개 문서 분석 벤치마크를 이용해 성능을 평가했다.
대표적인 olmOCR-Bench에서 4B 모델은 전체 점수 86.3점을 기록했다.
같은 평가에서 약 351억 파라미터 규모의 Infinity Parser Pro는 87.6점이었다.
즉 LightOnOCR-3-4B는 훨씬 작은 모델이지만 비슷한 수준의 전체 평가 점수를 기록했다.
0.8B 모델도 85.5점을 기록했다.
하지만 모델 크기가 작아졌다고 모든 문서 유형에서 성능이 유지되는 것은 아니다.
예를 들어 오래된 스캔 문서나 머리글·바닥글 처리에서는 다른 모델이 더 좋은 결과를 기록했다.
LightOn은 이런 차이를 숨기지 않고 문서 유형별 점수를 공개했다.
다른 벤치마크인 ParseBench에서는 4B 모델이 75.1점, 0.8B 모델이 74.6점을 기록했다.
비교 대상인 Infinity Parser Pro는 74.3점이었다.
4B 모델은 특히 그래프 데이터 추출과 문서의 의미적 구조를 유지하는 작업에서 높은 성능을 보였다.
다만 이 수치들은 LightOn이 자체 실행한 비교 평가 결과다.
실제 기업의 모든 문서 유형에서 동일한 성능을 보장하는 것은 아니다.
출력 형식도 성능에 영향을 준다
LightOn은 문서 분석 모델에서 정확도뿐 아니라 출력 형식이 사용하는 토큰 수도 중요하다고 설명한다.
문서의 모든 영역을 JSON이나 HTML로 상세하게 표현하면 구조를 유지하기는 쉽다.
하지만 실제 문서 내용보다 형식을 표현하는 문자열이 상당히 많아질 수 있다.
언어모델은 이런 문자열도 토큰으로 처리한다.
따라서 같은 문서를 분석하더라도 출력 형식에 따라 처리 시간과 비용이 달라질 수 있다.
LightOnOCR-3는 비교적 간결한 영역 표시 문법을 사용한다.
문서 영역의 종류와 좌표를 짧은 기호로 표현하고 필요한 내용만 이어서 출력하는 방식이다.
LightOn의 자체 평가에서 일부 경쟁 모델보다 출력 토큰 수가 약 9~14% 적었다.
이 차이는 특히 많은 PDF를 처리하는 서비스에서 중요할 수 있다.
문서 한 페이지에서 절약되는 토큰 수가 작더라도 수백만 페이지를 처리한다면 전체 추론 비용에 영향을 줄 수 있기 때문이다.
모델 학습과 공개 범위
LightOnOCR-3는 일반적인 문서 인식 데이터뿐 아니라 문서 영역의 위치와 이미지 설명, 그래프 데이터를 포함한 학습 자료를 사용했다.
연구팀은 정답이 명확한 데이터로 모델을 먼저 학습시키는 SFT(Supervised Fine-Tuning, 지도 미세조정)를 수행했다.
이후 일부 작업에서는 강화학습도 활용했다.
강화학습은 모델이 생성한 결과를 평가하고 그 결과에 따라 행동을 개선하는 방식이다.
특히 문서의 위치 정보나 표 구조처럼 결과를 비교적 명확하게 평가할 수 있는 작업에 활용할 수 있다.
LightOn은 모델 가중치와 평가용 코드, 후처리 도구를 공개했다.
라이선스는 Apache 2.0이다.
연구 목적뿐 아니라 상업적인 서비스에서도 사용할 수 있도록 공개된 것이다.
이번 글은 단순히 새로운 OCR 모델의 점수를 소개하는 데 그치지 않는다.
문서를 AI가 활용할 수 있는 형태로 변환하는 과정에서 텍스트 정확도, 시각적 구조, 출력 형식과 추론 비용을 함께 고려해야 한다는 점을 설명한다.
RAG나 문서 분석 에이전트를 개발할 때 모델이 잘못된 답변을 생성하는 원인이 언어모델 자체가 아니라 처음 문서를 읽고 구조화하는 단계의 오류일 수도 있다는 점을 이해하기 좋은 자료다.