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

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

---

1️⃣ 주요 모델·연구

Tencent, 차세대 멀티모달 모델 ‘Hy4’ 출시…화면 조작·코딩·금융 분석 강화하고 모델 가중치 공개 예고

• 발표일: 2026-11-04 — 보도자료 게시 시각 19:13(중국 현지 시각 기준으로 추정, 시간대 명시 미확인)
• 적용 범위: 대형 언어모델, 멀티모달 AI, 컴퓨터 사용 에이전트, 코딩 도구, 금융 분석, 오픈웨이트 모델, AI 안전
• 원문: Tencent — Tencent Launches Hy4

---

중국의 Tencent가 새로운 대형 언어모델 Tencent Hy4를 발표했다.

이번 모델은 기존 Hy4 Preview의 후속 버전으로, 이미지 이해와 복잡한 추론, 장시간 이어지는 에이전트 작업을 강화했다.

특히 이전 모델과 달리 이미지를 이해하고 실제 컴퓨터의 명령줄과 그래픽 인터페이스를 조작하는 기능을 새롭게 제공한다는 점이 특징이다.

Tencent는 Hy4를 오픈소스 모델 계열로 소개했지만, 발표일 현재 모델 가중치와 시스템 카드는 아직 공개되지 않았다.

회사는 앞으로 며칠 안에 관련 자료를 공개할 계획이라고 밝혔다.

따라서 11월 4일에 모델 사용이 시작됐다는 사실과 누구나 가중치를 다운로드해 자체 서버에서 실행할 수 있다는 사실은 구분해야 한다.

이미지를 이해하는 능력에서 실제 프로그램 조작으로

Hy4는 텍스트뿐 아니라 이미지도 입력받아 분석하는 멀티모달 모델이다.

멀티모달 AI(Multimodal AI)는 텍스트와 이미지, 음성처럼 서로 다른 형태의 정보를 함께 처리하는 기술을 의미한다.

예를 들어 사용자가 복잡한 금융 차트나 수학 문제가 포함된 이미지를 전달하면 모델이 시각적 요소를 분석해 관련 질문에 답하도록 설계됐다.

하지만 이번 업데이트에서 더 중요한 변화는 Computer Use(컴퓨터 사용) 능력이다.

컴퓨터 사용은 AI가 화면을 관찰하고 실제 프로그램을 조작해 작업을 수행하는 기능이다.

예를 들어 사용자가 3D 모델링 프로그램에서 특정한 형태의 물체를 만들도록 요청했다고 가정해 보자.

AI는 먼저 사용자의 요청을 이해해야 한다.

이후 프로그램의 메뉴와 도구를 확인하고 필요한 조작을 수행해야 한다.

중간에 예상하지 못한 결과가 나타나면 현재 화면을 다시 분석하고 다음 행동을 결정해야 한다.

Hy4는 이런 작업을 위해 CLI와 GUI를 모두 사용할 수 있도록 설계됐다.

CLI(Command-Line Interface)는 명령어를 입력해 프로그램을 조작하는 방식이다.

GUI(Graphical User Interface)는 버튼과 메뉴, 창 같은 시각적 요소를 이용해 프로그램을 조작하는 방식이다.

Tencent는 특히 Blender와 CAD 같은 전문 소프트웨어를 이용한 작업을 추가로 학습시켰다고 설명한다.

CAD(Computer-Aided Design)는 컴퓨터로 기계와 건축물 등의 설계 도면이나 3D 모델을 작성하는 기술이다.

다만 전문 소프트웨어를 조작할 수 있다는 사실만으로 실제 제조에 필요한 모든 공학적 제약을 정확하게 이해한다는 의미는 아니다.

실제 설계에서는 부품의 공차와 재질, 안전성 등을 별도로 검증해야 한다.

코딩 에이전트와 게임 개발에도 적용

Tencent는 Hy4의 코딩 능력도 개선했다고 밝혔다.

특히 프런트엔드와 백엔드 사이의 데이터 흐름, 복잡한 상태 관리와 여러 단계의 기능 구현을 주요 개선 대상으로 제시했다.

예를 들어 웹 애플리케이션에서 단순히 화면을 생성하는 것과 실제로 동작하는 기능을 구현하는 것은 다르다.

사용자가 장바구니에 상품을 추가하면 화면의 상태가 변경돼야 한다.

이후 서버에 저장된 장바구니 정보와 동기화돼야 할 수도 있다.

오류가 발생했을 때는 사용자에게 적절한 메시지를 보여줘야 한다.

Hy4는 이런 여러 요소를 함께 처리하도록 개선됐다는 것이 Tencent의 설명이다.

게임 개발에서는 Unreal Engine과 Unity, Godot 등의 엔진을 활용한 작업도 평가했다.

Tencent가 공개한 내부 벤치마크에서는 기존 Hy4 Preview보다 GameDev 평가가 19.1%, GameLogic 평가가 9.8% 개선됐다.

다만 이 수치가 실제 게임의 개발기간을 19.1% 줄였다는 의미는 아니다.

특정한 게임 개발 평가에서 측정된 성능 향상이다.

금융 전문가 213명이 참여한 비교 평가

Tencent는 금융 분야의 전문적인 업무를 수행하는 능력도 강화했다고 밝혔다.

모델은 기업 분석과 투자 연구, 정량적 금융 분석 등 여러 업무에 관한 추가 학습을 수행했다.

회사는 금융 전문가 213명이 참여한 평가를 진행했다.

이 가운데 153명은 외부 기관에서 참여한 전문가였다.

평가에는 실제 금융 업무에서 파생된 579개 작업이 사용됐다.

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

Hy4가 비교 대상 가운데 가장 높은 점수를 기록했다.

하지만 이 실험은 Tencent Hy와 Tencent Financial Technology가 설계하고 운영한 평가다.

외부 전문가가 참여했다는 사실과 독립적인 제3자가 평가 전체를 설계하고 검증했다는 사실은 다르다.

또한 어떤 금융 업무를 얼마나 정확하게 처리했는지는 실제 투자 분석 환경에 따라 달라질 수 있다.

따라서 이 점수를 투자 수익률이나 실제 금융 의사결정의 정확도로 해석해서는 안 된다.

환각과 근거 없는 가정 감소

Tencent는 모델이 사실과 다른 정보를 생성하는 문제도 개선했다고 밝혔다.

Hallucination(환각)은 AI가 실제 근거가 없거나 사실과 다른 정보를 그럴듯하게 생성하는 현상이다.

회사 내부 평가에서는 다음과 같은 변화가 나타났다.

Tencent는 최신 정보를 검색하고 여러 자료 사이의 일관성을 확인하는 과정을 강화한 결과라고 설명했다.

다만 위 수치는 회사가 정의한 특정 평가 조건에서 얻어진 결과다.

일반적인 모든 질문에서 오류 발생률이 7.2%라는 의미는 아니다.

특히 금융과 의료처럼 작은 사실 오류가 실제 의사결정에 영향을 줄 수 있는 분야에서는 모델이 제시한 근거를 별도로 확인해야 한다.

사이버보안 학습 데이터와 안전성 평가

Tencent는 이번 모델의 안전성에도 상당한 비중을 두었다.

특히 사이버보안 분야의 학습 데이터에서 방어적인 작업에 필요한 자료를 우선적으로 사용했다고 설명했다.

예를 들어 소프트웨어의 취약점을 분석하고 수정하는 업무를 지원하도록 설계했다.

반면 실제 악성 공격을 수행하는 데 사용될 수 있는 자료는 학습 데이터에서 제외했다고 밝혔다.

Tencent의 보안 연구조직인 Xuanwu Lab과 Keen Security Lab은 모델의 사이버보안 능력을 평가했다.

회사에 따르면 평가한 영역에서는 공격적인 사이버 능력과 관련된 중대한 우려를 발견하지 못했다.

하지만 이는 Tencent가 공개한 내부 평가 결과다.

모델의 가중치와 상세한 안전성 평가 보고서는 발표일에 아직 공개되지 않았으므로 외부에서 전체 결과를 재현하기는 어렵다.

제공 범위와 API 가격

Hy4는 Tencent의 여러 제품에서 이용할 수 있다.

주요 제공 대상에는 WorkBuddy와 CodeBuddy, WeCom의 AI Assistant, Tencent Cloud TokenHub 등이 포함된다.

Tencent는 일부 외부 모델 플랫폼과의 연동도 진행하고 있다고 밝혔다.

API 가격은 다음과 같다.

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

Prompt Caching(프롬프트 캐싱)은 반복되는 입력의 처리 결과를 재사용해 계산량과 비용을 줄이는 기술이다.

캐시 가격은 실제로 캐시를 사용할 수 있는 입력에 적용되므로 모든 요청에 동일하게 적용되는 것은 아니다.

Tencent는 더 저렴한 Hy4 Flash도 향후 출시할 계획이라고 밝혔다.

이번 발표는 중국의 AI 모델 경쟁이 단순한 언어 이해와 추론 성능을 넘어 실제 업무 프로그램을 조작하고 여러 단계의 작업을 완료하는 에이전트 능력으로 확대되고 있음을 보여준다.

---

Google Research, 사람마다 다른 주관적 판단 기준을 AI와 함께 정리하는 ‘Agile Deliberation’ 연구 공개

• 발표일: 2026-11-04 — 정확한 게시 시각 미확인
• 적용 범위: AI 연구, 이미지 분류, 인간·AI 협업, 콘텐츠 검토, 사용자 의도 정렬, 오픈소스 연구
• 원문: Google Research — Agile Deliberation: How AI helps humans define the gray areas
• 관련 원문: Google Research — 연구 코드

---

Google Research가 사람이 명확하게 정의하기 어려운 기준을 AI와 대화하면서 구체화하는 Agile Deliberation 연구를 소개하고 관련 코드와 알고리즘의 공개를 안내했다.

관련 논문은 2026년 CVPR 연구로 이미 발표됐다.

따라서 이번 소식은 완전히 새로운 연구 결과가 11월 4일 처음 발견됐다는 의미가 아니다.

11월 4일의 새로운 공개는 연구의 실제 동작 방식과 인간 대상 평가 결과를 자세히 설명하고 외부 연구자가 활용할 수 있는 구현 자료를 제공한다는 점에 있다.

이번 연구가 다루는 문제는 일반적인 이미지 분류와 조금 다르다.

예를 들어 AI에게 사진 속 물체가 자동차인지 자전거인지 구분하도록 요청할 수 있다.

이런 작업에서는 비교적 명확한 분류 기준을 설정할 수 있다.

하지만 다음과 같은 요청은 어떨까?

어떤 음식이 건강한 음식인지 구분해 달라고 요청할 수 있다.

