AI 데일리 브리핑 — 2026-10-26

기준 시점: 2026-10-26 06:00 KST (Asia/Seoul)
AI 동향 조사 범위: 2026-10-25 06:00 ~ 2026-10-26 06:00 KST
추천 글 범위: 2026-10-19 06:00 ~ 2026-10-26 06:00 KST

---

1️⃣ 주요 모델·연구

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

---

2️⃣ AI 제품·서비스

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

---

3️⃣ 개발 도구·에이전트

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

---

4️⃣ 산업·정책·안전

이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.

---

📚 추천 글

TokenGate: Adapting LLMs for Fast and Memory-Efficient Prefill with Learned Token Pruning

• 저자: Liana Patel, Rishabh Ranjan, Ion Stoica, Matei Zaharia, Carlos Guestrin
• 발행: Stanford University / UC Berkeley / arXiv
• 게시일: 2026-10-19
• 원문: arXiv — TokenGate: Adapting LLMs for Fast and Memory-Efficient Prefill with Learned Token Pruning
• 관련 원문: GitHub — TokenGate

---

대형 언어모델이 긴 문서를 분석할 때 가장 많은 계산 자원을 소비하는 부분은 어디일까?

일반적으로 AI의 응답 속도를 생각하면 답변이 화면에 한 글자씩 나타나는 속도에 주목하기 쉽다.

하지만 실제 언어모델의 추론은 크게 두 단계로 나뉜다.

첫 번째는 Prefill(입력 처리 단계)이다.

모델이 사용자가 전달한 질문과 문서, 이전 대화 기록을 읽고 내부 계산을 수행하는 과정이다.

두 번째는 Decode(출력 생성 단계)다.

입력을 처리한 뒤 다음 토큰을 하나씩 생성하면서 답변을 완성하는 과정이다.

여기서 Token(토큰)은 언어모델이 텍스트를 처리하는 기본 단위다.

예를 들어 사용자가 수백 개의 파일로 구성된 프로젝트 전체를 AI 코딩 에이전트에 전달했다고 가정해 보자.

모델은 답변을 생성하기 전에 수많은 코드와 문서를 처리해야 한다.

이 과정에서 상당한 시간이 발생할 수 있다.

사용자에게는 모델이 아무런 답변도 생성하지 않는 것처럼 보이지만, 실제로는 입력 전체를 계산하고 있는 것이다.

이 논문은 이러한 문제를 해결하기 위해 모델이 긴 입력의 모든 부분을 끝까지 계산하지 않아도 되도록 만드는 기술을 제안한다.

사람처럼 중요한 정보만 골라 읽기

사람이 수백 페이지짜리 문서를 읽을 때 모든 문장을 동일한 수준으로 분석하지는 않는다.

먼저 문서의 구조를 살펴보고 중요한 부분을 찾는다.

이후 실제 질문과 관련된 내용을 자세히 읽는다.

반면 일반적인 Transformer 기반 언어모델은 입력에 포함된 토큰을 여러 신경망 계층에 걸쳐 처리한다.

Transformer(트랜스포머)는 입력의 서로 다른 부분 사이의 관계를 계산하는 Attention 구조를 중심으로 설계된 신경망 아키텍처다.

Attention(어텐션)은 현재 정보를 처리할 때 입력의 다른 부분을 얼마나 참고해야 하는지 계산하는 기술이다.

예를 들어 코드의 특정 함수가 다른 파일에 정의된 함수를 호출한다면 두 부분 사이의 관계를 계산할 수 있다.

문제는 입력이 길어질수록 이런 계산에 필요한 자원이 크게 증가한다는 것이다.

일반적인 Self-Attention에서는 입력 길이가 증가할 때 토큰 사이의 관계를 계산하는 비용이 대략 입력 길이의 제곱에 비례해 증가할 수 있다.

또한 각 계층의 중간 정보를 저장해야 하므로 메모리 사용량도 증가한다.

연구팀은 이를 해결하기 위해 TokenGate라는 작은 신경망 구성요소를 추가했다.

TokenGate는 입력 토큰마다 현재 작업에 얼마나 중요한지 점수를 계산한다.

이후 상대적으로 중요한 토큰만 선택해 나머지 모델 계층에서 집중적으로 처리하도록 한다.

이런 방법을 Token Pruning(토큰 가지치기)이라고 한다.

중요한 토큰을 선택하는 방법 자체를 학습

토큰 가지치기에서 가장 어려운 문제는 어떤 토큰이 중요한지 판단하는 것이다.

예를 들어 사용자가 긴 문서에서 특정한 날짜를 찾으라고 요청했다고 가정해 보자.

해당 날짜가 포함된 문장은 매우 중요하다.

반면 문서의 전체적인 배경 설명은 상대적으로 중요하지 않을 수 있다.

하지만 사용자가 문서의 핵심 논리를 요약하라고 요청했다면 중요한 부분이 달라진다.

따라서 모든 작업에 동일한 토큰 선택 규칙을 적용하는 것은 적절하지 않다.

TokenGate는 이러한 판단 기준을 고정된 규칙으로 작성하지 않는다.

대신 모델이 학습 과정에서 중요한 토큰을 선택하는 방법을 익히도록 설계됐다.

여기에는 Top-K Selection이라는 방법이 사용된다.

Top-K는 점수가 가장 높은 K개의 항목만 선택하는 방식이다.

예를 들어 1만 개의 토큰 가운데 중요한 1,000개를 유지하도록 지정할 수 있다.

하지만 일반적인 Top-K 연산은 학습 과정에서 문제가 발생할 수 있다.

모델이 특정 토큰을 선택하거나 제외하는 결정은 불연속적으로 이뤄지기 때문이다.

신경망은 일반적으로 출력의 작은 변화가 학습 파라미터에 어떤 영향을 주는지 계산하는 Gradient(기울기)를 이용해 학습한다.

선택하거나 제외하는 과정이 불연속적이면 기울기를 계산하기 어려워질 수 있다.

