AI 데일리 브리핑 — 2026-09-30

Soshy·2026년 9월 30일

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

1️⃣ 주요 모델·연구

OpenAI, GPT-6.1 Sol 출시…Astra에 가까운 에이전트 성능을 더 낮은 비용으로 제공

발표일: 2026-09-29 — 정확한 게시 시각 미확인
적용 범위: 범용 LLM, 코딩 에이전트, 컴퓨터 사용, 전문 문서 업무, 과학 연구, OpenAI API
원문: OpenAI — GPT-6.1 Sol

OpenAI가 GPT-6.1 Sol을 공개했다. GPT-6 Sol의 후속 업그레이드로, 최고급 모델인 GPT-6 Astra에 가까운 에이전트·코딩·컴퓨터 사용 성능을 훨씬 낮은 비용으로 제공하는 데 초점을 맞춘 모델이다.

API 가격은 입력 100만 토큰당 2달러, 출력 100만 토큰당 10달러이며, 반복해서 사용하는 프롬프트를 재활용하는 cached input(캐시된 입력) 은 100만 토큰당 0.10달러다. OpenAI는 Astra의 일반 입력·출력 가격 대비 약 5분의 1 수준이라고 설명한다.

이번 모델에서 특히 강조되는 것은 agentic coding(에이전트형 코딩) 과 computer use다. 일반적인 코드 생성 모델은 요청에 코드 한 번을 작성하는 데 초점이 있지만, 에이전트형 모델은 저장소를 읽고 파일을 수정하고 터미널과 테스트를 여러 차례 실행하면서 실제 작업 완료까지 반복한다.

OpenAI 자체 평가에서 GPT-6.1 Sol은 실제 코드베이스의 장시간 소프트웨어 작업을 평가하는 DeepSWE v1.1에서 GPT-6 Astra와 비슷한 결과를 냈고, GPT-6 Sol의 최고 결과보다 6.4%포인트 높은 점수를 기록했다고 밝혔다.

업무 자동화에서도 비슷한 방향이 나타난다. 47개 업무 도구를 이용해 영업·마케팅·재무·인사 등의 다단계 작업을 수행하는 AutomationBench에서는 중간 reasoning effort 기준 Opus 5.5보다 2.2%포인트 높은 점수를 기록했고, 컴퓨터 애플리케이션을 직접 다루는 OSWorld 2.0에서는 GPT-6 Sol보다 7%포인트 높았다.

과학 연구용 터미널 작업을 평가하는 Terminal-Bench Science에서는 GPT-6 Sol의 최고 점수를 두 배 이상으로 높였으며, Astra는 여전히 68.1%로 가장 높은 점수를 유지했다.

이 비교 수치들은 OpenAI의 연구 환경 또는 API에서 측정됐고 경쟁 모델 값 일부는 공개 보고서에서 가져온 것이므로 완전히 동일한 독립 평가로 보기는 어렵다.

사실성 평가에서는 낮은 reasoning effort에서 최소 한 개의 사실 오류가 포함된 응답 비율이 GPT-6 Sol의 11.4%에서 7.7%로 감소했다고 보고했다.

다만 이 평가는 일반적인 사용자 질문이 아니라 과거 모델의 오류를 사용자가 직접 신고했던 어려운 대화만 모아 진행한 것이어서, 실제 전체 사용 환경의 오류율을 뜻하지 않는다.

GPT-6.1 Sol은 9월 29일부터 Plus, Pro, Business, Enterprise, Edu 사용자의 ChatGPT Work와 Codex에서 제공되며 일반 Chat에는 아직 적용되지 않았다. 개발자는 API에서 gpt-6.1-sol로 사용할 수 있다.

최근 프런티어 모델 경쟁이 단순히 “가장 높은 벤치마크 점수”에서 하나의 장시간 업무를 완료하는 데 필요한 비용과 시간까지 함께 최적화하는 방향으로 이동하고 있는데, GPT-6.1 Sol은 그 흐름을 매우 직접적으로 보여주는 모델이다.

Microsoft Research, 생물학의 여러 층위를 함께 모델링하는 연구 시스템 ‘Quine’ 공개

발표일: 2026-09-29 — 정확한 게시 시각 미확인
적용 범위: AI for Science, 생물학·암 연구, 멀티모달 AI, 신약 후보 탐색, 실험 설계
원문: Microsoft Research — Introducing Quine

Microsoft Research가 Quine이라는 새로운 AI 기반 생물학 연구 시스템을 공개했다. Quine은 하나의 질병이나 데이터 종류만 다루는 전문 모델이라기보다 유전체, 단백질, 화학 구조, RNA와 세포 상태, 생물학적 이미지처럼 서로 다른 정보를 함께 연결하는 multimodal world model(멀티모달 세계 모델) 을 만드는 연구 프로젝트다.

