AI 데일리 브리핑 — 2026-11-06

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

---

1️⃣ 주요 모델·연구

OpenAI, 사이버보안 전문 모델 ‘GPT-6 Cyber’ 공개…취약점 재현 능력 51% 개선하고 허용된 공격 범위 준수 강화

• 발표일: 2026-11-05 — 정확한 게시 시각 미확인
• 적용 범위: 사이버보안 AI, 코딩 에이전트, 취약점 연구, 보안 자동화, 오픈소스 보안, AI 안전성
• 원문: OpenAI — GPT-6 Cyber: Advancing the frontier of aligned cybersecurity agents

---

OpenAI가 사이버보안 연구에 특화된 새로운 모델 GPT-6 Cyber를 공개했다.

이번 모델은 기존 GPT-5.6 Cyber의 후속 모델이다. 일반적인 문서 작성이나 대화보다는 소프트웨어의 취약점을 분석하고, 문제가 실제로 발생하는지 검증하며, 수정 방법을 찾는 작업에 초점을 맞췄다.

이번 발표에서 특히 중요한 변화는 두 가지다.

첫 번째는 실제 보안 문제를 분석하는 기술적 능력이 크게 높아졌다는 점이다.

두 번째는 강력한 보안 분석 능력을 유지하면서도 사용자가 허용한 시스템과 작업 범위를 벗어나지 않도록 하는 능력을 강화했다는 점이다.

사이버보안 분야에서는 이 두 능력이 함께 중요하다.

예를 들어 기업의 보안 담당자가 자사 서버의 취약점을 검사하도록 AI에 요청할 수 있다.

AI가 해당 취약점을 발견하고 실제로 재현할 수 있다면 정상적인 보안 연구에 도움이 된다.

하지만 검사 과정에서 허용되지 않은 다른 서버에 접근하거나 외부 시스템의 인증정보를 사용한다면 문제가 발생할 수 있다.

따라서 모델은 기술적으로 가능한 행동과 실제로 허용된 행동을 구분해야 한다.

ExploitGym에서 기존 모델보다 16.4%포인트 개선

OpenAI는 GPT-6 Cyber의 보안 능력을 여러 벤치마크에서 평가했다.

벤치마크(Benchmark)는 동일한 조건에서 여러 모델의 성능을 비교하도록 만든 평가 환경이다.

대표적인 평가인 ExploitGym은 모델이 지정된 취약점을 실제로 재현할 수 있는지 측정한다.

취약점 재현은 소프트웨어에 문제가 있다는 설명을 작성하는 것보다 복잡하다.

프로그램의 구조를 이해하고 문제가 발생하는 조건을 확인해야 한다. 이후 격리된 환경에서 해당 문제가 실제로 발생하는지 검증해야 한다.

공개된 결과는 다음과 같다.

GPT-6 Cyber는 기존 모델보다 16.4%포인트 높은 성공률을 기록했다.

상대적인 개선율은 약 51%다.

여기서 51%라는 수치는 성공률 자체가 51%포인트 증가했다는 의미가 아니다. 기존 성공률 대비 상대적으로 얼마나 개선됐는지를 나타낸다.

OpenAI는 실제 웹 애플리케이션에서 취약점을 발견하는 별도의 평가도 수행했다.

이 평가에서는 모델에게 소스코드를 제공하지 않고, 실제 웹서비스를 분석하는 방식으로 취약점을 찾도록 했다.

그 결과 GPT-6 Cyber는 40.3%의 재현율(Recall)을 기록했다.

비교 대상인 GPT-6 Astra는 32.0%였다.

재현율은 실제로 존재하는 문제 가운데 시스템이 얼마나 많은 문제를 발견했는지 나타내는 지표다.

하지만 두 평가 모두 OpenAI가 설계하거나 운영한 평가 결과다.

모든 종류의 소프트웨어에서 GPT-6 Cyber가 같은 비율로 더 많은 취약점을 발견한다는 의미는 아니다.

공격 범위를 준수하는 능력도 평가

OpenAI는 이번 모델에서 허용되지 않은 시스템을 공격하지 않는 능력을 별도로 학습시켰다.

일반적인 보안 평가에서는 모델이 사용할 수 있는 대상과 도구, 네트워크 범위를 미리 지정한다.

이런 조건을 Rules of Engagement(보안 평가의 수행 규칙)라고 한다.

예를 들어 특정 서버의 취약점을 검증하도록 허용받았더라도 같은 네트워크에 존재하는 다른 서버까지 검사할 권한이 있는 것은 아니다.

OpenAI는 이런 상황을 시험하기 위해 ExploitGym Honeypot 평가를 사용했다.

평가 환경에는 실제 공격 대상과 별도로 쉽게 침해할 수 있도록 만든 서비스가 존재한다.

모델이 과제를 해결하려는 과정에서 해당 서비스를 발견하더라도 원래 허용된 대상이 아니므로 접근해서는 안 된다.

공개된 결과는 다음과 같다.

GPT-6 Cyber는 별도의 배포용 안전 지침이 없는 조건에서도 대부분의 평가에서 허용 범위를 준수했다.

배포용 안전 지침을 적용한 조건에서는 평가 대상 전부에서 허용 범위를 지켰다.

하지만 100%라는 결과가 실제 모든 보안 작업에서 규칙 위반이 발생하지 않는다는 보장은 아니다.

이는 특정한 격리 평가 환경에서 측정한 수치다.

새로운 종류의 취약점이나 예상하지 못한 실행 환경에서는 다른 결과가 나타날 수 있다.

Firefox와 Linux에서 실제 취약점 연구에 활용

OpenAI는 GPT-6 Cyber가 실제 소프트웨어의 보안 문제를 발견하는 데 활용된 사례도 공개했다.

대표적인 대상은 Mozilla Firefox와 Linux 커널이다.

Firefox 관련 연구에서는 이전에 알려지지 않았던 고위험 취약점 81개가 발견됐다.

OpenAI는 재현 가능한 자료와 수정 제안을 Mozilla에 전달했다고 밝혔다.

Mozilla는 이 가운데 여러 문제에 대한 수정사항을 배포했다.

Linux 커널 관련 연구에서도 대규모 취약점 분석이 진행됐다.

연구팀은 948개의 권한 상승 공격 재현 사례를 개발했다고 설명했다.

권한 상승(Privilege Escalation)은 프로그램이나 사용자가 원래 허용된 수준보다 높은 시스템 권한을 얻는 현상을 의미한다.

이런 문제는 정상적인 보안 연구에서 발견하고 수정해야 할 중요한 취약점이다.

다만 이러한 사례가 모두 11월 5일에 처음 발견된 것은 아니다.

기존에 진행하던 보안 연구의 결과를 이번 모델 발표와 함께 소개한 것이다.

또한 발견된 모든 문제가 이미 수정됐다는 의미도 아니다.

실제 소프트웨어의 보안 수정은 개발자 검토와 테스트, 배포 과정을 거쳐야 한다.

보안 능력은 Critical 등급으로 분류

OpenAI는 이번 모델을 자사의 Preparedness Framework에 따라 평가했다.

Preparedness Framework는 강력한 AI 모델에서 발생할 수 있는 위험을 분류하고 필요한 보호조치를 정하기 위한 OpenAI의 내부 안전성 체계다.

이번 평가에서 GPT-6 Cyber는 사이버보안 능력의 Critical 등급에 해당하는 것으로 분류됐다.

기존 GPT-5.6 Cyber는 High 등급이었다.

이는 모델이 실제로 악성 공격을 수행했다는 의미가 아니다.

모델이 가진 기술적 능력이 높아져 일반적인 모델보다 강한 접근 제한과 감시가 필요하다는 OpenAI의 내부 판단이다.

OpenAI는 이를 위해 사용자를 검증하고 일부 고위험 보안 작업에 별도의 접근권한을 부여한다.

또한 실제 모델 사용 기록에서 위험한 행동을 탐지하기 위한 감시 기능을 적용한다.

현재는 승인된 보안 고객에게만 제공

GPT-6 Cyber는 발표일부터 API와 Codex를 통해 제공된다.

하지만 모든 사용자가 이용할 수 있는 것은 아니다.

초기에는 Daybreak Red 프로그램의 승인을 받은 일부 고객에게만 제공된다.

OpenAI는 향후 승인된 Daybreak Red 고객 전체로 제공 범위를 확대할 계획이다.

또한 별도의 Daybreak Red for Critical Infrastructure 프로그램도 발표했다.

이 프로그램은 발전소와 상수도 시설 등 중요한 기반시설을 방어하는 보안 담당자를 위한 접근 체계다.

이런 시스템에서는 잘못된 보안 테스트가 실제 장비의 동작에 영향을 줄 수 있기 때문에 별도의 보호조치가 필요하다.

이번 발표는 AI의 사이버보안 능력이 단순한 코드 분석을 넘어 실제 취약점을 찾아 검증하고 수정까지 지원하는 수준으로 발전하고 있음을 보여준다.

동시에 모델의 기술적 능력이 강해질수록 실제 사용자의 권한과 검사 범위를 관리하는 기술도 중요해지고 있다.

---

Google Research, 스마트워치의 광학·움직임 센서로 고혈압 위험을 감지하는 AI 연구 발표…혈압계 보정 없이 장기간 신호 분석

• 발표일: 2026-11-05 — 정확한 게시 시각 미확인
• 적용 범위: 의료 AI, 웨어러블 센서, 멀티모달 머신러닝, 고혈압 선별검사, 스마트워치, 디지털 헬스
• 원문: Google Research — Detecting signs of hypertension using wearable sensors

---

Google Research가 일반적인 스마트워치에 포함된 센서로 지속적인 고혈압의 징후를 감지하는 AI 시스템의 연구 결과를 공개했다.

이번 연구는 국제학술지 Nature에 발표된 논문을 기반으로 한다.

특히 기존 혈압 측정 기술과 달리 상완에 착용하는 혈압계로 주기적인 보정을 수행하지 않고도 고혈압 위험을 선별하도록 설계했다는 점이 특징이다.

일반적인 혈압계는 팔을 압박하는 커프를 이용해 혈압을 측정한다.

반면 스마트워치에는 주로 심박수와 움직임을 측정하기 위한 센서가 포함돼 있다.

기존의 일부 커프리스 혈압 측정 기술은 이런 센서와 전통적인 혈압계의 측정값을 연결해 추정값을 계산한다.

하지만 이런 방법은 정기적인 보정이 필요할 수 있다.

Google은 다른 접근을 선택했다.

정확한 수축기·이완기 혈압 수치를 계산하는 대신, 여러 날에 걸쳐 수집한 생리학적 신호에서 지속적인 고혈압의 가능성을 판단하도록 모델을 설계했다.

PPG와 가속도 센서를 함께 사용

연구팀은 두 종류의 스마트워치 센서를 사용했다.

첫 번째는 PPG(Photoplethysmography, 광용적맥파) 센서다.

PPG는 피부에 빛을 비춘 뒤 반사되는 빛의 변화를 분석하는 기술이다.

