AI 데일리 브리핑 — 2026-10-16
Soshy··조회수 —
기준 시점: 2026-10-16 06:00 KST (Asia/Seoul)
AI 동향 조사 범위: 2026-10-15 06:00 ~ 2026-10-16 06:00 KST
추천 글 범위: 2026-10-09 06:00 ~ 2026-10-16 06:00 KST
1️⃣ 주요 모델·연구
Meta, 8,160억 파라미터 오픈웨이트 모델 ‘Muse Spark Open’ 공개…코딩·멀티모달·장기 에이전트 작업 지원
- 발표일: 2026-10-15 — 정확한 게시 시각 미확인
- 적용 범위: 오픈웨이트 LLM, 멀티모달 AI, 코딩 에이전트, 장기 추론, 로컬 AI, 모델 파인튜닝
- 원문: Meta AI Research — Introducing Muse Spark Open
- 관련 원문: Hugging Face — Muse Spark Open 816B-A42B 모델 카드
Meta가 새로운 대형 오픈웨이트 모델 Muse Spark Open을 공개했다.
이번 발표에서 중요한 변화는 기존에 Meta가 서비스로 제공하던 Muse 모델의 기능을 설명하는 데 그치지 않고, 외부 개발자가 직접 실행하고 수정할 수 있도록 모델 가중치를 배포했다는 점이다.
Muse Spark Open의 전체 파라미터는 8,160억 개(816B)이며, 토큰 하나를 처리할 때 활성화되는 파라미터는 약 420억 개(42B)다.
여기에는 MoE(Mixture of Experts, 여러 전문 신경망 가운데 입력에 필요한 일부만 선택적으로 사용하는 구조)가 적용됐다.
일반적인 Dense 모델은 입력을 처리할 때 대부분의 파라미터를 계산하지만, MoE는 여러 전문가 네트워크 가운데 일부만 활성화한다.
Muse Spark Open에는 256개의 전문가 네트워크가 있으며, 토큰마다 8개를 선택해 사용한다.
이 구조는 모델 전체에 많은 정보를 저장하면서도 매번 8,160억 개의 파라미터를 모두 계산하지 않도록 한다.
다만 활성 파라미터가 420억 개라고 해서 모델 전체를 420억 파라미터 모델과 동일한 메모리에서 실행할 수 있다는 의미는 아니다.
실제로 추론을 수행하려면 활성화되지 않는 전문가 네트워크의 가중치도 저장해 두어야 한다.
텍스트·이미지·음성·영상을 하나의 모델에서 이해
Muse Spark Open은 처음부터 여러 종류의 데이터를 함께 이해하도록 설계된 멀티모달 모델이다.
입력으로는 텍스트, 이미지, 음성, 영상을 사용할 수 있다. 출력은 텍스트다.
멀티모달 AI는 서로 다른 형태의 정보를 하나의 모델에서 처리하는 기술이다.
예를 들어 소프트웨어 사용 방법을 분석할 때 설명 문서와 실제 화면을 함께 참고하거나, 영상의 장면과 소리를 분석한 뒤 관련 내용을 설명할 수 있다.
모델에는 약 18억 파라미터 규모의 Perception Encoder도 포함돼 있다.
Encoder(인코더)는 이미지나 음성처럼 모델이 직접 처리하기 어려운 입력을 내부 계산에 사용할 수 있는 표현으로 변환하는 구성요소다.
Meta는 Muse Spark Open이 코딩, 화면 이해, 문서 분석과 여러 단계의 도구 사용을 하나의 시스템에서 수행하도록 설계됐다고 설명한다.
최대 컨텍스트 길이는 100만 토큰이다.
Context Window(컨텍스트 창)는 모델이 한 번의 요청에서 참고할 수 있는 입력과 대화 정보의 범위를 뜻한다.
컨텍스트가 길면 여러 파일로 구성된 코드베이스나 긴 문서, 이전 도구 실행 기록을 하나의 작업에 포함하기 쉬워진다.
그러나 100만 토큰을 입력할 수 있다는 것과 입력에 포함된 모든 정보를 정확하게 기억하고 활용한다는 것은 다른 문제다.
실제 장문 작업 성능은 별도의 평가가 필요하다.
코딩 에이전트를 위한 모델
Meta는 Muse Spark Open의 주요 활용 대상으로 Long-Horizon Agentic Task(여러 단계를 거쳐 오랫동안 수행하는 에이전트 작업)를 제시했다.
기존 질의응답에서는 사용자가 질문하면 모델이 답변을 생성하는 것으로 작업이 끝난다.
하지만 코딩 에이전트는 문제가 발생한 파일을 찾고, 관련 코드를 읽고, 수정안을 작성한 뒤 테스트 결과를 확인하는 과정을 여러 번 반복한다.
중간에 명령 실행이 실패하면 다른 방법을 찾거나 오류를 수정해야 한다.
Meta는 Muse Spark Open이 이런 도구 호출과 오류 복구, 여러 차례의 추론을 수행하도록 학습됐다고 밝혔다.
모델 카드에 따르면 실제 활용 대상에는 소프트웨어 엔지니어링, 합성 데이터 생성, 다른 모델의 결과 평가도 포함된다.
합성 데이터는 실제 사람이 직접 작성한 데이터가 아니라 프로그램이나 AI 모델을 이용해 생성한 학습 자료다.
Meta는 100개가 넘는 언어의 데이터를 학습에 활용했다고 설명한다.
또한 모델의 추론량을 조절하는 reasoning_effort 설정을 제공한다.
개발자는 작업의 난이도에 따라 low, medium, high, xhigh 가운데 하나를 선택할 수 있다.
복잡한 코드 수정이나 장기 작업에는 높은 추론량을 사용하고, 단순한 질문에는 낮은 추론량을 사용해 응답 시간과 계산 비용을 조정할 수 있다.
다만 모델이 여러 작업에 활용될 수 있다는 사실과 해당 분야에서 가장 높은 성능을 기록한다는 사실은 구분해야 한다.
Meta는 모델이 여러 코딩·에이전트 평가에서 경쟁력을 보인다고 설명하지만, 공개된 비교 결과만으로 모든 프런티어 모델보다 우수하다고 결론 내릴 수는 없다.
특히 벤치마크 점수는 모델을 실행하는 하네스와 도구 구성, 추론 설정에 따라 달라질 수 있다.
Harness(하네스)는 언어모델에 도구를 제공하고, 작업 상태를 관리하며, 실제 명령 실행과 오류 복구를 담당하는 소프트웨어 계층이다.
모델 가중치 공개와 라이선스 제한
Muse Spark Open은 Hugging Face에서 모델 가중치를 다운로드할 수 있다.
또한 Amazon SageMaker AI, Google Cloud Model Garden, Microsoft Foundry Models를 통해 제공된다.
API로는 Baseten, Fireworks AI, Groq, Modal, Nebius, OpenRouter, Together AI 등의 서비스에서 사용할 수 있다.
자체 인프라에서 실행하려는 개발자는 vLLM, SGLang, TensorRT-LLM, llama.cpp, Hugging Face Transformers, Apple MLX 등의 추론 엔진을 사용할 수 있다.
다만 오픈웨이트와 완전한 오픈소스는 다르다.
오픈웨이트는 학습된 모델의 가중치를 외부에 공개했다는 의미다.
모델의 전체 학습 데이터와 학습 과정, 모든 관련 코드가 제한 없는 라이선스로 공개됐다는 뜻은 아니다.
Muse Spark Open에는 Muse Model License라는 별도의 라이선스가 적용된다.
개발자는 모델을 사용하고 수정하거나 파인튜닝할 수 있지만, 이용 정책과 표시 의무 등을 따라야 한다.
특히 모델을 다른 고객에게 API 서비스 형태로 제공하는 Model as a Service 사업에서 최근 연속 12개월의 총매출이 2,000만 달러를 초과하는 경우에는 Meta에 통지하고 별도의 계약을 체결해야 한다.
일반적인 기업 내부 사용이나 모델을 자체 제품의 기능으로 활용하는 경우에는 해당 조항이 동일하게 적용되지 않는다.
따라서 상업적 서비스에 도입하려는 조직은 모델의 성능뿐 아니라 라이선스가 허용하는 활용 범위도 확인해야 한다.
로컬 실행도 가능하지만 일반적인 노트북 수준은 아니다
Muse Spark Open은 매우 큰 모델이다.
Meta의 모델 카드에 따르면 NVFP4 형식으로 GPU에 배포할 경우 최소 700GB의 VRAM이 필요하다.
NVFP4는 모델의 숫자 표현에 낮은 정밀도를 사용해 가중치 저장량과 연산 비용을 줄이는 4비트 형식이다.
일반적인 개인용 GPU 하나로 모델 전체를 실행하기는 어렵다.
이번 공개에서는 Apple과 협력해 M5 Ultra Mac Studio 두 대에서 모델을 분산 실행하는 방식도 제공했다.
Apple은 같은 날 업데이트한 MLX를 이용해 최대 네 대의 Mac Studio에서 모델을 실행하는 성능 결과를 공개했다.
이는 대형 모델을 실행하는 방법이 데이터센터의 NVIDIA GPU에만 한정되지 않고, 메모리 용량이 큰 개인용 컴퓨터 여러 대를 연결하는 방식으로도 확장되고 있음을 보여준다.
이번 발표는 모델 개발사가 제공하는 API를 이용하는 것과 개발자가 직접 모델을 실행하는 것 사이의 선택지를 넓혔다.
다만 모델의 가중치가 공개됐더라도 실제 운영에는 상당한 메모리와 계산 자원이 필요하며, 안전 정책과 접근권한을 관리하는 책임도 모델을 배포하는 조직에 남아 있다.
NVIDIA, 멀티모달 에이전트용 ‘Nemotron 3.5 Super VL’ 공개…1,200억 파라미터 가운데 120억 개만 활성화
- 발표일: 2026-10-15 — 정확한 게시 시각 미확인
- 적용 범위: 오픈웨이트 모델, 멀티모달 AI, 기업용 에이전트, 문서·영상 분석, 코딩, 보안 분석, 모델 파인튜닝
- 원문: NVIDIA — Nemotron 3.5 Super VL Powers Specialized Agents with Multimodal Reasoning
NVIDIA가 기업의 전문 업무를 수행하는 AI 에이전트를 위한 새로운 오픈웨이트 모델 Nemotron 3.5 Super VL을 공개했다.
이 모델은 약 1,200억 개의 전체 파라미터를 가지고 있지만, 토큰 하나를 처리할 때 활성화되는 파라미터는 약 120억 개다.
Meta의 Muse Spark Open과 마찬가지로 MoE 구조를 사용한다.
하지만 두 모델의 주된 활용 방향에는 차이가 있다.
Muse Spark Open은 대규모 범용 코딩·에이전트 모델의 가중치 공개에 초점을 맞췄다.
반면 NVIDIA는 Nemotron 3.5 Super VL을 기업이 자체 데이터와 업무 절차에 맞게 추가 학습시켜 사용하는 전문 에이전트용 기반 모델로 제시한다.
하나의 모델이 텍스트와 시각 정보를 함께 처리
실제 기업 업무에는 텍스트만 사용하는 작업보다 복잡한 상황이 많다.
예를 들어 재무팀의 에이전트는 영수증 사진에서 상호명과 결제 금액을 추출해야 한다.
고객지원 에이전트는 제품 설명서의 표와 화면 캡처를 함께 살펴봐야 할 수 있다.
보안 에이전트는 로그를 읽는 동시에 대시보드에 표시된 그래프와 경고 내용을 분석할 수 있다.
기존에는 이런 작업을 위해 여러 모델을 연결하는 경우가 많았다.
이미지를 분석하는 모델이 먼저 시각 정보를 텍스트로 변환하고, 별도의 언어모델이 그 결과를 읽어 판단하는 방식이다.
하지만 모델을 여러 개 연결하면 중간 결과를 전달하는 과정에서 정보가 손실될 수 있다.
또한 모델마다 별도의 추론 서버와 API 호출이 필요하므로 전체 작업 시간이 길어질 수 있다.
Nemotron 3.5 Super VL은 텍스트, 이미지, 문서, 영상을 이해하는 능력과 추론·도구 사용 능력을 하나의 모델에 결합했다.
예를 들어 보고서의 표와 그래프를 함께 분석하거나, 영상의 여러 장면에서 중요한 정보를 추출한 뒤 관련 문서와 비교하는 작업을 수행할 수 있다.
여기서 OCR(Optical Character Recognition)은 이미지나 스캔 문서 안에 있는 문자를 텍스트로 변환하는 기술이다.
NVIDIA는 이번 모델의 학습 과정에 표·그래프 이해, OCR, 여러 페이지로 구성된 문서, 영상 분석 데이터를 포함했다고 밝혔다.
기업별 데이터로 추가 학습하는 구조
Nemotron 3.5 Super VL은 공개된 모델을 그대로 사용하는 것뿐 아니라 조직의 업무에 맞게 수정하는 것을 주요 활용 방식으로 삼는다.
예를 들어 금융기업에서는 영수증이나 송장에서 특정 필드를 추출하는 모델로 학습시킬 수 있다.
보안기업에서는 취약점 보고서를 분석해 위험도를 판단하거나 관련 도구를 호출하도록 학습시킬 수 있다.
이를 Post-Training(사후 학습)이라고 한다.
일반적인 언어와 세계 지식을 학습한 기본 모델에 특정 업무의 데이터와 행동 규칙을 추가하는 과정이다.
NVIDIA는 이를 위해 NeMo AutoModel, NeMo RL, NeMo Gym 등의 도구를 제공한다.
활용 가능한 학습 방식에는 SFT(Supervised Fine-Tuning, 정답 예시를 이용한 지도 미세조정), LoRA(Low-Rank Adaptation, 상대적으로 적은 추가 파라미터를 학습하는 방식), 강화학습 등이 포함된다.
강화학습은 모델이 행동한 결과에 따라 보상을 제공해 더 좋은 행동을 학습시키는 방법이다.
이번 발표에서는 관련 학습에 활용할 수 있는 공개 데이터셋도 함께 제공됐다.
데이터셋에는 도구 호출과 대화, 금융 추론, 지시 이행, 긴 문맥 처리, 공정성 평가와 40개 비전·언어 데이터셋이 포함된다.
이는 모델의 가중치뿐 아니라 기업이 해당 모델을 전문화하는 데 필요한 학습 자료까지 제공하려는 접근이다.
모델 크기와 실제 응답 속도는 별개의 문제
NVIDIA는 Nemotron 3.5 Super VL의 주요 장점으로 높은 추론 효율을 강조한다.
회사 발표에 따르면 일부 에이전트 작업에서는 비슷한 규모의 오픈 모델보다 최대 5배 높은 처리량을 기록했다.
Baseten 환경에서 측정한 일부 작업에서는 초당 600개 이상의 출력 토큰을 생성했다고 설명한다.
하지만 이런 수치를 일반적인 사용자 응답 속도로 그대로 해석해서는 안 된다.
토큰 처리량은 모델을 실행하는 GPU, 서버 구성, 입력 길이, 동시에 처리하는 요청 수와 추론 설정에 따라 달라진다.
NVIDIA는 속도를 높이기 위해 여러 기술을 조합했다.
대표적인 방법은 Speculative Decoding(추측 디코딩)이다.
추측 디코딩은 상대적으로 가벼운 계산으로 여러 출력 토큰을 미리 예상하고, 큰 모델이 이를 검증하는 방식이다.
예상이 맞으면 토큰을 하나씩 생성하는 과정을 일부 줄일 수 있다.
또한 NVFP4 양자화와 컨텍스트 재사용을 통해 계산과 메모리 사용량을 줄였다.
컨텍스트 재사용은 같은 지침이나 문서를 여러 번 처리할 때 이전 계산 결과를 활용하는 접근이다.
긴 대화와 반복적인 도구 호출이 많은 에이전트에서는 이런 최적화가 중요하다.
실제 기업 사례와 성능 수치의 한계
NVIDIA는 모델을 전문 업무에 맞게 추가 학습한 여러 기업 사례를 소개했다.
Scale AI는 Skydance의 거래처 크레딧 처리 업무를 위해 모델을 추가 학습했다.
NVIDIA는 이 업무의 추론 비용이 최대 40분의 1, 지연시간은 5분의 1 수준으로 낮아질 것이라고 설명했다.
다만 원문은 일부 수치를 실제로 측정된 결과가 아니라 앞으로 기대되는 개선 효과로 제시한다.
금융 운영 플랫폼 Ramp도 영수증 이미지를 구조화된 JSON 데이터로 변환하는 업무에 모델을 적용하고 있다.
Ramp는 처리량이 최대 50% 증가하고 지연시간이 10분의 1 수준으로 낮아질 것으로 기대한다고 밝혔다.
AI21과 Alice의 보안 분석 사례에서는 모델을 추가 학습한 뒤 정확도가 약 41% 개선됐다고 보고했다.
이 수치들은 각 기업과 NVIDIA가 공개한 특정 업무의 결과이며, 모든 기업의 작업에서 같은 개선이 나타난다는 의미는 아니다.
일반적인 에이전트 평가에서도 개선된 점수가 공개됐다.
Hermes Bench에서는 Nemotron 3.5 Super VL이 63.44%, Nemotron 3 Ultra가 56.33%를 기록했다.
LangChain의 행동 평가에서는 각각 87.05%와 84.3%였다.
그러나 이 결과는 해당 벤치마크와 실행 설정에서의 비교다.
Super VL이 Ultra보다 모든 복잡한 추론 작업에서 더 강력하다고 해석해서는 안 된다.
이번 발표는 기업용 AI 에이전트의 모델 선택 기준이 단순한 파라미터 수나 일반적인 벤치마크 점수에서 벗어나고 있다는 점을 보여준다.
특정 업무를 완료하는 데 필요한 정확도, 실행 시간과 비용을 함께 고려하고, 모델을 조직의 데이터와 도구에 맞춰 추가 학습하는 방식이 점점 중요해지고 있다.
CERN·Mistral, 입자 충돌 데이터를 학습하는 ‘Large Physics Model’ 공동 개발 추진…과학 연구용 기반 모델 구축
- 발표일: 2026-10-15 — 정확한 게시 시각 미확인
- 적용 범위: AI for Science, 입자물리학, 과학 기반 모델, 대규모 시뮬레이션, 유럽 AI 연구 인프라
- 원문: CERN — CERN and Mistral join forces to accelerate AI for science
유럽입자물리연구소 CERN과 프랑스 AI 기업 Mistral이 과학 연구를 위한 기반 모델을 공동 개발하기로 했다.
양측은 10월 15일 장기적인 전략적 협력을 위한 의향서(Statement of Intent)를 체결했다고 발표했다.
이번 협력의 목표는 Large Physics Model이라는 새로운 종류의 과학 AI 모델을 개발하는 것이다.
다만 이는 완성된 모델의 출시가 아니다.
현재는 공동 연구 방향과 협력 의사를 공식화한 단계이며, 모델의 성능이나 실제 배포 일정이 확정된 것은 아니다.
언어 대신 입자 충돌을 학습하는 기반 모델
일반적인 대형 언어모델은 방대한 텍스트 데이터에서 단어와 문장 사이의 관계를 학습한다.
반면 CERN과 Mistral이 구상하는 모델은 입자가 충돌하면서 발생하는 물리적 현상을 학습한다.
CERN의 대형강입자충돌기 LHC(Large Hadron Collider)에서는 양성자 같은 입자를 매우 높은 에너지로 충돌시킨다.
이 과정에서 여러 종류의 입자가 생성되고 검출기에 복잡한 신호가 기록된다.
과학자들은 이 신호를 분석해 어떤 입자가 만들어졌고 어떤 상호작용이 발생했는지 추정한다.
문제는 검출기가 기록한 신호가 물리학자가 분석하고자 하는 입자 정보와 직접적으로 일치하지 않는다는 것이다.
여러 개의 전문 알고리즘을 순서대로 실행해 원시 신호를 입자의 궤적과 에너지, 종류 등의 정보로 변환해야 한다.
이 과정을 Event Reconstruction(입자 충돌 사건 재구성)이라고 한다.
기존 시스템에서는 입자의 궤적을 찾는 모델, 입자의 종류를 구분하는 모델, 이상 신호를 탐지하는 모델이 서로 분리돼 있을 수 있다.
CERN과 Mistral은 이런 작업을 하나의 기반 모델에서 처리하는 것을 목표로 한다.
수십억 건의 충돌 시뮬레이션 활용
새 모델은 LHC에서 발생하는 물리 현상을 재현한 수십억 건의 양성자 충돌 시뮬레이션을 학습 데이터로 사용할 계획이다.
Simulation(시뮬레이션)은 물리법칙과 계산 모델을 이용해 실제 실험과 유사한 현상을 컴퓨터 안에서 재현하는 과정이다.
시뮬레이션은 입자물리학에서 매우 중요하다.
실제 검출기가 기록한 신호만으로는 어떤 물리 현상이 원인이었는지 완전히 알기 어렵기 때문이다.
연구자는 물리법칙에 따라 생성한 시뮬레이션 결과와 실제 관측 데이터를 비교해 새로운 현상의 가능성을 검토한다.
Large Physics Model은 이런 데이터를 이용해 충돌 사건을 재구성하고, 입자를 식별하며, 예상하지 못한 신호를 찾는 작업을 지원하도록 설계될 예정이다.
또한 새로운 입자 검출기를 설계할 때 여러 구성의 성능을 비교하는 작업에도 활용하는 것을 목표로 한다.
CERN은 현재까지 LHC에서 약 1엑사바이트의 실험 데이터를 저장했다고 밝혔다.
1엑사바이트는 약 100만 테라바이트에 해당한다.
향후 2030년 무렵 가동이 예상되는 HL-LHC(High-Luminosity LHC)에서는 입자 충돌 횟수가 약 10배 증가할 것으로 예상된다.
따라서 앞으로는 지금보다 훨씬 많은 실험 데이터를 분석해야 한다.
CERN은 이러한 데이터 규모와 높은 물리적 정확성 요구사항이 새로운 과학 AI를 개발하기에 적합한 연구 환경을 제공한다고 설명한다.
기존 전문 모델을 하나로 연결할 수 있을까?
이번 협력의 핵심 연구 질문은 서로 다른 물리 분석 작업에 하나의 공통 기반 모델을 사용할 수 있는가이다.
최근 생성형 AI에서는 하나의 모델이 번역, 문서 요약, 코드 작성처럼 서로 다른 작업을 수행하는 사례가 늘어났다.
CERN과 Mistral은 입자물리학에서도 비슷한 접근이 가능할지 검토하려 한다.
하지만 과학 연구에서는 그럴듯한 결과를 생성하는 것만으로 충분하지 않다.
입자의 위치와 에너지, 검출기의 측정 오차 같은 수치가 물리법칙과 실제 실험 조건에 맞아야 한다.
따라서 모델이 복잡한 관계를 학습하더라도 결과의 물리적 타당성을 별도로 검증해야 한다.
이번 발표는 모델 구조와 최종 성능을 공개한 연구 결과가 아니라 향후 연구를 위한 협력 계획이다.
그럼에도 범용 AI 모델을 과학에 활용하는 것에서 나아가, 과학 데이터 자체를 학습하는 대규모 기반 모델을 만들려는 방향을 보여준다는 점에서 주목할 만하다.
2️⃣ AI 제품·서비스
Google, 검색과 Gemini의 장바구니를 통합하는 ‘Universal Cart’ 미국 출시…상품·가격·결제 혜택을 한곳에서 관리
- 발표일: 2026-10-15 — 정확한 게시 시각 미확인
- 적용 범위: Google Search, Gemini, 생성형 AI 쇼핑, 전자상거래, 개인화 추천, Google Pay
- 원문: Google — An intelligent new shopping cart
Google이 여러 쇼핑몰의 상품을 하나의 장바구니에서 관리할 수 있는 Universal Cart를 미국에서 출시했다.
Universal Cart는 올해 초 미리 공개된 기능이다.
10월 15일의 새로운 변화는 미국 사용자를 대상으로 Google 검색과 Gemini 앱에서 실제 제공을 시작했다는 점이다.
일반적인 온라인 쇼핑에서는 사용자가 여러 쇼핑몰을 비교하면서 상품을 장바구니에 넣는다.
문제는 쇼핑몰마다 장바구니와 가격 정보가 분리돼 있다는 것이다.
예를 들어 신발은 한 쇼핑몰에서, 옷은 다른 쇼핑몰에서, 화장품은 또 다른 쇼핑몰에서 찾아볼 수 있다.
구매를 바로 결정하지 않는다면 여러 브라우저 탭이나 스크린샷으로 상품을 관리하게 된다.
Universal Cart는 이런 상품들을 Google 검색과 Gemini에서 공통으로 사용하는 하나의 목록에 저장한다.
여러 쇼핑몰의 상품을 하나의 목록에 저장
사용자는 Google 검색의 AI Mode에서 찾은 상품을 장바구니에 저장할 수 있다.
이후 Gemini 앱에서 다른 상품을 발견해도 같은 장바구니에 추가된다.
즉 쇼핑 과정이 특정 웹사이트나 하나의 대화에 묶이지 않는다.
Google은 상품 정보의 기반으로 Shopping Graph를 사용한다.
Shopping Graph는 Google이 쇼핑 서비스를 위해 관리하는 대규모 상품 정보 시스템이다.
Google에 따르면 여기에는 600억 개 이상의 상품 목록이 포함되며 가격과 재고 정보가 지속적으로 갱신된다.
Universal Cart는 이런 정보를 이용해 사용자가 저장한 상품의 가격이 내려가거나 품절된 상품이 다시 판매되기 시작하면 알림을 제공할 수 있다.
다만 가격 정보의 갱신과 실제 판매자의 최종 결제 가격은 차이가 날 수 있다.
따라서 최종 구매 단계에서는 판매자가 제시하는 가격과 조건을 확인해야 한다.
단순 가격 비교를 넘어 결제 혜택까지 분석
새로운 장바구니는 여러 상품을 저장하는 데 그치지 않는다.
Google Wallet에 연결된 결제수단의 혜택을 고려해 어떤 카드나 결제 방법이 더 적합한지도 제안할 수 있다.
예를 들어 사용자가 여러 신용카드를 가지고 있고 각 카드의 할인 조건이 다르다면, 구매하려는 상품에 맞는 혜택을 비교하는 데 도움을 줄 수 있다.
관련 프로모션 코드도 함께 표시한다.
이 과정에는 사용자의 구매 상황과 상품 정보를 분석하는 AI 기능이 활용된다.
다만 Google이 제안한 결제수단이 사용자의 모든 카드 혜택과 실제 청구 조건을 완전하게 반영한다는 의미는 아니다.
특히 카드의 월간 할인 한도나 실적 조건, 국가별 적용 제한은 별도로 확인해야 할 수 있다.
실제 구매 권한은 사용자에게 남는다
이번 제품에서 중요한 설계 선택은 Google이 Universal Cart를 사용자가 통제하는 쇼핑 도구로 설명한다는 점이다.
최근 AI 쇼핑 에이전트는 사용자를 대신해 상품을 구매하는 기능으로 발전하고 있다.
하지만 Universal Cart의 기본 경험은 사용자가 상품을 선택하고 최종 구매를 결정하도록 설계됐다.
사용자는 Google Pay를 이용해 결제를 완료하거나 판매자의 장바구니로 이동해 구매할 수 있다.
참여 판매자로는 Nike, Sephora, Target, Ulta Beauty, Walmart, Wayfair와 여러 Shopify 기반 쇼핑몰이 소개됐다.
판매자는 계속해서 실제 상품의 판매 주체로 남는다.
따라서 주문 확인과 고객지원도 해당 판매자가 담당한다.
이 구조는 Google이 여러 판매자의 상품을 하나의 인터페이스에 모으면서도 최종 거래와 판매자 책임을 기존 전자상거래 시스템에 유지하려는 방식이다.
Google은 구매 절차에 UCP(Universal Commerce Protocol)를 활용한다고 설명한다.
UCP는 AI 기반 쇼핑 경험과 실제 판매자의 거래 시스템을 연결하기 위한 공통 통신 규격이다.
Universal Cart는 단순히 새로운 장바구니 화면을 제공하는 것이 아니라 검색, AI 대화와 결제 사이에 존재하던 경계를 줄이려는 제품이라는 점에서 의미가 있다.
다만 현재 제공 지역은 미국이며, 한국에서 같은 기능을 즉시 사용할 수 있다는 의미는 아니다.
3️⃣ 개발 도구·에이전트
GitHub, AI 보안 검사와 취약점 수정 에이전트 정식 출시…PR 검사부터 수정안 검증까지 연결
- 발표일: 2026-10-15 — 정확한 게시 시각 미확인
- 적용 범위: GitHub, Copilot, Code Security, 코드 취약점 분석, PR 검토, 보안 자동화, CodeQL
- 원문: GitHub — Agentic autofix for code scanning alerts general availability
- 관련 원문: GitHub — AI Scan for pull requests generally available
GitHub가 코드 보안과 관련된 두 가지 AI 기능을 GA(General Availability, 정식 제공) 상태로 전환했다.
첫 번째는 AI를 이용해 PR에 포함된 잠재적인 취약점을 탐지하는 AI Scan이다.
두 번째는 발견된 보안 경고를 분석하고 실제 수정안을 만드는 Agentic Autofix다.
두 기능은 서로 다른 단계에서 작동한다.
AI Scan은 문제가 있는 코드를 찾아내는 역할이고, Agentic Autofix는 이미 발견된 문제를 수정하는 역할이다.
CodeQL이 지원하지 않는 언어와 파일까지 검사
GitHub의 기존 코드 보안 기능 가운데 대표적인 기술은 CodeQL이다.
CodeQL은 소스코드를 분석할 수 있는 데이터 구조로 변환한 뒤, 정해진 보안 규칙을 이용해 취약점을 찾는 도구다.
예를 들어 외부 사용자의 입력이 검증 없이 운영체제 명령으로 전달되거나 데이터베이스 쿼리에 사용되는 문제를 탐지할 수 있다.
그러나 모든 프로그래밍 언어와 프레임워크를 동일한 수준으로 지원하는 것은 아니다.
GitHub는 이번 AI Scan을 통해 CodeQL의 기존 분석 범위를 보완한다고 설명했다.
새 기능은 PHP, Shell/Bash, Terraform의 HCL, Dockerfile, Java의 JSP, C#의 Blazor 등 CodeQL에서 현재 충분히 다루지 못하는 영역의 PR 변경사항을 검사한다.
예를 들어 Dockerfile에 위험한 권한 설정이 추가됐거나, Terraform 구성에 부적절한 인프라 접근 정책이 포함된 경우 이를 검토할 수 있다.
여기서 HCL(HashiCorp Configuration Language)은 Terraform 등에서 인프라 설정을 정의하는 데 사용하는 구성 언어다.
AI Scan은 PR이 생성되거나 변경될 때 자동으로 실행할 수 있다.
발견된 문제는 기존 CodeQL 결과와 함께 PR의 Conversation과 Files changed 화면에 표시된다.
AI로 발견한 문제에는 별도의 표시가 붙는다.
검사 결과에는 잠재적인 위험을 설명하는 내용과 수정 제안이 포함될 수 있다.
다만 AI Scan의 결과는 권고 사항이다.
GitHub는 해당 결과만으로 보안 검사를 실패 처리하거나 저장소 규칙을 이용해 PR 병합을 자동 차단할 수 없다고 명시했다.
이는 AI 분석 결과에 잘못된 경고가 포함될 가능성을 고려한 제한이다.
또한 포크 저장소에서 생성된 PR이나 Dependabot이 생성한 PR에서는 AI Scan이 실행되지 않는다.
Agentic Autofix는 실제 코드를 수정한다
Agentic Autofix는 AI Scan과 달리 이미 발생한 코드 스캔 경고를 해결하는 작업을 수행한다.
개발자가 보안 경고를 Copilot에 할당하면 에이전트가 관련 파일을 찾아 읽는다.
이후 취약점이 발생한 원인을 분석하고 수정 코드를 작성한다.
중요한 부분은 단순히 수정 코드를 제안하는 것으로 끝나지 않는다는 점이다.
에이전트는 CodeQL을 다시 실행해 해당 수정이 원래 경고를 해결했는지 확인한다.
문제가 남아 있다면 다른 수정안을 시도할 수 있다.
검증이 끝나면 개발자가 검토할 수 있도록 Draft PR을 생성한다.
Draft PR은 아직 최종 병합을 요청하는 상태가 아닌, 검토와 추가 수정을 위한 PR이다.
PR에는 어떤 문제를 수정했고 어떤 검증을 수행했는지 설명이 포함된다.
개발자는 생성된 PR에 댓글을 남기거나 GitHub의 에이전트 화면을 이용해 추가 변경을 요청할 수 있다.
여기서 중요한 점은 에이전트가 실제로 코드를 수정할 수 있더라도 최종 코드 검토와 병합은 개발자의 절차에 남아 있다는 사실이다.
보안 경고가 사라졌다는 것과 프로그램이 모든 환경에서 올바르게 작동한다는 것은 다른 문제이기 때문이다.
예를 들어 SQL Injection을 방지하기 위해 쿼리를 변경했더라도 해당 변경이 기존 기능의 동작에 영향을 주지 않았는지는 별도의 테스트가 필요할 수 있다.
여러 취약점을 하나의 PR로 수정
Agentic Autofix는 개별 보안 경고뿐 아니라 여러 경고를 한 번에 처리할 수 있다.
GitHub는 최대 25개의 경고를 하나의 수정 PR에 포함할 수 있다고 밝혔다.
다만 처리 대상은 저장소의 기본 브랜치(Default Branch)에서 발견된 코드 스캔 경고다.
PR에서만 발생했거나 다른 브랜치에만 존재하는 경고를 같은 방식으로 할당할 수 있는 것은 아니다.
또한 기업 관리자가 기능 사용을 허용해야 한다.
기업의 보안 정책에서 Agentic Autofix를 활성화한 뒤, 조직이나 저장소 관리자가 실제 사용 여부를 설정하는 구조다.
이는 AI 에이전트가 기업의 코드에 직접 변경사항을 작성하는 기능이기 때문에 일반적인 코드 검색보다 강한 관리가 필요하다는 점과 연결된다.
제공 범위와 과금
AI Scan은 공개 저장소에서 사용할 수 있다.
비공개 및 내부 조직 저장소에서는 GitHub Code Security 또는 GitHub Advanced Security가 필요하다.
AI Scan 자체를 사용하기 위해 별도의 GitHub Copilot 라이선스가 반드시 필요한 것은 아니다.
하지만 기능 사용에는 Code Security AI Credits가 소비된다.
Agentic Autofix는 GitHub Enterprise Cloud의 GitHub Code Security 또는 GitHub Advanced Security 고객에게 제공된다.
또한 Copilot 과금 설정이 필요하다.
실행 과정에서는 Code Security AI Credits와 GitHub Actions 실행 시간이 사용된다.
따라서 두 기능이 GA로 전환됐다고 해서 모든 조직이 무료로 무제한 사용할 수 있는 것은 아니다.
이번 변경은 AI 코딩 도구의 역할이 코드 생성과 설명을 넘어 보안 문제 탐지, 수정안 생성, 자동화된 재검증과 PR 작성까지 확대되고 있음을 보여준다.
동시에 AI가 보안 검사를 수행하더라도 결과를 그대로 신뢰하지 않고 정적 분석과 사람의 코드 검토를 함께 사용하는 구조가 중요하다는 점도 드러난다.
Google Cloud, Gemini에서 다른 클라우드의 기업 데이터 직접 조회…‘Borderless Lakehouse’ 연동 프리뷰 확대
- 발표일: 2026-10-15 — 정확한 게시 시각 미확인
- 적용 범위: Gemini, Google Cloud, BigQuery, 데이터 레이크하우스, 기업용 에이전트, AWS·Azure 데이터 연동
- 원문: Google Cloud — Bringing the borderless Lakehouse into the agentic era with innovations for Gemini
Google Cloud가 Gemini와 Borderless Lakehouse를 연결하는 새로운 데이터 접근 구조를 공개했다.
이번 발표는 지난주 Gemini at Work 행사에서 소개한 기업용 AI 전략을 구체화한 후속 발표다.
10월 15일에는 Gemini의 직접 연동 프리뷰와 기존에 발표했던 여러 데이터 연동 기능의 정식 제공 범위가 구체적으로 공개됐다.
기업이 AI 에이전트를 도입할 때 겪는 어려움 가운데 하나는 필요한 정보가 여러 시스템에 분산돼 있다는 점이다.
예를 들어 고객 정보는 Salesforce에 있고, 매출 데이터는 BigQuery에 있으며, 제품 로그는 AWS에 저장돼 있을 수 있다.
또 다른 분석 결과는 Snowflake나 Databricks에서 관리할 수 있다.
AI 에이전트가 이런 정보를 함께 분석하려면 서로 다른 데이터 시스템에 접근해야 한다.
가장 단순한 방법은 모든 데이터를 한곳으로 복사하는 것이다.
하지만 데이터가 수십 테라바이트에서 페타바이트 규모로 커지면 복사 비용이 커진다.
또한 개인정보나 기업 기밀을 다른 시스템으로 이동하는 과정에서 보안·규제 문제가 발생할 수 있다.
Google Cloud는 이런 문제를 해결하기 위해 데이터를 옮기지 않고 여러 시스템에 접근하는 구조를 강조한다.
Lakehouse와 Catalog Federation
Data Lakehouse(데이터 레이크하우스)는 다양한 형식의 데이터를 저장하는 데이터 레이크와, 구조화된 데이터를 분석하는 데이터 웨어하우스의 특징을 결합한 구조다.
Borderless Lakehouse는 데이터를 저장한 위치가 서로 달라도 공통된 방식으로 검색하고 분석할 수 있도록 한다.
여기서 중요한 기술은 Catalog Federation(카탈로그 연합)이다.
Catalog는 데이터가 어디에 저장돼 있고 어떤 구조를 가지고 있으며, 어떤 권한으로 접근할 수 있는지 설명하는 메타데이터 저장소다.
메타데이터는 데이터 자체에 관한 설명 정보다.
예를 들어 매출 테이블의 위치와 열 이름, 데이터 형식, 소유 조직 등이 여기에 포함된다.
Catalog Federation은 여러 데이터 플랫폼의 카탈로그를 연결해 하나의 공통 접근 계층으로 사용하는 방식이다.
이번 프리뷰에서는 Gemini가 Databricks Unity Catalog와 Snowflake Horizon 같은 외부 카탈로그에 연결된 데이터를 직접 활용할 수 있도록 한다.
따라서 사용자는 자연어로 질문하면서 여러 클라우드에 분산된 자료를 분석할 수 있다.
다만 AI 모델의 컨텍스트에 모든 원본 데이터를 넣는 방식은 아니다.
실제 대규모 계산은 데이터 분석 시스템이 수행하고, 모델은 필요한 질의와 결과를 활용하는 구조다.
수백 TB의 데이터를 모델에 직접 넣지 않는 이유
일반적인 LLM은 한 번의 요청에서 처리할 수 있는 컨텍스트 크기에 제한이 있다.
반면 기업의 분석 데이터는 수십억 개의 행으로 구성될 수 있다.
이런 데이터를 전부 프롬프트에 넣는 것은 현실적이지 않다.
또한 데이터베이스가 수행해야 하는 집계와 조인, 필터링을 언어모델이 직접 수행하는 것은 효율적이지 않다.
따라서 Gemini가 자연어 질문을 분석한 뒤 필요한 데이터 조회 작업을 생성하고, BigQuery 같은 분석 엔진이 실제 계산을 수행하도록 역할을 나누는 것이 중요하다.
예를 들어 사용자가 두 국가의 분기별 매출과 재고 수준을 비교해 달라고 요청한다면, 모델이 모든 주문 기록을 직접 읽는 대신 필요한 SQL을 생성하고 결과를 전달받을 수 있다.
SQL(Structured Query Language)은 관계형 데이터베이스에서 데이터를 조회하고 처리하는 데 사용하는 언어다.
이 구조에서는 모델의 추론 능력만큼 어떤 데이터가 올바른 정보인지, 매출과 재고 같은 지표를 조직이 어떻게 정의하는지가 중요하다.
Google Cloud는 Knowledge Catalog와의 연동을 통해 이런 비즈니스 정의를 모델이 참고하도록 설계했다.
AWS·Azure 데이터 연동 기능 정식 제공
이번 발표에는 기존에 소개했던 여러 기능의 GA 전환도 포함됐다.
Google Cloud는 AWS와 Azure를 대상으로 Cross-Cloud Interconnect와 Cross-Cloud Caching을 제공한다.
Cross-Cloud Interconnect는 서로 다른 클라우드 사이에 전용 네트워크 연결을 제공하는 기술이다.
이번 구성에서는 연결당 10Gbps 또는 100Gbps의 전용 통신 경로를 활용할 수 있다.
Cross-Cloud Caching은 다른 클라우드에서 반복해서 조회하는 데이터를 캐시에 저장해 같은 데이터를 계속 이동시키는 비용을 줄이는 기능이다.
또한 BigQuery에서 Apache Iceberg V3를 지원한다.
Apache Iceberg는 대규모 데이터 분석을 위한 개방형 테이블 형식이다.
특정 분석 엔진에 종속되지 않고 여러 시스템이 같은 데이터를 읽고 관리할 수 있도록 한다.
이번 업데이트에서는 BigQuery와 Managed Service for Apache Spark가 같은 Iceberg 테이블을 읽고 수정하는 기능도 제공된다.
여기서 중요한 점은 모델이 접근할 수 있는 데이터 범위를 넓히는 것과 무조건 모든 데이터에 접근할 권한을 부여하는 것은 다르다는 사실이다.
실제 기업용 에이전트에서는 사용자별 데이터 접근권한과 감사 기록, 민감정보 보호 정책을 기존 데이터 시스템과 일관되게 적용해야 한다.
이번 발표는 AI 에이전트의 경쟁력이 모델 자체의 성능뿐 아니라 기업에 분산된 실제 데이터를 얼마나 안전하고 정확하게 연결할 수 있는가에 달려 있다는 점을 보여준다.
🖥️ AI 인프라·반도체
Apple, Mac Studio 네 대에서 8,160억 파라미터 모델 실행…MLX·Thunderbolt RDMA로 초당 36토큰 생성
- 발표일: 2026-10-15 — 정확한 게시 시각 미확인
- 적용 범위: Apple Silicon, MLX, 로컬 LLM, 분산 추론, AI 하드웨어, 통합 메모리, Thunderbolt
- 원문: Apple Machine Learning Research — Local and Distributed Large LLM Inference with MLX and RDMA on Mac Studio
Apple이 새로운 MLX 버전을 활용해 M5 Ultra Mac Studio 여러 대에서 초대형 AI 모델을 분산 실행하는 방법과 성능 평가 결과를 공개했다.
이번 발표는 Meta가 같은 날 공개한 Muse Spark Open의 실제 실행 사례와 연결된다.
Apple은 약 8,160억 파라미터 규모의 Muse Spark Open을 Mac Studio 네 대에서 실행해 초당 36.73토큰의 출력 속도를 기록했다고 밝혔다.
이는 일반적인 노트북에서 거대한 프런티어 모델을 실행할 수 있게 됐다는 의미는 아니다.
대신 매우 큰 통합 메모리를 가진 고성능 데스크톱 여러 대를 연결하면 기존에는 대형 서버에서 실행하던 모델을 자체 환경에서 구동할 수 있다는 사실을 보여준다.
GPU 메모리와 통합 메모리의 차이
일반적인 고성능 AI 서버에서는 GPU에 탑재된 전용 메모리인 VRAM이 중요하다.
모델 가중치와 중간 계산 결과를 GPU가 빠르게 읽어야 하기 때문이다.
하지만 모델이 매우 크면 한 장의 GPU 메모리에 모든 가중치를 저장하기 어렵다.
예를 들어 Muse Spark Open의 전체 가중치를 BF16 형식으로 저장하려면 모델 파라미터만으로 약 1.6TB 이상의 메모리가 필요하다.
BF16(Bfloat16)은 AI 계산에 자주 사용되는 16비트 부동소수점 숫자 형식이다.
Apple은 이번 평가에서 모델을 NVFP4 4비트 형식으로 양자화했다.
Quantization(양자화)은 모델의 숫자를 더 낮은 정밀도로 표현해 메모리 사용량과 계산 비용을 줄이는 기술이다.
이렇게 하면 모델 가중치가 차지하는 공간을 약 493GB로 줄일 수 있다.
하지만 실제 추론에는 가중치 외에도 중간 계산 결과를 저장할 메모리가 필요하다.
따라서 모델을 단순히 512GB 메모리를 가진 Mac Studio 한 대에 넣을 수는 없었다.
Apple은 이를 해결하기 위해 여러 Mac Studio를 연결했다.
M5 Ultra Mac Studio는 최대 512GB의 통합 메모리(Unified Memory)를 제공한다.
통합 메모리는 CPU와 GPU가 하나의 메모리 공간을 공유하는 구조다.
별도로 제한된 GPU 전용 메모리만 사용하는 시스템과는 다른 메모리 구성 방식을 제공한다.
두 대에서는 모델을 나눠 저장하고, 네 대에서는 계산도 병렬화
Apple은 두 가지 분산 실행 방식을 비교했다.
첫 번째는 Pipeline Parallelism(파이프라인 병렬화)이다.
이 방식에서는 모델의 여러 계층을 서로 다른 컴퓨터에 나눠 배치한다.
예를 들어 첫 번째 Mac Studio가 모델의 앞부분을 계산하고, 그 결과를 두 번째 Mac Studio로 전달한다.
두 번째 컴퓨터는 나머지 계층을 계산해 출력 결과를 만든다.
장점은 구현이 비교적 단순하다는 것이다.
하지만 하나의 토큰을 생성할 때 두 컴퓨터가 순서대로 계산하는 부분이 많아, 컴퓨터 수를 늘려도 출력 속도가 크게 높아지지 않을 수 있다.
두 번째는 Tensor Parallelism(텐서 병렬화)이다.
Tensor Parallelism은 하나의 모델 계층 안에서 수행하는 행렬 계산 자체를 여러 컴퓨터에 나누는 방식이다.
여러 장치가 동시에 계산할 수 있으므로 이론적으로 처리 속도를 더 높일 수 있다.
하지만 계산 과정에서 장치 사이에 훨씬 많은 데이터 교환이 필요하다.
각 계층의 입력과 출력을 계속 주고받아야 하기 때문이다.
따라서 네트워크의 지연시간과 대역폭이 매우 중요해진다.
Thunderbolt 5와 RDMA
Apple은 이를 위해 Thunderbolt 5로 여러 Mac Studio를 연결했다.
연결에는 macOS 26.2에서 제공되는 RDMA over Thunderbolt 기능을 활용했다.
RDMA(Remote Direct Memory Access)는 한 컴퓨터가 다른 컴퓨터의 메모리에 효율적으로 접근하도록 지원하는 기술이다.
일반적인 네트워크 통신에서는 운영체제와 CPU가 데이터 전송 과정에 많이 개입할 수 있다.
RDMA는 이런 부담을 줄여 대량의 데이터를 낮은 지연시간으로 전달하도록 돕는다.
Apple의 MLX는 이를 활용하는 jaccl 통신 백엔드를 제공한다.
또한 MLX 0.30.1 이상에서는 여러 Mac 사이에 필요한 집합 통신을 수행할 수 있다.
Apple의 시험 환경에서는 Mac Studio 두 대를 연결할 때 두 개의 Thunderbolt 케이블을 사용해 통신 대역폭을 높였다.
네 대를 연결할 때는 컴퓨터들이 서로 직접 통신할 수 있는 메쉬 구조를 사용했다.
이 방식은 모델의 크기에 따라 분산 실행 전략을 다르게 선택할 수 있도록 한다.
실제 성능 평가
Apple은 8,192토큰의 입력을 제공한 뒤 128개의 출력 토큰을 생성하는 조건에서 여러 구성을 비교했다.
Muse Spark Open의 출력 속도는 다음과 같았다.
| 실행 구성 | 출력 속도 |
|---|---|
| M5 Ultra Mac Studio 2대, 파이프라인 병렬화 | 15.74토큰/초 |
| M5 Ultra Mac Studio 2대, 텐서 병렬화 | 24.99토큰/초 |
| M5 Ultra Mac Studio 4대, 텐서 병렬화 | 36.73토큰/초 |
같은 모델을 실행하더라도 어떤 병렬화 방식을 사용하느냐에 따라 출력 속도가 크게 달라졌다는 점이 중요하다.
Mac Studio 두 대에서 텐서 병렬화를 사용하면 파이프라인 병렬화보다 빠르게 토큰을 생성했다.
네 대를 사용하면 처리량이 더 증가했다.
다만 컴퓨터 수를 두 배로 늘린다고 속도가 정확히 두 배가 되지는 않았다.
여러 장치 사이에서 데이터를 전달하는 데 시간이 필요하기 때문이다.
Apple은 긴 입력을 처리하는 상황에서는 일부 텐서 병렬화 구성이 오히려 파이프라인 병렬화보다 느려질 수 있다고 설명했다.
특히 입력 길이가 65,536토큰인 경우 모델의 전문가 네트워크 결과를 서로 전달하는 통신 부담이 커질 수 있었다.
즉 분산 추론에서는 단순히 컴퓨터를 많이 연결하는 것보다 입력 길이와 모델 구조, 통신 비용에 맞는 실행 방식을 선택하는 것이 중요하다.
이전 세대 Mac과의 차이
Apple은 Muse Spark Open뿐 아니라 상대적으로 작은 모델도 평가했다.
비교 대상에는 270억 파라미터 규모의 Qwen 3.8과 1,280억 파라미터 규모의 Mistral Medium 3.5가 포함됐다.
이 모델들은 512GB 메모리를 가진 Mac Studio 한 대에서도 실행할 수 있었다.
M5 Ultra에서는 TTFT(Time to First Token, 요청을 보낸 뒤 첫 번째 토큰이 생성되기까지 걸리는 시간)가 M3 Ultra 대비 최대 4.6배 개선됐다.
출력 토큰 생성 속도는 최대 약 1.6배 증가했다.
Apple은 이 차이를 계산 성능과 메모리 대역폭의 변화로 설명한다.
입력 전체를 처리하는 단계에서는 많은 행렬 계산이 필요하다.
반면 출력 토큰을 반복해서 생성할 때는 모델 가중치와 이전 계산 결과를 계속 읽어야 하므로 메모리 대역폭이 중요해진다.
M5 Ultra의 통합 메모리 대역폭은 1.2TB/s다.
이전 M3 Ultra의 약 819GB/s보다 높다.
다만 이 수치는 Apple이 특정 모델과 설정에서 측정한 결과이며 모든 AI 작업이 동일하게 빨라진다는 의미는 아니다.
또한 Mac Studio 여러 대를 사용하는 구성은 고가의 하드웨어가 필요하다.
따라서 개인 개발자가 초대형 모델을 저렴하게 실행할 수 있게 됐다고 단순화할 수는 없다.
그럼에도 이번 결과는 대규모 오픈웨이트 모델을 기업이나 연구자의 자체 공간에서 실행하는 방법이 다양해지고 있다는 점을 보여준다.
특히 외부 AI API에 민감한 데이터를 보내기 어려운 조직에는 로컬 추론 환경이 새로운 선택지가 될 수 있다.
4️⃣ 산업·정책·안전
Anthropic, 외부 평가기관 METR 연구원 6명에게 내부 시스템 접근 허용…프런티어 AI 위험의 독립 평가 확대
- 발표일: 2026-10-15 — 정확한 게시 시각 미확인
- 적용 범위: 프런티어 AI 안전, 독립 감사, 모델 위험 평가, AI 거버넌스, 기업 내부 보안, 사고 공개
- 원문: Anthropic — An update on independent evaluators
Anthropic이 프런티어 AI 모델의 안전성을 평가하는 비영리 연구기관 METR 소속 연구원들에게 내부 시스템에 대한 광범위한 접근권한을 제공하기 시작했다고 발표했다.
이번 발표에서 중요한 변화는 단순히 외부 기관에 모델 API를 제공해 성능을 평가하도록 한 것이 아니라는 점이다.
Anthropic은 METR 연구원 6명이 회사 내부의 위험 평가 조직과 비슷한 수준으로 정보에 접근하도록 허용했다.
이를 위해 업무용 컴퓨터와 사무공간, 내부 도구에 대한 접근권한을 제공했다.
Anthropic은 이런 방식을 Employee-Like Access(직원과 유사한 접근권한)라고 설명한다.
외부 평가기관이 모델 API만 사용해서는 부족한 이유
AI 모델의 위험성을 평가하는 가장 일반적인 방법 가운데 하나는 모델에게 여러 질문과 작업을 제시하고 결과를 확인하는 것이다.
예를 들어 모델이 위험한 사이버보안 작업을 얼마나 잘 수행하는지, 특정 안전장치를 우회할 수 있는지 시험할 수 있다.
그러나 외부 기관이 공개 API만 사용하면 모델이 어떤 방식으로 학습됐는지, 기업 내부에서 어떤 안전 문제가 발견됐는지 알기 어려울 수 있다.
개발사가 보유한 내부 평가 결과와 외부 평가자가 확인할 수 있는 정보 사이에 차이가 생기는 것이다.
Anthropic은 이런 정보 비대칭을 줄이기 위해 외부 평가기관에 더 많은 정보를 제공하겠다고 설명했다.
정보 비대칭은 서로 다른 주체가 가진 정보의 양과 질에 차이가 있는 상황을 의미한다.
예를 들어 기업은 자신의 제품에서 발생한 내부 문제를 알고 있지만 외부 소비자는 그 사실을 모를 수 있다.
AI 모델에서는 기업 내부의 위험 평가 결과와 안전장치의 동작 방식, 학습 과정의 특징 등이 이런 정보에 포함될 수 있다.
METR 연구원들은 일부 제한된 정보를 제외하면 Anthropic의 내부 위험 평가팀과 유사한 자료에 접근할 수 있다.
실제로 제공하는 정보와 제한 범위
Anthropic은 METR 연구원들에게 내부 도구와 시스템에 대한 접근을 허용하지만 모든 기업 정보를 제한 없이 공개하는 것은 아니다.
고객 정보와 법률상 비밀유지특권이 적용되는 자료, 일부 모델 아키텍처 관련 정보 등은 접근이 제한될 수 있다.
또한 METR의 모든 직원이 동일한 내부 시스템에 접근하는 것도 아니다.
Anthropic과 별도 협약을 체결한 소수의 평가 인력에게만 접근이 제공된다.
이 인력은 회사의 보안 기준을 따라야 한다.
이는 외부 연구자가 내부 정보를 무제한으로 복사하거나 다른 기관에 전달할 수 있다는 의미가 아니다.
Anthropic은 이런 제한이 고객과 기업의 기밀을 보호하면서도 실제 위험 평가에 필요한 정보를 제공하기 위한 절충이라고 설명한다.
평가 결과를 회사가 임의로 차단할 수는 없다
이번 협력에서 중요한 부분은 평가 결과를 공개할 권한이다.
Anthropic은 METR이 자사의 AI 모델과 안전관리 체계에 대한 분석을 공개할 수 있다고 밝혔다.
Anthropic이 평가 결과의 출판 자체를 거부할 수는 없다.
다만 사전에 정의된 일부 기밀정보는 공개 전에 삭제하도록 요구할 수 있다.
이를 Redaction(비공개 처리 또는 가림 처리)이라고 한다.
예를 들어 평가 보고서에 고객의 개인정보나 공개하면 실제 공격에 악용될 수 있는 보안 세부사항이 포함됐다면 해당 부분을 가릴 수 있다.
METR은 Anthropic이 어떤 종류의 정보를 비공개 처리했는지 설명할 수 있으며, 해당 조치가 정당했는지에 대한 의견도 밝힐 수 있다.
단, 실제 비공개 처리된 정보를 공개해서는 안 된다.
이 구조는 AI 개발사가 자신에게 유리한 평가 결과만 선택적으로 공개하는 문제를 줄이려는 접근이다.
그러나 외부 평가기관의 독립성이 완전하게 보장된다고 단정할 수는 없다.
평가기관이 기업 내부에서 활동할 때는 정보 접근권한과 계약 조건, 보안 규정의 영향을 받을 수 있기 때문이다.
따라서 실제 독립성이 얼마나 확보되는지는 앞으로 METR이 공개하는 보고서와 평가 방식까지 살펴봐야 판단할 수 있다.
다른 평가기관과의 협력도 진행
Anthropic은 METR 외에도 SecureBio와 Accenture를 외부 평가기관으로 활용하고 있다고 밝혔다.
또한 Hugging Face 등 다른 기관과도 초기 협의를 진행하고 있다.
다만 이들 기관에는 현재 METR과 같은 수준의 정보 접근권한이 제공되는 것은 아니다.
Anthropic은 협력 초기 단계에서는 접근할 수 있는 정보와 결과 공개 권한을 제한하고, 이후 신뢰와 평가 능력이 확인되면 협력 범위를 확대할 수 있다고 설명한다.
이번 발표는 실제 독립 평가 체계를 확대하기 위한 조치지만, 새로운 AI 안전성 평가 결과 자체를 공개한 것은 아니다.
또한 외부기관의 접근을 허용했다고 해서 모든 모델 위험이 해결됐다는 의미도 아니다.
이번 변화는 프런티어 AI의 안전성을 개발사 자체 보고서에만 의존하지 않고, 외부 평가자가 개발사 내부의 실제 정보를 확인한 뒤 판단할 수 있도록 하는 제도적·운영적 실험이라는 점에서 의미가 있다.
Google, 400개 이상 언론사에 AI 콘텐츠 사용료 지급…뉴스 요약·오디오 브리핑에 정식 콘텐츠 라이선스 확대
- 발표일: 2026-10-15 — 정확한 게시 시각 미확인
- 적용 범위: 생성형 AI 저작권, 언론 콘텐츠 라이선스, Google News, AI 요약, 오디오 브리핑, 디지털 미디어 산업
- 원문: Google — 400 publications are now partnering with us on our News AI pilot program
Google이 자사의 News AI 파일럿 프로그램에 참여하는 언론 매체가 전 세계 400개 이상으로 확대됐다고 발표했다.
이번 프로그램은 지난해 시작됐다.
따라서 10월 15일에 새로운 콘텐츠 라이선스 제도가 처음 만들어진 것은 아니다.
이번 발표의 새로운 내용은 참여 언론사의 규모가 400개 이상으로 확대됐고, Google이 실제로 어떤 AI 뉴스 기능에 콘텐츠를 활용하는지 구체적으로 설명했다는 점이다.
참여 매체에는 Axios, CNN, Financial Times, Forbes 같은 국제적인 언론사뿐 아니라 미국의 여러 지역 언론사도 포함된다.
AI가 뉴스 콘텐츠를 사용하는 방식
최근 생성형 AI는 사용자의 질문에 답하면서 언론사의 기사를 요약하거나 여러 보도를 결합해 설명할 수 있다.
문제는 이런 과정에서 사용자가 원래 기사를 제공한 언론사의 웹사이트를 방문하지 않을 수 있다는 점이다.
기존 온라인 뉴스 산업은 상당 부분 검색과 소셜미디어에서 발생하는 방문 트래픽에 의존해 왔다.
사용자가 기사를 읽기 위해 언론사 웹사이트를 방문하면 광고 수익이나 구독 전환이 발생할 수 있다.
하지만 AI가 기사 내용을 충분히 요약해 제공한다면 일부 사용자는 원문을 열어볼 필요성을 덜 느낄 수 있다.
이런 변화는 뉴스 콘텐츠를 생산하는 기업과 AI 서비스를 운영하는 플랫폼 사이의 경제적 관계를 복잡하게 만든다.
Google의 News AI 프로그램은 언론사가 제공하는 콘텐츠를 새로운 AI 기능에 사용하는 대신 참여 매체에 라이선스 비용을 지급하는 방식을 채택했다.
Google은 참여 매체가 향상된 콘텐츠를 제공하고 이를 AI 기능에 사용할 수 있도록 허용하는 대가로 비용을 지급한다고 설명한다.
실제 활용 기능
프로그램에서 언급한 기능 가운데 하나는 기사의 심층 개요(Article Overview)다.
사용자가 Google News에서 언론사의 콘텐츠를 살펴볼 때 기사를 이해하는 데 도움이 되는 추가적인 맥락과 개요를 제공하는 방식이다.
다른 하나는 맞춤형 오디오 브리핑이다.
사용자는 뉴스 콘텐츠를 자신에게 적합한 음성 브리핑 형태로 들을 수 있다.
이는 기존 기사를 단순히 음성으로 읽어주는 기능과는 다르다.
AI가 여러 정보를 요약하고 사용자의 관심사에 맞게 구성하는 작업이 포함될 수 있기 때문이다.
Google은 이러한 기능에 출처 표시와 원문으로 연결되는 직접 링크를 제공한다고 밝혔다.
이 구조는 AI가 생성한 결과를 독립적인 콘텐츠처럼 제공하기보다 원래 정보를 생산한 언론사와 연결하려는 방식이다.
다만 출처 링크를 제공한다고 해서 사용자가 실제로 원문을 방문하는 비율이나 언론사의 수익이 얼마나 증가하는지는 별개의 문제다.
이번 발표에서는 이런 효과를 검증할 수 있는 구체적인 독립 데이터가 제시되지 않았다.
라이선스 계약과 저작권 분쟁은 구분해야 한다
이번 프로그램이 모든 언론사의 콘텐츠 사용 문제를 해결한 것은 아니다.
Google이 비용을 지급하는 대상은 프로그램에 참여하고 관련 계약을 체결한 언론사다.
또한 이번 발표만으로 Google의 다른 AI 서비스에서 발생할 수 있는 모든 뉴스 콘텐츠 사용이 같은 계약의 적용을 받는다고 볼 수 없다.
구체적인 지급 금액과 계약 기간, 매체별 조건도 공개되지 않았다.
따라서 400개 이상의 언론사가 참여한다는 사실을 모든 언론사에 동일한 금액을 지급한다는 의미로 해석해서는 안 된다.
이번 발표는 법원 판결이나 새로운 저작권 법률의 시행도 아니다.
Google과 개별 콘텐츠 제공업체 사이의 상업적인 라이선스 프로그램 확대에 관한 발표다.
그럼에도 생성형 AI 시대의 뉴스 콘텐츠 유통이 어떤 방향으로 변화하는지 보여준다.
기존에는 검색 서비스가 언론사의 원문을 찾아주는 역할을 중심으로 발전했다.
이제는 AI가 뉴스 내용을 새로운 형태로 가공하고 전달하면서 원문 콘텐츠에 대한 이용 권한과 보상, 출처 표시를 서비스 설계의 일부로 포함하는 방향이 나타나고 있다.
📚 추천 글
Context Engineering: How Deep Agents Remember
- 저자: Jess Weng
- 발행: LangChain
- 게시일: 2026-10-14
- 원문: LangChain — Context Engineering: How Deep Agents Remember
AI 에이전트가 오랫동안 작업을 수행할 때 발생하는 가장 중요한 문제 가운데 하나는 컨텍스트가 계속 쌓이면서 오히려 판단 품질이 떨어질 수 있다는 점이다.
예를 들어 시장 조사를 수행하는 에이전트가 있다고 가정해 보자.
에이전트는 다섯 개 기업의 매출 자료를 가져오고, 관련 기사를 검색하고, 내부 문서를 읽은 뒤 최종 보고서를 작성한다.
처음에는 필요한 정보가 많지 않다.
하지만 작업이 진행될수록 이전 검색 결과와 대용량 데이터, 중간 메모와 수정 전 보고서가 대화에 계속 추가된다.
최종 보고서를 작성하는 시점에는 실제로 필요한 정보보다 과거 작업 기록이 훨씬 많아질 수 있다.
이런 상황을 Context Rot(컨텍스트 품질 저하)라고 한다.
컨텍스트 창에 너무 많은 정보가 들어가면서 모델이 중요한 내용을 찾기 어려워지고, 오래된 자료나 관련 없는 도구 결과의 영향을 받는 현상이다.
이 글은 LangChain의 오픈소스 에이전트 실행 환경인 Deep Agents가 이 문제를 해결하기 위해 사용하는 다섯 가지 방법을 설명한다.
큰 도구 결과는 삭제하지 않고 외부에 저장
첫 번째 방법은 Offloading(외부 저장)이다.
예를 들어 데이터 조회 도구가 수만 행의 결과를 반환했다고 가정해 보자.
일반적인 에이전트는 이 데이터를 모두 모델의 컨텍스트에 포함할 수 있다.
하지만 실제 작업에서는 수만 행 가운데 일부 정보만 필요할 수 있다.
Deep Agents는 도구 결과가 약 2만 토큰을 넘으면 전체 결과를 파일 시스템에 저장하고, 모델에는 짧은 미리보기와 파일 경로만 제공한다.
이후 모델이 특정한 정보가 필요할 때 해당 파일의 관련 부분을 다시 읽을 수 있다.
중요한 점은 데이터를 무조건 잘라내서 버리는 방식이 아니라는 것이다.
긴 입력을 단순히 잘라내면 나중에 필요한 정보가 사라질 수 있다.
반면 외부에 저장하면 컨텍스트 사용량을 줄이면서 원본을 다시 확인할 수 있다.
컨텍스트가 길어지면 이전 대화를 요약
두 번째 방법은 Summarization(요약 또는 압축)이다.
도구 결과를 외부에 저장하더라도 작업이 길어지면 대화 기록 자체가 계속 늘어난다.
Deep Agents는 컨텍스트 사용량이 기본적으로 최대 크기의 85%를 넘으면 이전 대화를 요약한다.
최근 메시지는 원문 그대로 유지하고 오래된 기록만 짧은 요약으로 대체한다.
하지만 요약 과정에서 정보가 손실될 수 있다.
이를 해결하기 위해 원본 대화 기록을 별도의 파일에 보관한다.
모델이 나중에 과거의 구체적인 내용을 다시 확인해야 한다면 해당 파일을 읽을 수 있다.
이렇게 하면 컨텍스트를 압축하면서도 필요한 경우 원래 증거로 돌아갈 수 있는 구조를 만들 수 있다.
작업에 필요한 지침만 불러오기
세 번째 방법은 Skills다.
Skill은 특정한 작업을 수행하는 데 필요한 지침과 참고 자료, 스크립트를 묶은 구성요소다.
예를 들어 기업에서 사용하는 분기 보고서 템플릿을 하나의 Skill로 정의할 수 있다.
하지만 에이전트가 보고서와 관계없는 작업을 수행하는 동안에도 전체 템플릿을 계속 컨텍스트에 넣어둘 필요는 없다.
Deep Agents는 Skill의 이름과 짧은 설명만 기본적으로 제공한다.
모델이 해당 작업을 수행해야 한다고 판단하면 그때 전체 지침을 읽는다.
이를 Progressive Disclosure(필요한 정보를 단계적으로 공개하는 방식)이라고 한다.
여러 가지 작업을 수행하는 에이전트에서 매번 모든 지침을 입력하는 비용을 줄일 수 있다.
복잡한 작업은 하위 에이전트에 분리
네 번째 방법은 Subagent(하위 에이전트)다.
예를 들어 다섯 개 기업의 시장 동향을 조사하는 작업에서는 각각의 기업에 대해 수많은 검색과 문서 읽기가 발생할 수 있다.
모든 중간 결과를 상위 에이전트에 전달하면 최종 보고서를 작성할 때 관련 없는 정보가 너무 많이 쌓인다.
Deep Agents는 기업별 조사를 별도의 하위 에이전트가 수행하도록 한다.
하위 에이전트는 자신만의 컨텍스트 창에서 검색과 분석을 수행하고, 상위 에이전트에는 필요한 결과만 전달한다.
상위 에이전트는 검색 과정의 모든 기록을 보지 않아도 된다.
또한 작업이 비교적 명확하게 구분된다면 하위 에이전트에는 비용이 저렴한 모델을 사용할 수도 있다.
장기 기억을 모델 제공업체와 분리
다섯 번째 방법은 Long-Term Memory(장기 기억)이다.
사용자가 보고서의 특정 형식을 선호하거나 조직에서 사용하는 용어와 절차가 있다면 에이전트가 다음 작업에서도 이를 활용할 수 있어야 한다.
Deep Agents는 이런 정보를 일반적인 Markdown 파일에 저장한다.
새로운 대화가 시작되면 필요한 내용을 읽어 시스템 지침에 추가한다.
이 방식의 장점은 기억이 특정 모델 제공업체의 내부 기능에 묶이지 않는다는 것이다.
예를 들어 오늘은 OpenAI 모델을 사용하고 다음 주에는 다른 모델로 교체하더라도 같은 기억 파일을 사용할 수 있다.
이는 모델의 추론 능력과 조직이 축적한 업무 지식을 분리하는 설계다.
이 글에서 가장 중요한 부분은 AI 에이전트의 기억이 단순히 대화 전체를 오래 보관하는 기능이 아니라는 점이다.
오히려 현재 작업에 필요한 정보만 모델에 제공하고, 나머지는 다시 찾을 수 있는 형태로 외부에 유지하는 기술에 가깝다.
장시간 실행되는 코딩 에이전트나 조사 에이전트를 개발할 때 컨텍스트 관리가 왜 중요한지 이해하기 좋은 자료다.
The Most Common Questions About Agent Evals, Answered
- 저자: Divya Santhanam
- 발행: LangChain
- 게시일: 2026-10-15
- 원문: LangChain — The Most Common Questions About Agent Evals, Answered
AI 에이전트를 개발할 때 모델이 올바르게 동작하는지 어떻게 테스트해야 할까?
일반적인 소프트웨어에서는 같은 입력을 제공하면 동일한 결과가 나오는 경우가 많다.
예를 들어 함수에 특정 숫자를 전달했을 때 정해진 값을 반환하는지 자동화 테스트로 확인할 수 있다.
하지만 AI 에이전트에서는 같은 요청을 여러 번 실행해도 다른 답변이 생성될 수 있다.
또한 최종 결과가 동일하더라도 해당 결과를 얻기까지 수행한 행동이 다를 수 있다.
예를 들어 여행 예약 에이전트가 사용자가 요청한 날짜에 맞게 예약을 완료했다고 가정해 보자.
최종 예약 정보는 정확하지만, 그 과정에서 불필요한 외부 도구를 사용하거나 사용자 승인 없이 결제를 진행했다면 안전한 시스템이라고 볼 수 없다.
따라서 AI 에이전트는 최종 답변뿐 아니라 중간 행동과 실제 시스템에 남긴 결과까지 평가해야 한다.
이 글은 이런 평가를 설계하는 방법을 실제 개발 절차와 연결해 설명한다.
처음부터 거대한 평가 데이터셋이 필요하지는 않다
LangChain은 에이전트 평가를 시작할 때 먼저 실제 실행 기록(Trace)을 읽어보라고 제안한다.
Trace는 에이전트가 받은 입력과 생성한 출력, 모델 호출, 도구 실행과 중간 결과를 기록한 자료다.
예를 들어 검색 에이전트가 잘못된 날짜의 자료를 검색했다면 Trace에서 어떤 검색어를 생성했고 어떤 결과를 사용했는지 확인할 수 있다.
평가를 처음 시작하는 팀이라면 10~20개 정도의 실제 사례로도 충분하다고 설명한다.
중요한 것은 평가 데이터의 양보다 어떤 행동을 확인할 것인지 명확하게 정하는 것이다.
예를 들어 여행 예약 에이전트라면 사용자가 지정한 날짜를 유지하는지, 예산을 초과하지 않는지부터 검증할 수 있다.
현재 에이전트를 이 데이터셋으로 실행해 결과를 기록하면 Baseline(기준 성능)이 만들어진다.
이후 프롬프트나 모델, 도구를 변경할 때 같은 데이터셋을 다시 실행해 결과를 비교할 수 있다.
실제 운영에서 새로운 오류가 발견되면 해당 사례를 평가 데이터에 추가한다.
이런 방식으로 평가 데이터셋이 실제 서비스의 실패 경험을 반영하면서 점차 발전한다.
Offline Eval과 Online Eval
에이전트 평가는 크게 두 가지로 나뉜다.
Offline Evaluation(오프라인 평가)은 기능을 배포하기 전에 미리 준비한 데이터셋으로 에이전트를 시험하는 방식이다.
예를 들어 새로운 모델로 교체한 뒤 기존 질문 100개를 다시 실행해 정확도가 떨어지지 않았는지 확인할 수 있다.
Online Evaluation(온라인 평가)은 실제 서비스에서 발생한 실행 기록을 지속적으로 분석하는 방식이다.
오프라인 평가에는 정해진 정답이 있을 수 있지만, 실제 사용자의 모든 질문에 대해 사전에 정답을 준비하는 것은 어렵다.
따라서 온라인 평가에서는 출력 형식이 올바른지 검사하거나 다른 LLM을 이용해 응답 품질을 평가하기도 한다.
여기서 다른 모델이 답변을 평가하는 방식을 LLM-as-a-Judge라고 한다.
하지만 LLM 평가자 역시 오류를 만들 수 있다.
따라서 중요한 평가 기준에서는 일반 프로그램 코드와 사람의 검토를 함께 사용하는 것이 필요하다.
LangChain은 온라인 평가에서 발견한 실패를 다시 오프라인 데이터셋에 추가하는 구조를 강조한다.
즉 실제 서비스에서 오류가 발생할수록 이후 배포의 검증 체계가 강화되는 것이다.
어떤 평가 방법을 선택할까?
글에서는 네 가지 평가 방법을 구분한다.
첫 번째는 Code Evaluator다.
결과를 일반 프로그램 코드로 명확하게 확인할 수 있을 때 사용한다.
예를 들어 사용자가 최대 10만 원을 지출하라고 요청했다면 실제 결제 금액이 그 이하인지 검사할 수 있다.
두 번째는 LLM-as-a-Judge다.
답변이 이해하기 쉬운지, 필요한 설명을 충분히 제공했는지처럼 정해진 규칙만으로 확인하기 어려운 항목을 평가한다.
세 번째는 Human Review다.
사람이 실제 결과를 검토한다.
비용과 시간이 많이 들지만, 복잡한 전문 업무에서 잘못된 평가 기준을 발견하는 데 중요하다.
네 번째는 Pairwise Evaluation이다.
두 모델이나 프롬프트가 만든 결과를 나란히 비교해 어느 쪽이 더 적합한지 선택한다.
이 방식은 새로운 모델을 도입할 때 기존 모델과 직접 비교하는 데 유용하다.
최종 답변이 아니라 실제 시스템 상태를 검사
이 글에서 특히 중요한 부분은 Final State Evaluation(최종 상태 평가)이다.
예를 들어 코딩 에이전트가 오류를 수정했다고 답변했다고 가정해 보자.
모델이 수정했다고 설명하는 내용만 읽어서는 실제로 오류가 해결됐는지 알 수 없다.
대신 코드를 실행하고 테스트를 수행해야 한다.
여행 예약 에이전트라면 최종 메시지에 올바른 예약 정보를 표시하는지뿐 아니라 실제 예약 시스템에 어떤 기록이 생성됐는지 확인해야 한다.
이처럼 평가 대상이 단순한 텍스트에서 실제 외부 환경의 상태 변화로 확장된다.
LangChain은 이런 평가를 위해 Harbor라는 오픈소스 평가 실행 환경을 소개한다.
Harbor는 Terminal-Bench 같은 장시간 작업 평가에 사용되는 하네스다.
각 평가 작업을 별도의 컨테이너 환경에서 실행하고, 에이전트가 남긴 파일과 시스템 상태를 검사할 수 있다.
Container(컨테이너)는 프로그램을 격리된 실행 환경에서 실행할 수 있도록 하는 기술이다.
이를 사용하면 서로 다른 평가 실행이 같은 파일을 수정하거나 이전 결과에 영향을 주는 문제를 줄일 수 있다.
예를 들어 에이전트가 코드 저장소를 수정하는 작업을 평가한다면, 테스트마다 저장소의 깨끗한 복사본을 준비할 수 있다.
이 글은 AI 에이전트 평가가 단순히 모델의 답변에 점수를 매기는 작업이 아니라 사용자의 요구사항이 실제로 지켜졌는지 확인하는 소프트웨어 검증 체계라는 점을 보여준다.
특히 프롬프트나 모델을 자주 변경하는 개발팀이 회귀 테스트를 설계할 때 참고하기 좋은 자료다.
Tokenmaxxing BERT: 50x faster tokenization
- 저자: Simon Brandeis
- 발행: Hugging Face
- 게시일: 2026-10-15
- 원문: Hugging Face — Tokenmaxxing BERT: 50x faster tokenization
AI 모델을 더 빠르게 실행하려면 반드시 모델 자체를 변경해야 할까?
이 글은 모델의 신경망 구조나 학습 결과를 바꾸지 않고 모델에 입력하기 전 텍스트를 처리하는 코드만 최적화해 큰 성능 향상을 얻은 사례를 설명한다.
주인공은 2018년에 공개된 BERT다.
BERT는 최신 생성형 언어모델보다 오래된 기술이지만 여전히 많은 서비스에서 사용된다.
특히 문장의 의미를 숫자 벡터로 변환하는 Embedding(임베딩), 검색 결과의 관련성을 평가하는 Reranking(재순위화), 텍스트 분류 등에 BERT 계열 모델이 널리 활용된다.
이런 모델은 RAG 기반 서비스에서도 중요하다.
RAG(Retrieval-Augmented Generation)는 외부 문서에서 관련 정보를 검색한 뒤 언어모델에 제공하는 방식이다.
검색과 문서 분석을 위해 수많은 텍스트를 반복해서 처리하는 환경에서는 토크나이저의 속도도 전체 성능에 영향을 줄 수 있다.
토크나이저가 하는 일
Tokenizer(토크나이저)는 문장을 AI 모델이 처리할 수 있는 작은 단위인 토큰으로 나누는 도구다.
모델은 일반적으로 문자를 직접 처리하지 않고 토큰마다 부여된 숫자 ID를 이용해 계산한다.
하지만 문장을 토큰으로 나누기 전에 텍스트를 일정한 규칙으로 변환해야 하는 경우가 있다.
예를 들어 대문자를 소문자로 바꾸거나, 서로 다른 방식으로 표현된 악센트 문자를 통일할 수 있다.
이를 Normalization(정규화)이라고 한다.
유니코드에서는 사람이 보기에 같은 글자도 서로 다른 숫자 코드의 조합으로 표현될 수 있다.
예를 들어 프랑스어의 é는 하나의 문자로 표현할 수도 있고, e와 악센트 기호를 결합해 표현할 수도 있다.
정규화는 이런 서로 다른 표현을 모델이 일관되게 처리하도록 만든다.
BERT의 토크나이저는 문자 정리, 중국어 문자 주변의 공백 처리, 유니코드 분해, 악센트 제거, 소문자 변환 등의 과정을 수행한다.
이런 작업 자체는 복잡하지 않아 보인다.
그러나 매우 긴 문서를 처리하거나 수백만 개의 문장을 반복해서 변환하는 상황에서는 계산 비용이 커질 수 있다.
실제 병목은 토큰 분할이 아니라 정규화였다
저자는 Hugging Face의 tokenizers 라이브러리를 분석하면서 예상하지 못한 문제를 발견했다.
BERT 토크나이저가 텍스트를 처리하는 시간 가운데 약 88%가 정규화 단계에서 사용되고 있었다.
반면 실제로 토큰을 선택하는 WordPiece 처리에는 약 8%만 사용됐다.
WordPiece는 단어를 자주 등장하는 작은 문자열 단위로 나누는 토큰화 알고리즘이다.
즉 토크나이저의 핵심 작업처럼 보이는 토큰 분할보다, 그 전에 수행하는 문자 정리 작업이 훨씬 많은 시간을 차지하고 있었다.
문제의 주요 원인 가운데 하나는 악센트 문자를 판별하는 과정이었다.
기존 구현은 문자 하나를 처리할 때마다 유니코드 문자 목록을 검색했다.
이 목록에는 약 1,567개의 문자가 포함돼 있었다.
문자가 해당 목록에 존재하는지 찾기 위해 이진 탐색을 사용했다.
Binary Search(이진 탐색)는 정렬된 목록의 중간값을 기준으로 검색 범위를 반복해서 절반으로 줄이는 알고리즘이다.
일반적으로 효율적인 검색 방식이지만, 수백만 개 문자의 각각에 대해 반복하면 상당한 비용이 발생할 수 있다.
특히 CPU가 어떤 메모리 위치를 읽을지 예측하기 어려워지는 상황에서는 성능이 떨어질 수 있다.
더 큰 문제는 이런 검사가 영어 알파벳처럼 정규화가 필요하지 않은 문자에도 적용되고 있었다는 점이다.
ASCII는 복잡한 유니코드 검사를 건너뛴다
저자는 실제 텍스트 데이터의 특성에 주목했다.
영어 문장과 일반적인 소스코드에는 ASCII 문자가 매우 많이 사용된다.
ASCII는 기본적인 영문 알파벳과 숫자, 문장부호 등을 표현하는 문자 집합이다.
ASCII 문자는 UTF-8에서 한 바이트로 표현된다.
또한 유니코드 정규화 과정에서 대부분의 일반적인 ASCII 문자는 복잡한 변환이 필요하지 않다.
따라서 저자는 ASCII로만 구성된 구간을 찾아 불필요한 정규화 작업을 건너뛰도록 코드를 변경했다.
이때 사용한 기술이 SIMD(Single Instruction, Multiple Data)다.
SIMD는 하나의 CPU 명령으로 여러 데이터에 같은 연산을 동시에 수행하는 방법이다.
이번 구현에서는 16바이트를 한 번에 검사해 해당 구간이 모두 ASCII인지 확인한다.
복잡한 유니코드 변환이 필요하지 않다면 문자 하나씩 별도로 검사하지 않고 해당 구간을 빠르게 통과시킨다.
영어와 소스코드처럼 ASCII 문자가 많은 데이터에서 특히 효과적인 방식이다.
유니코드 문자도 캐시를 활용
ASCII가 아닌 문자에서는 다른 방법을 사용했다.
러시아어나 그리스어처럼 특정한 문자 체계를 사용하는 텍스트는 같은 범위의 유니코드 문자가 반복해서 나타나는 경우가 많다.
저자는 이를 이용해 문자 256개를 하나의 구간으로 묶었다.
해당 구간에서 어떤 문자가 정규화 대상인지 처음 한 번 계산한 뒤 결과를 캐시에 저장한다.
이후 같은 구간의 다른 문자를 처리할 때는 복잡한 목록 검색을 다시 수행하지 않고 캐시에서 결과를 읽는다.
Cache(캐시)는 반복해서 사용하는 데이터를 빠르게 접근할 수 있는 위치에 저장하는 기술이다.
CPU 내부의 작은 캐시에 이런 정보를 유지하면 주 메모리에 접근하는 횟수를 줄일 수 있다.
또한 실제로 텍스트를 수정할 필요가 없는 경우에는 새로운 문자열을 만들지 않고 원래 데이터를 그대로 반환하도록 했다.
이는 불필요한 메모리 할당과 복사를 줄이는 최적화다.
최대 50배 개선, 그러나 모든 언어에서 같은 결과는 아니다
이번 최적화는 토크나이저가 최종적으로 생성하는 토큰 ID를 변경하지 않았다.
저자는 기존 버전과 최적화된 버전의 출력이 동일하다는 사실을 검증했다.
그 상태에서 처리 속도를 비교했다.
기존 tokenizers 0.23 버전과 비교하면 새로운 최적화 구현은 일부 BERT 텍스트 처리 작업에서 약 50배 높은 처리량을 기록했다.
이는 최근 개발 중인 1.0 계열에서 이미 이뤄진 개선과 이번 추가 최적화의 효과를 합친 수치다.
이번 변경만으로 기존 최신 구현보다 50배 빨라졌다는 의미는 아니다.
저자는 최신 개발 버전 대비 추가로 최대 약 5.7배의 성능 향상을 얻었다고 설명한다.
또한 성능 개선은 입력 데이터의 특성에 따라 달랐다.
영어와 소스코드에서는 ASCII 구간을 건너뛰는 효과가 컸다.
러시아어와 그리스어, 아랍어에서는 유니코드 캐시를 이용한 최적화가 도움이 됐다.
반면 중국어 텍스트에서는 개선 효과가 거의 없었다.
일부 매우 짧은 입력에서는 최적화 코드의 추가적인 처리 비용 때문에 오히려 속도가 느려지기도 했다.
예를 들어 32바이트 이하의 짧은 입력이나 일부 중국어 데이터에서는 기존 구현이 더 유리한 경우가 있었다.
이는 중요한 결과다.
특정 벤치마크에서 높은 개선 수치가 나왔더라도 실제 사용하는 언어와 문서의 크기에 따라 최적화 효과가 달라질 수 있다는 의미이기 때문이다.
아직 정식 배포된 변경은 아니다
저자는 이번 최적화가 글을 공개한 시점에 PR 단계에 있다고 밝혔다.
따라서 Hugging Face의 모든 사용자가 이미 해당 성능 개선을 적용받고 있다는 의미는 아니다.
라이브러리의 실제 배포 버전과 변경사항의 병합 여부를 확인해야 한다.
연구에는 AMD EPYC와 Intel Xeon CPU가 사용됐으며, 여러 언어의 텍스트와 소스코드 데이터를 대상으로 결과를 측정했다.
또한 재현 가능한 벤치마크 코드도 공개했다.
이번 글이 특히 유용한 이유는 성능 문제의 원인을 실제 측정으로 찾은 뒤, 입력 데이터의 특성에 맞춰 필요한 계산을 줄였다는 점이다.
AI 서비스의 성능을 개선할 때는 모델 자체가 느린지, 토큰화와 데이터 전처리가 느린지, 외부 API나 네트워크가 병목인지 먼저 구분해야 한다.
실제 병목이 모델 바깥에 존재한다면 더 비싼 GPU나 더 작은 모델을 사용하는 것보다 일반적인 소프트웨어 최적화가 더 큰 효과를 낼 수 있다는 점을 구체적인 측정 결과로 보여주는 글이다.