여기서 world model은 현재 생물학적 상태를 표현하고 특정 개입을 했을 때 상태가 어떻게 변할지를 여러 단계 앞까지 예측하는 시스템을 의미한다.

생물학에서 이 접근이 필요한 이유는 한 종류의 데이터만 봐서는 실제 현상을 설명하기 어렵기 때문이다. 유전자의 변화는 단백질 기능에 영향을 주고, 단백질은 세포 안에서 다른 분자와 상호작용하며, 이런 변화가 조직과 질병 상태로 이어진다.

Quine은 이 데이터들을 별도의 전문 모델에 완전히 분리하기보다 공동 표현 안에서 학습해 한 층위에서 얻은 증거가 다른 층위의 예측에도 사용되도록 설계됐다.

Quine 자체만으로 연구가 끝나는 것도 아니다. 모델 주변에는 문헌, 과학 도구, reasoning model, 실제 연구자와 실험실을 연결하는 harness(모델이 도구와 환경을 사용하도록 구성한 실행 시스템) 가 있다.

연구자가 질문을 던지면 Quine이 계산적으로 가능한 후보를 좁히고, 실제 wet lab에서 실험한 결과가 다시 다음 예측과 연구 질문에 사용되는 폐쇄 루프 구조다.

Microsoft는 Harvard·MIT의 Broad Institute 연구진과 함께 췌장암의 하나인 PDAC(pancreatic ductal adenocarcinoma) 연구에 Quine을 적용했다.

수천 개 화합물 가운데 암세포를 특정 상태에서 다른 치료적으로 의미 있는 상태로 이동시킬 가능성이 높은 후보를 예측하고 순위를 매긴 뒤 실제 실험으로 검증했다.

최고 순위 화합물들이 실제 실험에서도 가장 큰 의도된 세포 상태 변화를 만들었으며, 후보 공간을 좁히는 과정이 한 주말 안에 이뤄졌다고 Microsoft는 설명한다.

흥미로운 부분은 모델이 단순히 이미 예상한 효과만 찾은 것이 아니라는 점이다. 일부 화합물에서는 연구진이 처음 설정했던 두 상태 사이가 아니라 세 번째 세포 표현형으로 이동하는 현상을 예측했고, 실험에서도 같은 패턴이 관찰됐다.

다만 이것이 새로운 치료법이 확인됐다는 뜻은 아니다. Microsoft는 Quine을 명시적으로 실험용 연구 기술로 규정하고 있으며 임상·의료 용도가 아니고, 모든 결과는 전문 연구자의 검토와 실제 실험 검증이 필요하다고 설명한다.

현재 접근은 Quine Fellows와 일부 연구 협력에 제한돼 있다. AI for Science가 논문을 읽고 가설을 제안하는 단계에서 더 나아가 계산 → 후보 우선순위화 → 실제 실험 → 새로운 데이터 → 다음 가설의 연구 주기 자체에 들어가기 시작하고 있다는 흐름을 보여주는 발표다.

Google Research, 닫힌 이미지 모델도 별도 제어망으로 조정하는 ‘Diffusion Controller’ 공개

발표일: 2026-09-29 — 정확한 게시 시각 미확인
적용 범위: 이미지 생성, diffusion model, 모델 개인화, 생성 제어, 안전 필터 연구
원문: Google Research — How Diffusion Controller unifies and simplifies AI image generation

Google Research가 이미지 생성 모델을 원하는 방향으로 조정하는 새로운 프레임워크인 Diffusion Controller를 공개했다.

Diffusion model은 무작위 노이즈에서 시작해 여러 단계를 거쳐 노이즈를 제거하면서 이미지를 만들어내는데, 기존에는 사용자의 세밀한 요구를 반영하려면 모델 내부 가중치를 직접 fine-tuning하거나 생성 시점마다 별도의 guidance 기법을 적용하는 경우가 많았다.

Diffusion Controller의 핵심은 원래 이미지 모델을 그대로 고정한 상태에서 옆에 작은 side network(보조 신경망) 를 붙이는 것이다.

Google은 이를 오토바이의 방향을 미세하게 안정화하는 ‘steering damper’에 비유한다. 원본 모델이 노이즈를 제거해가는 중간 상태를 관찰하면서 작은 보정값을 계속 주입해 결과를 원하는 목표 쪽으로 움직인다.

이 구조의 장점은 모델 전체를 수정할 권한이 없어도 사용할 수 있다는 것이다.

일반적인 LoRA 같은 parameter-efficient fine-tuning은 적은 수의 파라미터만 수정하지만 그래도 모델 내부 가중치에 접근해야 한다.

반면 Diffusion Controller는 일부 중간 정보를 사용할 수 있는 gray-box 환경, 즉 모델 전체가 공개되지 않은 상황에서도 별도 제어망을 연결할 수 있도록 설계됐다.

연구팀은 Stable Diffusion v1.4를 기반으로 SFT, reward-weighted loss, PPO 등 여러 방식으로 실험했다.