혈액량이 변하면 빛의 반사 특성도 달라질 수 있다.

스마트워치는 이를 이용해 심박수와 맥파의 형태를 추정할 수 있다.

두 번째는 가속도 센서(Accelerometer)다.

일반적으로 스마트워치에서는 걸음 수와 움직임을 측정하는 데 사용된다.

하지만 매우 작은 움직임을 분석하면 심장이 혈액을 내보낼 때 발생하는 미세한 기계적 진동도 관찰할 수 있다.

이를 BCG(Ballistocardiogram, 심탄도 신호)라고 한다.

연구팀은 두 신호를 함께 분석했다.

예를 들어 맥파의 형태는 혈관의 탄성과 혈액 흐름에 관한 정보를 포함할 수 있다.

가속도 센서의 미세 진동은 심장 박동의 기계적 특성에 관한 정보를 제공할 수 있다.

두 정보를 함께 사용하면 하나의 센서만 사용할 때보다 더 다양한 생리학적 특징을 분석할 가능성이 있다.

다만 특정한 신호가 관찰됐다고 해서 곧바로 고혈압이라고 진단할 수 있는 것은 아니다.

다른 생리학적 요인도 같은 신호에 영향을 줄 수 있기 때문이다.

49만 시간 이상의 센서 데이터로 사전학습

Google은 두 단계의 학습 구조를 사용했다.

첫 번째 단계에서는 PPG와 가속도 데이터를 이용해 신호의 특징을 학습했다.

연구팀은 2,109명의 자발적 참가자로부터 수집한 약 49만2천347시간의 센서 데이터를 사용했다.

여기에는 반드시 고혈압 여부가 기록돼 있을 필요는 없었다.

모델은 같은 사람에게서 수집된 여러 신호가 어떤 공통적인 특징을 가지는지 학습했다.

이런 방식을 자기지도학습(Self-Supervised Learning)이라고 한다.

정답을 사람이 하나씩 지정하지 않고 데이터 자체에 존재하는 관계를 이용해 학습하는 방법이다.

연구팀은 약 15초 길이의 신호 구간을 모델에 입력했다.

이후 모델이 각 구간의 특징을 여러 숫자로 표현하도록 만들었다.

이를 임베딩(Embedding)이라고 한다.

두 번째 단계에서는 여러 날에 걸쳐 생성된 임베딩을 결합했다.

이렇게 하면 특정한 순간의 움직임이나 온도 변화가 결과에 지나치게 큰 영향을 주는 문제를 줄일 수 있다.

연구팀은 최종적으로 임베딩과 사용자의 키 정보를 결합해 고혈압 가능성을 계산했다.

여기에는 로지스틱 회귀(Logistic Regression)가 사용됐다.

로지스틱 회귀는 여러 입력값을 이용해 특정한 범주에 속할 가능성을 계산하는 통계적 방법이다.

196명을 대상으로 임상 비교

Google은 미국 다섯 곳의 임상 연구시설에서 196명의 참가자를 대상으로 전향적 검증을 수행했다.

참가자들은 알려진 심혈관질환이 없었고 혈압약을 복용하지 않는 사람들이었다.

연구팀은 스마트워치의 예측 결과를 24시간 활동혈압 측정(ABPM)과 비교했다.

ABPM은 하루 동안 여러 시간대의 혈압을 반복해서 측정하는 방법으로, 고혈압의 실제 상태를 판단할 때 중요한 기준으로 사용된다.

초기 선별검사에서 공개된 결과는 다음과 같다.

민감도(Sensitivity)는 실제로 고혈압이 있는 사람 가운데 시스템이 고혈압 가능성을 발견한 비율이다.

특이도(Specificity)는 실제로 고혈압이 없는 사람 가운데 정상으로 분류한 비율이다.

양성 예측도(PPV)는 시스템이 고혈압 가능성이 있다고 판단한 사람 가운데 실제로 고혈압이 있었던 비율이다.

초기 선별검사에서 민감도 65.8%를 기록했다는 것은 실제 고혈압이 있는 사람 가운데 일부를 놓쳤다는 의미다.

따라서 이 시스템이 고혈압 가능성을 발견하지 못했다고 해서 고혈압이 없다고 판단해서는 안 된다.

추가 확인 단계에서는 특이도 90.9%

연구팀은 진료실에서 처음 측정한 혈압이 높았던 참가자 48명을 따로 분석했다.

이 집단에서는 다음과 같은 결과를 기록했다.

초기 선별검사보다 높은 민감도를 기록했다.

하지만 표본이 48명으로 작다는 점을 고려해야 한다.

또한 양성 예측도는 실제 검사 대상 집단에서 고혈압이 얼마나 흔한지에 영향을 받는다.

따라서 이번 연구의 96.7%라는 수치를 일반적인 모든 스마트워치 사용자에게 그대로 적용할 수는 없다.

Google은 이번 결과가 Google Health 앱의 Health Guardian 혈압 추세 기능을 개발하는 데 활용됐다고 밝혔다.

하지만 해당 기능이 모든 스마트워치와 모든 국가에서 이미 제공된다는 의미는 아니다.

실제 이용 가능 여부는 기기와 지역, 제품 제공 조건에 따라 달라질 수 있다.

고혈압의 위험을 알려주는 도구와 진단 도구는 다르다

이번 연구에서 가장 중요한 구분은 혈압 수치의 측정과 고혈압 위험의 선별이다.

Google의 모델은 특정한 시점의 수축기 혈압과 이완기 혈압을 정확하게 계산하는 방식이 아니다.

여러 날에 걸쳐 나타난 생리학적 신호를 분석해 고혈압 가능성을 추정한다.

따라서 기존 혈압계를 완전히 대체하는 기술로 이해해서는 안 된다.

실제 진단과 치료에는 검증된 혈압 측정과 의료진의 판단이 필요하다.

이번 연구는 일반적인 웨어러블 기기에서 수집하는 데이터를 이용해 평소에는 증상을 느끼기 어려운 건강 문제의 위험 신호를 더 일찍 발견할 가능성을 보여준다.

하지만 이를 실제 의료서비스에 적용하려면 다양한 연령과 건강 상태, 기기 환경에서의 추가 검증이 필요하다.

---

Anthropic, 과학 연구 관련 Claude 사용 20만7천 건 분석…연구 아이디어보다 데이터 분석과 논문 작성에 활용 집중

• 발표일: 2026-11-05 — 정확한 게시 시각 미확인
• 적용 범위: AI 과학 연구, Claude Code, 연구 생산성, AI 활용 통계, 학술 데이터 분석, AI 에이전트
• 원문: Anthropic — AI for scientific discovery: How researchers use Claude

---

Anthropic이 과학 연구와 관련된 Claude 사용 기록을 분석한 새로운 연구 보고서를 발표했다.

이번 연구는 AI가 과학 문제를 얼마나 잘 해결하는지 측정하는 벤치마크가 아니다.

실제 연구자들이 AI를 어떤 작업에 사용하고 있으며, 그 활용 방식이 연구 활동의 중요도와 얼마나 일치하는지 조사했다는 점이 특징이다.

연구팀은 개인정보 보호를 고려한 자동 분류 방법을 사용해 약 20만7천49개의 연구 관련 세션을 분석했다.

자료는 2026년 8월 2일부터 9월 30일까지 수집된 Claude의 개인용 요금제 사용 기록을 기반으로 한다.

분석 대상은 두 집단으로 나뉜다.

Claude Code는 파일을 읽고 수정하거나 프로그램을 실행할 수 있는 코딩 에이전트다.

일반적인 Claude 대화와 달리 실제 개발·분석 도구를 직접 사용하는 작업이 포함될 수 있다.

연구 업무를 7,262개 작업으로 분류

Anthropic은 연구 활동을 체계적으로 구분하기 위해 SciNet이라는 분류 체계를 사용했다.

여기에는 34개 연구 분야와 318개 세부 분야, 7,262개 연구 작업이 포함된다.

예를 들어 연구자는 논문을 작성하거나 통계 자료를 분석할 수 있다.

실험을 설계하거나 데이터를 수집할 수도 있다.

또한 새로운 가설을 제안하고 해당 가설을 검증하는 방법을 고안할 수도 있다.

Anthropic은 사용자의 대화를 자동 분류한 뒤 어떤 종류의 업무에 Claude가 사용됐는지 조사했다.

그 결과 데이터 분석과 글쓰기가 실제 사용에서 높은 비중을 차지했다.

데이터 분석은 실제 연구자가 사용하는 시간보다 Claude 활용에서 더 높은 비중을 차지했다.

반면 데이터 수집과 새로운 가설을 만드는 작업은 상대적으로 활용 비중이 낮았다.

데이터 분석에서는 AI의 역할이 크다

연구자가 데이터를 분석하는 작업에서는 컴퓨터로 처리할 수 있는 부분이 많다.

예를 들어 수백만 개의 관측값에서 통계적 특징을 계산할 수 있다.

특정한 분석 방법을 구현하기 위해 Python이나 R 코드를 작성할 수도 있다.

또는 여러 실험 결과를 비교하고 그래프로 표현할 수 있다.

이런 작업에서는 Claude Code 같은 코딩 에이전트가 직접 프로그램을 실행할 수 있다.

반면 실제 실험실에서 시료를 준비하거나 장비를 조작하는 업무는 일반적인 언어모델만으로 수행하기 어렵다.

Anthropic은 이런 차이가 실제 사용 패턴에도 나타났다고 설명한다.

컴퓨터과학과 수학, 통계학처럼 디지털 업무의 비중이 높은 연구 분야에서는 Claude 사용이 상대적으로 많았다.

반면 실제 실험과 현장 자료 수집의 비중이 높은 연구 분야에서는 활용이 적었다.

이는 AI가 과학 연구 전체를 균등하게 자동화하고 있는 것은 아니라는 사실을 보여준다.

연구자가 중요하게 생각하는 일과 AI에 맡기는 일은 다르다

Anthropic은 별도로 528명의 연구자를 대상으로 설문조사도 수행했다.

연구자들은 새로운 가설을 생성하고 실제 데이터를 수집하는 작업을 과학적 성과에 중요한 활동으로 평가했다.

하지만 실제 Claude 사용 기록에서는 이러한 작업의 비중이 상대적으로 낮았다.

예를 들어 AI가 논문 초안을 작성하는 데 도움을 줄 수 있다.

하지만 어떤 연구 질문이 학문적으로 중요한지 판단하는 일은 더 복잡하다.

해당 분야의 기존 연구와 아직 해결되지 않은 문제, 실제 실험 가능성 등을 함께 고려해야 하기 때문이다.

또한 새로운 연구 아이디어가 그럴듯하다고 해서 실제로 독창적이거나 실험으로 검증 가능한 것은 아니다.

Anthropic은 이런 이유로 AI가 잘 수행하는 작업과 연구자가 가장 중요하게 생각하는 작업 사이에 차이가 존재한다고 설명했다.

실제 연구 생산성 증가를 직접 측정한 것은 아니다

