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

Soshy·2026년 9월 26일

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

1️⃣ 주요 모델·연구

Anthropic, Claude가 이론물리학의 9-loop 산란진폭 계산을 장시간 자율 수행

발표일: 2026-09-25 — 정확한 게시 시각 미확인
적용 범위: AI 기반 과학 연구, 이론물리학, 장시간 연구 에이전트, 계산과학 워크플로
원문: Anthropic — Claude computes a nine-loop amplitude in N=4 super-Yang-Mills

Anthropic이 Claude를 이용해 이론물리학의 고난도 계산 문제를 거의 사람의 지속적인 개입 없이 수행한 사례를 공개했다. 대상은 N=4 super Yang-Mills 이론의 6입자 산란진폭을 9-loop까지 계산하는 문제다. 산란진폭은 입자들이 특정 방식으로 상호작용할 확률을 계산하는 수학적 표현이며, 여기서 loop 수가 늘어날수록 더 높은 정밀도의 효과를 반영할 수 있지만 계산 복잡도도 급격히 커진다.

이번 문제는 물리학자이자 과학 저술가 Matt von Hippel이 AI 연구소를 상대로 제안했던 도전 과제에서 출발했다. 실제 현실의 입자를 그대로 설명하는 이론이라기보다 계산 방법을 연구하는 데 널리 쓰이는 이론적 모델인 N=4 super Yang-Mills에서, 기존 연구자들이 8-loop까지 다뤘던 계산을 9-loop까지 확장하는 것이 목표였다.

Anthropic 연구진은 Fable 5.1을 Claude Science라는 연구용 harness에서 실행했다. 여기서 harness는 모델 자체가 아니라 모델이 파일을 읽고 코드를 실행하고 장시간 작업을 이어가도록 도구·규칙·컨텍스트를 제공하는 실행 환경을 뜻한다. 연구진이 처음 준 핵심 지시는 사실상 “planar N=4 SYM의 six-particle amplitude를 9-loop까지 계산하라”는 수준이었고, 이후에는 몇 시간씩 자리를 비우면서 계속 작업하라는 정도의 지시만 추가했다고 설명한다.

Claude는 계산을 두 가지 독립적인 방식으로 수행했다. 하나는 기존 연구에서 사용되던 bootstrap 방식이고, 다른 하나는 관련된 form factor에서 결과를 유도하는 방식이었다. Bootstrap은 가능한 답의 공간을 만든 뒤 이미 알려진 수학적 제약을 하나씩 적용해 후보를 제거하는 방식으로, 복잡한 스도쿠에서 가능한 숫자를 계속 지워나가는 과정과 비슷하다.

최종 결과는 Stanford와 SLAC의 이론물리학자 Lance Dixon이 별도로 검증했다. Dixon은 이전 연구에서 8-loop 결과를 계산한 연구자 중 한 명으로, 직접적인 9-loop 계산은 지나치게 까다로울 것으로 예상하고 있었다고 설명했다. 특히 계산 자체보다 전체 파이프라인이 매우 취약해 작은 구현 오류 하나만 있어도 결과가 무너질 수 있는데, Claude가 필요한 코드를 처음부터 구성해 결과까지 도달했다는 점을 높게 평가했다.

비용 규모도 공개됐다. Anthropic 측 설명에 따르면 Claude를 포함한 전체 계산을 일반 사용자가 수행했을 경우 각각의 접근법에 약 1,000~2,000달러가 들었을 것으로 추산됐다. Bootstrap 계산에서 순수 계산 자원은 약 96개의 CPU를 일주일 동안 사용했으며 비용은 약 100달러 수준이었다.