연구팀의 HPS-v2와 인간 선호 평가에서는 gray-box Diffusion Controller가 비교 대상으로 사용한 LoRA보다 높은 prompt alignment를 보였고, 내부 가중치까지 함께 조정하는 white-box 버전은 기본 모델 대비 인간 평가에서 최대 90%의 승률을 기록했다고 보고했다.

이는 Google Research가 수행한 특정 모델·데이터·평가 조건에서 나온 연구 결과로, 모든 이미지 생성 모델에서 같은 개선 폭이 보장된다는 의미는 아니다.

실제 활용 측면에서는 이미지 개인화뿐 아니라 안전 제어에도 응용 가능성이 있다. 원본 생성 모델을 다시 학습하지 않고 별도의 제어 계층에서 특정 생성 목표나 제한을 조정할 수 있기 때문이다.

연구팀은 이후 영상 생성과 유해 콘텐츠 완화 같은 영역으로 확장할 계획이라고 밝혔다.

2️⃣ AI 제품·서비스

OpenAI, 사용자가 자리를 비워도 계속 일하는 상시 에이전트 ‘Dots’ 출시

발표일: 2026-09-29 — 정확한 게시 시각 미확인
적용 범위: 개인·업무 AI 에이전트, 장기 작업, Slack·Teams, 기업 업무 자동화, 클라우드 컴퓨터
원문: OpenAI — Introducing Dots

OpenAI가 Dots라는 새로운 상시 실행형 AI 에이전트를 출시했다.

기존 ChatGPT가 사용자가 대화를 시작하고 작업을 요청할 때 움직이는 방식이었다면, Dot은 독립적인 클라우드 컴퓨터와 브라우저를 가지고 사용자가 앱을 닫은 뒤에도 여러 프로젝트를 계속 수행하도록 설계됐다. 기반 모델은 GPT-6 Astra다.

Dot은 플러그인을 통해 4,000개가 넘는 앱과 연결할 수 있으며 ChatGPT뿐 아니라 Slack과 Microsoft Teams에서도 대화를 이어갈 수 있다.

한 채널에서 받은 업무와 다른 채널의 대화 문맥을 연결할 수 있고, 사용자는 필요하면 Dot의 클라우드 컴퓨터 화면을 직접 열어 현재 어떤 작업을 하는지도 확인할 수 있다.

OpenAI가 제시한 예를 보면 일반적인 챗봇과 역할 차이가 분명하다.

개발자의 Dot은 고객 피드백을 계속 확인하다 반복되는 버그를 찾으면 코드를 수정하고 테스트한 뒤 PR을 준비할 수 있고, 연구자의 Dot은 새 데이터가 들어올 때 분석을 다시 실행하고 논문 그래프와 설명을 업데이트한다.

즉 한 번의 프롬프트에 답하는 대신 지속적인 책임 영역을 맡는 에이전트를 지향한다.

상시 실행 에이전트는 접근 권한이 커지는 만큼 별도의 제어 구조도 사용한다.

Dot의 클라우드 컴퓨터는 사용자의 실제 컴퓨터와 기본적으로 분리돼 있고, 앱별 권한을 직접 설정할 수 있다.

백그라운드에서 스스로 정보를 찾아보는 ‘proactive research’는 읽기 전용 도구만 사용할 수 있어 메시지를 보내거나 앱 데이터를 변경할 수 없다.

계정이나 외부 시스템에 영향을 줄 수 있는 행동은 별도의 auto-review가 사용자 지시와 규칙을 검사해 독립 실행할지, 승인을 받을지, 사용자가 직접 해야 할지를 결정한다.

개인용 Dot 외에 회사 내부에서 특정 업무만 맡는 specialist dots도 시험 중이다.

이들은 각각 별도의 신원과 자격증명, 시스템 접근권한을 받고 조달, 송장 처리, 고객 지원, 계약 업무 같은 역할을 수행한다.

Microsoft Agent 365의 기업 보안·거버넌스 체계와 연결하는 작업도 진행 중이다.

Dots는 9월 29일부터 지원 지역의 Pro와 Business Premium 사용자에게 순차 배포되고 있으며 Enterprise·Edu·Healthcare는 관리자가 활성화한 경우 베타를 사용할 수 있다.

최근 AI 에이전트 경쟁이 “복잡한 일을 한 번 처리하는 도구”에서 사람처럼 특정 책임을 계속 맡아 상태를 유지하는 상시 작업자로 이동하고 있음을 보여주는 대표적인 제품 변화다.

Meta, Muse를 소상공인용 업무 에이전트로 확장…Shopify·QuickBooks·Stripe 등 직접 연결

발표일: 2026-09-29 — 정확한 게시 시각 미확인
적용 범위: 소상공인 AI, 업무 자동화, 전자상거래, 회계·결제·마케팅, Facebook·Instagram 비즈니스
원문: Meta — The Future Is for Everyone: Muse for Small Business

