영상 보기
요약
AI 에이전트 시대가 도래하고 있으며, 구글 클라우드의 AI 전문 고객 엔지니어와 제너러티브 AI 필드 솔루션 아키텍트 사이의 에이전트 개발의 실제적인 측면을 논하고 있다. 구글은 제미나이 2.0과 2.5를 통해 에이전트 시대를 준비하고 있으며, 에이전트 개발을 지원하는 방향으로 나아가고 있음을 보여주는 영상이었다.
ADK (Agent Development Kit)의 필요성 및 특징
- 에이전트 개발은 LM 기술 활용을 넘어 소프트웨어 엔지니어링 지식과 LM 관련 지식이 모두 필요하여 시작이 어렵다.
- 시중에는 랭그래프(LangGraph)나 크루AI(CrewAI)와 같은 다양한 에이전트 개발 프레임워크가 있지만, 구글은 ADK를 개발하였다.
- ADK의 목적은 에이전트 개발을 더 쉽게 만들고, 개발된 에이전트를 쉽게 프로덕션에 배포할 수 있도록 이밸류에이션, 세션 관리, 다른 서비스와의 연결 등 필요한 부분을 신경 써서 만드는 것이다.
- 기존 프레임워크와의 차이점으로, ADK는 사용 편의성이 높고, 구글의 다른 서비스들과의 통합이 매우 쉽다. 또한 실제 프로덕션 환경을 위한 배포, CI/CD, 이밸류에이션 등의 고려가 잘 되어 있다.
- ADK는 고객의 요구사항을 셀즈포스에 반영하는 CRM 에이전트나 고객에게 제품을 추천하는 에이전트 등 다양하고 복합적인 전문 에이전트들을 이미 잘 만들어 놓은 예시를 제공하며, 이를 활용하여 개발을 시작할 수 있다. 튜토리얼을 통해 기존 기술로는 오래 걸렸을 작업을 매우 심플하게 구현하는 경험을 할 수 있다.
- ADK는 개발 시간을 획기적으로 단축시킨다. 예를 들어, RAG(Retrieval Augmented Generation) 기법을 활용한 프로젝트는 과거 몇 달이 걸렸으나, ADK를 사용하면 1~2주 만에 기존에 몇 달 걸렸을 만한 완성도로 개발이 가능하다. 문서 처리 프로젝트 또한 LLM과 에이전트를 결합하여 몇 개월, 심지어 1년 이상 걸리던 작업을 매우 빠르게 완성할 수 있다.
- ADK의 주요 기능은 다음과 같다:
- 인스트럭션 기반의 작업 위임: 프롬프트만 입력하면 에이전트가 필요에 따라 서브 에이전트에게 작업을 위임하거나 특정 툴을 호출한다.
- 쉬운 검색 연동: 구글의 Vertex AI Search나 Vertex AI의 RAG 엔진을 쉽게 붙일 수 있어 검색 부분 구현이 매우 용이하다.
- LLM 에이전트: 동적 추론을 통해 요청에 따라 전문화된 서브 에이전트에게 작업을 넘기는 것이 가능하다 (예: 수학 계산 에이전트가 소수점 계산은 더 똑똑한 에이전트에게 위임).
- 워크플로우 에이전트: 비즈니스 로직 처리를 위해 순차적, 병렬적, 루프 기반의 프로세스를 정의할 수 있다. 이는 LLM의 동적 추론만으로는 부족한 부분을 보완하여 에이전트의 안정적인 동작을 보장한다. 프로젝트에서는 LLM 에이전트와 워크플로우 에이전트를 혼합하여 설계하고 구현하는 경우가 많다.
에이전트 개발의 평가 및 안정성
- 에이전트 개발에서 평가는 가장 중요한 부분 중 하나이다.
- ADK는 세션 관리, 장기 기억(Long-term Memory), 이밸류에이션(Evaluation)과 같은 기능을 기본적으로 제공하여 개발자가 직접 구현해야 할 노력을 줄여준다.
- 에이전트 평가는 단순히 정답을 맞추는 것을 넘어, 설계 의도대로 플로우를 따랐는지, 정확한 도구를 호출했는지 등을 확인하는 것이 중요하다.
- ADK는 특정 쿼리에 대해 에이전트가 따라야 할 경로(트랙토리)를 정해 놓고 이를 따르는지 평가하는 경로 트랙토리 평가를 지원한다.
- 자연어 아웃풋 평가 시에는 로그 매트릭(Log Metric)이나 LLM을 심판(Judge)으로 활용하는 방식(LLM as a Judge)을 사용한다. LLM을 심판으로 활용하면 사람이 평가하는 것과 거의 차이 없는 정확도를 보이며, 특히 개발 단계에서 매우 유용하다.
- ADK Dev UI는 시각적인 디버깅을 제공한다. 요청 시 어떤 에이전트에게 위임되었는지, 어떤 툴을 사용했는지 등을 그래프 형태로 시각적으로 확인할 수 있으며, 트레이싱 정보도 제공하여 디버깅을 편리하게 한다. 또한 멀티모달(이미지, 비디오 처리) 및 스트리밍 처리도 지원한다.
에이전트 간 통신 표준: A2A (Agent-to-Agent)
- 에이전트가 많아지면 서로 다른 에이전트 간의 인터페이스 문제가 발생할 수 있다.
- 앤트로픽(Anthropic)이 발표한 MCP(Model Context Protocol)는 LLM의 한계를 보완하기 위해 외부 툴 사용을 쉽게 하는 개방형 프로토콜로 빠르게 확산되었다. 이는 기존 OpenAI의 펑션 콜링(Function Calling)이 GPT 생태계 내에서 폐쇄적으로 이루어진 것과 달리, 서버-클라이언트 개념을 차용하여 개발자에게 익숙하고 개방적이라는 점에서 큰 주목을 받았다.
- 구글은 MCP의 부상 당시 외부의 우려에도 불구하고, MCP를 포괄하는 더 큰 생태계를 만드는 청사진을 가지고 A2A라는 개방형 프로토콜을 개발하고 있었다.
- A2A는 에이전트 간 소통을 위한 개방형 프로토콜로, 구글 독점 기술이 아니라 여러 회사와 협력하여 발표되었다. 이는 A2A가 MCP처럼 널리 퍼질 수 있는 가능성을 시사한다.
결론적으로, ADK는 에이전트 개발을 쉽고 빠르며 프로덕션 수준으로 안정적으로 만들 수 있도록 지원하며, A2A는 에이전트 시대에 필수적인 에이전트 간 통신 표준이 될 것으로 기대된다.
내 생각 정리
말 그대로다.
AI 를 이제 슬슬 제대로 공부해야 하고, 배경지식에서 넘어서서 필요한 기술 스택을 배우고, 특히나 내가 중점적으로 생각하는 영역을 학습해야 할 때가 왔다고 생각한다.
그리고 그런 것들을 가능케 하는 도구들, 그 중에도 구글의 입장을 대변하는 것이 오늘 팟캐스트를 통해 들은 내용이다.
이러한 플랫폼으로 어떻게 고객을 먼저 잡는가, 그리고 거기서 개발이 얼마나 편리하게 될 수 있고, 개발 과정이 ‘예측 가능한가’의 강점을 어필할 수 있냐는 항상 AI 라는 혁신의 수면 아래에 잠잠하게 숨겨진 근본적인 한계치 였다.
ADK와 그 내부의 평가 절차, gui 화를 통해 조금이라도 쉽고, 명료하게 개발하며, A2A 등의 존재를 통해 AI 를 적극 제어한다… 등 특히나 확률적인 답변이 정말 의도대로 동작하는가 라는 차원의 문제를 해결하기 위한 구글의 나름대로의 해결책이며, 특히나 모델이 제대로 이해했는가를 평가하기 위해선, 결국 ‘해야할 일을 수행할만한 수준의 AI’에다가, 그 AI의 상황 업무를 판단, AI가 적절했는가를 평가하는 것이 필요하다는, 현재의 구조의 최대의 맹점을 보여주고, 인정하며, 해결하는 구글의 나름의 방식을 제시한 것 같다.
ChatGPT 5 가 처음 나왓을 때, 샘 알트만은 라우팅 처리가 자연스러워서, 필요한 순간 적절한 사이즈의 모델로 답을 해주겠다. 모델을 고를 필요는 없다- 라고 말했었다. 이것이 OpenAI 식의 LLM 이 가지는 근본적인 문제의 대답이었다.
하지만 ChatGPT 는 여전히 그 통제가 사람들이 원하는 수준이 안되었고, 그 결과 사람들에게 내리는 답변의 질, 그리고양 어느 면에서도 납득을 시키지 못해, 결국 슬그머니 다시 기존의 방식으로 돌아갔었다.(아마도 언젠간 다시 라우팅을 시도하지 않을까?)
그만큼 이 일은 매우 까다롭고 어려운데, 결국 이러한 한계를 개선하려면 정확하고, 적절한 평가 체계가 준비되어 있어야 하며, 무엇보다 그 평가체계가 CICD 과정에 통합되어야 개발은 쉬워진다.
그리고 결정적으로 구글이나, OpenAI, 다른 경쟁자들의 이러한 플랫폼 경쟁, 개발 친화 경쟁은 뭘 의미할까?
궁극적으로 신뢰성 + 비용 개선 이 두가지가 핵심이 아닐까 생각해본다.
LLM은 훌륭한건 사실이다. 인프라도 점점 싸질거다. 하지만 여전히 비싸고, 여전히 그 한계와, 사용성 대비 ‘비즈니스’로 취급하기엔 다른 기업들 입장에서 쉽지는 않다는 게 현실이다. 성능면에서나, 자원면에서 적절하게 리소스 분배- 라는 차원으로 사람의 통제하에 있지 못한 면도 여전히 존재한다. 그러한 점에서 통제력을 키우고, 개발자의 의도대로 움직이며, 오히려 더 기계적이게 정확한 인풋에 대해 정확한 답을 내리기, 그리고 그 과정에서 리소스는 최소화하기 - AGI 를 지향하고 가면서도, 소버린 AI 와 같이 안보 차원에서도 적극적인 것에 함께 더불어서 기업이란 관점에서 본다면 ‘최적화’ 와 ‘비용개선’이라는 표면화 하기 어려운 영역에 대해 개선하고 싶은게 아닐까?
그렇기에 생각하건데, 필요한 건 DevOps 관점의 기술과, AI 기술 두가지의 융복합은 필수라고 생각한다.
AI 개발자들의 티오를 보더라도, 1티어를 제외한 나머지 AI 개발자는 사실상 갈 곳이 없다. 그렇다고 백엔드 개발만 해서도 요즘의 시장에서 먹히지 않는 것을 볼 수 있었다.
그런데 또 대담을 하다보면 AI 개발자가 백엔드지식을 이해하고 접근하시는 분도 분명 있지만, 그렇지 않은 분도 월등히 많다는 사실 또한 알 수 있었다.
AI 를 통해 내가 기본적으로 해야할 백엔드 역량을 매우 빠르고, 정확하게 접근할 수 있게 되었으니, 나의 능력을 어디에 쏟아야 할까? 결국 구글이 제시하듯, LLM 의 리소스를 잘 분배하거나, 평가를 통해 요구되는 사항에 최적화된 기능을 제공하고, 궁극적으로 비용 절감이나, 비용 만큼의 신뢰있는 서비스화 할 수 있는가? 그게 내가 생각하는 다음 내 인계점(Inflection Point)이 아닐까 생각한다.