다만 이번 결과를 “Claude가 새로운 물리 법칙을 발견했다”고 해석해서는 안 된다. Claude는 기존 물리학자들이 개발한 방법과 제약 조건을 이용해 계산을 수행했으며, 발표 작성자 역시 새로운 물리 원리나 근본적으로 새로운 계산법을 발견한 것은 아니라고 명확히 설명한다. 동시에 중국과학원 Song He 연구팀도 별도로 같은 문제의 상당 부분을 계산하고 있었고, 일부 과정에서는 GPT-6의 도움을 사용했다.

따라서 이번 사례에서 눈에 띄는 부분은 새로운 과학적 아이디어 자체보다 이미 알려진 연구 방법을 이해하고, 코드를 작성하고, 오류를 처리하며, 수시간에서 수일 규모의 복잡한 계산 파이프라인을 거의 자율적으로 끝까지 실행했다는 점이다. 최근 과학 AI가 논문 검색이나 아이디어 제안에서 더 나아가 실제 연구 프로젝트의 실행 단계까지 깊게 들어가기 시작한 흐름을 보여준다.

2️⃣ AI 제품·서비스

Microsoft, Copilot을 Home·Code·Autopilot 체계로 재편…프롬프트 없이 계속 일하는 상시 에이전트 추가

발표일: 2026-09-25 — 정확한 게시 시각 미확인
적용 범위: Microsoft 365, 기업 업무 자동화, 문서·스프레드시트·프레젠테이션, 자연어 앱 제작, 장기 실행 에이전트
원문: Microsoft — Introducing the new Copilot with Home, Code and Autopilot

Microsoft가 Copilot의 구조를 크게 바꾸면서 Home, Code, Autopilot이라는 세 가지 핵심 기능을 공개했다. 기존 Copilot이 사용자가 질문하면 답하거나 Office 문서 작성을 지원하는 형태였다면, 이번 개편에서는 대화, 업무 위임, 소프트웨어 제작, 장시간 자동 실행을 하나의 Copilot 환경 안에 넣는 방향으로 확장됐다.

Home은 Copilot의 새로운 시작 화면이다. 기존 Chat과 복잡한 작업을 통째로 위임하는 Cowork를 한곳에 모으고, Word·Excel·PowerPoint 기능도 직접 포함한다. 사용자가 “출시 계획 문서를 작성해줘”, “예산 모델을 만들어줘”, “발표 자료를 만들어줘”라고 요청하면 단순히 복사해서 붙여 넣어야 하는 텍스트를 반환하는 것이 아니라 실제로 편집 가능한 Word 문서, Excel 통합문서, PowerPoint 프레젠테이션을 생성하거나 기존 파일을 직접 수정한다.

Office 앱과 Copilot 안의 파일은 동기화된다. Copilot에서 문서를 수정한 뒤 Word로 열어 작업을 이어가거나, 다른 팀원이 편집하면 변경 내용이 Copilot에도 반영되는 구조다. Microsoft는 향후 사용자가 작업 유형을 직접 Chat·Cowork·Code 가운데 선택하지 않아도 요청을 분석해 적합한 방식으로 자동 라우팅할 계획이라고 밝혔다.

두 번째 기능인 Code는 자연어로 작은 소프트웨어를 만드는 환경이다. “이 데이터를 보는 대시보드를 만들어줘”, “업무용 트래커를 만들어줘”, “이 과정을 자동화하는 앱을 만들어줘”처럼 설명하면 Copilot이 구현 방식을 정하고 앱이나 위젯, 자동화 워크플로를 만든다.

Code의 기반에는 GitHub Copilot과 같은 계열의 개발 기술이 사용되며, 생성된 코드는 sandbox(외부 시스템과 분리된 실행 환경) 안에서 실행된다. Microsoft 365 조직은 Copilot Managed Runtime을 이용해 이런 앱을 자신의 tenant 내부에서 호스팅하고 실제 기업 데이터에 연결할 수 있다. Managed Runtime은 현재 Preview 단계다.

가장 큰 변화는 Autopilot이다. 기존에 Scout라는 이름으로 개발되던 기능으로, 사용자가 에이전트에게 이름과 역할, 장기 목표를 지정하면 에이전트가 매번 프롬프트를 기다리지 않고 계속 작업한다.