Meta가 개인용 AI 에이전트 Muse를 기업 업무로 확장한 Muse for Small Business를 발표했다.

9월 초 출시한 개인용 Muse가 이메일이나 웹사이트를 이용해 개인의 일을 대신 처리하는 제품이었다면, 이번 버전은 소상공인이 실제 사업 운영에 쓰는 여러 서비스와 연결해 마케팅, 회계, 고객 관리, 일정 관리와 같은 업무를 함께 처리하도록 설계됐다.

연결 가능한 서비스에는 Asana, Box, Canva, Dropbox, Figma, Granola, HighLevel, QuickBooks, Klaviyo, Lovable, Notion, Shopify, Slack, Stripe, Zoom 등이 포함된다.

Facebook Pages, Instagram 전문 계정의 분석 정보, Meta 광고 계정도 연결할 수 있다.

공식 연결 기능이 없는 내부 서비스는 custom connector로 추가할 수도 있다.

이렇게 여러 데이터를 연결하면 사용자가 매번 정보를 복사해 프롬프트에 넣는 대신 Muse가 사업의 기존 문맥을 직접 사용한다.

Meta가 제시한 사례에서는 올해의 판매·광고·SNS 데이터를 함께 분석해 다음 해 성장 계획을 만들거나, 최근 재무 실적과 비용을 살펴 이상 지출을 찾고, 성과가 좋았던 광고와 최근 트렌드를 바탕으로 다음 캠페인을 초안하는 식이다.

에이전트에게 회계·결제·SNS 계정까지 연결하면 행동 권한이 중요한 문제가 된다.

Meta는 게시, 메시지 전송, 돈을 쓰는 행동은 사용자 승인 없이 실행하지 않는다고 명시한다.

이는 최근 개인 에이전트가 단순 정보 검색을 넘어 실제 경제·업무 시스템을 조작하기 시작하면서 제품 설계의 핵심이 모델의 지능뿐 아니라 승인 경계와 접근권한 관리로 옮겨가고 있음을 보여준다.

Muse는 대부분의 기본 사용이 무료이며 더 많은 사용량에는 구독제가 적용된다.

Meta가 며칠 전 별도의 Enterprise Platform 사업을 발표한 데 이어 개인 에이전트를 작은 사업자의 실제 업무 시스템까지 확장하면서, 기업용 AI 에이전트 시장 경쟁이 대기업뿐 아니라 소규모 사업자까지 빠르게 넓어지고 있다.

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

OpenAI DevDay, Agents API에 컴퓨터 사용 추가…Decisions API·Codex Security Cloud도 공개

발표일: 2026-09-29 — 정확한 게시 시각 미확인
적용 범위: AI 에이전트 API, 코딩 에이전트, 컴퓨터 사용, 소프트웨어 보안, MCP, 플러그인 개발
원문: OpenAI — DevDay 2026 Recap

OpenAI가 DevDay 2026에서 개발자용 에이전트 스택을 대폭 확장했다.

가장 큰 변화 가운데 하나는 Agents API가 computer use를 직접 지원하기 시작했다는 것이다.

개발자는 이제 API로 만든 에이전트가 일반 소프트웨어 화면을 보고 조작하도록 구성할 수 있으며, Codex에서 사용되던 multi-agent 기능과 tool search, tool calling, context compaction도 Agents API에 들어왔다.

Context compaction은 장시간 작업에서 대화와 도구 실행 기록이 지나치게 길어질 때 중요한 정보만 압축해 컨텍스트를 유지하는 기능이다.

새로운 Decisions API도 공개됐다.

일반 LLM API가 자유형 텍스트를 만들어내는 데 초점을 둔다면 Decisions API는 개발자가 미리 지정한 유한한 선택지 중 하나를 고르는 작업에 맞춰 Luna 모델을 사용한다.

텍스트와 이미지를 입력으로 줄 수 있으며 콘텐츠 분류, 요청 라우팅, 다음에 실행할 에이전트 행동 선택처럼 빠르고 반복적인 의사결정에 사용할 수 있다.

현재 limited preview이며 더 넓은 배포가 예정돼 있다.

보안 개발 도구인 Codex Security Cloud도 추가됐다.

GitHub 저장소 전체를 필요할 때 또는 일정에 따라 스캔하고, 새 커밋을 계속 확인하며, 발견된 문제의 중복을 제거하고 원인을 조사한 뒤 수정안까지 클라우드에서 준비한다.

기존 Daybreak Blue를 별도 신청하지 않고 이용할 수 있으며 Pro, Business, Enterprise, Edu 사용자에게 제공된다.

Codex 자체도 로컬 도구에서 장시간 실행 플랫폼으로 확장됐다.