이번 보고서를 해석할 때는 중요한 제한이 있다.

연구팀이 관찰한 것은 Claude 서비스의 사용 기록이다.

따라서 Claude를 사용하지 않는 연구자나 다른 AI 제품을 사용하는 연구자는 충분히 반영되지 않을 수 있다.

또한 연구 관련 대화를 자동으로 분류하는 과정에서 오류가 발생할 가능성이 있다.

무엇보다 사용량이 많다는 사실만으로 실제 연구 성과가 같은 비율로 증가했다고 판단할 수는 없다.

예를 들어 데이터 분석 관련 대화가 증가했더라도 실제로 새로운 과학적 발견이 더 많이 발생했는지는 별도로 검증해야 한다.

이번 연구는 AI가 과학 연구를 얼마나 빠르게 만드는지 직접 측정하기보다 현재 과학 연구의 어느 부분에서 AI가 실제로 사용되고 있는지를 보여주는 자료다.

특히 AI가 연구자의 반복적인 디지털 업무를 지원하는 단계에서 출발해 실제 실험과 새로운 가설 개발까지 얼마나 확대될 수 있는지가 앞으로의 중요한 과제가 될 수 있다.

---

2️⃣ AI 제품·서비스

Google, 영상 생성 모델 ‘Gemini Omni 1.2 Flash’ 출시…15초 영상·대화형 수정 지원하고 생성 가격 30% 인하

• 발표일: 2026-11-05 — 정확한 게시 시각 미확인
• 적용 범위: 생성형 영상 AI, 멀티모달 모델, 영상 편집, Google Vids, Gemini API, 광고 콘텐츠 제작
• 원문: Google — Gemini Omni 1.2 Flash: Fast and cost-effective with longer clips

---

Google이 생성형 영상 모델 Gemini Omni 1.2 Flash를 공개하고 정식 제공을 시작했다.

이번 모델은 기존 Omni 1.1 Flash의 후속 버전이다.

주요 개선사항은 생성 가능한 영상의 길이와 기존 참고자료를 유지하는 능력, 대화형 수정 기능이다.

또한 Google은 기존 모델보다 생성 가격을 30% 낮췄다고 밝혔다.

일반적인 영상 생성 모델에서는 사용자가 장면을 설명하면 해당 설명을 바탕으로 새로운 영상을 만든다.

하지만 결과물이 원하는 모습과 조금 다르다면 처음부터 다시 생성해야 하는 경우가 많다.

예를 들어 광고 영상의 배경이나 조명만 바꾸고 싶은 상황을 생각할 수 있다.

기존 방식에서는 전체 영상을 다시 생성하면서 원래 등장인물의 외모나 움직임이 달라질 가능성이 있다.

Omni 1.2 Flash는 이런 문제를 줄이기 위해 기존 영상을 유지하면서 일부 조건을 대화로 수정하는 기능을 강화했다.

최대 15초 영상 생성

이번 모델은 최대 15초 길이의 영상을 생성할 수 있다.

기존 Omni 1.1 Flash의 최대 길이는 10초였다.

영상의 길이는 3초부터 15초까지 1초 단위로 지정할 수 있다.

예를 들어 사용자가 7초 길이의 상품 소개 영상이나 15초 길이의 짧은 광고를 요청할 수 있다.

이런 기능은 광고와 소셜미디어 콘텐츠, 제품 설명 영상에 활용될 수 있다.

하지만 영상 길이가 15초로 늘어났다는 사실만으로 모든 장면의 일관성이 완벽하게 유지된다는 의미는 아니다.

영상 생성 모델은 시간이 지날수록 사물의 형태나 위치가 변하는 오류를 만들 수 있다.

이를 Visual Drift(시각적 일관성의 변화)라고 한다.

예를 들어 같은 사람이 영상의 앞부분과 뒷부분에서 미세하게 다른 얼굴을 가질 수 있다.

또는 처음 등장했던 물체의 형태가 시간이 지나면서 달라질 수도 있다.

Google은 이런 문제를 줄이기 위해 참고 이미지와 영상의 조건을 더 정확하게 유지하도록 모델을 개선했다고 설명했다.

제품 사진과 음성·동작 참고자료를 함께 사용

Omni 1.2 Flash는 여러 종류의 참고자료를 함께 사용할 수 있다.

예를 들어 인물 사진과 제품 사진을 제공할 수 있다.

여기에 짧은 동작 영상이나 음성 자료를 추가할 수도 있다.

모델은 이러한 자료를 바탕으로 새로운 영상을 생성한다.

Google은 실제 의류 사진을 이용해 가상의 착용 장면을 만드는 사례를 공개했다.

예를 들어 하나의 인물 사진과 여러 의류의 앞뒤 사진을 이용할 수 있다.

모델은 등장인물과 옷의 형태를 유지하면서 카메라 각도가 바뀌는 영상을 생성하도록 설계됐다.

또한 여러 등장인물이 대화하는 장면에서 음성과 입의 움직임을 맞추는 기능도 개선했다.

이를 Lip Sync(입 모양과 음성의 동기화)라고 한다.

대화형 영상에서는 어떤 인물이 어떤 대사를 말하는지 정확하게 연결하는 것이 중요하다.

하지만 이번 발표에서는 모든 종류의 복잡한 대화 장면에서 정확도가 얼마나 개선됐는지에 관한 독립적인 수치 평가가 제공되지는 않았다.

여러 번의 대화로 같은 영상 수정

이번 모델의 중요한 기능은 Multi-Turn Editing(여러 차례의 대화형 수정)이다.

사용자는 처음 생성한 영상을 바탕으로 추가적인 수정 요청을 할 수 있다.

예를 들어 숲을 배경으로 만든 영상에서 등장인물과 카메라 움직임은 유지한 채 배경만 성으로 바꾸도록 요청할 수 있다.

이후 날씨와 조명을 다시 변경할 수도 있다.

이런 방식은 기존 결과물을 일부 유지하면서 새로운 변형을 생성하는 데 도움이 된다.

하지만 실제로 생성된 모든 픽셀이 그대로 유지된다는 의미는 아니다.

모델이 새로운 영상을 생성하는 과정에서 원래의 사물과 배경을 일부 변경할 가능성은 남아 있다.

따라서 브랜드 로고와 상품명, 중요한 문구처럼 정확성이 필요한 요소는 최종 결과를 검토해야 한다.

생성 가격 30% 인하

Google은 Omni 1.2 Flash의 가격도 공개했다.

720p 영상 기준으로 초당 0.07달러다.

기존 Omni 1.1 Flash보다 30% 낮은 가격이다.

예를 들어 15초 길이의 영상을 한 번 생성한다면 해당 기준의 영상 생성 비용은 1.05달러에 해당한다.

다만 실제 청구액에는 사용하는 해상도와 기능, 생성 횟수 등에 따른 차이가 발생할 수 있다.

또한 사용자가 원하는 결과가 나올 때까지 여러 번 생성한다면 전체 비용은 증가한다.

Google은 낮은 해상도에서 초안을 생성하고 필요한 부분을 수정한 뒤 최종 결과를 고해상도로 변환하는 방식을 제안했다.

예를 들어 360p나 720p로 초안을 만들고 최종 결과를 1080p 또는 4K로 업스케일할 수 있다.

Upscaling(업스케일링)은 영상의 해상도를 높이는 처리 과정이다.

하지만 해상도가 높아졌다는 사실만으로 실제 원본에 없던 세부 정보가 정확하게 복원된다는 의미는 아니다.

Gemini API와 Google 제품으로 제공

이번 모델은 Gemini API와 Google Cloud에서 정식 제공된다.

또한 Google Vids와 Flow, Gemini 앱 등에서도 사용할 수 있도록 확대되고 있다.

다만 모든 제품의 제공 상태가 동일한 것은 아니다.

Gemini 앱의 일부 기능은 Google AI Ultra 사용자를 대상으로 단계적으로 배포된다.

또한 생성한 영상에는 SynthID 워터마크가 적용된다.

SynthID는 AI가 생성한 콘텐츠를 식별하는 데 활용할 수 있도록 눈이나 귀로 쉽게 구분되지 않는 신호를 포함하는 기술이다.

이번 발표는 생성형 영상 AI가 단순히 새로운 영상을 만들어내는 기술에서 벗어나 기존 결과물을 유지하고 반복적으로 수정하는 실제 제작 도구로 발전하고 있음을 보여준다.

---

Anthropic, Claude에 은행·카드 계좌를 연결하는 ‘Personal Finance’ 베타 출시…거래 내역 분석과 지출 관리 지원

• 발표일: 2026-11-05 — 정확한 게시 시각 미확인
• 적용 범위: 생성형 AI 개인 비서, 금융 데이터 분석, Plaid, 지출 관리, 개인정보 보호, 금융 AI
• 원문: Anthropic — Introducing Personal Finance in Claude

---

Anthropic이 Claude에서 사용자의 은행과 신용카드 계좌를 연결해 금융 정보를 분석하는 Personal Finance 기능을 베타로 공개했다.

이번 기능은 Claude가 실제 금융거래를 수행하도록 만드는 서비스가 아니다.

사용자가 이미 보유한 계좌의 거래 내역과 잔액을 연결해 자신의 소비와 재정 상황을 이해하도록 지원하는 도구다.

기존에는 사용자가 자신의 재정 상황을 분석하기 위해 여러 은행 앱을 열어야 하는 경우가 있었다.

예를 들어 월급이 들어오는 은행 계좌와 카드 결제 계좌가 다를 수 있다.

또한 구독 서비스의 결제와 대출 이자, 생활비 지출이 여러 금융기관에 분산돼 있을 수 있다.

이런 상황에서는 한 달 동안 실제로 얼마를 사용했는지 파악하기 어려울 수 있다.

Claude Personal Finance는 사용자가 연결한 계좌의 정보를 함께 분석하도록 설계됐다.

Plaid를 이용한 읽기 전용 계좌 연결

이번 기능에서는 Plaid를 사용한다.

Plaid는 금융기관의 계좌정보를 외부 애플리케이션과 연결하도록 지원하는 서비스다.

사용자는 Plaid를 통해 자신의 은행에 직접 로그인하고 필요한 접근권한을 승인한다.

Claude가 사용자의 은행 비밀번호를 직접 입력받는 방식은 아니다.

또한 계좌 접근은 읽기 전용(Read-Only)으로 제한된다.

읽기 전용은 정보를 조회할 수 있지만 실제 데이터를 변경하거나 거래를 실행할 수는 없는 권한이다.

따라서 Claude는 사용자를 대신해 송금하거나 주식을 구매할 수 없다.

이번 기능의 주요 목적은 사용자의 금융정보를 분석하고 설명하는 것이다.

최대 2년의 거래 내역 활용

사용자가 계좌를 연결하면 Claude는 다음과 같은 정보를 사용할 수 있다.

예를 들어 사용자는 지난달 소비가 평소보다 많았는지 질문할 수 있다.

Claude는 연결한 계좌의 거래 내역을 분석해 지출을 항목별로 정리할 수 있다.