또는 어떤 그림이 영감을 주는 작품인지 판단하도록 할 수도 있다.

문제는 이러한 개념이 사람마다 다르게 정의될 수 있다는 점이다.

사람도 처음부터 자신의 기준을 정확하게 알고 있지 않다

예를 들어 사용자가 건강한 음식을 판별하는 AI를 만들려고 한다고 가정해 보자.

처음에는 샐러드와 과일, 잡곡 식사를 건강한 음식이라고 설명할 수 있다.

하지만 실제 사진을 확인하다 보면 애매한 사례가 나타난다.

과일이 많이 들어간 스무디는 건강한 음식일까?

설탕이 많이 첨가된 스무디도 같은 범주에 포함해야 할까?

가공식품이지만 영양성분이 좋은 제품은 어떻게 처리해야 할까?

사용자는 이런 사례를 접하면서 자신이 처음 생각했던 기준을 수정할 수 있다.

Google은 이런 문제를 주관적인 분류 기준의 변화로 설명한다.

기존의 머신러닝에서는 사람이 먼저 명확한 기준을 정의한 뒤 데이터를 분류하도록 요구하는 경우가 많았다.

하지만 실제로는 분류할 사례를 검토하는 과정에서 사람의 기준 자체가 구체화될 수 있다.

Agile Deliberation은 이 과정을 AI 시스템에 포함하려 한다.

분류 기준을 두 단계로 정리

Agile Deliberation은 크게 두 단계로 작동한다.

첫 번째는 Concept Scoping(개념의 범위 설정)이다.

사용자가 원하는 분류 기준을 여러 하위 범주로 나누도록 돕는다.

예를 들어 건강한 음식이라는 개념을 샐러드와 잡곡 식사, 지방이 적은 단백질 식품 등으로 구분할 수 있다.

반대로 제외해야 하는 사례도 명시한다.

예를 들어 가공 수준이 높은 음식이나 특정 조건을 만족하지 않는 식품을 제외할 수 있다.

두 번째는 Concept Iteration(개념의 반복적 수정)이다.

시스템이 애매한 경계에 있는 이미지를 찾아 사용자에게 보여준다.

사용자는 해당 이미지가 자신의 기준에 맞는지 판단한다.

AI는 이 피드백을 바탕으로 분류 기준과 관련 프롬프트를 수정한다.

이런 과정을 반복하면서 사용자와 AI가 분류 기준을 함께 구체화한다.

여기서 중요한 것은 AI가 사용자를 대신해 무엇이 건강한 음식인지 최종적으로 결정하는 구조가 아니라는 점이다.

어떤 기준을 적용할지는 사람이 정하고 AI는 그 기준을 더 명확하게 표현하도록 돕는다.

18번의 실제 사용자 실험

Google은 정적인 벤치마크만으로 이런 연구를 평가하기 어렵다고 설명한다.

사람의 판단 기준이 실제 대화 중에 달라지는 과정을 관찰해야 하기 때문이다.

연구팀은 총 18회의 실제 사용자 세션을 진행했다.

각 세션은 약 1시간 30분 동안 진행됐다.

연구팀은 사용자가 분류 기준을 설정하고 수정하는 과정을 분석했다.

Google에 따르면 Agile Deliberation을 사용한 참가자는 일반적인 수작업 프롬프트 작성 방식보다 피로와 불안이 감소했다.

또한 더 일관되고 성능이 높은 이미지 분류기를 만들 수 있었다고 설명한다.

하지만 이번 결과를 모든 사용자의 생산성이 일정한 비율로 증가한다는 의미로 해석해서는 안 된다.

연구에는 제한된 수의 참가자가 참여했으며, 평가 대상도 주관적인 이미지 분류 작업이었다.

다른 종류의 업무에서 같은 효과가 나타나는지는 별도의 검증이 필요하다.

사람의 의도를 모델에 전달하는 문제

이번 연구는 최근의 AI 에이전트 개발과도 연결된다.

예를 들어 기업에서 고객 문의를 분류하는 AI를 만든다고 가정해 보자.

어떤 문의를 긴급한 문제로 분류해야 하는지 기준을 정해야 한다.

처음에는 서비스 장애와 결제 오류만 긴급하다고 판단할 수 있다.

하지만 실제 문의를 검토하다 보면 계정 접근 문제나 개인정보 노출 가능성도 긴급하게 다뤄야 한다는 사실을 발견할 수 있다.

이런 경우 모델의 성능을 높이는 것만으로 문제를 해결하기 어렵다.

모델이 따라야 할 기준 자체가 불완전하기 때문이다.

Agile Deliberation은 이런 상황에서 사람이 실제 사례를 검토하면서 판단 기준을 수정하고, AI가 그 기준을 일관되게 적용하도록 돕는 접근이다.

이번 연구는 AI의 성능을 개선하는 방법이 더 많은 데이터를 학습시키는 것에만 있지 않다는 점을 보여준다.

사람이 원하는 결과를 명확하게 정의할 수 있도록 지원하는 기술도 실제 AI 시스템의 정확성과 신뢰성에 중요한 영향을 줄 수 있다.

---

2️⃣ AI 제품·서비스

Adobe, 기업용 AI 마케팅 에이전트를 ChatGPT·Claude·Gemini·Copilot에 통합…여러 서비스의 고객 데이터를 연결해 업무 실행

• 발표일: 2026-11-04 — 게시 시각 06:00으로 표시, 시간대 미기재
• 적용 범위: 기업용 AI 에이전트, 디지털 마케팅, 고객경험 관리, ChatGPT 플러그인, Claude, Gemini, Microsoft Copilot, MCP
• 원문: Adobe — Adobe Integrates Agentic CX Enterprise Coworker Into AI Platforms

---

Adobe가 기업의 고객경험 관리에 사용하는 CX Enterprise Coworker를 여러 주요 AI 플랫폼에서 사용할 수 있도록 확대했다.

이번 업데이트는 Adobe의 새로운 범용 언어모델을 출시한 것이 아니다.

기존 Adobe의 기업용 데이터와 마케팅 업무 기능을 다른 기업의 AI 에이전트에 연결하도록 만든 통합 기능이다.

CX Enterprise Coworker는 고객 데이터를 분석하고 마케팅 활동을 계획하거나 실제 캠페인 운영을 지원하는 에이전트 시스템이다.

예를 들어 기업의 마케팅 담당자가 지난달 광고 성과를 분석하고 다음 캠페인의 대상 고객을 선정한다고 가정해 보자.

이 작업에는 여러 종류의 정보가 필요하다.

광고 서비스에는 노출과 클릭, 비용에 관한 정보가 존재한다.

고객관리 시스템에는 고객의 구매 기록과 관심사가 저장돼 있을 수 있다.

Adobe의 마케팅 도구에는 기존 캠페인의 성과와 브랜드 정책이 포함될 수 있다.

AI가 이런 정보를 함께 활용하려면 서로 다른 시스템의 데이터를 연결해야 한다.

Adobe는 이번 통합으로 사용자가 이미 사용하고 있는 AI 업무 환경에서 이러한 작업을 수행하도록 지원한다.

현재 제공되는 플랫폼과 향후 지원 플랫폼

Adobe가 발표한 제공 범위는 다음과 같다.

중요한 점은 현재 제공되는 기능과 향후 지원 계획을 구분해야 한다는 사실이다.

이번 발표가 모든 AI 플랫폼의 모든 사용자가 별도 설정 없이 Adobe의 고객 데이터를 즉시 사용할 수 있다는 의미는 아니다.

실제로는 Adobe 제품과 관련 계정의 연결, 조직의 접근권한 설정이 필요할 수 있다.

MCP와 A2A를 이용한 시스템 연결

이번 통합에는 MCP(Model Context Protocol)와 A2A(Agent-to-Agent)가 사용된다.

MCP는 AI 에이전트가 외부 프로그램과 데이터를 호출하도록 하는 통신 규격이다.

예를 들어 AI 에이전트가 광고 성과 데이터를 조회하는 도구를 MCP를 통해 호출할 수 있다.

A2A는 서로 다른 AI 에이전트가 작업을 전달하고 결과를 교환하도록 하는 통신 방식이다.

예를 들어 하나의 에이전트가 고객 세그먼트를 분석할 수 있다.

이후 다른 에이전트가 해당 고객에게 적절한 캠페인을 계획하도록 작업을 전달할 수 있다.

Adobe는 이런 구조를 이용해 고객 분석과 캠페인 운영, 결과 평가를 연결하려 한다.

이번에 공개된 새로운 연결 기능에는 Amazon Ads와 Databricks Genie, Demandbase, Meta 광고, Microsoft Work IQ, Snowflake Cortex AI 등이 포함된다.

다만 모든 외부 서비스에서 동일한 종류의 작업을 수행할 수 있는 것은 아니다.

어떤 데이터에 접근하고 어떤 행동을 실행할 수 있는지는 개별 서비스와 연결된 계정의 권한에 따라 달라진다.

고객 분석에서 실제 캠페인 실행으로

Adobe는 CX Enterprise Coworker의 주요 기능으로 캠페인 성과 분석과 고객 세그먼트 예측, 고객 여정 최적화를 제시했다.

Customer Journey(고객 여정)는 고객이 상품이나 서비스를 처음 인지하고 실제로 구매하거나 다시 이용하기까지 거치는 과정을 의미한다.

예를 들어 어떤 고객은 광고를 클릭한 뒤 바로 상품을 구매할 수 있다.

다른 고객은 여러 상품을 비교하고 이메일 안내를 받은 뒤 구매할 수 있다.

기업은 이런 차이를 분석해 고객에게 적절한 정보를 제공하려 한다.

CX Enterprise Coworker는 여러 시스템의 고객 데이터를 연결해 이런 분석과 업무 수행을 지원하도록 설계됐다.

하지만 AI가 특정 고객에게 상품을 추천하거나 광고를 실행할 수 있다는 사실과 해당 행동이 실제 매출을 높인다는 사실은 다르다.

광고 성과와 고객 반응은 실제 운영 데이터를 통해 검증해야 한다.

또한 여러 시스템의 데이터를 연결할 때는 개인정보와 고객의 동의 범위를 고려해야 한다.

기업용 AI의 공통 업무 계층으로 확장

이번 발표에서 주목할 부분은 Adobe가 하나의 AI 플랫폼에만 기능을 제공하지 않는다는 점이다.

기업마다 사용하는 AI 제품과 업무 환경이 다를 수 있다.

어떤 기업은 ChatGPT를 사용한다.

다른 기업은 Microsoft Copilot이나 Claude를 업무에 사용할 수 있다.

Adobe는 이런 환경에서도 같은 고객 데이터와 마케팅 기능을 재사용하도록 지원하려 한다.