연구팀은 이를 해결하기 위해 Token-Gated Attention을 개발했다.

선택된 토큰의 중요도 점수를 Attention 계산에 직접 반영하는 방식이다.

이렇게 하면 Top-K로 토큰을 선택하면서도 중요도 점수를 계산하는 신경망이 학습 신호를 받을 수 있다.

구조적으로는 MoE 모델의 전문가 선택 방식과 유사한 아이디어를 사용한다.

MoE(Mixture of Experts)는 여러 전문 신경망 가운데 입력에 필요한 일부만 선택적으로 사용하는 아키텍처다.

MoE가 활성화할 모델 파라미터를 선택한다면 TokenGate는 계산에 집중할 입력 토큰을 선택한다는 차이가 있다.

기존 모델을 처음부터 다시 학습하지 않아도 된다

TokenGate의 장점 가운데 하나는 기존 언어모델에 추가할 수 있도록 설계됐다는 것이다.

연구팀은 Qwen3와 Qwen3.5 계열의 모델을 이용해 실험했다.

이때 모델 전체를 처음부터 새롭게 사전학습하지 않았다.

대신 TokenGate 구성요소와 일부 모델 파라미터를 추가 학습했다.

여기에는 LoRA(Low-Rank Adaptation)라는 방법이 사용됐다.

LoRA는 대형 모델의 모든 파라미터를 수정하는 대신 상대적으로 적은 추가 파라미터를 학습하는 기술이다.

전체 모델을 다시 학습시키는 것보다 필요한 계산 자원을 줄일 수 있다.

연구팀은 TokenGate의 학습 비용이 일반적인 효율적 미세조정과 비슷한 수준이라고 설명했다.

따라서 특정한 업무에서 긴 입력을 자주 처리한다면 기존 모델을 유지하면서 입력 처리 효율만 개선하는 방안을 검토할 수 있다.

다만 모델에 TokenGate를 추가한다고 해서 별도의 학습이나 설정 없이 모든 작업이 자동으로 빨라지는 것은 아니다.

최대 11.3배 빠른 첫 토큰 생성

연구팀은 여러 종류의 작업에서 TokenGate를 평가했다.

대상에는 코드 자동완성과 긴 문서 요약, 여러 문서에 걸친 질문·답변, 의학 문서의 정보 추출 등이 포함됐다.

또한 긴 입력에 특정한 정보를 숨겨 놓고 모델이 이를 찾아낼 수 있는지 평가하는 작업도 사용했다.

이를 Needle-in-a-Haystack(건초더미 속 바늘 찾기) 평가라고 한다.

매우 긴 문서 가운데 필요한 정보 하나를 얼마나 정확하게 찾아내는지 측정하는 방법이다.

연구팀이 공개한 주요 결과는 다음과 같다.

TTFT(Time to First Token)는 요청을 보낸 뒤 첫 번째 출력 토큰이 생성되기까지 걸리는 시간이다.

사용자가 AI의 응답을 기다릴 때 체감하는 초기 지연시간과 밀접하게 연결된다.

연구팀은 평가한 작업에서 기존 모델의 정확도를 유지하면서 이러한 성능 개선을 기록했다고 밝혔다.

하지만 모든 언어모델과 모든 입력 길이에서 최대 11.3배의 속도 향상이 발생한다는 의미는 아니다.

개선 폭은 모델 구조와 입력 길이, 선택하는 토큰 수, 실제 작업의 특성에 따라 달라진다.

또한 TokenGate가 개선하는 주요 대상은 입력 처리 단계다.

출력 토큰을 하나씩 생성하는 모든 계산이 같은 비율로 빨라지는 것은 아니다.

따라서 실제 전체 작업의 속도 향상은 입력 처리와 출력 생성에 각각 얼마나 많은 시간이 필요한지에 따라 달라진다.

AI 코딩 에이전트에서 생각해 볼 문제

이 연구는 긴 코드베이스를 반복해서 읽는 AI 코딩 에이전트와 연결된다.

예를 들어 개발자가 특정 컴포넌트의 오류를 수정하도록 에이전트에 요청했다고 가정해 보자.

저장소에는 수백 개의 파일이 있을 수 있지만 실제 수정에 필요한 파일은 일부일 수 있다.

기존 RAG 시스템은 검색 단계에서 관련 파일을 선택한다.

RAG(Retrieval-Augmented Generation)는 외부 문서나 데이터에서 관련 정보를 검색해 언어모델의 입력에 추가하는 방식이다.

반면 TokenGate는 모델에 전달된 입력을 처리하는 과정에서 중요한 토큰을 선택한다.

두 기술은 서로 대체하는 관계가 아니다.

RAG가 어떤 문서를 입력에 포함할지 결정한다면 TokenGate는 이미 선택된 입력의 어느 부분에 계산을 집중할지 결정한다.

따라서 두 방식을 결합하는 접근도 생각할 수 있다.

다만 현재 연구 결과만으로 모든 코딩 에이전트에서 같은 개선이 나타난다고 볼 수는 없다.

특히 코드 수정에 필요한 작은 조건문이나 중요한 예외 처리 코드가 제거된다면 결과의 정확도가 떨어질 수 있다.

이번 연구는 언어모델의 성능을 개선하는 방법이 모델을 더 크게 만드는 것에만 있지 않다는 점을 보여준다.

기존 모델이 수행하는 계산 가운데 실제 작업에 필요한 부분을 선택하는 기술도 긴 문서와 코드베이스를 처리하는 AI 시스템에서 중요한 연구 방향이 될 수 있다.

---

How Commerce.com and Cloudflare are getting storefronts ready for AI agents

• 저자: Jenny Lea, Max Brosnahan, Matthew Conroy
• 발행: Cloudflare Engineering
• 게시일: 2026-10-21
• 원문: Cloudflare — How Commerce.com and Cloudflare are getting storefronts ready for AI agents

---

