Hacker News 의견

• A2A와 MCP 프로토콜의 실제 예시를 찾기 어려움. 간단한 대화 예시와 JSON을 보고 싶음. 이와 관련된 치트 시트를 만들 계획임

  • MCP는 현재 사람들이 겪는 특정 문제를 해결하는 데 중점을 둠. LLM이 훈련되지 않은 데이터에 접근해야 하지만, 이를 구현하기 어려움. MCP는 LLM이 클라이언트를 통해 API를 호출할 수 있는 표준을 정의함
  • A2A는 Google이 기술 파트너와 함께 해결하려는 마케팅 문제를 다룸
  • 6개월 후에도 남아 있을 프로토콜이 무엇인지 알 것 같음. 모든 기여자가 같은 회사에 속한 프로토콜은 아닐 것임

• JSON 사양이 MCP와 유사함. Google이 원하는 웹사이트의 기능을 설명하는 에이전트 카드가 있음. 크롤러가 에이전트를 발견할 수 있도록 함

  • JSON-RPC 호출이 MCP 도구 호출과 유사하지만, 입력과 출력이 LLM 호출의 입력/출력과 더 유사함
  • JS 서버 예시가 흥미로움. SSE 이벤트를 호출자에게 보내기 위해 생성기를 사용함. API로 노출하는 것이 다소 이상함

• SOA와 WSDL을 재발견하는 것인지 궁금함. 소프트웨어 공학 학위에 다양한 아키텍처, 방법론, 패턴의 역사 과목을 포함해야 할지 고민 중임

• MCP 보안과 프롬프트 주입에 대한 노트를 게시함. MCP 자체에는 보안 결함이 없지만, LLM이 사용자 대신 행동할 수 있는 도구에 접근할 수 있도록 하는 패턴이 프롬프트 주입 공격에 취약함

• A2A는 에이전트 간의 통신을 위한 것임. MCP는 에이전트가 도구와 통신하는 방법임

  • A2A는 작업, 작업 준비 등의 개념을 포함함. 작업을 주고 며칠 후 완료를 기대할 수 있으며, 웹훅이나 폴링을 통해 알림을 받을 수 있음
  • 최종 사용자에게 A2A는 혼란을 초래할 수 있으며, 많은 MCP 사용을 대체할 수 있음

• MCP는 호스트에게 프롬프트, 리소스, 도구를 노출함. A2A는 기능 발견, 작업, 협업, 사용자 경험 논의를 노출함

  • 이러한 개념에 동의하는 것이 합리적임. 완전히 지정된 프로토콜이 필요한지 의문임. API 엔드포인트/기능에 대한 모범 사례를 가질 수 있지 않을까 생각함
  • MCP에 대해서도 비슷한 생각을 가짐. /prompts라는 API 엔드포인트를 가지는 관례를 가질 수 있지 않을까 생각함

• MCP만으로도 A2A가 주장하는 주요 사용 사례를 이미 허용할 수 있을 것 같음. MCP 서버 뒤에 에이전트를 두면, 에이전트가 다른 도구처럼 쿼리할 수 있음. A2A가 필요하지 않을 수 있음

• 이 프로토콜은 데이터를 중개자에게 맡기고, 이를 검색을 통해 다시 판매하는 것임. LLM에 미래를 거는 회사들은 법적으로 사용할 수 있는 데이터가 유일한 장기적인 차별점임을 깨달음

  • 모든 사람이 거의 동일한 공공 데이터 접근을 가지게 되면서, 목표는 개인 텍스트 데이터를 영원히 그들에게 전송하여 데이터에 대한 최신화되고 조정된 모델을 가지는 것임

• MCP는 에이전트가 자원을 표준 방식으로 사용할 수 있도록 함. A2A는 에이전트가 서로 협력할 수 있도록 함