개발자는 Codex 작업을 클라우드에 올려 PC가 꺼져 있어도 실행할 수 있고, CLI의 새로운 /agents 화면에서 여러 에이전트에게 작업을 나누고 진행 상황을 한꺼번에 볼 수 있다.

ChatGPT 데스크톱에는 GitHub PR이나 GitLab merge request의 diff를 읽고 문제를 찾아주는 별도의 Code Review 화면도 추가됐다.

플러그인 쪽에서는 MCP Events 지원도 추가됐다.

MCP(Model Context Protocol)는 AI가 외부 도구·데이터와 통신하는 표준 규격인데, Events를 사용하면 사용자가 직접 프롬프트를 보내지 않아도 외부 앱의 사건이 에이전트 작업을 시작할 수 있다.

예를 들어 프로젝트 보드에 새 작업이 생기면 ChatGPT가 관련 문서를 읽고 계획을 초안하는 식이다.

이번 DevDay에서 공통적으로 드러나는 흐름은 개발자 API의 기본 단위가 점차 “모델에 텍스트를 보내고 답을 받는 호출”에서 지속적인 상태를 가지고 컴퓨터·코드·외부 앱을 사용하는 에이전트 실행 환경으로 이동하고 있다는 점이다.

모델 성능만큼 도구 실행, 장기 컨텍스트, 권한, 이벤트 처리와 실행 인프라가 개발 플랫폼의 핵심 요소가 되고 있다.

4️⃣ 산업·정책·안전

Anthropic, 오픈웨이트 GLM-5.3이 프런티어급 사이버 공격 능력에 도달했다고 분석

발표일: 2026-09-29 — 정확한 게시 시각 미확인
적용 범위: AI 사이버보안, 오픈웨이트 모델, 모델 안전장치, 취약점 탐색·익스플로잇, AI 안전 평가
원문: Anthropic — GLM-5.3 and the spread of advanced cyber capabilities

Anthropic이 중국 Zhipu AI(Z.ai)의 오픈웨이트 모델 GLM-5.3을 별도로 평가한 결과, 복잡한 소프트웨어 취약점을 찾아 실제 공격 코드까지 만드는 능력이 자사의 제한 공개 사이버 모델 Claude Mythos Preview에 가까워졌다고 발표했다.

Open-weight model(오픈웨이트 모델) 은 모델의 학습된 파라미터를 내려받아 사용자가 직접 실행하거나 수정할 수 있는 모델을 뜻한다.

Google Chrome의 V8 엔진 취약점을 대상으로 하는 ExploitBench에서 GLM-5.3은 410번의 시도 중 50번, Mythos Preview는 56번 완전한 exploit을 만드는 데 성공했다.

Anthropic 내부의 별도 binary exploitation 평가에서는 각각 4%와 6%의 성공률을 기록했으며 이전 세대 GLM-5.2와 Claude Opus 4.6은 이 평가에서 성공 사례가 없었다.

NIST 산하 CAISI도 9월 17일 별도 평가에서 GLM-5.3을 당시 공개된 오픈웨이트 모델 중 가장 강한 사이버 모델이라고 평가한 바 있다.

자동 벤치마크보다 더 주목할 만한 것은 사람 연구자와 함께 진행한 실험이다.

한 연구자는 GLM-5.3에 샌드박스 안의 실제 브라우저를 분석하게 했고, 모델은 하루 안에 JavaScript 엔진에서 이전에 알려지지 않았던 여러 취약점을 찾아 연결해 악성 웹페이지가 방문자의 임의 파일을 읽을 수 있는 exploit chain을 만들었다.

Anthropic은 해당 취약점을 개발사에 알렸다고 밝혔다.

GLM-5.3-Flash를 사용한 다른 실험에서는 공개된 두 Chrome 취약점을 ARM64용 exploit chain으로 연결하는 데 사람의 집중 작업 약 20분과 모델 실행 약 8시간이 필요했고, 당시 Zhipu API 가격으로 모델 사용료는 20.40달러였다고 설명했다.

문제는 이런 능력에 비해 안전장치를 제거하기 쉽다는 점이다.

Anthropic은 명시적으로 악의적인 요청을 그대로 주면 GLM-5.3이 모두 거부했지만, 공격을 보안 훈련으로 위장한 프롬프트에서는 64%, reasoning 앞부분을 미리 채워 넣는 방법에서는 92%가 공격에 참여했다고 보고했다.

모델 내부의 거부 행동을 제거하는 abliteration을 적용한 버전에서는 100%였다.

모델 가중치를 수정해 거부 방향을 제거하는 데 약 2,200 GPU 시간이 들었으며 계산비용은 약 4,400달러였다고 한다.

다만 Claude와 GLM의 안전성 비교 결과는 Anthropic이 직접 설계하고 실행한 평가라는 점을 반드시 감안해야 한다.

자사 API 모델은 서버 측 보호 장치를 포함한 상태로 평가됐고, 오픈웨이트 GLM은 사용자가 가중치 자체를 변경할 수 있어 배포 구조가 근본적으로 다르다.