또한 같은 금액이 중복 결제됐는지 확인하거나 정기 구독료가 증가했는지 조사할 수 있다.

이번 기능은 지출 그래프와 결제 일정, 대시보드 생성도 지원한다.

하지만 이런 분석이 항상 정확한 것은 아니다.

예를 들어 거래 내역의 가맹점 이름만으로 실제 지출 목적을 정확하게 분류하기 어려울 수 있다.

또한 금융기관의 거래 기록이 늦게 반영되는 경우도 존재한다.

따라서 중요한 잔액과 결제 금액은 실제 금융기관의 자료와 비교해야 한다.

계좌 연결과 AI 학습의 구분

Anthropic은 개인정보 보호를 위한 별도 조건도 설명했다.

Personal Finance 허브 안에서 진행한 대화는 모델 학습에 사용하지 않는다고 밝혔다.

하지만 Claude의 일반적인 다른 대화에서 공유한 정보는 사용자의 기존 개인정보 설정을 따른다.

따라서 Personal Finance 허브의 처리 조건과 일반 대화의 처리 조건은 구분해야 한다.

또한 사용자는 연결한 계좌를 언제든 해제할 수 있다.

계좌 연결을 해제하면 Claude가 해당 계좌의 새로운 데이터에 접근할 수 없게 된다.

다만 금융정보의 처리와 보관에 관한 구체적인 내용은 실제 서비스의 개인정보 정책과 연결 서비스의 약관을 함께 확인해야 한다.

현재는 미국 유료 사용자 대상 베타

Personal Finance는 발표 주간부터 미국에서 단계적으로 제공된다.

대상 요금제는 Claude Pro, Max, Ultra다.

미국 이외의 국가에서 동일한 기능을 사용할 수 있다는 발표는 없었다.

또한 Anthropic은 이번 기능이 투자 자문을 제공하도록 설계되지 않았다고 설명했다.

예를 들어 사용자가 지출 구조와 대출 이자의 의미를 이해하도록 도울 수 있다.

하지만 사용자를 대신해 금융상품을 구매하거나 투자 판단을 실행하지는 않는다.

이번 발표는 생성형 AI 개인 비서가 일반적인 질문·답변에서 벗어나 사용자의 실제 금융 데이터를 연결해 지속적인 생활관리 도구로 확장되는 방향을 보여준다.

동시에 금융 분야에서는 개인정보와 실제 거래 권한을 엄격하게 구분해야 한다는 점도 중요하다.

---

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

Google, AI 에이전트 인프라 3종을 CNCF에 기증…Agent Substrate 1.0 정식 출시로 유휴 에이전트 실행 환경 자동 복원

• 발표일: 2026-11-05 — 정확한 게시 시각 미확인
• 적용 범위: 오픈소스 AI 인프라, Kubernetes, AI 에이전트, 보안 샌드박스, 강화학습, GKE, CNCF
• 원문: Google Cloud — Open infrastructure for autonomous agents comes to CNCF

---

Google이 AI 에이전트 실행과 보안, 강화학습에 사용되는 세 가지 오픈소스 프로젝트를 CNCF(Cloud Native Computing Foundation)에 기증한다고 발표했다.

대상 프로젝트는 Agent Substrate, gVisor, OpenRL이다.

CNCF는 Kubernetes와 여러 클라우드 네이티브 기술의 개발과 운영을 지원하는 재단이다.

이번 발표에서 중요한 부분은 프로젝트의 소유와 개발 방향을 특정 기업에서 중립적인 오픈소스 재단으로 옮긴다는 점이다.

이와 함께 Google은 Agent Substrate 1.0을 정식 출시하고 Google Kubernetes Engine에서 관리형 서비스로 제공하기 시작했다.

다만 세 프로젝트가 이번에 처음 개발됐다는 의미는 아니다.

gVisor는 2018년부터 공개된 오픈소스 기술이다.

Agent Substrate와 OpenRL 역시 이전부터 개발돼 왔다.

또한 세 프로젝트의 CNCF Sandbox 승인 자체는 10월에 이뤄졌으며, 11월 5일에는 기증과 실제 제공 상태를 발표했다.

AI 에이전트는 실제 계산보다 기다리는 시간이 길 수 있다

일반적인 AI 에이전트는 언어모델만 실행하지 않는다.

예를 들어 코딩 에이전트는 파일을 읽고 테스트를 실행할 수 있다.

이후 모델이 다음 행동을 판단하는 동안 기다린다.

외부 API의 응답이나 사용자의 승인도 기다릴 수 있다.

문제는 에이전트가 기다리는 동안에도 실행 환경이 서버의 메모리와 CPU를 점유할 수 있다는 점이다.

예를 들어 에이전트 하나마다 별도의 컨테이너를 계속 실행한다고 가정해 보자.

실제 코드를 실행하는 시간은 짧아도 해당 컨테이너는 장시간 유지될 수 있다.

에이전트의 수가 수만 개로 증가하면 상당한 서버 자원이 사용될 수 있다.

Agent Substrate는 이런 문제를 해결하기 위해 설계됐다.

Agent Substrate는 상태와 계산 자원을 분리

Agent Substrate의 핵심은 에이전트의 상태와 실제 실행 자원을 분리하는 것이다.

Google은 이를 세 가지 구성요소로 설명한다.

예를 들어 에이전트가 파일을 수정하고 작업 결과를 저장했다고 가정해 보자.

이후 외부 API의 응답을 기다려야 한다.

일반적인 구조에서는 에이전트의 실행 컨테이너를 그대로 유지할 수 있다.

하지만 Agent Substrate는 현재 상태를 저장한 뒤 Worker를 다른 작업에 사용할 수 있도록 반환한다.

이 과정을 Snapshot(스냅샷 저장)이라고 한다.

스냅샷은 특정 시점의 프로그램과 파일 상태를 나중에 복원할 수 있도록 저장한 자료다.

새로운 작업이 도착하면 저장된 상태를 다른 Worker에서 복원한다.

이렇게 하면 에이전트마다 고정된 실행 컨테이너를 장시간 유지할 필요가 줄어든다.

500ms 이내 복원과 10배 높은 밀도

Google은 Agent Substrate가 유휴 상태의 에이전트를 저장했다가 500밀리초 이내에 복원할 수 있다고 밝혔다.

또한 일반적인 컨테이너 실행 방식과 비교해 약 10배 높은 에이전트 실행 밀도를 제공한다고 설명했다.

실행 밀도는 같은 서버 자원에서 얼마나 많은 에이전트 실행 환경을 관리할 수 있는지 나타낸다.

Google은 초당 500회 이상의 일시 중단과 재개 작업도 처리할 수 있다고 밝혔다.

하지만 이 수치들은 Google이 공개한 자체 기술 평가 결과다.

모든 종류의 에이전트와 실제 클라우드 환경에서 같은 복원 시간과 자원 효율이 나타나는 것은 아니다.

특히 실제 작업의 상태가 크거나 파일을 많이 사용하는 경우에는 저장과 복원에 필요한 시간이 달라질 수 있다.

gVisor는 실제 프로그램 실행을 격리

두 번째 프로젝트는 gVisor다.

gVisor는 AI 에이전트가 실행하는 프로그램을 격리하는 데 사용할 수 있다.

일반적인 Linux 컨테이너는 호스트 운영체제의 커널을 공유한다.

Kernel(커널)은 운영체제가 하드웨어와 메모리, 파일과 프로그램 실행을 관리하는 핵심 구성요소다.

문제는 AI 에이전트가 예상하지 못한 코드를 실행할 수 있다는 점이다.

예를 들어 에이전트가 외부 패키지를 설치하거나 사용자가 제공한 코드를 실행할 수 있다.

이때 악의적인 코드가 포함돼 있다면 실행 환경의 보안이 중요해진다.

gVisor는 사용자 공간에서 동작하는 별도의 커널 계층을 제공해 애플리케이션이 호스트 커널에 직접 접근하는 범위를 제한한다.

이를 Sandbox(샌드박스)라고 한다.

샌드박스는 프로그램이 접근할 수 있는 시스템 자원과 행동을 제한하는 격리 환경이다.

Google은 gVisor가 이미 여러 클라우드와 AI 기업의 실행 환경에서 사용되고 있다고 설명했다.

하지만 gVisor를 사용한다고 해서 모든 보안 취약점이 사라지는 것은 아니다.

실제 시스템에는 네트워크 접근과 인증정보, 파일 권한 등에 관한 추가적인 보안 설정이 필요하다.

OpenRL은 에이전트의 강화학습을 지원

세 번째 프로젝트는 OpenRL이다.

OpenRL은 Kubernetes 환경에서 AI 모델의 강화학습을 수행하도록 지원하는 프레임워크다.

강화학습(Reinforcement Learning)은 모델이 수행한 행동의 결과에 보상을 제공해 더 좋은 행동을 학습시키는 방법이다.

예를 들어 코딩 에이전트가 실제 코드 수정 작업을 수행한다고 가정해 보자.

테스트가 통과하면 높은 보상을 줄 수 있다.

반대로 프로그램이 정상적으로 동작하지 않으면 낮은 보상을 줄 수 있다.

이런 작업을 여러 번 반복하면 모델이 더 좋은 행동을 선택하도록 학습시킬 수 있다.

OpenRL은 이러한 실험을 여러 서버에서 병렬로 실행하는 구조를 제공한다.

또한 PyTorch와 vLLM 같은 기존 AI 개발 도구를 연결할 수 있다.

PyTorch는 신경망의 학습과 계산을 지원하는 프레임워크다.

vLLM은 언어모델의 추론을 효율적으로 실행하기 위한 오픈소스 도구다.

OpenRL은 LoRA 기반의 미세조정과 전체 파라미터 학습을 지원한다.

다만 OpenRL은 세 프로젝트 가운데 상대적으로 초기 단계에 있다.

Google은 TPU 지원도 향후 계획으로 제시했으므로 모든 하드웨어에서 동일한 수준의 기능이 이미 제공되는 것은 아니다.

CNCF Sandbox 승인과 정식 제품은 다른 개념

이번 발표에서는 프로젝트들이 CNCF Sandbox에 포함됐다는 점도 강조됐다.

하지만 CNCF Sandbox는 기술적으로 완성됐다는 인증이 아니다.

오픈소스 커뮤니티가 프로젝트를 공동으로 개발하고 관리하기 위한 초기 단계에 가깝다.

따라서 CNCF Sandbox에 포함됐다는 이유만으로 모든 기업이 해당 기술을 즉시 대규모 운영 환경에 적용할 수 있다고 판단해서는 안 된다.

반면 Agent Substrate on GKE는 1.0 정식 제공 상태다.

개발자는 Google Cloud의 관리형 환경을 사용할 수도 있고 오픈소스 코드를 이용해 다른 Kubernetes 클러스터에 직접 배포할 수도 있다.

이번 발표는 AI 에이전트를 대규모로 운영하는 데 필요한 기술이 모델 실행뿐 아니라 상태 복원과 보안 격리, 작업 스케줄링과 강화학습 인프라까지 확장되고 있음을 보여준다.

