Google I/O 2026은 5월 19일부터 20일까지 열리고, Google은 올해 개발자 키노트의 중심 주제로 agentic era of development를 예고했습니다. Android, Chrome, Cloud, AI 전반에서 자동화된 개발 워크플로와 agent-ready application이 주요 메시지가 될 가능성이 큽니다.
아직 본 발표 전이지만 개발팀은 기다리기만 하면 안 됩니다. 최근 Google 개발자 블로그의 흐름을 보면 방향은 이미 보입니다. Genkit Middleware는 agentic app에 retry, fallback, human approval, observability를 넣는 구조를 제시했습니다. ADK는 장기 실행 에이전트의 pause/resume과 context 유지 문제를 다뤘습니다. Antigravity와 Gemini CLI 관련 발표는 코딩 에이전트를 editor, terminal, browser 전반으로 확장했습니다.
즉 I/O의 새 기능이 무엇이든, 실무 개발자가 준비해야 할 질문은 같습니다. 우리 서비스는 에이전트가 안전하게 도구를 호출할 수 있는가. 실패했을 때 되돌릴 수 있는가. 사람이 승인해야 할 지점이 분리되어 있는가. 로그를 보고 원인을 찾을 수 있는가.
첫 번째 신호는 middleware입니다. 모델 호출 앞뒤에 retry와 fallback을 붙이는 수준을 넘어, tool execution loop 자체를 가로채는 구조가 중요해졌습니다. 에이전트는 한 번의 답변으로 끝나지 않습니다. 모델이 도구를 부르고, 도구 결과를 다시 모델에 넣고, 다시 도구를 부르는 루프입니다. 이 루프의 각 지점에 정책을 넣을 수 있어야 운영이 됩니다.
두 번째 신호는 승인 흐름입니다. 파일 삭제, 결제 실행, 고객 데이터 변경, 외부 메시지 전송 같은 작업은 모델이 바로 실행하면 안 됩니다. Google이 Genkit Middleware에서 tool approval을 전면에 둔 것은 우연이 아닙니다. 에이전트 시대의 UX는 “자동 실행”이 아니라 “자동 진행 + 위험 지점 승인”에 가깝습니다.
세 번째 신호는 개발 환경 통합입니다. agentic coding은 단순 코드 생성이 아니라 브라우저 확인, 터미널 실행, 테스트, 배포 로그 확인까지 포함합니다. 따라서 앞으로의 발표는 IDE 플러그인보다 manager surface, artifact, workflow orchestration에 가까운 형태가 될 가능성이 높습니다.
Agent-ready application은 AI 기능을 붙인 앱과 다릅니다. AI 기능을 붙인 앱은 채팅창 하나로도 만들 수 있습니다. Agent-ready application은 외부 행위자가 안전하게 읽고 쓰고 검증할 수 있도록 경계가 정리된 앱입니다.
예를 들어 관리자 페이지의 버튼만 있는 시스템은 사람에게는 충분할 수 있습니다. 하지만 에이전트가 쓰려면 API contract, permission scope, dry-run 모드, audit log, idempotency key가 필요합니다. “환불 처리”라는 도구가 있다면 에이전트는 먼저 대상 주문을 조회하고, 환불 가능 여부를 확인하고, 예상 결과를 설명하고, 승인 후 실행해야 합니다. 실행 결과는 audit log에 남아야 합니다.
검색과 조회도 마찬가지입니다. 에이전트가 고객 데이터를 가져갈 수 있다면 최소 권한과 redaction이 필요합니다. 사용자의 전체 CRM을 넘기는 대신 필요한 필드만 조회하는 tool을 만들어야 합니다. 내부 문서 검색도 “모든 문서 RAG”가 아니라 부서, 권한, 최신성 기준이 들어가야 합니다.
첫째, 현재 서비스의 write action 목록을 뽑으세요. 생성, 수정, 삭제, 전송, 결제, 초대, 권한 변경, 배포 같은 동작을 모두 적습니다. 그리고 각 action에 승인 필요 여부, 되돌리기 가능 여부, audit log 여부를 표시합니다. 이 표가 없으면 어떤 에이전트 플랫폼을 도입해도 위험합니다.
둘째, idempotency를 점검하세요. 에이전트는 네트워크 오류나 모델 재시도 때문에 같은 도구를 두 번 호출할 수 있습니다. 결제, 쿠폰 발급, 이메일 발송, 데이터 마이그레이션은 idempotency key 없이 열면 사고가 납니다.
셋째, dry-run 응답을 만드세요. 좋은 도구는 실행 전에 “무엇이 바뀌는지”를 구조화해 반환합니다. 예를 들어 POST /refunds/dry-run은 환불 금액, 취소될 혜택, 알림 대상, 회계 영향, 실패 가능성을 보여줘야 합니다.
넷째, observability 필드를 정하세요. agent_session_id, tool_name, input_hash, output_status, approval_id, user_id, tenant_id, latency_ms 정도는 최소로 남겨야 합니다. 모델 로그 전문을 저장하지 않더라도 이 메타데이터가 있어야 장애 분석이 됩니다.
새 SDK나 플랫폼이 나오면 데모보다 운영 기능을 먼저 보세요. 모델 성능보다 더 중요한 질문은 다음과 같습니다. Tool call을 middleware로 가로챌 수 있는가. 승인 interrupt와 resume이 공식 지원되는가. Retry가 tool side effect를 중복 실행하지 않는가. Trace를 OpenTelemetry나 기존 APM으로 보낼 수 있는가. 권한 scope를 사용자·조직·도구 단위로 나눌 수 있는가.
또 하나는 vendor lock-in입니다. agent workflow를 특정 플랫폼 객체에만 묶으면 나중에 모델이나 클라우드를 바꾸기 어렵습니다. 업무 규칙, 도구 contract, 승인 정책, 감사 로그는 가능하면 애플리케이션 쪽에 남겨야 합니다. 플랫폼은 실행 엔진으로 쓰되 핵심 정책은 제품 코드와 문서로 관리하는 편이 안전합니다.
Google I/O 2026의 발표는 화려할 수 있습니다. 하지만 개발팀의 숙제는 변하지 않습니다. 에이전트가 일할 수 있는 도구를 만들되, 위험한 행동은 사람이 통제하고, 모든 변경은 추적 가능해야 합니다. 이 기본기가 있어야 새 기능이 실제 제품 속도로 이어집니다.