그럼에도 고급 exploit 개발 능력이 더 이상 제한된 프런티어 API에만 존재하지 않고 다운로드 가능한 모델로 빠르게 확산되고 있다는 사실은 AI 사이버보안의 중요한 변화다.

Google, EU의 Android AI 개방·검색 데이터 공유 명령에 법적 이의 제기

공개·보도일: 2026-09-29 14:06 KST
적용 범위: EU Digital Markets Act, AI 경쟁정책, Android AI assistant, 검색 데이터, 개인정보 보호
원문 보도: Reuters — Google challenges EU orders to open up to AI, search-engine rivals
관련 1차 자료: European Commission — AI interoperability on Android and sharing of Google Search data under the DMA
출처 한계: 이번 법적 이의 제기 자체의 법원 제출문은 직접 확인하지 못했으며, Google과 European Commission의 입장을 인용한 Reuters 보도를 기준으로 정리했다.

Google이 유럽연합이 지난 7월 Digital Markets Act(DMA)에 따라 내린 두 가지 명령에 대해 EU 일반법원에 법적 이의를 제기했다.

하나는 Android에서 Gemini가 사용하는 주요 기능을 경쟁 AI assistant에도 동등하게 제공하도록 하는 것이고, 다른 하나는 Google Search가 축적한 검색 데이터를 일정 조건 아래 경쟁 검색 서비스와 공유하도록 하는 조치다.

EU의 목적은 Android 위에서 Gemini와 다른 AI가 동일한 시스템 기능을 이용할 수 있도록 하고, 검색 시장에서는 Google만 대규모로 확보할 수 있는 query·click·view 등의 데이터 일부를 다른 사업자가 사용할 수 있도록 해 경쟁을 촉진하는 것이다.

AI 챗봇 가운데 검색 기능을 제공하는 서비스도 일정 요건을 충족하면 데이터 제공 대상이 될 수 있다.

Google은 이에 대해 검색 기록의 anonymization(익명화)이 충분하지 않은 상태에서 민감한 검색 데이터를 경쟁사에 넘기게 될 수 있고, Android의 보안 장치를 약화시킬 수 있다고 주장했다.

반면 European Commission은 기존 결정이 개인정보와 시스템의 무결성·보안을 이미 고려해 설계됐으며 법정에서 결정을 방어하겠다는 입장이다.

현재 명령 자체가 취소된 것은 아니며, EU가 요구한 변경사항은 2027년부터 적용될 예정이다.

이번 분쟁은 AI 경쟁이 모델 품질만의 문제가 아니라 운영체제 수준의 기능 접근권과 검색 데이터처럼 기존 플랫폼이 보유한 자산을 경쟁 AI에 어디까지 개방해야 하는가라는 규제 문제로 이동하고 있음을 보여준다.

미국 정부·AI 기업 경영진, AI 개발 원칙을 담은 ‘morally binding’ 문서 서명

공개 시각: 2026-09-30 05:04 KST
적용 범위: 미국 AI 정책, AI 기업 자율규제, 안전 평가, 산업 거버넌스
원문 보도: Reuters — Trump, tech executives sign 'morally binding' AI document
출처 한계: 기준 시점인 06:00 KST까지 문서 전문과 구체적인 참여 기업·의무사항을 설명하는 공식 자료를 확인하지 못해, 현장에서 공개된 발언을 전한 Reuters 보도를 기준으로 정리했다.

미국 정부와 주요 기술기업 경영진이 워싱턴에서 AI와 관련한 공동 문서에 서명했다.

도널드 트럼프 대통령은 이를 법적인 규제가 아니라 “morally binding”, 즉 법적 구속력보다는 참여자의 자발적 책임에 기반한 문서라고 설명했다.

공개 시각은 9월 29일 20:04 UTC, 한국시간으로 9월 30일 오전 5시 4분이어서 이번 조사 범위 종료 직전에 포함된다.

Reuters와 AP 보도에 따르면 이 합의에는 AI 시스템에 대한 내부·외부 검토와 기업의 자율적인 안전 관리가 핵심 방향으로 포함된 것으로 알려졌다.

트럼프 대통령은 기업들의 “self-policing”을 강조했으며, AI 산업 전체를 관찰할 약 10명 규모의 위원회를 만드는 방안도 검토하고 있다고 밝혔다.

다만 기준 시점까지 합의문 전문이나 구체적인 검사 기준, 위반 시 조치, 참여 기업별 의무가 공개되지 않았기 때문에 실제 정책 효과를 판단하기에는 정보가 부족하다.

또한 이는 미국의 새로운 AI 규제법이 통과됐거나 법적 의무가 생겼다는 의미가 아니다.

현재 확인되는 범위에서는 기업의 자율적인 안전 관리와 정부의 감독 논의를 연결하려는 정책적 합의에 가깝다.