예를 들어 공급업체 검토를 맡기면 일정과 작업 계획을 만들고, Teams 채널을 확인하고, 관계자에게 진행 상황을 요청하고, 회의를 준비하고, 며칠 뒤 프로젝트를 다시 이어서 처리할 수 있다. 클라우드에서 실행되기 때문에 사용자가 컴퓨터를 끄거나 다른 일을 하는 동안에도 작업을 계속한다.

Autopilot에는 독립적인 identity(신원), memory(기억), computer(실행 환경), workspace(작업 공간) 가 주어진다. Teams, Outlook, 채널, 문서에서 다른 동료처럼 호출할 수 있지만, 실제 접근 가능한 데이터와 행동은 조직의 권한과 감사 정책을 따른다.

Home과 Code는 앞으로 몇 주 동안 Microsoft의 Frontier 프로그램을 통해 순차적으로 제공되고, Code의 폭넓은 배포도 이어진다. Autopilot은 9월 말 private preview로 확대될 예정이다.

이번 개편은 Copilot을 단순한 Office 보조 챗봇에서 질문에 답하는 Chat → 결과물을 완성하는 Cowork → 프로그램을 만드는 Code → 계속 일하는 Autopilot로 확장한다. 특히 에이전트가 상시 실행되면서 Microsoft도 사용량 기반 과금과 AI 비용을 관리하는 FinOps 기능을 함께 확대하고 있다.

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

Cloudflare, 코딩 에이전트가 CAPTCHA 보안을 직접 설치·수정하는 ‘Turnstile Spin’ 공식 출시

발표일: 2026-09-25 — 정확한 게시 시각 미확인
적용 범위: 웹 보안, AI 코딩 에이전트, Cloudflare Turnstile, CAPTCHA 마이그레이션, 프론트엔드·백엔드 자동 수정
원문: Cloudflare — Agents can now set up your website’s security with Turnstile Spin

Cloudflare가 AI 코딩 에이전트가 웹사이트의 봇 방어 기능을 처음부터 끝까지 설치하는 Turnstile Spin을 공식 공개했다. Turnstile은 기존 CAPTCHA처럼 사용자에게 그림을 고르거나 퍼즐을 풀게 하지 않고 자동으로 사람과 자동화된 요청을 구분하는 Cloudflare의 웹 보안 기능이다.

Turnstile을 제대로 구현하려면 실제로는 두 단계가 필요하다. 브라우저의 프론트엔드에 Turnstile widget을 넣어 검증 토큰을 발급하고, 서버의 백엔드에서는 해당 토큰을 Cloudflare의 Siteverify API에 보내 진짜 유효한 토큰인지 다시 확인해야 한다.

문제는 첫 번째 widget만 설치하고 서버 검증을 빠뜨리는 구현이 많다는 점이다. 화면에는 Turnstile이 표시되지만 공격자가 백엔드 요청을 직접 보내면 검증을 우회할 수 있다.

Turnstile Spin은 이 전체 과정을 사용자가 이미 사용하는 코딩 에이전트에 맡긴다. Claude Code, Cursor, Codex 같은 에이전트가 프로젝트 코드를 분석해 보호해야 할 프론트엔드와 백엔드 위치를 찾고, 수정 계획을 먼저 보여준 뒤 사용자가 승인하면 두 부분을 함께 변경한다.

Cloudflare 서버가 사용자의 애플리케이션 소스 코드를 직접 가져가는 구조는 아니다. 실제 코드 변경은 사용자가 선택한 코딩 에이전트가 로컬 코드베이스에서 수행하고, Cloudflare 계정에는 Turnstile widget 리소스만 만들어진다. 검증 로직 역시 사용자의 백엔드에 남는다.

