MCP와 A2A가 바꾸는 Agentic PM 시대 — PM 코치가 해석하는 PO·PM·PL의 준비
본 글은 MCP · A2A 프로토콜 영역의 2026년 5월 시그널을 반영해 본문 약 35%를 재작성한 v3 개정본입니다. 2026-04-18 v2 발행본 이후 1개월 사이 발생한 구조적 시그널을 통합하면서 다음 프레임 전환을 적용했습니다.
프레임 전환: “MCP vs A2A vs ACP 경쟁” → “2-layer 스택(MCP vertical · A2A horizontal · ACP lateral) + Linux Foundation 단일 거버넌스 정렬” 프레임 전환
통합된 1개월 시그널 (09편 월간 관전포인트 2026-05에서 도출):
- #6 Linux Foundation 정렬 — MCP·A2A·ACP 모두 Linux Foundation 산하 joint working groups + cross-protocol interoperability commitments (2026-05-06 update) (출처)
- #7 A2A v1.0 GA — gRPC · signed Agent Cards · multi-tenancy 추가 — 에이전트 상호 식별·인증·과금이 사양 안으로 (출처)
- #1 Claude Opus 4.7 GA — Managed Agents의 private MCP sandbox 연결 — 사내 MCP 서버 보안 검토 부담 완화 (출처)
갱신 일자 2026-05-28 · 갱신 근거 추적은 09편 월간 관전포인트 — 1개월 시그널 13선 카드에서 1차 인용을 함께 확인하실 수 있습니다.
PM 코치가 해석하는 Agentic PM 시리즈 · 1편 (시리즈 누적 35번째 · 8편 마감편의 첫 문) “8주 동안 PO·PM·PL이 먼저 준비할 것 vs 나중에 키울 것”
2026년 4월 9일 Linux Foundation은 Agent2Agent(A2A) 1주년을 맞아 150+ 조직·GitHub stars 22,000+·5개 언어 SDK·3대 클라우드(AWS Bedrock AgentCore·Azure AI Foundry·Google Cloud) 네이티브 통합을 공식 발표했고 (출처), 1주 전 뉴욕에서 열린 MCP Dev Summit North America 2026(1,200명·17 keynote·95+ 세션)과 동시에 x402 Foundation이 별도 재단으로 발족하면서 결제 레이어가 분리되었습니다 (출처). 한 달 뒤인 2026-05-06 Zylos.ai 리서치는 MCP·A2A·ACP가 모두 Linux Foundation 산하 joint working groups + cross-protocol interoperability commitments로 거버넌스를 단일화했다고 정리했습니다 (출처).
PM 코치로서 저는 이 일련의 사건을 한 문장으로 압축합니다 — 2026 Q2의 프로토콜 질문은 더 이상 “MCP vs A2A vs ACP 중 어느 진영에 베팅할 것인가”가 아닙니다. 셋 모두 한 단체 산하에서 상호 운용을 약속한 상태이고, 실제 의제는 “툴 통합(vertical) · 에이전트 조정(horizontal) · 메시징(lateral) 세 축을 어떤 거버넌스 게이트로 묶을 것인가“로 이동했습니다. Uber의 운영계 볼륨 — 월 1,500+ active agents, 주 60,000+ executions (출처) — 은 이 이동이 파일럿이 아니라 인프라 가정 위에서 굴러간다는 증거입니다.
이 글은 Agentic PM 시리즈 마감편 8편 중 1편이며, 마지막 9편 2026-05 월간 시그널 워치 (09편 cross-link) 에서 본 편의 프레임을 한 달 단위 신호로 점검합니다. 시리즈 전반의 34편에서 B-3 “AI 시대 PM/PL 역량이 근본부터 바뀌어야 하는 이유” 가 역량 변화의 큰 그림을, G-2 “주니어 PM을 위한 AI 하네스 구축 가이드” 가 개인 하네스 조립법을, G-3 “대기업 직장인을 위한 AI Agent & Skill 추천 가이드” 가 도구 랜드스케이프를 정리했습니다. 본 편은 그 위에 2-layer + 1-lateral 스택(MCP 툴 통합 vertical · A2A 에이전트 조정 horizontal · ACP 메시징 lateral) + 단일 거버넌스 단체(Linux Foundation/AAIF) 정렬이라는 프레임을 얹고, PO·PM·PL 결재 라인과 연결합니다. 단계적 과제 대신 L3→L4→L5 역량 진입 조건을 축으로 삼아 Post 8 캡스톤에서 24-cell 매트릭스로 집약합니다.
- MCP·A2A·ACP는 2026 Q2 현재 “경쟁 진영”인가 “단일 단체 정렬 스택”인가 — 거버넌스의 무게중심은 어디로 옮겨갔습니까?
- 세 프로토콜을 “vertical 툴 통합 · horizontal 에이전트 조정 · lateral 메시징” 2-layer + 1-lateral 스택으로 읽으면 PM 결재 라인은 어떻게 바뀝니까?
- A2A v1.0 GA가 사양 안에 넣은 gRPC · signed Agent Cards · multi-tenancy는 사내 에이전트 등록부를 어떻게 표준화합니까?
- Claude Opus 4.7 Managed Agents의 Private MCP Sandbox는 사내 보안 검토 부담을 얼마만큼 줄일 수 있습니까?
- PO·PM·PL이 L3→L4→L5 역량 래더 어느 단계에 서야 Deloitte “거버넌스 성숙 21%”·Gartner “40% 취소” 비대칭을 피할 수 있습니까?
근거: LG WebEx 세미나 정의 기반 — lecture/lge-webex-seminar-ai-agent-pm/02-slide-fulltext.md:277-283
프레임 시프트: "경쟁 3진영"에서 "2-layer + 1-lateral 단일 거버넌스 스택"으로
지난 12개월 PM 코칭 현장에서 가장 자주 받은 질문은 “우리는 MCP 진영에 붙어야 합니까, A2A 진영에 붙어야 합니까, ACP를 따로 가야 합니까?” 였습니다. 2025년까지는 이 질문이 합리적이었습니다. 세 프로토콜은 각각 다른 모기관(Anthropic·Google·IBM 계열) 출신이었고, 사양 회의는 분리돼 있었으며, 기업 조달부는 “어느 진영에 베팅하는가”라는 리스크 라인을 그어야 했습니다. 2026 Q1을 지나면서 이 질문 자체가 무의미해졌습니다. Zylos.ai의 2026-05-06 정렬 리포트는 세 프로토콜이 Linux Foundation 산하 joint working groups + cross-protocol interoperability commitments로 묶였다는 사실을 명시했고 (출처), Linux Foundation 자체 발표가 A2A v1.0의 AAIF 합류 (출처) 와 x402 결제 재단 분리 (출처) 를 같은 거버넌스 우산 안에 정렬했습니다.
그러므로 본 편이 제안하는 프레임은 “경쟁 3진영”이 아니라 “2-layer + 1-lateral 스택 + 단일 거버넌스 단체 정렬” 입니다. PM 결재 라인 관점에서 셋은 다른 차원에서 작동하며 경쟁하지 않습니다.
1.1 2-Layer + 1-Lateral 프레임 (신규)
이 표가 함의하는 첫 번째 변화는 “진영 베팅”이 사라진다는 것입니다. 조달부가 그어야 하는 라인은 더 이상 “MCP를 채택하면 A2A·ACP는 포기” 식이 아닙니다. 세 프로토콜은 한 단체 안에서 cross-protocol interop을 약속한 상태이고, 사내 아키텍처는 세 축 모두를 디폴트로 가정한 채 — 어느 레이어를 먼저 채택할지, 어느 레이어의 게이트를 우선 설계할지 — 순서만 결정하면 됩니다.
두 번째 변화는 차별화의 무게가 “프로토콜 선택”에서 “Layer별 거버넌스 게이트”로 이동한다는 것입니다. Vertical(MCP) 게이트는 사내 데이터·툴 접근 권한과 audit log를, Horizontal(A2A) 게이트는 에이전트 간 신뢰·서명·과금을, Lateral(ACP) 게이트는 비동기 메시징의 expiry·retry·dead-letter 정책을 다룹니다. 세 게이트의 소유 부서는 다르고, 게이트 통과 기준도 다르며, 감사 증빙 양식도 다릅니다. PM의 일은 “어느 진영”이 아니라 “세 게이트의 결재 라인을 그리는 것” 입니다.
세 번째 변화는 PMBOK 8판 “Lead Accountably + Tailor Based on Context” 원칙이 비로소 구체적인 산출물에 매핑된다는 것입니다 (PMBOK 8판 근거). Vertical·Horizontal·Lateral 세 축이 같은 거버넌스 단체 안에서 표준화되었기 때문에, 기획 문서에 “Layer별 소유 부서 + 채택 표준 + 게이트 통과 기준 + 감사 증빙 양식” 4개 필드를 박아두면 그 자체가 Tailoring 산출물이 됩니다. 2025년에는 이 4개 필드를 채우면 “어느 벤더 SDK인가”가 매번 답을 바꿨지만, 2026 Q2부터는 표준 ID만 적으면 됩니다.
삼성전자 GAUSS 5,665 Q&A 데이터셋을 Fine-tuning한 PM Agent, SKT AgentSkill 결과물, 현대MOBIS SDV 파이프라인 — 세 현장을 가로지르며 반복 확인한 현상이 하나 있습니다. 2024년까지는 “이 도구 쓸까 말까”가 의제였습니다. 2026년 2분기부터는 “어떤 레이어에 어떤 게이트를 둘까“가 의제입니다. 단어가 바뀐 것이 아니라 질문의 소유자가 바뀐 것입니다. 도구 선택은 엔지니어링의 몫이지만, 레이어별 게이트는 PM의 결재 라인 문제입니다. 이어지는 1.2~1.5에서는 이 변곡점을 14일짜리 사건과 거버넌스 정렬 신호로 풀어냅니다. 읽으시는 동안, 독자 조직의 에이전트 운영 볼륨이 “Uber의 월 1,500건”에 얼마나 근접하는지 — 또는 얼마나 멀리 있는지 — 감지해 보시길 권합니다.
1.2 2026-04 시점 핵심 수치
제가 PM 코칭 현장에서 “MCP가 뭔가요, 아직 쓸 만한가요”라는 질문을 받을 때 먼저 보여드리는 표입니다. 수치 자체보다 변화의 속도를 읽으셔야 합니다.
네 가지 변곡점이 같은 14일 안에 겹쳤습니다. 첫째, MCP Dev Summit에서 Anthropic·AWS·Microsoft·OpenAI 메인테이너들이 공동으로 “MCP는 AI 앱과 데이터 소스 연결에만 집중한다”는 스코프 규율을 선언했습니다 (출처). 둘째, A2A v1.0이 3대 클라우드에 네이티브 통합되었습니다 — AWS Bedrock AgentCore Runtime, Microsoft Azure AI Foundry + Copilot Studio, Google Cloud 전반에 걸친 “deep integration”입니다 (출처). 셋째, MCP 메인테이너 팀이 멀티 벤더 거버넌스로 질적 전환되었습니다 — AWS Senior Principal Engineer Clare Liguori가 Core Maintainer, Anthropic Den Delimarsky가 Lead Maintainer로 승격되어 Anthropic 단독 거버넌스를 벗어났습니다 (출처). 넷째, x402 Foundation 발족으로 에이전트 결제가 별도 재단으로 이관되었습니다 — Coinbase·Google·Microsoft·Visa·Mastercard·AWS 등 20+ 파트너 참여 (출처).
1.3 “엔터프라이즈 인프라 진입”이 실제로 의미하는 것
AAIF 공식 블로그는 2026 Summit의 메시지를 한 줄로 요약했습니다 — “MCP is now enterprise infrastructure” (출처). Uber가 5,000+ 내부 엔지니어·10,000+ 내부 서비스를 중앙 MCP Gateway + Registry 제어 평면으로 노출한 아키텍처를 공개했고 (출처), Nordstrom·Bloomberg·Duolingo·PwC가 프로덕션 사례로 공개되었습니다 (출처). agent gateway·orchestration pattern·skill management framework가 프로덕션 공통 패턴으로 수렴하고 있습니다.
이 변화의 의미를 PM 관점으로 풀어드리면 두 겹입니다. 첫 번째 겹은 벤더 lock-in 완화입니다. MCP 메인테이너 팀의 멀티 벤더화(Anthropic·AWS·Microsoft·OpenAI) 는 “특정 벤더가 내일 로드맵을 뒤집을 수 있는가”라는 리스크를 낮춥니다. 두 번째 겹은 이벤트·교육 공급선 확보입니다. AAIF는 2026 AGNTCon + MCPCon을 유럽(9월 암스테르담)·북미(10월 산호세)·아시아·인도·아프리카 순회로 공식화해 (출처) 조직 내부 역량 플랜에 매핑할 교육 트랙이 생겼습니다. 조달 가능성·표준화 신호는 다음 1.4 “Linux Foundation 정렬” 절에서 독립적으로 다룹니다.
반면 Deloitte가 State of AI 2026 에서 짚은 “거버넌스 성숙 21%” (출처) 와 MIT NANDA 연구의 “엔터프라이즈 AI 파일럿 95%가 측정 가능한 P&L 임팩트 제로” (출처) 는 같은 흐름의 그림자입니다. 프로토콜이 엔터프라이즈 인프라로 진입한 순간, 차별화의 무게가 프로토콜에서 거버넌스로 이동합니다. 우리 질문은 “MCP 할까 말까”가 아니라, “세 레이어 위에 어떤 거버넌스 게이트를 얹을까” 로 이동해야 합니다.
1.4 Linux Foundation 정렬 — 거버넌스의 무게중심 이동 (신규)
2026 Q1 정렬 확인 + 2026-05-06 update가 PM 결재 라인에 시사하는 바를 별도 절로 다룹니다. 핵심은 세 문장입니다.
(1) 단일 단체 정렬: MCP·A2A·ACP 세 프로토콜은 Linux Foundation 산하 joint working groups로 묶였고, cross-protocol interoperability commitments를 공식 약속한 상태입니다 (출처). AAIF가 MCP·AGENTS.md·goose를 우산 아래 묶었고 (출처), A2A v1.0이 같은 단체에 합류했으며 (출처), x402 Foundation이 결제 레이어를 별도 분리해 받았습니다 (출처).
(2) PM 관점 1 — “어느 진영에 베팅” 부담 해소: 엔터프라이즈 조달부는 더 이상 “MCP 진영을 고르면 A2A·ACP는 어떻게 되는가”라는 리스크 라인을 그릴 필요가 없습니다. cross-protocol interop이 사양 차원에서 약속되었기 때문에, 2-layer + 1-lateral 스택을 디폴트로 가정한 채 RFP/RFI를 작성할 수 있습니다. 9편 2026-05 월간 시그널 워치 의 Signal 6 (09편 cross-link) 이 같은 정렬을 한 달 단위로 재확인합니다.
(3) PM 관점 2 — 거버넌스의 무게중심이 “프로토콜 채택”에서 “단체 운영 신호 추적”으로 이동: 2025년까지 PM이 모니터링해야 했던 신호는 “어느 벤더가 어떤 SDK를 내놓았는가”였습니다. 2026 Q2부터는 Linux Foundation TAC 결정 · AAIF Working Group SEP merge · cross-protocol interop test suite 릴리스가 추적 대상이 됩니다. 이는 PM 하네스 안에 LF/AAIF 단체 신호 RSS 한 줄을 추가해 plan 검토 시 자동 표기하도록 만드는 것이 합리적이라는 뜻입니다 — 9편에서 월간 시그널 워치 양식을 별도로 제안합니다.
1.5 A2A v1.0 GA가 사양 안에 넣은 것 (신규)
2026 Q1 A2A v1.0 GA가 사양 안에 공식으로 편입한 세 항목은 PM이 “사내 에이전트 등록부 양식”을 표준화할 토대를 만듭니다 (A2A vs MCP 공식 토픽 · Google Developers Guide to AI Agent Protocols).
PM 관점의 의미는 명확합니다 — **사내 에이전트 등록부(Agent Registry)가 4편 멀티에이전트 아키텍처 의 출발점이 됩니다. 2025년까지 등록부는 팀마다 자체 스프레드시트로 운영되었고, 서명·테넌트·트랜스포트는 각자 다른 방식으로 표기됐습니다. v1.0 GA 이후에는 위 세 필드를 사양 표준에 맞춰 통일할 수 있고, 그 결과 등록부가 조달·감사·과금 모두에서 단일 SoR(System of Record)** 로 작동합니다. 4편 멀티에이전트 시스템 2026 에서 등록부 템플릿·서명 발급 워크플로를 별도로 다룹니다.
1.6 Private MCP Sandbox — Claude Opus 4.7 Managed Agents가 만든 보안 모델 (신규)
2026-04-16 Claude Opus 4.7 GA가 Managed Agents 안에 도입한 Private MCP Sandbox 기능은 사내 MCP 서버를 둘러싼 보안 검토 부담을 구조적으로 낮춥니다 (Anthropic 공식 발표 · Claude 4.7 What’s New).
기존 모델은 다음과 같습니다 — 사내 MCP 서버를 외부 모델 API에 연결하려면 (a) MCP 서버를 별도 공개 엔드포인트로 노출하거나 (b) 외부 모델에 사내 VPC 진입 권한을 부여해야 했습니다. 두 경로 모두 정보보안 부서 검토가 4~12주 소요됐고, 일부 산업(금융·의료·국방)에서는 사실상 차단됐습니다.
Private MCP Sandbox 모델은 이 구조를 뒤집습니다 — 사내 MCP 서버를 Managed Agents 샌드박스 안에 묶어 외부 공개 없이 사용할 수 있습니다. 보안 경계는 Anthropic 인프라가 아니라 사내 샌드박스 안으로 들어오고, audit trail은 샌드박스 단위로 떨어집니다. PM·정보보안 협업 양식은 다음 4단계로 바뀝니다.
- PM (Product): 위임할 사내 도구·데이터 소스 3개를 1차 후보로 선언
- 정보보안 (Security): 샌드박스 단위 audit log 형식 + DPoP/Workload Identity 적용 여부 게이팅
- Platform Engineering: MCP 서버를 샌드박스 안에 묶고 SSO·gateway 연동
- PL (Project Lead): pass@k·escalation rate·샌드박스 격리 위반 0건을 품질 게이트로 측정
이 모델이 만드는 PM 결재 라인의 변화는 “외부 모델 API 연결 vs 사내 자체 호스팅” 양자택일을 줄인다는 것입니다. 2025년까지는 보안 부서가 “외부 API 연결은 불가, 자체 호스팅만 허용”이라는 답을 자주 내렸고, 그 결과 사내 PM 조직은 외부 모델의 빠른 개선 속도에서 이탈했습니다. Private MCP Sandbox는 “외부 모델 + 사내 데이터 + 사내 감사” 라는 제3의 경로를 사양 안에서 정당화합니다. 정보보안 검토 부담의 감소량을 정량적으로 단정하기는 이르지만, 2026 Q3까지 산업별 사례가 누적되면 9편 월간 시그널 워치 가 후속 신호를 추적합니다.
💬 Voice Box #1 — PM 코치의 해석 2025년까지의 질문은 “어느 진영에 베팅할까”였습니다. 2026 Q2의 질문은 “2-layer + 1-lateral 스택의 세 게이트를 누가 소유하고, 단체 정렬 신호를 어떻게 주기 추적할까“입니다. A2A v1.0 GA가 signed Agent Cards·multi-tenancy를 사양 안에 넣었다는 것은 사내 에이전트 등록부가 표준화될 토대가 생겼다는 뜻이고, Claude Opus 4.7 Private MCP Sandbox는 “외부 모델 + 사내 데이터 + 사내 감사”라는 제3의 보안 경로를 정당화했습니다. PM이 이 세 신호를 plan 산출물 상단에 박아두지 못하면, 내년에 받게 될 질문은 “왜 우리는 아직도 진영 베팅 RFP를 쓰고 있지?”입니다.
개념 심층: MCP·A2A·4-레이어 스택을 PM의 언어로
Part 1과의 관계: Part 1의 “2-layer(vertical/horizontal) + 1-lateral” 프레임은 PM 결재 라인용 압축본입니다. Part 2의 “4-레이어 (Identity/Context/Coordination/Payment)”는 그것을 아키텍처 상세본으로 풀어 쓴 것입니다. MCP=Layer 2(Context/Tool, vertical), A2A=Layer 3(Coordination, horizontal), ACP=Layer 3의 lateral 보조 채널, NANDA=Layer 1(Identity), x402/AP2=Layer 4(Payment) — 두 프레임은 동일한 스택을 다른 해상도로 부르는 명칭입니다.
제가 aipm 운영 레포에서 매일 돌리는 파이썬 스크립트 하나가 있습니다. scripts/prompt-router.py입니다. 이 스크립트는 사용자의 자연어 메시지 한 줄을 받아 RoutingContext에 담은 뒤 route_message_v2로 분기시키고, 선택된 프롬프트 팩 ID와 카테고리를 구조화해 돌려줍니다. 라우팅 결과는 별도 파일에 telemetry로 누적되어, 어떤 요청이 어떤 조합으로 분류되었는지를 해시와 타임스탬프로 남깁니다. 이 100행짜리 스크립트가 보여주는 원리는 MCP·A2A의 4-레이어 스택이 말하는 것과 구조적으로 동일합니다. 자연어는 Intent 레이어에서 분류되고, tool 호출은 Context 레이어로 분리되며, 에이전트 간 위임은 Coordination 레이어의 책임이고, telemetry는 Observability로 빠집니다. 엔터프라이즈의 차이는 규모뿐입니다. Part 2에서 네 개의 레이어를 PM의 조달·감사·운영 언어로 해석하는 순간, 독자 조직의 prompt-router가 어디서부터 어떻게 성장해야 하는지가 구체적으로 보입니다. “이 기술을 쓸까”가 아니라 “이 레이어의 소유권을 누가 가지는가”가 질문이어야 합니다.
2.1 MCP와 A2A의 역할 분담
2026-04-08 공개된 메인테이너 확장 (출처) 과 함께 공표된 스코프 규율은 PM에게 중요한 신호입니다. MCP는 tool connectivity, A2A는 agent coordination, OpenTelemetry는 observability, x402·AP2는 payment, NANDA는 identity로 역할을 쪼갰습니다. Kubernetes가 초기에 스토리지·관측성·네트워킹을 분리해 장수한 전략(“Kubernetes’ durability strategy”)을 의도적으로 벤치마킹한 것으로 평가됩니다 (출처).
PM 실무자의 시선에서 이 분리는 기획 산출물을 다시 짜는 근거가 됩니다. 과거에는 “에이전트 기능 한 장짜리 소개서”에 tool·coordination·observability·payment를 한 덩어리로 묶어 설명했고, 결과적으로 각 레이어의 오너십이 모호해져 운영 단계에서 책임 공백이 발생했습니다. 2026 Q2부터는 기획 문서에 “Layer별 소유 부서 + Layer별 채택 표준 + Layer별 감사 증빙” 세 필드를 명시적으로 두는 편이 합리적입니다. 예를 들어 Layer 2(MCP)는 Platform Engineering이 소유·Uber식 Gateway 표준 채택·audit log를 SIEM으로 연결, Layer 3(A2A)는 Product 조직이 소유·v1.0 Agent Card 서명 강제·운영 대시보드 연결, Layer 4(x402/AP2)는 Finance·Compliance가 소유·사전 승인 한도 게이트·분기 감사 보고 — 이 식으로 나누면 Deloitte가 지적한 거버넌스 공백이 plan 단계에서 메워집니다. Anthropic Claude Code가 progressive discovery로 토큰 85%를 절감했다는 숫자 (출처) 는 기술 튜닝이 아니라 레이어 분리 후 실험이 비로소 가능해진 결과라고 보는 편이 정확합니다.
2.2 4-레이어 스택 비교 (2열 카드)
2.3 MCP 2026 로드맵 4대 축
2026-03-09 공개된 MCP 공식 로드맵은 네 가지 축으로 정리됩니다 (출처).
- Transport Scalability — stateful session을 stateless 요청 모델로 이행,
.well-known서버 메타데이터 표준 (SEP-1442) - Agent Communication — Tasks primitive (SEP-1686)
call-now, fetch-later패턴, Triggers Working Group 신설 (서버→클라이언트 능동 알림) - Governance Maturation — Working Group에 도메인별 SEP 권한 위임, Contributor ladder 공식화
- Enterprise Readiness — audit trail, SSO-integrated auth, gateway behavior, configuration portability / 보안 SEP: SEP-1932 (DPoP), SEP-1933 (Workload Identity Federation)
ℹ️ 핵심 인사이트 2026 Q2 기준 “MCP 채택”은 더 이상 차별화가 아닙니다. 4-레이어 스택 중 어느 레이어에 어떤 재단·표준을 채택했는지가 조달·감사·보안 팀의 질문이 됩니다. PM이 “standard-first procurement” 원칙을 수립해야 하는 이유입니다.
2.4 Mermaid #1 — 2026 4-레이어 프로토콜 아키텍처
- PMBOK 8: Governance Domain · Lead Accountably · Tailor Based on Context
- SAFe 6: Portfolio Level: Solution Architect · Program Level: Architectural Runway
- BABOK v3: 6.1 Elicitation & Collaboration · Interface Analysis
- SEBOK v2.x: Part 3 System Deployment · Interface Management
(전체 32-cell 매핑은 시리즈 진입 가이드의 부록 D에서 확인)
비교·한계·경고: "프로토콜 성숙 vs 조직 미성숙" 비대칭
지난 12개월 삼성전자 GAUSS PM Agent Fine-tuning(5,665 Q&A 데이터셋)·SKT Agent/Skill(83건 PMO 산출물)·SKAX PM 2-Day 워크숍 설계를 진행하면서 반복 확인한 패턴이 있습니다. 세 현장 모두에서 첫 질문은 동일했습니다. “우리 조직은 Gateway가 있는가, 아니면 팀별 MCP 서버가 난립하는가?” 그리고 대부분의 대답도 동일했습니다. 후자입니다. 심지어 “어떤 팀은 자체 gateway를 쓰고, 어떤 팀은 SSO 연동이 안 된다”는 실토가 이어집니다. Gartner의 “40% 취소” 통계는 이런 조직들의 합계입니다. 제가 현장에서 강조하는 해석은 이렇습니다. 프로토콜이 성숙할수록 차별화는 기술에서 게이트로 이동합니다. 프로토콜 채택은 2주 결정 사안이고, 게이트 설계는 6~12개월 조직 변환입니다. Part 3은 이 비대칭을 두 가지 채택 경로(Gateway-First vs Ad-hoc), 6가지 실패 유형, 14일 리스크 델타로 해부합니다. 읽으시면서 독자 조직이 어느 경로에 가까운지 — 그리고 그 경로가 Deloitte “성숙 21%”로 향하는지 Gartner “40% 취소”로 향하는지 — 판정해 보시길 권합니다.
3.1 두 가지 채택 시나리오 (2열 카드)
3.2 실패 유형 테이블
3.3 리스크 맵 14일 델타 (2026-04-02 → 2026-04-16)
💬 Voice Box #2 — PM 코칭 현장에서 본 흔한 함정 저는 지난 3개월 동안 PM 조직 다섯 곳에서 같은 실수를 봤습니다. “우리 팀이 MCP 서버 3개를 만들었다”는 자랑으로 시작해서 “각 팀이 자체 gateway를 쓴다”는 실토로 이어지고, “SSO가 연동이 안 된다”는 긴급 티켓으로 끝납니다. 이 흐름의 정체는 게이트 없이 tool만 늘린 결과입니다. Gartner 40% 통계는 마법이 아니라, 이 실수를 반복한 조직들의 합계입니다. PM이 plan 단계에서 “escalation threshold + fallback owner” 2개 필드를 강제하지 않으면, 프로덕션 첫 주에 반드시 어긋납니다. 프로토콜이 성숙할수록 조직 게이트의 상대적 비중이 커집니다.
PO·PM·PL 3-Role Translation ⭐
- L3 수행(Performance) — 팀 단위 반복 운영 + Named Owner 지정 + 기본 가드레일. 진입 조건: 주 5회 이상 AI 협업 · SOP 1건.
- L4 주도(Leadership) — 조직 표준 내재화 + OKR 정렬 + 월간 대시보드. 진입 조건: 부서 간 공유 SOP · 12지표 대시보드 운영.
- L5 코칭·표준화(Coaching & Standardization) — 타 조직·업계 코칭 + 외부 표준 기여. 진입 조건: 외부 강연·컨설팅·표준 기고 3건/년+.
(L1~L2 및 L 전환 Trigger 상세는 부록 C “L1~L5 성숙도 표준 정의” 참조)
이 시리즈에서 제가 단계적 과제(Day 1 / Week 1 / Month 1) 대신 역량 래더(L3 → L4 → L5)만 축으로 쓰는 이유를 먼저 말씀드립니다. 삼성전자·LG전자·SKT·현대모비스·SK쉴더스 다섯 조직의 현장에서 확인한 것은, “Day 1에 뭘 할까”라는 질문의 답이 조직마다 너무 다르다는 것입니다. A라는 회사의 Day 1 행동이 B에서는 이미 완료된 일이고, C에서는 3개월 후에나 가능한 일입니다. 반면 L3(수행 경험) → L4(주도 산출) → L5(코칭·표준화) 이라는 역량 래더는 규모·산업·성숙도에 상관없이 같은 방향을 가리킵니다. 삼성 GAUSS 5,665 Q&A 데이터셋이 L3·L4·L5를 섞어 만들었고, LG전자 PM Competition에서 68명이 인증을 받은 축도 L4 수준 “주도 산출”의 증거였습니다. SKT 83건 PMO 산출물도 마찬가지였습니다. 이 시리즈 8편 모두 같은 L3→L4→L5 래더를 공통 축으로 쓰고, Post 8 캡스톤에서 24-cell 매트릭스(PO·PM·PL × 8주제 × L3·L4·L5)로 집약합니다. 독자 조직은 자기 현 위치를 L3·L4·L5 중 하나에 꽂고 시리즈 전체를 읽을 수 있게 됩니다. 구체적 진입 조건은 각 L 레벨에서 1줄로 제시하고, 실제 착수 동작은 Part 5 Pentagon에 축약해 담았습니다.
- 역량(Competency) — 이 시리즈의 공통 축: L3 수행 경험 → L4 주도 산출 → L5 코칭·표준화
- 맥락(Context) — 편별 변주 축: 각 편의 주제별로 L3·L4·L5의 “진입 조건” 1줄을 명시
- L1·L2는 전제로만 언급하고 별도 체크리스트를 두지 않습니다 — 대기업 PO·PM·PL은 대부분 이미 L2를 넘어선 상태이기 때문입니다.
4.1 PO의 관점 (시나리오·비전·성공 메트릭 결정자)
현황 진단
PO의 업무는 “어떤 고객 가치를 제품으로 만들 것인가”를 시나리오와 성공 메트릭으로 압축하는 일입니다. MCP/A2A가 등장하면서 PO가 결단해야 할 새 질문이 생겼습니다 — “어떤 고객 가치를 어떤 에이전트에 위임할 것인가.” A2A 1주년 발표에서 공급망·금융·보험·IT 운영 4개 산업이 프로덕션으로 호명되었다는 사실 (출처) 은, PO 시나리오에 “에이전트-투-에이전트 핸드오프 지점”을 명시적으로 정의해야 한다는 신호입니다. 제품 비전 문장도 “사람이 이 가치를 경험한다”에서 “사람과 에이전트가 이 가치를 협업으로 경험한다”로 재서술이 필요합니다.
L3 → L4 → L5 역량 래더
4.2 PM의 관점 (위임·거버넌스·검증 루프 설계자)
현황 진단
PM의 업무는 PMBOK 8판 (출처) 기준으로 Estimate Activity Resources에서 AI를 공식 tool/technique으로 다루게 되었고, Stakeholder·Uncertainty 퍼포먼스 도메인이 “human-in/on/out-of-the-loop 자율성 스펙트럼”을 Risk Register와 RACI에 매핑하라고 요구합니다 (출처). MCP·A2A 도입은 이것을 2-layer delegation map으로 구조화할 기회입니다 — MCP는 tool 레이어 위임, A2A는 agent 레이어 위임. Uber가 월 1,500 agents·주 60,000 execution을 중앙 Gateway로 감사하는 이유가 여기입니다 (출처). 제가 PM 코칭에서 강조하는 문장은 “위임은 할당이 아니라 계약이다” 입니다.
L3 → L4 → L5 역량 래더
4.3 PL의 관점 (품질 게이트·실험 시스템 결정자)
PL은 본 시리즈에서 Project Lead를 가리킵니다 — 기술 스쿼드의 Team Lead가 아니라, 품질 게이트와 실험 시스템을 결정하는 역할로 정의합니다 (LG WebEx 세미나 정의 기반:
lecture/lge-webex-seminar-ai-agent-pm/02-slide-fulltext.md:277-283).
현황 진단
PL의 업무는 “우리 에이전트가 내일도 동일한 품질을 보장할 수 있는가”를 실험·측정·게이팅으로 보장하는 일입니다. 2026-04 시점 품질 게이트의 재료는 세 가지입니다 — ① A2A Agent Card 서명 검증(멀티테넌시·OAuth 2.0 현대화 기반) (출처), ② MCP Tasks SEP-1686의 expiry/retry 정책 (call-now, fetch-later 패턴) (출처), ③ gRPC 트랜스포트 전환 준비(Summit에서 공식 의제화) (출처). Claude Code가 progressive tool discovery로 토큰 85%를 절감했다는 사례 (출처) 는 PL이 실험 설계로 원가 구조를 바꿀 수 있다는 구체적 증거입니다.
L3 → L4 → L5 역량 래더
4.4 3-role 통합 테이블 (9-cell, 역량 단일 축)
4.5 Mermaid #2 — 3-role 핸드오프 (시리즈 고정 스켈레톤)
💬 Voice Box #3 — “이것을 PO·PM·PL의 언어로 해석하면” 저는 프로토콜 로드맵을 읽을 때 항상 3번 해석합니다. 첫 번째 해석은 PO의 언어로 — “A2A 150+ 기업”은 “고객 가치 위임의 공급자 수”입니다. 두 번째 해석은 PM의 언어로 — “MCP Tasks SEP-1686″은 “call-now·fetch-later 위임 계약서”입니다. 세 번째 해석은 PL의 언어로 — “SEP-1932 DPoP + SEP-1933 WIF”는 “품질 게이트의 서명·신원 pass/fail 기준”입니다. 세 해석이 같은 방으로 모이지 않으면, 조직은 Deloitte 21% 밖에 남습니다. 제 PM 하네스에서 이 세 해석을 plan 템플릿 상단 3줄에 강제로 박아두는 이유입니다 — 실제로 aipm 레포의
.claude/settings.jsonPostToolUse hook이 plan 파일 생성 시점에 이 3줄 존재를 자동 검사합니다.
실전: Quick Start Pentagon (역량 진입 조건으로 읽기)
Part 4에서 L3·L4·L5 래더를 단일 축으로 세웠습니다. Pentagon은 그 래더에 진입하기 위한 최소 착수 동작을 Day 1·Week 1·Month 1 축으로 배치한 실행표입니다. 즉 “Day 1에 뭘 하라”가 아니라, “L3에 진입하려면 Day 1에 이것은 되어 있어야 한다“로 읽어주십시오. 삼성 GAUSS·LG 인증·SKT PMO 세 현장을 종합해 만든 최소 공통 분모입니다. 각 셀의 동사는 PO는 정의/정렬/압축/선언, PM은 위임/검증/조율/게이팅/매핑, PL은 설계/실험/측정/자동화/게이팅으로 역할별 허용 동사만 사용합니다. 독자 조직의 현 위치를 L3~L5 중에서 먼저 고르시고, 해당 L을 지금 이번 분기 안에 통과시키기 위해 필요한 Pentagon 셀만 골라서 실행하시면 됩니다. 10개 셀 전부를 동시에 밀어붙이지 않는 것이 2026년 현장에서 가장 중요한 실무 원칙입니다.
5.1 자산 D — Quick Start Pentagon
5.2 하지 말 것 (Callout Red)
⚠️ 이 주제에서 하지 말 것
- Gateway 없이 팀별 MCP 서버 난립 — Uber 5,000 엔지니어 사례가 보여주듯, 중앙 Gateway + Registry 없이 시작하면 SSO·audit 소급 리팩토링이 6개월 이상 소요됩니다.
- “MCP 채택”을 성과 지표로 발표 — 2026 Q2 시점에는 차별화가 아닙니다. “4-레이어 중 어느 레이어를 어느 표준으로 덮었는가” 로 보고해야 조달/감사 팀이 수용합니다.
- Agent Card 서명 없이 A2A 배포 — 멀티테넌시·OAuth 2.0 현대화의 근간을 무시하면 EU AI Act audit trail 요구에서 막힙니다. SEP-1932(DPoP)/SEP-1933(WIF)을 초기부터 채택하시기 바랍니다.
마무리
2026년 4월의 14일 동안, 에이전트 프로토콜은 “실험”에서 “엔터프라이즈 인프라”로 공식 넘어갔습니다. 하지만 같은 14일 동안 Deloitte는 거버넌스 성숙 기업이 여전히 21%라고 확인했고, Gartner는 40% 프로젝트 취소 경고를 유지했습니다. 이 비대칭을 메우는 것이 PM 코치가 보는 2026 Q2의 진짜 과제이며, PO·PM·PL 세 역할이 L3·L4·L5 중 어느 래더에 서 있는가가 Quick Win과 ROI 실패를 가릅니다. 제가 이번 편에서 가장 강조하고 싶은 한 문장은 — “프로토콜이 표준이 되는 순간, 차별화는 게이트로 이동한다.” 입니다. 프로토콜 선택은 이제 조달 결정이고, 차별화는 우리 조직이 설계한 delegation map + gov gate + 품질 게이트 v1.0에 있습니다. 다음 편부터는 이 3-role 해석을 “Agentic PM 운영 모델”, “Vibe Coding 가드레일”, “멀티에이전트 아키텍처”로 순차 확장합니다.
💬 Voice Box #4 — 8주 시리즈 내 이 편의 자리매김 이 1편은 시리즈의 지반입니다. 프로토콜 레이어를 언어로 갖추지 않으면, 2편의 PMBOK·Agentic PM, 3편의 Vibe Coding, 4편의 멀티에이전트 토폴로지 모두가 추상적인 비유로만 남습니다. 반대로 이 1편을 조직의 공용 해석기로 쓰시면, 나머지 7편의 의사결정 비용이 한 자릿수 낮아집니다. 기존 34편 시리즈와의 관계도 여기서 고정됩니다 — B-3의 역량 변화 논의는 L3·L4·L5 래더라는 구체적 축을 얻고, G-2 하네스 가이드는 4-레이어 프로토콜 위에 얹는 위임 계약으로 갱신되며, G-3 Tool 가이드는 조달 결정 체크리스트로 재정렬됩니다. 다음 8주 동안 같이 해석을 반복하시겠습니다.
이 시리즈 지도
이전: 없음 — 8편 마감편의 첫 문 (시리즈 누적 35번째) 현재: MCP와 A2A가 바꾸는 Agentic PM 시대 — PM 코치가 해석하는 PO·PM·PL의 준비 다음: Post 2 에이전틱 프로젝트 관리 (2026-04-27) · Post 3 Vibe Coding & 에이전틱 엔지니어링 (2026-05-04) · Post 4 멀티에이전트 시스템 2026 (2026-05-11)
Related Posts (기존 34편 중 보완 각도) {#related-posts}
- 시리즈 09편 — 2026-05 월간 시그널 워치 (예정) — 본 편의 “2-layer + 1-lateral · 단일 거버넌스 정렬” 프레임을 한 달 단위 신호(Signal 6 Linux Foundation 정렬 + Signal 7 A2A v1.0 GA + Signal 1 Claude Opus 4.7)로 재점검
- 시리즈 04편 — 멀티에이전트 시스템 2026 (예정) — 본 편 1.5의 “signed Agent Cards · multi-tenancy”가 사내 에이전트 등록부 양식으로 구체화되는 후속 편
- B-3 AI 시대, PM/PL의 역량이 근본부터 바뀌어야 하는 이유 — 본 편의 L3→L5 래더가 서 있는 역량 변화 논의의 원전
- G-2 주니어 PM을 위한 AI 하네스 구축 가이드 — 개인 수준 하네스 조립 가이드, 본 편의 2-layer + 1-lateral 스택은 그 위에 얹는 조직 결재 라인
- G-3 대기업 직장인을 위한 AI Agent & Skill 추천 가이드 2026 — 도구 랜드스케이프, 본 편의 Layer별 조달 결정에 직접 연결
- A-1 AI 코딩 에이전트 시대, 거버넌스 없이 괜찮을까? — 본 편 Part 3의 “프로토콜 성숙 vs 조직 미성숙” 비대칭의 실전 실험 버전
- S-3 SKT Agent/Skill 회고 — 본 편 Part 3에서 인용한 SKT PMO 83건 산출물의 원본 현장
Tags: Agentic PM 2026 Q2, PO-PM-PL 3-role, AX Delivery OS, MCP, A2A
- P-0 7인의 사고 체계 종합 프레임워크
- P-1 Karpathy: 제약 설계 + 닫힌 루프
- P-2 Sutskever: 압축이 곧 지능이다
- P-3 Hassabis: 제1원리 분해
- P-4 LeCun: 세계 모델 + 예측
- P-5 Hinton: 거버넌스 + 자기부정
- P-6 Ng: AI 전환 플레이북
- P-7 Fei-Fei Li: 인간중심 설계
- P-8 Builders 종합: Boris·Cat·Truell·Masad·Murati·Brockman
- P-9 Operators 종합: Altman·Amodei·Nadella·Pichai·Zuckerberg·Suleyman
- P-10 Hardware 양강: Jensen Huang · Lisa Su
- P-11 PO·PM·PL 역량 통합: 5-Domain × 3-Level