Zero에서의 A2A는 무엇인가요?
Zero A2A는 제품 내부의 에이전트 간 실용적인 의사소통 방식입니다. 한 에이전트가 여러 격리된 채팅을 열 수 있게 해주며, 조정자는 전문가 에이전트에게 제한된 작업을 위임할 수 있게 해주고, 채팅 작성을 위해 @를 입력하여 기존 채팅을 비교, 전달 또는 결정에 가져올 수 있게 해줍니다.
한 작업이 한 번의 긴 대화로는 너무 넓거나 노이즈가 많거나 위험하다면 이는 유용합니다. 한 에이전트가 모든 테스트, 원본, 결정을 동일한 맥락에서 유지하는 대신, 각 작업의 부분을 명확한 집합으로 분류하고 중요한 증거만을 가져옵니다.
Zero에서 A2A가 어떻게 작동하는지 세 가지 방법
| 원하는 작업 | 사용할 설정 | 좋은 첫 번째 시나리오 |
|---|---|---|
| 동일한 방법을 깨끗한 맥락에서 반복 | 한 에이전트, 여러 채팅 | 가입, 요금제, 권한, 모바일을 각각 별도로 테스트 |
| 작업의 일부를 다른 전문가에게 위임 | 한 조정자, 여러 전문가 에이전트 또는 하위 에이전트 | 출시를 연구, 브라우저 퀄리티 어드민, 글쓰기, 출판으로 나누기 |
| 이미 존재하는 작업을 재사용 | 입력창에서 다른 채팅을 @로 불러오기 | 두 QA 보고서를 비교하거나 리서치를 작성 작업으로 전달하기 |
세 가지 제품 객체가 이러한 패턴 뒤에 자리잡고 있습니다:
- 에이전트는 재사용 가능한 작업자입니다. 지시사항, 워크플로, 연결기, 권한, 톤, 역할, 모델 선택을 소유합니다.
- 채팅은 에이전트와의 격리된 한 번의 대화입니다. 테스트, 검토 또는 생산 작업을 자체 맥락에서 유지합니다.
- 런은 채팅 내의 활성 응답입니다. 런은 작업 공간의 동시성 제한에 도달할 때까지 작업을 수행할 수 있습니다.
중요한 세부 사항은 간단합니다: 새로운 하위 채팅은 제어 채팅의 전체 기록을 상속하지 않습니다. 첫 번째 메시지는 작업을 수행하기 위해 필요한 모든 정보를 포함해야 합니다.
A2A, 여러 채팅, 하위 에이전트, 워크플로, 자동화
이 용어는 서로 다른 문제를 해결합니다. 필요한 경계를 제공하는 최소한의 설정을 사용하세요.
| 제품 패턴 | 변경 사항 | 최적 사용 사례 |
|---|---|---|
| Zero에서의 A2A | 에이전트와 채팅 간의 작업 조정 방법 | 위임, 비교, 전달 및 최종 합성 |
| 한 에이전트 아래의 여러 채팅 | 맥락, 지시사항과 권한은 동일하게 유지 | 병렬 테스트, 로케일 체크, 연구 배치 및 모델 평가 |
| 전문가 에이전트 또는 하위 에이전트 | 역할, 지시사항, 모델, 도구 또는 권한 | 연구, 퀄리티 어드민, 글쓰기, 데이터 분석 및 제어된 출판 |
| 워크플로 | 에이전트가 반복할 수 있는 저장된 절차 | 안정적인 체크리스트 또는 다단계 방법 |
| 자동화 | 워크플로를 시작하는 트리거 | 예정된 보고서, 이벤트 기반 분류, 반복적인 검사 |
유용한 지침: 동일한 방법이 유지되는 경우 채팅을 나누고, 방법 또는 접근이 변경되는 경우 전문가 에이전트를 나누고, 동일한 방법으로 반복해야 하는 경우 워크플로를 사용하세요.
1. 한 에이전트가 여러 깨끗한 채팅을 열기
배포를 앞두고 있습니다. 가입, 요금제, 권한, 모바일 모두 최종 검토가 필요합니다. 모든 검사를 한 긴 채팅에 넣는 것은 편리해 보일 수 있지만, 상태가 다음 단계로 유출될 수 있습니다. 요금제 업그레이드가 권한 테스트가 시작되기 전에 계정을 변경할 수 있습니다.
각 여행에 하나의 채팅을 사용하세요.
공통 요약서, 네 개의 격리된 검사, 그리고 하나의 최종 보고서.
25일 2026년 8월에 이 설정을 스테이징 제품에서 재현했습니다. 동일한 Zero 에이전트는 온보딩, 요금제, 동료 권한, 모바일 및 로케일 테스트를 위한 네 개의 실제 채팅을 열었습니다.
각 여행은 자신의 채팅을 가지고 있으므로 증거는 쉽게 검토할 수 있습니다.
다음 프롬프트를 사용해 보세요.
이 staging 릴리스를 네 개의 독립된 작업으로 점검해 주세요. 가입과 온보딩, 결제 업그레이드, 팀원 초대와 권한 거부, 모바일과 로케일 확인에 각각 하나의 채팅을 여세요. 모든 채팅에서 같은 워크스루 에이전트를 사용하세요. 각 작업자는 테스트한 URL, 계정 역할, 번호가 붙은 단계, 스크린샷, 통과/실패 상태, 정확한 재현 단계를 반환해야 합니다. 결과를 이 채팅으로 모으고 중복 블로커를 묶어 주세요.
이 패턴은 다음과 같은 경우에도 작동합니다:
- 각 브라우저 또는 장치 크기당 하나의 채팅
- 각 로케일 또는 계정 역할당 하나의 채팅
- 각 피치 요청 또는 피처 플래그당 하나의 채팅
- 각 리뷰어당 하나의 채팅, 결과는 마지막까지 별도로 유지
- 각 고객 인터뷰 배치 또는 연구 원본 세트당 하나의 채팅
- 공정하게 비교하기 위해 모델당 하나의 채팅
보통 무엇이 잘못되나요? 요약이 너무 짧습니다. “요금제를 확인하세요”는 작업자가 계정, 빌드, 예상 결과, 증거 형식에 대해 추측하도록 합니다. 모든 채팅에 동일한 체크리스트와 별도의 테스트 계정을 제공하세요. 맥락이 변경될 때.
2. @로 다른 채팅을 작업에 불러오기
필요한 작업이 이미 다른 채팅에 있을 때가 있습니다. 리서치 채팅에는 고객 인용문이 있고, QA 채팅에는 스크린샷이 있습니다. 두 번째 검토가 다른 결론에 도달했을 수도 있습니다. 이 내용을 전부 복사해 붙여넣을 필요는 없습니다.
채팅 입력창을 클릭하고 @를 입력하면 Zero가 기존 채팅 목록을 엽니다.
제목을 입력해 목록을 좁힌 다음 필요한 채팅을 선택합니다.
선택한 채팅은 클릭할 수 있는 주황색 칩으로 표시됩니다.
칩은 정확한 온보딩 채팅을 가리키며, 답변은 현재 채팅에 작성됩니다.
그다음 동사를 추가해 Zero가 해당 채팅으로 무엇을 해야 하는지 알려 주세요.
- “
@Onboarding QA와 이 결제 검토를 비교해 줘.” - “
@Customer research batch 2의 작업을 이어서 여기 추천안을 작성해 줘.” - “
@Security review에서 위험도가 가장 높은 결론을 다시 검증해 줘.” - “
@Mobile walkthrough의 스크린샷으로 버그 리포트를 작성해 줘.” - “
@Launch research에서 해결되지 않은 질문을 모두 추출해 줘.”
@를 입력하고 채팅을 선택한 뒤, 그 채팅으로 무엇을 할지 지시합니다.
멘션은 모호한 텍스트 라벨이 아니라 선택한 채팅을 가리키는 주소입니다. 전체 대화를 입력창에 붙여넣지 않아도 Zero가 참조할 채팅을 정확히 알 수 있습니다. 다만 지시에는 분명한 행동이 필요합니다. “이걸 사용해 줘”는 모호합니다. “실패한 단계를 비교하고 공통 블로커의 우선순위를 정해 줘”는 명확합니다.
3. 전문 에이전트나 하위 에이전트에게 작업을 나누기
같은 에이전트의 컨텍스트만 분리하려면 여러 채팅을 사용합니다. 지시, 도구, 모델, 권한 경계가 달라져야 한다면 전문 에이전트를 사용합니다. 코디네이터에게 범위가 정해진 작업을 받는 전문 에이전트를 하위 에이전트라고도 합니다.
제품 출시가 좋은 예입니다. Research Scout는 근거를 검증하고, Browser QA는 출시된 제품을 확인합니다. Launch Writer는 페이지 초안을 작성하고, Publishing Operator는 주장이 검토를 통과한 뒤 CMS 초안을 만듭니다.
staging 워크스페이스에는 하나의 코어 에이전트와 이름이 지정된 네 개의 전문 에이전트가 있으며, 각자 범위가 정해진 작업을 맡을 수 있습니다.
코디네이터가 결과에 책임을 집니다. 전문 에이전트는 근거와 산출물을 반환하고, 한 명의 담당자가 최종 결과를 작성합니다.
실제 출시 작업에서는 다음과 같이 요청할 수 있습니다.
Feature X의 출시 패키지를 조율해 주세요. Research Scout에게 고객 근거와 경쟁사 주장을 검증하도록 요청하세요. Browser QA에게 staging에서 각 제품 주장을 재현하고 스크린샷을 첨부하도록 요청하세요. Launch Writer는 근거가 도착한 뒤에만 페이지 초안을 작성해야 합니다. Publishing Operator는 CMS 초안을 만들 수 있지만 게시해서는 안 됩니다. 누락된 근거와 서로 충돌하는 주장은 이 채팅에 보고해 주세요.
가치는 명확한 경계에서 나옵니다. 리서치 에이전트는 읽기 전용으로 둘 수 있습니다. 게시 에이전트는 게시 권한 없이 초안 접근 권한만 가질 수 있습니다. QA 에이전트는 매번 같은 브라우저 체크리스트를 따를 수 있습니다. Zero의 권한 제어는 이러한 경계를 필요한 만큼만 좁게 유지하는 데 도움이 됩니다.
사이드바를 복잡하게 만들기 위해 전문 에이전트를 추가하지 마세요. 역할이 작업 방식 자체를 바꿀 때 만드세요.
4. 독립적인 검토 결과를 비교하고 판정 에이전트 활용하기
두 번째 검토자가 첫 번째 검토 내용을 그대로 따라 하면 독립 검토의 의미가 없습니다. 새 채팅을 열고 두 검토자에게 같은 근거를 제공하되, 첫 보고서는 서로 보지 못하게 분리해 두세요.
그다음 판정용 채팅을 열고 하나의 프롬프트에서 두 보고서를 모두 멘션합니다.
하나의 프롬프트에서 두 개의 실제 QA 채팅을 참조하고 공통 블로커를 찾도록 Zero에 요청할 수 있습니다.
예를 들면 다음과 같습니다.
@Onboarding QA와@Billing QA를 비교해 주세요. 두 채팅이 모두 찾은 블로커, 한 채팅만 찾은 문제, 아직 부족한 근거를 나열하세요. 그런 다음 릴리스를 진행해도 되는지 결정하세요. 각 블로커를 뒷받침하는 스크린샷이나 단계를 인용하세요.
이 패턴은 디자인 검토, 보안 검토, 공급업체 선정, 아키텍처 선택, 계약 검토, 모델 비교에도 사용할 수 있습니다. 보고서가 도착하기 전에 판정 기준을 정하세요. 그렇지 않으면 판정 에이전트가 가장 강한 근거보다 가장 자신 있게 쓰인 문장을 높게 평가할 수 있습니다.
5. 한 명의 에이전트에서 다른 에이전트로 작업 전달
동시에 작업을 실행하지 않는 것이 좋습니다. 연구는 초안 작성보다 먼저 완료되어야 합니다. 초안 작성은 QA보다 먼저 완료되어야 하고, QA는 출판보다 먼저 완료되어야 합니다.
각 전달은 짧은 배송 노트처럼 다루어야 합니다:
- 수신 에이전트나 채팅의 이름을 명시하십시오.
- 파일 또는 참조 링크를 첨부하거나 참조하십시오.
- 수락 기준을 명시하십시오.
- 수신자가 다시 보고해야 할 위치를 명시하십시오.
“작가에게 발견한 것을 말해라”는 검증하기 어렵습니다. 이는 더 나은 방법입니다:
승인된 연구 요약을 런치 작가에게 보내세요. 초안은 검증된 주장만 사용해야 하며 승인된 용어를 유지해야 하며, 증거가 부족한 부분은
[증거 필요]로 표시해야 합니다. 초안 링크와 해결되지 않은 질문을 이 채팅으로 반환하세요.
@ 채팅 칩은 다음 작업자에게 정확한 출처를 전달할 때 유용합니다. 파일이 많은 작업이라면 산출물 링크도 함께 넘겨 주세요. 코디네이터에게 필요한 것은 상태, 결정, 최종 패키지입니다. 모든 임시 메모를 자신의 컨텍스트에 복사할 필요는 없습니다.
Zero에서 AI 에이전트가 어떻게 컨텍스트를 공유하는가?
Zero의 에이전트는 하나의 거대한 공유 대화가 필요하지 않습니다. 컨텍스트는 명시적인 요약, @ 채팅 언급, 파일 링크, 반환 요약을 통해 이동합니다. 각 작업자는 최소한의 유용한 컨텍스트를 받고 한정된 작업을 완료한 후에 증거나 결정을 조정자에게 반환합니다.
이 접근 방식은 두 가지 일반적인 다중 에이전트 문제를 피합니다. 첫째, 관련 없는 역사는 작업자의 컨텍스트를 막지 않습니다. 둘째, 조정자는 주장이 어떤 출처나 채팅에 의해 지원되는지 정확히 볼 수 있습니다.
다음 네 가지 컨텍스트 공유 패턴을 사용하세요:
- 자체 포함 요약: 새로운 자식 채팅이 깨끗하게 시작해야 할 때 가장 좋습니다.
@채팅 언급: 기존 대화가 출처일 때 가장 좋습니다.- 파일 링크: 문서, 스크린샷, 데이터셋, 코드 변경 등에 가장 좋습니다.
- 구조화된 반환: 여러 작업자가 동일한 형식으로 보고해야 할 때 가장 좋습니다.
자식 채팅이 이미 결정을 알고 있다고 가정하지 마세요. 단어, 제약 조건, 계정, 날짜 범위, 또는 출력 형식이 중요하다면 첫 메시지에 포함시켜야 합니다.
추가 A2A 및 다중 에이전트 작업 흐름 시나리오
| 시나리오 | 어떻게 나눌 것인가 | 무엇이 돌아오나 |
|---|---|---|
| 출시 투어 | 동일한 에이전트, 각 사용자 경로당 하나의 채팅 | 스크린샷, 패스/실패 체크, 공유 장애 요인 |
| 로케일 QA | 동일한 에이전트, 각 언어당 하나의 채팅 | 깨진 문자열, 레이아웃 문제, 언어별 스크린샷 |
| 브라우저 및 기기 테스트 | 동일한 에이전트, 각 브라우저 또는 뷰포트당 하나의 채팅 | 비교 테스트 매트릭스와 증거 |
| 피치 요청 검토 | 동일한 에이전트, 각 피치 또는 검토 각도당 하나의 채팅 | 버그, 위험 노트, 라인 수준 권장 사항 |
| 고객 연구 | 동일한 에이전트, 각 인터뷰 배치당 하나의 채팅 | 인용, 패턴, 반대 의견, 출처 링크 |
| 사고 응답 | 조정자 및 앱, API, 배포, 고객 영향 에이전트 | 일정 시간표와 의견 충돌을 명시한 하나의 시간표 |
| 콘텐츠 생산 | 연구, 쓰기, 디자인, QA, 출판 에이전트 | 검토된 초안과 통제된 출판 전달 |
| 고객 지원 분류 | 조정자 및 계정, 제품, 청구, 답변 에이전트 | 원인, 우선 순위, 소유자, 초안 답변 |
| 데이터 분석 QA | 분석가 에이전트와 독립적인 검토자 | 확인된 조인, 분모, 시간대, 가정 |
| 모델 비교 | 동일한 요약과 다른 모델로 깨끗한 채팅 | 정확도, 비용, 지연 시간, 형식 점수 |
적절한 분할은 유용한 경계를 만듭니다. 이는 컨텍스트를 격리하거나 권한을 보호하거나 검토를 독립적으로 유지하거나 준비된 작업이 동시에 실행될 수 있도록 합니다.
하나의 채팅, 여러 채팅, 여러 에이전트를 언제 사용해야 하는가?
각 다음 단계가 바로 전에 있는 답변에 의존하는 경우 하나의 채팅을 사용하세요. 순차적인 디버깅 세션이 좋은 예입니다.
동일한 지시사항이지만 깨끗한 컨텍스트나 독립적인 증거가 필요할 때 하나의 에이전트 아래 여러 채팅을 사용하세요. 이는 테스트, 연구 배치, 공정 비교의 일반적인 시작점이 됩니다.
각 부분이 다른 전문 지식, 연결자, 권한, 모델이 필요할 때 다양한 전문가 에이전트를 사용하세요. 한 조정자가 최종 결정을 책임지도록 합니다.
작업 흐름을 사용할 때 절차가 반복될 수 있어야 합니다. 자동화는 절차가 일정이나 이벤트 트리거가 필요할 때만 추가합니다. Zero는 이 두 구성 요소를 별도로 문서화합니다: 작업 흐름은 방법을 정의하고, 자동화는 언제 실행되는지 결정합니다.
A2A 보안 및 권한 경계
다중 에이전트 작업은 각 전문가가 필요한 연결자와 권한만을 가진 경우에 더 안전합니다. 연구 에이전트는 일반적으로 출판 권한이 필요하지 않습니다. QA 에이전트는 스테이징 로그인은 필요하나 생산 비용 관리 권한은 필요하지 않습니다. 출판 에이전트는 초안에 접근할 수 있지만 최종 출시는 여전히 사람이 승인해야 합니다.
외부 쓰기는 한 명의 이름으로 지정된 소유자 아래에 유지되어야 합니다. 여러 에이전트는 저장소, CRM, CMS를 읽을 수 있지만 최종 티켓을 생성하거나 기록을 업데이트하거나 고객에 대한 답변을 보내거나 페이지를 출판하는 것은 한 에이전트만이 해야 합니다. 이는 중복 쓰기를 방지하고 검사 기록을 쉽게 따라갈 수 있도록 합니다.
고위험 작업에서는 요약에 중지 조건을 추가하세요: "초안만", "보내지 마세요", "증거 충돌 시 상신하세요", "생산 변경 전에 승인 요청하세요". A2A는 위임을 쉽게 만듭니다. 그러나 명확한 책임감이 필요합니다.
네 가지 규칙으로 A2A 작업을 정리합니다
1. 첫 메시지는 모든 정보를 포함해야 합니다
목적, 원본 자료, 제약 조건, 출력 형식, 목적지, 그리고 중지 조건을 포함해야 합니다. 자식 채팅은 제어 채팅이 이미 알고 있는 정보를 추측하지 않아야 합니다.
2. 작업자에게 동일한 응답 형식을 제공하십시오
네 개의 QA 채팅이 네 가지 다른 형식을 반환하면 채팅 조정자는 텍스트를 정리하는 데 시간을 보내야 합니다. 각 작업자에게 동일한 필드를 요청하십시오: 환경, 단계, 증거, 상태, 그리고 다음 작업.
3. 공유 쓰기를 한 명의 소유자에게 맡깁니다
두 개의 올바른 에이전트조차도 쓰기 작업을 두 번 수행하여 혼란을 일으킬 수 있습니다. 최종 외부 작업의 소유자를 지정하십시오.
4. 나눌 필요가 있는 작업만 나누십시오
여덟 개의 채팅을 생성하더라도 여덟 개의 실행이 동시에 실행되는 것은 아닙니다. 작업 공간의 병렬성은 여전히 적용되며, 의존 작업은 입력을 기다려야 합니다. 이전 답변에 의존하는 모든 다음 단계가 있는 작업은 한 채팅에 유지되어야 합니다.
Zero A2A와 Google의 Agent2Agent 프로토콜은 동일한가요?
여기서 프로토콜 동등성을 주장하지 않습니다. 이 가이드는 Zero 내에서 에이전트와 채팅 간의 제품 수준 조정 방법을 설명합니다: 작업이 나누어지며, 참조되며, 평가되며, 인터페이스를 통해 전달되는 방법.
Google의 Agent2Agent 오픈 프로토콜은 원격 에이전트 시스템 간의 통신 기술 표준으로, 능력 발견, 작업 관리, 메시지 및 아트리팩트를 포함합니다. "A2A"에 대한 검색 결과는 종종 이 프로토콜에 집중하므로 차이가 중요합니다: Zero A2A는 이 기사에서 다루는 실제 제품 작업 흐름입니다.
자주 묻는 질문
채팅과 에이전트는 동일한가요?
아니요. 에이전트는 재사용 가능한 작업자 구성입니다. 채팅은 해당 에이전트와 격리된 한 번의 대화입니다. 한 에이전트는 여러 채팅을 소유할 수 있습니다.
자식 채팅은 제어 채팅의 맥락을 공유합니까?
아니요. 각 자식 채팅은 완전한 요약을 시작해야 합니다. 작업자는 결과를 반환하거나 한 채팅에 제한된 아트리팩트를 전달할 수 있지만 공유 역사가 가정되어서는 안 됩니다.
@를 사용하면 무엇이 일어나나요?
Zero는 선택한 채팅에 구조화된 참조를 삽입합니다. 참조는 당신이 의미하는 대화를 식별합니다. 전체 대화가 콘스터저에 붙여지지는 않으므로 비교, 검토, 계속, 또는 추출과 같은 명확한 작업을 추가하십시오.
Zero에서 서브에이전트는 무엇인가요?
서브에이전트는 채팅 조정자로부터 제한된 작업을 받는 전문가 에이전트입니다. 다른 지시사항, 도구, 권한, 또는 다른 모델을 사용할 수 있으며 결과를 제어 채팅으로 반환합니다.
병렬로 여러 채팅이 실행될 수 있나요?
네, 작업 공간 병렬성이 사용 가능하고 작업이 독립적일 때입니다. 작업 제한이 초과되면 추가 작업은 대기열에 대기할 수 있습니다. 의존 작업은 순차적으로 실행되어야 합니다.
다른 에이전트를 사용해야 언제인가요?
작업이 다른 지시사항, 흐름, 모델, 연결자 또는 권한이 필요할 때 다른 에이전트를 사용해야 합니다. 동일한 에이전트 아래의 여러 채팅을 사용할 때 주로 깨끗한 맥락이 필요할 때입니다.
첫 번째 시험용 가이드를 먼저 시도해 보세요
새 채팅을 Zero에서 열고 실제 출시 체크를 네 개의 깨끗한 채팅으로 나눕니다. 각 채팅에서 캡처 화면과 동일한 통과/실패 형식을 요청하십시오. 그 작업이 성공하면 전문가 에이전트를 한 가지 분기로 대체하거나 평가 프롬프트에서 두 개의 완료된 채팅을 언급하십시오.
더 많은 아이디어를 얻으려면 20 AI 에이전트 사용 사례와 정확한 프롬프트 및 도구를 참조하십시오.
