업무별 에이전트를 수천 개씩 찍어내는 것도, 모든 일을 하나의 만능 AI에게 맡기는 것도 — 나는 둘 다 조심해야 한다고 생각한다. 대기업 AX의 핵심은 에이전트의 개수 가 아니라 운영 가능한 단위로 관리되고 있는가 이다. 최근 한 영상을 보면서 조금 오래 생각하게 되었다. 영상의 핵심은 대략 이랬다. 기업들이 "OO 업무 자동화 에이전트"를 하나씩 만들기 시작하면, 결국 수백 개, 수천 개의 에이전트가 쌓이고, 그것은 유지보수 지옥이 될 수 있다는 이야기였다. 그러니 특정 업무별 에이전트를 계속 만드는 SI식 사고에서 벗어나, Claude Code나 Codex 같은 범용 슈퍼 에이전트를 조직 전체가 잘 활용할 수 있도록 해야 한다는 주장이었다. 영상의 문제의식 자체는 이해한다 실제로 AI 시대에 과거 SI 방식 그대로 "회의록 에이전트", "카드뉴스 에이전트", "위험성 평가 에이전트", "재무 예측 에이전트"를 각각 따로 구축하는 방식은 위험할 수 있다. 그렇게 만들면 중복 기능이 생기고, 프롬프트도 흩어지고, 권한도 흩어지고, 데이터도 흩어지고, 누가 유지보수할지 모르는 자동화 조각들이 회사 안에 쌓일 수 있다. 그런 의미에서 "업무별 에이전트 난립을 경계해야 한다"는 메시지는 맞다. 그런데 "에이전트 4,000개"라는 전제가 걸렸다 하지만 내가 걸렸던 부분은 그다음이었다. 그 위험을 설명하기 위해 "대기업이 에이전트를 300개, 400개, 4,000개씩 만들게 될 것"이라는 전제가 깔려 있는 것처럼 들렸기 때문이다. 나는 이 전제가 그렇게 쉽게 받아들여지지 않았다. 내가 경험한 대기업은 그렇게 움직이지 않았다. 물론 비효율도 있고, 부서 이기주의도 있고, 오래된 SI 문법도 있다. 하지만 그렇다고 해서 대기업이 아무런 통제 없이 업무별 에이전트를 수천 개씩 발주하고 운영하는 조직은 아니다. ...
2026년 7월 현재, 구글(Google)의 기술 트렌드를 관통하는 단 하나의 키워드를 꼽으라면 단연 **'에이전트(Agent)'**입니다. 지난 5월 Google I/O 2026에서 공개된 Gemini 3.5 Flash , 에이전트 우선 개발 플랫폼 Antigravity 2.0 , 그리고 영상 기반 생성 모델 Gemini Omni 까지 — 구글이 던진 메시지는 명확합니다. AI는 이제 코드를 '거들어 쓰는' 부조종사(Co-pilot)를 넘어, 스스로 작업을 '실행하는' 자율 에이전트로 이동하고 있습니다. 이번 글에서는 개발자와 기술 실무자의 관점에서, 구글이 최근 발표한 핵심 기술들이 실제 개발 워크플로우를 어떻게 바꾸고 있는지 근거와 함께 정리합니다. 1. Gemini 3.5 Flash: '싸고 빠른' 티어가 이전 플래그십을 넘어섰다 이번 발표에서 가장 상징적인 사건은 저가·고속 티어인 Gemini 3.5 Flash가 이전 플래그십 모델인 Gemini 3.1 Pro를 코딩·에이전트 벤치마크에서 앞질렀다 는 점입니다. 구글은 이를 "행동하는 프런티어 지능(frontier intelligence with action)"이라고 표현했습니다. 공개된 벤치마크 수치는 다음과 같습니다. Terminal-Bench 2.1: 76.2% — 터미널 환경에서의 실제 코딩 수행 능력 GDPval-AA: 1656 Elo — 실무형 에이전트 태스크 수행 능력 MCP Atlas: 83.6% — 도구 호출(tool-use) 및 MCP 연동 성능 핵심은 단순히 점수가 높다는 것이 아니라 **"다른 프런티어 모델 대비 약 4배 빠른 속도로, 절반 이하의 비용"**에 이 성능을 낸다는 점입니다. 에이전트는 하나의 작업을 완수하기 위해 수십~수백 번의 추론·도구 호출을 반복합니다. 따라서 '속도 × 비용'은 에이전트 워크플로우의 실용성을 결정하는 절대적 변수...