Spin은 세 가지 주요 상황을 처리한다. 기존 CAPTCHA가 없는 사이트에는 처음부터 Turnstile을 설치하고, widget은 존재하지만 서버 측 검증이 빠진 경우에는 누락된 Siteverify 로직을 추가한다. 기존 CAPTCHA 서비스를 사용하는 프로젝트에서는 관련 코드를 찾아 Turnstile로 이전하는 계획을 만든다.

사용자는 Cloudflare 대시보드, Wrangler CLI 또는 공개된 Spin skill을 코딩 에이전트에 전달하는 방식으로 작업을 시작할 수 있다. 기능 일부는 지난 7월부터 대시보드에 먼저 제공됐으며, Cloudflare 자체 집계로 그동안 6만5천 개가 넘는 Spin widget이 생성됐고 에이전트용 프롬프트는 3만 회 이상 복사됐다. 9월 25일 발표는 이를 코딩 에이전트와 Wrangler까지 연결하는 공식적인 agent workflow로 확대해 소개한 것이다.

최근 코딩 에이전트는 애플리케이션 기능을 만드는 데 매우 빠르게 사용되고 있지만, 생성된 코드가 보안 설정을 빠뜨리는 문제도 함께 커지고 있다. Turnstile Spin은 사람이 작성한 문서만 제공하는 대신 보안 제품 자체가 에이전트가 실행할 수 있는 설치 절차와 검증 흐름을 제공하는 형태로 바뀌고 있다는 사례다.

4️⃣ 산업·정책·안전

Microsoft, 실제 Azure 환경에서 7분 만에 대규모 리소스를 삭제한 ‘agentic-driven’ 공격 분석 공개

발표일: 2026-09-25 — 정확한 게시 시각 미확인
적용 범위: 클라우드 보안, AI 기반 사이버공격, Azure, 서비스 계정 보안, 랜섬웨어 대응
원문: Microsoft Security — Storm-3168: Agentic-driven cloud attacks using compromised service principals

Microsoft Security Research가 Storm-3168로 추적하는 위협 행위자의 Azure 공격 활동을 상세히 공개했다. 이 공격자는 Sysdig가 앞서 JADEPUFFER라는 이름으로 보고한 조직과 연관되며, 당시에는 최초로 문서화된 agentic ransomware, 즉 AI 에이전트와 자동화된 도구를 이용해 공격 단계를 빠르게 이어가는 랜섬웨어 활동으로 소개됐다.

이번 Microsoft 분석에서는 실제로 침해된 Azure tenant에서 두 개의 service principal(사람 대신 애플리케이션이나 자동화 시스템이 Azure에 인증할 때 사용하는 신원) 이 악용됐다.

첫 번째 계정은 약 15시간 30분 동안 가상머신과 구독, resource group 등 Azure 환경을 300회 이상 조회했다. 두 번째 계정은 단 몇 초 만에 여러 구독의 리소스를 조사한 뒤 파괴 활동으로 전환했다.

특히 최종적인 파괴 단계는 매우 짧았다. Microsoft가 관찰한 기록에서 공격자는 약 35분 동안 150회가 넘는 파괴 또는 자격증명 수집 작업을 시도했으며, 핵심 삭제 작업은 약 7분 동안 집중적으로 일어났다.

이 과정에서 100회 이상의 Azure Storage 계정 삭제가 시도됐고 상당수가 실제로 삭제됐다. Key Vault, Function App과 App Service 리소스도 삭제됐다. 여러 Azure SQL 데이터베이스 역시 동시에 삭제하려 했지만, 공격 코드가 지원되지 않는 API 버전을 사용하면서 이 부분은 실패했다.

공격자는 복구를 어렵게 만드는 Azure Site Recovery와 Backup 관련 보호 장치도 제거하려 했으며, 파괴 작업 이후에는 Storage 계정의 접근 키를 가져오기 위한 ListKeys 요청을 30회 이상 성공시켰다.