향후 문서 전문과 감독위원회 구조가 공개되면 기업 자체 평가를 어느 정도 외부 검증과 연결할지, 그리고 자율규제와 법적 규제의 경계를 어떻게 정할지가 중요한 쟁점이 될 전망이다.

📚 추천 글

How we found 24 Android vulnerabilities using our open source AI security agent

저자: Kevin Stubbings
발행: GitHub Security Lab
게시일: 2026-09-28
원문: GitHub — How we found 24 Android vulnerabilities using our open source AI security agent

AI 보안 에이전트가 단순히 정적 분석 도구를 대신하는 것이 아니라 보안 전문가가 사용하는 사고 과정을 여러 단계의 taskflow로 구성하면 실제 취약점을 어디까지 찾을 수 있는지 보여주는 상세한 사례다.

GitHub Security Lab은 오픈소스 Taskflow Agent를 이용해 Android 앱을 분석했고, 글 작성 시점까지 총 24개의 취약점을 찾아 개발사에 신고했다고 밝혔다.

Taskflow의 핵심은 모델에게 “취약점을 찾아라”라는 거대한 프롬프트 하나만 주지 않는다는 것이다.

먼저 외부에서 들어오는 데이터를 받을 수 있는 **entry point(공격자가 영향을 줄 수 있는 코드 진입점)**를 분류하고, Android 특유의 Intent, exported activity, WebView, broadcast 같은 공격 표면을 따로 조사한다.

이후 각 진입점에 대해 자주 발생하는 취약점 클래스를 체크하고, 더 자유로운 분석도 여러 번 반복한다.

실제 사례 가운데 하나는 지도 앱 OsmAnd에서 발견됐다.

외부 앱이 실행할 수 있는 exported activity에 공격자가 조작 가능한 Intent extra가 전달되면서 앱 설정을 사용자 몰래 바꿀 수 있었다.

이를 이용하면 지도 타일의 서버 주소를 공격자가 운영하는 서버로 변경해 사용자가 보고 있는 위치와 이동 경로의 출발지·목적지를 알아낼 수 있었다.

OsmAnd의 Android 버전은 Google Play에서 1,000만 회 이상 다운로드된 앱이다.

Wikipedia Android 앱에서는 두 개의 논리 오류를 연결했다.

조작된 deep link를 통해 Wikipedia가 아닌 공격자 페이지를 앱 내부 WebView에서 열 수 있었고, 잘못된 도메인 검사와 결합하면 Wikipedia 쿠키가 공격자 페이지에 전달돼 계정 탈취로 이어질 수 있었다.

단순한 메모리 오류가 아니라 여러 컴포넌트 사이의 신뢰 관계를 이해해야 찾을 수 있는 logic vulnerability라는 점이 흥미롭다.

동시에 GitHub 연구자는 AI가 취약점의 심각도를 판단하는 데에는 여전히 약점이 있다고 지적한다.

실제로는 exploit이 불가능하거나 영향이 작은 문제도 심각하게 평가하는 false positive가 발생했고, 최종 판단에는 모바일 보안 전문가가 필요했다.

모델의 능력뿐 아니라 전문가가 어떤 문제를 작은 단계로 나누고 어떤 도구와 검증 과정을 제공하느냐가 결과를 좌우한다는 점을 실제 사례로 이해하기 좋은 글이다.

GLM-5.3-Flash Ran Out of Cache Snapshots, Not Cache Tokens

저자: HelixML
발행: HelixML Engineering Blog
게시일: 2026-09-26
원문: HelixML — GLM-5.3-Flash Ran Out of Cache Snapshots, Not Cache Tokens

LLM 서버의 성능 문제를 실제 운영 환경에서 추적하는 과정을 매우 구체적으로 보여주는 글이다.

HelixML은 GLM-5.3-Flash 기반 에이전트가 평소에는 약 1초 만에 답하기 시작하다가 가끔 8~10초, 한 번은 68초까지 지연되는 문제를 겪었다.

처음에는 KV cache가 부족하다고 생각했지만 실제 병목은 전혀 다른 곳에 있었다.

일반 Transformer의 attention layer는 이전 토큰 각각의 key와 value를 KV cache에 저장한다.

같은 긴 프롬프트를 다시 사용하면 이미 계산한 부분을 재사용해 첫 토큰이 나오기까지의 시간을 크게 줄일 수 있다.

그런데 GLM-5.3-Flash의 45개 언어 레이어 가운데 일반 attention은 11개뿐이고 나머지 34개는 KDA linear-attention layer다.

이 레이어들은 토큰별 KV를 저장하는 대신 지금까지 읽은 정보를 하나의 누적 상태로 압축한다.

따라서 중간 지점부터 계산을 다시 시작하려면 KV cache뿐 아니라 그 시점의 recurrent-state snapshot(누적 상태 스냅샷) 도 있어야 한다.