이는 기업용 AI의 경쟁이 어떤 모델이 가장 좋은 답변을 생성하는가에서, 여러 업무 시스템의 정보를 얼마나 안전하고 일관되게 연결할 수 있는가로 확대되고 있음을 보여준다.

다만 Adobe는 이번 발표에서 새로운 통합 기능의 독립적인 업무 성공률이나 실제 비용 절감 수치를 제시하지 않았다.

따라서 구체적인 효과는 기업별 실제 도입 결과를 통해 확인해야 한다.

---

Google Cloud, 여러 클라우드의 데이터를 AI 에이전트에 연결하는 Agentic Data Cloud 기능 확대…Iceberg 직접 조회와 기업 지표 관리 강화

• 발표일: 2026-11-04 — 정확한 게시 시각 미확인
• 적용 범위: Google Cloud, BigQuery, AlloyDB, 데이터 레이크하우스, 기업용 AI 에이전트, Apache Iceberg, 데이터 거버넌스
• 원문: Google Cloud — New capabilities to power agents at scale with Google's Agentic Data Cloud
• 관련 원문: Google Cloud — Unify operational and Lakehouse data with direct Iceberg access in AlloyDB

---

Google Cloud가 기업용 AI 에이전트가 서로 다른 데이터 저장소의 정보를 안전하게 활용하도록 지원하는 Agentic Data Cloud의 기능을 확대했다.

이번 발표에서는 기존에 제공하던 여러 데이터 서비스의 최근 변화도 함께 소개됐다.

따라서 모든 기능을 11월 4일에 처음 출시된 것으로 이해해서는 안 된다.

이번 발표의 주요 신규 내용은 클라우드 간 데이터 접근의 정식 제공 확대, AlloyDB의 Iceberg 직접 접근, Knowledge Catalog의 업무 문맥 관리 기능과 새로운 개발 경험이다.

기업에서 AI 에이전트를 실제 업무에 사용하는 경우 데이터가 하나의 시스템에만 존재하는 일은 드물다.

예를 들어 고객의 주문정보는 PostgreSQL 데이터베이스에 저장돼 있을 수 있다.

과거 판매 기록은 BigQuery에서 분석할 수 있다.

일부 데이터는 AWS의 저장장치에 존재할 수도 있다.

이런 상황에서 AI가 정확한 보고서를 작성하려면 여러 시스템에 저장된 정보를 함께 이해해야 한다.

Google은 이 문제를 해결하기 위해 서로 다른 데이터 저장소를 하나의 관리된 분석 환경으로 연결하려 한다.

데이터를 복사하지 않고 다른 클라우드에서 조회

이번 업데이트의 주요 기술 가운데 하나는 Borderless Lakehouse다.

Lakehouse(레이크하우스)는 대량의 원본 데이터를 저장하는 데이터 레이크와 구조화된 분석 기능을 제공하는 데이터 웨어하우스의 특징을 결합한 데이터 플랫폼이다.

Google은 여기에 Apache Iceberg를 활용한다.

Apache Iceberg는 대규모 분석 데이터의 테이블 구조와 파일 정보를 관리하기 위한 개방형 형식이다.

예를 들어 기업의 판매 기록이 AWS S3에 Iceberg 테이블 형태로 저장돼 있다고 가정해 보자.

기존에는 해당 데이터를 Google Cloud로 복사한 뒤 분석해야 할 수도 있었다.

하지만 새롭게 확대된 연결 기능을 이용하면 데이터를 모두 옮기지 않고 원래 저장소의 자료를 조회할 수 있다.

Google은 AWS와 Azure 사이의 클라우드 간 연결 및 캐싱 기능을 정식 제공한다고 발표했다.

이 연결은 사설 네트워크 경로를 사용하며, Google이 설명한 해당 연결 구성에서는 가변적인 데이터 반출 요금이 발생하지 않도록 설계됐다.

다만 데이터 반출에 관한 특정 요금이 없다는 사실이 전체 데이터 분석 비용이 무료라는 의미는 아니다.

실제 쿼리 실행과 저장장치, 네트워크 연결 등에 관한 비용은 별도로 발생할 수 있다.

AlloyDB에서 실시간 거래 데이터와 과거 분석 데이터를 함께 조회

이번 발표에서는 AlloyDB의 Apache Iceberg 직접 접근 기능도 공개됐다.

AlloyDB는 Google Cloud의 PostgreSQL 호환 데이터베이스 서비스다.

PostgreSQL은 관계형 데이터베이스 관리 시스템이다.

기업의 실제 거래 데이터와 고객정보 등을 저장하는 데 사용할 수 있다.

문제는 실시간 운영 데이터와 과거 분석 데이터가 서로 다른 시스템에 존재할 수 있다는 점이다.

예를 들어 사용자가 지난 1년의 평균 판매량과 현재 재고를 비교해 달라고 요청했다고 가정해 보자.

현재 재고는 운영 데이터베이스에 저장돼 있을 수 있다.

하지만 지난 1년의 판매 기록은 데이터 레이크하우스에 저장돼 있을 수 있다.

이번 기능을 사용하면 AlloyDB에서 Iceberg 테이블을 직접 조회하고 운영 데이터와 결합할 수 있다.

SQL(Structured Query Language)은 관계형 데이터베이스의 데이터를 검색하고 처리하기 위한 언어다.

Google은 하나의 PostgreSQL SQL 쿼리에서 실시간 데이터와 과거 분석 데이터를 함께 조회하는 구조를 제공한다.

이렇게 하면 매번 별도의 데이터 복사 파이프라인을 만드는 부담을 줄일 수 있다.

Google은 특정 집계 쿼리에서 비교 대상인 AWS의 PostgreSQL 호환 서비스보다 최대 7배 빠른 실행 속도를 기록했다고 밝혔다.

하지만 이는 Google의 자체 성능 평가 결과다.

모든 쿼리와 데이터 구조에서 같은 속도 향상이 발생한다는 의미는 아니다.

AI가 기업의 계산 규칙을 추측하지 않도록 지원

Google은 Knowledge Catalog도 확대했다.

Knowledge Catalog는 여러 데이터 저장소에 존재하는 정보와 그 의미, 접근권한을 관리하는 서비스다.

예를 들어 기업에서 사용하는 매출이라는 개념을 생각해 보자.

어떤 회사는 모든 결제 금액을 매출로 계산할 수 있다.

다른 회사는 환불과 할인 금액을 제외한 순매출을 중요하게 사용할 수 있다.

AI가 데이터베이스에서 매출과 관련된 열을 찾았다고 해서 실제 기업의 공식 매출 계산 방식을 정확하게 이해했다고 볼 수는 없다.

Google은 이런 문제를 해결하기 위해 기존에 정의된 Semantic Model(의미 모델)을 에이전트에 제공한다.

의미 모델은 데이터의 실제 업무상 의미와 계산 규칙을 구조화한 자료다.

이번 발표에서는 BigQuery와 Looker, Databricks, Snowflake, dbt, SAP 등에서 정의된 기업의 업무 규칙을 재사용하는 기능의 정식 제공 범위도 설명했다.

또한 Gemini가 BigQuery나 AlloyDB 등과 연결될 때 Knowledge Catalog에서 관련 지표와 테이블의 관계를 자동으로 확인하도록 하는 기능을 프리뷰로 제공한다.

중요한 점은 AI가 단순히 SQL 문법에 맞는 쿼리를 작성하는 것으로 충분하지 않다는 것이다.

실제 기업이 승인한 지표와 계산 방법을 사용해야 올바른 업무 결과를 얻을 수 있다.

새로운 업무 문맥 관리 기능

Google은 Knowledge Catalog에 대화형 관리 화면과 업무 문맥의 자동 보강 기능도 추가했다.

예를 들어 에이전트가 업무 규칙을 확인할 때 GitHub와 Jira, Confluence와 SharePoint에 존재하는 관련 문서를 참고할 수 있도록 설계됐다.

하지만 모든 문서의 내용을 무조건 AI에게 전달하는 방식은 아니다.

사용자에게 필요한 정보와 접근권한을 고려해 관련 문맥을 제공하려는 접근이다.

또한 데이터 관리자가 자동으로 제안된 지식과 업무 규칙을 검토하고 승인할 수 있는 기능도 제공한다.

이 과정에서는 변경 이력을 관리하고 이전 버전으로 돌아가는 기능도 중요하다.

예를 들어 특정한 매출 계산 규칙이 변경됐는데 문제가 발생했다면 이전에 승인한 규칙으로 복구해야 할 수 있다.

Google은 내부 평가에서 Knowledge Catalog를 사용한 에이전트의 정확도가 약 네 배에 가깝게 개선됐고, 일부 조건에서 지연시간과 토큰 사용량도 감소했다고 설명했다.

하지만 이 수치는 Google의 자체 평가다.

모든 기업의 AI 에이전트가 같은 수준으로 개선된다는 의미는 아니다.

또한 Knowledge Catalog의 일부 기능은 이전에 발표됐으며, 이번 발표는 신규 기능과 최근 제공 상태의 변화를 함께 정리하고 있다.

이번 업데이트는 기업용 AI에서 더 강력한 언어모델을 선택하는 문제만큼 기업의 실제 데이터와 업무 규칙을 정확하게 연결하는 작업이 중요해지고 있음을 보여준다.

---

OpenAI, 보안 특화 모델 ‘GPT-5.6 Cyber’를 AWS GovCloud에서 제공…승인된 정부기관의 취약점 분석 지원

• 발표일: 2026-11-04 — 정확한 게시 시각 미확인
• 적용 범위: AI 사이버보안, 미국 정부 클라우드, AWS GovCloud, Amazon Bedrock, 취약점 연구, 모델 접근권한 관리
• 원문: OpenAI — Daybreak Red is now available in AWS GovCloud (US-East)

---

OpenAI가 보안 전문 AI 모델 GPT-5.6 Cyber를 미국의 AWS GovCloud 환경에서 제공하기 시작했다.

이번 발표는 GPT-5.6 Cyber라는 새로운 모델을 처음 출시한 소식이 아니다.

기존의 보안 전문 모델을 미국 정부기관이 사용하는 별도의 클라우드 환경에서 접근할 수 있도록 제공 범위를 확대한 것이다.

AWS GovCloud는 미국 정부기관과 규제 요구사항이 높은 조직을 위한 AWS의 클라우드 환경이다.

일반적인 상용 클라우드와는 구분되는 운영·접근 조건을 제공한다.

OpenAI는 이번에 GovCloud US-East에서 Daybreak Red를 이용할 수 있도록 했다.

일반적인 코딩 지원보다 전문적인 보안 분석

Daybreak Red는 승인된 보안 전문가에게 전문적인 사이버보안 능력을 제공하는 프로그램이다.