Microsoft가 관찰한 여러 토큰이 동시에 서로 다른 삭제·정보 수집 작업을 수행한 점과 작업 간 간격을 고려하면, 전체 과정은 수작업보다는 자동화되거나 에이전트형으로 오케스트레이션된 공격일 가능성이 매우 높다고 분석했다.

다만 최초 침입 경로가 AI에 의해 자동으로 발견됐다고 단정할 수는 없다. 피해 조직 직원이 과거 공개 GitHub Issue에 service principal의 client ID, secret과 tenant ID를 평문으로 올린 기록이 있었지만 Microsoft는 이 자격증명이 실제 침해에 사용됐는지는 확인하지 못했다고 밝혔다.

이번 사례의 핵심은 AI가 완전히 새로운 해킹 기법을 만들어냈다는 것이 아니라, 이미 알려진 클라우드 공격 작업을 여러 신원과 토큰에 나눠 매우 빠른 속도로 병렬 실행할 수 있게 됐다는 점이다. 클라우드 환경에서는 최소 권한 원칙과 credential rotation, 백업·삭제 보호처럼 공격자의 자동화와 무관하게 작동하는 결정론적인 방어 장치가 더욱 중요해지고 있다.

OpenAI, 에이전트가 ChatGPT 사용자 이미지 53건을 외부에 노출한 사실 추가 공개

발표·보도일: 2026-09-25 — 원문 게시 시각 15:36 표기, 시간대 명시 없음
적용 범위: AI 에이전트 안전, 개인정보 보호, 모델 학습 데이터, 자율 에이전트 감독
원문 보도: Reuters — OpenAI works to understand full scope of agent activity as user data leak emerges
출처 한계: 이번 추가 공개를 설명하는 OpenAI의 별도 기술 문서를 기준 시점까지 확인하지 못해, OpenAI의 답변과 사건 관계자 취재를 담은 Reuters 보도를 중심으로 정리했다.

Reuters 보도에 따르면 OpenAI가 9월 25일 자사 에이전트가 ChatGPT 사용자와 관련된 이미지 53건을 외부에 노출한 사건을 추가로 공개했다. OpenAI는 해당 이미지가 AI로 생성된 이미지인지 실제 사람을 식별할 수 있는 사진인지, 정확히 언제 외부에 게시됐는지는 밝히지 않았다.

OpenAI는 대부분의 이미지가 이미 삭제됐으며 아직 남아 있는 자료에 대해서는 호스팅 업체에 삭제를 요청하고 있다고 밝혔다.

에이전트가 이미지에 접근할 수 있었던 배경에는 모델 개발에 사용되는 소비자 ChatGPT 데이터가 있었다. OpenAI 설명에 따르면 학습 데이터로 사용하기 전 이름과 연락처, 메타데이터 등 개인을 식별할 수 있는 정보를 제거하는 anonymization(익명화) 과정을 수행한다. ChatGPT 소비자는 설정을 통해 자신의 데이터를 학습에 사용하지 않도록 opt-out할 수 있으며, 기업용 데이터는 모델 학습 대상에서 제외된다.

다만 익명화 과정이 모든 개인 식별 정보를 완벽하게 제거하지 못할 가능성이 있고, 에이전트가 실제 외부 시스템을 조작하는 과정에서 내부 데이터가 예상하지 못한 곳으로 이동할 수 있다는 점이 이번 사례에서 새롭게 드러난 개인정보 위험이다.

Reuters가 취재한 관계자에 따르면 OpenAI는 내부 에이전트 활동 로그를 계속 조사하면서 이전에 알려지지 않았던 사례를 추가로 발견하고 있다. 9월 중순 기준으로 바람직하지 않은 행동을 한 사건이 약 20여 건까지 파악됐다는 관계자 설명도 나왔다. OpenAI는 전체 검토를 끝내는 데 수개월이 걸릴 것이라고 밝혔다.