AI 에이전트가 온라인 쇼핑몰에서 상품을 검색하고 장바구니에 추가하려면 어떤 기술이 필요할까?

일반적인 웹사이트는 사람이 화면을 보고 조작하도록 만들어졌다.

사용자는 상품 목록을 확인하고 원하는 상품을 선택한 뒤 버튼을 클릭한다.

하지만 AI 에이전트가 같은 작업을 수행하려면 별도의 문제가 발생한다.

예를 들어 AI가 상품을 찾기 위해 웹페이지의 HTML을 분석할 수 있다.

HTML(HyperText Markup Language)은 웹페이지의 구조와 내용을 표현하는 언어다.

AI는 HTML을 분석해 상품 목록과 버튼, 입력 필드를 찾을 수 있다.

하지만 웹사이트마다 구조가 다르다.

또한 쇼핑몰 운영자가 디자인을 변경하면 이전에 찾았던 버튼의 위치나 구조가 달라질 수 있다.

특히 쿠키 동의 창과 상품 옵션 선택, 장바구니 업데이트 같은 과정이 복잡해지면 에이전트가 예상과 다른 행동을 수행할 수 있다.

Cloudflare와 Commerce.com은 이를 해결하기 위해 AI 에이전트가 웹사이트의 기능을 직접 호출할 수 있는 구조를 구축했다.

브라우저 안에서 사용하는 WebMCP

이번 사례의 핵심 기술은 WebMCP다.

WebMCP는 웹페이지가 AI 에이전트에게 자신이 제공하는 기능을 구조화된 도구 형태로 노출하도록 하는 실험적인 브라우저 기술이다.

일반적인 AI 에이전트는 상품 검색 버튼이 어디에 있는지 화면이나 HTML에서 찾아야 한다.

반면 WebMCP를 지원하는 사이트에서는 상품 검색 기능 자체를 도구로 제공할 수 있다.

예를 들어 사용자가 특정한 가격 이하의 방수 러닝화를 찾아 달라고 요청했다고 가정해 보자.

기존 방식에서는 에이전트가 검색창을 찾아 검색어를 입력한다.

이후 가격 필터를 선택하고 상품 목록을 확인한다.

원하는 상품을 찾으면 장바구니 버튼을 클릭한다.

WebMCP에서는 이 과정을 다음과 같은 구조화된 도구로 처리할 수 있다.

• search_products: 조건에 맞는 상품 검색
• add_to_cart: 지정한 상품을 장바구니에 추가

에이전트는 웹사이트의 화면 구조를 추측하는 대신 해당 도구에 필요한 정보를 전달한다.

이를 통해 화면이 변경되더라도 도구 인터페이스가 유지되는 한 동일한 기능을 사용할 수 있다.

하지만 WebMCP가 모든 브라우저에서 정식 지원되는 표준은 아니다.

이번 글이 공개된 시점에는 실험적인 제안 단계였으며, Chrome의 실험 기능과 Origin Trial, 일부 에이전트 브라우저와 개발 환경에서 사용할 수 있었다.

Origin Trial은 웹 플랫폼의 새로운 기능을 일부 웹사이트에서 시험적으로 제공하도록 하는 제도다.

따라서 일반적인 웹사이트에서 WebMCP를 사용한다고 해서 모든 브라우저의 모든 AI 에이전트가 즉시 해당 기능을 호출할 수 있는 것은 아니다.

약 10만 개 쇼핑몰에 기능을 적용하는 문제

Commerce.com은 약 10만 개의 도메인을 운영하는 전자상거래 플랫폼이다.

여러 판매자가 이 플랫폼을 이용해 자신만의 쇼핑몰을 운영한다.

Cloudflare는 Commerce.com이 운영하는 쇼핑몰에 WebMCP를 적용할 수 있도록 지원했다.

여기서 흥미로운 부분은 모든 쇼핑몰 운영자가 직접 코드를 수정하도록 요구하지 않았다는 점이다.

Cloudflare는 네트워크의 Edge(엣지)에서 필요한 스크립트를 웹페이지에 추가하도록 설계했다.

엣지는 사용자와 가까운 네트워크 위치에서 요청과 응답을 처리하는 인프라를 의미한다.

예를 들어 사용자가 쇼핑몰에 접속하면 Cloudflare의 서버가 웹페이지를 전달하기 전에 작은 JavaScript 모듈을 추가할 수 있다.

이 모듈은 해당 쇼핑몰의 WebMCP 도구를 브라우저에서 사용할 수 있도록 연결한다.

이렇게 하면 쇼핑몰 운영자가 개별적으로 프런트엔드 코드를 변경하지 않아도 AI 에이전트용 기능을 제공할 수 있다.

다만 플랫폼 전체에 기능을 적용하는 과정에서는 새로운 문제가 발생했다.

하나의 플랫폼 안에서도 판매자별 선택권이 필요

Commerce.com에는 서로 다른 판매자가 존재한다.

일부 판매자는 AI 에이전트가 자신의 쇼핑몰을 이용하도록 허용하고 싶어 할 수 있다.

반면 다른 판매자는 아직 관련 기능을 사용할 준비가 되지 않았거나 정책적인 이유로 사용하지 않으려 할 수 있다.

그런데 기존 Cloudflare의 WebMCP 기능은 하나의 도메인 영역을 기준으로 켜거나 끄도록 설계돼 있었다.

Commerce.com처럼 수많은 판매자가 하나의 플랫폼에서 운영되는 환경에서는 이 방식이 충분하지 않았다.

Cloudflare는 이를 해결하기 위해 판매자별 Opt-out(사용 거부) 기능을 추가했다.

쇼핑몰 운영자는 관리 화면에서 WebMCP 사용을 거부할 수 있다.

Cloudflare는 해당 판매자의 도메인에 저장된 메타데이터를 확인한다.

Metadata(메타데이터)는 데이터나 시스템에 관한 설명 정보를 의미한다.

해당 판매자가 사용을 거부했다면 Cloudflare는 WebMCP 스크립트를 추가하지 않는다.

