A2A 1.0 이후: 다른 회사의 에이전트와 일을 나누는 기준

2026년 안정판 발표에서 달라진 출발점

A2A 프로젝트는 2026년 3월 12일 v1.0을 첫 안정판으로 발표했습니다. 서로 다른 구현의 에이전트가 작업과 결과를 교환하는 표준이며, 발표는 서명된 Agent Card 등을 설명합니다. 이는 조직 사이의 연결 방식을 맞추는 진전입니다. 상대 업체의 업무 품질이나 계약 이행을 인증하는 제도가 생겼다는 뜻은 아닙니다.

• A2A · v1.0 안정판 발표 (2026-03-12)
• A2A · Protocol Specification v1.0.1

토핑이 업무 시스템 연동 관점에서 보는 핵심은 상대의 내부 구현을 몰라도 협의 가능한 경계를 만드는 일입니다. 각 회사가 자체 모델과 데이터를 유지하되 요청 목적, 전달 항목, 결과 형식과 책임자를 합의해야 합니다. 기존 API로 충분한 단순 조회라면 에이전트 간 협상까지 도입할 필요는 없습니다.

납기 확인과 발주 확정은 다른 위임입니다

가상의 제조사가 부품 공급사에 납기를 확인한다고 가정해 보겠습니다. 내부 에이전트는 품목 식별자, 필요 수량과 희망일을 보내고 공급사 에이전트는 공급 가능일과 견적 유효기간을 답합니다. 이때 납기를 문의할 권한만 줬다면 가격을 수락하거나 발주서를 확정하는 단계로 넘어가서는 안 됩니다.

외부에 보낼 정보는 요청에 필요한 부분부터 정합니다. 공급사가 알아야 할 것은 해당 부품의 주문 조건이지 전체 생산 계획이나 다른 업체의 견적은 아닐 수 있습니다. 질문이 모호해 추가 정보가 필요해지면 내부 담당자에게 돌아오는 경로를 두고, 상대 에이전트의 추가 요청만으로 공유 범위를 늘리지 않습니다.

연결 계약과 업무 계약을 함께 맞춥니다

Agent Card의 기능 설명을 읽는 단계와 그 기능을 실행할 권한을 얻는 단계는 나눕니다. 운영에서는 상대 엔드포인트와 인증 주체, 적용하는 명세 버전, 허용 요청 종류를 관리 목록에 기록하는 편이 좋습니다. 담당 회사가 바뀌거나 주소가 변경되면 이름이 같더라도 기존 승인을 자동 승계하지 않도록 검토합니다.

작업을 받았다는 응답은 납기 확약과 다릅니다. 요청 식별자와 상대 작업 식별자를 연결하고, 처리 중·추가 자료 필요·완료·거절을 업무 화면에서 구분하세요. 연결이 끊겼을 때 새 요청부터 보내면 같은 문의가 여러 건 생성될 수 있으므로 먼저 기존 작업을 조회할 수 있는지 확인해야 합니다.

연결 성공 다음에 검수할 것

도입 검수에는 정상 견적 외에도 알 수 없는 품목, 만료된 결과, 잘못된 통화와 응답 도중 끊긴 연결을 포함합니다. 상대가 완료라고 표시했더라도 내부 발주 조건에 맞지 않으면 수락하지 않아야 합니다. 에이전트가 내놓은 설명보다 실제로 보존된 요청·승인·발주 기록이 일치하는지를 확인합니다.

시범 운영은 납기 조회처럼 되돌리기 쉬운 업무에서 시작할 수 있습니다. 업무 담당자가 기존 방식과 결과를 비교한 뒤 견적 요청, 승인 후 발주처럼 범위를 넓히세요. 상대 서비스가 중단되었을 때 사람이 이어받을 연락처와 미처리 목록을 확보해야 프로토콜 연결이 실제 협업으로 이어집니다.