2026년 7월 7일 | AI 최신 트렌드
에이전트라는 단어가 다시 플랫폼, 개인정보, 로컬 실행 쪽으로 갈라졌다. Vercel은 모델과 에이전트를 분리해서 조립하는 운영 레이어를 말했고, Meta AI는 예약 작업 기능으로 챗봇을 비동기 작업자에 가깝게 밀고 있다. Google은 검색 서비스에서 사용자가 올린 이미지·음성·파일을 AI 개선에 쓰는 설정을 더 드러냈고, Claude Code의 숨은 추적 코드 논란은 개발자 도구가 어느 정도까지 사용자를 관찰해도 되는지를 다시 물었다.
여기에 Office 문서를 에이전트가 직접 읽고 고치는 OfficeCLI, 그리고 Mac과 CUDA 장비를 이어 하나의 LLM을 나눠 돌리려는 DRIFT까지 붙이면 흐름은 꽤 선명하다. 내가 보기에는 모델 하나의 성능보다, 모델을 어디에 묶고 어떤 권한과 데이터와 하드웨어 경계 안에서 실행할지가 더 중요한 날이었다.
Vercel: 모델과 에이전트를 떼어 놓는 플랫폼 싸움
TechCrunch 인터뷰에서 Vercel의 Guillermo Rauch는 꽤 직접적으로 말했다. Vercel은 하루 600만 건의 배포를 보고 있고, 그중 절반은 코딩 에이전트가 트리거하며, AI Gateway에는 하루 1조 토큰 이상이 흐른다고 한다. 이 숫자만 봐도 코딩 에이전트가 더 이상 데모용 보조 도구가 아니라 실제 배포 파이프라인 안으로 들어왔다는 느낌이 든다.
흥미로운 건 Rauch가 에이전트의 핵심을 모델이 아니라 하네스, 데이터 플랫폼, 샌드박스, 게이트웨이의 조합으로 본다는 점이다. Vercel은 Eve라는 프레임워크와 Vercel Sandbox를 통해 에이전트의 지시·스킬·데이터 접근·감사 추적을 관리하려 한다. 코딩 에이전트가 만든 결과물을 어디에 배포할지, 내부 업무 에이전트가 어떤 SaaS 데이터에 접근할지까지 묶어야 한다는 이야기다.
나는 이 대목이 요즘 에이전트 플랫폼 경쟁의 핵심이라고 봤다. 특정 모델 하나를 고르는 일보다, 모델을 바꿔 끼울 수 있는 상태에서 권한·로그·비용·샌드박스를 통제하는 쪽이 더 오래 간다. 좋은 모델이 있어도 실행 공간이 없으면 제품이 안 되고, 실행 공간이 있어도 감사 로그가 없으면 기업 안으로 못 들어간다.
Meta AI 예약 작업: 챗봇이 먼저 움직이는 쪽으로
AI타임스 보도에 따르면 Meta AI 웹 버전 개발 빌드에서 Scheduled Tasks 메뉴가 포착됐다. 일반 사용자에게 공개된 기능은 아니지만, 반복적인 프롬프트를 사용자가 매번 입력하지 않아도 정해진 시간에 뉴스 요약이나 주간 동향 같은 작업을 실행하는 형태로 설명된다.
이 기능은 겉으로 보면 알림 예약에 가까워 보이지만, 실제 의미는 조금 더 크다. 챗봇은 사용자가 말을 걸어야 움직인다. 예약 작업은 반대로 사용자가 자리를 비운 뒤에도 정해진 시간에 일을 시작한다. 이벤트 트리거나 외부 앱 연동이 어디까지 되는지는 아직 확인되지 않았지만, 방향 자체는 명확하다. AI 서비스가 질의응답 창에서 비동기 작업자로 넘어가고 있다.
나도 이런 기능을 볼 때마다 편리함보다 먼저 실패 모드를 떠올리게 된다. 매일 아침 자동 요약이 틀리면 누가 확인할지, 반복 작업이 오래된 조건으로 계속 돌면 어디에서 멈출지, 사용자가 잊은 권한이 계속 유지되면 어떤 로그가 남을지 같은 문제다. 에이전트 제품은 “알아서 해준다”는 말만으로는 부족하고, 멈춤 조건과 작업 영수증까지 같이 설계해야 한다.
Google 검색 데이터 설정: 사진과 음성도 AI 학습 재료가 된다
TechCrunch는 Google의 검색 서비스 개인정보 설정 변경을 짚었다. 새 설정은 Search Services History와 Personalized Recommendations로 나뉘며, Google Lens 사진, Search Live 음성, Translate 음성 연습처럼 검색 서비스에 올린 미디어가 AI 모델과 안전 시스템 개선에 쓰일 수 있다고 한다. Maps, Shopping, Flights, Hotels, Translate, News 같은 검색 계열 서비스도 함께 언급됐다.
핵심은 웹에서 긁은 데이터만 문제가 아니라는 점이다. 사용자가 직접 올리는 이미지, 파일, 오디오, 비디오가 제품 사용 과정에서 자연스럽게 학습 재료가 된다. 설정에서 Save Media를 끄거나 기록 보존 기간을 조정할 수 있지만, 기본값과 안내 문구를 사용자가 얼마나 이해하는지는 별개의 문제다.
나는 이 흐름이 AI 제품의 프라이버시 논의를 더 어렵게 만든다고 본다. 예전에는 “웹 공개 자료를 학습했는가”가 중심 질문이었다면, 이제는 “내가 기능을 쓰려고 올린 입력이 어디까지 저장되고, 누가 검토하며, 어떤 모델 개선에 들어가는가”가 더 중요해진다. 제품 UI에서 한 번 체크한 설정이 데이터 거버넌스의 실질적인 경계가 되는 셈이다.
Claude Code 추적 논란: 보안 목적이어도 숨기면 신뢰가 흔들린다
Ars Technica는 Claude Code에 중국 사용자와 프록시·타임존·연구소 연결 가능성을 감지하는 숨은 코드가 들어 있었다는 논란을 다뤘다. Anthropic 엔지니어는 이 코드가 3월에 추가된 실험이며, 무단 리셀러와 모델 증류 공격을 막기 위한 목적이었다고 설명했다. 이후 더 강한 완화책이 들어가며 해당 코드는 제거됐다고 한다.
보안 목적 자체를 무조건 가볍게 볼 수는 없다. 프런티어 모델을 대량 호출해 증류하려는 시도, 우회 리셀링, 국가 간 모델 경쟁은 실제 운영 리스크다. 다만 개발자 도구가 로컬 코드와 명령 실행 권한에 가까이 붙어 있을수록, 숨은 텔레메트리는 훨씬 민감해진다. 사용자가 모르는 신호를 시스템 프롬프트에 숨겨 보낸다면, 그 도구가 말하는 프라이버시 약속도 같이 의심받는다.
이 사건은 에이전트 도구의 신뢰 계약을 잘 보여 준다. 필요한 수집이라면 문서화하고, 어떤 필드를 보내는지 설명하고, 정책과 릴리스 노트에 남기는 편이 낫다. 특히 코딩 에이전트는 코드, 환경변수, 파일 경로, 패키지 설치 기록을 가까이 본다. 그래서 투명한 텔레메트리와 감사 가능한 정책은 기능이 아니라 기본 안전장치에 가깝다.
OfficeCLI: 문서 파일도 에이전트의 작업 표면이 된다
Hacker News에 올라온 OfficeCLI 저장소도 눈에 띄었다. GitHub 설명에 따르면 이 도구는 AI 에이전트가 Word, Excel, PowerPoint 파일을 읽고, 수정하고, 새로 만들 수 있게 하는 단일 바이너리 CLI다. Office 설치 없이 동작하고, Apache 2.0 라이선스이며, 저장소 기준 별도 설치 없이 문서 구조를 JSON·HTML·PNG로 확인하는 흐름을 강조한다.
내가 좋게 본 포인트는 “문서를 만든다”보다 렌더링해서 보고 다시 고치는 루프다. 에이전트가 pptx나 xlsx를 문자열 덩어리로만 만지면, 최종 산출물이 실제로 어떻게 보이는지 놓치기 쉽다. OfficeCLI는 문서를 HTML이나 PNG로 렌더링해 에이전트가 결과를 확인하고, 구조화된 경로로 특정 요소를 고칠 수 있게 하려는 쪽에 가깝다.
이런 도구가 늘어나는 건 코딩 에이전트의 표면이 코드 저장소 밖으로 넓어진다는 뜻이다. 회사 업무의 많은 산출물은 여전히 보고서, 스프레드시트, 발표 자료다. 에이전트가 실제 업무를 하려면 API 호출만 잘해서는 부족하고, 사람이 쓰는 파일 포맷을 읽고 고치고 검증해야 한다. OfficeCLI는 그 방향의 꽤 노골적인 예시다.
DRIFT: 개인 장비를 묶어 LLM 하나를 나눠 돌리기
GeekNews에 올라온 DRIFT 소개는 로컬 AI 쪽에서 재미있는 질문을 던졌다. 한 대의 개인 장비가 모델 전체를 감당하지 못한다면, 여러 개인 기기가 하나의 모델을 같이 돌릴 수 없을까. DRIFT는 Mac의 Apple GPU와 Windows·Linux의 NVIDIA GPU를 함께 써서 하나의 LLM을 디코더 레이어 단위로 나눠 실행하는 오픈소스 프로젝트로 소개됐다.
설계에서 눈에 띄는 부분은 노드 사이에 모델 전체나 KV cache를 주고받는 대신 hidden state를 넘기고, 통신을 TCP와 msgpack 기반의 중립적인 바이트 프로토콜로 둔다는 점이다. X25519와 ChaCha20-Poly1305 기반 암호화, Ed25519 서명 영수증, 노드 실패 시 re-split과 replay 같은 요소도 언급됐다. 즉 속도만 외치는 프로젝트라기보다, 서로 다른 장비가 정확히 같은 모델 실행에 참여할 수 있는지 보는 쪽이다.
물론 이것이 바로 개인용 초대형 모델 실행을 쉽게 만든다는 뜻은 아니다. 네트워크 지연, 노드 안정성, 모델 분할 효율, 실제 처리량 문제는 계속 남는다. 그래도 방향은 중요하다. 프런티어 모델은 점점 비싸지고, 로컬 모델은 여전히 하드웨어 장벽이 높다. 그 사이에서 개인 장비 여러 대를 묶어 실행 능력을 키우는 실험은 로컬 AI의 다음 병목이 소프트웨어 프로토콜일 수 있다는 걸 보여 준다.
한 줄로 묶으면: 에이전트는 실행 환경의 문제다
여섯 소식을 한 줄로 묶으면 에이전트는 모델보다 실행 환경의 문제라는 말이 된다. Vercel은 모델·하네스·샌드박스·게이트웨이를 조립하려 하고, Meta는 예약 작업으로 챗봇을 먼저 움직이는 작업자로 바꾸려 한다. Google과 Anthropic 사례는 그 과정에서 데이터와 텔레메트리 경계가 얼마나 민감해지는지 보여 준다.
OfficeCLI와 DRIFT는 더 아래쪽 레이어를 건드린다. 에이전트가 실제 문서 파일을 고치려면 포맷과 렌더링 루프가 필요하고, 로컬 모델을 개인 장비에서 더 크게 돌리려면 이종 장비를 묶는 실행 프로토콜이 필요하다. 결국 좋은 AI 제품은 모델 API 하나로 끝나지 않는다. 권한, 감사, 데이터 설정, 파일 포맷, 하드웨어 분할까지 버티는 구조가 있어야 오래 간다.