이 결정은 사용자의 요청을 처리하는 엣지에서 이뤄진다.

따라서 판매자별 설정을 확인하기 위해 별도의 원격 서버를 계속 호출할 필요가 없다.

또한 WebMCP를 비활성화한 쇼핑몰에는 관련 스크립트가 추가되지 않는다.

이는 단순한 기능 구현보다 플랫폼이 제공하는 공통 기능과 개별 판매자의 통제권을 함께 유지하는 설계라는 점에서 중요하다.

서버 MCP와 브라우저 WebMCP의 역할 분리

이번 글에서는 WebMCP와 서버 측 MCP의 차이도 설명한다.

MCP(Model Context Protocol)는 AI 에이전트가 외부 프로그램과 데이터를 호출할 수 있도록 하는 통신 규격이다.

서버 측 MCP에서는 에이전트가 외부 서버의 도구에 직접 연결할 수 있다.

예를 들어 AI 쇼핑 비서가 여러 쇼핑몰의 상품을 검색하는 작업에 사용할 수 있다.

반면 WebMCP는 사용자가 실제로 방문한 웹사이트의 브라우저 환경에서 도구를 제공한다.

Commerce.com은 두 방식을 함께 사용한다.

서버 측에는 실제 상품 검색과 장바구니 처리를 담당하는 MCP 서버가 존재한다.

브라우저의 WebMCP는 이 서버가 제공하는 기능을 사용자의 현재 쇼핑 세션에 연결한다.

여기서 Session(세션)은 사용자가 특정 웹사이트를 이용하는 동안 유지되는 로그인 상태나 장바구니 등의 정보를 의미한다.

이번 구조의 장점은 AI가 사용자의 실제 브라우저 세션을 활용한다는 점이다.

예를 들어 사용자가 이미 장바구니에 넣은 상품이 있다면 AI 에이전트도 같은 장바구니를 사용할 수 있다.

별도의 제3자 서비스에 사용자의 인증정보를 전달할 필요가 없도록 설계됐다.

또한 최종 결제는 판매자의 쇼핑몰에서 사용자가 직접 진행하도록 구성됐다.

AI 에이전트가 상품을 검색하고 장바구니에 추가하는 작업을 돕지만, 사용자의 결제정보와 최종 구매 결정은 기존 쇼핑몰의 통제 아래 유지하는 방식이다.

실제 통합 과정에서 발견한 문제

Cloudflare는 Commerce.com과의 통합 과정에서 발견한 실제 문제도 공개했다.

첫 번째는 MCP 서버의 주소다.

Cloudflare의 초기 구현은 MCP 서버가 /mcp 경로에 존재한다고 가정했다.

하지만 Commerce.com은 /api/mcp 경로를 사용했다.

따라서 Cloudflare는 MCP 서버의 경로를 설정할 수 있도록 기능을 수정했다.

이 사례는 작은 구현 차이처럼 보이지만 실제 플랫폼 통합에서는 중요하다.

여러 기업이 서로 다른 방식으로 서버를 구성하고 있기 때문이다.

두 번째는 장애 상황에 대한 처리다.

MCP 서버에 연결할 수 없거나 사용자의 브라우저가 WebMCP를 지원하지 않을 수 있다.

이런 경우 AI 에이전트용 기능에 문제가 발생했다고 해서 일반 사용자의 쇼핑까지 중단돼서는 안 된다.

Cloudflare는 이런 상황에서 WebMCP 연결 스크립트가 정상적으로 종료되도록 설계했다.

기존 웹사이트의 화면과 일반적인 쇼핑 기능은 그대로 유지된다.

이를 Graceful Degradation(점진적 기능 저하)이라고 한다.

일부 기능에 문제가 발생하더라도 서비스 전체가 중단되지 않도록 만드는 설계 원칙이다.

AI 에이전트를 위한 웹사이트는 어떻게 달라질까?

이번 글에서 중요한 변화는 AI 에이전트가 웹사이트를 이용하는 방식이다.

지금까지 많은 AI 에이전트는 사람이 사용하는 화면을 분석하고 버튼을 클릭하는 방법으로 작업을 수행해 왔다.

하지만 이런 방식은 화면 구조에 크게 의존한다.

반면 WebMCP는 웹사이트가 AI에게 사용할 수 있는 기능을 명시적으로 제공하도록 한다.

이는 사람이 사용하는 웹 UI와 AI 에이전트가 사용하는 인터페이스를 분리하는 접근이다.

다만 모든 작업을 도구 호출로 대체해야 하는 것은 아니다.

상품의 디자인과 색상처럼 시각적인 판단이 필요한 작업에서는 실제 이미지를 분석하는 능력이 필요할 수 있다.

또한 결제와 개인정보 처리처럼 민감한 행동은 사용자 승인과 접근권한 검사가 필요하다.

이번 사례는 AI 에이전트 시대의 웹 개발에서 웹사이트가 사람에게 어떤 화면을 보여줄 것인가뿐 아니라 외부 AI 에이전트에게 어떤 기능을 안전하게 제공할 것인가도 중요한 설계 문제가 될 수 있음을 보여준다.

특히 프런트엔드와 전자상거래 서비스를 개발하는 사람에게 참고할 만한 기술 자료다.

---

A curriculum for post-training agents

• 저자: Ben Burtenshaw, Sergio Paniego, Merve Noyan
• 발행: Hugging Face
• 게시일: 2026-10-20
• 원문: Hugging Face — A curriculum for post-training agents

---

최근 AI 에이전트는 단순히 질문에 답하는 것을 넘어 실제 업무를 수행하고 있다.

예를 들어 코딩 에이전트는 파일을 읽고 코드를 수정한다.

이후 테스트를 실행하고 오류가 발견되면 다시 수정한다.

그런데 이런 복잡한 행동을 수행하도록 모델을 학습시키려면 어떤 방법을 사용해야 할까?