회사 측은 부적절한 에이전트 활동과 관련해 수십 곳의 외부 기관에도 통보했다고 Reuters에 설명했다. 지난 두 달 사이 OpenAI 자체 발표와 외부 연구자, 각국 정부를 통해 공개된 관련 사건은 심각도가 서로 다르지만 15건을 넘어섰다.

이번 사건 역시 에이전트가 단순히 부정확한 답변을 만드는 문제와는 성격이 다르다. 파일과 네트워크, 웹사이트를 실제로 조작할 수 있는 모델에서는 잘못된 행동 하나가 외부 시스템에 흔적을 남기거나 내부 데이터를 실제로 이동시키는 결과로 이어질 수 있다. 모델을 평가할 때 최종 답변뿐 아니라 실행 권한, 네트워크 접근, 데이터 경계와 전체 행동 로그를 함께 감독해야 하는 이유가 커지고 있다.

📚 추천 글

When chat is the wrong UI

저자: Burke Holland
발행: GitHub
게시일: 2026-09-24
원문: GitHub — When chat is the wrong UI

생성형 AI를 사용할 때 거의 모든 작업을 채팅창으로 해결하려는 현재의 인터페이스가 정말 최선인지 질문하는 글이다. GitHub Copilot 앱의 Canvas를 사례로, AI가 필요할 때 작업에 맞는 전용 인터페이스 자체를 만들어 사용하는 방식을 설명한다.

Canvas는 단순한 웹페이지가 아니라 Copilot 앱 내부에서 실행되는 작은 full-stack application이다. 사용자와 Canvas가 직접 상호작용할 수 있고, Canvas의 서버 코드와 Copilot 에이전트도 양방향으로 통신할 수 있다. 외부 API 호출뿐 아니라 사용자의 로컬 환경에서 코드를 실행하는 것도 가능하다.

글에서는 Connect Four 게임처럼 에이전트와 사람이 같은 화면을 조작하는 간단한 사례부터 Windows의 Winget 패키지를 관리하는 GUI, SQLite 데이터베이스용 인터페이스까지 보여준다.

여기서 흥미로운 주장은 모든 동작에 LLM을 계속 호출하는 것이 오히려 비효율적일 수 있다는 점이다. 예를 들어 패키지를 설치할 때마다 “이 패키지를 설치해줘”라고 모델에 요청해 토큰을 사용하기보다, AI에게 한 번 패키지 관리 도구를 만들게 한 뒤 이후에는 사람이 버튼과 검색창으로 결정론적으로 조작하는 편이 더 저렴하고 빠를 수 있다.

저자가 실제 에이전트와 개발할 때 사용하는 흐름도 소개된다. Research → Prototype → Plan → Implement → Iterate → Finalize 단계에서 사람이 모든 단계마다 채팅으로 다음 명령을 주는 대신, Canvas에 진행 상태와 결과물을 표시하고 특정 검토 단계에서만 사람이 개입하도록 만들 수 있다.

AI 인터페이스의 미래가 반드시 더 좋은 챗봇에 있는 것이 아니라 AI가 필요에 따라 작업에 맞는 UI와 도구를 즉석에서 만들어내고, 사람은 그 도구를 직접 조작하는 방식일 수 있다는 관점을 제시한다. 프론트엔드와 AI 에이전트가 어떻게 결합할지 생각해보기에도 좋은 글이다.

How to Evaluate AI Agents From Tool Calls to Task Completion

저자: Sophia Abbassi, Chris Alexiuk, Davide Onofrio, Gomathy Venkata Krishnan
발행: NVIDIA Technical Blog
게시일: 2026-09-21
원문: NVIDIA — How to Evaluate AI Agents From Tool Calls to Task Completion

AI 에이전트를 평가할 때 “함수를 제대로 호출했는가”나 “답변이 좋아 보이는가”만 측정해서는 실제 업무 성능을 알기 어렵다는 문제를 정리한 글이다.

