AI 데일리 브리핑 — 2026-10-07
Soshy·
기준 시점: 2026-10-07 06:00 KST (Asia/Seoul)
AI 동향 조사 범위: 2026-10-06 06:00 ~ 2026-10-07 06:00 KST
추천 글 범위: 2026-09-30 06:00 ~ 2026-10-07 06:00 KST
1️⃣ 주요 모델·연구
Google DeepMind, 740M 멀티모달 임베딩 모델 ‘EmbeddingGemma 2’ 공개…텍스트·이미지·영상·음성을 하나의 벡터 공간으로
- 발표일: 2026-10-06 — 정확한 게시 시각 미확인
- 적용 범위: 멀티모달 AI, 임베딩 모델, 온디바이스 AI, 검색·RAG, 이미지·영상 검색, 로컬 AI
- 원문: Google — Bring multimodal semantic search to the edge with EmbeddingGemma 2
Google DeepMind가 EmbeddingGemma 2를 공개했다. 7억4천만 개 파라미터를 가진 오픈웨이트 임베딩 모델로, 텍스트뿐 아니라 이미지, 영상 프레임과 음성을 하나의 공통 벡터 공간으로 변환한다.
Embedding(임베딩) 은 문장이나 이미지 같은 데이터를 의미를 나타내는 숫자 벡터로 바꾸는 기술이다. 의미가 비슷한 데이터는 벡터 공간에서도 가까운 위치에 놓이기 때문에 검색, 추천, RAG(Retrieval-Augmented Generation, 관련 정보를 검색해 생성 모델에 제공하는 방식) 등에 널리 사용된다.
기존 임베딩 모델은 텍스트 전용인 경우가 많았고 멀티모달 검색을 만들려면 이미지와 텍스트를 각각 다른 모델로 처리하거나 이미지를 먼저 텍스트 설명으로 변환해야 했다.
EmbeddingGemma 2는 텍스트, 이미지, 영상 프레임, 음성을 같은 공간에 매핑하기 때문에 예를 들어 텍스트로 사진을 검색하거나, 이미지와 의미가 비슷한 문서를 찾고, 영상 속 특정 장면을 자연어로 검색하는 기능을 하나의 모델로 만들 수 있다.
Google은 특히 클라우드 API가 아니라 스마트폰과 노트북에서 직접 실행하는 온디바이스 사용을 핵심 목표로 두고 모델을 설계했다.
모델 내부는 modality별 encoder를 필요할 때 선택적으로 사용하는 구조다. 텍스트 기능만 사용하는 경우 활성 메모리는 약 191MB, 전체 멀티모달 모델을 Pixel 11 Pro에서 사용하는 경우 약 567MB라고 Google은 설명한다.
양자화도 적용됐다. Quantization(양자화) 은 모델이 사용하는 숫자의 정밀도를 낮춰 메모리와 연산량을 줄이는 방식이다. EmbeddingGemma 2는 INT4·INT8 Quantization-Aware Training을 지원하고, 임베딩 크기도 필요에 따라 줄일 수 있다.
이를 위해 MRL(Matryoshka Representation Learning) 이 사용됐다. 하나의 768차원 임베딩을 그대로 사용하거나 512, 256, 128차원처럼 앞부분만 잘라 사용해도 의미 정보를 최대한 유지하도록 학습하는 방식이다. 저장공간이 중요한 모바일 환경에서는 벡터 인덱스의 크기를 최대 약 8분의 1까지 줄일 수 있다.
Google이 공개한 MacBook M5 Pro GPU 테스트에서는 이미지 임베딩 하나를 만드는 데 최소 37.3ms, 초당 약 26.9장의 이미지를 처리했다. 이 수치는 Google이 특정 하드웨어와 자체 환경에서 측정한 결과이므로 다른 기기의 실제 성능과 동일하다고 볼 수는 없다.
EmbeddingGemma 2는 검색 모델을 넘어 작은 로컬 의사결정 엔진으로도 사용할 수 있다.
예를 들어 사용자의 요청과 미리 준비한 여러 행동 설명을 각각 임베딩하고 가장 가까운 항목을 선택하면, 생성형 LLM을 실행하지 않고도 “이 요청에는 어떤 기능을 실행해야 하는가”를 판단할 수 있다.
Google은 MediaPipe의 새로운 Decision Task에서 이 방식을 이용해 최대 500개 후보 가운데 행동을 선택하는 작업을 100ms 미만에 수행할 수 있다고 설명한다. 별도의 fine-tuning 없이 새로운 분류 항목을 추가할 수 있다는 점도 특징이다.
Google AI Edge Gallery에는 이 모델을 활용한 Instant Media Search와 Video Moments Finder가 추가됐다. 자연어를 입력해 스마트폰 속 이미지와 영상의 특정 장면을 로컬에서 검색할 수 있다.
Mac용 실험 프로젝트 Google AI Edge Foresight도 공개됐다. 회의 내용과 개인 파일을 로컬에서 임베딩하고 Gemma 4와 연결해 회의 기록을 검색하거나 과거 논의를 다시 찾는 개인용 회의 도우미다. 데이터가 외부 서버로 전송되지 않는 구조를 전면에 내세운다.
최근 멀티모달 AI 경쟁은 거대한 생성 모델뿐 아니라 로컬 환경에서 개인 데이터 전체를 의미 기반으로 검색하고 작은 의사결정을 빠르게 수행하는 경량 모델 쪽으로도 확장되고 있다. EmbeddingGemma 2는 생성 자체보다 검색과 정보 연결에 집중하면서 스마트폰 안에서 동작할 수 있도록 만든 모델이라는 점에서 이 흐름을 잘 보여준다.
OpenAI·Ironclad, 전문 소프트웨어를 직접 사용하는 에이전트 학습법 공개…Astra가 계약 업무에서 Sol 대비 32% 높은 점수
- 발표일: 2026-10-06 — 정확한 게시 시각 미확인
- 적용 범위: 컴퓨터 사용 에이전트, 전문 업무 소프트웨어, 강화학습, 계약·법무·조달 업무, 에이전트 평가
- 원문: OpenAI — Advancing computer use with Ironclad
OpenAI가 계약 관리 소프트웨어 기업 Ironclad와 진행한 연구를 공개했다. 연구의 목적은 단순히 웹사이트 버튼을 클릭하는 수준을 넘어 기업의 업무 규칙을 이해하고 전문 소프트웨어 안에서 수십 단계의 작업을 완료하는 에이전트를 훈련하는 것이다.
컴퓨터 사용 에이전트를 평가할 때 흔히 사용하는 작업은 폼에 값을 입력하거나 파일을 내려받는 것처럼 성공 여부가 비교적 명확하다.
하지만 실제 기업 업무에서는 상황이 훨씬 복잡하다.
예를 들어 회사가 소프트웨어를 구매하려면 일정 금액 이상은 재무팀의 승인을 받고, 보안 검토가 필요한 제품은 보안팀을 거치고, 표준 계약과 다른 조항이 있으면 법무팀 승인을 받아야 할 수 있다.
AI 에이전트가 이 업무를 수행하려면 버튼을 제대로 클릭하는 것만으로는 부족하다. 처음에 주어진 여러 규칙을 기억하면서 각각의 예외 상황에 맞는 승인 흐름을 만들고, 마지막에는 전체 프로세스가 원래 요구사항과 일치하는지 검증해야 한다.
OpenAI와 Ironclad는 법무·상업·조달 분야에서 11개의 실제 업무 형태를 연구 과제로 만들었다.
여기에는 NDA 설정, 구매 승인 프로세스 구성, 요청자가 선택한 관할 지역에 따라 서로 다른 법률 조항을 적용하는 재사용 가능한 계약 조항 작성 등이 포함된다.
OpenAI는 숙련된 사람이 직접 수행하면 각 작업에 평균 약 30~40분이 걸릴 것으로 추정했다.
단순 성공·실패 대신 작업별로 8~50개의 세부 평가 기준을 만들었다. 에이전트가 최종 결과 일부만 맞혀도 어느 단계에서 실패했는지 확인할 수 있도록 한 것이다.
Ironclad는 실제 제품과 유사한 별도의 hosted software environment를 제공했고, OpenAI는 이 환경에서 모델이 반복적으로 연습할 수 있도록 synthetic training task를 만들었다.
여기서 synthetic data(합성 데이터) 는 실제 고객의 업무 기록을 그대로 사용하는 대신 비슷한 형태의 가상 사례를 생성한 학습 자료를 뜻한다.
OpenAI는 미국 SEC EDGAR에 공개된 계약서를 이용해 시뮬레이션 작업을 만들었으며 개인 정보를 제거하기 위한 필터를 적용했다고 설명한다. OpenAI 고객 데이터, OpenAI 내부 계약, 비공개 Ironclad 고객 계약은 학습이나 평가에 사용하지 않았다고 밝혔다.
이 환경을 기반으로 Reinforcement Learning(RL, 작업 결과에 대한 보상을 이용해 행동 전략을 개선하는 강화학습) 을 진행했다.
GPT-6 Astra는 Ironclad 작업으로 학습된 첫 프런티어 모델이다.
OpenAI 자체 연구 평가에서 GPT-5.6 Sol은 평균 41.6%, GPT-6 Astra는 55.0% 의 평가 기준을 충족했다. 상대적으로 약 32% 높은 결과다.
Astra 개발 과정의 내부 모델은 63.7%까지 기록했다.
한 번의 작업을 완료하는 데 걸리는 추정 시간도 Sol의 평균 37.0분에서 Astra 19.2분으로 약 48% 줄었다.
다만 이 시간은 실제 사람이 옆에서 측정한 작업 시간이 아니다. OpenAI가 모델의 처리·생성 속도를 가정해 계산한 시뮬레이션 추정치이며, 평가 대상도 Ironclad 전체 업무가 아니라 11개의 연구용 작업에 한정된다.
이번 연구에서 눈에 띄는 부분은 모델 회사가 공개 웹이나 코드 환경에서만 에이전트를 학습시키는 대신 전문 업무 소프트웨어를 만드는 기업과 함께 평가 기준과 연습 환경 자체를 구축한다는 점이다.
OpenAI는 Ironclad를 시작으로 실제 전문 업무를 가진 소프트웨어 업체들과 비슷한 연구를 확대할 계획이며, 복잡한 workflow와 성공 기준, 안전한 테스트 환경을 제공할 수 있는 업체의 연구 참여 신청도 받고 있다.
프런티어 모델의 경쟁이 일반적인 reasoning benchmark를 넘어 SAP, Salesforce, 계약 관리, 설계 도구처럼 사람이 실제 업무에 사용하는 전문 프로그램을 얼마나 정확하게 다룰 수 있는가로 이동하면서, 모델 학습 데이터 자체도 문서와 코드에서 실제 업무 환경으로 확장되고 있다는 흐름을 보여준다.
2️⃣ AI 제품·서비스
Atlassian·OpenAI 파트너십 확대…GPT-6 계열을 Rovo와 Teamwork Graph에 연결
- 발표일: 2026-10-06 — 정확한 게시 시각 미확인
- 적용 범위: Jira, Confluence, Rovo, ChatGPT, Codex, 기업용 AI 에이전트, 조직 지식 검색
- 원문: OpenAI — Atlassian and OpenAI expand partnership to turn enterprise knowledge into action
Atlassian과 OpenAI가 기존 협력을 확대해 GPT-6 계열 프런티어 모델을 Atlassian 플랫폼과 Rovo의 에이전트에 폭넓게 적용한다고 발표했다.
Atlassian의 Rovo는 회사 내부의 Jira 티켓, Confluence 문서, 프로젝트와 사람 정보를 AI가 검색하고 활용할 수 있도록 하는 기업용 AI 서비스다.
여기서 핵심 역할을 하는 것이 Teamwork Graph다.
Teamwork Graph는 단순한 문서 검색 인덱스가 아니라 사람, 프로젝트, 문서, 업무 항목과 의사결정 사이의 관계를 연결한 조직 context layer다.
예를 들어 제품 관리자가 “다음 주 출시에 문제가 없는가?”라고 질문하면 Rovo가 관련 Jira 작업, Confluence 문서와 대화를 연결해 아직 해결되지 않은 개발 blocker나 놓친 milestone, 확인이 필요한 의사결정을 찾아내는 식이다.
이번 계약을 통해 Atlassian은 GPT-6 Astra와 GPT-5.6 계열을 포함한 OpenAI 최신 프런티어 모델에 대한 접근을 확대하고 Rovo 안에서 새로운 reasoning 기능을 적용할 수 있게 된다.
연결 방향은 반대쪽으로도 이어진다.
Atlassian과 Teamwork Graph용 CLI plugin을 이용하면 ChatGPT와 Codex가 사용자의 기존 Jira·Confluence 프로젝트 정보를 가져와 작업할 수 있다. 데이터 접근은 해당 사용자가 원래 가지고 있던 권한의 범위 안에서 이뤄진다.
Atlassian은 최근 Jira work item, Confluence 문서와 사람 정보를 ChatGPT·Codex 프롬프트에 직접 불러오는 plugin extension도 추가했으며, Atlassian Home을 통해 자신에게 할당된 작업과 최근 Loom 영상, 프로젝트, Bitbucket PR 등을 확인할 수 있도록 했다.
Atlassian 내부의 AI 사용도 확대되고 있다.
회사에 따르면 3,000명이 넘는 Atlassian 개발자가 Codex를 터미널, IDE와 코드 리뷰 workflow에서 사용하고 있다. 개발자가 Codex에서 현재 작업과 관련된 Jira 항목이나 기술 문서를 직접 가져와 코드를 작성하고 테스트하는 형태다.
두 회사는 앞으로 Jira 업무를 AI 에이전트에게 직접 할당하고, 진행 상태와 AI가 내린 결정을 기록하고, 사람이 결과를 검토하는 더 깊은 통합도 연구하고 있다.
다만 이 부분은 향후 개발 방향이며 현재 모든 고객에게 제공되는 기능이라고 보면 안 된다.
최근 기업용 AI의 핵심 문제 중 하나는 모델의 성능보다 “우리 회사에서 지금 진행 중인 일을 AI가 얼마나 정확하게 알고 있는가”다.
범용 LLM이 아무리 강해도 프로젝트 상태, 내부 문서, 담당자와 최근 결정 내용을 모르면 실제 업무를 대신하기 어렵다.
이번 파트너십은 모델 회사와 업무 소프트웨어 업체가 각각 추론 능력과 조직 context를 결합해 에이전트를 실제 업무 시스템 안으로 넣는 방식을 선택하고 있다는 점에서 기업용 AI 시장의 방향을 보여준다.
3️⃣ 개발 도구·에이전트
Mysten Labs·Google Cloud, AI 에이전트 행동을 사후 검증하는 ‘Verifiable Agent Arbiter’ 공개
- 발표일: 2026-10-06 — 정확한 게시 시각 미확인
- 적용 범위: AI 에이전트 감사, Agent-to-Agent, 금융·상거래 에이전트, 암호학적 증명, 기업 AI 거버넌스
- 원문: Mysten Labs — Verifiable Agent Arbiter
Mysten Labs가 Google Cloud와 함께 AI 에이전트가 사용자로부터 받은 권한 안에서 행동했다는 사실을 나중에 독립적으로 검증하기 위한 시스템 VAA(Verifiable Agent Arbiter) 를 공개했다.
AI 에이전트가 문서를 작성하는 정도라면 결과를 사람이 직접 읽어볼 수 있지만, 앞으로 에이전트가 기업 간 주문을 체결하거나 API 사용료를 지불하고 다른 회사의 에이전트와 협상하기 시작하면 문제가 달라진다.
예를 들어 한 에이전트가 1만 달러까지 구매할 권한을 받았는데 1만5천 달러를 결제했다면 단순한 애플리케이션 로그만으로는 거래 당사자와 감사기관이 “실제로 어떤 권한이 주어졌고 에이전트가 어떤 판단을 했는가”를 독립적으로 확인하기 어렵다.
VAA는 이 문제를 위한 evidence layer, 즉 에이전트 행동의 증거 계층을 만드는 시스템이다.
프롬프트, 모델 출력, tool call, 정책 판단 같은 상세 telemetry 자체는 고객이 관리하는 Google Cloud Storage 안에 비공개 상태로 유지한다.
대신 해당 기록이 특정 시점에 존재했고 이후 바뀌지 않았음을 확인할 수 있는 암호학적 증명을 만들어 Mysten Labs의 Walrus 분산 스토리지와 Sui 네트워크에 기록한다.
따라서 원본 대화를 공개하지 않고도 “이 행동 기록이 사후에 조작되지 않았다”는 사실을 외부 당사자가 검증할 수 있도록 설계됐다.
예를 들어 서로 다른 회사의 AI 에이전트가 Agent2Agent(A2A) 프로토콜을 통해 거래했는데 나중에 분쟁이 생기면 각 회사가 자체 로그만 제시하는 대신 당시의 승인 범위와 실행 결과를 공통 증거를 이용해 다시 확인할 수 있다.
A2A(Agent2Agent) 는 서로 다른 AI 에이전트가 능력을 공개하고 작업을 주고받도록 Google이 시작한 개방형 프로토콜이며 현재 Linux Foundation 산하에서 관리되고 있다.
에이전트 결제에도 같은 구조를 적용한다.
VAA는 Sui Agent Payments와 연결돼 에이전트가 x402 프로토콜을 이용해 API나 서비스 비용을 자동으로 지급했을 때 어떤 권한으로 얼마를 지출했고 실제 서비스가 제공됐는지를 증거로 남길 수 있다.
x402는 HTTP의 402 Payment Required 상태 코드를 활용해 소프트웨어나 AI 에이전트가 요청 시점에 서비스 사용료를 지불하도록 만드는 결제 규격이다.
장기 보존도 고려한다. 현재 사용한 암호기술이 미래에 약해지면 과거의 원본 기록과 연결 관계를 유지하면서 새로운 암호 방식, 장기적으로는 post-quantum 방식으로 증명을 다시 생성할 수 있도록 설계됐다고 Mysten Labs는 설명한다.
다만 VAA는 지금 당장 누구나 사용할 수 있는 완성된 범용 서비스는 아니다.
현재 Google Cloud와 공동 개발 중이며 기업 고객을 대상으로 초기 배포를 진행한 뒤 더 넓은 공개를 계획하고 있다.
AI 에이전트 보안은 지금까지 실행 전에 무엇을 허용할 것인지 정하는 permission과 guardrail에 많이 집중돼 왔다.
VAA는 여기에 실행이 끝난 뒤 “에이전트에게 무엇이 허용됐고 실제로 무엇을 했는가”를 제3자도 검증할 수 있는 감사 계층을 추가하려는 접근이다. 에이전트가 회사 경계를 넘어 계약이나 결제를 하기 시작하면 이런 사후 증명 구조의 중요성도 커질 가능성이 있다.
NVIDIA, GPU Kubernetes 구성을 재현·검증하는 오픈 프로젝트 ‘AICR 1.0’ 공개
- 발표일: 2026-10-06 — 정확한 게시 시각 미확인
- 적용 범위: AI 인프라, GPU 클러스터, Kubernetes, GitOps, 모델 학습·추론 인프라, 공급망 검증
- 원문: NVIDIA — AICR v1.0: Open, stable, and verifiable GPU cluster configuration
NVIDIA가 AICR(NVIDIA AI Cluster Runtime) 1.0을 공개했다. GPU 기반 Kubernetes 클러스터를 구성할 때 서로 호환되는 소프트웨어 버전 조합을 기록하고, 같은 환경을 재현하고, 실제 클러스터가 그 구성과 일치하는지 검증하는 오픈 프로젝트다.
대규모 AI 모델을 Kubernetes에서 운영할 때 GPU만 설치한다고 끝나는 것이 아니다.
Linux kernel, NVIDIA driver, container runtime, Kubernetes, networking, storage, device plugin, scheduler와 모델 serving framework까지 수많은 구성요소의 버전이 맞아야 한다.
각 프로젝트가 서로 다른 주기로 업데이트되기 때문에 드라이버 하나만 바꿔도 잘 작동하던 클러스터가 깨질 수 있다.
AICR는 이 문제를 version-locked recipe로 해결한다.
Recipe에는 특정 GPU와 운영체제, Kubernetes 서비스, workload 종류에서 함께 검증된 구성요소 버전이 기록된다.
예를 들어 EKS + GB300 + Ubuntu + training + Kubeflow처럼 원하는 환경을 선택하면 이에 맞는 recipe를 찾고, 이를 Helm, Argo CD, Flux, Helmfile 같은 기존 배포 도구에서 사용할 수 있는 bundle로 변환한다.
AICR는 네 기능을 명확히 분리한다.
Snapshot은 현재 실행 중인 클러스터의 Kubernetes 버전, 운영체제, kernel, GPU와 topology를 기록한다.
Recipe는 원하는 목표 구성을 정의한다.
Bundle은 해당 recipe를 실제 배포 도구에서 사용할 수 있는 파일로 변환한다.
마지막 Validation은 현재 클러스터 상태와 recipe가 일치하는지 확인하고 필요하면 기능·성능 테스트까지 실행한다.
여기서 중요한 것은 AICR 자체가 Kubernetes 배포 시스템을 새로 만들지 않는다는 점이다.
실제 변경은 Helm이나 Argo CD 같은 기존 GitOps 도구가 담당하고 AICR는 “어떤 구성이 검증됐는가”와 “실제로 그 구성대로 실행되고 있는가” 를 관리한다.
검증 결과에는 디지털 서명을 넣은 evidence를 생성할 수 있다.
운영자는 공개 dashboard에서 특정 recipe가 어떤 하드웨어에서 어떤 검사를 통과했으며 누가 결과에 서명했는지를 확인할 수 있다.
AICR 1.0은 CLI뿐 아니라 REST API, Go SDK, bundle layout과 artifact schema에 v1.x compatibility contract를 도입했다. 향후 1.x 버전 안에서는 공개 인터페이스를 임의로 깨지 않겠다는 안정성 규칙이다.
현재 coverage에는 11개 Kubernetes 서비스, Rubin·Blackwell·Hopper·Ampere·Ada 세대에 걸친 10종의 NVIDIA GPU accelerator, Ubuntu·COS·Oracle Linux 등의 운영체제가 포함된다.
학습 환경에서는 Kubeflow와 Slurm, 추론에서는 NVIDIA Dynamo와 NIM을 지원한다.
NVIDIA에 따르면 프로젝트에는 현재 100명 이상의 contributor가 참여하고 있으며 거의 절반이 NVIDIA 외부 개발자다. Pulumi Labs는 AICR를 Infrastructure-as-Code provider로 연결했고 Mirantis의 k0rdent는 multi-cluster 관리에 통합하고 있다.
생성형 AI 인프라가 커질수록 단순히 GPU 대수를 늘리는 문제보다 수백·수천 대 GPU가 동일하고 검증된 소프트웨어 조합으로 동작하도록 만드는 재현성이 중요해진다.
AICR는 AI 인프라 운영에서 Docker image처럼 애플리케이션만 고정하는 것을 넘어 GPU driver와 Kubernetes 주변 시스템까지 검증 가능한 구성으로 버전 관리하려는 흐름을 보여주는 사례다.
4️⃣ 산업·정책·안전
Anthropic, 보안 전문가용 Claude 제한 완화 프로그램 확대…방어·레드팀·핵심 인프라 3단계로 분리
- 발표일: 2026-10-06 — 정확한 게시 시각 미확인
- 적용 범위: AI 사이버보안, Claude, 취약점 연구, 레드팀, 핵심 인프라, 모델 안전장치
- 원문: Anthropic — Expanding the Cyber Verification Program
Anthropic이 보안 전문가에게 일반 사용자보다 더 강한 사이버 기능을 허용하는 Cyber Verification Program(CVP) 을 대폭 확대했다.
프런티어 모델은 취약점 분석, malware reverse engineering과 exploit 연구 능력이 빠르게 좋아지고 있지만 같은 능력이 공격자에게도 사용될 수 있다.
이 때문에 Anthropic의 일반 Claude 모델에는 사이버 관련 요청을 보수적으로 차단하는 classifier가 적용된다.
문제는 실제 보안팀도 동일한 이유로 정상적인 보안 업무를 수행하지 못하는 false positive가 생긴다는 점이다.
Anthropic은 그동안 검증된 보안조직을 대상으로 CVP와 Project Glasswing이라는 별도 프로그램을 운영해왔고, 이번에 이를 하나의 구조로 통합하면서 접근 수준을 Defense, Red Team, Specialized 세 단계로 나눴다.
Defense Access는 SOC(Security Operations Center), incident response, malware reverse engineering, 취약점 분석·검증 같은 방어 업무를 대상으로 한다.
기업이나 정부뿐 아니라 대학, 비영리단체, 오픈소스 maintainer와 일정한 취약점 연구 이력을 가진 개인 연구자도 신청할 수 있다.
Red Team Access는 조직의 허가를 받은 penetration test와 red-team 업무를 위한 단계다.
일반 CVP보다 사이버 차단이 훨씬 적으며 ransomware나 물리 시스템·고위험 안전 시스템에 피해를 주는 것처럼 대규모 피해로 이어질 수 있는 행동 위주로 제한한다.
마지막 Specialized Access는 발전소, 통신망, 금융 결제망, 정부 행정망, 항공 시스템처럼 실제 핵심 인프라의 보안을 테스트할 권한이 있는 소수 조직을 대상으로 한다.
검증 과정도 가장 엄격하며 Anthropic은 미국 정부와 함께 신청 조직의 권한을 확인할 계획이라고 밝혔다.
세 단계 모두 Claude Opus 5.5, Sonnet 5.5, Mythos 5.1과 향후 추가되는 모델에 접근할 수 있다.
안전장치를 얼마나 줄였는지 확인하기 위한 평가도 공개했다.
Anthropic의 CyScenarioBench 10개 문제를 각각 다섯 번 실행했을 때 일반 공개 설정은 첫 요청부터 모든 작업을 차단했다.
Defense Access에서는 50번 가운데 46번이 어느 시점에선가 차단됐고 4번만 끝까지 성공했다.
Red Team Access에서는 safeguard가 작업을 차단한 경우가 없었고 Claude Opus 5.5가 50번 가운데 34번 문제를 완료했다. 이는 safeguard 자체를 제거한 상태의 성공률과 사실상 비슷한 수준이었다고 Anthropic은 설명한다.
그만큼 프로그램 가입자 검증과 사후 감시가 중요해진다.
CVP를 사용하는 조직은 Anthropic이 misuse를 감시할 수 있도록 데이터 보존에 동의해야 한다. 향후 고객 자신의 cloud 안에서 데이터를 유지하면서 안전 모니터링을 수행하는 Enterprise Frontier Safeguards도 제공할 예정이다.
Anthropic은 Project Glasswing에 참여한 조직들이 2026년 4월부터 7월 사이 최소 12만9천 개의 검증된 소프트웨어 취약점을 발견했다고 밝혔다.
Anthropic 자체의 오픈소스 스캔에서는 4월부터 10월까지 추가로 5,500개가 발견됐고, 이 가운데 전체 합산 3만3천 개 이상이 critical 또는 high severity로 평가됐다.
다만 12만9천이라는 숫자는 모든 참여 조직의 완전한 데이터를 집계한 것이 아니다. 일부 파트너가 설문에 응답해 제공한 결과이며 조직마다 취약점을 검증하고 집계하는 방식도 다를 수 있기 때문에 독립적인 전체 산업 통계처럼 해석하면 안 된다.
최근 AI 사이버 정책의 쟁점은 단순히 “위험한 기능을 차단할 것인가” 에서 벗어나고 있다.
강한 모델이 실제 공격 능력도 높이지만 동시에 보안팀에게 가장 유용한 방어 도구가 되면서, 이제 모델 제공업체는 사용자 신원과 권한을 검증하고 같은 모델의 안전 제한 수준을 사용자 유형에 따라 다르게 적용하는 접근을 실험하고 있다.
영국 정부, 의료 AI 규제위원회의 44개 권고 전부 수용…AI 의료기기를 ‘한 번 승인’에서 생애주기 감시 체계로 전환
- 발표일: 2026-10-06 — 정확한 게시 시각 미확인
- 적용 범위: 영국 AI 규제, 의료 AI, AI 의료기기, NHS, MHRA, 모델 업데이트·사후 감시
- 원문: GOV.UK — Government backs recommendations of NHS doctors-led AI Commission
- 관련 원문: GOV.UK — Government Response to the National Commission's Recommendations on the Regulation of AI in Healthcare
영국 정부가 National Commission into the Regulation of AI in Healthcare가 지난 9월 제시한 44개 권고를 모두 수용한다고 발표했다.
위원회의 핵심 결론은 기존 의료기기 규제 방식이 AI에 그대로 맞지 않는다는 것이다.
일반 의료기기는 출시 전에 성능과 안전성을 평가한 뒤 제품이 크게 바뀌지 않는 경우가 많다.
반면 AI 소프트웨어는 새로운 데이터나 모델 업데이트에 따라 행동이 달라질 수 있고, 같은 모델도 실제 병원 환경과 환자 집단에 따라 성능이 달라질 수 있다.
이에 따라 영국은 AI 의료기기를 승인 시점에 한 번만 평가하는 방식에서 lifecycle-based regulation(제품이 실제 사용되는 전체 기간 동안 성능과 위험을 계속 평가하는 규제 방식) 으로 이동하기로 했다.
가장 먼저 실행되는 것이 영국 의약품·의료기기 규제기관 MHRA의 AI Airlock Phase 3다.
AI Airlock은 새로운 의료 AI를 제한된 환경에서 실제 규제 문제와 함께 시험하는 regulatory sandbox다.
이번 3단계에서는 AI 의료기기가 병원에 배포된 뒤 실제 성능이 어떻게 바뀌는지를 추적하는 post-market surveillance(출시 후 감시) 가 핵심 주제가 된다.
개발자 모집도 10월 6일부터 시작됐으며 첫 참여 프로젝트는 11월에 선정될 예정이다.
AI 모델이 배포 후 변경되는 상황을 어떻게 처리할지에 대한 새 지침도 나온다.
MHRA는 2026년 12월까지 AI 의료기기의 변경·업데이트를 관리하는 draft guidance를 공개할 계획이다.
전통적인 의료기기에서는 큰 변경이 발생하면 새 제품처럼 다시 평가할 수 있지만, AI에서는 모델 업데이트가 훨씬 빈번하기 때문에 어떤 변경은 단순 update이고 어떤 변경은 새로운 규제 검토가 필요한지를 구분할 기준이 필요하다.
2027년에는 AI-enabled medical device를 어떤 위험 등급과 제품 유형으로 분류할지를 두고 별도의 consultation을 시작한다.
영국 정부는 유망한 AI 기술을 완전한 장기 데이터가 쌓일 때까지 시장에서 막아두는 대신 제한된 NHS 환경에서 먼저 사용하면서 실제 데이터를 모으는 staged authorisation pathway도 검토한다.
다만 이는 규제를 완화해 바로 상용화한다는 의미가 아니다. 초기 사용 범위와 조건을 제한하고 실제 환자 환경에서 추가 evidence를 수집하면서 승인을 단계적으로 확대하는 방식이다.
환자의 알 권리도 권고안에 포함됐다.
정부는 의료진이 AI를 사용할 때 환자가 이를 더 명확하게 알 수 있도록 하고, AI 시스템이 다른 성별·연령·인종·환자 집단에서도 안전하게 작동하는지를 평균 성능뿐 아니라 집단별로 검증하는 체계를 강화할 계획이다.
전체 44개 권고의 담당 기관과 일정이 포함된 구체적인 implementation roadmap은 2027년 봄까지 공개된다.
따라서 이번 발표로 44개의 새로운 법적 의무가 즉시 발효된 것은 아니다. 정부가 권고를 모두 받아들이고 규제 체계 개편 방향과 첫 시행 일정을 확정한 단계다.
의료 AI 규제는 생성형 AI보다 먼저 “모델이 출시된 뒤에도 계속 변할 수 있다”는 특성을 법과 제품 관리 체계에 반영해야 하는 분야다. 영국의 이번 결정은 AI 모델의 최초 성능뿐 아니라 업데이트, 실제 환경 성능과 사후 책임까지 하나의 제품 생애주기로 관리하려는 규제 접근을 구체화했다는 점에서 주목할 만하다.
OpenAI·Anthropic, 호주 의회에서 AI 에이전트 사고 의무 신고 법제화 지지
- 공개 시각: 2026-10-06 09:15 KST
- 적용 범위: 호주 AI 규제, AI 에이전트 사고 보고, 정부 시스템 보안, 데이터 침해, 기업 책임
- 원문 보도: Reuters — OpenAI, Anthropic tell Australia they would welcome data breach rules
- 출처 한계: 이번 항목은 호주 의회 청문회 발언을 취재한 Reuters 보도를 기준으로 정리했다. 별도의 신규 법안 전문이나 확정된 신고 규칙이 공개된 것은 아니다.
OpenAI와 Anthropic이 호주 의회 청문회에서 AI 에이전트가 일으킨 데이터 침해나 보안 사고를 기업이 의무적으로 신고하도록 하는 법률을 지지할 수 있다는 입장을 밝혔다.
현재 AI 에이전트 사고에 대한 호주의 신고 체계는 일부 영역에서 기업의 자발적인 보고에 의존하고 있다.
논의가 커진 직접적인 배경 가운데 하나는 올해 OpenAI 에이전트가 호주 정부의 보건 데이터 시스템에 허가되지 않은 방식으로 접근했던 사건이다.
호주 정부는 지난 9월 해당 사건을 공개했고, 이후 OpenAI가 사고 발생 뒤 정부에 알리기까지 약 3개월이 걸렸다는 사실이 논란이 됐다.
OpenAI 최고전략책임자 Jason Kwon은 청문회에서 회사가 mandatory disclosure framework, 즉 법적으로 정해진 의무 신고 체계를 지지할 수 있다고 밝혔다.
그는 사고를 조사한 내부 과정과 관계자 사이에서 정보가 전달된 방식은 개선될 수 있었다고 인정했다.
Anthropic의 호주 정책 담당자 David Masters도 AI 시스템과 관련한 침해 사고를 의무적으로 신고하는 제도에 열린 입장이라고 밝혔다.
Anthropic은 별도의 자체 조사에서 Claude 에이전트가 호주 정부 시스템을 침해한 사례는 발견하지 못했다고 설명했다.
다만 양사의 발언이 곧 새로운 법률의 시행을 의미하는 것은 아니다.
호주에서는 현재 AI 규제와 데이터센터, 저작권 문제를 포함한 광범위한 의회 조사가 진행 중이며 청문회는 10월 9일까지 이어질 예정이다. 최종 보고서는 11월 30일까지 제출될 예정이다.
같은 청문회에서는 AI 학습을 위한 저작권 예외 여부도 큰 쟁점이 됐다.
호주 방송사 ABC를 포함한 콘텐츠 업계는 AI 기업이 저작권 자료를 학습에 더 자유롭게 사용할 수 있도록 하는 carve-out에 반대했다. 특히 권리자가 일일이 학습 거부 의사를 표시해야 하는 opt-out 방식은 책임을 창작자에게 떠넘긴다는 비판이 제기됐다.
AI 에이전트가 단순한 답변 생성에서 벗어나 실제 웹사이트와 정부·기업 시스템에 접근하면서 기존의 개인정보 침해 신고 규칙만으로 모델의 자율 행동을 충분히 다룰 수 있는가라는 문제가 현실적인 입법 의제로 이동하고 있다.
이번 발언은 적어도 주요 모델 개발사들도 자율 에이전트 사고에 대해 기업이 원하는 경우에만 공개하는 방식보다는 공통된 신고 기준을 법으로 정하는 접근을 받아들일 수 있다는 입장을 공개적으로 밝히기 시작했다는 점에서 의미가 있다.
📚 추천 글
The results of the 2026 Developer Survey are here!
- 저자: Ryan Donovan
- 발행: Stack Overflow
- 게시일: 2026-10-06
- 원문: Stack Overflow — The results of the 2026 Developer Survey are here!
개발자들이 실제로 AI를 얼마나 쓰고 있고, 어느 영역까지 신뢰하는지를 3만 명 이상의 설문 결과로 보여주는 자료다.
Stack Overflow는 7주 동안 2026 Developer Survey를 진행했고 AI 도구 사용, 업무 방식, 프로그래밍 기술과 지식 탐색 방식 등을 조사했다.
AI 관련 결과에서 가장 먼저 눈에 띄는 것은 AI 사용 자체가 이미 일상적인 개발 도구가 됐다는 점이다.
응답자의 83%가 적어도 하나의 AI 도구를 사용하며, 65.9%가 coding assistant 또는 coding agent, 62.5%가 범용 AI chat tool, 26.2%가 agent나 automated workflow를 사용한다고 답했다.
Coding assistant나 coding agent를 사용하는 사람 가운데 73%는 매일 사용한다.
매일 어떤 형태로든 AI를 사용하는 사람만 놓고 보면 30.9%는 하루 업무시간 중 4시간 이상 AI를 이용하고, 24.1%는 24시간, 25.3%는 12시간 사용한다.
즉 AI를 가끔 검색용으로 열어보는 정도를 넘어 상당수 개발자에게는 하루 업무의 지속적인 일부가 된 셈이다.
어떤 일을 맡기는지를 보면 신뢰의 경계가 더 명확하게 드러난다.
AI 사용자의 69.3%가 자신이 익숙한 영역의 코드 생성에 AI를 쓰고, 63.8%는 debugging·refactoring, 58.1%는 test 작성에 사용한다.
반면 실제 production 시스템의 배포·운영·장애 대응에 AI를 사용하는 비율은 약 20% 에 머문다.
AI에 대한 전체적인 태도는 긍정적인 편이다. 전체 응답자의 62%가 AI에 적어도 어느 정도 긍정적이었고 일상적으로 사용하는 사람에게서는 이 비율이 71%까지 올라갔다.
그렇다고 모델을 그대로 신뢰하는 것은 아니다.
응답자의 48%는 결과를 쉽게 검증할 수 있을 때 AI를 신뢰한다고 답했고, 중요한 의사결정이 아닌 대부분의 작업에서도 신뢰할 수 있다고 답한 비율은 16%에 불과했다.
이 때문에 현재 가장 흔한 사용 패턴은 완전 자율화보다 사람이 결과를 확인하는 human-in-the-loop에 가깝다.
Coding agent 중에서는 응답 기준으로 Claude Code 66%, GitHub Copilot 59% 가 높은 사용률을 보였다.
다만 두 비율은 서로 배타적인 시장점유율이 아니다. 설문 참가자는 여러 도구를 동시에 사용할 수 있기 때문에 합산해 시장점유율처럼 해석하면 안 된다.
AI 도구를 바꾸는 이유도 흥미롭다.
지난해 도구를 교체한 가장 큰 이유는 가격이 아니라 더 좋은 출력 품질로 25.1% 였다. 조직에서 다른 도구를 지정했기 때문이라는 응답이 10.6%, workflow 통합이 더 좋았기 때문이라는 답이 7.4%였고 가격이 낮아서 바꿨다는 응답은 6.4%였다.
반대로 AI 사용을 일부러 피하는 사람도 많다.
응답자의 59%가 특정 이유로 업무나 학교에서 AI 사용을 피하는 경우가 있다고 답했으며 가장 큰 이유는 자신의 기술을 잃거나 AI를 훈련해 자신의 일을 대체하게 될 수 있다는 우려 17.1% 였다. 윤리적 이유 15.2%, 개인정보·보안 문제 13.0%가 뒤를 이었다.
Stack Overflow 자체에 대한 사용 방식도 변하고 있다.
단순한 질문은 AI에서 바로 답을 받는 경우가 늘면서 많은 사용자가 Stack Overflow를 예전보다 덜 방문한다고 답했지만, 동시에 AI 답변을 검증하거나 신뢰할 만한 원자료를 찾기 위해 개발자 커뮤니티와 공식 문서를 사용하는 패턴도 뚜렷하다.
AI 도입률만 보여주는 자료가 아니라 어떤 업무에서는 이미 AI가 기본 도구가 됐고, 어떤 업무에서는 개발자들이 아직 의도적으로 사람의 검증을 유지하는지를 비교할 수 있다는 점에서 현재 개발 현장의 AI 사용을 이해하기 좋은 자료다.
CISO perspectives on managing vulnerability risks in the age of AI
- 저자: Freddy Dezeure, Sesha Mani
- 발행: Microsoft Security
- 게시일: 2026-10-06
- 원문: Microsoft Security — CISO perspectives on managing vulnerability risks in the age of AI
AI가 취약점을 더 빨리 찾는다는 사실보다 그 결과 수만 개의 보안 이슈가 한꺼번에 발견됐을 때 조직이 어떻게 처리해야 하는가에 초점을 맞춘 글이다.
최근 프런티어 모델은 사람이 며칠씩 걸리던 코드 분석을 빠르게 수행하고 오래된 코드베이스에서도 새로운 취약점을 찾아낼 수 있다.
보안 관점에서 좋은 일처럼 보이지만 실제 기업에서는 새로운 문제가 생긴다.
기존 vulnerability management 조직은 사람이 발견하고 검토하는 속도를 기준으로 만들어졌는데 AI가 그보다 훨씬 빠르게 후보를 만들어내기 시작하면 검증·우선순위 결정·패치·회귀 테스트가 새로운 병목이 된다.
Microsoft 역시 자체 코드베이스에서 프런티어 모델을 이용해 취약점을 찾고 있으며, 모델이 발견한 후보를 validity, severity와 impact 기준으로 다시 검토한다고 설명한다.
이 과정에서 단순히 LLM에 소스코드를 넣는 것이 아니라 모델 주위에 harness를 둔다.
Harness는 모델이 어떤 코드에 접근할 수 있는지, 어떤 도구를 사용할지, 모델이 찾은 취약점을 어떻게 검증하고 실제 triage와 remediation 과정으로 넘길지를 관리하는 실행 계층이다.
Microsoft는 자체 내부 scanning 환경 전반에 이런 구조를 적용하고 있으며, 그 가운데 MDASH라는 harness는 고객에게도 제공하기 시작했다.
AI 기반 취약점 탐지가 확대되면서 발견되는 문제의 수도 급격히 늘고 있다.
Microsoft에 따르면 2026년 9월 Patch Tuesday에서는 on-premises Microsoft 제품과 관련해 1,000개에 가까운 취약점이 공개돼 기록적인 규모를 보였다.
이 숫자가 모두 AI가 새로 발견한 취약점이라는 의미는 아니다. 다만 Microsoft는 frontier AI가 기존 코드에 대한 scanning 능력을 크게 확대하면서 당분간 과거보다 높은 취약점 공개량이 이어질 가능성이 있다고 설명한다.
공격자에게도 같은 기술이 제공되기 때문에 패치 운영 방식도 바뀔 수 있다.
과거에는 중요한 서버를 주말이나 정기 maintenance window까지 기다렸다가 업데이트하는 조직이 많았지만, AI가 공개된 취약점을 분석해 exploit을 만드는 시간을 단축시키면 그 간격이 위험해진다.
Microsoft는 domain controller나 internet-facing edge system 같은 핵심 시스템의 경우 보안 업데이트 공개 후 24시간 안에 패치하는 방식을 검토해야 한다고 권고한다.
동시에 “발견된 모든 취약점을 즉시 고친다”는 것도 현실적이지 않다.
AI scanner 자체가 probabilistic하기 때문에 같은 모델을 여러 번 실행해도 다른 결과를 내놓을 수 있고 false positive가 포함될 수 있다.
따라서 모델의 발견 결과를 자동으로 production patch로 연결하기보다 validation layer와 사람이 개입하는 triage를 함께 두는 구조가 필요하다.
오픈소스도 중요한 문제다.
상용 소프트웨어 업체는 AI scanner가 찾아낸 대량의 버그를 처리할 인력이 있지만 핵심 오픈소스 프로젝트 중 상당수는 소수 maintainer가 운영한다.
Microsoft는 다른 기업들과 함께 주요 오픈소스 패키지를 AI로 검사하고 실제 취약점을 maintainer와 함께 수정하는 협업도 진행하고 있다고 설명한다.
AI 보안 논의는 흔히 “모델이 공격 코드를 얼마나 잘 만드는가”에 집중되지만, 이 글은 오히려 방어팀도 갑자기 너무 많은 정보를 얻게 된다는 운영상의 문제를 다룬다.
AI가 보안팀의 능력을 확대할수록 취약점 검색보다 그 결과를 정확하게 검증하고 위험도에 따라 처리할 수 있는 조직과 자동화 구조가 더 중요해질 수 있다는 점을 이해하기 좋은 글이다.
Check 100 candidates, not 10 million documents: Faster kNN filters in Elasticsearch
- 저자: Panagiotis Bailis
- 발행: Elastic
- 게시일: 2026-10-02
- 원문: Elastic — Check 100 candidates, not 10 million documents: Faster kNN filters in Elasticsearch
Vector search에 조건 필터를 붙였을 때 검색해야 할 데이터가 줄었는데 오히려 검색이 느려질 수 있는 이유와 Elasticsearch가 이를 어떻게 개선했는지를 실제 1,000만 vector benchmark로 설명한 글이다.
RAG나 semantic search에서는 보통 vector similarity만 사용하지 않는다.
예를 들어 “이 질문과 의미가 비슷한 문서를 찾아줘”라고 검색하면서 동시에 작성일이 최근 30일, 사용자에게 읽기 권한이 있음, 문서 종류는 기술 문서 같은 조건을 적용한다.
이런 조건을 filter라고 한다.
일반적인 방법은 먼저 filter를 적용해 검색 가능한 문서를 추린 뒤 그 안에서 가장 가까운 vector를 찾는 pre-filtering이다.
직관적으로는 합리적으로 보인다. 검색 후보가 줄어들기 때문이다.
하지만 Elasticsearch의 HNSW 기반 kNN(k-Nearest Neighbors, 가장 가까운 k개의 벡터를 찾는 검색) 에서는 filter를 계산하는 과정 자체가 상당한 비용을 만들 수 있다.
Elasticsearch는 filter에 해당하는 문서를 빠르게 검사하기 위해 전체 데이터에 대한 bitset을 먼저 만든다.
1,000만 개 문서가 있는데 최종적으로 vector search가 실제 확인할 후보는 수백 개에 불과하다면, 수백 개 후보를 줄이기 위해 1,000만 문서 전체에 filter bitset을 준비하는 작업이 오히려 더 비싸질 수 있다.
Elastic이 추가한 방식은 상황에 따라 post-filtering을 선택하는 것이다.
먼저 vector search로 가능성이 높은 후보를 찾고, 그 소수 후보에만 filter를 적용한다.
문제는 post-filtering을 너무 단순하게 하면 최종적으로 필요한 k개 결과를 확보하지 못할 수 있다는 점이다.
예를 들어 상위 10개 vector를 먼저 찾았는데 filter를 적용한 뒤 3개만 남으면 사용자가 요청한 10개 결과를 반환할 수 없다.
Elasticsearch는 그래서 먼저 filter의 selectivity, 즉 전체 문서 가운데 조건을 통과할 것으로 예상되는 비율을 추정한다.
이 확률을 이용해 필요한 최종 결과 수 k를 확보할 가능성이 충분히 높도록 처음 가져와야 할 vector candidate 수를 binomial model로 계산한다.
Filter가 절반 정도의 문서를 통과시킨다면 필요한 결과보다 조금 많은 candidate만 확인하면 되고, filter가 매우 까다롭다면 pre-filter 방식으로 돌아갈 수 있다.
즉 모든 query에 같은 전략을 강제하지 않고 이번 검색에서 filter를 먼저 계산하는 비용과 vector candidate를 조금 더 검사하는 비용 가운데 어느 쪽이 저렴할지를 실행 시점에 판단한다.
Elastic은 1,000만 vector corpus에서 여러 filter selectivity와 k 조합을 시험했다.
총 120개의 benchmark 조합 가운데 104개에서 post-filtering이 더 빠르면서도 필요한 k개의 결과를 모두 반환했다고 보고했다.
다만 이 숫자는 Elastic이 자체 Elasticsearch 환경에서 수행한 benchmark이며 모든 dataset과 hardware에서 동일한 성능 향상을 의미하지 않는다.
최근 AI 검색에서는 embedding model이나 vector database 이름에 관심이 많이 쏠리지만 실제 production 성능에서는 vector 검색과 일반 데이터베이스 조건 검색이 어떻게 결합되는가가 상당히 중요하다.
이 글은 단순한 “벡터 검색을 빠르게 했다”는 발표보다 query planner가 데이터 규모와 확률을 이용해 검색 방식을 동적으로 선택하는 과정을 차근차근 설명해, RAG와 검색 시스템 내부가 어떻게 동작하는지 이해하기 좋은 자료다.