A2A, MCP, RAG? 기업용 AI 도입 전 모르면 손해 보는 기술 용어

기업용 AI 플랫폼 고를 때 ‘이 단어’만큼은 꼭 알고 가세요.
A2A, MCP, RAG, ReBAC…
혹시 어떤 개념인지 알고 계신가요?
그렇다면, 이 기술들이 실제로 우리 조직의 AI 수준을 어디까지 끌어올릴 수 있는지 구분할 수 있으신가요?
기업용 AI 시스템을 도입하려고 제안서를 검토하는 순간, 리더들은 생각지 못한 난관에 부딪힙니다. “RAG 됩니다”, “MCP 연동됩니다”, “권한 관리도 됩니다” 같은 말이 쏟아지죠.
업체의 설명에 고개를 끄덕이면서도 마음 한구석이 찜찜한 이유는 딱 하나입니다. 이 중 무엇이 기본이고, 무엇이 진짜 구현 난도가 높은 기술인지 리더 입장에서 바로 구분하기 어렵기 때문이죠.
그래서 오늘은 기업용 AI를 고를 때, 반드시 구분해야 할 기술 용어를 가장 쉬운 언어로 정리했습니다.
글을 읽고 나면 적어도 ‘그럴듯해 보이는 단어’에 휘둘리는 일은 없을 겁니다.
💡 바쁜 리더를 위한 3줄 요약
1. MCP·아티팩트·스킬·RAG = 기본 ⭐️
이거 된다고 기술력 자랑하는 업체라면 아직 출발선에 서 있다는 뜻입니다.
2. A2A = AI 에이전트끼리 서로 협업하게 만드는 기술 ⭐️⭐️⭐️⭐️
AI가 조직의 핵심 인재처럼 일하려면, 답변하기 어려운 질문에는 다른 AI 에이전트와 서로 소통하여 답할 수 있어야 합니다.
3. ReBAC = 진짜 기업용 AI를 가르는 최종 기준 ⭐️⭐️⭐️⭐️⭐️
내부 기밀 유출을 막아주는 권한 기술. AI가 허락된 사람에게, 허락된 데이터만, 허락된 관계 안에서 보여줄 수 있어야 진짜 Agentic AI입니다.
→ MCP·RAG 등은 기본 체력, A2A는 협업 능력, ReBAC은 현업 투입 자격이라고 보시면 됩니다.
1단계 : MCP, 스킬, 아티팩트, RAG
먼저 가장 기본이 되는 개념부터 확인해보겠습니다.
다음 4가지는 기업용 AI를 이야기할 때 이제 기본 요건처럼 언급되는 기술입니다.
MCP란?
MCP(Model Context Protocol) : AI와 바깥세계를 연결하는 길목을 만들어 주는 것 (Connection)
노션, 슬랙, Gmail 등 사내 시스템들을 넘나들게 해주는 만능 연결선
MCP는 AI가 회사 안의 데이터, 업무 도구, 시스템과 연결될 수 있도록 만들어둔 ‘길’입니다. 고립된 AI의 답변 세계를 확장시켜주는 거죠. “우리 회사 업무 환경으로 들어가는 문"이라고도 볼 수 있어요.
이전에는 직원이 AI에게 질문하기 위해 직접 필요한 파일을 열고, 그 안의 데이터를 복사해서 AI에게 보내줘야 했다면, MCP 기능이 있는 AI는 직접 인사 시스템에 들어가 근태를 읽고, 매출 시스템에 가서 보고서를 가져와 답변에 참고할 수 있게 됩니다.
스킬이란?
스킬(Skills) : AI 시스템이 문서 생성, 코드 작성, 이미지 생성 등 특화된 작업을 할 때 참조하는 지침서. 개개인별로 달라지는 AI 답변을 '조직의 매뉴얼'로 통합 (Execution)
‘앞으로 해당 업무는 늘 이 매뉴얼대로 처리해’라고 출력값의 기준을 정해두는 것
혼자 챗봇을 쓸 때는 원하는 답이 나올 때까지 질문을 바꿔가며 반복 학습시켜도 괜찮습니다. 하지만 회사 일은 그러면 안 되죠. 김 대리와 이 과장이 똑같이 물었는데, 결과물이 다르고 기준이 제각각이라면 실제 업무에 쓸 수 없으니까요.
스킬은 AI가 일하는 방식을 정식 사내 매뉴얼로 못 박아둔 '표준 업무 방식'입니다. 우리 회사가 정한 보고서 양식, 말투, 필수 검증 단계들을 미리 정의해서 반영해 두는 것이죠.
신입사원이든 베테랑이든 버튼만 누르면 회사 기준에 딱 맞춘 고품질의 결과물이 나옵니다. AI가 마음대로 단계를 건너뛰거나 엉뚱한 답을 내는 위험을 막아주는 안전장치인 거죠.
아티팩트란?
아티팩트(Artifacts) : AI 결과물을 작업물 파일로 남기는 방식 (Result)
AI의 결과물을 '채팅 답변'에서 '작업물 파일'로 바꾸다
AI가 질문을 받는 즉시 결과물을 ‘진짜 파일’ 형태로 만들어주는 겁니다.
예를들어 클로드에게 “우리 회사 마케팅 결과 보고서 써줘”라고 하면, 예전에는 채팅창에 긴 글을 줄줄이 뱉었습니다. 하지만 지금은 오른쪽에 별도의 화이트보드 창(Artifacts)을 새로 열고, 보고서나 엑셀차트와 같은 별도 작업물로 완성해 놓죠. 이 개념이 아티팩트입니다.
RAG란?
RAG(Retrieval-Augmented Generation) : AI가 근거를 찾아오게 만드는 기술 (Information)
그럴듯한 추측이 아니에요. 실제 사내 데이터 기반으로만 답변합니다.
아무리 MCP로 전사 시스템을 연결하고 스킬로 묶어놔도, AI가 자기 머릿속(학습 데이터)에서만 답을 찾으면 결국 헛소리를 내뱉게 됩니다.
RAG는 AI가 답변을 하기 전, 사내 문서나 데이터베이스에서 정확한 실제 근거 자료부터 '검색'해 오도록 강제하는 기술입니다.
"우리 회사 규정상 이럴 땐 어떻게 해야 하지?"라고 물었을 때, AI가 대충 그럴듯한 규정을 지어내서 소설을 쓰는 게 아니라, 실제 사내 인사 규정 PDF 파일에서 해당 조항을 먼저 눈으로 찾아온 뒤 그걸 바탕으로 답하게 만드는 구조입니다.
| 구분 | MCP | 스킬 | 아티팩트 | RAG |
|---|---|---|---|---|
| 핵심 역할 | 연결 (Connection) |
실행 (Execution) |
결과 (Result) |
지식 (Knowledge) |
| 한 줄 정의 | AI가 전사 데이터·도구를 쓸 수 있게 통로를 여는 표준 규격 | 특정 업무를 조직 기준에 맞춰 반복 수행하게 하는 능력 | AI 결과물을 독립된 작업물·비즈니스 자산으로 남기는 방식 | 사내 문서를 실시간 검색해 환각을 줄이고 사실 기반으로 답변하게 하는 기술 |
| 핵심 질문 | 필요한 데이터와 도구가 유기적으로 연결되는가? | 조직이 정한 프로세스대로 오차 없이 실행되는가? | 결과물이 즉시 활용 가능한 비즈니스 자산으로 남는가? | 사내 정보 기반으로 답하는가? |
| 실무 예시 | ERP·CRM·HR·슬랙 등 이기종 시스템 연동 | 정기 매출 분석, 코드 리뷰, 맞춤형 보고서 자동 작성 | 인터랙티브 대시보드, 웹 시안, 커스텀 가이드라인 문서 | 취업규칙 조회, 제품 사양서 검색, 프로젝트 이력 추적 |
여기까지가 기업용 AI가 대부분 갖추고 있는 최소한의 인프라입니다.
하지만 현명한 리더라면 저렴하다는 이유만으로 ‘질문에 겨우 답하는 챗봇 수준’의 AI를 도입하고 싶지는 않을 겁니다. 비용을 더 지불하더라도 각각의 전문성을 가진 AI 에이전트들이 서로 소통하며 업무를 진행하는 수준의 고도화된 AI를 원할 테죠.
지금부터 말씀드릴 두 가지가 바로 그 차이를 가릅니다.
수많은 AI 시스템이 간과하고 있거나 기술이 부족해 포기하는 영역입니다.
구현하기가 까다롭고 막대한 리소스가 들기 때문에, 이 두 개가 제대로 돌아가느냐에 따라 AI는 나를 도와주는 ‘업무 보조 도구’에 머물 수도 있고, 조직 안에서 ‘핵심 인재’처럼 일하는 시스템이 될 수도 있습니다.
2단계 : A2A(Agent-to-Agent)
A2A는 에이전트끼리 서로 필요한 정보를 주고받게 만드는 기술입니다.
같은 회사가 만든 AI끼리만 대화하는 것이 아니라, 서로 다른 회사와 다른 기술로 만들어진 AI 에이전트들도 같은 규칙으로 정보를 주고받고 일을 나눠 할 수 있게 만드는 방식입니다.
A2A가 중요한 이유
기업 업무는 한 에이전트 안에서 끝나지 않기 때문이에요.
예를 들어 “신규 입사자 온보딩 일정을 짜줘”라는 요청 하나에도 채 용 정보, 근로계약 기준, 필수 교육, 팀 배치 데이터가 함께 필요합니다.
A2A를 구현하지 못하면 채용 에이전트는 여기서 답변을 멈춥니다.
“채용 정보는 확인할 수 있지만, 근로계약 기준이나 필수 교육 일정에는 접근할 수 없습니다. 관련 부서에 확인이 필요합니다.”
결국 사람이 다시 각 시스템을 열고 정보를 이어붙여야 하죠.
A2A가 있으면 무엇이 달라질까?
반대로 A2A가 있으면 채용 에이전트가 노무 어시스턴트에게 계약 기준을 확인하고, 교육 에이전트에게 필수 교육 일정을 받아와 하나의 온보딩 계획으로 합칠 수 있게 됩니다.
즉, A2A는 AI가 혼자 답하는 수준을 넘어서, 에이전트들이 서로 협업해 업무를 완성하게 만드는 구조입니다.
3단계 : 최종 판가름, ReBAC '권한 제어'
ReBAC 권한 제어란?
ReBAC은 직책만 보고 권한을 주는 방식이 아닙니다. 이 사람이 지금 이 팀, 프로젝트, 문서, 상위 조직과 어떤 관계에 있는지를 실시간으로 따져 접근을 허락하는 방식입니다.
- RBAC (Role-Based Access Control, 역할 기반 접근 제어)
- ReBAC (Relationship-Based Access Control, 관계 기반 접근 제어)
A2A로 에이전트들이 아무리 똑똑하게 협업해도, 누가 어떤 데이터에 접근해도 되는지 판단하지 못하면 핵심 업무에 투입될 수 없습니다.
권한 제어가 중요한 이유
인사 정보, 재무 기밀, 실시간 목표 데이터 등. 예민한 정보를 다루는 기업 AI는 “볼 수 있는 자격이 있는 사람에게만” 진실을 말하도록 철저히 통제되어야 합니다. 이게 안 되면 AI는 민감한 정보를 전사에 유출하는 내부 밀고자가 되어버리니까요.
그렇기에 업체 계약 전, 반드시 아래 3가지 권한 제어 수준 중 어디까지 지원하는지 확인해야 합니다.
| 수준 | 방식 | 설명 | 리스크 |
|---|---|---|---|
| 🔴 낮음 | 단일 권한 | 문서 통째로 권한을 열거나 닫는 수준 |
정보 노출 위험도 매우 높음 |
| 🟠 보통 | RBAC (역할 기반) |
"팀장급은 다 봐" 수준의 뭉뚱그린 제어 |
역할 내 불필요한 접근 여전히 존재 |
| 🟢 높음 | ReBAC (관계 기반) |
"본인 TF 프로젝트 + 본인 팀원 근태만 봐" 사람·조직·역할·프로젝트 관계 기준으로 정교하게 제어 |
가장 안전함. 구현 난이도 매우 높음 |
RBAC만으로는 부족한 이유?
대부분의 업체는 구현이 쉬운 RBAC, 즉 역할 기반 권한에 머무릅니다. 쉽게 말해 “팀장이니까 보여준다”, “임원이니까 열어준다”는 식입니다.
하지만 실제 조직의 업무는 그렇게 단순하지 않죠. 내 직급은 팀장이지만 특정 TF팀에서는 일반 ‘팀원’일 수 있고, 다른 프로젝트에서는 ‘단순 참조자’일 수도 있습니다. 심지어 전임 팀장이 인수인계를 위해 당분간 단톡방에 남아있어야 하는 일도 흔합니다.
이런 상황에서 직책 기준으로만 통제하면 참사가 일어납니다. AI는 그 사람이 어제 보직 해임됐든 말든, 서류상 ‘팀장’이라는 타이틀만 보고 움직이기 때문이에요.
그렇게 되면 다음 분기 핵심 전략, 다른 팀원의 평가 자료, 보상 정보처럼 절대 새어나가면 안 되는 데이터가 엉뚱한 사람에게 노출될 수 있습니다.
ReBAC이 필요한 이유
그래서 진짜 기업용 AI는 ReBAC, 즉 관계 기반 권한으로 움직여야 합니다. 권한을 사람에게 고정해두는 것이 아니라, 사람·직책·조직·프로젝트·문서 사이의 관계가 맞을 때만 데이터를 열어주는 방식입니다.
“팀장 직책에겐 다 보여줘”가 아니라,
- “이 사람이 지금 이 조직의 팀장이 맞는가?”
- “이 문서가 속한 프로젝트의 승인권자가 맞는가?”
- “오늘 기준으로 이 데이터에 접근할 관계가 유지되고 있는가?”를 따지는 방식이죠.
진짜 기업용 AI의 핵심은 똑똑한 챗봇들이 개별로 존재해서만 되는 것이 아니에요.
A2A로 서로 소통하며 일하되, ReBAC으로 허락된 경계 안에서만 움직이게 만드는 것. 리더가 계약 전 가장 먼저 뜯어봐야 할 핵심은 바로 이 ‘통제력’입니다.
에이전트가 서로 소통하며 '핵심 인재'처럼 일하는 진짜 기업용 AI가 궁금하다면?
AI 소개서 받아보기
🖇️ 함께 읽으면 좋을 아티클