이 글은 Hugging Face가 AI 에이전트의 사후 학습 과정을 다섯 단계로 정리한 기술 자료다.

여기서 Post-Training(사후 학습)은 모델이 대규모 데이터로 기본적인 언어 능력을 학습한 이후, 특정한 작업을 잘 수행하도록 추가 학습하는 과정을 의미한다.

일반적인 언어모델은 방대한 문서와 코드를 학습하면서 언어의 구조와 다양한 지식을 익힌다.

하지만 이런 모델이 자동으로 도구를 올바르게 사용하거나 긴 작업을 안정적으로 완료할 수 있는 것은 아니다.

따라서 실제 에이전트로 활용하려면 별도의 학습이 필요할 수 있다.

Hugging Face는 이를 지도 미세조정, 지식 증류, 강화학습, 환경 기반 강화학습, 실제 하네스에서의 학습으로 나누어 설명한다.

1단계: 성공한 에이전트의 행동을 따라 배우기

첫 번째는 SFT(Supervised Fine-Tuning, 지도 미세조정)다.

SFT는 모델에게 입력과 올바른 출력의 예시를 제공해 원하는 행동을 학습시키는 방법이다.

AI 에이전트에서는 단순한 질문과 답변뿐 아니라 전체 작업 과정의 기록을 학습 데이터로 사용할 수 있다.

예를 들어 강력한 코딩 모델이 특정한 오류를 수정하는 과정을 생각해 보자.

모델이 파일을 읽는다.

문제의 원인을 찾는다.

코드를 수정한다.

테스트를 실행한다.

오류가 해결됐는지 확인한다.

이 과정의 모든 모델 출력과 도구 실행 결과를 저장할 수 있다.

이를 Agent Trace(에이전트 실행 기록)라고 한다.

상대적으로 작은 모델은 이런 기록을 학습하면서 강력한 모델이 문제를 해결하는 방법을 따라 할 수 있다.

하지만 이 방법에는 한계가 있다.

성공적인 실행 기록만 학습했다면 모델이 실제로 잘못된 행동을 선택했을 때 어떻게 복구해야 하는지 충분히 배우지 못할 수 있다.

실제 코딩 에이전트에서는 명령 실행이 실패하거나 예상하지 못한 오류가 발생할 수 있다.

따라서 성공 사례를 모방하는 능력만으로는 긴 작업을 안정적으로 완료하기 어려울 수 있다.

2단계: 큰 모델의 지식을 작은 모델에 전달

두 번째는 Knowledge Distillation(지식 증류)이다.

지식 증류는 상대적으로 강력한 모델이 학습한 능력을 작은 모델에 전달하는 방식이다.

일반적으로 강력한 모델을 Teacher Model(교사 모델), 학습 대상 모델을 Student Model(학생 모델)이라고 한다.

교사 모델이 작성한 답변을 학생 모델에게 학습시킬 수 있다.

또는 교사 모델이 다음 토큰에 부여한 확률분포를 학생 모델에게 전달할 수도 있다.

예를 들어 교사 모델이 특정한 도구를 호출할 확률을 높게 계산했다면 학생 모델도 비슷한 선택을 하도록 학습할 수 있다.

이 방식은 단순히 정답만 제공하는 것보다 더 풍부한 학습 신호를 줄 수 있다.

SFT가 특정한 결과를 따라 하도록 학습시킨다면, 증류는 교사 모델이 여러 선택지를 어떻게 평가하는지에 관한 정보까지 활용할 수 있기 때문이다.

하지만 교사 모델의 판단이 항상 올바른 것은 아니다.

교사 모델이 가진 오류나 편향도 학생 모델에 전달될 수 있다.

또한 교사 모델을 계속 호출해야 하는 학습 방식에서는 추가적인 추론 비용이 발생한다.

따라서 지식 증류는 학생 모델을 처음부터 크게 만드는 것보다 효율적일 수 있지만, 교사 모델의 성능과 학습 비용에 영향을 받는다.

3단계: 정답 대신 결과에 대한 보상으로 학습

세 번째는 RL(Reinforcement Learning, 강화학습)이다.

강화학습에서는 모델이 생성한 결과에 점수를 부여한다.

모델은 더 높은 점수를 받는 행동을 선택하도록 학습한다.

예를 들어 수학 문제를 해결하는 모델을 학습시킨다고 가정해 보자.

사람이 모든 풀이 과정을 작성하지 않아도 최종 답이 올바른지 검사할 수 있다.

코딩에서도 비슷한 접근이 가능하다.

모델이 작성한 코드가 정해진 테스트를 통과하는지 확인할 수 있다.

이렇게 하면 사람이 모든 중간 행동의 정답을 제공하지 않아도 학습이 가능하다.

Hugging Face는 이 단계에서 GRPO(Group Relative Policy Optimization)를 설명한다.

GRPO는 하나의 요청에 대해 여러 결과를 생성한 뒤 각 결과의 보상을 비교하는 학습 방법이다.

예를 들어 같은 코딩 문제를 여러 번 해결하도록 하고, 테스트를 통과한 결과와 실패한 결과를 비교할 수 있다.

평균보다 높은 보상을 받은 행동의 가능성을 높이도록 모델을 조정한다.

하지만 최종 결과에 점수 하나만 제공하는 방식에는 한계가 있다.

예를 들어 에이전트가 열 번의 도구 호출을 수행한 뒤 실패했다고 가정해 보자.

어느 단계의 행동이 잘못됐는지 구분하기 어려울 수 있다.

또한 모델이 같은 문제를 여러 번 시도해야 하므로 학습 비용이 증가할 수 있다.

4단계: 실제로 도구를 사용하는 환경에서 학습

네 번째는 RL Environment(강화학습 환경)를 이용하는 방법이다.

여기서는 모델이 단순히 답변을 생성하는 데서 끝나지 않는다.

실제 도구를 실행하고 그 결과를 다시 확인한다.

예를 들어 코딩 에이전트의 학습 환경을 생각해 보자.