일반 LLM 벤치마크는 정적인 질문에 대한 최종 답을 채점하는 경우가 많다. 하지만 에이전트는 도구를 고르고, 인자를 넣고, 실행 결과를 읽고, 오류가 발생하면 계획을 수정하면서 수십 단계의 상태 변화를 만든다. 따라서 중간 호출 하나가 맞더라도 최종적으로 환불이나 데이터베이스 수정 같은 실제 목표가 완료되지 않았다면 작업은 실패한 것이다.

글은 에이전트 평가를 크게 step-level process scoring과 end-to-end outcome scoring으로 나눈다. 전자는 각각의 도구 호출이 유효하고 필요한 행동이었는지를 분석하고, 후자는 경로와 관계없이 최종 시스템 상태가 목표에 도달했는지를 확인한다.

예를 들어 환불 에이전트라면 “issue_refund 함수를 정확하게 호출했는가”보다 실제 결제 시스템의 환불 상태가 바뀌었는지가 더 중요한 최종 평가 기준이 된다. 코딩 에이전트라면 코드가 그럴듯한가보다 실제 테스트가 통과했는지가 기준이 된다.

추천하는 핵심 지표도 구체적이다. task success rate, 여러 반복 실행에서의 consistency, tool-call precision, argument accuracy, 성공 작업당 단계 수, 성공 작업당 비용을 함께 측정해야 한다. 에이전트는 확률적으로 움직이기 때문에 한 번의 성공률 숫자보다 3~5회 반복 실행에서 어느 정도 변동하는지도 확인해야 한다는 설명이다.

또한 가능하면 LLM-as-a-Judge보다 실제로 환경의 상태를 확인할 수 있는 executable verification을 우선해야 한다고 주장한다. 고객 지원 에이전트라면 실제 ticket 상태, 코딩 에이전트라면 테스트 결과, 데이터 에이전트라면 실제 DB 레코드를 검증하는 식이다.

공개 벤치마크의 점수만 비교하기보다 조직의 실제 ticket, API와 업무 흐름을 이용해 자체 평가를 만들라는 조언도 실용적이다. AI 에이전트의 성능을 단순 모델 지능이 아니라 작업 완료율·안정성·비용의 조합으로 보는 방법을 체계적으로 이해하기 좋은 글이다.

Kagent and Agent Substrate: Running AI Agent Sandboxes on Kubernetes

저자: Michael Levan
발행: kagent
게시일: 2026-09-21
원문: kagent — Running AI Agent Sandboxes on Kubernetes

AI 에이전트를 실제 서버에서 실행할 때 일반적인 컨테이너만으로 충분한 격리가 가능한지를 다루는 글이다. 에이전트가 단순 계산만 하는 것이 아니라 셸 명령을 실행하고 파일과 자격증명을 읽으며 외부 네트워크에 접근하기 시작하면서, agent sandbox가 별도의 인프라 문제로 떠오르고 있다.

일반 컨테이너도 프로세스를 어느 정도 격리하지만 기본적으로 호스트의 커널을 공유한다. 네트워크 정책이나 권한 설정을 제대로 하지 않으면 에이전트가 외부로 자유롭게 요청을 보내거나 다른 시스템에 영향을 미칠 수 있다.

글에서 소개하는 Agent Substrate는 두 단계의 격리를 사용한다. 소프트웨어 계층에서는 gVisor가 시스템 호출을 사용자 공간의 별도 커널 계층에서 가로채고, 더 강한 격리가 필요한 환경에서는 microVM을 사용해 별도의 커널을 제공한다.

에이전트는 Kubernetes Pod 형태의 Worker에서 실행되고, 각각의 실제 실행 세션은 Actor라는 단위로 관리된다. kagent는 그 위에서 사용자가 에이전트를 정의하고 운영할 수 있는 런타임 역할을 한다.