예를 들어 기업의 소프트웨어에서 보안 문제가 발견됐다고 가정해 보자.

보안 담당자는 해당 취약점이 실제로 악용 가능한지 확인해야 한다.

이후 어떤 조건에서 문제가 발생하는지 분석하고 수정 방법을 제안해야 한다.

GPT-5.6 Cyber는 이런 종류의 방어적 업무를 지원하도록 설계됐다.

OpenAI가 제시한 주요 활용 분야는 다음과 같다.

• 소프트웨어 취약점의 원인 분석
• 승인된 환경에서의 취약점 재현과 검증
• 보안 문제의 실제 영향 평가
• 수정 코드와 완화 조치의 검토
• 방어적 보안 테스트

여기서 중요한 것은 승인된 환경에서 수행하는 보안 연구라는 조건이다.

모델이 강력한 보안 분석 능력을 제공한다고 해서 실제 권한이 없는 외부 시스템을 자유롭게 시험할 수 있다는 의미는 아니다.

검증된 보안 전문가에게 다른 사용 조건 적용

OpenAI는 Daybreak Red에서 승인된 보안 전문가에게 일반적인 모델보다 일부 보안 작업에 대한 제한을 완화한다고 설명한다.

예를 들어 정상적인 취약점 연구 과정에서 필요한 기술적 분석이 일반적인 안전장치에 의해 차단될 수 있다.

Daybreak Red는 이러한 상황을 줄이기 위해 별도의 접근 검증과 사용 정책을 적용한다.

하지만 제한을 완화한다는 사실이 모든 사이버보안 요청을 무조건 허용한다는 의미는 아니다.

사용자는 자신의 자격과 연구 목적을 검증받아야 한다.

OpenAI는 강한 신원 확인과 접근권한 관리, 사용 기록 감시를 함께 적용한다고 밝혔다.

또한 AI가 제안한 취약점 수정과 방어 조치는 실제 보안 전문가가 검토해야 한다고 강조했다.

모델이 생성한 수정 코드가 기존 기능에 새로운 오류를 만들 수 있기 때문이다.

AWS Bedrock과 데이터 처리 조건

이번 기능은 Amazon Bedrock을 통해 제공된다.

Amazon Bedrock은 AWS가 여러 생성형 AI 모델을 API 형태로 제공하는 서비스다.

정부기관은 기존 AWS 환경에서 관련 모델을 호출하는 방식으로 보안 분석 시스템을 구축할 수 있다.

OpenAI는 이번 구성에서 모델 추론에 사용한 데이터를 OpenAI에 전달할 필요가 없으며, 해당 데이터를 모델 학습에도 사용하지 않는다고 밝혔다.

Inference(추론)는 이미 학습된 모델이 새로운 입력을 받아 결과를 생성하는 과정이다.

이는 정부기관이 보유한 중요한 보안 자료를 처리할 때 의미 있는 조건이다.

하지만 해당 설명이 모든 AWS 서비스와 관련 로그가 자동으로 동일한 보관 정책을 따른다는 의미는 아니다.

실제 사용기관은 AWS의 계정 설정과 네트워크, 접근권한 및 로그 보관 정책도 함께 확인해야 한다.

승인과 실제 서비스 활성화는 별개의 절차

이번 발표에는 중요한 이용 조건이 있다.

Daybreak Red를 사용하려면 OpenAI의 프로그램 승인을 받아야 한다.

하지만 OpenAI의 승인을 받았다고 해서 AWS GovCloud에서 모델이 자동으로 활성화되는 것은 아니다.

AWS 측의 별도 제공 설정과 자원 할당 절차가 필요하다.

따라서 일반적인 AWS 계정을 가진 모든 개발자가 이번 모델을 즉시 호출할 수 있는 것은 아니다.

이번 발표는 AI의 사이버보안 능력이 강해질수록 모델의 성능뿐 아니라 누가 어떤 환경에서 어떤 목적으로 사용할 수 있는지 관리하는 접근 체계가 중요해지고 있음을 보여준다.

---

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

Redis, AI 에이전트용 ‘Iris’ 기능 6종으로 확대…기억·도구 검색·실행 추적·에이전트 간 통신을 하나의 플랫폼으로 통합

• 발표일: 2026-11-04 — 정확한 게시 시각 미확인
• 적용 범위: Redis, AI 에이전트 인프라, 장기 기억, MCP, 모델 라우팅, 분산 에이전트, 실시간 메시징
• 원문: Redis — Redis Iris
• 관련 원문: Redis — Redis Expands Redis Iris to Give AI Agents the Memory, Context, and Messaging They Need

---

Redis가 AI 에이전트를 위한 실시간 데이터·기억 플랫폼 Redis Iris의 주요 기능을 확대했다.

Iris 자체는 2026년 5월에 처음 공개됐다.

11월 4일의 새로운 발표는 기존 시스템을 여섯 가지 주요 기능으로 재구성하고, 일부 기능을 정식 제공 단계로 전환했다는 점이다.

Redis는 일반적으로 빠른 데이터 조회와 캐싱에 사용되는 데이터 플랫폼으로 알려져 있다.

하지만 AI 에이전트에서는 단순히 데이터를 빠르게 가져오는 것보다 더 복잡한 요구사항이 존재한다.

예를 들어 고객지원 에이전트가 특정 고객의 주문 문제를 해결한다고 가정해 보자.

에이전트는 고객의 과거 문의와 현재 주문 상태를 확인해야 한다.

어떤 환불 정책을 적용해야 하는지도 알아야 한다.

필요하다면 실제 고객지원 시스템의 도구를 호출해야 한다.

또한 다른 에이전트에게 작업을 전달할 수도 있다.

문제는 이러한 정보와 작업 상태가 서로 다른 시스템에 분산돼 있을 수 있다는 점이다.

Redis Iris는 이 과정을 지원하는 공통 인프라를 제공하려 한다.

여섯 가지 기능과 제공 상태

이번 발표의 주요 기능은 다음과 같다.

여기서 중요한 점은 모든 기능이 동일한 제공 단계에 있는 것은 아니라는 사실이다.

Intent Router와 Agent Playbooks, Agent Memory와 Context Gateway는 정식 제공된다.

반면 Lens와 Agent Mesh는 베타 단계다.

따라서 새롭게 공개된 모든 기능이 실제 기업 환경에서 동일한 안정성과 지원 조건을 제공한다고 볼 수는 없다.

Intent Router: 어떤 요청에 어떤 도구가 필요한가

Intent Router(의도 라우터)는 사용자의 요청을 분석해 적절한 처리 경로를 선택한다.

예를 들어 사용자가 배송비 정책을 질문했다고 가정해 보자.

이미 검증된 답변이 존재한다면 굳이 대형 언어모델을 호출할 필요가 없을 수 있다.

반면 특정한 고객의 배송 상태를 확인하는 요청이라면 실제 주문 데이터를 조회해야 할 수 있다.

Intent Router는 이런 차이를 구분하도록 설계됐다.

사용자의 요청을 다음과 같은 대상으로 전달할 수 있다.

• 미리 저장한 FAQ 답변
• 특정 업무를 수행하는 Agent Skill
• 사람 담당자
• 생성형 AI 모델
• 별도의 업무 처리 시스템

Agent Skill(에이전트 스킬)은 특정 작업을 수행하는 데 필요한 지침과 도구 사용 방법을 묶은 구성요소다.

Intent Router는 단순히 특정한 단어가 포함됐는지만 확인하는 방식에 한정되지 않는다.

요청의 의미를 분석해 관련 기능을 선택하도록 설계됐다.

이를 Semantic Routing(의미 기반 라우팅)이라고 한다.

이런 구조는 불필요한 모델 호출을 줄이는 데 도움이 될 수 있다.

하지만 라우터가 사용자의 요청을 잘못 분류하면 필요한 도구가 호출되지 않을 수 있으므로 실제 업무 데이터를 이용한 검증이 필요하다.

Agent Playbooks: 같은 문제를 매번 처음부터 해결하지 않는다

Agent Playbooks는 이전에 검증된 답변과 업무 절차를 재사용하도록 지원한다.

예를 들어 특정한 환불 요청을 처리하기 위해 다섯 단계의 검증이 필요하다고 가정해 보자.

모델이 같은 종류의 요청이 들어올 때마다 전체 절차를 다시 계획한다면 불필요한 계산이 반복될 수 있다.

Playbooks는 이미 확인된 처리 절차를 저장하고 재사용하도록 만든다.

하지만 여기에는 주의할 점이 있다.

어떤 정보는 시간이 지나도 거의 변경되지 않는다.

반면 현재 주문 상태나 계좌 잔액처럼 계속 변하는 정보도 존재한다.

따라서 모든 답변을 그대로 캐싱해서는 안 된다.

Redis는 재사용할 수 있는 안정적인 정보와 실제 데이터를 다시 조회해야 하는 작업을 구분하도록 설계했다고 설명한다.

Agent Memory: 과거 대화와 실제 업무 기록을 함께 관리

Agent Memory는 AI 에이전트의 단기·장기 기억을 관리한다.

단기 기억은 현재 진행 중인 작업과 최근 대화에 필요한 정보다.

장기 기억은 이후의 작업에서도 참고할 수 있는 사용자 선호나 과거 결정, 반복적인 업무 규칙 등을 의미한다.

예를 들어 사용자가 특정한 보고서 형식을 선호한다면 이후 비슷한 작업에서 이를 참고할 수 있다.

하지만 기억을 많이 저장한다고 해서 좋은 결과가 자동으로 만들어지는 것은 아니다.

오래된 정보가 현재 상황과 충돌할 수 있기 때문이다.

Redis는 기억을 계층적으로 관리하고 출처와 변경 이력을 추적하도록 지원한다.

또한 필요하지 않은 개인정보를 저장하지 않거나 삭제하는 기능도 제공한다.

이런 구조는 개인화와 개인정보 보호, 정보의 최신성 사이의 균형을 관리하기 위한 것이다.

Context Gateway: 필요한 도구와 데이터만 제공

Context Gateway는 여러 데이터 저장소와 도구를 하나의 관리된 연결 경로로 제공한다.

여기에는 MCP(Model Context Protocol)가 사용된다.

MCP는 AI 에이전트가 외부 프로그램과 데이터를 호출하도록 하는 통신 규격이다.

예를 들어 기업에 주문 데이터베이스와 배송 서비스, 고객지원 시스템이 존재할 수 있다.

에이전트는 Context Gateway를 통해 필요한 정보를 조회할 수 있다.

하지만 모든 데이터와 도구에 접근해야 하는 것은 아니다.

실제 사용자의 권한과 업무 목적에 따라 접근 가능한 기능을 제한해야 한다.