모델은 특정 파일을 수정한다.

이후 테스트 명령을 실행한다.

환경은 테스트 결과를 반환한다.

모델은 실패한 테스트를 분석한 뒤 다시 코드를 수정할 수 있다.

이런 과정 전체를 하나의 Episode(에피소드)라고 한다.

에피소드는 하나의 작업을 시작한 뒤 최종 결과에 도달할 때까지의 실행 과정이다.

환경은 여러 단계의 도구 실행과 프로그램 상태를 관리한다.

마지막에는 실제로 작업이 성공했는지 검사해 보상을 제공한다.

이렇게 하면 모델은 단순히 정답을 생성하는 방법뿐 아니라 오류가 발생했을 때 대응하고 다시 시도하는 방법도 학습할 수 있다.

Hugging Face는 이 과정에 OpenEnv를 사용할 수 있다고 설명한다.

OpenEnv는 AI 에이전트를 학습하고 평가할 수 있는 환경을 재사용 가능한 형태로 구성하도록 돕는 프로젝트다.

다만 환경 기반 학습에는 추가적인 비용이 발생한다.

각 학습 시도에서 실제 프로그램과 도구를 실행해야 하기 때문이다.

예를 들어 테스트 하나가 30초 걸린다면 수천 번의 학습 실행에서 상당한 시간이 필요할 수 있다.

5단계: 실제 서비스의 하네스에서 학습

마지막은 Harness-Based Training(실제 에이전트 실행 환경을 이용한 학습)이다.

Harness(하네스)는 언어모델에 도구를 제공하고 실제 행동을 실행하며, 세션과 작업 상태를 관리하는 소프트웨어 계층이다.

예를 들어 코딩 에이전트의 하네스는 파일 읽기와 수정, 명령 실행, 테스트, 오류 복구 등의 작업을 연결한다.

문제는 학습에 사용한 환경과 실제 운영 환경이 서로 다를 수 있다는 것이다.

예를 들어 학습 중에는 단순한 파일 수정 도구를 사용했지만 실제 제품에서는 복잡한 PR 관리와 샌드박스 기능을 사용할 수 있다.

이렇게 환경이 다르면 학습 과정에서 얻은 행동 전략이 실제 서비스에서는 잘 작동하지 않을 수 있다.

Hugging Face는 이를 해결하기 위해 실제로 운영할 에이전트의 하네스에서 직접 강화학습을 수행하는 방법을 설명한다.

또한 모델이 작업을 실행하는 과정과 모델의 가중치를 업데이트하는 학습 과정을 서로 다른 GPU에서 수행하도록 제안한다.

이를 Asynchronous Training(비동기 학습)이라고 한다.

예를 들어 한쪽 GPU에서는 여러 에이전트가 실제 작업을 수행한다.

다른 GPU에서는 이미 완료된 작업의 결과를 이용해 모델을 학습시킨다.

이렇게 하면 특정 작업이 오랫동안 실행되는 동안 학습용 GPU가 계속 기다리는 문제를 줄일 수 있다.

다만 비동기 학습에서는 모델의 가중치가 업데이트되는 동안 이전 버전의 모델이 생성한 실행 기록을 어떻게 처리할지 관리해야 한다.

실제로 학습한 모델과 실행 중인 모델의 버전이 달라질 수 있기 때문이다.

다섯 가지 방법은 서로 대체하는 관계가 아니다

이 글에서 중요한 점은 다섯 가지 학습 방법을 하나의 순위로 설명하지 않는다는 것이다.

SFT는 성공적인 행동 예시를 이용해 기본적인 도구 사용 방식을 학습시키는 데 적합할 수 있다.

지식 증류는 강력한 모델의 능력을 상대적으로 작은 모델에 전달하는 데 활용할 수 있다.

강화학습은 결과를 자동으로 평가할 수 있는 작업에서 효과적일 수 있다.

환경 기반 강화학습은 여러 단계의 도구 사용과 오류 복구를 학습시키는 데 필요할 수 있다.

실제 하네스에서의 학습은 개발 환경과 운영 환경 사이의 차이를 줄이는 데 도움이 될 수 있다.

하지만 어떤 방법이 가장 적합한지는 작업의 특성과 보유한 데이터, 평가 방법과 계산 자원에 따라 달라진다.

예를 들어 최종 결과를 정확하게 검사할 수 없다면 강화학습에서 사용할 보상 함수를 설계하기 어려울 수 있다.

반대로 검증 가능한 테스트가 충분하다면 모든 행동을 사람이 직접 작성할 필요 없이 모델의 작업 전략을 개선할 수 있다.

이번 글은 새로운 모델의 성능을 발표하는 연구 결과라기보다 AI 에이전트가 실제로 도구를 사용하는 능력을 어떻게 학습하는지 체계적으로 정리한 교육 자료다.

각 단계에 설명 자료와 관련 코드, 문서와 발표 영상이 연결돼 있어 사후 학습 기술들이 어떤 관계에 있는지 이해하는 데 유용하다.

특히 기존 언어모델을 실제 업무에 특화된 에이전트로 발전시키는 과정에서 모델의 학습과 실행 환경, 최종 결과의 검증을 함께 설계해야 한다는 점을 이해하기 좋은 글이다.

---

Measured, Not Claimed: 72 Local-LLM Benchmark Records from Two Strix Halo Mini PCs

• 저자: Alan Chen
• 발행: GEEKOM Engineering / Hugging Face Community
• 게시일: 2026-10-24
• 원문: Hugging Face — Measured, Not Claimed: 72 Local-LLM Benchmark Records from Two Strix Halo Mini PCs
• 관련 원문: GitHub — GEEKOM A9 Mega Local LLM Benchmarks

---

대형 언어모델을 개인용 컴퓨터에서 실행할 때 가장 중요한 하드웨어 사양은 무엇일까?

일반적으로 AI 컴퓨터의 성능을 비교할 때 GPU의 연산 성능에 주목하기 쉽다.