HelixML의 서버는 약 50만 토큰의 KV 공간을 가지고 있었지만 스냅샷 슬롯은 28개뿐이었다.

31만3천 토큰짜리 긴 프롬프트 하나를 처리하면서 51개의 스냅샷이 생성되자 다른 대화의 스냅샷이 모두 밀려났다.

KV cache는 72%밖에 차지 않았지만 사용할 수 있는 스냅샷이 없어 기존 프롬프트를 처음부터 다시 계산한 것이다.

해결책은 캐시 메모리를 무작정 늘리는 것이 아니었다.

SGLang에서 대화 하나가 유지할 수 있는 상태 스냅샷 개수를 제한하는 --mamba-max-states-per-path 설정을 사용했다.

최대 네 개로 제한한 실험에서는 6개 세션이 긴 프롬프트 처리 뒤에도 캐시를 유지했고, 응답 시작 시간이 기존 약 3.35초에서 0.15~0.30초로 줄면서 프롬프트의 99.6%를 재사용했다.

이후 실제 에이전트 특성을 고려해 제한을 두 개까지 줄였다.

최근 LLM이 Transformer만 사용하는 대신 linear attention, state-space model 같은 구조를 섞기 시작하면서 “KV cache 크기만 보면 추론 서버 용량을 알 수 있다”는 기존 상식이 더 이상 항상 맞지 않는다는 점을 보여준다.

모델 구조가 바뀌면 캐시의 정의와 병목도 함께 바뀐다는 것을 실제 장애 조사와 수치로 설명해, AI 인프라에 관심이 있다면 특히 읽을 가치가 있는 글이다.

Coding Agent Memory Post-training: 파일 시스템 자체를 에이전트의 장기 기억으로 학습시키기

저자: Lirui Luo 외 12명
발행: arXiv
게시일: 2026-09-28
원문: arXiv — Coding Agent Memory Post-training

장시간 움직이는 AI 에이전트에서 가장 큰 문제 가운데 하나는 작업 기록이 모델의 context window를 넘어가기 시작한다는 것이다.

몇 시간 전에 발견했던 원인이나 사용자의 조건, 이미 실패한 접근법이 대화창 밖으로 밀려나면 같은 실수를 반복할 수 있다.

최근에는 별도의 memory API나 vector database를 붙이는 방식이 많이 연구되고 있지만, 이 논문은 다른 접근을 택한다.

코딩 모델이 이미 익숙한 파일 시스템을 그대로 기억장치로 사용하게 학습시키는 것이다.

연구팀은 CAMG(Coding Agent Memory Gym) 라는 학습 환경을 만들었다.

쇼핑, 코딩, Deep Research, AutoResearch라는 서로 다른 네 종류의 장시간 작업에서 모델에게 일반적인 shell과 작업 도중 유지되는 workspace를 제공한다.

별도의 save_memory() 같은 특수 기능은 없다.

모델이 필요하다고 판단하면 Markdown이나 텍스트 파일을 만들고 수정하고 검색하고 다시 읽는 방식으로 직접 기억을 관리한다.

예를 들어 코딩 작업에서는 버그 원인과 이미 실행한 테스트를 파일에 적어두고 context가 교체된 뒤 다시 읽을 수 있다.

연구 작업에서는 이전 검색에서 발견한 근거와 아직 확인해야 할 내용을 파일에 쌓는다.

모델은 어떤 내용을 언제 저장할지 별도의 정답 데이터로 배우는 것이 아니라 최종 작업 성공 여부를 보상으로 받는 reinforcement learning(RL, 강화학습) 을 통해 이런 행동을 학습한다.

학습에는 fully asynchronous PPO가 사용됐다.

연구팀은 Qwen3.5 기반 4B와 9B 모델을 이 방식으로 학습했다.

네 가지 CAMG 테스트 환경 전체에서 파일 기반 메모리를 강화학습한 정책이 별도의 memory tool이나 단순한 context compaction 기반 접근보다 높은 평균 성공률을 보였으며, 외부 평가인 SWE-bench Verified와 MLE-bench Lite에서는 각각 훨씬 큰 Qwen3.5-35B-A3B와 122B-A10B 모델에 경쟁력 있는 결과를 냈다고 보고했다.

아직 단일 연구팀의 결과이며 추가 독립 검증이 필요하다.

이 논문의 관점이 흥미로운 이유는 “에이전트에게 어떤 특별한 기억 시스템을 만들어줄 것인가” 대신 모델이 이미 수많은 코드 저장소에서 배운 파일 읽기·쓰기 능력을 기억 관리에 재활용할 수 있지 않은가라고 질문하기 때문이다.

에이전트의 장기 기억이 별도의 거대한 인프라가 아니라 CONTINUATION.md 같은 작은 파일과 그것을 언제 쓰고 읽어야 하는지 아는 정책에서 시작할 수도 있다는 점을 보여주는 연구다.