Redis는 이미 연결된 MCP 서버를 활용하고 어떤 도구가 특정 문제를 해결했는지에 관한 정보를 캐싱하도록 지원한다.

이렇게 하면 같은 종류의 업무에서 도구를 반복적으로 탐색하는 비용을 줄일 수 있다.

Lens와 Agent Mesh: 실행 결과의 추적과 에이전트 간 통신

새롭게 베타로 제공되는 Lens는 에이전트의 실제 행동을 관찰하는 기능이다.

예를 들어 에이전트가 잘못된 답변을 생성했다고 가정해 보자.

원인을 확인하려면 어떤 데이터를 사용했고 어떤 도구를 호출했는지 알아야 한다.

Lens는 요청을 처리할 때 사용한 경로와 Skill, 기억과 실제 결과를 연결해 기록하도록 설계됐다.

또한 작업별 성공률과 지연시간, 토큰 사용량을 확인할 수 있다.

Agent Mesh는 여러 에이전트 사이의 메시지 전달을 지원한다.

예를 들어 하나의 에이전트가 고객의 문제를 분석하고 다른 에이전트가 실제 환불 절차를 수행할 수 있다.

그런데 두 에이전트 사이의 네트워크 연결이 중단되면 메시지가 손실될 수 있다.

Agent Mesh는 버퍼와 자동 재연결, 지속적인 이벤트 스트림을 이용해 이런 문제를 줄이도록 설계됐다.

다만 두 기능은 현재 베타 단계이며 모든 종류의 장애를 자동으로 복구하거나 완전한 실행 기록을 보장한다고 단정할 수는 없다.

이번 발표는 AI 에이전트의 실제 운영에서 모델이 얼마나 똑똑한가뿐 아니라 현재 상황을 어떻게 기억하고, 도구를 어떻게 선택하며, 여러 에이전트가 어떻게 안정적으로 협력하는가가 중요한 기술적 과제로 발전하고 있음을 보여준다.

---

Google Cloud, AI 코딩 에이전트용 ‘AlloyDB Express’ 공개…2초 이내 데이터베이스 생성하고 15분 미사용 시 자동 중지

• 발표일: 2026-11-04 — 정확한 게시 시각 미확인
• 적용 범위: PostgreSQL, AI 코딩 에이전트, 데이터베이스 자동화, MCP, CI/CD, 서버리스 인프라, RAG
• 원문: Google Cloud — AlloyDB Express: Instant, scale-to-zero PostgreSQL for developers and coding agents

---

Google Cloud가 개발자와 AI 코딩 에이전트를 위한 새로운 데이터베이스 서비스 AlloyDB Express를 프리뷰로 공개했다.

이번 기능은 기존 AlloyDB를 단순히 더 저렴하게 제공하는 것보다 개발 환경의 생성 속도와 운영 방식에 초점을 맞췄다.

AI 코딩 에이전트가 새로운 기능을 개발하고 시험할 때 필요한 데이터베이스를 몇 초 안에 만들고, 사용하지 않을 때는 자동으로 중지하도록 설계했다는 점이 핵심이다.

일반적인 웹 개발에서도 데이터베이스를 준비하는 과정은 필요하다.

예를 들어 새로운 기능을 시험하려면 별도의 테스트 데이터베이스를 만들 수 있다.

이후 테이블을 생성하고 샘플 데이터를 입력해야 한다.

문제는 AI 코딩 에이전트가 여러 작업을 병렬로 수행할 때 발생한다.

예를 들어 세 개의 에이전트가 같은 데이터베이스를 수정한다면 서로의 테스트 데이터가 영향을 받을 수 있다.

따라서 각 작업에 별도의 데이터베이스를 제공하는 편이 안전할 수 있다.

하지만 매번 데이터베이스를 생성하는 데 오랜 시간이 필요하다면 전체 개발 속도가 느려진다.

AlloyDB Express는 이런 문제를 줄이기 위해 개발됐다.

2초 이내 데이터베이스 생성

Google에 따르면 AlloyDB Express는 2초 이내에 새로운 PostgreSQL 데이터베이스를 생성할 수 있다.

지원하는 생성 방법에는 다음이 포함된다.

• Google Cloud Console
• gcloud CLI
• REST API
• MCP
• Terraform

여기서 REST API는 HTTP를 이용해 프로그램 사이에서 자원과 데이터를 처리하는 인터페이스다.

Terraform은 클라우드 인프라를 코드로 정의하고 관리하는 도구다.

MCP는 AI 에이전트가 외부 프로그램과 데이터를 호출하도록 하는 통신 규격이다.

개발자는 이런 인터페이스를 통해 데이터베이스의 생성 과정을 자동화할 수 있다.

예를 들어 코딩 에이전트가 새로운 기능을 개발하기 전에 자신의 작업에 사용할 데이터베이스를 생성할 수 있다.

이후 관련 테이블과 테스트 데이터를 준비하고 실제 프로그램을 실행할 수 있다.

작업이 끝나면 해당 데이터베이스를 정리하도록 구성할 수 있다.

다만 2초라는 수치는 Google이 공개한 서비스 생성 시간에 관한 설명이다.

실제로 필요한 테이블과 데이터를 모두 준비하는 시간까지 포함한 전체 개발환경 구성 시간이 항상 2초 이내라는 의미는 아니다.

15분 동안 사용하지 않으면 계산 자원 자동 중지

AlloyDB Express는 Scale-to-Zero 기능을 제공한다.

Scale-to-Zero는 서비스에 작업이 없는 동안 실행 중인 계산 자원을 자동으로 줄이거나 중지하는 방식이다.

AlloyDB Express에서는 15분 동안 사용하지 않으면 데이터베이스의 계산 자원이 중지된다.

새로운 쿼리가 도착하면 수초 안에 다시 활성화된다.

예를 들어 개발자가 저녁에 작업을 마치고 다음 날 아침 다시 개발을 시작할 수 있다.

이때 데이터베이스가 사용되지 않는 동안 계속 계산 자원 비용을 지불할 필요가 줄어든다.

하지만 데이터베이스가 중지된 동안 모든 비용이 사라지는 것은 아니다.

저장된 데이터를 보관하기 위한 스토리지 비용은 계속 발생할 수 있다.

Google이 공개한 가격은 다음과 같다.

실제 청구액은 지역과 사용량, 별도 서비스 사용 여부에 따라 달라질 수 있다.

또한 무료 제공량이 있다는 사실이 모든 데이터베이스 사용이 무제한으로 무료라는 의미는 아니다.

PostgreSQL과 AI 검색 기능 통합

AlloyDB Express는 PostgreSQL 기반의 관계형 데이터베이스다.

하지만 일반적인 데이터 저장과 조회뿐 아니라 AI 애플리케이션에 필요한 검색 기능도 제공한다.

대표적인 기능은 Vector Search(벡터 검색)다.

벡터 검색은 문서나 이미지의 의미를 여러 숫자로 표현한 뒤 비슷한 정보를 찾는 방식이다.

이때 사용하는 숫자 표현을 Embedding(임베딩)이라고 한다.

예를 들어 고객지원 문서를 임베딩으로 변환하면 정확히 같은 단어가 포함되지 않은 문서도 의미에 따라 검색할 수 있다.

이런 기술은 RAG(Retrieval-Augmented Generation, 검색 증강 생성)에 활용된다.

RAG는 외부 문서에서 관련 정보를 검색한 뒤 이를 언어모델의 입력에 추가하는 방식이다.

AlloyDB Express는 pgvector와 ScaNN 기반의 벡터 검색을 지원한다.

또한 SQL 안에서 Gemini 모델을 이용한 임베딩 생성과 의미 기반 필터링, 요약 기능을 호출할 수 있다.

예를 들어 고객문의 데이터를 조회하면서 관련 설명을 요약하거나 비슷한 문의를 검색하는 기능을 구현할 수 있다.

다만 데이터베이스 안에서 AI 기능을 호출할 수 있다는 사실만으로 모델의 실제 추론 비용이 사라지는 것은 아니다.

연결된 모델의 사용 조건과 비용을 함께 고려해야 한다.

테스트 환경에서 실제 운영 환경으로 이동

이번 서비스의 또 다른 특징은 기존 데이터베이스를 그대로 유지하면서 일반 AlloyDB로 업그레이드할 수 있다는 점이다.

Google은 데이터와 테이블 구조, 사용자와 연결 문자열을 유지하면서 정식 운영용 AlloyDB로 전환하도록 지원한다고 설명했다.

이렇게 하면 개발자가 시험용 데이터베이스를 만들고 애플리케이션을 개발한 뒤 실제 서비스 운영 환경으로 이동하는 과정의 부담을 줄일 수 있다.

하지만 정식 운영으로 전환하기 전에 성능과 접근권한, 백업과 장애 복구 정책을 별도로 확인해야 한다.

실제 운영환경에서는 많은 사용자의 동시 요청과 데이터 무결성, 장애 발생 시 복구 능력이 중요하기 때문이다.

AlloyDB Express는 현재 프리뷰 단계다.

따라서 모든 지역과 기능에서 정식 운영 서비스와 같은 지원 조건을 제공한다고 볼 수는 없다.

이번 발표는 AI 코딩 에이전트가 단순히 코드를 작성하는 단계를 넘어 필요한 개발 인프라를 직접 생성하고 시험한 뒤 실제 서비스에 연결하는 방향으로 발전하고 있음을 보여준다.

---

4️⃣ 산업·정책·안전

미국 OCC, 은행의 고도화된 AI 사용을 평가하는 감독 프레임워크 발표…모델의 규모보다 실제 결정 권한과 잠재 피해에 초점

• 발표일: 2026-11-04 — 정확한 게시 시각 미확인
• 적용 범위: 미국 금융 규제, AI 거버넌스, 은행 감독, AI 에이전트, 모델 위험관리, 인간 승인, 금융소비자 보호
• 원문: 미국 OCC — Super Intelligence: Supervisory Framework

---

미국 통화감독청 OCC(Office of the Comptroller of the Currency)가 은행의 고도화된 AI 사용을 평가하기 위한 새로운 감독 프레임워크를 발표했다.

OCC는 미국의 국법은행과 연방 저축기관 등을 감독하는 금융 규제기관이다.

이번 문서는 Super Intelligence: Supervisory Framework라는 제목으로 공개됐다.

여기서 반드시 확인해야 할 부분이 있다.

문서에서 사용하는 Super Intelligence(SI)는 일반적인 기술 담론에서 말하는 인간보다 모든 분야에서 뛰어난 초지능만을 가리키는 표현이 아니다.