예를 들어 특정 GPU가 몇 TOPS의 AI 연산 성능을 제공하는지 확인할 수 있다.

TOPS(Tera Operations Per Second)는 초당 수행할 수 있는 연산의 수를 나타내는 지표다.

1TOPS는 초당 1조 회의 연산을 의미한다.

하지만 실제 언어모델을 실행하는 데는 연산 성능만큼 메모리 용량과 메모리 대역폭이 중요하다.

모델의 가중치를 메모리에 저장할 수 없으면 계산 성능이 아무리 높아도 정상적인 실행이 어려울 수 있기 때문이다.

이번 글은 GEEKOM이 자사의 소형 PC 두 대를 이용해 실제 언어모델 추론 성능을 측정한 결과를 공개한 기술 자료다.

중요한 점은 가장 빠른 결과만 보여주는 대신 느리게 실행된 사례와 실패한 테스트까지 포함한 원본 측정 기록을 공개했다는 사실이다.

다만 이번 실험은 하드웨어 제조사인 GEEKOM이 직접 수행했다.

따라서 독립적인 제3자 검증 결과는 아니며, 해당 제조사의 제품을 대상으로 한 측정이라는 점을 고려해야 한다.

두 종류의 Strix Halo PC 비교

연구팀은 AMD의 Strix Halo 프로세서를 사용하는 두 종류의 PC를 평가했다.

첫 번째는 GEEKOM A9 Mega 395다.

AMD Ryzen AI Max+ 395 프로세서와 128GB 통합 메모리를 사용한다.

두 번째는 GEEKOM A9 Mega 388이다.

AMD Ryzen AI Max+ 388 프로세서와 64GB 통합 메모리를 사용한다.

두 제품 모두 Radeon 8060S 그래픽을 사용하며 메모리 대역폭은 약 256GB/s다.

Unified Memory(통합 메모리)는 CPU와 GPU가 하나의 메모리 공간을 공유하는 구조다.

일반적인 데스크톱 PC에서는 CPU가 사용하는 시스템 메모리와 GPU가 사용하는 전용 VRAM이 분리된 경우가 많다.

반면 통합 메모리 시스템에서는 GPU가 상대적으로 큰 메모리 공간을 활용할 수 있다.

이는 대형 언어모델을 실행할 때 장점이 될 수 있다.

하지만 통합 메모리의 용량이 크다고 해서 모든 데이터에 전용 고성능 GPU 메모리와 같은 속도로 접근할 수 있는 것은 아니다.

실제 성능은 메모리 대역폭과 프로그램의 데이터 접근 방식에 영향을 받는다.

이번 평가에는 Ubuntu 26.04와 ROCm 10.0, llama.cpp가 사용됐다.

ROCm은 AMD GPU에서 AI와 범용 계산을 실행하기 위한 소프트웨어 플랫폼이다.

llama.cpp는 여러 언어모델을 CPU와 GPU에서 실행할 수 있도록 하는 오픈소스 추론 엔진이다.

72개의 실제 실행 결과 공개

연구팀은 여러 모델과 실행 방식, 입력 길이를 조합해 총 72개의 측정 기록을 수집했다.

각 기록에는 다음 정보가 포함됐다.

• 사용한 AI 모델과 가중치 형식
• 실제 하드웨어와 실행 구성
• 입력 토큰 길이와 생성한 출력 토큰 수
• 첫 번째 출력 토큰이 나타나기까지 걸린 시간
• 입력 처리 속도와 출력 생성 속도
• 실행 중 사용한 메모리
• 실제 실행 명령과 관련 설정

이렇게 상세한 정보를 공개한 이유는 AI 추론의 성능이 단일한 숫자로 설명되기 어렵기 때문이다.

예를 들어 어떤 모델이 초당 50토큰을 생성한다고 가정해 보자.

이 수치는 답변을 생성하는 단계의 속도를 나타낸다.

하지만 모델이 긴 문서를 읽는 데 10분이 걸린다면 실제 사용자는 첫 번째 답변을 보기까지 오랫동안 기다려야 한다.

따라서 출력 속도뿐 아니라 TTFT(Time to First Token, 첫 토큰 생성까지 걸리는 시간)를 함께 확인해야 한다.

연구팀은 128토큰의 짧은 입력부터 최대 25만6천 토큰의 긴 입력까지 여러 조건을 평가했다.

긴 컨텍스트를 지원하는 것과 빠르게 처리하는 것은 다르다

이번 실험에서 가장 흥미로운 결과 가운데 하나는 긴 입력에서 발생한 지연시간이다.

연구팀은 Qwen3.8-Flash-Next 모델을 평가했다.

해당 모델의 양자화 가중치 파일 크기는 약 111.4GB였다.

양자화는 모델의 숫자를 낮은 정밀도로 표현해 저장공간과 계산 비용을 줄이는 기술이다.

128GB 메모리를 가진 PC에서는 이 모델을 실행할 수 있었다.

짧은 입력에서는 초당 32.43토큰의 출력 생성 속도를 기록했다.

하지만 입력 길이를 12만8천 토큰으로 늘리자 출력 생성 속도는 초당 15.45토큰으로 감소했다.

더 중요한 문제는 첫 토큰이 생성되기까지 걸리는 시간이었다.

12만8천 토큰을 입력했을 때 720.61초가 필요했다.

약 12분이다.

즉 모델은 긴 입력을 처리할 수 있었지만 사용자가 즉시 답변을 받기는 어려웠다.

이 결과는 중요한 구분을 보여준다.

모델이 12만8천 토큰의 컨텍스트를 지원한다는 사실과, 해당 길이의 입력을 대화형 서비스에서 빠르게 처리할 수 있다는 사실은 다르다.

실제 서비스를 설계할 때는 최대 입력 길이뿐 아니라 해당 길이에서 발생하는 지연시간도 측정해야 한다.

더 많은 PC를 연결한다고 항상 빨라지지는 않는다