---

4️⃣ 산업·정책·안전

METR, Anthropic 내부 AI 연구개발 속도 독립 평가…AI 활용 이후 기술 발전 속도 약 2배 증가 추정

• 발표일: 2026-11-05 — 정확한 게시 시각 미확인
• 적용 범위: 프런티어 AI 안전, AI 연구개발 자동화, 독립 안전성 평가, 연구 생산성, AI 거버넌스
• 원문: METR — Independent Assessment of AI R&D Acceleration at Anthropic in October 2026

---

독립 AI 평가기관 METR가 Anthropic의 내부 연구개발 과정을 조사한 결과를 공개했다.

이번 연구는 단순히 Claude가 특정한 벤치마크에서 얼마나 높은 점수를 기록했는지 평가한 것이 아니다.

AI 기업이 자신의 AI 모델을 이용해 새로운 AI 모델을 개발하는 과정이 실제로 얼마나 빨라지고 있는지 조사했다는 점에서 주목할 만하다.

최근 AI 코딩 에이전트는 프로그램을 작성하고 테스트를 실행하는 능력이 빠르게 발전하고 있다.

AI 연구기관에서는 새로운 모델을 만들기 위해 많은 소프트웨어 개발과 실험이 필요하다.

예를 들어 모델의 학습 방법을 변경하려면 관련 코드를 작성해야 한다.

이후 실제로 학습을 수행하고 성능을 평가해야 한다.

결과가 좋지 않으면 원인을 분석하고 새로운 실험을 진행해야 한다.

이런 과정을 AI 에이전트가 지원한다면 연구자는 더 많은 아이디어를 시험할 수 있다.

문제는 이러한 생산성 개선이 실제 AI 모델의 발전 속도를 얼마나 높이는지 객관적으로 측정하기 어렵다는 점이다.

METR은 이를 확인하기 위해 Anthropic의 내부 자료에 접근했다.

약 11주 동안 내부 연구자료 조사

METR의 평가는 2026년 8월 12일부터 10월 29일까지 진행됐다.

연구팀은 Anthropic의 내부 모델 평가와 학습 관련 자료, 연구자 설문과 인터뷰 등을 검토했다.

조사 대상에는 다음과 같은 정보가 포함됐다.

• 모델의 사전학습과 강화학습 관련 성능 자료
• 모델 학습에 사용되는 계산 자원의 변화
• 내부 모델의 벤치마크 결과
• 연구자들이 AI를 사용하면서 경험한 작업 속도 변화
• 실제 연구 과정에서 AI 에이전트가 수행하는 역할

METR은 약 15명의 Anthropic 직원과 인터뷰도 진행했다.

이 자료를 바탕으로 최근 AI 모델의 기술적 능력이 얼마나 빠르게 향상되고 있는지 분석했다.

모델 능력의 발전 속도 약 1.9배 증가

METR은 Anthropic의 내부 모델 평가 자료를 이용해 발전 속도를 계산했다.

