Agentic AI Foundation 출범으로 MCP·goose·AGENTS.md가 에이전트 오픈 표준 축을 형성했다. 동시에 Concentrix·IBM·Oracle·Rubrik·Veza가 프리빌트·보안 특화 에이전트를 전면에 내세우며 마켓플레이스 경쟁이 시작됐다. 이 글은 오픈 재단 vs 벤더 생태계 구도 속에서 agentic AI 도입 전략, 보안·거버넌스, 역량 맵을 압축 정리한다.
2025년 12월 9일, 리눅스 재단이 Agentic AI Foundation 출범을 공식 선언했습니다. 에이전트형 AI 전용 오픈 표준 재단이 생긴 첫 사건입니다.
불과 몇 주 사이 Concentrix, IBM, Oracle, Rubrik, Veza, EPAM은 컨택센터·ERP·CRM·보안 워크플로를 통째로 자동화하는 프리빌트 에이전트를 쏟아냈습니다. 2024년까진 사내용 챗봇·프롬프트 실험이 중심이었지만, 2025년부터는 “어떤 에이전트 스택과 마켓플레이스를 고르느냐”가 승부처가 됐습니다.
이 글은 Agentic AI Foundation과 MCP·goose·Shinkai·AGENTS.md로 대표되는 오픈 스택 흐름, 주요 벤더의 프리빌트·보안 특화 에이전트 전략, 그리고 2026년을 겨냥한 개발자·IT 리더의 도입·거버넌스·역량 로드맵을 정리합니다.
에이전틱 AI와 Agentic AI Foundation: 2025년 등장한 새 축
agentic AI란? 기존 LLM·챗봇을 넘어선 4가지 차이
- 자율성: agentic AI란 사용자의 한 번 요청 이후에도 스스로 계획을 세우고 여러 단계를 실행하는 에이전트 기반 AI 시스템을 뜻합니다. 전통 LLM·챗봇은 한 번의 질문에 한 번의 답변만 주는 단발형이었습니다.
- 목표 지향: 에이전틱 AI는 목표를 입력하면 하위 작업으로 쪼개고 순서를 정해 실행합니다. “30일 내 미수금 10% 줄이기”처럼 결과 지표를 향해 여러 워크플로를 조합합니다.
- 툴·시스템 호출: 텍스트 대화에 머무르지 않고 데이터베이스, ERP, CRM, 이메일, 티켓 시스템 등 실제 시스템을 API·툴 호출로 제어합니다.
- 피드백·협업: 오류·예외가 발생하면 로그·결과를 점검하고 경로를 수정하며, 필요 시 사람에게 승인을 요청합니다. 여러 전문 에이전트가 역할을 나누는 멀티에이전트 협업 구조가 복잡한 업무 자동화를 가능하게 합니다.
에이전트 기술 구조: 플래너·메모리·툴 호출 3블록
에이전틱 AI의 전형적인 아키텍처는 세 블록으로 요약됩니다. 목표를 해석해 단계로 쪼개는 플래너, 맥락을 기억하는 메모리, 실제 시스템을 조작하는 툴 호출 계층입니다.
플래너는 자연어 요청을 입력으로 받아 여러 하위 태스크와 순서를 생성합니다. 예를 들어 “미수금 줄이기 캠페인 실행” 요청을 받으면 고객 세분화, 우선순위 산정, 메시지 생성, 발송, 결과 분석 단계를 만듭니다.
메모리는 과거 대화·실행 결과·관련 비즈니스 데이터를 축적합니다. 단순 히스토리를 넘어 “이 고객은 지난달에도 연체했다” 같은 요약 정보를 워크플로에 곧바로 활용합니다.
툴 호출 계층은 ERP, CRM, 이메일 게이트웨이, 결제 시스템, 내부 REST API 등과 연결된 추상화 레이어입니다. 워크플로우 자동화 에이전트는 이 층을 통해 티켓 생성, 주문 변경, 인보이스 발행 같은 실제 행위를 수행합니다.
복잡한 도메인에서는 여러 에이전트가 이 구조를 공유하며 역할을 분담합니다. 이때 멀티에이전트 협업 구조가 등장하고, 오케스트레이터가 각 에이전트의 책임 범위와 호출 순서를 관리합니다.
Agentic AI Foundation의 목표: 오픈 표준과 레퍼런스 스택
Agentic AI Foundation은 LLM 모델이 아니라 에이전트 인프라·프로토콜·표준을 다루는 리눅스 재단 산하 오픈 재단입니다.
출범 시점 기준 핵심 앵커 프로젝트는 Anthropic의 MCP, Block의 goose, OpenAI의 AGENTS.md 세 가지입니다. 서로 다른 벤더의 에이전트가 동일한 프로토콜로 툴·데이터를 호출하게 해 특정 벤더 API에 묶이지 않도록 돕습니다.
또한 goose 같은 오픈소스 구현을 통해 “엔터프라이즈급 에이전트 스택은 이렇게 구성된다”는 실질적인 레퍼런스 구조를 제공합니다. 여기에 보안 가이드라인·인증 프로그램·규제 대응 모범 사례를 공개 거버넌스로 축적해, 기업이 에이전틱 AI를 인프라 레벨에서 도입할 수 있는 토대를 마련하고 있습니다.
오픈 표준 전선: goose·Shinkai·MCP·AGENTS.md 조합하기
goose: 로컬-퍼스트 개발자를 위한 온-머신 에이전트 스택
goose는 블록(Block)이 만든 오픈소스 온-머신 에이전트 스택입니다. 개발자 로컬 환경에 설치해 파일 읽기·쓰기, 테스트 실행, git 조작 같은 실제 작업을 자동화합니다. LLM은 로컬 실행(Ollama 등)과 클라우드 API 중 선택할 수 있지만 기본 철학은 “내 머신에서 돌아가는 에이전트”입니다.
이 구조는 데이터 프라이버시와 보안 측면에서 유리합니다. 코드베이스나 민감 로그가 클라우드로 나가지 않고 로컬에 남기 때문입니다. 사내 레포 전반의 반복 코드 정리, 리팩터링, 보일러플레이트 작성 등을 에이전트 기반 AI 시스템으로 처리하면서 소스 유출 위험을 줄일 수 있습니다.
예를 들어 개발자가 goose 에이전트에 “이 레포에서 deprecated API 사용을 최신 버전으로 교체하고 테스트까지 돌려줘”라고 지시합니다. 에이전트는 로컬 파일을 스캔하고 변경을 수행한 뒤 테스트를 실행해 실패 케이스를 리포팅하는 식으로 전체 플로우를 자동화합니다.
Shinkai와 분산 지식·MCP 생태계의 접점
Shinkai는 분산형 개인 지식·에이전트 네트워크를 지향하는 프로젝트입니다. 각 사용자가 자신의 노드와 스토리지를 소유하고, 그 위에서 여러 에이전트가 지식을 공유하고 작업을 수행하는 구조를 취합니다.
Agentic AI Foundation과 공식 제휴가 발표된 것은 아니지만, 로컬 또는 셀프호스팅 인프라를 중시하고 사용자가 통제하는 환경에서 에이전트를 운영한다는 점에서 방향은 유사합니다.
MCP와 결합하면 그림이 선명해집니다. Shinkai 노드가 다양한 데이터 소스를 MCP 서버 형태로 노출하고, 상위 에이전트 스택(goose 포함)이 이를 호출하는 구조를 상상할 수 있습니다. 이 경우 사용자의 지식 그래프와 도메인 문서를 외부로 넘기지 않고도 agentic AI를 분산 환경에서 구현하는 토대가 됩니다.
MCP·AGENTS.md vs goose·Shinkai: 표준과 런타임의 역할 분담
| 표준/스택 | 주 역할 | 계층 | 로컬-퍼스트 친화도 | 대표 활용 예 |
|---|---|---|---|---|
| MCP(Model Context Protocol) | 모델이 툴·데이터소스를 호출하는 프로토콜 | 런타임 통신 | 로컬·클라우드 중립 | Claude·Copilot·ChatGPT가 동일 MCP 서버 호출 |
| AGENTS.md | 에이전트 행동 지침을 담는 마크다운 문서 | 메타데이터·정책 | 실행 위치와 무관 | 레포별 빌드·테스트 규칙을 코딩 에이전트가 읽어 적용 |
| goose | 온-머신 에이전트 런타임·툴링 스택 | 실행·오케스트레이션 | 매우 높음 | 로컬 코드 리팩터링·CI 작업 자동화 |
| Shinkai | 분산 개인 지식·에이전트 네트워크 | 인프라·오케스트레이션 | 높음 | 사내·개인 지식그래프 위 자율 에이전트 운영 |
이처럼 goose·Shinkai는 실제 런타임·인프라에 가깝고 MCP·AGENTS.md는 상호운용성을 위한 표준입니다. 멀티에이전트 협업 구조를 구축하려는 조직은 네 요소를 조합해 자신만의 에이전트 스택을 설계하게 됩니다.
프리빌트 에이전트의 부상: 컨택센터·ERP·보안 현장의 변화
Concentrix Pre-Built Agentic AI: 컨택센터 자동화 4가지 시나리오
Concentrix의 Pre-Built Agentic AI는 컨택센터·고객 지원 업무를 겨냥한 워크플로우 자동화 에이전트입니다.
첫째, 문의·FAQ 셀프서비스입니다. 고객이 채팅·음성으로 질문하면 프리빌트 에이전트가 FAQ, 주문 정보, 정책 문서를 조회해 1차 응대를 처리합니다. 반복 문의가 많을수록 효과가 커집니다.
둘째, 주문·계정 조회와 변경입니다. “주문 상태 알려줘”, “배송지 바꿔줘” 같은 요청을 들으면 ERP·CRM에서 데이터를 조회하고 주소 변경·재발송 지시까지 자동 실행합니다.
셋째, 병원·매장·서비스 방문 예약 같은 일정 관리입니다. 캘린더·슬롯 관리 시스템과 연동해 예약 생성·변경·취소를 처리합니다.
넷째, 연체·콜렉션 업무입니다. 연체 고객을 세분화하고 메시지를 생성해 발송하며, 납부 약속 잡기·분할 결제 제안 시나리오를 자동 실행합니다. 단순 독촉을 넘어 비즈니스 프로세스에 Agentic AI 적용한 사례입니다.
IBM·Oracle AI Agent Marketplace: ERP·CRM 안으로 들어간 에이전트
Oracle은 2025년 10월 Fusion Applications AI Agent Marketplace를 공개했습니다. ERP, HCM, SCM, CX(포함 CRM) 안에 AI 에이전트를 설치·관리하는 전용 마켓플레이스입니다.
IBM은 이 마켓플레이스용 에이전트 3종을 발표했습니다. 대표적인 인터컴퍼니 에이전트는 복수 법인 간 거래·계약을 검토하고 규칙에 따라 차이를 분석한 뒤 조정 요청 워크플로를 자동으로 띄웁니다. 재무·영업·조달 에이전트는 청구·수금 현황 검토, 견적·기회 정보 업데이트, 구매요청·발주 승인 처리를 자동화합니다.
핵심은 ERP·CRM 화면을 벗어나지 않고 에이전트를 “앱처럼” 설치한다는 점입니다. 조직은 비즈니스 프로세스에 Agentic AI 적용을 시도하면서도 Oracle이 제공하는 공통 접근제어·감사·모니터링 프레임워크 안에서 리스크를 관리할 수 있습니다.
개발자 입장에선 IBM watsonx Orchestrate와 Oracle AI Agent Studio가 백엔드 오케스트레이션을 담당합니다. 직접 에이전트 인프라를 구축하지 않고도 프로세스 단계별로 설계된 에이전트를 끼워 넣는 방식입니다.
Rubrik·Veza·EPAM: 보안·규제 특화 도메인 에이전트
보안·규제 영역에선 도메인 특화 AI 에이전트가 빠르게 등장하고 있습니다.
Rubrik Agent Cloud는 컨택센터 봇, ERP·CRM 에이전트, 커스텀 LLM 봇이 어디에 있고 어떤 데이터에 접근하는지 자동 탐지합니다. 정책을 적용해 행동을 제한하고, 문제가 생기면 특정 시점 이후 변경만 되감는 Agent Rewind 기능으로 피해를 줄입니다.
Veza AI Agent Security는 에이전트 계정·API 키·롤을 통합 관리하며 어떤 에이전트가 어떤 민감 데이터에 접근 가능한지 그래프로 보여줍니다. 최소 권한 정책과 승인 워크플로를 자동화해 권한 남용과 프롬프트 인젝션 영향 범위를 줄입니다.
EPAM AI Agents는 금융 KYC, 규제 문서 작성, 연구 데이터 파이프라인 등 규제가 강한 도메인의 워크플로를 엔드투엔드로 자동화합니다. Google Cloud의 IAM·로깅을 활용해 규제 준수 요건을 지키면서 산업별 복잡한 프로세스를 에이전트화합니다.
프리빌트 vs 커스텀: 2026년을 향한 에이전트 선택 전략
프리빌트 에이전트, 언제 빠르고 언제 한계에 부딪히는가
| 구분 | 장점 | 한계 |
|---|---|---|
| 도입 속도 | 바로 설치해 써볼 수 있어 PoC와 초기 가치 검증이 빠름 | 워크플로 세부 단계까지 조직 특성에 맞추기 어렵습니다. |
| 비용 구조 | 초기 구축 비용이 낮고 구독·사용량 기반 과금으로 예산 예측이 용이함 | 장기적으로 라이선스·마켓플레이스 수수료가 누적될 수 있습니다. |
| 기술 부담 | 인프라·스케일링·모니터링을 벤더가 책임져 운영 부담이 적음 | 내부 팀의 에이전트 설계 역량이 늦게 쌓여 의존도가 커집니다. |
| 커스터마이징 | 설정·플러그인 수준에서 빠른 튜닝 가능 | 전통적 챗봇 vs 에이전트형 AI 비교 시 에이전트 잠재력을 온전히 활용하기 어렵습니다. |
| 벤더 이동성 | 같은 벤더 생태계 내 확장은 쉽고 통합 UX를 얻을 수 있음 | 다른 벤더로 옮길 때 워크플로와 데이터 모델 이식 난도가 큽니다. |
커스텀 에이전트·오픈 프레임워크 선택 시 체크리스트 6가지
커스텀 에이전트나 goose·Shinkai 같은 오픈 스택을 선택할 땐 몇 가지를 먼저 점검해야 합니다.
첫째, 도메인 복잡도와 표준화 수준입니다. 프로세스가 산업 표준에 가깝다면 프리빌트 우선, 조직 특수성이 강하면 커스텀이나 오픈 스택 비중을 키웁니다.
둘째, 내부 기술 역량입니다. LLM, 툴 호출, 관측성, 보안까지 포괄하는 Agentic AI 구축 방법을 소화할 엔지니어링 팀이 있는지 확인합니다.
셋째, 데이터 거버넌스 요구입니다. 규제가 강하거나 데이터 경계가 복잡하다면 로컬-퍼스트·셀프호스팅 옵션을 지원하는 프레임워크를 우선 고려합니다.
넷째, MCP·AGENTS.md 같은 표준 채택 전략입니다. 향후 멀티벤더 환경에서도 재사용 가능한 에이전트 아키텍처를 설계할 수 있는지 검토합니다.
다섯째, 운영·SRE 모델입니다. 에이전트 장애·드리프트·품질 저하를 어떻게 모니터링하고 롤백할지 SRE 수준에서 책임 소재를 명확히 해야 합니다.
여섯째, 비즈니스 오너십입니다. 어떤 부서가 에이전트 성과와 리스크를 책임지는지, 제품·프로세스 오너십 구조를 선명하게 나눠야 합니다.
‘프롬프트 짜는 시대’에서 ‘에이전트 마켓플레이스 시대’로의 전환
초기 생성형 AI 붐의 핵심 역량은 프롬프트 엔지니어링이었습니다. 어떤 문장을 어떻게 써야 원하는 답을 얻을지에 모든 관심이 쏠렸고, 많은 조직이 사내용 챗봇·FAQ 봇을 만드는 데 리소스를 투입했습니다.
지금은 흐름이 달라지고 있습니다. 프롬프트만으로 한계를 느낀 조직이 툴 호출·워크플로 오케스트레이션·장기 메모리·권한 제어까지 포함한 에이전트 스택 설계 역량을 요구하기 시작했습니다.
다음 단계는 에이전트 마켓플레이스입니다. Oracle Fusion, Salesforce Agentforce, Microsoft Copilot 확장, Google Cloud Marketplace, Concentrix Pre-Built Agentic AI처럼 플랫폼 위에 수십·수백 개 도메인 특화 에이전트가 올라가는 구조가 빠르게 확산 중입니다.
개발자와 IT 리더의 역할도 바뀝니다. 직접 모든 에이전트를 만드는 장인이라기보다, 어떤 프리빌트 에이전트를 어디에 배치하고 어떤 영역을 자체 구축할지 설계하는 아키텍트가 됩니다. 에이전트 카탈로그·표준·거버넌스를 모두 고려해 포트폴리오를 짜는 일이 핵심 역할이 됩니다.
보안·거버넌스·벤더 락인: 에이전틱 AI의 3대 리스크
데이터 보안·접근 통제: 왜 Rubrik·Veza가 주목받는가
에이전틱 AI의 가장 큰 특징은 자율 에이전트 특징인 “스스로 행동하는 능력”입니다. 이 능력이 ERP, CRM, 컨택센터, 보안 시스템 같은 핵심 인프라에 연결되면 데이터 보안과 접근 통제 난이도가 크게 올라갑니다.
예를 들어 영업 데이터 정리를 맡은 에이전트가 잘못된 규칙으로 수만 건 고객 정보를 덮어쓸 수 있습니다. 사람 한 명의 실수보다 훨씬 빠르고 광범위한 피해가 발생합니다. Rubrik Agent Cloud의 Agent Rewind 같은 기능이 주목받는 이유입니다.
Veza AI Agent Security는 또 다른 각도에서 문제를 다룹니다. 에이전트 계정·API 키·롤을 통합 관리하고, 어떤 에이전트가 어떤 민감 데이터에 접근 가능한지 지속적으로 점검합니다. 컨택센터·ERP·보안 로그 등 여러 시스템을 가로지르는 에이전트 권한을 통합 시야로 보는 것이 핵심입니다.
실무적으로는 “사람 계정에 대한 IAM”과 별도로 “에이전트 계정에 대한 IAM”을 설계해야 합니다. 권한 부여·승인·리뷰·해지를 자동화할 수 있는 에이전트 전용 거버넌스 층이 필요합니다.
벤더 락인·규제 리스크: 오픈 표준이 줄여주는 4가지
에이전트 마켓플레이스 확산과 함께 벤더 락인·규제 리스크도 커지고 있습니다.
첫째, 마켓플레이스 종속 리스크입니다. 특정 ERP·CRM 마켓플레이스 에이전트에만 의존하면 다른 플랫폼으로의 이동이 어렵습니다. MCP 기반 툴 호출·표준화된 워크플로 정의를 사용해 에이전트 로직의 이식성을 높여야 합니다.
둘째, 데이터 거버넌스·규제 대응입니다. 규제가 강화될수록 에이전트가 어디에서 실행되고 어떤 데이터에 접근하는지 증명해야 합니다. Agentic AI Foundation 같은 표준 재단이 제공하는 참조 아키텍처·인증 프로그램을 활용하면 감사 대응 부담을 줄일 수 있습니다.
셋째, 계약·라이선스 조건 관리입니다. 에이전트 마켓플레이스는 종종 별도 수수료·과금 구조를 가집니다. 계약서에 데이터 소유권, 로그 보존, 모델 재학습 권한 등을 명확히 두고 멀티벤더 전략을 전제로 협상해야 합니다.
넷째, 멀티벤더 오케스트레이션 전략입니다. 한 벤더 Copilot·에이전트에 모든 워크플로를 얹기보다, 핵심 시스템마다 1~2개 벤더를 조합하는 구조를 그리고 표준 프로토콜 위에서 이들을 오케스트레이션해야 락인 리스크가 줄어듭니다.
2026년 개발자·IT 리더를 가를 에이전트 역량 맵
2026년을 기준으로 개발자·IT 리더에게 요구될 역량은 크게 다섯 가지입니다.
첫째, 에이전트 아키텍처 설계 역량입니다. 플래너·메모리·툴 호출·관측·거버넌스 블록을 조합해 목적에 맞는 에이전트 스택을 설계하는 능력이 필요합니다.
둘째, 도메인 모델링·프로세스 이해입니다. 특정 산업·업무 도메인을 엔드투엔드로 이해하고 어디까지를 에이전트에 맡기고 어디서부터 사람 개입을 둘지 정의할 수 있어야 합니다.
셋째, 거버넌스·보안 설계 역량입니다. IAM, 데이터 분류, 감사 로그, 정책 엔진 등 Agentic AI 도입 시 고려사항을 체계적으로 설계하는 능력이 필수입니다.
넷째, 마켓플레이스·벤더 전략 수립 능력입니다. 프리빌트 에이전트 카탈로그를 읽고 조직에 맞는 조합을 고르며, 필요 시 오픈 스택 기반 커스텀 에이전트로 보완하는 포트폴리오 설계 역량입니다.
다섯째, 제품·변화 관리 역량입니다. 에이전트는 한번 도입하면 조직의 일하는 방식을 바꿉니다. 교육·채택·피드백·버전 업그레이드를 포함한 제품 관점에서 운영할 수 있어야 합니다.
결론
Agentic AI Foundation 출범과 MCP·goose·AGENTS.md로 대표되는 오픈 표준 스택, Concentrix·IBM·Oracle의 프리빌트 에이전트, Rubrik·Veza의 거버넌스 솔루션이 맞물리며 에이전트 전쟁의 판이 깔렸습니다. 오픈 재단과 벤더 마켓플레이스, 보안·규제 요구가 서로 밀고 당기며 2026년까지 에이전트 생태계의 기본 구도를 결정하게 됩니다.
앞으로 경쟁력을 가르는 질문은 “프롬프트를 잘 쓰느냐”가 아니라 “어떤 에이전트 스택·마켓플레이스·통제 프레임워크 조합을 선택하느냐”입니다. 에이전틱 AI를 개별 챗봇이 아니라 인프라·프로덕트 레벨의 설계 과제로 보는 관점 전환이 필요합니다.
지금 사용하는 컨택센터, ERP, CRM, 보안 툴을 기준으로 3개월 안에 시도할 프리빌트 에이전트 후보와 1년 안에 투자할 오픈 표준·에이전트 설계 역량을 각각 리스트로 작성해 보세요. 이 리스트를 분기별로 업데이트하면서 PoC·파일럿·본격 도입 로드맵을 구체적인 날짜·시스템 단위로 쪼개 실행 계획을 세우면, 2026년 에이전트 전환의 속도를 주도하는 쪽에 설 수 있습니다.