OCC는 최근 미국 행정명령에서 사용한 폭넓은 정의에 따라 기존 AI 기술과 빠르게 발전하는 관련 시스템을 포함하는 개념으로 사용하고 있다.

또한 이번 문서는 은행에 새로운 법적 의무를 부과하는 규정이 아니다.

OCC 감독관이 은행의 AI 활용을 검토할 때 참고하도록 작성한 내부 감독 지침이다.

AI 모델의 성능보다 실제 업무에서 수행하는 역할 평가

OCC는 AI 시스템의 위험을 판단할 때 모델 자체의 기술적 복잡성만을 기준으로 삼아서는 안 된다고 설명했다.

예를 들어 두 은행이 같은 언어모델을 사용한다고 가정해 보자.

첫 번째 은행에서는 고객지원 담당자가 내부 문서를 검색하는 데 사용한다.

AI는 관련 문서를 찾아주지만 실제 고객의 계좌를 변경하지는 않는다.

두 번째 은행에서는 같은 모델을 이용해 대출 신청을 평가하고 실제 승인 과정에 영향을 준다.

두 시스템은 같은 모델을 사용하지만 실제 위험 수준은 다를 수 있다.

대출 승인 과정에서 잘못된 판단이 발생하면 금융소비자에게 직접적인 피해가 발생할 수 있기 때문이다.

따라서 OCC는 모델의 규모와 벤치마크 점수보다 실제 사용 사례와 잘못된 행동이 발생했을 때의 결과를 중요하게 평가하도록 했다.

세 가지 주요 판단 요소

OCC는 특히 다음 요소를 강조한다.

Transfer of Agency(행동·결정 권한의 이전)는 사람이 직접 수행하던 업무를 AI 시스템에 어느 정도 위임했는지 나타낸다.

예를 들어 AI가 대출 관련 자료를 요약하는 것과 실제로 대출 신청을 승인하는 것은 다르다.

후자에서는 AI의 판단이 외부 세계에 직접적인 영향을 줄 수 있다.

또한 인간의 감독이 존재한다고 해서 항상 위험이 낮다고 판단할 수는 없다.

예를 들어 AI가 수천 건의 신청을 자동으로 처리하고 담당자가 최종 결과만 형식적으로 승인한다면 실제로 얼마나 충분한 검토가 이뤄지는지 확인해야 한다.

반면 AI가 여러 후보를 제시하고 담당자가 필요한 근거를 확인한 뒤 실제로 결정한다면 통제 수준이 다를 수 있다.

OCC는 이런 차이를 실제 업무의 위험에 비례해 평가하도록 안내한다.

기존 위험관리 체계와 통합

이번 프레임워크는 AI를 완전히 새로운 위험 범주로 분리하지 않는다.

OCC는 기존의 모델 위험관리와 내부통제, 규정 준수와 운영 위험관리 체계를 활용하도록 했다.

예를 들어 은행은 이미 여러 금융 모델을 사용하고 있다.

대출의 신용 위험을 평가하는 통계 모델이나 시장 위험을 분석하는 시스템이 대표적이다.

이런 모델에는 실제 데이터의 품질과 결과의 검증, 변경 이력과 운영 절차를 관리하는 체계가 필요하다.

OCC는 AI 에이전트에도 이런 기존 원칙을 활용할 수 있다고 설명한다.

다만 에이전트는 일반적인 예측 모델과 다른 위험을 만들 수 있다.

예를 들어 모델이 단순히 숫자를 출력하는 것이 아니라 외부 도구를 호출해 실제 계좌정보를 수정할 수 있다.

이 경우 잘못된 판단이 단순한 보고서 오류에서 끝나지 않을 수 있다.

따라서 실제 행동 권한이 큰 시스템에서는 보다 강한 접근권한 제한과 승인 절차가 필요할 수 있다.

은행의 규모와 사용 목적에 따라 감독 강도 조정

OCC는 모든 은행에 같은 수준의 기술적 통제를 요구하는 방식도 적절하지 않다고 설명한다.

예를 들어 작은 지역은행이 내부 문서 검색에 제한적으로 AI를 사용하는 상황과 대형 은행이 여러 금융상품의 거래를 자동화하는 상황은 다르다.

따라서 감독관은 은행의 규모와 복잡성, 위험 특성을 고려해야 한다.

또한 AI가 수행하는 작업의 성격과 잠재적인 피해, 자율성 수준을 함께 평가해야 한다.

이번 프레임워크는 은행이 별도의 SI Risk Appetite(초지능 위험 감수 성향)를 반드시 정의하도록 요구하지 않는다.

Risk Appetite(위험 감수 성향)는 조직이 사업 목표를 달성하는 과정에서 어느 정도의 위험을 허용할지 정하는 기준이다.

OCC는 기존의 위험관리 체계를 활용할 수 있으며, 이번 문서가 새로운 규제 기준을 만드는 것은 아니라고 명시했다.

새로운 법률이나 의무가 아니라 감독관의 참고 지침

이번 발표에서 가장 중요한 법적 구분은 문서의 성격이다.

OCC는 이번 프레임워크가 은행에 대한 새로운 규제 기대나 강제 가능한 기준을 설정하지 않는다고 명확하게 밝혔다.

또한 은행이 이 문서를 이용해 자사의 AI 위험관리 체계를 직접 평가해야 한다는 의무도 부과하지 않는다.

이 문서는 감독관이 실제 은행의 AI 활용을 검토할 때 위험 수준에 맞는 질문을 하도록 지원하는 자료다.

향후 기술과 사용 사례가 발전하면 프레임워크도 변경될 수 있다.

따라서 이번 발표를 미국 정부가 새로운 AI 금융 규제를 즉시 시행했다고 설명하는 것은 정확하지 않다.

그럼에도 이번 문서는 AI 금융 감독의 중요한 방향을 보여준다.

모델이 얼마나 강력한가보다 그 모델이 실제로 어떤 결정을 내리고, 사람의 권한을 얼마나 대신하며, 실패했을 때 어떤 피해를 만들 수 있는가를 중심으로 AI 위험을 평가하려는 접근이다.

---

📚 추천 글

Progress on provable inference for large language models

• 저자: Roy Rinberg, Alex Allain 외 Anthropic Frontier Red Team 및 공동 연구진
• 발행: Anthropic Research
• 게시일: 2026-11-02
• 원문: Anthropic — Progress on provable inference for large language models

---

사용자가 특정한 AI 모델을 선택했을 때 실제로 그 모델이 답변을 생성했는지 어떻게 확인할 수 있을까?

예를 들어 어떤 AI 서비스가 강력한 프런티어 모델을 제공한다고 광고한다고 가정해 보자.

사용자는 해당 모델의 API를 호출한다.

하지만 실제로는 더 작고 저렴한 다른 모델이 요청을 처리했을 가능성도 존재한다.

대부분의 사용자는 생성된 답변만 보고 실제로 어떤 모델이 실행됐는지 확인하기 어렵다.

이 문제는 단순히 서비스 요금에 관한 문제에 그치지 않는다.

예를 들어 특정한 안전성 평가를 통과한 모델만 사용해야 하는 조직이 있을 수 있다.

이 경우 실제로 어떤 모델이 요청을 처리했는지 검증할 수 있어야 한다.

Anthropic은 이를 해결하기 위한 Provable Inference(검증 가능한 AI 추론) 연구를 공개했다.

핵심은 모델의 가중치를 공개하지 않고도 특정한 모델이 실제로 주어진 답변을 생성했다는 사실을 암호학적으로 증명하는 방법이다.

모델의 가중치를 공개하지 않고 검증

일반적인 방법으로는 모델의 가중치를 확인한 뒤 같은 입력을 다시 실행할 수 있다.

하지만 대형 모델의 가중치는 상당한 저장공간을 사용한다.

또한 상용 모델의 가중치는 공개되지 않는 경우가 많다.

따라서 모든 사용자가 직접 모델을 실행해 결과를 검증하는 것은 현실적이지 않다.

Anthropic은 이를 해결하기 위해 zkSNARK라는 암호학적 기술을 활용했다.

zkSNARK는 어떤 계산이 올바르게 수행됐다는 사실을 비교적 작은 증명으로 확인할 수 있도록 만드는 기술이다.

여기서 중요한 특징은 Zero-Knowledge(영지식성)다.

검증자가 실제 계산에 사용한 비밀정보를 직접 알지 못하더라도 특정한 계산이 올바르게 수행됐다는 사실을 확인할 수 있다.

예를 들어 모델 제공업체는 실제 모델 가중치를 공개하지 않는다.

대신 그 가중치를 대표하는 암호학적인 약속값을 공개한다.

이를 Commitment(커밋먼트)라고 한다.

이후 모델이 특정한 질문에 답변하면 제공업체가 관련 증명을 생성한다.

사용자는 해당 증명을 검증해 약속된 모델이 실제로 해당 결과를 생성했는지 확인할 수 있다.

FlashProve: 실제 대형 모델에서 증명 생성

Anthropic은 이러한 접근을 구현하기 위해 FlashProve를 개발했다.

연구팀은 Meta의 Llama 4 Maverick을 이용해 실험했다.

이 모델은 약 4,000억 개의 전체 파라미터를 가진 MoE 모델이다.

MoE(Mixture of Experts)는 여러 전문 신경망 가운데 입력에 필요한 일부만 활성화하는 구조다.

FlashProve는 실제로 사용한 전문가 네트워크를 기준으로 증명 작업을 수행하도록 최적화했다.

Anthropic이 공개한 주요 결과는 다음과 같다.

Quantization(양자화)은 모델의 숫자를 낮은 정밀도로 표현해 메모리 사용량과 계산 비용을 줄이는 기술이다.

이번 실험에서는 4비트 가중치와 정수 연산을 활용했다.

또한 결과를 검증하는 프로그램은 일반적인 CPU에서도 실행할 수 있도록 설계됐다.

하지만 중요한 문제가 있다.

증명을 생성하는 계산 비용은 일반적인 모델 추론보다 훨씬 높다.

따라서 FlashProve를 사용한다고 해서 모든 AI 요청을 저렴하게 검증할 수 있는 것은 아니다.

실제 적용을 위해서는 추가적인 최적화가 필요하다.

검증 프로그램도 올바르게 작동해야 한다

이번 연구에서 흥미로운 부분은 증명 생성 프로그램뿐 아니라 증명을 검사하는 프로그램의 정확성도 다뤘다는 점이다.

예를 들어 모델이 특정한 답변을 생성했다는 증명을 받았다고 가정해 보자.

그런데 증명을 검사하는 프로그램에 버그가 존재한다면 잘못된 증명도 통과할 가능성이 있다.

Anthropic은 이를 해결하기 위해 두 종류의 검증기를 제공했다.

하나는 빠르게 실행되는 C++ 검증기다.

