A2A 프로토콜: 소프트웨어개발 패러다임 변화시작
출처 : https://www.youtube.com/watch?v=rAeqTaYj_aI올해 4월에 구글이 발표한 에이전트 간(A2A) 프로토콜은 단순한 AI 업그레이드가 아닙니다. 이는 오랜 기간 지속되어 온 프로그래밍 개발 방식을 넘어, 에이전트들 간에 자율적이고 동적으로 협업하는 시대로의 변화를 예고합니다. 구글은 A2A를 통해 AI 에이전트들이 서로 통신하고 정보를 교환하며 협업할 수 있게 되어 생산성을 높이고 비용을 낮출 것이라고 설명합니다. 이 프로토콜은 앤트로픽(Anthropic)의 모델 컨텍스트 프로토콜(MCP)과 경쟁구도가 아닌 서로 도와주는 역할을 합니다. MCP가 AI가 도구와 데이터를 연결하도록 돕는 표준이라면, A2A는 에이전트 간 협업의 표준 역할을 합니다. A2A의 가장 큰 특징은 내가 원하는 무언가를 만들려고 할 때, 다른 누군가가 만든 에이전트를 발견(discovery)하고, 이를 내가 만든 에이전트와 조합을 해서 새로운 서비스를 만들 수 있다는 것입니다.
기존 소프트웨어를 넘어서
기존 소프트웨어는 명확한 데이터 흐름과 고정된 요구사항에 맞추어서 개발이 되었습니다. 그래서, 예측 가능했고, 서비스 안정성을 보장했습니다. 하지만 LLM(대규모 언어 모델)의 등장으로 출력은 매번 다르며, 다양한 입력에 따라 예상치 못한 결과를 만들어 냅니다. 이를 한 단계 발전시킨 MCP는 AI에게 도구 사용법을 일일이 프로그래밍하지 않고, 도구의 기능을 설명만 해주면 AI가 알아서 활용하게 합니다. 즉, 세부적인 절차를 직접 코딩하던 방식을 버리고, 역량(description of capabilities), 곧 할 수 있는 것들을 정의만 하면 나머지는 시스템에 맡기는 방식으로 바뀌고 있습니다.
A2A: 도구에서 에이전트로 자율성 확장
A2A 프로토콜은 한 발 더 나아가, 에이전트 간의 협업 과정 자체를 자동화합니다. 에이전트는 더 이상 미리 짜놓은 고정된 워크플로우(workflow)를 따르지 않습니다. 예를 들어, A2A에서는 각 에이전트가 자신이 제공할 수 있는 역량을 JSON 형식의 “AgentCard”에 공개하고, 다른 에이전트들이 이를 조회해 적절한 상대를 찾을 수 있습니다. 또한 메시지 한 개에 텍스트·JSON·이미지 등 다양한 콘텐츠가 포함될 수 있어서, 사용자 인터페이스나 데이터 형식도 유연하게 대응가능합니다. 구글은 A2A가 “메모리나 도구를 공유하지 않고도 에이전트들이 자연스럽고 자율적으로 협업할 수 있게” 설계되었다고 밝힙니다. 즉, 소프트웨어 자체가 일종의 살아 있는 시스템이 되어, 예측된 동작이 아니라 그때 그때 상황에 맞게 적절하게 동작하는 것을 목표인 셈입니다.
현실적인 문제들
이처럼 강력한 것인데도 쉽게 다가서기에는 현실적인 문제가 있습니다.
예를 들면:
상태 관리의 복잡성: 자율 에이전트들이 각자 독립된 컨텍스트를 유지하기 때문에 시스템 전체의 상태를 일관되게 관리하기가 매우 어렵습니다. 에이전트들은 불완전한 정보로 학습하고, 전혀 엉뚱한 방향으로 움직일 수 있기에, 잘못된 결정을 스스로 내릴 수도 있습니다.
추론 및 리소스 과부하: 에이전트 간 연동 및 의사결정은 CPU, 메모리, 대역폭 등의 비용을 크게 발생시킵니다. 여러 에이전트가 경쟁적으로 작업을 수행하면 자원을 서로 잠식하기 때문에, 규모가 커질수록 비용이 기하급수적으로 늘어날 수 있습니다.
보안 위험: 에이전트들이 서로를 자유롭게 검색하기에, 신뢰할 수 있는 영역안에 있는 것이 아니라면, 새로운 공격 루트를 만들어주는 것입니다. 예를 들어, 악의적인 에이전트가 정상 에이전트로 위장하거나, 에이전트 간 통신 채널을 통해 시스템 내부로 침투하는 등의 위협이 있습니다.
전통적인 소프트웨어는 인간만이 지능을 가진다고 생각하고, 컴퓨터한테 의사결정권을 주지 않았습니다. 인간이 구상한 틀안에서 프로그램은 동작하도록 개발되어 왔습니다. 그러나 이제는 지능이 컴퓨터한테도 있다라고 가정하고, 의사결정권을 컴퓨터한테 양도하는 셈입니다. 그러면, 더 이상 모든 워크플로우를 미리 짜지 않아도 됩니다. 일부 영역은 컴퓨터한테 위임하면서, 처리해도 되는 것입니다.
패러다임의 변화: 과거 vs. 새로운 방식
전산 운영담당자인데, 시스템에 장애가 난 상황을 가정하겠습니다.
기존 방식은 장애가 발생하면 정해진 "장애대응 메뉴얼" 에 따라 조치합니다. 누가한테 보고할지, 어떤 조치를 언제 취할지 등등 하나하나 명시적으로 프로그래밍해 두어야 하고, 사람이 중간중간 개입해서 프로세스를 처리해야 하는 상황이 발생합니다. 따라서 새로운 상황이 생길 때마다 엔지니어가 개입해 워크플로우를 재조정해야 합니다.
새로운 방식은 사람개입없이 AI 에이전트들이 상황에 맞게 자동으로 협업할 수 있게 됩니다. 어떤 장애가 발생하면 모니터링을 담당하는 에이전트가 시스템 로그나 모니터링 도구에 접근해 상황을 분석합니다. 각 분야의 전문가 에이전트(로그 분석, 네트워크 이상 탐지 등)가 필요한 정보를 제공하고, 마지막으로 관리자 에이전트는 이들을 조합해 원인을 파악합니다. 별도의 프로세스를 개발할 때까지 기다릴 필요 없이, 상황 특성에 맞춰 에이전트들이 스스로 대응팀을 구성하고 해결책을 제시합니다. 이로써 단순히 속도만 빨라지는 것이 아니라, 모든 위기 상황에 지능적으로 적응하는 시스템이 만들어집니다.
에이전트 워크플로우란 무엇인가요?
에이전트 워크플로우는 여러 전문 에이전트가 협업하는 조립 라인(Line)과 같은 개념입니다. 각 에이전트는 자신이 처리해야 할 역할(task)과 접근 가능한 도구(tool)를 알고 있으며, 다른 에이전트와 협력해 공동 목표를 달성합니다.
"AI 에이전트 기반 제안서 분석 워크플로우" 를 예시로 들어보겠습니다.
사용자가 공급업체 제안서 PDF를 에이전트 시스템에 upload 합니다.
-> 에이전트 A (문서 분석): PDF 리더 도구를 사용해 주요 조항과 데이터를 추출합니다.
-> 에이전트 B (규정 확인): 내장된 엔진을 이용해서 회사내규들의 준수 여부를 검토합니다.
-> 에이전트 C (점수 평가): 위험도와 적합도에 따라 점수를 매깁니다.
-> 에이전트 D (요약 생성): 최종 요약문을 작성해 결과를 제공합니다.
각 에이전트는 PDF 리더, 데이터베이스 조회, 채점 엔진 등의 도구를 호출하며 메모리에 중간 결과를 유지하고, 다음 에이전트로 전달합니다. 이렇게 하면 단순한 한 번의 LLM 응답이 아니라, 완전한 자동화가 가능한 워크플로우가 만들어집니다.
그러면, 우리는 무엇을 준비해야 할까요?
에이전트 AI는 빠르게 성장 중이지만, 앞서 현실적인 문제점을 다루었지만, 완전한 생태계 및 활성화를 위해서는 아직 해결해야 할 대표적인 과제 몇가지가 있습니다.
표준화된 인증 및 권한 관리: 현재 대부분의 에이전트는 각 플랫폼에 고유한 인증 메커니즘에 의존합니다. 에이전트가 여러 조직이나 서비스 간에 안전하게 협업하려면 표준화된 인증·인가 모델이 필요합니다.
지속적 메모리 및 컨텍스트 관리: 지금까지 많은 에이전트는 단기 대화나 작업에 초점을 맞춰 설계되었습니다. 에이전트가 어제의 작업을 기억하고 장기 프로젝트를 이어가기 위해서는 지속적인 메모리 시스템과 상태 롤백 메커니즘이 필요합니다. 현재는 이러한 기능이 여전히 초기 단계에 머물러 있습니다.
도구 검색 및 구성 지원: 앞으로 이용 가능한 도구들은 점차 늘어나고 있지만, 에이전트용 도구를 평가할 수 있는 레지스트리나, AI 에이전트 개발을 위한 통합 개발 환경이 구축되어야 실용성이 한층 높아질 것입니다.
마치며
우리는 틀에 박힌 프로그래밍의 시대에서 AI 자율형 시대로 진입하고 있습니다. 오랜 기간 소프트웨어는 사람이 짠 명령만을 그대로 수행했지만, 이제는 시스템 자체가 학습하고 협업할 수 있게 되었습니다. 미래의 소프트웨어 아키텍처는 더 이상 정적 파이프라인이 아니라, 모든 계층에 지능이 살아 숨 쉬는 역동적이고 생명력 있는 생태계가 될 것입니다. 물론 해결해야 할 어려운 문제들과 보안·운영상 위험이 많지만, 그만큼 새로운 가능성도 무궁무진합니다. 우리는 단순한 도구를 만드는 차원을 넘어, 에이전트 생태계를 구축하는 길에 서 있습니다.