여기에는 AECI(Anthropic's Epoch Capabilities Index)라는 지표가 사용됐다.

AECI는 여러 평가에서 얻은 모델의 성능을 하나의 지표로 결합해 기술적 능력의 변화를 추적하는 방법이다.

METR은 2025년 10월 이전과 이후의 발전 속도를 비교했다.

그 결과 2025년 10월 이후 발전 속도가 이전보다 약 1.9배 높아진 것으로 추정했다.

통계적 95% 신뢰구간은 약 1.5~2.8배였다.

이 결과는 과거에 약 2년 동안 달성하던 수준의 평가 점수 개선이 최근에는 약 1년에 발생한 것과 비슷하다는 의미다.

하지만 모든 종류의 AI 능력이 정확히 1.9배 빠르게 발전한다는 의미는 아니다.

AECI는 주로 명확한 정답이나 검증 가능한 결과가 있는 작업을 평가한다.

따라서 새로운 연구 아이디어의 독창성이나 실제 과학적 발견, 복잡한 사회적 의사결정처럼 평가하기 어려운 능력까지 동일하게 반영하는 것은 아니다.

연구개발 속도 증가의 원인은 무엇인가

METR은 발전 속도가 빨라진 원인을 조사했다.

가능한 원인에는 AI의 연구 지원과 연구 인력 증가, 새로운 알고리즘, 학습 데이터 개선과 계산 자원 확대 등이 포함된다.

METR은 학습 계산 자원의 증가 속도가 더 빨라졌기 때문에 이번 결과가 발생한 것은 아니라는 판단을 제시했다.

반면 나머지 요인들의 기여도를 정확하게 분리하는 것은 어려웠다.

연구팀은 내부 자료와 인터뷰를 종합해 현재의 가속 가운데 상당 부분이 AI의 연구개발 지원에서 비롯됐을 가능성이 높다고 추정했다.

METR이 제시한 주관적인 추정에서는 현재 가속의 약 80%가 AI 활용에 기인했을 가능성을 언급했다.

하지만 이는 엄격한 실험으로 확인된 인과적 비율이 아니다.

연구팀도 상당한 불확실성이 존재한다고 강조했다.

실제 연구자들 사이에서도 어느 요인이 가장 중요한지에 관한 의견이 달랐다.

완전 자율 연구보다 사람을 지원하는 방식이 중심

METR은 현재의 연구개발 가속이 주로 AI의 보조적 활용에서 나타났다고 설명한다.

예를 들어 연구자가 새로운 학습 방법을 생각해 낼 수 있다.

이후 AI 에이전트가 해당 방법을 코드로 구현하고 테스트를 실행하도록 도울 수 있다.

연구자는 여러 실험 결과를 확인해 어떤 방법을 더 조사할지 결정한다.

이런 구조에서는 AI가 상당한 양의 개발 작업을 수행하더라도 연구 방향을 정하는 역할은 사람이 담당할 수 있다.

따라서 이번 결과를 Anthropic의 AI가 스스로 새로운 AI 모델을 완전히 자율적으로 개발하고 있다는 증거로 해석해서는 안 된다.

다만 METR은 AI가 연구자의 보조 역할을 넘어 더 많은 실험 과정을 자율적으로 수행할 가능성도 관찰했다고 밝혔다.

이런 변화가 지속된다면 향후 연구개발 속도가 더 빨라질 가능성이 있다.

하지만 실제로 그러한 가속이 계속될지는 아직 불확실하다.

자료 공개에는 상당한 제한 존재

이번 보고서에서 특히 중요한 부분은 평가의 독립성과 공개 가능한 자료 사이에 차이가 있었다는 점이다.

Anthropic은 METR에 상당한 양의 내부 연구자료를 제공했다.

하지만 계약상 일부 비공개 자료를 최종 보고서에서 삭제하도록 요구할 권한도 가지고 있었다.

METR에 따르면 Anthropic은 실제로 중요한 근거 가운데 상당 부분의 공개를 제한했다.

따라서 일반 독자는 METR의 결론을 뒷받침하는 모든 자료를 직접 확인할 수 없다.

METR은 이로 인해 공개 보고서가 이상적인 수준의 증거 투명성을 확보하지 못했다고 설명했다.

또한 원래 평가 범위에 포함돼 있던 학습 계산 자원의 배분에 대한 별도 검증도 도중에 취소됐다.

이 검증은 AI의 능력을 높이는 연구와 안전성 연구에 계산 자원이 어떻게 배분되는지 확인하려는 작업이었다.

Anthropic은 평가의 초점을 연구개발 가속 문제에 맞추기 위해 범위를 변경했다고 설명했다.

따라서 이번 보고서가 Anthropic의 모든 AI 안전 활동과 자원 배분을 독립적으로 검증한 것은 아니다.

AI 연구의 가속과 안전성 평가의 중요성

이번 연구가 중요한 이유는 AI가 실제 개발자의 업무를 빠르게 만드는 수준에서 더 나아가 AI 모델 자체를 개발하는 속도에도 영향을 줄 수 있다는 점 때문이다.

이런 현상은 장기적으로 기술 발전을 더욱 가속할 가능성이 있다.

하지만 AI 모델이 강력해질수록 실제로 어떤 행동을 수행할 수 있는지 평가하는 과정도 중요해진다.

예를 들어 모델의 코딩 능력이 높아졌다면 보안 취약점을 발견하거나 외부 프로그램을 조작하는 능력도 함께 변할 수 있다.

따라서 기술 발전 속도를 추적하는 것뿐 아니라 안전성 평가와 외부 검증이 그 속도를 따라갈 수 있는지 확인해야 한다.

이번 METR 보고서는 상당한 내부 자료를 바탕으로 작성된 독립적인 평가이지만, 공개 증거의 제한과 연구팀이 인정한 불확실성도 함께 고려해 읽어야 한다.

---

NVIDIA, AI 에이전트용 Vera CPU의 실제 운영 성능 공개…동시 실행 수와 샌드박스 시작 속도 개선

• 발표일: 2026-11-05 — 정확한 게시 시각 미확인
• 적용 범위: AI 반도체, CPU 인프라, AI 에이전트, 데이터센터, 코드 실행 샌드박스, 전력 효율
• 원문: NVIDIA — Vera Delivers the Best of Both Worlds: Highest Throughput and Fastest Agents

---

NVIDIA가 AI 에이전트 실행에 특화된 Vera CPU의 성능 평가 결과를 공개했다.

이번 발표는 Vera CPU라는 제품 자체를 처음 공개한 소식이 아니다.

기존에 발표한 CPU가 실제 AI 에이전트 작업과 샌드박스 실행 환경에서 어떤 성능을 제공하는지 여러 협력기업의 평가를 통해 설명한 것이다.

AI 모델을 실행할 때는 일반적으로 GPU가 중요하다고 생각하기 쉽다.

GPU는 신경망의 대규모 행렬 연산을 병렬로 처리하는 데 적합하다.

하지만 AI 에이전트는 모델의 추론만 수행하지 않는다.

예를 들어 코딩 에이전트는 파일을 읽고 프로그램을 실행한다.

테스트를 수행하거나 데이터베이스에 쿼리를 보낼 수도 있다.

이런 작업의 상당 부분은 CPU에서 실행된다.

따라서 실제 에이전트 시스템의 처리 속도는 GPU의 추론 성능뿐 아니라 CPU의 실행 성능에도 영향을 받는다.

AI 에이전트에서는 CPU와 GPU의 역할이 다르다

예를 들어 사용자가 코딩 에이전트에게 웹 애플리케이션의 오류를 수정하라고 요청했다고 가정해 보자.

먼저 GPU에서 언어모델이 관련 코드를 분석할 수 있다.

이후 모델이 테스트 명령을 실행하라고 판단한다.

실제 테스트 프로그램은 CPU를 사용해 실행될 수 있다.

테스트가 끝나면 결과를 다시 모델에 전달한다.

모델은 다음 행동을 결정한다.

이런 과정에서는 GPU와 CPU 사이에 작업이 반복적으로 이동한다.

GPU의 추론이 매우 빠르더라도 CPU에서 프로그램을 실행하는 시간이 길다면 전체 작업은 느려질 수 있다.

Vera CPU는 이런 종류의 작업을 효율적으로 처리하도록 설계됐다.

전력당 동시 에이전트 수 비교

NVIDIA는 100MW 규모의 데이터센터를 가정한 비교에서 Vera CPU의 처리량을 평가했다.

공개된 결과에 따르면 Vera는 비교 대상인 가장 빠른 x86 CPU보다 전력당 약 1.6배 많은 에이전트를 지원했다.

또한 에너지 효율이 높은 다른 x86 CPU와 비교했을 때는 에이전트 작업 속도가 약 2배 높았다고 설명했다.

이 결과를 이해할 때는 두 지표를 구분해야 한다.

첫 번째는 하나의 작업을 완료하는 속도다.

두 번째는 같은 전력으로 동시에 처리할 수 있는 작업의 수다.

예를 들어 어떤 CPU는 하나의 작업을 매우 빠르게 처리할 수 있지만 많은 전력을 소비할 수 있다.

반대로 다른 CPU는 전력 효율이 높지만 개별 작업의 속도가 느릴 수 있다.

실제 데이터센터에서는 두 요소를 함께 고려해야 한다.

다만 이번 수치는 NVIDIA가 공개한 자체 비교 결과다.

모든 AI 서비스에서 동일한 성능 향상이 나타난다고 판단해서는 안 된다.

실제 협력기업의 평가 결과

NVIDIA는 여러 기업이 수행한 시험 결과도 공개했다.

Daytona의 평가에서는 샌드박스 1,000개를 시작하는 데 Vera 환경에서 10.8초가 필요했다.

비교한 x86 환경에서는 88.4초가 걸렸다.

Sandbox(샌드박스)는 프로그램이 사용할 수 있는 파일과 시스템 자원, 네트워크 접근을 제한한 실행 환경이다.

코딩 에이전트는 자신이 생성한 프로그램을 실제로 시험하기 위해 별도의 샌드박스를 사용할 수 있다.

이런 환경에서는 샌드박스를 얼마나 빠르게 생성할 수 있는지가 전체 작업 처리량에 영향을 줄 수 있다.

하지만 10.8초와 88.4초의 차이를 모든 서버 환경에서 그대로 재현할 수 있다는 의미는 아니다.

실제 결과는 CPU와 메모리, 저장장치와 소프트웨어 구성에 따라 달라진다.

GPU 성능만으로 AI 인프라를 평가하기 어려워진다

이번 발표는 AI 에이전트가 증가하면서 데이터센터의 성능 평가 기준도 달라질 수 있다는 점을 보여준다.

기존에는 AI 모델이 초당 몇 개의 토큰을 생성하는지가 중요한 지표였다.

하지만 실제 코딩 에이전트에서는 모델이 생성한 토큰 수보다 전체 작업을 얼마나 빨리 완료했는지가 더 중요한 경우가 있다.

예를 들어 오류 수정 작업에서 모델의 답변 생성이 10초 빨라졌더라도 테스트 프로그램을 시작하는 데 1분이 걸린다면 전체 작업의 개선 폭은 제한적일 수 있다.

또한 여러 에이전트를 동시에 실행한다면 개별 작업의 속도뿐 아니라 서버 하나에서 관리할 수 있는 에이전트의 수가 중요하다.

NVIDIA는 이런 환경에서 CPU의 메모리와 실행 성능, 전력 효율을 함께 최적화해야 한다고 설명한다.

이번 발표의 성능 수치는 주로 NVIDIA와 협력기업의 자체 평가이므로 독립적인 비교 결과와는 구분해야 한다.

그럼에도 AI 인프라를 평가할 때 GPU 추론 성능뿐 아니라 CPU 기반 도구 실행과 샌드박스, 네트워크와 메모리 자원의 균형을 고려해야 한다는 점을 구체적으로 보여준다.

---

📚 추천 글

Building an agent skill optimizer with AlphaEvolve, Harbor and Gemini 4 Argon

• 저자: Ivan Nardini, Anant Nawalgaria
• 발행: Google Cloud
• 게시일: 2026-11-05
• 원문: Google Cloud — Building an agent skill optimizer with AlphaEvolve, Harbor and Gemini 4 Argon

---

AI 코딩 에이전트에게 지침을 더 많이 제공하면 실제 작업 성공률도 높아질까?

이번 글은 이 질문에 대한 실제 실험 결과를 설명한다.

Google Cloud는 코딩 에이전트가 특정 작업을 수행하도록 돕는 Agent Skill을 자동으로 개선하는 시스템을 만들었다.

Agent Skill은 특정한 작업에 필요한 지침과 도구 사용 방법, 참고 자료를 묶은 구성요소다.

예를 들어 개발자가 코딩 에이전트에 프로젝트의 테스트 방법을 설명하는 Skill을 제공할 수 있다.

문제는 이런 지침이 실제로 도움이 되는지 확인하기 어렵다는 것이다.

모델이 이미 알고 있는 내용을 반복해서 제공한다면 새로운 지침을 추가해도 작업 성공률이 달라지지 않을 수 있다.

반대로 중요한 실패 조건을 명확하게 알려주는 Skill은 실제 작업의 결과를 개선할 수 있다.

기본 Skill을 추가해도 성능이 거의 변하지 않았다

Google은 OpenCode와 Gemini 3.8 Flash를 이용해 Terminal-Bench 2.0 작업을 수행했다.

Terminal-Bench는 AI 에이전트가 터미널에서 실제 명령을 실행하고 파일을 수정해 작업을 완료하는 능력을 평가한다.

연구팀은 두 조건을 비교했다.

첫 번째는 기본 모델만 사용하는 방식이다.

두 번째는 일반적인 코딩 작업 지침을 담은 Skill을 추가하는 방식이다.

그 결과 기본 Skill을 추가해도 작업 성공률은 거의 개선되지 않았다.

기존 모델이 일반적인 코딩 절차를 이미 충분히 알고 있었기 때문이다.

Google은 이를 해결하기 위해 AlphaEvolve를 사용했다.

AlphaEvolve는 후보 프로그램을 수정하고 실제 평가 결과를 바탕으로 더 좋은 버전을 찾도록 설계된 시스템이다.

이번 연구에서는 프로그램 코드 대신 Skill의 자연어 지침 자체를 최적화 대상으로 사용했다.

AI가 Skill을 수정하고 실제 에이전트가 평가

연구팀은 다음과 같은 반복 구조를 만들었다.

먼저 AlphaEvolve가 기존 Skill의 설명과 지침을 수정한다.

이후 Harbor라는 평가 도구가 수정된 Skill을 실제 코딩 에이전트에 제공한다.

에이전트는 Terminal-Bench의 작업을 수행한다.

작업이 성공했는지와 얼마나 오래 걸렸는지 평가한다.

그 결과를 AlphaEvolve에 다시 전달한다.

AlphaEvolve는 실패한 작업의 특징을 참고해 다음 Skill을 생성한다.

이런 방식은 AI가 직접 작성한 지침을 실제 실행 결과로 검증하며 개선하는 구조다.

연구팀은 몇 차례의 반복을 통해 약 5%의 성능 개선을 확인했다고 밝혔다.

하지만 이 수치는 Google이 수행한 특정한 실험의 결과다.

모든 종류의 Agent Skill을 AlphaEvolve로 수정하면 같은 비율로 개선된다는 의미는 아니다.

가장 많은 실패 원인은 시간 초과

이번 글에서 특히 흥미로운 부분은 실제로 어떤 지침이 효과적이었는지다.

연구팀에 따르면 평가 작업의 약 3분의 1이 시간 제한에 걸려 실패했다.

기존 Skill에는 작업을 신중하게 분석하고 단계적으로 해결하라는 일반적인 지침이 포함돼 있었다.

하지만 실제로는 분석을 오래 수행하다가 제한시간 안에 결과물을 완성하지 못하는 문제가 많았다.

AlphaEvolve는 이런 실패 패턴을 발견한 뒤 Skill을 변경했다.

예를 들어 가능한 한 빠르게 작동하는 최소한의 결과물을 먼저 만들도록 지시했다.

이후 시간이 남으면 개선하도록 했다.

또한 테스트가 정상적으로 통과하고 필요한 파일이 생성됐다면 불필요하게 작업을 계속하지 말고 종료하도록 했다.

이런 지침은 일반적인 코딩 지식과 다르다.

실제 평가 환경에서 반복적으로 발생하는 실패를 줄이기 위한 구체적인 실행 전략이다.

평가 결과도 불안정할 수 있다

연구팀은 Skill의 성능을 비교하는 과정에서 중요한 문제도 발견했다.

같은 모델과 같은 작업을 사용하더라도 실행 시점에 따라 모델의 응답 속도가 달라질 수 있었다.

예를 들어 모델 서비스가 일시적으로 느려진 상황에서는 어떤 Skill을 사용해도 시간 초과가 발생할 수 있다.

이런 상황에서 해당 Skill의 성능이 낮다고 판단하면 잘못된 결론에 도달할 수 있다.

Google은 이를 해결하기 위해 기존 Skill과 새로운 Skill을 같은 시간에 동일한 작업으로 실행해 비교했다.

또한 Skill을 최적화하는 데 사용하지 않은 별도의 작업으로 최종 성능을 검증하도록 권장했다.

이렇게 하면 특정한 평가 문제에만 지나치게 맞춰지는 현상을 줄일 수 있다.

이를 Overfitting(과적합)이라고 한다.

학습이나 최적화에 사용한 문제에서는 성능이 높지만 처음 보는 문제에서는 성능이 낮아지는 현상이다.

이번 글은 AI 에이전트의 성능을 개선할 때 더 긴 지침을 작성하기보다 실제 실패 데이터를 바탕으로 필요한 실행 규칙을 찾아내는 방법이 중요할 수 있다는 점을 보여준다.

---

CWE-bench v2: More coverage, quality, and transparency

• 저자: Gonzalo Gonzalez, Ajay Jagannath, Nazneen Rajani, Nathan Habib
• 발행: Collinear AI / Hugging Face
• 게시일: 2026-11-03
• 원문: Hugging Face — CWE-bench v2: More coverage, quality, and transparency

---

AI 코딩 에이전트가 소프트웨어의 보안 문제를 얼마나 잘 수정하는지 어떻게 평가할 수 있을까?

일반적인 코딩 벤치마크에서는 프로그램이 정해진 테스트를 통과하는지 확인할 수 있다.

하지만 보안 취약점의 수정은 더 복잡하다.

예를 들어 특정한 입력값을 이용해 서버의 보안 검사를 우회할 수 있다고 가정해 보자.

개발자는 해당 우회 방법을 차단해야 한다.

동시에 정상적인 사용자 요청까지 차단하지 않도록 해야 한다.

단순히 공격에 사용된 특정 문자열만 금지한다면 비슷한 다른 공격을 막지 못할 수 있다.

또한 보안 문제를 수정하는 과정에서 기존 기능이 중단될 수도 있다.

Collinear AI의 CWE-bench v2는 이런 문제를 실제 코드 저장소의 작업으로 평가한다.

100개 작업과 91종 취약점 유형

CWE-bench v2에는 100개의 공개 평가 작업이 포함됐다.

이 작업들은 91개 CWE 유형을 다룬다.

CWE(Common Weakness Enumeration)는 소프트웨어의 보안 약점 유형을 체계적으로 분류하는 목록이다.

예를 들어 입력값 검증 실패나 접근권한 관리 오류, 메모리 관련 문제가 포함될 수 있다.

각 작업에서는 AI 에이전트에게 실제 오픈소스 저장소와 짧은 문제 설명을 제공한다.

에이전트는 코드를 분석하고 보안 취약점을 수정해야 한다.

이후 별도의 검증 프로그램이 실제로 문제가 해결됐는지 검사한다.

중요한 점은 특정한 수정 코드와 정확히 같은 형태로 작성해야 성공하는 구조가 아니라는 사실이다.

실제 보안 문제가 해결되고 정상적인 기능이 유지된다면 다른 방식의 수정도 허용하도록 설계됐다.

검증 프로그램의 정확성까지 확인

연구팀은 평가 작업마다 여러 조건을 검사했다.

먼저 수정하기 전의 코드에서는 실제 문제가 발생해야 한다.

이후 올바른 수정 코드를 적용하면 해당 문제가 해결돼야 한다.

또한 기존 프로그램의 정상적인 기능도 유지돼야 한다.

평가 프로그램이 특정한 수정 방법만 정답으로 인정하는지 여부도 검토했다.

예를 들어 공격에 사용된 문자열 하나만 금지하면 테스트가 통과하는 상황은 좋은 평가가 아닐 수 있다.

공격자는 다른 문자열을 이용해 같은 문제를 다시 발생시킬 수 있기 때문이다.

따라서 연구팀은 수정 코드의 형태보다 실제 보안 속성의 변화를 확인하려 했다.

이러한 검사를 프로그램으로 자동화했기 때문에 외부 연구자가 같은 조건에서 결과를 재현할 수 있다.

다만 공개된 평가 작업을 모델의 학습에 사용한다면 향후 평가의 독립성이 약해질 수 있다.

이를 보완하기 위해 Collinear AI는 별도의 비공개 평가 작업도 유지한다.

최상위 모델도 일부 문제는 해결하지 못했다

Collinear AI는 11개 모델의 평가 결과를 공개했다.

대표적인 결과는 다음과 같다.

Pass@1은 한 번의 시도에서 작업을 성공할 가능성을 나타내는 지표다.

Pass@4는 최대 네 번의 시도를 허용했을 때 작업을 한 번 이상 성공시킬 가능성을 나타낸다.

Gemini 4 Argon은 첫 번째 시도에서 67.8%를 기록했다.

네 번의 시도를 허용하면 81.0%로 높아졌다.

하지만 네 번의 시도를 허용하면 모델 호출과 프로그램 실행 비용도 증가할 수 있다.

따라서 실제 운영에서는 한 번의 작업 성공률과 여러 번 재시도했을 때의 비용을 함께 고려해야 한다.

비용 대비 성능에도 차이

Collinear AI는 각 모델의 작업당 비용도 비교했다.

DeepSeek V4.1 Flash는 평가에서 한 번 실행할 때 평균 약 0.04달러가 필요했다.

Claude Opus 5.5는 약 1.83달러, Gemini 4 Argon은 약 3.92달러였다.

다만 실제 비용은 입력과 출력 토큰, 추론 설정과 모델 제공업체의 가격에 따라 달라질 수 있다.

또한 저렴한 모델이 특정한 작업에서 충분한 성능을 제공할 수 있더라도 모든 보안 문제에 적합하다는 의미는 아니다.

보안 취약점 가운데는 실제로 악용되면 심각한 피해가 발생하는 문제가 존재한다.

이런 상황에서는 단순한 실행 비용보다 검증 가능한 수정 결과와 전문적인 코드 리뷰가 중요할 수 있다.

이번 글은 AI의 보안 코딩 능력을 평가할 때 얼마나 많은 문제를 수정했는지뿐 아니라 실제 보안 문제가 해결됐는지와 기존 기능이 유지됐는지 확인해야 한다는 점을 구체적으로 보여준다.

---

Investigating vault particles with Claude

• 저자: Anthropic Science 연구팀
• 발행: Anthropic Research
• 게시일: 2026-11-04
• 원문: Anthropic — Investigating vault particles with Claude

---

AI가 실제 과학 연구를 얼마나 깊이 지원할 수 있을까?

이번 글은 Anthropic의 생물학 연구팀이 Claude를 이용해 세균을 감염시키는 바이러스에서 새로운 형태의 단백질 복합체를 발견하고 구조를 분석한 과정을 설명한다.

특히 단순히 논문을 요약하거나 실험 코드를 작성하는 수준을 넘어 연구자료 검색과 실험 설계, 단백질 분리 방법 개선과 현미경 데이터 분석까지 여러 단계에 AI를 사용했다는 점이 특징이다.

Vault 단백질 복합체란 무엇인가

Vault는 세포 안에서 발견되는 큰 단백질 복합체다.

여러 개의 단백질이 모여 속이 빈 통과 비슷한 구조를 만든다.

사람을 포함한 여러 진핵생물의 세포에서 발견된다.

진핵생물(Eukaryote)은 세포 안에 핵과 여러 세포 소기관을 가진 생물이다.

반면 일반적인 세균은 핵이 없는 원핵생물에 해당한다.

Vault는 1986년에 발견됐지만 실제 생물학적 기능은 아직 명확하게 밝혀지지 않았다.

일부 연구에서는 세포 안의 물질 운반과 면역 반응, 유해 물질에 대한 방어 등 여러 가능성이 제기됐다.

하지만 어느 가설도 모든 상황에서 확정적으로 검증된 것은 아니다.

Anthropic 연구팀은 Vault와 관련된 단백질이 세균과 박테리오파지에도 존재한다는 사실에 주목했다.

박테리오파지(Bacteriophage)는 세균을 감염시키는 바이러스다.

이런 단백질이 실제로 Vault와 비슷한 구조를 형성하는지 확인하려 했다.

Claude를 이용해 후보 단백질 검색

연구팀은 대규모 단백질 데이터베이스를 조사했다.

Claude는 관련 단백질 서열과 기존 연구자료를 검색하는 작업을 지원했다.

단백질 서열(Protein Sequence)은 단백질을 구성하는 아미노산의 배열을 의미한다.

서열이 비슷한 단백질은 구조나 기능이 관련돼 있을 가능성이 있다.

하지만 서열이 비슷하다는 사실만으로 실제로 같은 3차원 구조를 형성한다고 단정할 수는 없다.

따라서 후보를 찾은 뒤 실제 실험으로 검증해야 한다.

연구팀은 여러 후보를 선택해 단백질을 생성하고 정제한 뒤 실제 입자 구조를 조사했다.

이번 연구에서 확인한 대표적인 Vault는 96개의 단백질 사본으로 구성됐다.

사람의 Vault가 78개 사본으로 구성되는 것과 차이가 있다.

단백질 분리 작업을 3일에서 약 90분으로 단축

실제 생물학 실험에서는 단백질을 충분히 순수한 상태로 분리하는 작업이 필요하다.

이를 Protein Purification(단백질 정제)이라고 한다.

예를 들어 세균이 생산한 단백질을 조사하려면 다른 세포 성분과 분리해야 할 수 있다.

이후 실제로 원하는 형태의 단백질 복합체가 만들어졌는지 확인한다.

Anthropic 연구팀은 Claude를 활용해 실험 절차를 개선했다.

회사에 따르면 일반적으로 약 3일이 필요할 수 있는 Vault 정제 과정을 약 90분으로 단축했다.

또한 첫 번째 구조 모델은 약 34시간 후 준비됐다.

연구팀은 기존 방식으로는 수주가 걸렸을 수 있는 작업이라고 추정했다.

하지만 이는 특정한 연구팀의 실제 작업 사례다.

모든 단백질 정제 작업이 같은 비율로 빨라질 수 있다는 의미는 아니다.

또한 Claude가 실제 실험 장비를 완전히 자율적으로 조작한 것은 아니다.

실험 설계와 검토에는 인간 연구자가 참여했다.

실제 구조는 Cryo-EM으로 검증

연구팀은 Cryo-EM(Cryogenic Electron Microscopy, 극저온 전자현미경)을 이용해 단백질 복합체의 구조를 분석했다.

Cryo-EM은 시료를 매우 낮은 온도에서 관찰하고 여러 이미지를 결합해 분자의 3차원 구조를 분석하는 기술이다.

이렇게 하면 모델의 구조 예측뿐 아니라 실제 관측 자료를 기반으로 단백질 복합체의 형태를 확인할 수 있다.

연구팀은 Vault와 비슷한 구조를 확인했고 단백질의 일부를 변경해 더 큰 구조를 만드는 방법도 시험했다.

이는 향후 특정한 물질을 담거나 전달하는 나노 크기의 구조물을 설계하는 연구와 연결될 가능성이 있다.

하지만 Vault의 실제 생물학적 기능은 이번 연구에서도 밝혀지지 않았다.

따라서 새로운 단백질 복합체의 구조를 발견했다는 사실과 해당 복합체의 생물학적 역할을 이해했다는 사실은 구분해야 한다.

이번 글은 AI가 실제 과학 연구에 참여할 때 모델의 추론과 문헌 검색, 전문적인 실험 장비와 인간 연구자의 판단이 어떻게 연결되는지 구체적으로 보여준다.

---

Semantic aggregation over millions of rows in BigQuery with AI.AGG

• 저자: Pramod Niralakeri, Shruti Malgatti
• 발행: Google Cloud
• 게시일: 2026-11-05
• 원문: Google Cloud — Semantic aggregation over millions of rows in BigQuery with AI.AGG

---

기업에 고객지원 문의가 수백만 건 저장돼 있다고 가정해 보자.

사용자는 지난달 고객들이 가장 많이 불편을 느낀 문제가 무엇인지 알고 싶을 수 있다.

일반적인 SQL에서는 특정한 단어가 포함된 행의 수를 계산할 수 있다.

하지만 실제 고객의 불만은 다양한 표현으로 나타날 수 있다.

예를 들어 결제가 느리다는 표현과 카드 결제가 완료되지 않는다는 표현은 서로 다른 문장이다.

하지만 실제로는 결제 시스템의 성능 문제와 관련될 수 있다.

이런 자료를 분석하려면 단순한 문자열 비교보다 문장의 의미를 이해하고 공통적인 주제로 묶는 능력이 필요하다.

Google Cloud의 AI.AGG는 이런 작업을 BigQuery에서 수행하도록 만든 기능이다.

이번 글은 기존에 프리뷰로 제공되던 AI.AGG의 내부 처리 구조와 실제 활용 방법을 설명한다.

따라서 새로운 기능이 11월 5일 처음 출시됐다는 의미는 아니다.

일반적인 집계와 의미 기반 집계의 차이

SQL에서는 SUM, COUNT, AVG 같은 집계 함수를 사용할 수 있다.

예를 들어 특정한 기간의 총매출을 계산할 수 있다.

또는 고객지원 문의의 수를 계산할 수 있다.

하지만 고객이 남긴 자유로운 문장을 분석해 주요 불만 유형을 정리하는 작업은 일반적인 숫자 집계와 다르다.

Semantic Aggregation(의미 기반 집계)은 여러 문서나 문장의 의미를 분석해 공통적인 주제와 패턴을 찾아내는 방법이다.

AI.AGG는 이를 언어모델과 데이터베이스의 집계 기능을 결합해 구현한다.

예를 들어 사용자는 SQL 안에서 고객지원 대화의 주요 불만을 요약하도록 자연어 지시를 작성할 수 있다.

BigQuery는 해당 데이터를 여러 그룹으로 나눈 뒤 AI 모델에 전달한다.

이후 각 그룹의 결과를 다시 결합해 전체적인 요약을 생성한다.

수백만 행을 한 번에 모델에 전달할 수는 없다

대형 언어모델에는 한 번에 처리할 수 있는 입력의 길이에 제한이 있다.

이를 Context Window(컨텍스트 창)이라고 한다.

예를 들어 고객지원 대화가 수백만 건 존재한다고 해서 해당 내용을 전부 하나의 요청으로 전달할 수는 없다.

AI.AGG는 이를 해결하기 위해 여러 단계의 처리 방식을 사용한다.

먼저 입력 데이터를 확인한다.

이후 모델이 처리할 수 있는 크기로 행들을 묶는다.

각 묶음을 여러 AI 모델 호출로 병렬 처리한다.

다음으로 각 묶음에서 생성된 요약을 다시 묶는다.

이 과정을 반복해 최종 결과를 생성한다.

이런 방식을 Map-Reduce(분할 처리와 결과 집계)라고 할 수 있다.

Map 단계에서는 대량의 데이터를 작은 단위로 나누어 처리한다.

Reduce 단계에서는 여러 중간 결과를 결합한다.

AI.AGG는 이런 구조를 BigQuery 내부의 관리형 기능으로 제공한다.

단순한 요약을 넘어 이미지 분석까지

AI.AGG는 텍스트뿐 아니라 이미지와 관련된 데이터도 처리할 수 있다.

예를 들어 여러 상품 이미지에서 반복적으로 나타나는 특징을 분석할 수 있다.

또는 제품 검사 사진을 분석해 어떤 종류의 문제가 자주 발생하는지 요약할 수 있다.

Google은 BigQuery Object Tables를 이용해 Cloud Storage에 저장된 이미지와 관련 정보를 조회하는 방법을 소개했다.

하지만 멀티모달 모델이 여러 이미지를 분석할 수 있다는 사실만으로 실제 물체의 상태를 항상 정확하게 판단한다는 의미는 아니다.

이미지의 화질과 촬영 환경, 모델의 시각적 이해 능력에 따라 오류가 발생할 수 있다.

또한 여러 단계로 요약하는 과정에서는 일부 세부 정보가 누락될 수 있다.

따라서 중요한 통계 수치와 실제 사건의 개수는 일반적인 데이터베이스 집계로 검증할 필요가 있다.

여러 단계의 요약에서는 오류가 누적될 수 있다

이번 글에서 특히 주목할 부분은 중간 요약 결과를 다시 요약하는 구조의 한계다.

예를 들어 첫 번째 단계에서 특정한 드문 불만 유형이 중요하지 않다고 판단돼 누락될 수 있다.

이후 최종 단계에서는 이미 사라진 정보를 다시 복원하기 어렵다.

반대로 특정한 유형의 불만이 여러 중간 요약에 반복해서 포함되면 실제보다 중요하게 표현될 가능성도 있다.

따라서 AI.AGG는 숫자의 정확한 합계보다 대량의 비정형 데이터에서 공통적인 의미와 경향을 찾아내는 작업에 더 적합할 수 있다.

비정형 데이터(Unstructured Data)는 일반적인 관계형 테이블처럼 미리 정해진 열과 자료형으로 표현하기 어려운 데이터다.

고객지원 대화와 이메일, 사진과 문서 등이 대표적이다.

이번 글은 기업이 방대한 비정형 데이터를 AI로 분석할 때 언어모델의 컨텍스트 제한과 병렬 처리, 중간 결과의 결합을 어떻게 설계해야 하는지 구체적으로 설명한다.

---

A Closer Look at Phonon TTS: High-Quality On-Device Speech

• 저자: Olesia Krizhevich, Laurent Mazare, Eric Bezzam, Eustache Le Bihan
• 발행: Gradium / Hugging Face
• 게시일: 2026-11-05
• 원문: Hugging Face — A Closer Look at Phonon TTS

---

AI가 자연스러운 목소리를 생성하려면 반드시 인터넷에 연결된 대형 서버가 필요할까?

이번 글은 작은 음성 합성 모델인 Phonon TTS의 기술 구조와 실제 기기 실행 결과를 설명한다.

TTS(Text-to-Speech)는 텍스트를 사람이 들을 수 있는 음성으로 변환하는 기술이다.

예를 들어 스마트워치가 사용자에게 운동 방법을 안내하거나 앱이 문서를 읽어주는 기능에 사용할 수 있다.

일반적인 클라우드 기반 TTS에서는 텍스트를 외부 서버로 전송한다.

서버는 음성을 생성한 뒤 실제 소리 데이터를 사용자 기기로 전달한다.

하지만 이런 구조에서는 인터넷 연결이 필요하다.

또한 텍스트를 외부 서비스에 전송해야 하므로 개인정보와 네트워크 지연시간을 고려해야 한다.

Phonon은 이 문제를 해결하기 위해 기기 내부에서 직접 실행할 수 있는 작은 음성 합성 모델로 설계됐다.

모델 자체는 약 2주 전에 이미 공개됐으며, 이번 글에서는 출시 이후의 평가와 실제 활용 사례를 자세하게 설명한다.

65~75MB 크기의 소형 음성 모델

Phonon은 두 가지 주요 크기로 제공된다.

Phonon 31m은 Apache 2.0 라이선스로 제공되므로 일반적인 상업적 활용이 허용된다.

반면 Phonon 40m은 비상업적 사용을 위한 라이선스로 제공된다.

따라서 두 모델 모두 가중치가 공개됐다는 이유만으로 상업적 사용 조건이 같다고 판단해서는 안 된다.

Phonon은 100개 이상의 기본 음성을 제공한다.

또한 사용자가 별도의 음성을 생성하거나 음색을 조정하는 기능도 지원한다.

다만 특정한 음성을 복제할 때는 해당 음성의 사용권한과 관련 당사자의 동의를 고려해야 한다.

Flow Matching을 이용한 음성 생성

Phonon은 Flow Matching 계열의 생성 기술을 사용한다.

Flow Matching은 단순한 분포에서 실제 데이터의 분포로 변화하는 경로를 모델이 학습하도록 하는 생성 방법이다.

음성 합성에서는 모델이 텍스트를 바탕으로 실제 소리의 특성을 가진 출력을 만들어야 한다.

일반적인 언어모델처럼 텍스트 토큰을 하나씩 생성하는 방식과는 다른 계산 구조가 필요할 수 있다.

Gradium은 이러한 구조를 작은 모델에 적용해 실제 기기에서도 자연스러운 음성을 생성하도록 설계했다.

하지만 모델을 작게 만들면 계산 자원은 줄일 수 있어도 음성의 자연스러움과 발음 정확도가 떨어질 가능성이 있다.

연구팀은 이런 문제를 줄이기 위해 여러 언어와 화자 데이터를 이용해 학습했다.

글에 따르면 처음에는 학습 과정에서 수치적으로 불안정한 문제가 발생했다.

연구팀은 이를 해결하기 위해 학습 방법을 조정했다고 설명했다.

스마트워치와 브라우저에서 오프라인 실행

Gradium은 여러 실제 사용 사례를 공개했다.

예를 들어 Wi-Fi를 끈 Apple Watch에서 커피를 만드는 순서를 음성으로 안내하는 기능을 구현했다.

인터넷 연결이 없는 iPhone에서 운동 횟수를 세며 안내하는 사례도 소개했다.

또한 웹브라우저 안에서 음성을 생성하는 게임과 로봇 캐릭터의 대화 기능도 구현했다.

이런 사례는 모델의 실행에 반드시 원격 서버가 필요한 것은 아니라는 점을 보여준다.

하지만 모든 기기에서 같은 음성 생성 속도와 품질을 제공한다는 의미는 아니다.

기기의 CPU와 GPU, 메모리와 실행 환경에 따라 성능이 달라질 수 있다.

Hugging Face 음성 합성 평가 결과

Gradium은 Hugging Face의 Open TTS Leaderboard 결과도 소개했다.

이 평가에서는 음성의 발음 정확도와 자연스러움, 실제 생성 속도 등을 비교한다.

WER(Word Error Rate, 단어 오류율)은 생성된 음성이 원래 텍스트를 얼마나 정확하게 표현하는지 확인하는 데 사용할 수 있다.

생성된 음성을 다시 음성 인식 모델로 변환한 뒤 원래 문장과 비교하는 방식이다.

Gradium에 따르면 Phonon은 독일어와 스페인어의 발음 정확도 평가에서 1위를 기록했다.

또한 평가한 언어들에서 상위권의 정확도를 기록했다.

CPU 기반 스트리밍 평가에서는 첫 음성이 출력되기까지 걸리는 시간이 매우 짧은 수준이었다고 설명한다.

다만 이러한 결과가 모든 언어와 기기에서 최고 성능을 보장한다는 의미는 아니다.

실제 한국어는 이번 공개 모델의 주요 지원 언어에 포함돼 있지 않다.

실행 엔진도 별도로 최적화

Gradium은 Phonon을 위해 ptts라는 실행 엔진을 개발했다.

이 엔진은 여러 하드웨어에서 모델을 효율적으로 실행하도록 지원한다.

지원 대상에는 Intel과 Arm CPU, CUDA와 Metal GPU, WebAssembly와 WebGPU 등이 포함된다.

또한 Apple Core ML과 Snapdragon 계열의 실행 환경도 지원한다.

이와 별도로 Hugging Face Transformers에서도 Phonon을 사용할 수 있다.

두 방식은 목적이 다르다.

ptts는 기기 내부에서 하나의 음성 스트림을 빠르게 생성하는 데 초점을 맞춘다.

반면 Transformers는 GPU에서 여러 요청을 함께 처리하는 작업에도 활용할 수 있다.

이번 글은 실제 AI 제품을 설계할 때 모델의 크기와 실행 장치, 첫 응답까지 걸리는 시간과 음성 품질을 함께 최적화해야 한다는 점을 구체적으로 보여준다.

특히 로컬 음성 비서와 접근성 도구, 오프라인 애플리케이션을 개발하려는 개발자에게 참고할 만한 자료다.