다른 하나는 Lean으로 작성한 검증기다.

Lean은 수학적 명제와 프로그램의 성질을 형식적으로 검증하는 데 사용하는 언어이자 도구다.

Anthropic은 보안 성질에 관한 상위 수준의 증명을 Lean으로 작성했다.

하지만 이번 시스템의 모든 구성요소가 완전하게 형식 검증됐다는 의미는 아니다.

연구팀은 현재의 결과를 완성된 제품이 아니라 개발 중인 연구 시제품이라고 설명한다.

실제 AI 서비스에 필요한 신뢰의 새로운 방식

이번 연구는 AI의 신뢰성을 확보하는 방법이 모델의 답변을 검사하는 것에만 있지 않다는 점을 보여준다.

어떤 모델이 실제로 답변했는지 확인할 수 있다면 AI 서비스 제공업체의 설명을 외부에서 검증하는 방법이 생긴다.

또한 특정한 모델만 사용할 수 있는 환경에서 실제 사용 모델을 확인할 가능성도 있다.

하지만 증명이 올바르다고 해서 해당 모델의 답변이 사실이라는 의미는 아니다.

증명은 지정한 모델이 실제로 해당 계산을 수행했는지를 확인한다.

모델이 사실과 다른 답변을 생성했는지는 별도의 문제다.

이번 글은 생성형 AI의 신뢰성을 이해할 때 모델의 정확성, 실행한 모델의 정체성과 실제 계산의 검증 가능성은 서로 다른 문제라는 점을 명확하게 보여준다.

---

Palette: teaching a small model to build decks in your design language

• 저자: Praveen Venkateswaran, Anupama Murthi, Hamid Adebayo
• 발행: IBM Research / Hugging Face
• 게시일: 2026-11-03
• 원문: Hugging Face — Palette: teaching a small model to build decks in your design language

---

AI에게 프레젠테이션을 만들어 달라고 요청하면 그럴듯한 슬라이드가 생성될 수 있다.

하지만 실제 기업에서 사용하기에는 여러 문제가 발생할 수 있다.

예를 들어 회사가 사용하는 특정한 글꼴과 색상, 여백과 도표 형식이 존재할 수 있다.

AI가 생성한 슬라이드의 내용은 적절하더라도 회사의 디자인 규칙과 다를 수 있다.

또는 제목과 본문의 위치가 겹치거나 일부 글자가 화면 밖으로 벗어날 수 있다.

IBM Research의 Palette 연구는 이런 문제를 해결하기 위해 개발됐다.

특히 이번 연구는 강력한 상용 모델을 매번 호출하는 대신 상대적으로 작은 오픈웨이트 모델을 기업의 디자인 규칙에 맞게 학습시키고, 실제 렌더링 결과를 검사하는 구조를 제안한다.

기획과 슬라이드 제작을 분리

일반적인 슬라이드 생성 모델은 사용자의 문서를 읽고 슬라이드 내용을 결정하면서 동시에 레이아웃도 만들어야 할 수 있다.

하지만 두 작업은 서로 다른 능력을 요구한다.

예를 들어 어떤 내용을 첫 번째 슬라이드에 배치할지 결정하는 것은 기획의 문제다.

반면 60자 길이의 제목을 몇 포인트 크기로 표시해야 하는지는 실제 레이아웃 계산의 문제다.

Palette는 이를 두 역할로 분리했다.

첫 번째는 Designer(디자이너)다.

디자이너는 문서의 핵심 내용을 정리하고 전체 슬라이드 구성을 결정한다.

이후 각 슬라이드에 어떤 텍스트와 도표를 배치할지 구조화된 JSON 형식으로 작성한다.

JSON(JavaScript Object Notation)은 데이터를 키와 값의 형태로 표현하는 구조화된 형식이다.

두 번째는 Coder(코더)다.

코더는 각 슬라이드의 구조화된 명세를 읽고 실제 슬라이드를 생성하는 JavaScript 코드를 작성한다.

여기에는 PptxGenJS가 사용된다.

PptxGenJS는 JavaScript로 PowerPoint 파일을 생성할 수 있도록 지원하는 라이브러리다.

이렇게 하면 슬라이드의 내용과 실제 배치를 서로 다른 단계에서 처리할 수 있다.

20B 모델과 약 1만 장의 합성 슬라이드

연구팀은 약 200억 파라미터 규모의 오픈웨이트 모델을 추가 학습했다.

오픈웨이트 모델은 학습된 가중치를 다운로드하고 자체 실행 환경에서 사용할 수 있도록 공개된 모델이다.

이번 연구에는 LoRA(Low-Rank Adaptation)가 사용됐다.

LoRA는 모델의 전체 가중치를 다시 학습하는 대신 상대적으로 적은 추가 파라미터를 학습하는 방법이다.

연구팀은 약 1,000개 프레젠테이션과 1만 장의 슬라이드로 구성된 합성 학습 데이터를 생성했다.

여기에는 슬라이드의 실제 내용과 레이아웃뿐 아니라 왜 특정한 디자인을 선택했는지 설명하는 정보도 포함됐다.

예를 들어 분기별 매출을 설명할 때 표보다 막대그래프가 적절하다고 판단한 이유를 학습 데이터에 포함할 수 있다.

이렇게 하면 모델이 특정한 모양만 반복해서 생성하는 것이 아니라 상황에 맞는 디자인을 선택하는 기준도 학습하도록 유도할 수 있다.

생성된 슬라이드를 실제로 렌더링한 뒤 검사

Palette의 핵심은 모델이 생성한 결과를 그대로 반환하지 않는다는 점이다.

슬라이드를 실제로 렌더링한 뒤 오류를 검사한다.

예를 들어 제목과 본문이 겹치는지 확인할 수 있다.

텍스트가 슬라이드 밖으로 벗어나는지도 검사할 수 있다.

일부 글자의 색상이 배경과 너무 비슷한 상황도 확인할 수 있다.

문제가 발견되면 별도의 수정 모델이 해당 슬라이드의 코드를 다시 작성한다.

하지만 수정 결과를 무조건 적용하지는 않는다.

검사 결과 실제로 개선됐다고 판단되는 경우에만 새로운 코드를 채택한다.

이런 방식을 Check-and-Repair Harness(검사와 수정 기능을 가진 실행 구조)라고 할 수 있다.

Harness(하네스)는 AI 모델의 실행 과정과 외부 도구, 결과 검증을 연결하는 소프트웨어 계층이다.

연구팀은 131개 프레젠테이션을 대상으로 검사·수정 기능의 효과를 측정했다.

그 결과 평가 점수가 평균 3.5점 개선됐다고 밝혔다.

여러 슬라이드를 병렬로 생성

이번 구조의 또 다른 장점은 슬라이드를 병렬로 생성할 수 있다는 점이다.

먼저 디자이너가 전체 슬라이드의 구조를 결정한다.

이후 각 슬라이드의 명세가 독립적으로 제공된다.

따라서 코더는 여러 슬라이드를 동시에 생성할 수 있다.

연구팀은 이 방식으로 슬라이드 코드 생성 단계가 약 6~7배 빨라졌다고 설명했다.

다만 이 수치는 전체 프레젠테이션 생성 시간이 6~7배 빨라졌다는 의미는 아니다.

전체 과정에는 기획과 코드 생성, 실제 렌더링과 오류 수정에 필요한 시간도 포함된다.

공개 평가에서의 결과와 한계

연구팀은 PresentBench라는 프레젠테이션 평가를 사용했다.

Palette는 경제와 교육 분야에서 비교 시스템 가운데 가장 높은 점수를 기록했다.

발표 중심의 프레젠테이션 분야에서는 세 번째였다.

세 분야 평균 점수는 59.7점이었다.

비교 대상인 NotebookLM은 60.8점을 기록했다.

다만 이번 실험에서는 원본 자료에서 슬라이드 기획안을 만드는 과정에 별도의 강력한 모델을 사용했다.

따라서 20B 모델 하나만으로 모든 과정을 독립적으로 수행한 결과와는 구분해야 한다.

또한 PresentBench는 프레젠테이션의 일반적인 완성도를 평가하지만 특정 기업의 디자인 규칙을 얼마나 정확하게 따르는지 직접 측정하는 벤치마크는 아니다.

이번 글은 AI가 만든 결과물을 실제 업무에 활용하려면 모델의 생성 능력과 프로그램으로 검증 가능한 결과를 결합하는 방식이 중요하다는 점을 구체적인 구현 사례로 보여준다.

---

StateBench: Testing how language models track state changes over long documents

• 저자: Allen Institute for AI 연구진 / Kyle Wiggers
• 발행: Allen Institute for AI(Ai2) / Hugging Face
• 게시일: 2026-11-03
• 원문: Hugging Face — StateBench: Testing how language models track state changes over long documents

---

언어모델이 매우 긴 문서를 읽을 수 있다면 문서 안에서 계속 변하는 정보도 정확하게 추적할 수 있을까?

예를 들어 사용자가 AI 코딩 에이전트에게 여러 파일에 걸친 코드의 동작을 분석하도록 요청했다고 가정해 보자.

처음에는 특정 변수에 10이라는 값이 저장돼 있을 수 있다.

이후 프로그램이 실행되면서 해당 변수가 20으로 변경될 수 있다.

다른 함수에서는 이 값을 다시 변경할 수도 있다.

이 경우 실제로 중요한 것은 변수에 관한 설명을 많이 기억하는 능력이 아니다.

여러 변경사항을 순서대로 반영해 최종 상태를 정확하게 계산하는 능력이다.

Allen Institute for AI(Ai2)가 공개한 StateBench는 이런 문제를 평가하기 위한 새로운 벤치마크다.

네 가지 상태 추적 난이도

StateBench는 상태 추적 문제를 네 단계로 구분한다.

첫 번째는 거의 변하지 않는 정보다.

예를 들어 사람의 생년월일처럼 한 번 정해진 값을 계속 참고하는 상황이다.

두 번째는 새로운 값이 이전 값을 대체하는 상황이다.

예를 들어 회의 시작 시각이 오후 2시에서 오후 3시로 변경됐다면 가장 최근의 값이 중요하다.

세 번째는 이전 상태를 바탕으로 새로운 상태를 계산하는 상황이다.

예를 들어 게임 점수에 5점을 더하는 작업이 반복될 수 있다.

네 번째는 여러 정보의 상태가 서로 연결되는 상황이다.

예를 들어 물건을 A에게서 B에게 전달한 뒤 다시 다른 사람이 가져가는 과정을 추적해야 할 수 있다.

이런 작업에서는 한 번의 변경사항을 놓치면 최종 결과가 완전히 달라질 수 있다.

강력한 모델도 긴 상태 변경에 취약

