핵심 요약
이번 내용의 중심은 Google의 Gemini Enterprise Agent Platform이다.
핵심 메시지는 "에이전트는 쉽게 시제품을 만들 수 있지만, 실제 운영 환경에 올리려면 빌드·확장·거버넌스·최적화가 함께 필요하다"는 점이다.
또한 개발자의 역할은 사라지기보다, AI와 에이전트를 다루는 문제 해결자로 더 확장된다는 관점이 반복해서 강조되었다.
Gemini Enterprise Agent Platform의 역할
이 플랫폼은 에이전트를 단순히 "만드는 도구"가 아니라, 실제 기업 환경에서 운영 가능한 수준으로 끌어올리는 전체 기반으로 소개되었다.
핵심 축은 네 가지다. 빌드, 스케일, 거버넌스, 최적화다.
그동안 많은 팀이 에이전트 프로토타입은 빠르게 만들었지만, 운영 단계에서 막혔다. 이유는 모델 자체보다 주변 문제가 더 어려웠기 때문이다. 예를 들어 신원 관리, 권한, 메모리, 추적, 이상 탐지, 평가 같은 요소를 따로따로 붙여야 했다.
이 플랫폼은 그런 조각난 구성 대신, 기업용 에이전트 개발에 필요한 요소를 한 덩어리로 제공하려는 방향이다.
ADK는 에이전트의 제작 엔진이다
에이전트 개발의 중심 도구는 ADK(Agent Development Kit)다.
ADK는 에이전트를 빠르게 만들 수 있게 해주는 프레임워크이며, Python, Go, TypeScript, Java를 지원한다고 설명되었다.
중요한 점은 ADK가 "0에서 1까지"를 돕는다는 것이다. 즉, 아이디어를 실행 가능한 에이전트로 바꾸는 기본 뼈대를 제공한다.
하지만 운영 환경까지 가려면 ADK만으로 끝나지 않는다. 그래서 상위 개념으로 Agent Platform이 붙는다. 쉽게 말해 ADK가 엔진이라면, 플랫폼은 도로·교통법규·계기판·정비 시스템까지 포함한 자동차 생태계에 가깝다.
기업 환경에서 왜 거버넌스가 중요한가
에이전트는 행동한다. 그래서 단순한 텍스트 생성보다 더 강한 통제가 필요하다.
여기서 강조된 요소는 에이전트 게이트웨이, 에이전트 신원, 레지스트리, 이상 탐지다.
특히 에이전트마다 암호학적으로 생성된 고유 신원을 부여할 수 있다는 점이 중요하다. 사람 직원에게 각자 계정과 권한을 주듯, 에이전트도 독립된 신원과 권한을 가져야 한다는 논리다.
이렇게 해야 누가 어떤 작업을 했는지 추적할 수 있고, 문제가 생겼을 때 감사 기록도 남길 수 있다. 규제가 강한 산업에서는 이 기능이 선택이 아니라 필수에 가깝다.
메모리와 세션은 에이전트의 지속성을 만든다
좋은 에이전트는 지금 한 번만 똑똑한 것이 아니라, 이전 맥락을 잊지 않아야 한다.
대화에서는 메모리 관리가 지난 6~12개월 사이 에이전트 품질을 좌우하는 핵심 문제로 떠올랐다고 설명되었다.
세션과 메모리 관리가 중요한 이유는 간단하다. 고객 지원 에이전트든, 장시간 실행되는 분석 에이전트든, 중간에 맥락을 잃으면 다시 처음부터 시작하는 것과 다르지 않기 때문이다.
여기서 "장시간 실행 에이전트" 개념도 함께 언급됐다. 몇 분이 아니라 며칠, 심지어 더 오래 돌아가는 에이전트라면 상태 보존과 기억은 필수다.
메모리 뱅크는 이런 부담을 줄여주는 구성요소로 설명되었다. 개발자가 메모리 저장 전략을 처음부터 설계하지 않아도, 중요한 정보를 저장하고 다시 꺼내 쓰는 기반을 제공하는 식이다.
에이전트 최적화의 핵심은 평가와 관측 가능성이다
LLM은 비결정적이다. 에이전트도 그 위에 서 있기 때문에 비결정적이다.
그래서 "잘 만들었다"보다 중요한 질문은 "항상 원하는 방식으로 행동하는가"다.
에이전트 평가(agent eval)는 바로 이 지점을 다룬다. 질문에 답만 잘하는지 보는 것이 아니라, 여러 단계의 흐름 속에서 목표를 제대로 달성하는지 확인해야 한다.
또 하나의 핵심은 관측 가능성이다. 에이전트가 어떤 판단을 했고, 어떤 도구를 썼고, 어디서 흐름이 어긋났는지 볼 수 있어야 한다.
이는 전통적인 클라우드 관측성과 비슷하지만, 비결정적 실행과 멀티에이전트 흐름까지 다뤄야 하므로 더 복잡하다. 대시보드와 트레이싱은 그런 복잡성을 개발자가 이해하게 해주는 지도 역할을 한다.
샌드박스는 에이전트의 '행동 반경'을 제한한다
에이전트가 강력해질수록 위험도 함께 커진다.
특히 도구 호출, 사내 데이터 접근, 다른 시스템과 상호작용이 늘어나면, 작은 실수가 큰 피해로 이어질 수 있다.
그래서 샌드박스가 중요하다. 샌드박스는 에이전트가 사용할 수 있는 도구와 권한의 범위를 제한하는 안전 울타리다.
비유하자면 새집을 만들게 하려면 망치와 못을 주면 된다. 굳이 모든 무기를 쥐여줄 필요는 없다.
이 관점은 특히 코딩 에이전트에 잘 맞는다. 필요한 도구만 허용하면, 생산성은 유지하면서도 사고 반경은 줄일 수 있다.
개발자를 위한 새 도구: Agent CLI와 Skills
개발자 관점에서 눈에 띄는 발표 중 하나는 Agent CLI다.
이 도구는 에이전트 개발 전 과정을 명령형 인터페이스로 다루게 해준다. 빌드, 배포, 평가, 거버넌스까지 한 흐름에서 연결하려는 시도다.
여기서 중요한 개념이 "스킬"이다.
스킬은 에이전트에게 특정 작업 능력을 주는 모듈처럼 설명되었다. 예전에는 긴 시스템 프롬프트 안에 모든 규칙과 능력을 몰아넣었다면, 이제는 스킬 단위로 기능을 분리해 필요할 때 선택하게 하는 방식이다.
이 구조는 더 깔끔하고, 더 확장 가능하며, 문맥 혼잡도 줄인다. 쉽게 말해 거대한 지시문 한 장보다, 전문 기술을 가진 작은 팀을 호출하는 방식에 가깝다.
ADK 2.0의 그래프 기반 워크플로우
ADK 2.0에서는 그래프 기반 워크플로우가 강조되었다.
이 기능은 에이전트에 어느 정도의 결정성과 구조를 부여한다. 즉, 자유로운 추론은 유지하되, 작업 흐름 자체는 설계자가 통제할 수 있게 한다.
이는 금융, 보험, 심사, 규정 준수 같은 업무에 특히 중요하다. 이런 분야는 "대충 잘하면 되는" 것이 아니라, 어떤 순서로 어떤 검증을 거쳤는지가 중요하기 때문이다.
그래프 기반 접근은 에이전트를 완전히 즉흥적으로 움직이게 두지 않고, 정해진 경로 안에서 판단하도록 만드는 방식이라고 볼 수 있다.
AI 시대에도 개발자의 역할은 더 중요해진다
대화에서 반복해서 나온 메시지는 개발자는 여전히 문제 해결자라는 점이다.
도구는 바뀐다. 예전에는 언어, IDE, 라이브러리가 중심이었다면 이제는 에이전트, AI 코딩 도구, 평가 시스템이 그 자리를 일부 차지한다.
하지만 본질은 같다. 무엇이 좋은 구조인지, 어떤 품질 기준이 필요한지, 어떤 제약을 설계에 반영해야 하는지는 여전히 사람이 결정한다.
좋은 개발자는 앞으로 코드를 직접 쓰는 사람을 넘어, 여러 에이전트를 설계·감독·평가하는 사람으로 역할이 넓어질 가능성이 크다.
AI와 클라우드의 다음 단계: 효율화에서 전환으로
대화 후반부에서는 AI가 아직은 "효율화 단계"에 있다는 시각이 나왔다.
즉, 현재는 고객지원 자동화, 문서 작성 보조, 연구 보조처럼 기존 업무를 더 빠르고 싸게 만드는 데 강하다.
하지만 진짜 큰 변화는 그 다음 단계, 즉 비즈니스 모델 자체를 바꾸는 단계에서 나온다.
인터넷 초기에 종이신문을 그냥 웹에 올렸던 것처럼, 지금은 기존 업무를 AI로 덧칠하는 수준이 많다. 시간이 지나면 AI와 에이전트에 맞는 완전히 새로운 제품과 흐름이 등장할 가능성이 크다.
Google의 TPU, 모델, 클라우드가 통합된 구조는 이런 전환을 받치는 기반으로 언급되었다. 특히 추론 비용과 속도가 계속 좋아지면, AI는 "가끔 쓰는 기능"이 아니라 거의 실시간으로 상호작용하는 기본 인터페이스가 될 수 있다.
인사이트
이 내용에서 가장 실용적인 교훈은 분명하다. 에이전트 개발은 이제 "프롬프트 잘 쓰기" 수준을 넘어섰다.
실무에서는 ADK 같은 제작 도구만 볼 것이 아니라, 신원 관리, 메모리, 평가, 추적, 샌드박스까지 함께 설계해야 한다.
학습 우선순위를 잡는다면 이렇게 보면 좋다. 먼저 ADK와 Agent CLI로 기본 빌드를 익히고, 다음으로 메모리와 평가를 이해한 뒤, 마지막으로 거버넌스와 샌드박스를 붙여 운영 관점까지 확장하면 된다.
짧게 말해, 앞으로 강한 개발자는 코드를 많이 쓰는 사람보다 에이전트를 믿을 수 있게 만드는 사람일 가능성이 높다.
출처 및 참고 :
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.