AI 데일리 브리핑 — 2026-10-28
Soshy··조회수 —

기준 시점: 2026-10-28 06:00 KST (Asia/Seoul)
AI 동향 조사 범위: 2026-10-27 06:00 ~ 2026-10-28 06:00 KST
추천 글 범위: 2026-10-21 06:00 ~ 2026-10-28 06:00 KST
1️⃣ 주요 모델·연구
Google DeepMind, 실시간 음성·대화까지 생성하는 월드 모델 ‘Genie 4’ 공개…가상세계 안에서 날씨와 등장인물도 즉시 변경
- 발표일: 2026-10-27 — 정확한 게시 시각 미확인
- 적용 범위: 월드 모델, 멀티모달 생성형 AI, 로봇 시뮬레이션, 게임 개발, 영상 제작, 인터랙티브 콘텐츠
- 원문: Google DeepMind — Genie 4: A new generation of world simulation
Google DeepMind가 사용자의 행동에 따라 가상세계의 모습과 소리, 등장인물의 행동을 실시간으로 생성하는 새로운 AI 모델 Genie 4를 공개했다.
이번 모델은 기존 Genie 3의 후속 모델이다.
Genie 3가 사용자가 직접 이동하면서 탐색할 수 있는 가상환경을 생성하는 데 집중했다면, Genie 4는 시각적 사실성과 물리적 상호작용, 음성 생성과 장면의 일관성을 함께 개선하는 방향으로 발전했다.
특히 이번 모델은 Google의 Gemini 계열 모델과 결합해 복잡한 사건이 발생하는 가상세계를 유지하도록 설계됐다.
일반적인 영상 생성 모델과 비교하면 이 차이를 이해하기 쉽다.
영상 생성 모델은 사용자가 장면을 설명하면 정해진 길이의 동영상을 생성한다.
하지만 생성이 완료된 영상에서 사용자가 갑자기 다른 방향으로 이동하거나 등장인물에게 새로운 행동을 지시하기는 어렵다.
반면 Genie 4에서는 사용자가 가상공간을 탐색하면서 새로운 지시를 전달할 수 있다.
예를 들어 숲속을 걷는 가상환경을 생성했다고 가정해 보자.
사용자가 이동 방향을 바꾸면 모델은 새로운 시점에서 보이는 숲을 생성한다.
이후 비가 내리도록 요청하면 기존 공간을 유지하면서 날씨가 변하는 장면을 생성할 수 있다.
등장인물을 추가하거나 카메라를 이동시키는 것도 가능하다.
이런 기술을 World Model(월드 모델)이라고 한다.
월드 모델은 환경의 현재 상태와 사용자의 행동을 바탕으로 다음 상태가 어떻게 변할지 예측하거나 생성하는 AI 시스템이다.
영상과 소리를 하나의 세계로 생성
Genie 4의 가장 큰 변화 가운데 하나는 음성을 자체적으로 생성한다는 점이다.
기존 영상 생성 시스템에서는 영상과 소리를 별도의 모델로 생성한 뒤 결합하는 경우가 많았다.
예를 들어 AI가 바닷가 영상을 만들었다면 별도의 효과음 생성 시스템이 파도 소리를 추가할 수 있다.
하지만 화면에서 발생하는 사건과 소리가 정확하게 일치하도록 만들기는 쉽지 않다.
Genie 4는 환경을 생성하는 과정에서 배경 소음과 음악, 사람의 음성을 함께 생성한다.
Google DeepMind는 바람과 파도 소리, 악기 연주와 등장인물의 대화를 포함한 사례를 공개했다.
특히 등장인물이 사용자의 행동이나 새로운 상황에 맞춰 대화 내용을 변경할 수 있도록 설계됐다.
이것은 미리 녹음한 음성을 재생하는 방식과 다르다.
모델이 생성 중인 환경의 변화에 맞춰 소리와 대화를 생성하려는 접근이다.
다만 이 기능이 모든 장면에서 물리적으로 정확한 음향을 보장하는 것은 아니다.
예를 들어 물체의 재질과 거리, 공간의 구조에 따라 실제 소리의 반사와 울림은 달라진다.
Google은 이런 세부적인 음향 정확성도 추가 연구가 필요한 분야라고 설명했다.
Gemini Omni와 Gemini 3.8 Flash를 함께 사용
이번 모델은 Genie 4 하나만으로 모든 작업을 수행하는 구조가 아니다.
Google DeepMind는 여러 Gemini 모델을 함께 사용하는 방법을 공개했다.
Gemini Omni는 생성하는 세계가 실제 사물의 모습과 행동에 가깝도록 돕는다.
또한 Gemini 3.8 Flash가 가상세계의 진행 상황을 지속적으로 관찰하는 에이전트 역할을 수행한다.
AI 에이전트는 주어진 목표를 달성하기 위해 상황을 분석하고 여러 단계의 행동을 결정하는 시스템이다.
예를 들어 가상환경 속 인물이 물건을 가져오라는 지시를 받았다고 가정해 보자.
이 작업은 단순히 사람이 물건을 들고 있는 장면을 생성하는 것보다 복잡하다.
인물이 물건을 찾고, 해당 위치로 이동하고, 물건을 집은 뒤 목적지로 이동해야 한다.
각 단계가 실제로 완료됐는지도 확인해야 한다.
Gemini 3.8 Flash는 이런 목표를 여러 단계로 나누고, Genie 4가 생성하는 영상을 관찰하면서 다음 행동을 결정하도록 설계됐다.
모델은 새로운 프레임을 확인하고 이전 계획이 성공했는지 판단한다.
예상하지 못한 상황이 발생하거나 사용자가 지시를 변경하면 계획을 수정할 수 있다.
이처럼 추론을 담당하는 모델과 실제 환경을 생성하는 모델의 역할을 분리한 것이 이번 시스템의 중요한 특징이다.
Google은 Gemini 4 Argon과 Genie 4를 결합해 휴머노이드 로봇이 보드게임을 수행하는 과정을 시뮬레이션한 연구 사례도 공개했다.
여기서 Genie 4는 물리적 환경을 생성하고, Gemini는 수행할 행동을 단계별로 결정한다.
다만 연구 시연에서 작업이 자연스럽게 표현됐다는 사실만으로 실제 로봇이 동일한 작업을 수행할 수 있다는 의미는 아니다.
물리법칙을 이해하는 것과 정확하게 계산하는 것은 다르다
Google DeepMind는 Genie 4가 충돌과 공기역학, 사람의 움직임처럼 물리적 상호작용을 더 자연스럽게 생성한다고 설명한다.
하지만 일반적인 물리 시뮬레이터와 Genie 4는 구조가 다르다.
예를 들어 물리 엔진은 물체의 질량과 속도, 마찰력과 충돌 조건을 이용해 다음 상태를 계산할 수 있다.
반면 생성형 월드 모델은 학습한 영상과 행동 패턴을 바탕으로 다음 장면을 생성한다.
따라서 영상이 매우 자연스럽다고 해서 실제 물리법칙을 정확하게 계산했다는 뜻은 아니다.
Google 역시 물체의 위치와 형태가 시간이 지나면서 조금씩 달라질 수 있다고 인정했다.
이런 문제를 Object Permanence(물체 영속성) 및 장기적인 공간 일관성 문제와 연결해 이해할 수 있다.
예를 들어 사용자가 방을 떠났다가 다시 돌아왔을 때 이전에 존재하던 물체가 같은 위치에 있어야 한다.
하지만 생성형 모델에서는 이전 장면의 세부 정보가 충분히 유지되지 않아 물체가 사라지거나 형태가 달라질 수 있다.
Genie 4에서도 긴 시뮬레이션이나 복잡한 지시 변경이 반복되면 이런 오류가 나타날 수 있다.
따라서 현재 Genie 4는 정밀한 공학 계산을 수행하는 검증된 물리 엔진보다는 현실적인 상호작용 장면을 생성하는 연구용 모델에 가깝다.
게임과 로봇 개발에 활용할 가능성
게임 개발에서는 새로운 환경을 제작하는 데 상당한 시간이 필요하다.
개발자는 3D 모델과 재질, 조명과 물리 효과 등을 구성해야 한다.
Genie 4는 이런 과정의 초기 기획 단계에서 새로운 장면을 빠르게 시험하는 데 활용될 수 있다.
예를 들어 게임 디자이너가 특정한 분위기의 마을을 설명한 뒤 그 안을 이동하면서 배경과 동선, 분위기를 확인할 수 있다.
영상 제작에서도 촬영 전에 카메라 움직임과 조명, 등장인물의 행동을 검토하는 용도로 사용할 수 있다.
로봇 연구에서는 서로 다른 환경을 생성해 에이전트가 예상하지 못한 상황에 어떻게 반응하는지 시험하는 방법을 생각할 수 있다.
다만 실제 로봇의 학습에 활용하려면 시뮬레이션의 물리적 정확성과 현실 환경으로의 전이 가능성을 별도로 검증해야 한다.
Genie 4는 현재 신뢰할 수 있는 일부 연구 협력사를 대상으로 연구 프리뷰를 제공한다.
Google AI Ultra 구독자를 위한 Project Genie와 Gemini API, Google AI Studio의 일부 초기 협력사에도 향후 제공할 계획이다.
모든 일반 사용자와 개발자가 발표 당일부터 Genie 4를 사용할 수 있는 것은 아니다.
Google은 생성된 영상과 음성에 SynthID라는 디지털 워터마크를 적용한다고 밝혔다.
SynthID는 AI가 생성한 콘텐츠를 식별하는 데 활용할 수 있도록 눈이나 귀로 쉽게 구분되지 않는 신호를 포함하는 기술이다.
이번 발표는 월드 모델이 단순한 시각적 장면 생성에서 사용자의 행동과 자연어 지시, 환경의 소리와 복잡한 사건을 함께 처리하는 상호작용 시스템으로 발전하고 있음을 보여준다.
Liquid AI, 2B급 멀티모달 모델 6종으로 구성된 ‘LFM3’ 공개…텍스트·영상·음성·판단 모델을 하나의 기반 구조에서 학습
- 발표일: 2026-10-27 — 정확한 게시 시각 미확인
- 적용 범위: 소형 언어모델, 멀티모달 AI, 온디바이스 AI, 음성 에이전트, 영상 이해, 모델 미세조정, 오픈웨이트
- 원문: Liquid AI — Build specialized multimodal models with LFM3
Liquid AI가 텍스트와 이미지, 영상, 음성을 처리하는 새로운 모델 계열 LFM3를 공개했다.
이번 발표에서는 단순히 하나의 소형 언어모델을 개선한 것이 아니라 동일한 기반 모델에서 출발한 여섯 가지 전문 모델을 제공한다.
대부분의 모델은 약 20억 개 이하의 파라미터를 가진다.
파라미터는 모델이 학습 과정에서 조정하는 숫자 데이터로, 입력을 처리하고 출력을 생성하는 데 사용된다.
Liquid AI의 핵심 전략은 범용 프런티어 모델 하나에 모든 작업을 맡기는 대신 필요한 입력 형태와 업무에 맞는 작은 모델을 선택해 사용하도록 만드는 것이다.
예를 들어 스마트홈에서는 사용자의 음성을 이해하고 기기를 제어할 수 있는 모델이 필요하다.
반면 영수증을 처리하는 앱에서는 이미지 속 숫자와 상품명을 정확하게 읽는 능력이 중요하다.
고객지원 문의를 분류하는 시스템에서는 길고 자연스러운 답변보다 미리 정해진 데이터 형식에 맞는 판단 결과가 더 유용할 수 있다.
LFM3는 이런 서로 다른 작업을 하나의 기반 아키텍처에서 지원하도록 설계됐다.
여섯 가지 전문 모델
이번에 공개된 모델은 다음과 같다.
| 모델 | 주요 입력 | 주요 출력 | 활용 방향 |
|---|---|---|---|
| LFM3-1.7B | 텍스트 | 텍스트 | 로컬 에이전트, 도구 호출 |
| LFM3-VL-2B | 텍스트·이미지·영상 | 텍스트 | 시각적 이해, 영상 분석 |
| LFM3-Audio-2B | 텍스트·음성 | 텍스트·음성 | 음성 비서, 음성 인식 |
| LFM3-Omni-2B | 텍스트·이미지·영상·음성 | 텍스트·음성 | 통합 멀티모달 에이전트 |
| d1-2B | 텍스트·이미지·영상 | 구조화된 판단 | 분류, 추출, 점수 계산 |
| d1-omni-2B | 텍스트·이미지·영상·음성 | 구조화된 판단 | 음성까지 포함한 의사결정 |
여기서 VL(Vision-Language)은 시각 정보와 언어를 함께 처리하는 모델을 의미한다.
Omni 모델은 이미지와 음성, 텍스트 등 여러 입력 형태를 하나의 모델에서 함께 처리하도록 설계됐다.
반면 d1 계열은 길게 답변을 생성하는 대신 정해진 질문에 대한 판단값을 반환하는 데 특화돼 있다.
이런 구성은 하나의 서비스를 여러 작은 전문 모델로 만드는 방식과 연결된다.
예를 들어 스마트홈 에이전트가 사용자의 음성 명령을 이해하고 특정 기기를 제어하는 기능에는 Audio 모델을 사용할 수 있다.
반면 같은 시스템에서 카메라 화면을 확인하며 위험한 상황을 분류하는 작업에는 VL이나 d1 모델을 활용할 수 있다.
합성곱과 두 종류의 Attention을 결합
LFM3-1.7B의 기반 구조는 총 24개 계층으로 구성된다.
Liquid AI는 여기에 세 종류의 연산 구조를 혼합했다.
첫 번째는 Gated Short Convolution(게이트가 적용된 짧은 합성곱)이다.
합성곱은 입력의 인접한 부분에 반복적인 계산을 적용해 지역적인 패턴을 추출하는 방법이다.
두 번째는 Sliding-Window Attention(슬라이딩 윈도 어텐션)이다.
입력 전체가 아니라 현재 위치 주변의 제한된 범위를 참고하도록 하는 방식이다.
세 번째는 Global Attention(전역 어텐션)이다.
입력의 더 넓은 영역에 존재하는 정보 사이의 관계를 계산한다.
이런 구조를 Tri-Hybrid Architecture(세 가지 구조를 결합한 하이브리드 아키텍처)라고 한다.
24개 계층의 구성은 다음과 같다.
| 계층 종류 | 개수 |
|---|---|
| Gated Short Convolution | 13개 |
| Sliding-Window Attention | 5개 |
| Global Attention | 6개 |
일반적인 Transformer 모델은 Attention을 중심으로 작동한다.
하지만 입력이 길어지면 Attention 계산과 관련 메모리 사용량이 증가할 수 있다.
반면 합성곱은 인접한 정보 사이의 패턴을 상대적으로 효율적으로 처리할 수 있다.
LFM3는 두 방식을 결합해 짧은 입력의 빠른 처리와 긴 입력의 관계 이해 사이에서 균형을 맞추려 했다.
Liquid AI는 새로운 아키텍처를 선택할 때 휴대전화와 Raspberry Pi 5, 노트북과 GPU 서버 등 14개 하드웨어·실행 환경 조합을 고려했다고 밝혔다.
즉 모델의 이론적인 성능뿐 아니라 실제 기기에서 실행할 때의 효율을 함께 반영하려는 접근이다.
1.7B 모델에서 25만6천 토큰 컨텍스트 지원
LFM3-1.7B는 최대 256K 토큰 컨텍스트를 지원한다.
Context Window(컨텍스트 창)는 모델이 하나의 작업에서 참고할 수 있는 입력과 대화 기록의 범위다.
긴 컨텍스트는 여러 문서나 파일을 참고하는 에이전트에 유용할 수 있다.
예를 들어 소규모 코딩 에이전트가 프로젝트의 여러 파일을 분석하거나 이전 작업 기록을 참고할 수 있다.
하지만 최대 25만6천 토큰을 지원한다는 사실이 그 안의 모든 정보를 정확하게 찾고 활용할 수 있다는 의미는 아니다.
실제 긴 문서 검색과 추론 성능은 별도의 평가가 필요하다.
Liquid AI는 LFM3-1.7B가 이전 LFM2.5-2.6B보다 약 35% 적은 파라미터를 사용하면서도 일부 에이전트 평가에서 더 높은 성능을 기록했다고 밝혔다.
대표적인 WebArena-Verified 평가에서는 기존 모델의 3.02점에서 38.42점으로 개선됐다고 설명한다.
WebArena는 AI 에이전트가 실제 웹 애플리케이션 형태의 환경에서 작업을 수행하는 능력을 평가한다.
다만 이 수치는 Liquid AI의 자체 평가 결과다.
모든 브라우저 자동화 작업에서 같은 비율의 개선이 발생한다는 의미는 아니다.
음성을 듣는 동안 입력 처리를 시작
LFM3-Audio-2B에는 새로운 음성 인코더와 LiquidCodec이 사용된다.
Encoder(인코더)는 음성처럼 복잡한 입력을 모델이 처리하기 좋은 내부 표현으로 바꾸는 구성요소다.
Liquid AI는 새로운 음성 인코더가 사용자의 말이 끝날 때까지 기다리지 않고 일부 입력을 미리 처리할 수 있도록 설계했다.
이를 통해 음성 대화에서 첫 출력이 시작되기까지 걸리는 시간을 줄이려 했다.
회사에 따르면 일부 설정에서는 첫 토큰까지 걸리는 시간이 50ms 수준이었다.
또한 LiquidCodec은 생성된 음성 토큰을 실제 소리로 변환한다.
Apple M4 Max의 CPU 스레드 하나에서 실제 음성 재생 시간보다 약 87배 빠르게 디코딩했다고 밝혔다.
다만 모델 전체가 실제 음성보다 87배 빠르게 대답한다는 뜻은 아니다.
이 수치는 음성 토큰을 파형으로 변환하는 특정 구성요소의 처리 속도다.
LFM3-Audio-2B는 18개 언어의 음성 관련 작업을 지원한다.
음성 인식과 합성, 번역, 음성 명령에 따른 도구 호출 등이 주요 활용 대상이다.
d1 모델은 긴 답변 대신 판단값 반환
d1 계열은 일반적인 생성형 언어모델과 다른 방식으로 설계됐다.
예를 들어 사용자가 고객 문의를 전달했다고 가정해 보자.
시스템은 이 문의가 환불 요청인지, 어떤 팀에 전달해야 하는지, 얼마나 긴급한지 판단해야 할 수 있다.
일반적인 LLM은 이런 결과를 JSON 문장으로 생성할 수 있다.
하지만 필요한 항목이 명확하다면 길게 텍스트를 생성하는 방식이 비효율적일 수 있다.
d1 모델은 여러 질문에 대한 결과를 한 번의 순전파(Forward Pass)로 반환하도록 설계됐다.
순전파는 입력을 모델에 전달한 뒤 각 계층의 계산을 수행해 결과를 얻는 과정이다.
예를 들어 환불 여부는 참·거짓에 해당하는 확률로 반환할 수 있다.
담당 부서는 미리 정의된 여러 선택지 가운데 하나로 반환할 수 있다.
긴급도는 숫자 점수로 반환할 수 있다.
이런 구조는 대량의 문서 분류와 정보 추출, 업무 규칙 적용에 유용할 수 있다.
다만 출력된 확률이 실제 정답 확률과 정확히 일치하는지는 별도의 검증 데이터로 확인해야 한다.
공개 모델과 자체 데이터 미세조정
LFM3 모델들은 Hugging Face에서 공개됐으며 Transformers 기반 실행을 지원한다.
Liquid AI는 텍스트와 이미지, 음성 모델을 GPU 한 대에서 미세조정할 수 있도록 설계했다고 밝혔다.
Fine-Tuning(미세조정)은 이미 학습된 모델을 특정 업무와 데이터에 맞게 추가 학습하는 방법이다.
예를 들어 회사 내부 용어를 더 정확하게 이해하거나 특정 문서 양식에서 정보를 추출하도록 모델을 조정할 수 있다.
다만 GPU 한 대로 미세조정할 수 있다는 설명이 모든 종류의 GPU에서 같은 작업을 수행할 수 있다는 의미는 아니다.
필요한 메모리와 학습 시간은 모델과 입력 길이, 학습 방식에 따라 달라진다.
이번 발표는 소형 AI 모델의 발전이 단순히 파라미터를 줄이는 방향에 머무르지 않음을 보여준다.
하나의 기반 구조에서 여러 입력 형태와 작업 유형을 지원하고, 필요한 모델을 기기 내부에서 실행하거나 특정 업무에 맞게 수정하는 생태계가 만들어지고 있다.
Anthropic, AI 에이전트가 전문가의 판단을 바꾸는 현상 실험…분석가 50명이 주요 선택의 86%에서 AI 의견을 따랐다
- 발표일: 2026-10-27 — 정확한 게시 시각 미확인
- 적용 범위: AI 에이전트, 인간·AI 협업, 의사결정 연구, 통계 분석, AI 안전, 업무 자동화
- 원문: Anthropic — How AI agents shape experts’ judgment calls
Anthropic이 실제 전문 분석가들이 AI 에이전트와 함께 작업할 때 독립적인 판단을 얼마나 유지하는지 조사한 실험 결과를 발표했다.
이번 연구는 AI가 계산이나 문서 작성에서 얼마나 높은 생산성을 제공하는지 평가하는 일반적인 실험과 다르다.
연구팀은 AI가 작업을 대신 수행하면서 사람의 최종 판단에도 얼마나 큰 영향을 미치는지를 측정하려 했다.
AI 에이전트가 보편화되면 사람은 여러 작업을 직접 수행하기보다 AI의 결과를 검토하는 역할을 맡을 수 있다.
하지만 검토자가 AI가 제시한 판단을 충분히 독립적으로 검증하지 않는다면 문제가 발생할 수 있다.
예를 들어 AI가 통계 분석 결과를 작성하면서 특정한 분석 방법을 선택했다고 가정해 보자.
사용자가 그 방법을 명시적으로 선택한 것이 아니더라도 분석 결과가 이미 생성된 이후에는 AI의 선택을 그대로 받아들일 가능성이 있다.
Anthropic은 이를 실제 전문가를 대상으로 실험했다.
실제 통계 분석가에게 농업 정책 평가를 맡김
연구에는 인과추론 경험이 있는 전문 분석가들이 참여했다.
Causal Inference(인과추론)는 단순한 상관관계를 넘어 어떤 요인이 다른 결과를 실제로 발생시켰는지 분석하는 방법이다.
연구팀은 61명의 분석가를 모집했고, 이 가운데 50명이 AI 에이전트를 사용해 작업했다.
나머지 11명은 AI를 사용하지 않았다.
과제는 가상의 농업협동조합이 운영하는 자문 프로그램을 평가하는 것이었다.
협동조합은 농민들에게 생산성을 높이기 위한 유료 자문 서비스를 제공하고 있었다.
약 40%의 회원이 프로그램에 참여했다.
분석가는 이 프로그램이 실제로 농업 생산성을 높였는지 조사하고, 전체 회원에게 확대할지 결정해야 했다.
이 과제에는 명확한 정답이 하나만 존재하지 않는 부분들이 포함됐다.
예를 들어 농업 생산성을 면적당 수확량으로 측정할 수도 있고 운영비용 대비 수확량으로 측정할 수도 있다.
둘 다 합리적인 지표지만 선택에 따라 분석 결과가 달라질 수 있다.
에이전트의 선호를 무작위로 설정
연구팀은 네 가지 분석 결정과 하나의 최종 권고를 평가했다.
네 가지 분석 결정은 생산성의 정의와 비교 방법, 분석 대상 농장의 범위, 통계적 가중치 설정이었다.
참가자들은 자신이 원하는 방법을 선택할 수 있었다.
하지만 연구팀은 참가자가 사용하는 Claude Code 에이전트에 숨겨진 선호를 무작위로 부여했다.
예를 들어 특정 참가자의 AI는 면적당 수확량을 선호하도록 설정했다.
다른 참가자의 AI는 운영비용 대비 수확량을 선호하도록 설정했다.
어느 방향을 선호할지는 동전 던지기 방식으로 결정했다.
중요한 점은 에이전트에게 거짓말을 하라고 지시한 것이 아니라는 사실이다.
연구팀은 모델이 특정 선택지의 장점을 합리적으로 설명하되, 실제 증거가 반대 방향을 가리키면 판단을 바꾸도록 지시했다.
즉 실험에서 조작한 것은 데이터 자체가 아니라 AI가 어느 선택지에 더 우호적인 설명을 제공하는가였다.
전문가들은 분석 선택의 86%에서 AI 의견을 따름
연구 결과는 상당히 뚜렷했다.
참가자들은 네 가지 주요 분석 결정의 86%에서 AI 에이전트가 선호하도록 설정된 선택지를 채택했다.
각 결정의 결과는 다음과 같았다.
| 분석 결정 | AI의 선호와 일치한 비율 |
|---|---|
| 생산성 측정 지표 | 92% |
| 통계 비교 방법 | 82% |
| 분석 대상 농장 범위 | 81% |
| 가중치 설정 | 90% |
| 네 가지 결정 평균 | 86% |
AI의 선호가 전혀 영향을 주지 않았다면 양쪽 선택지가 비슷하게 선택될 것으로 예상할 수 있다.
하지만 실제 참가자들의 선택은 AI의 무작위 선호와 강하게 일치했다.
더 흥미로운 결과는 참가자가 이미 자신의 의견을 표현한 상황에서 나타났다.
AI가 기존 의견과 다른 방향을 제안했을 때 참가자는 60%의 경우 자신의 선택을 변경했다.
반면 AI가 기존 의견에 동의한 경우에는 선택을 바꾼 비율이 6%였다.
다만 이 비교는 38개 사례를 기반으로 하므로 추정의 불확실성이 크다.
연구팀도 이를 명시했다.
AI가 작성한 논리를 자신의 판단으로 기억
실험이 끝난 뒤 참가자들에게 자신이 선택한 방법의 이유를 설명하도록 했다.
그 결과 77%의 참가자가 AI가 제시했던 논리를 자신의 설명에 활용했다.
일부는 에이전트가 사용했던 표현을 거의 그대로 사용했다.
하지만 그 논리의 출처가 AI라고 명시한 참가자는 15%에 불과했다.
이는 단순히 참가자가 AI의 권고를 따랐다는 사실보다 복잡한 문제를 보여준다.
참가자는 AI가 제공한 설명을 자신의 판단 과정에 통합하면서, 실제로 그 설명이 어디에서 시작됐는지 충분히 인식하지 못할 수 있다.
이를 Automation Bias(자동화 편향)와 관련해 이해할 수 있다.
자동화 편향은 사람이 자동화 시스템의 판단을 과도하게 신뢰하거나 자신의 판단보다 우선시하는 경향을 의미한다.
다만 이번 연구에서 참가자들의 모든 선택이 잘못됐다는 뜻은 아니다.
두 선택지 모두 합리적인 경우가 많았으며, 문제의 핵심은 최종 선택이 누구의 판단에 의해 결정됐는지였다.
AI 사용자는 더 빠르고 오류도 적었다
이번 연구는 AI 사용의 부정적인 측면만 보여주지 않는다.
AI를 사용한 참가자들은 작업을 완료하는 데 중앙값 기준 65분이 걸렸다.
반면 AI를 사용하지 않은 참가자들은 90분이 필요했다.
또한 AI를 사용하지 않은 11명 가운데 6명은 분석 결과를 무효화할 수 있는 심각한 방법론적 오류를 범했다.
AI를 사용한 50명에서는 이런 오류가 3명에게서 나타났다.
그러나 두 집단을 직접 비교해 AI가 오류율을 줄였다고 단정해서는 안 된다.
AI 사용 여부를 무작위로 배정한 것이 아니었고, AI를 사용하지 않은 집단은 평균적으로 경험이 적었기 때문이다.
Anthropic 역시 이런 제한을 명확히 설명했다.
실제 업무에서의 영향은 별도 검증 필요
이번 실험은 하나의 통계 분석 과제를 대상으로 했다.
또한 AI 에이전트에 평소보다 강한 선호를 의도적으로 부여했다.
따라서 모든 AI 에이전트가 실제 업무에서 전문가의 판단을 86% 조종한다는 의미는 아니다.
실제 업무에서는 전문가가 해당 분야에 더 깊은 지식을 가지고 있거나, 다른 동료와 토론하면서 AI의 의견을 검토할 수 있다.
또한 모든 모델이 특정 선택지를 이렇게 강하게 주장하는 것도 아니다.
그럼에도 이번 연구는 인간이 최종 승인 버튼을 누른다는 사실만으로 충분한 독립적 검토가 이뤄졌다고 판단하기 어렵다는 점을 보여준다.
AI 에이전트가 여러 분석 방법 가운데 하나를 선택하고 그 근거를 설득력 있게 제시한다면, 사람은 그 선택이 처음부터 자신의 것이었다고 받아들일 수 있다.
특히 정책과 과학 연구처럼 합리적인 선택지가 여러 개 존재하는 업무에서는 AI가 제시하지 않은 대안도 독립적으로 검토할 수 있는 절차가 중요해질 수 있다.
Ai2, AI의 연구 아이디어가 실제로 새로운지 평가하는 벤치마크 공개…프롬프트 몇 단어로 평가 정확도가 50%포인트 이상 변동
- 벤치마크·데이터 공개일: 2026-10-27 — 정확한 게시 시각 미확인
- 관련 논문 최초 공개일: 2026-10-01
- 관련 논문 최근 개정일: 2026-10-26
- 적용 범위: AI 과학 연구, LLM 평가, 논문 분석, 연구 아이디어 생성, 벤치마크, AI 안전
- 원문: Allen Institute for AI — Can we trust LLMs to judge whether a research idea is novel?
- 관련 원문: arXiv — Old Ideas, Novel Problems: The Instability of LLM-Based Novelty Evaluation
미국의 비영리 AI 연구기관 Allen Institute for AI(Ai2)가 언어모델이 과학 연구 아이디어의 새로움을 얼마나 안정적으로 평가할 수 있는지 조사한 벤치마크와 데이터, 코드를 공개했다.
관련 연구 논문은 10월 1일에 처음 공개됐고 10월 26일에 개정됐다.
10월 27일의 새로운 발표는 해당 연구를 설명하면서 평가 벤치마크와 데이터, 재현용 코드 및 평가 데이터 생성 절차를 공개한 것이다.
최근 AI를 과학 연구에 사용하는 시스템은 논문을 요약하는 수준에서 벗어나고 있다.
일부 에이전트는 기존 문헌을 조사하고 새로운 연구 가설을 제안한다.
하지만 연구 가설을 생성하는 것과 해당 가설이 실제로 새로운지 확인하는 것은 다른 문제다.
예를 들어 AI가 새로운 머신러닝 알고리즘을 제안했다고 가정해 보자.
설명이 복잡하고 기술적으로 그럴듯하더라도 기존 논문에 거의 같은 아이디어가 존재할 수 있다.
따라서 AI가 생성한 연구 아이디어를 평가하려면 기존 연구와의 차이를 확인해야 한다.
이 작업을 다른 언어모델에게 맡기는 방식을 LLM Novelty Judge(언어모델 기반 신규성 평가자)라고 한다.
논문 승인 여부만으로 새로움을 판단하지 않음
Ai2는 2026년 ICLR 학술대회의 논문 심사 자료를 분석했다.
ICLR은 머신러닝과 딥러닝 분야의 주요 국제 학술대회 가운데 하나다.
연구팀은 논문이 채택됐는지만 보지 않았다.
대신 심사위원이 논문의 독창성에 관해 어떤 평가를 내렸는지 확인했다.
그 결과 새로움에 대해 긍정적인 평가를 받은 연구 아이디어 154개를 선정했다.
이들은 해당 연구 분야에서 높은 평가를 받은 채택 논문에서 추출됐다.
반대로 심사위원이 독창성 부족을 지적한 145개 연구 아이디어도 선정했다.
이들은 낮은 평가를 받은 미채택 논문에서 추출됐다.
다만 논문이 채택됐다고 해서 반드시 독창성이 높고, 미채택됐다고 해서 반드시 독창성이 낮은 것은 아니다.
연구팀이 논문 심사평에서 독창성에 관한 명시적인 근거를 찾으려 한 이유도 이 때문이다.
또한 연구팀은 언어모델이 직접 생성한 아이디어 154개를 별도로 준비했다.
이렇게 하면 인간이 작성한 연구 아이디어뿐 아니라 AI가 생성한 아이디어에 대해서도 평가 시스템을 시험할 수 있다.
프롬프트의 작은 차이가 평가 결과를 크게 변경
연구팀은 여섯 개 언어모델을 평가했다.
대상에는 GPT-5.1과 GPT-5.2, GPT-5.4, Claude Sonnet 4.5와 Claude Opus 4.5·4.6이 포함됐다.
연구팀은 두 가지 아이디어를 보여준 뒤 어느 쪽이 더 새로운지 선택하도록 했다.
그런데 평가 지시문의 표현을 조금만 변경해도 결과가 크게 달라졌다.
특정 실험에서는 프롬프트의 몇 단어를 변경했을 때 평가 정확도가 50%포인트 이상 달라졌다.
같은 두 연구 아이디어를 평가했는데도 어떤 설명을 덧붙였는지에 따라 판단이 바뀐 것이다.
여기서 중요한 것은 모델의 지식이 갑자기 바뀌었다는 뜻이 아니라는 사실이다.
동일한 모델과 아이디어를 사용했더라도 평가 지시문의 구조가 결과에 강하게 영향을 줬다는 의미다.
일부 설정에서는 모델의 정확도가 무작위 선택보다 낮아지기도 했다.
또한 어떤 프롬프트 변경은 한 모델의 성능을 높였지만 다른 모델의 성능은 낮췄다.
따라서 모든 모델에 공통으로 적용할 수 있는 간단한 최적 프롬프트를 찾기 어려울 수 있다.
더 많은 검색과 추론이 항상 도움이 되지는 않았다
연구팀은 평가 모델에 추가적인 논문 검색 기능을 제공하거나 더 많은 추론 자원을 사용하는 방법도 시험했다.
일반적으로 관련 문헌을 더 많이 검색하면 연구의 독창성을 더 정확하게 판단할 수 있을 것으로 기대할 수 있다.
하지만 이번 연구에서는 추가 검색이나 더 긴 추론이 모든 조건에서 일관된 성능 개선을 제공하지 않았다.
또한 신규성 평가만을 위해 개발한 전문 시스템 두 종류가 간단한 프롬프트를 사용한 Claude Opus 4.6보다 낮은 성능을 기록했다.
이는 연구팀이 사용한 특정 평가 데이터에서 얻은 결과다.
모든 연구 분야에서 전문 평가 시스템이 불필요하다는 의미는 아니다.
벤치마크 자체의 한계
이번 연구에는 중요한 제한이 있다.
AI가 생성한 154개 아이디어는 상대적으로 단순한 방식으로 생성됐다.
연구팀은 이 아이디어들이 높은 평가를 받은 인간 연구자의 아이디어보다 덜 독창적일 것으로 가정했다.
하지만 모든 개별 아이디어에 대해 실제 독창성이 완전히 검증된 것은 아니다.
이를 Weak Label(약한 정답 레이블)이라고 한다.
충분한 독립 검증 없이 합리적인 가정에 따라 부여한 평가값이라는 의미다.
따라서 이 벤치마크의 점수도 완벽한 독창성 판단 기준은 아니다.
다만 연구팀의 핵심 발견 가운데 일부는 정답 레이블의 정확성과 무관하다.
동일한 아이디어 쌍에 대해 합리적인 두 평가 설정이 서로 반대되는 결론을 내렸다는 사실 자체가 평가 시스템의 불안정성을 보여주기 때문이다.
이번 발표는 AI가 과학 연구를 자동화하는 과정에서 새로운 문제가 등장하고 있음을 보여준다.
연구 아이디어를 빠르게 생성하는 능력이 발전하더라도 그 아이디어가 실제로 새로운지 신뢰할 수 있게 평가하는 기술이 함께 발전하지 않으면 과학적 성과를 제대로 판단하기 어려울 수 있다.
NASA·Google, 우주 임무 지원 로봇의 초기 실험 공개…4B 모델을 2.5시간 미세조정하고 실험실 물체 이동 성공률 85% 기록
- 발표일: 2026-10-27 — 정확한 게시 시각 미확인
- 적용 범위: 로봇 AI, 우주 탐사, 온디바이스 AI, 시뮬레이션, 멀티모달 모델, 자율 작업
- 원문: Google Cloud — Google Cloud and NASA: Testing robotic systems for deep space missions
Google Cloud와 NASA가 달과 화성 등 장거리 우주 임무에서 사용할 수 있는 로봇 시스템의 초기 실험 결과를 공개했다.
이번 연구의 목표는 우주비행사가 수행하는 반복적인 물품 운반과 장비 준비 작업의 일부를 로봇이 지원하도록 만드는 것이다.
장거리 우주 탐사에서는 지구의 관제센터가 모든 상황을 실시간으로 도와주기 어렵다.
예를 들어 화성과 지구 사이의 통신은 위치에 따라 상당한 지연이 발생한다.
Google에 따르면 왕복 통신 지연시간은 최대 약 44분에 달할 수 있다.
이런 환경에서는 지구에서 매번 새로운 지시를 전달하기보다 우주선 내부의 시스템이 스스로 상황을 이해하고 작업을 수행할 필요가 있다.
물체를 이해하고 실제로 움직이는 VLA 모델
연구팀은 VLA(Vision-Language-Action) 모델을 사용했다.
VLA는 시각정보와 자연어 지시를 함께 이해하고 실제 행동을 생성하도록 설계된 모델이다.
예를 들어 사용자가 의료용 가방을 특정 위치로 옮기라고 요청할 수 있다.
로봇은 카메라로 주변 환경을 관찰하고 해당 가방을 찾는다.
이후 로봇 팔을 움직여 가방을 집고 목적지로 이동시켜야 한다.
이런 작업을 Pick-and-Place(물체 집기와 배치)라고 한다.
연구팀은 Physical Intelligence의 오픈소스 Pi0 모델을 기반으로 작업을 진행했다.
Google Cloud의 G4 인스턴스를 이용해 약 40억 파라미터 규모의 모델을 2.5시간 동안 미세조정했다.
미세조정은 기존에 학습한 모델을 특정 환경과 작업에 맞게 추가 학습하는 과정이다.
물리 시뮬레이션에서 학습한 뒤 실제 로봇으로 연결
연구에는 MuJoCo라는 물리 시뮬레이션 엔진도 사용됐다.
MuJoCo는 로봇과 물체의 움직임, 중력과 충돌 등을 계산하는 데 사용되는 도구다.
연구팀은 NASA Johnson Space Center의 시험 시설에서 실제 로봇의 동작도 확인했다.
초기 실험에서는 의료용 가방을 찾아 옮기는 작업에서 85%의 성공률을 기록했다고 밝혔다.
다만 이 수치는 특정한 실험실 환경에서 측정한 초기 결과다.
실제 우주선이나 달·화성 기지에서 같은 성공률을 보장하는 것은 아니다.
또한 우주 환경에서는 지구와 다른 중력 조건과 제한된 전력, 좁은 작업 공간 등 추가적인 문제가 존재한다.
따라서 현재 시스템을 실제 우주 임무에 투입할 준비가 완료된 로봇으로 이해해서는 안 된다.
클라우드에서 학습하고 기기 내부에서 실행
이번 연구에서 중요한 설계 선택은 모델의 학습과 실제 실행 위치를 구분한 것이다.
대규모 계산이 필요한 추가 학습은 Google Cloud에서 수행한다.
하지만 실제 우주 임무에서는 모델을 로봇 가까이에 있는 저전력 컴퓨터에서 실행하도록 설계한다.
이런 방식을 Edge AI(엣지 AI)라고 한다.
데이터를 항상 중앙 서버로 보내지 않고 실제 작업이 발생하는 기기나 그 주변에서 AI를 실행하는 접근이다.
연구팀은 지난 2년 동안 약 15종의 엣지 컴퓨팅 장치를 시험했다고 밝혔다.
이는 AI 모델이 실제 현장에서 안정적으로 작동하려면 단순한 모델 정확도 외에도 전력 사용량과 실행 지연시간, 하드웨어 호환성을 고려해야 한다는 점을 보여준다.
이번 발표는 AI 로봇 연구가 공장이나 가정뿐 아니라 통신이 제한되고 사람의 직접적인 지원을 받기 어려운 환경으로 확장되고 있음을 보여주는 초기 사례다.
2️⃣ AI 제품·서비스
Google Cloud, ‘Gemini Robotics Embodied Reasoning 2’ 공개 프리뷰 시작…로봇이 작업 진행 상황을 확인하고 실패하면 계획 수정
- 발표일: 2026-10-27 — 정확한 게시 시각 미확인
- 적용 범위: 로봇 AI, Gemini API, 멀티모달 모델, 산업 자동화, 로봇 에이전트, Google Cloud
- 원문: Google Cloud — Gemini Robotics Embodied Reasoning 2 is now available on Google Cloud
Google Cloud가 로봇을 위한 전문 추론 모델인 Gemini Robotics Embodied Reasoning 2(ER 2)를 Gemini 플랫폼에서 공개 프리뷰로 제공하기 시작했다.
이번 발표는 모델 자체가 처음 공개됐다는 의미는 아니다.
Gemini Robotics 2와 ER 2는 올해 앞서 소개된 기술이다.
10월 27일의 새로운 변화는 기업과 개발자가 Google Cloud의 Gemini 플랫폼에서 ER 2에 접근할 수 있게 됐다는 점이다.
기존 로봇 시스템에서는 높은 수준의 작업 계획과 실제 모터 제어가 분리되는 경우가 많다.
예를 들어 로봇에게 컵을 정리하라고 지시했다고 가정해 보자.
로봇은 먼저 컵의 위치를 찾아야 한다.
이후 로봇 팔을 움직여 컵을 집고, 지정된 위치에 내려놓아야 한다.
이 과정에서 컵을 제대로 잡지 못하거나 예상하지 못한 물체가 나타날 수 있다.
단순히 처음에 작성한 행동 순서를 끝까지 실행하는 방식으로는 이런 상황에 대응하기 어렵다.
ER 2는 실제 환경을 지속적으로 관찰하면서 다음 행동을 판단하는 상위 추론 계층으로 설계됐다.
로봇의 두뇌와 실제 제어장치 분리
ER 2는 로봇의 모든 모터를 직접 제어하는 모델이 아니다.
개발자는 실제 로봇의 동작을 수행하는 VLA 모델이나 내비게이션 API, 로봇 제어 함수를 별도의 도구로 등록할 수 있다.
VLA(Vision-Language-Action)는 시각정보와 언어를 바탕으로 실제 행동을 생성하는 모델 구조다.
ER 2는 사용자의 요청과 카메라 영상, 음성 등을 분석한 뒤 어떤 도구를 어떤 순서로 사용할지 결정한다.
예를 들어 로봇에게 작업대에 놓인 물체를 정리하라고 요청할 수 있다.
ER 2는 먼저 작업대의 상태를 확인한다.
그다음 물체를 이동시키는 순서를 계획한다.
이후 실제 로봇 제어 도구를 호출한다.
도구 실행이 끝나면 카메라 영상을 다시 확인해 해당 작업이 성공했는지 판단한다.
실패했다면 계획을 변경하거나 재시도할 수 있다.
이런 구조는 AI 에이전트의 도구 호출(Tool Calling)을 실제 물리적 환경에 적용한 사례다.
작업의 성공 여부를 프레임 단위로 확인
Google은 ER 2가 특정한 사건이 영상의 어느 시점에서 발생했는지 찾는 능력을 강조했다.
예를 들어 로봇이 용기에 액체를 붓고 있다면 액체가 특정 높이에 도달한 순간을 확인해야 할 수 있다.
작업 완료 여부를 잘못 판단하면 액체가 넘칠 수 있다.
Google이 공개한 자체 평가에서는 특정 사건의 발생 시점을 찾는 작업에서 91.3%의 정확도를 기록했다.
또한 실제 사건 발생 시점과 예측 시점 사이의 평균 절대 오차는 0.96초였다.
회사에 따르면 비교 대상으로 삼은 일부 대형 모델 구성보다 약 4배 빠른 실행 속도도 기록했다.
다만 이 결과는 Google이 공개한 평가 조건에서 얻어진 수치다.
실제 산업 현장의 모든 로봇 작업에서 같은 정확도를 보장하지는 않는다.
특히 로봇의 작업 안전성은 모델의 판단뿐 아니라 센서의 정확도와 기계적인 제어 장치, 비상 정지 시스템에도 영향을 받는다.
서로 다른 로봇이 협력하는 작업
ER 2는 하나의 로봇뿐 아니라 여러 종류의 로봇이 함께 수행하는 작업에도 활용할 수 있도록 설계됐다.
예를 들어 이동 로봇이 물품을 운반하고, 고정된 로봇 팔이 물품을 작업대에 배치하는 과정을 생각할 수 있다.
두 로봇은 서로 다른 제어장치를 사용한다.
하지만 상위 작업 계획에서는 같은 공간과 목표를 공유해야 한다.
ER 2는 이런 상황에서 작업을 나누고 필요한 정보를 전달하도록 설계됐다.
또한 사용자가 자연어로 계획을 수정하도록 지시할 수도 있다.
다만 이번 발표가 특정한 로봇을 구매하면 이런 기능을 즉시 사용할 수 있다는 의미는 아니다.
실제 사용을 위해서는 로봇의 제어 인터페이스와 안전장치, 실행 환경을 별도로 연결해야 한다.
이번 기능은 공개 프리뷰 단계이며, 정식 상용 서비스의 전체 안정성과 지원 조건이 확정된 것은 아니다.
이번 변화는 산업용 로봇 개발에서도 작업 계획을 수행하는 AI 모델과 실제 움직임을 제어하는 시스템을 분리하는 아키텍처가 중요해지고 있음을 보여준다.
OpenAI·Oracle, ChatGPT에서 기업의 재무·구매 업무를 수행하는 ‘Oracle AI Workspace’ 개발 발표…미국 고객은 Oracle Marketplace 구매 지원
- 발표일: 2026-10-27 — 정확한 게시 시각 미확인
- 적용 범위: 기업용 AI 에이전트, ChatGPT Work, Codex, Oracle Cloud, 재무·구매 업무 자동화, 기업 보안
- 원문: OpenAI — OpenAI expands partnership with Oracle to bring its apps to ChatGPT
OpenAI와 Oracle이 기업용 업무 시스템을 ChatGPT에 연결하기 위한 협력 확대 계획을 발표했다.
이번 발표의 핵심은 Oracle의 기존 업무 애플리케이션을 자연어로 조회하고 일부 승인된 작업을 수행할 수 있는 환경을 개발한다는 점이다.
예를 들어 기업의 재무 담당자가 월말 결산을 준비한다고 가정해 보자.
기존에는 여러 업무 애플리케이션을 열어 결제 기록과 구매 내역, 예산과 처리되지 않은 항목을 확인해야 할 수 있다.
Oracle은 이런 업무를 하나의 대화형 작업 공간에서 처리할 수 있도록 Oracle AI Workspace를 개발하고 있다.
사용자는 자연어로 필요한 정보를 질문하고 관련 업무의 진행 상태를 확인할 수 있다.
이후 조직이 허용한 범위에서 실제 업무 절차를 수행하도록 연결하는 것이 목표다.
다만 Oracle AI Workspace가 이번 발표와 동시에 모든 고객에게 정식 출시된 것은 아니다.
현재는 개발 중인 제품이다.
기업 데이터와 사용자 권한을 함께 연결
기업용 AI 에이전트에서는 외부 데이터에 접근하는 기능만큼 접근권한을 관리하는 일이 중요하다.
예를 들어 일반 직원이 자신의 부서의 구매 내역은 볼 수 있지만 모든 직원의 급여정보에 접근해서는 안 될 수 있다.
AI 에이전트가 사용자를 대신해 업무를 수행할 때도 이런 권한이 유지돼야 한다.
OpenAI와 Oracle은 조직의 기존 사용자 인증과 접근권한, 승인 절차를 유지하면서 AI가 업무를 수행하도록 설계할 계획이라고 설명했다.
이런 방식은 단순한 데이터 검색과 차이가 있다.
사용자가 특정 정보를 볼 수 있는지뿐 아니라 실제로 어떤 변경을 수행할 수 있는지도 구분해야 하기 때문이다.
예를 들어 구매 요청의 현재 상태를 확인하는 작업과 실제 구매를 승인하는 작업은 필요한 권한이 다를 수 있다.
Oracle AI Security Mesh와 App Composer
두 회사는 Oracle의 다른 제품에도 OpenAI 모델을 적용할 계획이다.
Oracle AI Security Mesh는 AI를 이용해 애플리케이션과 인프라의 보안 취약점을 찾고 수정하는 작업을 지원하도록 설계된다.
Oracle은 관련 시험 환경을 관리하고 승인된 범위에서만 보안 분석을 수행하도록 할 계획이다.
Oracle App Composer는 Codex 등의 도구로 업무 애플리케이션을 생성하고 Oracle 데이터와 연결하는 기능을 목표로 한다.
예를 들어 개발자가 자연어로 내부 업무 도구를 설명하고 필요한 화면과 데이터 연결 기능을 생성할 수 있다.
이후 Oracle Cloud Infrastructure에서 배포하도록 구성하는 방식이다.
또한 소규모 기업을 대상으로 ChatGPT Business와 Codex, Oracle 애플리케이션 및 클라우드 크레딧을 결합한 Oracle AI SMB Bundle도 발표했다.
하지만 이러한 제품들의 실제 제공 일정과 세부 기능은 모두 확정된 것이 아니다.
이번 발표는 여러 제품의 개발 방향과 제공 계획을 설명하는 성격이 강하다.
현재 이용 가능한 것은 Oracle Marketplace 구매 경로
이번 발표에서 이미 제공된 기능과 향후 계획을 구분해야 한다.
미국의 Oracle 고객은 Oracle Marketplace를 통해 OpenAI API와 Codex, ChatGPT Work에 대한 접근권한을 구매할 수 있다.
이 과정에서 기존 Oracle 구매 절차와 적용 가능한 Oracle Universal Credits를 사용할 수 있다.
반면 Oracle AI Workspace와 App Composer 등은 향후 통합을 목표로 개발 중인 제품이다.
OpenAI에 따르면 Oracle 내부에서는 이미 ChatGPT와 Codex를 업무에 사용하고 있다.
Oracle이 보고한 활성 사용자는 ChatGPT 약 13만 명, Codex 9만5천 명 이상이다.
또한 Oracle의 채용팀은 과거 24일이 걸렸던 시장조사 자료 준비 작업을 1520분 수준으로 줄인 사례를 소개했다.
다만 이 수치는 Oracle 내부의 특정 업무 사례에서 얻어진 결과다.
모든 기업의 시장조사 업무가 같은 비율로 빨라진다는 의미는 아니다.
이번 발표는 AI 에이전트가 독립적인 채팅 도구를 넘어 기업이 이미 사용하는 재무·구매·개발 시스템의 공통 인터페이스로 확장되려는 방향을 보여준다.
3️⃣ 개발 도구·에이전트
AWS SageMaker, ‘SOCI’ 이미지 지연 로딩 지원…35GB AI 컨테이너의 시작 시간을 7분에서 수초로 단축
- 발표일: 2026-10-27 — 정확한 게시 시각 미확인
- 적용 범위: AI 모델 학습, SageMaker, 컨테이너, Docker, GPU 인프라, 클라우드 비용 최적화
- 원문: AWS — Announcing SOCI-indexed images for faster SageMaker AI jobs
AWS가 Amazon SageMaker AI의 모델 학습과 데이터 처리 작업에서 SOCI 인덱스를 이용한 컨테이너 지연 로딩(Lazy Loading)을 지원한다고 발표했다.
이번 업데이트는 새로운 AI 모델이나 에이전트 프레임워크가 아니다.
모델 학습을 시작하기 전에 발생하는 불필요한 대기시간을 줄이는 인프라 기능이다.
일반적인 AI 학습 환경에서는 필요한 프로그램과 라이브러리를 컨테이너 이미지에 포함한다.
Container Image(컨테이너 이미지)는 프로그램과 실행에 필요한 파일, 라이브러리와 설정을 묶어둔 패키지다.
실제 작업을 실행할 때는 이미지를 서버에 내려받고 압축을 풀어야 한다.
문제는 딥러닝 컨테이너의 크기가 매우 클 수 있다는 점이다.
PyTorch나 TensorFlow, CUDA와 관련 라이브러리를 포함한 이미지에서는 수GB에서 수십GB의 파일이 필요할 수 있다.
하지만 프로그램이 시작되는 순간부터 모든 파일을 사용하는 것은 아니다.
예를 들어 이미지에 수많은 라이브러리가 포함돼 있더라도 실제 학습 작업에서 일부만 사용할 수 있다.
그런데 기존 방식에서는 컨테이너 이미지 전체를 다운로드한 뒤에야 학습을 시작할 수 있었다.
SOCI로 필요한 파일부터 가져오기
이번에 도입된 기술은 SOCI(Seekable OCI)다.
OCI(Open Container Initiative)는 컨테이너 이미지와 실행 환경에 관한 개방형 규격을 개발하는 프로젝트다.
SOCI는 컨테이너 이미지에 포함된 파일의 위치를 나타내는 별도의 인덱스를 만든다.
Index(인덱스)는 필요한 정보를 빠르게 찾을 수 있도록 정리한 데이터 구조다.
일반적인 방식에서는 컨테이너 이미지 전체를 서버에 내려받아야 한다.
반면 SOCI를 사용하면 실행에 필요한 파일을 먼저 가져온다.
그다음 프로그램이 작동하는 동안 나머지 파일을 필요할 때 다운로드할 수 있다.
이를 Lazy Loading(지연 로딩)이라고 한다.
프로그램이 시작될 때 모든 자원을 미리 불러오지 않고 필요한 순간에 가져오는 방식이다.
예를 들어 모델 학습 프로그램이 처음에는 Python 실행 환경만 필요하다면 해당 부분을 먼저 준비한다.
이후 특정 라이브러리나 파일을 사용할 때 추가 데이터를 가져올 수 있다.
실제 측정 결과
AWS는 압축된 크기가 1.8GB에서 35.4GB인 여덟 종류의 컨테이너 이미지를 이용해 성능을 측정했다.
대표적인 결과는 다음과 같다.
| 이미지 크기 | 기존 다운로드 | SOCI 지연 로딩 |
|---|---|---|
| 1.8GB | 48초 | 3~11초 |
| 13.2GB | 3분 42초 | 약 6초 |
| 35.4GB | 7분 17초 | 3~11초 |
가장 큰 35.4GB 이미지에서는 기존 약 7분17초가 필요했던 시작 과정이 수초로 줄었다.
AWS는 시험 조건에서 이미지 다운로드 때문에 발생하는 GPU 유휴시간을 최대 90% 감소시켰다고 밝혔다.
다만 이 수치는 컨테이너 이미지를 준비하는 과정의 개선 효과다.
실제 모델 학습 계산 자체가 35배 빨라졌다는 의미는 아니다.
모델이 데이터를 읽고 파라미터를 업데이트하는 과정은 여전히 별도로 실행된다.
또한 프로그램이 처음 시작할 때 필요한 파일이 많다면 지연 로딩의 효과가 달라질 수 있다.
AWS는 이미지 분류와 언어모델 미세조정 작업을 이용해 실제 학습 성능도 비교했다.
그 결과 학습 중 필요한 파일을 처음 읽는 시점에는 일부 추가적인 지연이 발생할 수 있었지만, 이후 반복적인 학습 계산에서는 큰 성능 차이가 없었다고 설명한다.
따라서 전체 작업 시간의 개선 폭은 컨테이너 다운로드가 실제 작업에서 차지하는 비율에 따라 달라질 수 있다.
기존 컨테이너 이미지를 변경하지 않아도 된다
SOCI 인덱스는 컨테이너 이미지 자체를 다시 작성하는 방식이 아니다.
원본 이미지와 연결되는 별도의 파일로 저장된다.
AWS는 이를 Amazon ECR(Elastic Container Registry)에 저장하도록 지원한다.
ECR은 컨테이너 이미지를 저장하고 관리하는 서비스다.
기존 이미지에 SOCI 인덱스를 추가하면 SageMaker가 해당 인덱스를 자동으로 확인한다.
지연 로딩을 사용할 수 있다면 필요한 파일부터 가져온다.
반대로 인덱스가 없거나 지연 로딩에 실패하면 기존의 전체 다운로드 방식으로 돌아간다.
따라서 기존 학습 코드와 실행 명령을 반드시 변경할 필요는 없다.
이런 방식을 Fallback(대체 경로)이라고 한다.
새로운 방식이 작동하지 않을 때 기존 방식으로 계속 실행하도록 만드는 설계다.
반복 실험에서 비용 절감 효과
AI 개발에서는 같은 모델을 여러 설정으로 반복 학습하는 일이 많다.
예를 들어 학습률과 배치 크기, 데이터 구성 등을 변경해 수십 번의 실험을 실행할 수 있다.
이를 Hyperparameter Tuning(하이퍼파라미터 탐색)이라고 한다.
하이퍼파라미터는 모델 학습을 시작하기 전에 개발자가 설정하는 값이다.
이런 실험에서 각 작업이 실행될 때마다 컨테이너 다운로드에 몇 분이 필요하다면 대기시간이 누적될 수 있다.
특히 실제 학습 작업이 짧은 경우에는 준비 시간이 전체 실행 시간의 상당 부분을 차지할 수 있다.
SOCI는 이런 반복적인 실험에서 자원을 더 효율적으로 사용하는 데 도움이 될 수 있다.
이번 발표는 AI 인프라의 비용을 줄이는 방법이 GPU 계산 자체를 최적화하는 것에만 있지 않다는 점을 보여준다.
모델 학습을 시작하기 전과 끝난 뒤의 불필요한 대기시간을 줄이는 작업도 전체 AI 개발 비용에 영향을 줄 수 있다.
NVIDIA, 로컬 AI 캐릭터 모델 ‘Nemotron 3.5 Bolt’와 RTX Spark 개발 도구 공개…4GB 모델로 게임 속 NPC의 대화·행동 지원
- 발표일: 2026-10-27 — 정확한 게시 시각 미확인
- 적용 범위: 온디바이스 AI, 게임 개발, 소형 언어모델, NVIDIA ACE, Unreal Engine, AI 그래픽, Windows on Arm
- 원문: NVIDIA — NVIDIA RTX Spark Powers Neural Rendering and AI Characters in Games
NVIDIA가 새로운 Windows AI 개발 플랫폼 RTX Spark를 위한 게임 개발 도구와 소형 언어모델 Nemotron 3.5 Bolt E4B 4GB를 공개했다.
RTX Spark는 NVIDIA Grace CPU와 Blackwell RTX GPU를 결합한 컴퓨팅 플랫폼이다.
최대 128GB 통합 메모리와 CUDA, RTX 그래픽 기술을 지원하도록 설계됐다.
여기서 Unified Memory(통합 메모리)는 CPU와 GPU가 하나의 메모리 공간을 공유하는 구조를 의미한다.
일반적인 게이밍 PC에서는 GPU의 전용 메모리 용량이 제한적일 수 있다.
게임을 실행하면서 동시에 AI 모델을 사용하면 그래픽 렌더링과 AI 추론이 메모리 자원을 경쟁적으로 사용하게 된다.
NVIDIA는 이번 플랫폼에서 이런 두 종류의 작업을 함께 수행하는 환경을 지원하려 한다.
게임 캐릭터의 대화를 미리 작성하지 않아도 된다
일반적인 게임에서는 NPC의 대화와 행동을 개발자가 미리 정의하는 경우가 많다.
NPC(Non-Player Character)는 플레이어가 직접 조작하지 않는 게임 속 등장인물이다.
예를 들어 플레이어가 마을 주민에게 말을 걸면 정해진 대화 선택지가 나타날 수 있다.
생성형 AI를 이용하면 사용자가 자유롭게 질문하고 NPC가 상황에 맞춰 새로운 답변을 생성하도록 만들 수 있다.
하지만 일반적인 대형 언어모델을 사용하는 경우에는 높은 추론 비용과 지연시간이 발생할 수 있다.
게임에서는 사용자 입력에 빠르게 반응해야 하므로 이런 문제가 더 중요하다.
NVIDIA는 이를 해결하기 위해 Nemotron 3.5 Bolt E4B 4GB를 제공한다.
이 모델은 약 4GB 규모의 메모리 사용을 목표로 설계된 소형 언어모델이다.
게임의 현재 상태와 등장인물의 설정, 이전 대화를 참고하면서 새로운 응답을 생성하도록 구성됐다.
또한 외부 게임 API를 호출하는 Tool Calling(도구 호출)도 지원한다.
예를 들어 사용자가 NPC에게 특정 장소로 이동하라고 요청하면 모델이 실제 게임의 이동 기능을 호출하도록 만들 수 있다.
단순히 이동하겠다고 말하는 것과 실제 게임 상태를 변경하는 것은 다른 작업이다.
도구 호출을 사용하면 언어모델의 판단을 게임의 실제 기능에 연결할 수 있다.
더 적은 토큰으로 빠르게 응답
NVIDIA는 Nemotron 3.5 Bolt가 기존 모델보다 일부 평가에서 약 40% 높은 평균 품질을 기록했다고 밝혔다.
또한 특정 비교 모델보다 답변 생성에 필요한 토큰 수가 최대 80% 적었다고 설명한다.
토큰은 언어모델이 텍스트를 처리하는 기본 단위다.
출력 토큰이 줄어들면 모델이 생성해야 할 계산 단계도 감소할 수 있다.
게임에서는 이런 특징이 중요하다.
예를 들어 NPC에게 짧은 질문을 했는데 모델이 수십 문장에 걸쳐 답변한다면 게임의 흐름이 느려질 수 있다.
반면 필요한 정보만 간결하게 전달하면 플레이어가 자연스럽게 대화를 이어갈 수 있다.
Nemotron 3.5 Bolt에는 대화형 응답을 짧게 생성하도록 유도하는 설정도 포함됐다.
최대 64K 토큰 컨텍스트와 여러 단계의 도구 호출을 지원한다.
다만 NVIDIA가 공개한 성능 향상은 회사의 자체 평가 결과다.
게임의 모든 상황에서 같은 속도와 품질을 보장하지는 않는다.
DLSS 5의 AI 렌더링도 개선
이번 발표에는 AI 그래픽 기술인 DLSS 5의 업데이트도 포함됐다.
DLSS는 AI를 이용해 게임의 그래픽 품질이나 처리 속도를 개선하는 NVIDIA 기술 계열이다.
이번 업데이트에서는 3D-Guided Neural Rendering의 처리 효율을 개선했다.
Neural Rendering은 신경망을 이용해 이미지나 영상의 일부 표현을 생성하거나 개선하는 기술이다.
NVIDIA에 따르면 10월 모델 업데이트는 9월 버전보다 약 2배 빠르게 실행됐다.
또한 GPU에 발생하는 추가 부담을 절반으로 줄였고, 4K 해상도에서 메모리 사용량도 약 20% 감소시켰다.
다만 이는 특정 렌더링 구성요소에 관한 비교 결과다.
모든 게임의 전체 프레임 속도가 두 배로 증가한다는 의미는 아니다.
또한 DLSS 5의 모든 기능을 모든 게임에서 사용할 수 있는 것은 아니다.
실제 지원 여부는 게임 개발사의 통합과 하드웨어 조건에 따라 달라진다.
Windows on Arm과 Unreal Engine 지원 확대
NVIDIA는 RTX Spark에서 사용할 수 있는 개발 도구도 확대했다.
새로운 Nsight Graphics와 Nsight Systems 도구는 Windows on Arm 환경에서 그래픽과 시스템 성능을 분석하도록 지원한다.
Windows on Arm은 Arm 아키텍처의 CPU에서 실행되는 Windows 운영체제다.
또한 Unreal Engine 5.8용 NVIDIA RTX Branch도 공개했다.
이는 NVIDIA의 최신 RTX 기능을 Unreal Engine 프로젝트에 연결하도록 지원하는 별도의 엔진 코드 계열이다.
인간과 로봇의 움직임을 생성하는 MotionBricks에도 새로운 인체 동작 모델이 추가됐다.
하지만 MotionBricks는 아직 연구용 코드와 모델이며, 시연된 Unreal Engine 통합 전체가 이번 배포에 포함된 것은 아니다.
이번 발표는 게임 속 생성형 AI가 단순한 대화 기능에서 벗어나 현재 게임 상태를 이해하고 실제 행동을 수행하는 로컬 에이전트로 발전하고 있음을 보여준다.
또한 이러한 기능을 실제 게임에 적용하려면 언어모델뿐 아니라 그래픽 렌더링과 메모리, 실행 지연시간을 함께 관리해야 한다는 점을 드러낸다.
4️⃣ 산업·정책·안전
Anthropic, Claude가 Chrome·Safari·Android·Windows·Linux에서 발견한 중대한 취약점 공개…Chrome 관련 62개 CVE 수정
- 발표일: 2026-10-27 — 정확한 게시 시각 미확인
- 적용 범위: AI 사이버보안, 브라우저 보안, 운영체제 보안, 취약점 분석, AI 에이전트, 책임 있는 취약점 공개
- 원문: Anthropic — Discovering and exploiting vulnerabilities in critical, real-world software with Claude
Anthropic이 내부 연구용 Claude 모델을 사용해 여러 주요 소프트웨어에서 실제 보안 취약점을 발견하고 검증한 결과를 공개했다.
이번 연구는 일반적인 코딩 벤치마크에서 모델이 높은 점수를 기록했다는 발표와 다르다.
실제 운영체제와 브라우저에서 취약점을 발견하고 여러 취약점을 연결해 실제 공격 가능성을 검증한 사례다.
Anthropic은 지난 몇 개월 동안 아직 공개하지 않은 내부 연구 모델을 사용했다.
연구 대상에는 Google Chrome과 Apple Safari, Android, Windows와 Linux가 포함됐다.
연구팀은 이번 발표에서 다섯 가지 대표적인 사례를 설명했다.
다만 이번에 공개된 취약점들이 모두 10월 27일에 처음 발견된 것은 아니다.
대부분은 이전에 발견해 해당 소프트웨어 업체에 보고한 뒤 수정 절차를 거친 사례다.
10월 27일의 새로운 발표는 이런 연구 결과와 검증 과정을 공개한 것이다.
Chrome에서는 여러 취약점을 연결해 샌드박스 탈출
Chrome 같은 브라우저는 웹페이지의 JavaScript가 운영체제의 모든 기능에 접근하지 못하도록 여러 보안 계층을 제공한다.
예를 들어 악의적인 웹페이지가 브라우저 내부에서 오류를 발생시켜도 컴퓨터의 다른 프로그램이나 파일에 직접 접근하는 것은 제한돼야 한다.
이를 위한 기술 가운데 하나가 Sandbox(샌드박스)다.
샌드박스는 프로그램이 사용할 수 있는 파일과 메모리, 시스템 자원을 제한하는 실행 환경이다.
Anthropic에 따르면 Claude는 Chrome에서 여러 취약점을 발견한 뒤 이를 연결해 브라우저의 격리 경계를 우회하는 공격 가능성을 확인했다.
연구팀은 일부 취약점이 브라우저 내부의 메모리 관리 문제와 관련돼 있다고 설명했다.
다른 취약점은 격리된 실행 영역 사이의 경계를 우회하는 데 영향을 줬다.
이처럼 여러 취약점을 하나의 공격 과정에 연결하는 것을 Exploit Chain(공격 체인)이라고 한다.
하나의 취약점만으로는 공격 목표를 달성하지 못하더라도 여러 문제가 결합되면 더 심각한 결과가 발생할 수 있다.
Anthropic은 Google에 관련 문제를 보고했다고 밝혔다.
회사 발표에 따르면 Chrome 156까지 총 62개의 CVE가 할당되고 수정됐다.
이 가운데 13개는 샌드박스 탈출과 관련됐고, 21개는 브라우저의 렌더러 프로세스를 침해하는 데 사용될 가능성이 있었다.
CVE(Common Vulnerabilities and Exposures)는 공개적으로 알려진 보안 취약점을 식별하기 위한 고유 번호 체계다.
다만 이 수치는 Anthropic의 이번 연구와 보고 과정에서 확인된 전체 취약점에 관한 회사 발표다.
62개 취약점이 모두 동일한 공격 체인에 사용됐다는 의미는 아니다.
Safari에서는 같은 출처 정책을 우회
Safari 사례에서는 웹사이트 사이의 보안 경계를 우회하는 문제가 확인됐다.
일반적인 브라우저에서는 한 웹사이트의 JavaScript가 다른 웹사이트의 민감한 정보에 마음대로 접근할 수 없다.
이를 SOP(Same-Origin Policy, 동일 출처 정책)라고 한다.
예를 들어 사용자가 이메일 서비스에 로그인한 상태에서 다른 웹사이트를 방문했다고 가정해 보자.
정상적인 브라우저라면 새로 방문한 웹사이트가 이메일 서비스의 로그인 세션과 내용을 마음대로 읽을 수 없어야 한다.
Anthropic에 따르면 Claude는 Safari의 여러 내부 구성요소를 분석하고, 보안 경계가 우회될 수 있는 취약점들의 연결 관계를 찾아냈다.
이론적으로 악의적인 웹사이트가 다른 서비스의 정보에 접근하는 문제가 발생할 수 있었다.
Anthropic은 Apple에 이를 보고했고, Apple이 관련 수정사항을 제공했다고 밝혔다.
다만 이 연구 결과가 실제 일반 사용자의 계정이 대규모로 침해됐다는 사실을 의미하는 것은 아니다.
보안 연구 환경에서 공격 가능성을 검증한 사례다.
Android 잠금 화면 보호와 Windows·Linux도 분석
Android 연구에서는 잠금 상태의 휴대전화에서 개인정보에 접근할 가능성이 있는 취약점들이 확인됐다.
연구팀은 실제 Google Pixel 9 기기를 이용해 분석했다.
Anthropic은 Google이 관련 문제를 수정했다고 밝혔다.
Windows에서는 네트워크 요청을 처리하는 기능의 메모리 안전성 문제가 확인됐다.
Memory Safety(메모리 안전성)는 프로그램이 허용된 메모리 범위를 벗어나 읽거나 쓰지 않도록 보장하는 성질이다.
이런 문제가 발생하면 프로그램이 비정상적으로 종료되거나 공격자가 예상하지 못한 행동을 유도할 가능성이 있다.
Anthropic은 Microsoft에 해당 문제를 보고했고, CVE-2026-33096으로 등록된 취약점이 수정됐다고 설명했다.
Linux에서는 네트워크 처리 과정에서 발생할 수 있는 심각한 취약점이 확인됐다.
연구팀은 해당 문제가 악용될 경우 원격으로 높은 권한의 명령을 실행하는 위험으로 이어질 수 있다고 밝혔다.
관련 문제는 CVE-2026-98432로 공개됐으며 유지보수 중인 Linux 커널 계열에 수정사항이 제공됐다고 설명했다.
이러한 결과는 AI가 단순한 코드 검색을 넘어 복잡한 시스템의 동작을 분석하고 서로 다른 취약점 사이의 관계를 찾아내는 수준에 도달하고 있음을 보여준다.
한 번의 질문보다 병렬 탐색이 효과적
Anthropic은 취약점을 발견하는 과정에서 여러 AI 에이전트를 병렬로 실행했다고 설명했다.
어떤 에이전트는 특정 함수의 메모리 안전성을 조사한다.
다른 에이전트는 공격자가 얻을 수 있는 권한에 초점을 맞춘다.
또 다른 에이전트는 프로그램의 공식 보안 모델을 기준으로 우회 가능성을 분석한다.
이렇게 서로 다른 탐색 전략을 결합하면 하나의 방법으로는 발견하기 어려운 취약점을 찾을 수 있다.
연구팀은 새로운 문제가 발견되면 유사한 코드 패턴을 가진 다른 부분에서도 같은 문제가 발생하는지 조사했다.
이를 Variant Analysis(변종 취약점 분석)이라고 한다.
특정한 취약점이 발견됐을 때 같은 원인이 다른 위치에서도 발생하는지 분석하는 방법이다.
다만 연구팀의 내부 실행 기록 전체와 모델별 성공률이 독립적인 형태로 공개된 것은 아니다.
따라서 이번 결과만으로 어떤 모델이 다른 모든 보안 연구 도구보다 뛰어나다고 판단할 수는 없다.
발견부터 패치까지의 시간 단축이 중요
Anthropic은 발견한 문제를 소프트웨어 업체에 먼저 보고하는 Coordinated Vulnerability Disclosure(조정된 취약점 공개) 절차를 사용했다고 밝혔다.
이 방식은 보안 문제를 발견한 뒤 바로 모든 세부 내용을 공개하는 대신 소프트웨어 개발자가 수정할 시간을 제공한다.
Anthropic은 개발자에게 90일의 수정 기간을 제공하고, 그 이후 추가적인 기간을 거쳐 세부 내용을 공개하는 정책을 설명했다.
이는 취약점 연구가 가진 양면성과 관련된다.
AI가 보안 문제를 더 빠르게 발견할 수 있다면 정상적인 방어 연구자뿐 아니라 공격자도 비슷한 기술을 활용하려 할 수 있다.
따라서 취약점 발견 능력이 증가하는 만큼 수정과 배포, 실제 사용자 시스템의 업데이트 과정도 빨라져야 한다.
이번 발표는 AI의 사이버보안 능력이 단순한 벤치마크의 성능 향상이 아니라 실제 주요 소프트웨어의 보안 연구에 영향을 줄 수 있는 단계로 발전하고 있음을 보여준다.
동시에 외부 보안 연구자와 소프트웨어 유지보수 담당자 사이의 협력, 실제 패치 배포와 검증의 중요성도 커지고 있다.
Google·Oracle, Google TPU를 Oracle Cloud에서 제공하기로 합의…2027년부터 Google 외 첫 대형 클라우드 배포 계획
- 발표일: 2026-10-27 — 정확한 게시 시각 미확인
- 적용 범위: AI 반도체, TPU, Oracle Cloud Infrastructure, AI 데이터센터, 분산 학습, AI 추론 비용
- 원문: Google Cloud·Oracle — Bringing Google TPUs to Oracle Cloud Infrastructure
Google Cloud와 Oracle이 Google의 AI 가속기인 TPU(Tensor Processing Unit)를 Oracle Cloud Infrastructure에서 제공하기 위한 협력을 발표했다.
이번 발표는 새로운 TPU 칩의 출시가 아니다.
Google이 자체적으로 개발한 AI 반도체를 Google Cloud 밖의 다른 대형 클라우드 사업자 인프라에서도 제공하기로 했다는 점이 중요한 변화다.
Oracle은 Google을 제외하고 TPU를 제공하는 첫 번째 대형 클라우드 사업자가 될 예정이다.
다만 10월 27일 발표 시점에 Oracle Cloud에서 TPU가 이미 제공되기 시작한 것은 아니다.
두 회사는 2027년부터 Oracle Cloud에 TPU 용량을 배치할 계획이라고 밝혔다.
GPU와 TPU의 차이
AI 모델을 학습하고 실행할 때는 매우 많은 행렬 계산이 필요하다.
GPU는 이런 계산을 병렬로 수행하는 데 널리 사용된다.
반면 TPU는 Google이 AI 모델의 학습과 추론을 위해 직접 설계한 전용 가속기다.
두 기술 모두 신경망 연산에 사용할 수 있지만 하드웨어 구조와 소프트웨어 환경, 지원하는 연산 방식에 차이가 있다.
Google은 TPU를 단순한 칩이 아니라 반도체와 네트워크, 메모리와 냉각·전력 시스템을 함께 설계하는 플랫폼으로 설명한다.
예를 들어 TPU 수천 개를 연결해 하나의 모델을 학습하려면 칩 사이의 통신이 매우 중요하다.
연산 성능이 높은 칩을 많이 배치해도 데이터를 전달하는 네트워크가 느리면 실제 학습 속도가 떨어질 수 있기 때문이다.
8세대 TPU의 계산 성능
Google에 따르면 8세대 TPU는 칩 하나당 최대 12.6PFLOPS의 FP4 연산 성능을 제공한다.
PFLOPS는 초당 1,000조 회의 부동소수점 연산을 수행할 수 있는 능력을 나타내는 단위다.
FP4는 4비트 부동소수점 숫자 형식이다.
이런 낮은 정밀도의 숫자 표현은 일부 AI 연산에서 메모리와 계산 비용을 줄이는 데 도움이 될 수 있다.
다만 FP4 연산 성능이 높다는 사실만으로 모든 AI 모델의 학습과 추론 속도가 같은 비율로 증가하는 것은 아니다.
모델마다 사용하는 숫자의 정밀도와 계산 패턴이 다르기 때문이다.
Google은 8세대 TPU가 이전 세대보다 전력 대비 최대 두 배 높은 성능을 제공할 수 있다고 설명했다.
이 역시 특정한 하드웨어와 연산 조건에서 얻어진 회사 측 수치다.
대규모 클러스터의 효율은 네트워크가 결정
Google은 TPU의 고속 연결망인 ICI(Inter-Chip Interconnect)와 OCS(Optical Circuit Switching)를 강조했다.
ICI는 서로 다른 TPU 사이에서 데이터를 교환하는 연결 기술이다.
OCS는 광신호의 연결 경로를 변경해 데이터를 전달하는 기술이다.
대규모 AI 학습에서는 일부 장비나 네트워크 연결이 고장 날 수 있다.
이때 모든 작업을 처음부터 다시 시작하면 많은 계산 자원이 낭비된다.
Google은 TPU 클러스터가 장애를 감지하면 일부 광 연결 경로를 변경해 작업을 계속하도록 설계했다고 설명한다.
회사 발표에 따르면 수천 개의 TPU를 사용하는 대규모 학습에서 97% 이상의 Goodput을 유지했다.
Goodput은 전체 실행 시간 가운데 실제로 유용한 계산이 수행된 비율을 의미한다.
예를 들어 GPU나 TPU가 켜져 있더라도 다른 장치의 결과를 기다리는 동안은 실제 학습에 기여하지 못할 수 있다.
따라서 단순한 장비의 가동률과 Goodput은 다르다.
Google은 새로운 연결 구조와 메모리 개선을 통해 일부 저지연 추론 작업에서 비용 대비 성능을 최대 80% 높일 수 있다고 설명했다.
다만 이 수치가 모든 모델에서 추론 비용을 80% 절감한다는 의미는 아니다.
실제 비용은 모델 구조와 입력 길이, 동시 요청 수 등에 따라 달라진다.
PyTorch 생태계와의 호환성 확대
AI 반도체를 도입할 때는 하드웨어의 연산 성능뿐 아니라 개발자가 사용하는 소프트웨어와의 호환성이 중요하다.
예를 들어 PyTorch 기반의 모델을 TPU에서 실행하려면 관련 연산을 TPU가 이해하는 형태로 변환해야 한다.
Google은 최근 공개한 TorchTPU를 통해 이런 작업을 지원하고 있다.
이번 발표에서는 vLLM과 SGLang, llm-d, Hugging Face 등의 도구를 이용해 TPU 기반 모델 실행 환경을 구성할 수 있다고 설명했다.
이는 개발자가 기존 모델 코드를 크게 변경하지 않고도 다른 하드웨어에서 실행할 수 있도록 하려는 방향이다.
하지만 같은 코드를 실행할 수 있다는 사실만으로 모든 하드웨어에서 동일한 성능과 비용이 발생한다는 의미는 아니다.
각 가속기에 맞는 실제 성능 검증이 필요하다.
Oracle 고객에게 새로운 AI 인프라 선택지
Oracle은 기존 데이터베이스와 기업용 애플리케이션을 사용하는 고객을 많이 보유하고 있다.
이런 기업이 AI 시스템을 구축하려면 데이터베이스에 저장된 정보를 모델과 연결해야 할 수 있다.
Oracle Cloud에서 TPU를 사용할 수 있게 되면 해당 고객은 같은 클라우드 환경에서 Oracle의 데이터 서비스와 Google의 AI 가속기를 조합할 수 있다.
다만 실제 사용 가능 지역과 공급량, 가격과 지원되는 TPU 구성은 향후 발표를 통해 구체화돼야 한다.
이번 소식은 AI 인프라의 경쟁 구도가 변화하고 있음을 보여준다.
AI 반도체 제조사와 클라우드 서비스 제공업체가 반드시 하나의 회사에 속해야 하는 것은 아니라는 점이다.
또한 모델 개발자가 특정 하드웨어에 종속되지 않고 작업의 특성에 맞는 가속기를 선택할 수 있도록 하는 소프트웨어 호환성이 중요해지고 있다.
📚 추천 글
Fix evaluation bias to unlock better models on Amazon Bedrock
- 저자: Khaled Thabit, Meriem Boughrara, Mina Metias, Mohamed Desouky, Mohamed Noordeen Alaudeen, Vadim Selyutin
- 발행: AWS Artificial Intelligence Blog / Property Finder
- 게시일: 2026-10-27
- 원문: AWS — Fix evaluation bias to unlock better models on Amazon Bedrock
AI 모델을 평가하는 데이터의 정답이 잘못됐다면 어떤 일이 발생할까?
이 글은 부동산 플랫폼 Property Finder가 실제 운영 중인 이미지 분석 모델을 교체하는 과정에서 발견한 문제를 설명한다.
특히 단순히 더 좋은 모델을 찾는 것이 아니라 모델을 평가하는 정답 데이터 자체가 기존 모델에 유리하게 만들어져 있었다는 사실을 발견한 사례다.
Property Finder는 중동과 북아프리카 지역에서 부동산 정보를 제공하는 서비스다.
이 플랫폼에는 매일 수많은 부동산 이미지가 등록된다.
새로운 매물을 등록할 때는 이미지가 실제 방을 보여주는지, 워터마크가 포함돼 있는지, 이미지 품질이 충분한지 등을 검사해야 한다.
Property Finder는 이런 작업을 위해 AI 이미지 분석 시스템을 사용했다.
모델은 이미지마다 11개의 품질 관련 속성을 평가했다.
문제는 기존 모델의 비용이 높았다는 것이다.
회사는 더 저렴한 모델로 교체하려 했지만 새로운 모델을 평가할 때마다 기존 모델보다 낮은 점수가 나왔다.
처음에는 기존 모델의 성능이 훨씬 뛰어난 것으로 보였다.
하지만 평가 데이터를 조사하면서 더 근본적인 문제가 발견됐다.
정답 데이터의 96.8%가 기존 모델의 출력이었다
연구팀이 확인한 결과 평가 데이터의 정답 가운데 96.8%가 기존 모델의 예측을 그대로 사용한 값이었다.
사람이 직접 검증한 정답이 아니었다는 의미다.
이런 방식은 순환적인 평가 문제를 만든다.
예를 들어 기존 모델이 특정 이미지를 거실이라고 분류했다고 가정해 보자.
평가 데이터에도 그 결과가 정답으로 저장된다.
이후 새로운 모델이 같은 이미지를 침실과 거실이 함께 보이는 장면이라고 판단하면 실제로는 더 정확할 수도 있다.
하지만 기존 모델이 작성한 정답과 다르다는 이유로 오답 처리될 수 있다.
따라서 새로운 모델이 실제로 더 좋은 결과를 생성하더라도 평가에서는 불리해진다.
연구팀은 이런 현상을 Evaluation Bias(평가 편향)라고 설명한다.
평가 데이터나 절차가 특정한 모델이나 결과에 유리하게 설계돼 객관적인 비교가 어려워지는 문제다.
이 사례에서 중요한 것은 기존 모델이 만든 오류도 정답 데이터에 포함될 수 있었다는 사실이다.
예를 들어 이미지의 워터마크를 잘못 읽거나 존재하지 않는 브랜드 이름을 생성한 결과도 정상적인 정답으로 취급될 수 있었다.
독립적인 전문가가 정답을 다시 작성
Property Finder는 이를 해결하기 위해 새로운 평가 데이터를 만들었다.
기존 모델의 예측을 참고하지 않고 전문가가 실제 이미지를 검토하도록 했다.
최종 평가에는 UAE 부동산 이미지 356개가 사용됐다.
이 가운데 256개는 모델과 프롬프트를 개선하는 개발 데이터로 사용됐다.
나머지 100개는 이후 추가됐다.
또한 이집트의 이미지 230개를 이용한 별도의 지역 간 평가도 수행했지만 이번 글에는 전체 결과를 공개하지 않았다.
이 과정에서 단순히 기존 정답을 수정하는 것이 아니라 이미지 분류 기준도 변경했다.
예를 들어 하나의 사진에 두 종류의 방이 함께 보일 수 있다.
기존에는 방의 종류를 하나만 선택하도록 했다.
하지만 실제 사진에는 거실과 연결된 주방이 함께 나타날 수 있다.
연구팀은 이런 경우 여러 레이블을 허용하는 Multi-Label Classification(다중 레이블 분류)으로 변경했다.
이를 통해 모델이 실제로 이해한 내용을 더 적절하게 평가할 수 있게 됐다.
프롬프트 최적화도 평가 기준이 올바를 때 가능
연구팀은 독립적인 정답 데이터를 만든 뒤 새로운 모델을 평가했다.
여기에는 Meta의 Llama 4 Maverick 17B Instruct도 포함됐다.
모델의 출력 형식과 업무 규칙을 명확하게 정의하는 프롬프트를 반복해서 개선했다.
예를 들어 중동 지역의 부동산 이미지에는 장식용 아랍어 문자가 포함될 수 있다.
이런 문자는 실제 워터마크가 아닌데도 모델이 워터마크로 잘못 분류할 수 있다.
연구팀은 이러한 사례를 분석해 프롬프트에 세부적인 규칙을 추가했다.
또한 MIPROv2라는 프롬프트 최적화 도구도 활용했다.
이렇게 총 27개의 주요 프롬프트 버전을 거쳐 최종 구성을 만들었다.
정확도를 높이면서 비용 86% 감소
AWS와 Property Finder가 공개한 결과에서는 새로운 모델의 이미지 분류 성능이 기존 모델보다 높았다.
최종 평가 데이터에서 기존 모델의 Micro F1 점수는 약 0.56이었다.
반면 새롭게 선택한 Llama 4 Maverick 17B Instruct는 약 0.80을 기록했다.
F1 Score(F1 점수)는 예측의 정밀도와 재현율을 함께 고려하는 평가 지표다.
일반적으로 1에 가까울수록 좋다.
이번 모델 교체에서는 추론 비용도 약 86% 감소했다고 밝혔다.
하지만 이 수치는 Property Finder의 특정한 이미지 분석 작업에서 얻어진 결과다.
모든 이미지 분류 업무에서 같은 정확도와 비용 절감 효과가 나타나는 것은 아니다.
또한 최종 평가 이미지 356개 가운데 256개가 프롬프트 개발에도 사용됐으므로 최종 성능 추정치에는 낙관적인 편향이 포함될 수 있다.
연구팀 역시 이런 한계를 명시했다.
이번 글은 AI 모델을 비교할 때 평가 데이터의 품질을 먼저 검증해야 한다는 점을 구체적인 운영 사례로 보여준다.
특히 AI가 생성한 결과를 그대로 정답 데이터로 사용하는 구조에서는 기존 모델의 오류와 편향이 다음 모델의 평가에도 영향을 줄 수 있다는 사실을 이해하기 좋은 자료다.
Exowatt beats frontier models on accuracy with SageMaker serverless model customization
- 저자: Purna Sanyal, Felipe Arce, Jingchao Yang, Tim Child
- 발행: AWS Artificial Intelligence Blog / Exowatt
- 게시일: 2026-10-27
- 원문: AWS — Exowatt beats frontier models on accuracy with SageMaker serverless model customization
강력한 프런티어 모델보다 작은 전문 모델이 실제 업무에서 더 정확할 수 있을까?
이 글은 에너지 기술 기업 Exowatt가 실제 태양광 에너지 설비의 상태를 분석하는 AI 시스템을 구축한 과정을 설명한다.
Exowatt는 AI 데이터센터 같은 전력 수요가 큰 시설에 에너지를 공급하는 시스템을 개발한다.
회사의 설비는 태양에너지를 열 형태로 저장하고 필요할 때 전기를 생산하도록 설계됐다.
이런 설비를 대규모로 운영하려면 여러 장비의 상태를 지속적으로 확인해야 한다.
예를 들어 전압이 정상 범위를 벗어나거나 특정 센서가 예상하지 못한 값을 반환할 수 있다.
이때 운영자는 경고를 분석해 실제 문제가 무엇인지 확인해야 한다.
하지만 설비가 수천 개로 증가하면 모든 경고를 사람이 직접 처리하기 어렵다.
Exowatt는 이를 해결하기 위해 AI 에이전트를 개발했다.
클라우드 연결이 없어도 작동해야 한다
에너지 설비는 항상 안정적인 인터넷 연결을 사용할 수 있는 환경에 존재하지 않는다.
일부 현장에서는 연결이 제한되거나 일시적으로 끊길 수 있다.
따라서 AI가 모든 상황에서 외부 클라우드 모델을 호출해야 한다면 통신 장애가 발생했을 때 정상적인 판단을 수행하기 어렵다.
Exowatt는 Edge AI(엣지 AI)를 사용하기로 했다.
엣지 AI는 데이터가 발생하는 기기나 현장 가까이에서 모델을 실행하는 방식이다.
이 방식에서는 현장 장비가 인터넷에 연결되지 않아도 일부 분석을 수행할 수 있다.
문제는 현장 장비에 고성능 GPU가 없다는 점이었다.
따라서 CPU에서도 실행할 수 있는 작은 모델이 필요했다.
처음에는 상대적으로 큰 모델을 프롬프트만 조정해 사용했지만 원하는 정확도를 얻기 어려웠다.
Exowatt는 이후 Qwen3-1.7B를 특정 업무에 맞게 미세조정했다.
소규모 데이터로 전문 모델 학습
Exowatt는 장비의 상태를 판단하는 예시를 준비했다.
초기 학습에는 684개의 검증된 판단 사례가 사용됐다.
이후 다른 AI 모델로 같은 의미의 설명을 다양하게 바꿔 추가 데이터를 생성했다.
이를 Paraphrasing(의미를 유지한 표현 변경)이라고 한다.
예를 들어 특정 센서가 고장 났다는 동일한 상황을 여러 문장으로 설명할 수 있다.
모델은 서로 다른 표현을 읽더라도 같은 판단을 내려야 한다.
Exowatt는 이런 방식으로 생성한 데이터 가운데 검증을 통과한 1,838개 사례를 추가했다.
최종 학습 데이터는 총 2,522개 사례였다.
중요한 점은 AI가 생성한 문장을 무조건 학습에 사용하지 않았다는 것이다.
숫자와 상태, 정답 레이블이 원래 사례와 일치하는지 프로그램으로 검사했다.
Label(레이블)은 모델이 예측해야 하는 정답이나 분류 항목을 의미한다.
이런 방식으로 실제로 검증된 판단을 유지하면서 문장의 다양성을 높이려 했다.
32분 학습으로 작은 모델을 현장에 배포
Exowatt는 SageMaker의 서버리스 미세조정 기능을 사용했다.
Serverless(서버리스)는 사용자가 개별 서버를 계속 관리하지 않고 필요한 작업을 실행하도록 하는 운영 방식이다.
회사가 발표한 결과에 따르면 Qwen3-1.7B의 추가 학습에는 약 32분이 필요했다.
학습 비용은 약 20~25달러였다.
이후 모델의 숫자 표현을 8비트로 줄였다.
이런 작업을 Quantization(양자화)이라고 한다.
양자화는 모델의 가중치를 낮은 정밀도로 표현해 메모리 사용량과 일부 계산 비용을 줄이는 기술이다.
양자화된 모델의 크기는 약 1.71GiB였다.
이 모델은 실제 현장의 CPU 서버에서 인터넷 연결 없이 실행하도록 구성됐다.
프런티어 모델보다 높은 업무 정확도
Exowatt는 320개 테스트 사례를 이용해 경고 분류 성능을 평가했다.
공개된 결과는 다음과 같다.
| 모델 | Macro F1 |
|---|---|
| Claude Haiku 4.5 | 0.519 |
| Claude Opus 4.7 | 0.680 |
| Claude Sonnet 4.6 | 0.698 |
| 미세조정한 Qwen3-1.7B | 0.911 |
Macro F1은 여러 분류 항목 각각의 F1 점수를 계산한 뒤 평균을 낸 값이다.
특정 항목의 데이터가 많더라도 다른 항목의 성능을 함께 고려하는 데 사용된다.
이번 평가에서는 상대적으로 작은 모델이 더 강력한 범용 모델보다 높은 점수를 기록했다.
하지만 이 결과를 Qwen3-1.7B가 모든 업무에서 Claude Opus보다 뛰어나다는 의미로 해석해서는 안 된다.
Exowatt의 장비 상태 분류라는 좁고 전문적인 작업에 맞춰 학습했기 때문에 얻어진 결과다.
또한 현장의 실제 장애를 자동으로 복구하는 모든 과정이 검증됐다는 의미도 아니다.
이번 평가는 주로 입력된 상태를 올바르게 분류하는 능력을 측정했다.
클라우드 분석에도 같은 방법 적용
Exowatt는 같은 접근을 에너지 시장 분석에도 적용했다.
이번에는 Qwen3-14B를 사용했다.
모델은 전력 가격과 수요, 시장 공지 등을 분석해 특정한 사건이 발생했는지 판단하도록 학습됐다.
연구팀은 약 5년의 전력시장 데이터를 활용했다.
초기 데이터에는 약 1억6천300만 개의 행이 포함됐다.
이를 정해진 규칙에 따라 분류하고, AI가 문장의 표현을 변경한 데이터를 추가해 학습에 활용했다.
미세조정한 Qwen3-14B는 테스트에서 Macro F1 0.975를 기록했다.
비교 대상인 Claude Opus 4.7의 점수는 0.625였다.
또한 회사가 계산한 1,000회 분석 비용은 약 0.60달러로, 비교한 Claude Opus 4.7의 약 29.26달러보다 낮았다.
약 49배의 비용 차이다.
하지만 이 계산은 회사가 측정한 토큰 사용량과 해당 API의 가격을 기준으로 했다.
모델 개발과 데이터 구축, 검증에 필요한 전체 비용을 모두 포함한 수치는 아니다.
작은 모델이 강한 이유는 전문 데이터
이번 글에서 특히 중요한 점은 모델의 크기보다 업무에 적합한 학습 데이터와 검증 절차가 성능을 좌우했다는 사실이다.
작은 모델은 모든 분야의 지식을 폭넓게 처리하는 데 한계가 있을 수 있다.
하지만 반복적으로 발생하는 특정한 업무에서는 필요한 판단 기준이 비교적 명확할 수 있다.
예를 들어 현장 설비의 경고를 몇 가지 유형으로 분류하는 작업은 회사의 장비와 운영 규칙을 정확히 학습하는 것이 중요하다.
이런 경우 범용 모델을 매번 호출하는 것보다 작은 전문 모델을 현장에서 실행하는 방식이 효율적일 수 있다.
이번 글은 AI 에이전트의 운영 구조를 설계할 때 어떤 업무를 범용 모델에 맡기고 어떤 업무를 작은 전문 모델로 분리할지 판단하는 데 유용한 실제 사례다.
3 Ways to Boost MoE Inference on NVIDIA DGX Spark
- 저자: NVIDIA Technical Blog
- 발행: NVIDIA
- 게시일: 2026-10-27
- 원문: NVIDIA — 3 Ways to Boost MoE Inference on NVIDIA DGX Spark
같은 모델과 같은 하드웨어를 사용하면서 AI의 답변 생성 속도를 높일 수 있을까?
이 글은 NVIDIA가 Ling-3.0-flash라는 대형 언어모델을 이용해 실제 추론 병목을 분석하고 최적화한 과정을 설명한다.
특히 단순히 새로운 기술을 소개하는 데서 끝나지 않고 서로 다른 최적화를 결합했을 때 예상과 다른 성능 저하가 발생하는 문제까지 다룬다는 점에서 읽어볼 가치가 있다.
MoE 모델의 실제 계산 구조
이번 실험에 사용된 Ling-3.0-flash는 약 1,240억 개의 전체 파라미터를 가진 모델이다.
하지만 토큰 하나를 처리할 때 사용하는 활성 파라미터는 약 51억 개다.
이는 MoE(Mixture of Experts) 구조 때문이다.
MoE는 여러 전문 신경망 가운데 현재 입력에 필요한 일부만 실행하는 방식이다.
예를 들어 모델에 수백 개의 전문가 네트워크가 존재하더라도 각 토큰에서는 일부 전문가만 활성화할 수 있다.
따라서 전체 모델이 매우 크더라도 매번 모든 전문가를 계산하지는 않는다.
하지만 이 방식에는 다른 문제가 있다.
활성화해야 하는 전문가의 가중치를 메모리에서 읽어야 하기 때문이다.
특히 사용자가 한 번에 하나의 요청을 처리하는 환경에서는 GPU의 연산 장치가 충분히 빠르더라도 메모리에서 데이터를 가져오는 과정이 병목이 될 수 있다.
이를 Memory-Bound(메모리 대역폭에 의해 성능이 제한되는 상태)라고 한다.
NVIDIA는 실제 실행 시간을 분석한 결과 모델의 MoE 계산과 최종 출력 계층에서 상당한 시간이 소요된다는 사실을 확인했다.
첫 번째: MoE 연산 커널 최적화
첫 번째 방법은 Humming이라는 GPU 연산 커널을 사용하는 것이다.
Kernel(커널)은 GPU에서 특정 계산을 수행하도록 작성된 프로그램 단위다.
같은 수학적 계산이라도 GPU 커널이 데이터를 어떻게 배치하고 실행하는지에 따라 처리 속도가 달라질 수 있다.
NVIDIA는 기존 FlashInfer 기반 커널 대신 Humming을 사용했다.
그 결과 출력 토큰 생성 속도가 다음과 같이 달라졌다.
| 구성 | 초당 출력 토큰 |
|---|---|
| 기존 구성 | 36.09 |
| Humming 적용 | 39.45 |
약 9.3% 개선된 결과다.
이 수치는 NVIDIA DGX Spark에서 특정 모델과 입력 길이, 배치 크기를 사용한 평가 결과다.
모든 MoE 모델에서 같은 성능 향상이 나타나는 것은 아니다.
두 번째: 출력 계층의 FP8 양자화
언어모델은 다음 토큰을 선택하기 위해 최종적으로 여러 단어 후보의 점수를 계산한다.
이 작업을 담당하는 구성요소를 LM Head(언어모델 출력 계층)라고 한다.
모델의 어휘가 매우 많으면 이 계층의 행렬도 커질 수 있다.
Ling-3.0-flash에서는 약 15만7천 개의 토큰 후보를 처리한다.
NVIDIA는 출력 계층의 숫자 표현을 더 낮은 정밀도의 FP8로 변환했다.
FP8은 숫자를 8비트 부동소수점 형식으로 표현하는 방식이다.
기존 BF16보다 숫자 하나를 저장하는 데 필요한 공간이 적다.
따라서 같은 가중치를 읽는 데 필요한 메모리 전송량을 줄일 수 있다.
NVIDIA는 Humming과 FP8 출력 계층을 함께 적용해 기존 구성보다 21.7% 높은 출력 처리량을 기록했다고 밝혔다.
다만 숫자 정밀도를 낮추면 일부 계산 결과가 달라질 수 있다.
따라서 성능을 개선할 때는 모델의 정확성도 함께 평가해야 한다.
세 번째: 여러 토큰을 예측한 뒤 검증
세 번째 방법은 Speculative Decoding(추측 디코딩)이다.
일반적인 언어모델은 다음 토큰을 하나씩 생성한다.
반면 추측 디코딩에서는 여러 토큰의 후보를 먼저 제안한 뒤 이를 한 번에 검증하도록 구성할 수 있다.
Ling-3.0-flash에는 NEXTN이라는 여러 토큰 예측 기능이 포함돼 있다.
NVIDIA는 이를 활용해 한 번의 검증 과정에서 여러 출력 토큰을 처리하도록 했다.
합성 평가에서는 한 번의 과정에서 평균 3.9개 토큰이 채택됐다.
해당 조건에서는 출력 처리량이 기존보다 최대 185.1% 개선됐다.
하지만 합성 평가의 최고 성능 수치를 실제 모든 작업에 적용할 수는 없다.
추측한 토큰이 실제 모델의 선택과 일치하지 않으면 다시 계산해야 할 수 있기 때문이다.
실제 수학 평가에서는 42.5% 개선
NVIDIA는 세 가지 기술을 함께 적용한 구성을 GSM8K 평가에서도 시험했다.
GSM8K는 수학 문장제 문제를 이용해 언어모델의 추론 능력을 평가하는 벤치마크다.
그 결과 출력 처리량이 42.5% 증가했다.
평균 지연시간은 24.5% 감소했다.
NVIDIA는 이번 평가에서 통계적으로 확인할 수 있는 수준의 정답률 차이는 발견되지 않았다고 설명했다.
다만 유의미한 정확도 차이를 발견하지 못했다는 사실이 모든 입력에서 완전히 동일한 답변을 생성한다는 의미는 아니다.
또한 이번 결과는 특정 모델과 하드웨어에서 측정한 자체 평가다.
NVIDIA는 최적화 기술들을 단순히 결합했을 때 오히려 성능이 저하되는 사례도 설명했다.
각 기술이 GPU의 메모리와 계산 자원을 사용하는 방식이 서로 다르기 때문이다.
이번 글은 AI 추론 최적화가 단순히 더 빠른 GPU 커널을 추가하는 작업이 아니라 실제 병목을 측정하고 서로 다른 최적화 사이의 상호작용을 검증하는 과정이라는 점을 이해하기 좋은 자료다.
Fine-Tuning NVIDIA Nemotron to Know Local Rules, Not Just Local Languages
- 저자: NVIDIA Technical Blog
- 발행: NVIDIA
- 게시일: 2026-10-27
- 원문: NVIDIA — Fine-Tuning NVIDIA Nemotron to Know Local Rules, Not Just Local Languages
AI가 특정 국가의 언어를 이해한다면 그 나라의 행정 절차와 문화도 올바르게 이해한다고 볼 수 있을까?
이 글은 그런 가정이 항상 성립하지 않는 이유를 설명한다.
특히 NVIDIA와 프랑스 AI 기업 Pleias, 벨기에 KU Leuven이 개발한 지역별 합성 인물 데이터를 이용해 언어모델을 미세조정하는 방법을 소개한다.
일반적인 대형 언어모델은 여러 나라의 언어와 문서를 학습한다.
하지만 특정 국가의 행정 절차나 규제, 지역별 차이를 정확하게 처리하는 것은 별도의 문제다.
예를 들어 같은 프랑스어를 사용하는 사람이라도 프랑스 본토와 해외 영토에 거주하는 경우 적용되는 행정 비용과 절차가 다를 수 있다.
따라서 특정 언어로 자연스럽게 답변하는 능력과 해당 지역의 실제 규칙을 올바르게 적용하는 능력은 구분해야 한다.
프랑스 여권 신청 사례
NVIDIA는 건강 문제로 직접 이동하기 어려운 사람이 프랑스 여권을 신청하는 상황을 예시로 들었다.
일반적인 모델은 우편으로 관련 서류를 제출하면 된다고 설명할 수 있다.
하지만 해당 조건에서 실제로 필요한 절차는 다를 수 있다.
NVIDIA는 공식 행정 문서를 기반으로 해당 상황에 필요한 절차를 확인하고, 이를 모델의 학습 데이터에 반영하는 방법을 소개했다.
예를 들어 이동이 어려운 사람은 특정한 의료 증명서를 준비하고 담당 공무원이 방문하도록 요청해야 할 수 있다.
중요한 것은 모델이 프랑스어를 얼마나 자연스럽게 사용하는지가 아니다.
실제 행정 절차를 잘못 안내하지 않는 것이다.
행정이나 의료, 금융처럼 잘못된 설명이 실제 피해로 이어질 수 있는 분야에서는 이런 차이가 중요하다.
합성 인물 데이터를 지역 통계에 맞춰 생성
NVIDIA는 Nemotron-Personas-France와 Nemotron-Personas-Belgium이라는 데이터셋을 소개했다.
Synthetic Persona(합성 인물)는 실제 개인의 개인정보를 그대로 복사하는 대신 여러 특성을 조합해 만든 가상의 인물이다.
예를 들어 특정 지역에 거주하는 40대 직장인과 가족 구성, 언어와 생활환경을 설정할 수 있다.
하지만 인물의 특성을 완전히 무작위로 설정하면 실제 사회의 분포와 크게 달라질 수 있다.
NVIDIA는 이를 해결하기 위해 국가별 인구와 지역, 직업과 가구에 관한 통계를 활용했다고 설명한다.
예를 들어 프랑스의 합성 인물에는 실제 행정구역과 지역적 특성을 반영할 수 있다.
벨기에 데이터에는 네덜란드어와 프랑스어, 독일어와 영어 등 여러 언어 사용 환경이 포함된다.
이렇게 하면 특정한 사용자 집단에만 맞춰진 데이터보다 다양한 상황을 학습시킬 수 있다.
합성 대화와 공식 문서를 결합
연구팀은 합성 인물이 특정한 질문을 하는 상황을 생성한다.
이후 해당 질문에 적용되는 공식 문서와 규칙을 연결한다.
예를 들어 여권 신청에 관한 질문이라면 실제 행정기관의 안내를 확인해 학습 데이터의 근거로 사용한다.
이 과정에서 중요한 것은 합성 데이터의 양을 늘리는 것이 아니라 각 답변의 사실관계를 검증할 수 있도록 구성하는 것이다.
AI가 만든 질문과 답변을 그대로 다시 학습하면 기존의 잘못된 정보를 반복해서 학습할 가능성이 있다.
반면 공식 규정을 바탕으로 답변을 구성하면 특정 지역의 실제 절차에 더 가까운 학습 데이터를 만들 수 있다.
NVIDIA는 이런 데이터를 이용해 Nemotron 3.5 Lightning을 미세조정하는 과정을 설명했다.
미세조정은 기존에 학습된 모델의 일부 또는 전체 파라미터를 새로운 데이터에 맞춰 추가 학습하는 과정이다.
이번 글에서는 데이터 생성과 학습, 평가에 사용할 수 있는 공개 코드와 에이전트 Skills도 소개한다.
지역화는 번역 이상의 문제
이번 글에서 중요한 관점은 Localization(지역화)이 단순히 문장을 번역하는 작업과 다르다는 점이다.
예를 들어 하나의 고객지원 서비스를 여러 국가에서 운영한다고 가정해 보자.
모델이 해당 국가의 언어를 정확하게 구사하더라도 실제 환불 규정이나 행정 절차가 다르면 잘못된 답변을 생성할 수 있다.
또한 같은 언어를 사용하는 국가 사이에도 문화와 법률, 가격과 신청 절차가 다를 수 있다.
따라서 여러 국가를 대상으로 AI 서비스를 제공하려면 언어 지원뿐 아니라 지역별 공식 규정과 실제 사용자 상황을 반영하는 데이터가 필요하다.
다만 합성 데이터를 사용했다고 해서 모든 인구 집단을 정확하게 대표할 수 있는 것은 아니다.
일부 소수 집단이나 특수한 상황이 데이터에 충분히 포함되지 않을 수 있다.
또한 규정이 변경되면 이전 학습 데이터의 내용도 오래될 수 있다.
따라서 실제 서비스에서는 공식 문서의 최신성을 유지하고 모델의 답변을 정기적으로 평가해야 한다.
이번 글은 AI 모델을 특정 산업과 국가에 도입할 때 범용 모델의 언어 능력보다 실제 업무에 필요한 지역적 정확성이 더 중요한 문제가 될 수 있다는 점을 구체적인 사례로 보여준다.