연구팀은 Gemini 3.8 Flash와 Claude Opus 5.5, GPT-6 Sol과 Luna를 평가했다.

비교적 단순한 상태 추적에서는 높은 정확도를 기록했다.

하지만 여러 변수의 상태가 서로 연결되는 복잡한 문제에서는 입력이 길어질수록 성능이 크게 감소했다.

가장 긴 고난도 문제에서 최고 수준 모델들의 정확도는 13% 이하로 떨어졌다.

이는 모델이 긴 문서를 읽을 수 있다는 사실만으로 문서 안의 모든 상태 변경을 정확하게 처리할 수는 없다는 의미다.

예를 들어 모델이 수만 토큰의 문서를 처리할 수 있더라도 중간에 발생한 중요한 변경사항 하나를 놓칠 수 있다.

이 경우 최종 답변이 그럴듯하더라도 실제 값은 잘못될 수 있다.

다만 이번 결과는 연구팀이 설계한 상태 추적 작업에서 얻어진 수치다.

모든 긴 문서 요약이나 코딩 작업의 정확도가 13% 이하라는 의미는 아니다.

Transformer와 순환 상태 모델의 차이

연구팀은 모델의 구조에 따라 성능이 달라지는지도 조사했다.

Transformer(트랜스포머)는 입력의 서로 다른 위치 사이의 관계를 Attention으로 계산하는 신경망 구조다.

반면 Recurrent Architecture(순환 구조)는 이전 입력의 정보를 내부 상태에 계속 반영하면서 새로운 정보를 처리한다.

Ai2는 Gated DeltaNet이라는 순환 상태 구조를 사용한 모델도 평가했다.

연구팀은 여러 종류의 모델을 같은 상태 추적 데이터로 직접 학습시켰다.

학습에는 최대 256개의 상태 변경으로 구성된 문제를 사용했다.

이후 최대 6만4천 개의 상태 변경으로 구성된 문제까지 평가했다.

학습에서 본 가장 긴 문제보다 250배 긴 입력을 시험한 것이다.

Gated DeltaNet과 일부 하이브리드 모델은 상대적으로 단순한 세 단계에서 긴 입력에 대해서도 높은 정확도를 유지했다.

반면 일반적인 Transformer는 입력이 길어질수록 성능이 감소했다.

가장 어려운 상태 추적에서는 유연한 메모리 업데이트를 지원하는 Gated DeltaNet 모델이 학습 길이의 약 열 배까지 높은 정확도를 유지했다.

다만 이러한 결과는 특정한 상태 추적 문제에 맞춰 직접 학습한 작은 모델에서 얻어졌다.

실제 모든 업무에서 순환 구조가 Transformer보다 뛰어나다는 의미는 아니다.

AI 에이전트의 긴 작업에서 발생할 수 있는 문제

이번 연구는 실제 AI 에이전트의 긴 작업과 연결된다.

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

처음에는 특정한 파일의 내용을 읽는다.

이후 파일을 수정하고 테스트를 실행한다.

그 과정에서 작업의 상태가 여러 번 변경된다.

모델이 이전의 변경사항을 정확하게 추적하지 못하면 이미 수정한 파일을 다시 수정하거나 오래된 정보를 바탕으로 잘못된 결정을 내릴 수 있다.

따라서 긴 컨텍스트를 지원하는 모델을 사용하더라도 실제 작업의 상태를 외부 프로그램에 저장하고 필요할 때 확인하는 구조가 유용할 수 있다.

이번 글은 긴 문맥을 처리할 수 있는 능력과 시간에 따라 변하는 상태를 정확하게 관리하는 능력이 서로 다르다는 점을 구체적인 실험으로 보여준다.

---

Agentic cheminformatics with Google Antigravity

• 저자: Zoi Tsangalidou, Ruijie (Kelly) Zhang, Sukhdeep Singh, Michael V. LeVine
• 발행: Google DeepMind
• 게시일: 2026-11-03
• 원문: Google DeepMind — Agentic cheminformatics with Google Antigravity

---

AI 에이전트가 실제 신약개발 연구를 지원하려면 어떤 기능이 필요할까?

일반적인 언어모델은 화학과 생물학에 관한 질문에 답할 수 있다.

하지만 새로운 약물 후보를 연구하는 작업에는 여러 단계가 필요하다.

기존 논문과 특허를 조사해야 한다.

실제 분자의 구조를 확인해야 한다.

특정한 구조 변화가 약물의 활성에 어떤 영향을 주는지 분석해야 한다.

마지막으로 새로운 약물 후보를 제안하고 실제로 합성할 수 있는지 검토해야 한다.

Google DeepMind는 이번 글에서 Google Antigravity와 전문적인 화학정보학 도구를 연결한 에이전트 시스템을 소개했다.

Cheminformatics(화학정보학)는 화학물질의 구조와 성질, 반응에 관한 데이터를 컴퓨터로 분석하는 분야다.

이번 사례는 AI가 과학 지식을 설명하는 것에서 더 나아가 실제 연구의 여러 단계를 연결하는 방법을 보여준다.

실제 폐암 치료제의 분자 구조 비교

연구팀은 실제 비소세포폐암 치료에 사용되는 Crizotinib과 Lorlatinib을 사례로 선택했다.

두 약물은 관련된 생물학적 표적을 다루지만 분자의 구조가 다르다.

예를 들어 어떤 분자는 여러 결합을 중심으로 자유롭게 회전할 수 있다.

이런 경우 분자가 여러 3차원 형태를 가질 수 있다.

하지만 실제 표적 단백질에 결합하려면 특정한 형태를 취해야 할 수 있다.

분자의 구조를 더 단단하게 만들면 원하는 형태를 유지하기 쉬워질 수 있다.

이를 Rigidification(분자의 구조적 강직화)이라고 한다.

예를 들어 두 부분을 새로운 결합으로 연결해 고리 구조를 만들 수 있다.

이렇게 하면 회전할 수 있는 결합의 수가 감소한다.

이번 연구에서는 이런 변화가 약물의 활성에 어떤 영향을 주는지 분석했다.

다만 분자를 단단하게 만드는 것이 항상 더 좋은 약물을 만든다는 의미는 아니다.

실제 약물의 성능에는 표적과의 결합뿐 아니라 독성과 체내 분포, 대사와 배설 등 여러 요인이 영향을 준다.

논문과 데이터베이스에서 수천 개 분자 검색

Google의 에이전트는 관련 논문과 데이터베이스를 조사했다.

여기에는 PubChem과 ChEMBL이 사용됐다.

PubChem은 화학물질의 구조와 특성 등에 관한 공개 데이터베이스다.

ChEMBL은 생물학적 활성이 알려진 여러 화합물과 관련 실험 자료를 제공하는 데이터베이스다.

에이전트는 수천 개의 화합물 정보를 검색했다.

이후 분석에 필요하지 않은 물질을 제외하고 실제 비교에 사용할 자료를 정리했다.

Google이 공개한 예시에서는 568개 화합물에 관한 분석 결과를 시각화했다.

이 과정에서는 같은 분자가 서로 다른 이름이나 구조 표현으로 등장할 수 있다.

예를 들어 어떤 논문에는 분자의 화학식이 포함돼 있을 수 있다.

다른 자료에는 그림이나 특정한 명명 규칙에 따른 이름이 사용될 수 있다.

AI는 이런 정보를 연결해야 하지만 실제 분자의 구조를 정확하게 계산하는 작업까지 자연어 모델의 추론에만 맡기는 것은 위험할 수 있다.

언어모델과 화학 계산 도구의 역할 분리

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

RDKit은 분자의 구조와 화학적 특성을 계산하는 오픈소스 라이브러리다.

예를 들어 분자에 포함된 원자와 결합, 회전 가능한 결합의 수를 계산할 수 있다.

이번 시스템에서는 언어모델이 문헌 검색과 연구 절차의 계획, 분석 결과의 해석을 담당한다.

반면 실제 분자 구조의 계산은 RDKit 같은 전문 프로그램에 맡긴다.

이런 방식을 통해 언어모델의 유연한 추론 능력과 전문 프로그램의 재현 가능한 계산을 결합한다.

이는 다른 과학 분야에서도 적용할 수 있는 구조다.

예를 들어 물리학에서는 수치 시뮬레이터를 사용할 수 있다.

생물학에서는 유전체 분석 프로그램을 연결할 수 있다.

일반적인 웹 개발에서도 모델이 모든 계산을 직접 수행하도록 하기보다 검증 가능한 프로그램을 사용하는 방식이 유용할 수 있다.

기존 분자의 작은 변화를 비교하는 분석

연구팀은 MMPA(Matched Molecular Pair Analysis)도 수행했다.

MMPA는 구조가 거의 같지만 특정한 부분만 다른 두 분자를 비교하는 분석 방법이다.

예를 들어 두 분자가 거의 같은 구조를 가지고 있지만 하나는 고리 구조를 추가했다고 가정해 보자.

두 분자의 생물학적 활성을 비교하면 해당 구조 변화가 어떤 영향을 주는지 추정할 수 있다.

Google의 에이전트는 여러 분자 쌍을 비교해 고리화가 회전 가능한 결합의 수를 줄이고 활성에 어떤 영향을 주는지 분석했다.

또한 화합물의 특성과 활성을 예측하는 머신러닝 모델도 생성했다.

하지만 이런 예측은 실제 실험으로 검증한 결과와 다르다.

예를 들어 모델이 특정한 분자가 높은 약물 활성을 가질 것으로 예측했더라도 실제로 합성하고 실험해야 확인할 수 있다.

또한 합성할 수 있는 경로가 존재한다는 사실만으로 실제 제조가 쉽거나 안전하다는 의미도 아니다.

수일 걸리는 연구 절차를 약 1시간으로 시연

Google은 기존에 수일 걸릴 수 있는 자료 정리와 비교 분석, 후보 제안 과정을 약 1시간에 수행하는 시연을 공개했다.

하지만 이는 특정한 연구 사례에서 제시한 작업 시간이다.

모든 신약개발 연구가 같은 수준으로 빨라진다는 의미는 아니다.

특히 실제 약물의 합성과 실험, 임상시험에 필요한 시간까지 포함한 결과는 아니다.

이번 연구의 중요한 점은 약물 후보를 최종적으로 발견했다는 사실보다 여러 종류의 공개 연구자료와 전문적인 계산 도구를 하나의 에이전트 작업 흐름으로 연결했다는 점이다.

이번 글은 과학 분야의 AI 에이전트를 이해할 때 모델의 전문 지식뿐 아니라 정확한 데이터 검색과 검증 가능한 계산, 실제 실험으로 이어지는 작업 구조가 중요하다는 점을 구체적으로 설명한다.