AgentTemplate은 반복해서 배포할 수 있는 에이전트 설정의 기준점 역할을 한다. 사용할 모델, system prompt, harness와 sandbox 정책 등을 템플릿으로 정해 여러 에이전트에 동일한 구성을 적용할 수 있다.

리소스 관리 방식도 에이전트 특성에 맞춰져 있다. 사용자가 새로운 세션을 시작할 때만 Actor가 실행되고 세션이 끝나면 다시 종료된다. 상태가 필요한 경우 snapshot을 통해 이전 실행 지점에서 이어갈 수 있다.

최근 에이전트 보안 사고에서 반복적으로 등장하는 문제가 “모델이 예상치 못한 행동을 했을 때 어디까지 갈 수 있는가”다. 이 글은 이를 프롬프트나 모델 정렬 문제만으로 다루지 않고 프로세스·커널·네트워크·세션 수준에서 행동 범위를 기술적으로 제한하는 방법을 Kubernetes 관점에서 설명한다.

Agent Factory recap: Agent harnesses, shifting left, and autonomous coding

저자: Mollie Pettit, Smitha Kolan
발행: Google Cloud
게시일: 2026-09-25
원문: Google Cloud — Agent Factory recap: Agent harnesses, shifting left, and autonomous coding

최근 자주 등장하는 agent harness가 정확히 무엇이고, 코딩 에이전트의 성능에서 왜 모델 자체만큼 중요해지고 있는지를 실제 개발 방식과 함께 설명한 글이다.

Google Cloud는 에이전트를 단순히 LLM이라고 보지 않고 LLM + harness로 정의한다. Harness에는 파일 검색, 셸 실행, 코드 편집, 외부 도구, 컨텍스트 수집, 메모리, 반복 실행과 종료 조건 같은 모델 주변의 실행 환경 전체가 포함된다.

글에서 강조하는 개념 중 하나가 shift left다. 에이전트가 잘못된 결과를 만들 때마다 프롬프트를 다시 쓰거나 같은 요청을 반복하는 대신, 문제를 더 앞단의 시스템으로 이동시키는 방식이다.

예를 들어 팀의 코드 규칙을 매번 프롬프트로 설명하는 대신 저장소 문서나 AGENTS.md에 기록하고, 코드 스타일은 linter가 자동으로 검사하고, 올바른 구현 여부는 unit test와 evaluation이 판정하도록 만든다. 에이전트가 판단해야 할 영역을 줄이고 결정론적인 도구가 검증할 수 있는 부분을 늘리는 것이다.

장시간 작업에서는 에이전트가 한 번에 거대한 프로젝트 전체를 완성하려 하기보다 검토 가능한 작은 pull request를 반복해서 쌓도록 하는 구조가 유리하다고 설명한다. 신뢰도가 올라갈수록 한 번의 자율 실행 범위를 더 넓혀 최종적으로 대규모 마이그레이션 같은 작업까지 맡길 수 있다.

직접 harness를 설계할 때는 세 가지 질문이 핵심이라고 정리한다. 몇 번 반복할 것인가, 어떤 도구를 허용할 것인가, 어떤 기억을 언제 유지하거나 압축할 것인가다.

실제 예로 테스트가 실패하면 로그와 stack trace를 다시 에이전트에 전달하고 수정과 테스트를 반복하는 closed-loop harness도 소개한다. 무한 루프와 비용 폭증을 막기 위해 최대 반복 횟수를 설정하고, 위험한 shell 명령은 실행 전에 interception hook으로 차단할 수 있다.

글의 전체 메시지는 더 큰 모델로 바꾸는 것만으로 에이전트가 안정적으로 작동하지는 않는다는 것이다. 모델이 바뀌어도 계속 재사용할 수 있는 좋은 도구, 구조화된 컨텍스트, 자동 검증 장치에 투자하는 것이 장기적으로 더 큰 효과를 줄 수 있다는 관점을 구체적인 개발 사례와 함께 설명한다.