AI 데일리 브리핑 — 2026-10-05
Soshy·
기준 시점: 2026-10-05 06:00 KST (Asia/Seoul)
AI 동향 조사 범위: 2026-10-04 06:00 ~ 2026-10-05 06:00 KST
추천 글 범위: 2026-09-28 06:00 ~ 2026-10-05 06:00 KST
1️⃣ 주요 모델·연구
이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.
2️⃣ AI 제품·서비스
이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.
3️⃣ 개발 도구·에이전트
이번 조사 범위에서 포함할 만한 주요 신규 발표를 확인하지 못했습니다.
4️⃣ 산업·정책·안전
미국, ‘Super Intelligence Force’ 출범…정보·소비자보호·국방 조직 묶어 연방 AI 정책 조정
- 발표 시각: 2026-10-04 21:23 KST (미국 동부시간 08:23)
- 적용 범위: 미국 연방 AI 정책, AI 안전·사고 보고, 국가안보·사이버보안, 소비자 보호, 정부 AI 거버넌스
- 원문: Donald Trump — Truth Social announcement
- 관련 원문 보도: Reuters — Trump names intelligence chief Clayton as AI czar, to head task force
- 출처 한계: 태스크포스의 설립과 주요 참여자, 이해관계자 협의 범위는 대통령의 공식 게시물에서 확인된다. 120일 보고서와 사고 보고 체계 검토 등 세부 임무는 Reuters가 확인한 관련 보도를 기준으로 정리했으며, 기준 시점까지 별도의 백악관 정식 charter 전문은 확인하지 못했다.
도널드 트럼프 미국 대통령이 새로운 연방 AI 태스크포스인 Super Intelligence Force(SIF) 출범을 발표했다. 지난 9월 말 미국 정부와 주요 AI 기업들이 참여한 White House Accord에 이어, 여러 정부기관에 흩어진 AI 관련 정책과 위험 대응을 하나의 범정부 조직에서 조정하려는 후속 조치다.
여기서 “Super Intelligence”는 미국 정부가 이번 조직에 붙인 정책 용어이지, 인간을 뛰어넘는 초지능 AI가 실제로 개발됐다는 의미는 아니다. 현재 공개된 임무는 프런티어 AI의 기술 발전과 위험, 산업 경쟁력, 소비자 보호, 국가안보 문제를 연방정부 차원에서 함께 검토하는 데 가깝다.
SIF는 국가정보국장 Jay Clayton이 이끌며, 연방거래위원회(FTC) 위원장 Andrew Ferguson, 국방부 연구·엔지니어링 담당 차관 겸 CTO Emil Michael, 연방인사관리처(OPM) 국장 Scott Kupor 등이 참여한다. 조직은 대통령과 백악관 비서실장 Susie Wiles에게 보고하는 구조다.
참여 기관 구성이 넓다는 점이 눈에 띈다. 국가정보국은 국가안보와 해외 AI 경쟁을, FTC는 소비자 보호와 기업의 안전 책임을, 국방부는 고성능 AI와 사이버·군사 기술을, OPM은 연방정부 인력과 행정 체계를 담당한다. 최근 AI 정책이 모델 규제만의 문제가 아니라 보안 사고, 정부 조달, 노동력, 핵심 인프라와 산업 경쟁력까지 하나의 시스템으로 연결되는 방향으로 이동하고 있음을 보여준다.
트럼프 대통령의 발표문은 SIF가 소비자, 공익단체, 종교단체, 핵심 인프라 사업자와 AI 기업 등의 의견을 조율한다고 설명한다. Reuters가 확인한 관련 보도에 따르면 태스크포스는 향후 120일 안에 AI의 위험과 기회, 연방정부가 맡아야 할 역할을 정리한 보고서를 제출할 예정이다.
보고 범위에는 AI와 관련된 보안 침해, 해킹, 기타 사고를 어떤 방식으로 정부에 보고할지와 현재 연방정부가 가진 법적 권한으로 어떤 대응을 할 수 있는지도 포함될 것으로 전해졌다. 최근 에이전트가 브라우저, 코드 실행 환경, 기업 시스템에 직접 접근하기 시작하면서 단순한 모델 출력 문제가 아니라 AI가 실제 외부 시스템에서 일으킨 사고를 누가 기록하고 어느 기관이 대응할 것인가가 정책 문제로 부상한 상황과 연결된다.
다만 SIF 출범 자체가 새로운 AI 규제법을 만든 것은 아니다. 별도의 법률이 통과된 것도 아니며, 현재 공개된 구조는 여러 기관의 정책과 조사·대응 기능을 조정하고 향후 정책 방향을 제안하는 태스크포스에 가깝다. 실제 규제 효과는 앞으로 공개될 세부 charter와 120일 보고서, 그리고 기존 FTC·정보기관·국방기관의 권한을 어떤 방식으로 연결할지에 따라 달라질 가능성이 크다.
트럼프 행정부는 전반적으로 AI 개발 속도를 늦추는 강한 사전 규제보다는 미국 기업의 경쟁력과 빠른 기술 개발을 강조해왔다. 동시에 최근 자율 에이전트 사고와 사이버보안 위험을 둘러싼 연방·주정부 조사가 잇따르고 있어, SIF는 빠른 AI 개발을 유지하면서 사고 보고와 위험 대응을 어느 수준까지 중앙화할 것인지를 결정하는 새로운 정책 축이 될 가능성이 있다.
📚 추천 글
We’re going to need default hard budget caps on pretty much everything
- 저자: Simon Willison
- 발행: Simon Willison’s Weblog
- 게시일: 2026-10-03
- 원문: Simon Willison — We’re going to need default hard budget caps on pretty much everything
AI 에이전트 시대에는 API 서비스의 비용 관리 방식도 바뀌어야 한다는 짧지만 실용적인 글이다. 핵심 주장은 사용량 기반 서비스를 제공하는 회사라면 기본적으로 hard budget cap을 제공해야 한다는 것이다.
Hard budget cap은 비용이 일정 금액을 넘으면 경고 메일을 보내는 수준이 아니라 실제로 추가 사용을 차단하는 한도를 의미한다. 기존 클라우드 서비스에서는 예산을 초과하면 알림을 보내는 soft limit이 흔했지만, 사용자가 직접 API를 호출하는 환경에서는 그나마 문제가 발생했을 때 빠르게 대응할 수 있었다.
AI 에이전트에서는 상황이 달라진다. 코딩 에이전트나 개인 에이전트가 사용자가 자리를 비운 동안에도 여러 시간 동안 API와 외부 서비스를 반복 호출할 수 있기 때문이다. 잘못된 반복문이나 예상하지 못한 tool call 하나만으로도 사용자가 알아차리기 전에 상당한 비용이 발생할 수 있다.
Willison은 이런 환경에서는 서비스가 실패하면서 오류를 반환하는 편이 예상하지 못한 수천 달러짜리 청구서를 받는 것보다 훨씬 안전하다고 주장한다. 예산을 넘기면 작업이 중단되는 것이 불편하더라도, 사용자가 직접 한도를 올리는 명시적인 행동을 거치도록 하는 편이 낫다는 것이다.
글에서는 AWS가 최근 일부 환경에서 프로젝트 단위 spend limit을 제공하기 시작했고 Google Cloud도 올해 Spend Caps를 도입한 사례를 언급한다. 앞으로 에이전트가 새로운 API 서비스를 스스로 선택하는 상황이 늘어나면 에이전트 자체가 hard cap을 지원하는 서비스를 우선 선택하는 정책도 필요할 수 있다고 본다.
최근 에이전트 운영에서는 토큰 비용뿐 아니라 검색 API, 브라우저 실행, 코드 샌드박스, 데이터베이스, 메시지 발송 등 수많은 외부 서비스 비용이 하나의 작업에 묶인다. 이 글은 에이전트의 안전 문제를 권한이나 보안 공격만이 아니라 경제적 권한과 비용 한도의 문제로 바라봐야 한다는 점을 간결하게 설명한다.
Agents Don’t Need Memory. They Need Documentation.
- 저자: Kevin Liao
- 발행: liao.gg
- 게시일: 2026-10-03
- 원문: Kevin Liao — Agents Don’t Need Memory. They Need Documentation.
AI 코딩 에이전트의 장기 기억 문제를 해결하기 위해 vector database와 memory plugin을 붙이는 흐름에 의문을 제기하고, 구조화된 문서 자체가 더 좋은 장기 기억장치가 될 수 있다고 주장하는 글이다.
현재 많은 agent memory 시스템은 이전 세션의 대화를 작은 조각으로 분해한 뒤 embedding을 만들고 vector database에 저장한다. 이후 현재 요청과 의미적으로 비슷한 기록을 top-k 검색해 모델에게 다시 보여주는 RAG(Retrieval-Augmented Generation, 필요한 정보를 검색해 모델의 입력에 추가하는 방식) 구조를 사용한다.
저자는 이 방식에서 네 가지 문제가 생긴다고 지적한다. 첫째, 의미적으로 비슷한 기록이 현재 상황에서도 옳거나 최신이라는 보장이 없다. 둘째, 짧은 memory snippet으로 분해하면서 “왜 이런 결정을 내렸는지” 같은 맥락이 사라진다. 셋째, 오래된 결정과 최신 결정을 동일한 종류의 기억으로 취급하기 쉽다. 마지막으로 에이전트가 어떤 정보가 존재하는지도 모르면 무엇을 검색해야 하는지조차 알기 어렵다.
Vector memory는 사람이 직접 검토하기도 어렵다. 프로젝트 방향이 잘못 기록됐을 때 어느 기억을 수정하거나 삭제해야 하는지 찾기 힘들고, 여러 세션에서 생성된 작은 메모들이 서로 충돌하는 상황도 발생할 수 있다.
저자가 제안하는 대안은 특별한 memory system보다 프로젝트 안의 명시적인 문서 구조다. AGENTS.md 하나만 두는 것이 아니라 요구사항, 설계 결정, 조사 결과, 운영 절차와 현재 진행 상태를 각각 사람이 읽을 수 있는 문서로 관리한다.
에이전트의 작업 흐름도 프롬프트 → 기억 검색 → 작업보다 프롬프트 → 관련 문서 확인 → 작업 → 문서 업데이트에 가까워진다. 다음 세션에서는 다시 같은 문서를 읽으면 되기 때문에 별도의 숨겨진 기억 저장소가 필요하지 않다.
이 방식의 중요한 차이는 기억이 프로젝트의 일부가 된다는 점이다. 개발자도 내용을 읽고 Git diff를 통해 어떤 결정이 바뀌었는지 확인할 수 있고, 잘못된 내용은 일반 문서를 수정하듯 바로 고칠 수 있다. 에이전트에게도 여러 개의 독립적인 과거 기억보다 현재 프로젝트의 합의된 상태를 보여줄 수 있다.
저자가 자신의 프로젝트에서 internal/ 디렉터리의 문서를 쌓아가면서 이를 사실상의 “Operator Memory”로 발전시킨 경험을 바탕으로 한 글이기 때문에 통제된 실험 결과는 아니다. 그럼에도 장기 에이전트 설계에서 기억을 얼마나 많이 저장하느냐보다 무엇을 현재의 공식 상태로 유지할 것인가가 더 중요할 수 있다는 관점을 이해하기 좋은 글이다.
Chaining Skills to Hijack LLM Agents
- 저자: Tian Dong 외
- 발행: arXiv
- 게시일: 2026-10-01
- 원문: arXiv — Chaining Skills to Hijack LLM Agents
AI 에이전트에서 개별 Skill 하나가 안전해 보여도 여러 Skill이 데이터를 주고받는 과정에서 새로운 공격 경로가 만들어질 수 있다는 점을 실험적으로 분석한 논문이다.
연구팀은 APEX(Authority Promotion EXplorer) 라는 공격 방식을 만들었다. 공격자는 먼저 정상적인 작업처럼 보이는 upstream Skill을 이용해 파일이나 작업 상태에 기록을 남긴다. 이 기록에는 실제 작업 진행 상황뿐 아니라 “사용자가 이미 이 행동을 승인했다”는 식의 거짓 권한 정보가 섞여 있다.
이후 다른 downstream Skill이 해당 파일이나 작업 상태를 신뢰한다. 두 번째 Skill 자체에는 직접적인 악성 명령이 없지만, 앞 단계가 남긴 기록을 사용자 승인처럼 받아들이면서 원래 사용자가 요청하지 않았던 행동을 실행하게 된다.
즉 공격 명령을 하나의 prompt에 직접 넣는 대신 여러 도구 사이의 workflow state를 통해 권한을 단계적으로 세탁하는 공격이다. 최근 에이전트가 Skill이나 MCP tool을 조합해 장시간 작업을 수행하면서 중요해지고 있는 공격면이다.
연구팀은 SkillsBench를 기반으로 네 종류의 공격 목표와 여섯 개 모델을 평가했다. 전체 690개의 공격 시도 가운데 512개, 74.2%에서 공격 목표가 성공했다.
GPT-5.4에서는 여러 Skill을 연결한 전체 APEX 공격 성공률이 84.3% 였다. 같은 악성 논리를 하나의 Skill에 합친 경우 성공률은 17.4%, 단순한 direct prompt injection에서는 3.5%였다. 연구팀은 이 결과를 통해 개별 Skill의 보안 검사만으로는 여러 Skill이 조합됐을 때 발생하는 위험을 충분히 발견하기 어렵다고 설명한다.
비용을 소모시키는 공격도 실험했다. 이른바 Work Loop는 에이전트가 실제로 끝낼 필요가 없는 작업을 계속 수행하게 만들며 모델에 따라 정상적인 작업 대비 token 사용량을 2.20배에서 36.39배까지 늘렸다.
단순한 방어책도 시험했다. 다음 Skill을 실행하기 전에 앞 단계에서 만들어진 파일과 원래 사용자 요청을 비교하고 실제 요청 범위를 벗어난 권한 주장이 있는지 검사하도록 했다. GPT-5.4의 공격 성공률은 84.3%에서 59.1%로 낮아졌다.
하지만 대가도 컸다. 정상적인 작업을 방해하지 않고 verifier를 통과한 benign workflow 비율도 86.7%에서 56.3%로 감소했다. 공격을 더 강하게 차단하려다 정상적인 에이전트 행동까지 지나치게 막는 security-usability trade-off가 발생한 것이다.
논문의 핵심은 “악성 Skill을 설치하지 않으면 안전하다”는 가정이 충분하지 않다는 데 있다. 실제 에이전트에서는 파일, 메모리, 작업 상태와 다른 Skill의 출력이 다음 단계의 암묵적인 권한 정보로 사용될 수 있다. 따라서 앞으로 에이전트 보안은 도구 하나씩의 권한뿐 아니라 도구 사이에서 권한과 상태가 어떻게 전달되는지까지 추적해야 한다는 점을 보여준다.
Agents Are Systems, Not Models: Rethinking Agentic Evaluation
- 저자: Luis Wiedmann, Leander Girrbach, Cordelia Schmid, Zeynep Akata
- 발행: arXiv
- 게시일: 2026-10-01
- 원문: arXiv — Agents Are Systems, Not Models: Rethinking Agentic Evaluation
“어떤 모델이 가장 좋은 에이전트인가?”라는 질문 자체가 충분하지 않을 수 있다는 것을 대규모 실험으로 보여주는 논문이다. 연구팀은 에이전트의 성공률을 결정하는 요소가 backbone LLM 하나가 아니라 정보 제공 방식, 도구, 실행 시간, 검증 방법과 모델이 결합된 전체 시스템이라고 주장한다.
실험에서는 천체물리학과 유전체학 등 네 가지 과학 작업을 사용했다. 에이전트는 단순히 문제를 읽고 답을 생성하는 것이 아니라 관련 논문을 찾고, 해당 논문에서 공개한 전문 머신러닝 모델이나 코드를 확인한 뒤 이를 실제로 사용해 결과를 만들어야 했다.
연구팀은 1만8천 개가 넘는 agent trajectory를 실행하면서 다섯 가지 요소를 바꿨다. 에이전트에게 처음부터 제공하는 정보량, reasoning 방식, 검증하라는 추가 프롬프트의 유무, 5·10·20분의 실행 시간 제한, 그리고 backbone model의 크기다.
가장 눈에 띄는 결과는 완전히 같은 설정을 다시 실행하는 것만으로도 전체 결과 변동의 약 54%가 발생했다는 점이다. 모델·프롬프트·도구가 모두 같더라도 에이전트 실행 경로의 확률적 차이 때문에 성공과 실패가 크게 달라질 수 있었다.
따라서 한두 번의 실행 결과만 보고 에이전트 A가 B보다 뛰어나다고 결론 내리는 것은 위험할 수 있다. 기존 LLM 벤치마크보다 반복 실행과 분산 측정이 훨씬 중요해진다는 의미다.
설정 요소 가운데 가장 큰 영향을 준 것은 모델 크기나 실행 시간이 아니라 처음 제공하는 정보의 품질과 양이었다. 필요한 논문과 도구에 대한 유용한 정보를 제공하면 성공률이 올라갔을 뿐 아니라 에이전트가 쓸데없는 검색과 시행착오를 덜 하면서 비용도 줄고 결과에 대한 confidence calibration도 개선됐다.
단순히 시간을 더 주는 것은 항상 도움이 되지 않았다. 충분한 정보와 능력이 있는 모델에서는 추가 시간이 유용했지만, 올바른 방향을 잡지 못한 에이전트는 시간을 늘려줘도 같은 잘못된 탐색을 더 오래 반복하는 경우가 있었다.
검증 방식에서도 차이가 나타났다. 프롬프트에 “결과를 다시 확인해라”라고 적는 것만으로는 행동 변화가 크지 않았다. 반면 결과를 독립적으로 확인할 수 있는 전용 verification tool을 제공했을 때는 실제 검증 행동이 뚜렷하게 늘었다.
이는 최근 에이전트 제품의 품질을 평가할 때 모델 benchmark만 봐서는 부족한 이유를 보여준다. 같은 모델이라도 어떤 정보를 먼저 주는지, 어떤 도구를 제공하는지, 실패를 확인할 방법이 있는지, 얼마 동안 실행하도록 하는지에 따라 완전히 다른 시스템처럼 행동할 수 있다.
특히 코딩·리서치·업무 자동화처럼 장시간 실행되는 에이전트에서는 “가장 높은 점수를 받은 모델을 선택한다”보다 전체 agent harness를 함께 측정하고 반복 실행의 변동성까지 평가하는 것이 더 중요하다는 점을 실제 1만8천 개 이상의 실행 결과로 보여주는 연구다.