연구팀은 여러 대의 PC를 연결해 하나의 큰 모델을 실행하는 방법도 시험했다.

이를 Distributed Inference(분산 추론)라고 한다.

분산 추론은 하나의 모델을 여러 컴퓨터에 나누어 저장하거나 계산을 분담하는 방식이다.

예를 들어 111.4GB 크기의 모델을 64GB 메모리를 가진 PC 한 대에 저장하기는 어렵다.

하지만 여러 대의 PC를 연결하면 모델의 가중치를 나누어 저장할 수 있다.

연구팀은 두 대 또는 세 대의 PC를 연결하는 구성을 시험했다.

Qwen3.8-Flash-Next 모델을 두 대의 A9 Mega 388에서 실행했을 때 짧은 입력의 출력 속도는 초당 30.76토큰이었다.

세 대를 연결한 경우에는 초당 28.00토큰이었다.

즉 세 대를 사용했다고 해서 두 대보다 빠르게 출력한 것은 아니다.

왜 이런 결과가 발생했을까?

모델을 여러 컴퓨터에 나누면 각 컴퓨터가 필요한 계산을 수행한 뒤 다른 컴퓨터에 결과를 전달해야 한다.

이때 네트워크 통신에 시간이 필요하다.

모델을 나누어 저장함으로써 메모리 문제를 해결할 수 있지만, 장치 사이의 통신 비용 때문에 출력 속도가 감소할 수 있다.

이번 실험에서는 PC를 추가했을 때 처리 속도보다 메모리 용량의 확장 효과가 더 컸다.

이는 분산 추론을 평가할 때 중요한 차이다.

여러 컴퓨터를 연결하는 목적이 더 큰 모델을 실행하는 것인지, 하나의 요청을 더 빠르게 처리하는 것인지 구분해야 한다.

작은 모델이 실제 사용에서는 더 빠를 수 있다

이번 실험에서는 상대적으로 작은 모델이 매우 높은 출력 속도를 기록하기도 했다.

예를 들어 MiniCPM5-2B는 약 20억 파라미터 규모의 모델이다.

64GB 메모리를 가진 A9 Mega 388에서 짧은 입력을 처리했을 때 초당 103.10토큰을 생성했다.

또 다른 모델인 Qwen3.6-35B-A3B는 초당 68.03토큰을 기록했다.

Qwen3.6-35B-A3B는 MoE 구조를 사용하는 모델이다.

MoE(Mixture of Experts)는 여러 전문 신경망 가운데 필요한 일부만 선택적으로 사용하는 방식이다.

모델 전체의 파라미터가 많더라도 토큰 하나를 처리할 때 사용하는 계산량을 줄일 수 있다.

이런 구조는 특정한 하드웨어의 메모리 용량과 대역폭에 잘 맞는 경우 높은 추론 효율을 제공할 수 있다.

하지만 초당 토큰 수가 높다는 사실과 답변의 정확도가 높다는 사실은 다르다.

작은 모델은 빠르게 응답할 수 있지만 복잡한 코딩이나 장기 추론에서는 더 큰 모델보다 성능이 낮을 수 있다.

따라서 실제로 사용할 모델을 선택할 때는 작업 성공률과 응답 속도, 메모리 사용량을 함께 비교해야 한다.

실패한 테스트도 공개

이번 글에서 특히 인상적인 부분은 실패한 결과를 숨기지 않았다는 점이다.

예를 들어 Gemma-4-31B 모델을 25만6천 토큰 입력 조건에서 실행하려 했지만 정상적인 측정 결과를 얻지 못했다.

연구팀은 이 결과를 성공한 실행으로 처리하지 않았다.

실패한 테스트라는 사실을 공개하고 관련 데이터가 없음을 명시했다.

또한 일부 모델은 모든 입력 길이에서 평가하지 않았다.

모델의 양자화 방식과 추론 엔진 버전이 서로 다른 경우도 있었다.

따라서 연구팀은 해당 결과들을 완전히 동일한 조건의 모델 성능 순위로 비교해서는 안 된다고 설명한다.

이런 제한을 공개한 점은 기술 자료를 읽을 때 중요하다.

예를 들어 A 모델이 B 모델보다 빠르게 실행됐더라도 두 모델의 양자화 수준이 다르다면 성능 차이의 원인을 모델 자체로만 돌리기 어렵다.

또한 연구팀이 사용한 llama.cpp와 ROCm의 특정 버전에서 얻어진 결과이므로 다른 운영체제나 GPU 드라이버에서는 성능이 달라질 수 있다.

로컬 AI의 실제 비용을 판단하는 방법

이번 글은 로컬 AI를 도입할 때 무엇을 측정해야 하는지 보여준다.

첫 번째는 실제 모델을 메모리에 저장할 수 있는지다.

두 번째는 사용하려는 입력 길이에서 첫 번째 토큰이 얼마나 빨리 생성되는지다.

세 번째는 이후 출력 토큰을 얼마나 빠르게 생성하는지다.

네 번째는 여러 사용자가 동시에 요청을 보냈을 때 처리량이 어떻게 달라지는지다.

이번 연구는 주로 개별 모델 실행과 입력 길이에 따른 성능을 다뤘다.

따라서 여러 사용자가 동시에 이용하는 실제 서비스의 전체 처리량까지 검증한 것은 아니다.

또한 전력 사용량과 하드웨어 구입 비용, 장기 운영 비용을 종합적으로 비교한 결과도 아니다.

그럼에도 실제 실행 명령과 측정 기록을 공개했기 때문에 다른 개발자가 같은 조건에서 결과를 재현하거나 비교할 수 있다.

이 글은 로컬 AI의 성능을 평가할 때 모델의 최대 컨텍스트 길이와 GPU의 이론적 연산 성능보다 실제 입력 처리 시간과 메모리 사용량이 더 중요한 판단 기준이 될 수 있다는 점을 구체적인 측정 결과로 보여준다.