지난 2년 동안 AI 엔지니어링은 단순한 시나리오를 따랐습니다. 에이전트에게 프롬프트, 몇 가지 도구, 그리고 메모리 레이어를 제공합니다. 그러면 에이전트가 회의 일정을 잡거나, 계약서를 요약하거나, 스크립트를 디버깅하는 것을 지켜보기만 하면 되었습니다. 전체적인 목표는 단일 에이전트가 그 자체로 유용하게 만드는 것이었습니다.
그 목표가 변했습니다.
이제 우리는 업계가 단독 에이전트에서 에이전트 팀으로 전환되는 것을 목격하고 있습니다. 고객 서비스 분류 봇이 환불 요청을 식별하고 해당 케이스를 결제 에이전트에게 전달합니다. 웹 데이터를 스크래핑하는 리서치 에이전트가 특정 분야의 공백을 발견하면, 독점 데이터베이스를 보유한 전문가 에이전트에게 작업을 위임합니다. 배송을 계획하는 물류 에이전트가 실시간 화물 견적이 필요하면 가격 책정 에이전트에게 수치를 요청합니다.
서류상으로는 간단해 보이지만, 실제로는 취약합니다.
새로운 과제는 상호 운용성입니다. 팀마다 서로 다른 프레임워크로 에이전트를 구축합니다. 서로 다른 벤더가 서로 다른 인터페이스를 가진 에이전트를 출시합니다. 한 회사가 다른 회사와 협업해야 할 때, 그 격차는 더욱 벌어집니다. 현재 우리는 공통 언어가 없는 유능한 작업자들로 가득 찬 환경에 놓여 있습니다. 에이전트는 디렉토리에서 다른 에이전트를 찾아볼 수 없습니다. 동료가 무엇을 하는지에 대한 설명을 읽을 수도 없습니다. 또한 데이터 유출, 컨텍스트 손실 또는 중복 실행의 위험 없이 민감한 작업을 넘겨줄 수도 없습니다.
이것이 바로 A2A가 해결하고자 하는 문제입니다. A2A는 에이전트에게 발견, 위임 및 안전한 협업을 위한 공통 프로토콜을 제공합니다.
단일 에이전트에서 에이전트 사일로로
첫 번째 에이전트 프레임워크의 물결은 시스템의 경계를 에이전트의 경계로 취급했습니다. 추론 루프를 구축하고 도구 벨트를 제공한 뒤, 에이전트가 워크플로우를 스스로 해결해 나가기를 기대했습니다. 에이전트가 하나의 코드베이스, 하나의 클라우드 계정 또는 하나의 벤더 플랫폼 내에 머물 때는 이 방식이 충분히 잘 작동했습니다.
실제 비즈니스는 모놀리스(monoliths) 내부에서 운영되지 않습니다. 환불 요청은 CRM에서 시작되어 Python으로 작성된 내부 결제 서비스로 전달된 다음, 제3자가 호스팅하는 사기 탐지 서비스에서 끝날 수 있습니다. 이러한 각 서비스를 에이전트로 모델링하면, 서로 다른 스택에서 구축된 에이전트들이 기본적으로 서로를 이해하지 못한다는 사실을 곧 깨닫게 됩니다. 독점 프레임워크로 구축된 엔터프라이즈 에이전트는 자신의 역량을 외부 세계에 알리지 않습니다.
표준이 없으면 모든 통합은 커스텀 프로젝트가 됩니다. 엔지니어들은 일회성 글루 코드(glue code)를 작성해야 합니다. 번역 과정에서 컨텍스트가 손실됩니다. 각 핸드오프(handoff)가 맞춤형으로 이루어지기 때문에 보안 정책이 일관되지 않게 됩니다.
에이전트 카드: 공개 이력서
A2A는 에이전트가 자신이 누구인지, 무엇을 할 수 있는지 알리는 방법으로 에이전트 카드(Agent Cards)를 도입합니다.
에이전트 카드를 기계가 읽을 수 있는 이력서라고 생각하십시오. 에이전트는 자신의 도메인, 필요한 입력값, 예상 출력값, 그리고 수락 가능한 작업에 대한 제약 조건을 설명하는 카드를 게시합니다. 결제 에이전트는 주문 ID와 사유 코드가 제공될 때 특정 금액 미만의 환불 요청을 처리하며, 확인 번호나 오류를 반환한다고 선언할 수 있습니다. 데이터 전문가는 특정 크기까지의 구조화된 파일을 수락하고 예측 가능한 시간 내에 정제된 시계열 데이터를 반환한다고 명시할 수 있습니다.
작업을 위임하기 전에 요청 에이전트는 카드를 읽습니다. 대상 에이전트가 해당 작업을 수행할 능력이 있는지 파악합니다. 페이로드가 어떤 형식을 갖춰야 하는지 배웁니다. 동기식 응답을 기대해야 하는지, 아니면 나중에 완료될 비동기식 작업인지 알게 됩니다.
이를 통해 추측할 필요가 없어집니다. 가능한 모든 파트너에 대해 통합 코드를 하드코딩하는 대신, 에이전트는 사용 가능한 역량을 탐색하고 적절한 팀원을 동적으로 선택할 수 있습니다.
태스크: 단순한 API 호출이 아닌 구조화된 작업
에이전트는 인간처럼 대화할 필요가 없습니다. 작업을 깔끔하게 넘겨주어야 합니다. A2A는 이러한 교환을 태스크(Task)로 모델링합니다.
태스크는 ~ 이상의 것입니다