프로덕션 운영

​

A2A 보안 고려사항

​

인증 (Authentication)

• Agent Card의 authentication.schemes 필드로 지원하는 인증 방식을 명시합니다
• OAuth2 가 권장 방식입니다. 토큰 만료, 스코프 제한 등 세밀한 제어가 가능합니다
• API Key 는 구현이 간단하지만 보안이 약합니다. 개발/테스트 환경에만 권장합니다
• Mutual TLS (mTLS) 는 양방향 인증서 검증으로, 높은 보안이 필요한 금융/의료 환경에 권장됩니다

​

인가 (Authorization)

• Agent가 요청할 수 있는 skill 범위를 제한해야 합니다
• Task 생성 권한과 특정 skill 호출 권한을 분리하여 관리합니다
• 예: “항공 Agent는 search_flights만 가능, book_flight는 별도 권한 필요”와 같이 세분화합니다

​

데이터 보안

• Agent 간 전달되는 모든 데이터는 TLS 암호화가 필수 입니다
• PII(개인정보) 전달 시 마스킹 또는 토큰화를 적용합니다
• 민감 데이터는 Artifact로 직접 전달하지 않고, 참조 ID만 전달 하여 수신 Agent가 별도 인증 후 조회하도록 합니다

​

Trust Boundary (신뢰 경계)

• 내부 Agent 와 외부 Agent 를 명확히 구분합니다
• 외부 Agent의 응답은 항상 검증합니다 (LLM-as-Judge 또는 규칙 기반 검증)
• 외부 Agent에게 쓰기 권한 을 부여할 때는 특히 주의가 필요합니다

​

주요 위협과 대응 방안

주의 보안 설계의 핵심 원칙: 최소 권한 원칙(Principle of Least Privilege) 을 적용하세요. 각 Agent에게는 작업 수행에 필요한 최소한의 skill과 데이터 접근 권한만 부여합니다.

​

A2A의 현실적 한계와 대안

​

현재 A2A 채택 현실

1. 이기종 벤더의 Agent가 협업 해야 하는 경우 (예: 우리 Agent + 파트너사 Agent)
2. 조직 간 경계를 넘는 Agent 통신(예: 본사 Agent + 자회사 Agent)
3. Agent 마켓플레이스 구축 시 (다양한 3rd party Agent를 플러그인처럼 연결)

​

MCP로 Multi-Agent를 구현하는 패턴

[Orchestrator Agent]
    │
    ├── MCP ──→ [데이터 분석 Agent (MCP Server로 래핑)]
    │              └── Tool: "analyze" (내부적으로 LLM 호출)
    │
    ├── MCP ──→ [리포트 생성 Agent (MCP Server로 래핑)]
    │              └── Tool: "generate_report" (내부적으로 LLM 호출)
    │
    └── MCP ──→ [Slack 알림 Agent (MCP Server로 래핑)]
                   └── Tool: "notify" (내부적으로 LLM 호출)

참고 실용적 조언: 지금 당장 Multi-Agent가 필요하다면 MCP 래핑 방식으로 시작하세요. 상태 관리나 Agent 발견이 절실해지는 시점에 A2A로 전환해도 늦지 않습니다.

​

현실적 도입 로드맵

​

A2A 설계 패턴 카탈로그

​

1. 위임 패턴 (Delegation)

Client Agent ──tasks/send──→ Server Agent
Client Agent ←──completed───── Server Agent (Artifact 포함)

• 번역 요청: “이 문서를 영어로 번역해줘”
• 데이터 조회: “지난 달 매출 합계를 알려줘”
• 코드 리뷰: “이 PR을 리뷰해줘”

​

2. 협상 패턴 (Negotiation)

Client Agent ──tasks/send──→ Server Agent
Client Agent ←──input-required── Server Agent ("예산 범위는?")
Client Agent ──message 추가──→ Server Agent ("100만원 이내")
Client Agent ←──input-required── Server Agent ("조식 포함 필요?")
Client Agent ──message 추가──→ Server Agent ("네, 조식 포함")
Client Agent ←──completed───── Server Agent (최종 결과)

• 호텔 예약: 날짜만 주어지고 세부 조건은 대화로 확인
• 보고서 작성: 대략적 주제에서 구체적 분석 방향을 좁혀감
• IT 헬프데스크: 증상 설명 → 추가 진단 질문 → 해결책 제시

​

3. 파이프라인 패턴 (Pipeline)

Orchestrator ──Task 1──→ Agent A (데이터 수집)
Orchestrator ←──Artifact 1─── Agent A
Orchestrator ──Task 2 (Artifact 1 포함)──→ Agent B (데이터 정제)
Orchestrator ←──Artifact 2─── Agent B
Orchestrator ──Task 3 (Artifact 2 포함)──→ Agent C (시각화)
Orchestrator ←──Artifact 3─── Agent C

• ETL 파이프라인: 추출 Agent → 변환 Agent → 적재 Agent
• 콘텐츠 제작: 리서치 Agent → 초안 작성 Agent → 편집 Agent
• 보안 분석: 로그 수집 Agent → 이상 탐지 Agent → 대응 권고 Agent

​

4. 경쟁 패턴 (Competition)

Orchestrator ──Task (동일)──→ Agent A (GPT 기반)
Orchestrator ──Task (동일)──→ Agent B (Claude 기반)
Orchestrator ──Task (동일)──→ Agent C (Gemini 기반)

Orchestrator ←──결과 A── Agent A (3초)
Orchestrator ←──결과 B── Agent B (2초)  ← 가장 빠름
Orchestrator ←──결과 C── Agent C (5초)

→ 결과 B 채택 (또는 3개 결과를 비교하여 최선 선택)

• 번역 품질 비교: 여러 번역 Agent의 결과를 비교하여 최선 채택
• 가격 비교: 여러 항공사/호텔 Agent에 동시 검색하여 최저가 선택
• LLM-as-Judge: 여러 Agent의 답변을 평가 Agent가 비교 채점

​

5. 패턴 선택 가이드

​

Databricks에서의 활용 전망

주의 A2A는 2025년 초 발표된 프로토콜로, 아직 초기 단계입니다. Databricks의 공식 A2A 지원은 추후 발표를 확인하세요.

​

흔한 오해 (Common Misconceptions)

​

고객이 자주 묻는 질문

​

”A2A를 지금 도입해야 하나요?”

​

”A2A와 REST API의 차이가 뭔가요?”

• 자기소개 (Agent Card): Agent가 자신의 능력을 표준화된 형식으로 공개
• 상태 관리 (Task lifecycle): 작업의 진행 상황을 추적하고, 추가 정보 요청도 가능
• 스트리밍: 장기 실행 작업의 중간 결과를 실시간으로 수신

​

”MCP만 쓰면 안 되나요?”

• 도구 연동만 필요 → MCP
• Agent 간 협업 필요 → A2A
• 둘 다 필요 → A2A + MCP 결합

​

연습 문제

1. MCP와 A2A의 핵심 차이를 “택배 시스템”에 비유하여 설명하세요.
2. Agent Card에서 skills 필드가 왜 중요한지, 이 필드가 없다면 어떤 문제가 발생하는지 설명하세요.
3. Task 상태 중 input-required가 존재하는 이유와, 이 상태가 없다면 어떤 한계가 있을지 설명하세요.
4. “사내 IT 헬프데스크”를 A2A로 설계한다면 어떤 Agent들이 필요하고, 각 Agent의 Agent Card를 어떻게 정의하겠습니까?