AI 에이전트라는 말이 어디서든 들립니다. 알아서 일을 처리해주는 AI. 업무를 자동화하는 AI. 사람 대신 판단하는 AI. 그런데 실제로 쓸 만한 AI 에이전트를 만들려고 하면, 세 가지 문제에 곧바로 부딪힙니다.

첫째, 외부 도구에 연결할 때마다 맞춤 코드를 새로 짜야 합니다. 슬랙에 연결하려면 슬랙 API 코드, 검색 엔진에 연결하려면 검색 API 코드, 데이터베이스에 연결하려면 또 다른 코드. 도구가 하나 늘 때마다 개발 작업이 추가됩니다.

둘째, 학습하지 않은 지식에 대해 정확하게 답해야 합니다. AI 모델은 학습 데이터에 없는 내용을 물으면 자신 있게 지어냅니다. 우리 회사의 내부 문서, 최신 제품 스펙, 어제 업데이트된 정책 같은 것들은 모델이 알 리가 없습니다.

셋째, 매번 같은 지시를 프롬프트에 반복해서 넣어야 합니다. "너는 고객 응대 전문가야, 이런 톤으로 말해, 이 규칙을 따라" 같은 지시를 매 호출마다 토큰을 소비하면서 다시 넣습니다.

AI 에이전트 전문가 라케시 고헬Rakesh Gohel​이 정리한 것처럼, 이 세 문제를 각각 해결하기 위해 만들어진 것이 MCP, RAG, 그리고 Skills입니다. AI 에이전트를 떠받치는 세 개의 기둥입니다.

첫 번째 기둥: MCP — 도구를 연결하는 표준 규격

MCPModel Context Protocol​는 AI 에이전트가 외부 도구에 연결될 때마다 맞춤 코드를 짜야 하는 문제를 해결합니다.

비유하자면 이렇습니다. USB가 나오기 전에는 프린터, 키보드, 마우스마다 전용 포트와 케이블이 따로 있었습니다. 새 기기를 연결할 때마다 드라이버를 설치하고 설정을 맞춰야 했습니다. USB가 나오면서 하나의 규격으로 모든 기기를 연결할 수 있게 됐습니다.

MCP가 AI 에이전트에게 하는 일이 이겁니다. 슬랙이든, 검색 엔진이든, 벡터 데이터베이스든, 하나의 표준화된 프로토콜로 연결합니다.

작동 방식은 이렇습니다. 사용자가 질문을 보내면 MCP 클라이언트가 적합한 서버를 선택합니다. LLM이 요청을 처리해서 MCP 서버로 라우팅합니다. 서버(슬랙, Qdrant, Brave Search 등)가 관련 데이터를 보내줍니다. 최종 결과가 사용자에게 돌아옵니다.

핵심은 이겁니다. MCP가 없으면 새 도구를 연결할 때마다 맞춤 코드를 짜야 합니다. MCP가 있으면 하나의 표준 프로토콜로 어떤 서버든 연결됩니다. 새 도구가 추가돼도 연결 방식은 동일합니다.

언제 쓰나요. 에이전트가 외부 도구와 서비스에 접근해야 하는데, 매번 통합 코드를 처음부터 다시 만들고 싶지 않을 때입니다.

두 번째 기둥: RAG — 모르는 것을 정확히 답하게 하는 장치

RAGRetrieval Augmented Generation​는 AI 에이전트에게 '기억이 가능한 검색 능력'을 부여합니다. 학습하지 않은 지식에 대해서도 지어내지 않고 정확하게 답할 수 있게 만드는 구조입니다.

AI 모델의 가장 큰 문제 중 하나가 '환각(hallucination)'입니다. 모르는 것을 모른다고 하지 않고, 그럴듯하게 지어냅니다. 회사 내부 문서에 대해 물으면, 있지도 않은 정책을 자신 있게 설명합니다. RAG는 이 문제를 구조적으로 막습니다.

작동 방식은 이렇습니다. 데이터 소스문서, 스프레드시트, 데이터베이스 등​를 잘게 쪼갭니다. 쪼갠 조각들을 임베딩으로 변환해서 벡터 데이터베이스에 저장합니다. 사용자가 질문하면 가장 관련 있는 조각들을 검색합니다. 검색된 정보 + 원래 질문 + 시스템 프롬프트를 LLM에 넣어서 답변을 생성합니다.

핵심은 이겁니다. RAG가 없으면 에이전트는 자신 있게 지어냅니다. RAG가 있으면 먼저 검색하고, 그다음에 추론합니다. 순서가 바뀌는 것만으로 정확도가 근본적으로 달라집니다.

언제 쓰나요. 에이전트가 크고 동적인 지식 베이스를 기반으로 정확하고 맥락 있는 추론을 해야 할 때입니다. 회사 내부 문서, 제품 매뉴얼, 법률 문서, 고객 이력 같은 데이터가 있을 때 특히 유용합니다.

세 번째 기둥: Skills — 반복 지시를 없애는 모듈

Skills는 매번 같은 지시를 프롬프트에 반복하면서 토큰을 낭비하는 문제를 해결합니다.

AI 에이전트를 쓰다 보면 이런 일이 생깁니다. "너는 코드 리뷰 전문가야. 이 규칙을 따라. 이 형식으로 답해." 같은 지시를 매 호출마다 넣습니다. 토큰이 소비되고, 프롬프트가 길어지고, 정작 중요한 질문을 넣을 공간이 줄어듭니다.

Skills는 이런 반복 지시를 모듈화합니다. 자주 쓰는 행동 패턴을 미리 정의해두고, 필요할 때만 불러 쓰는 방식입니다.

작동 방식은 이렇습니다. 사용자가 질문하면 LLM이 스킬 매니저Skill Manager​에 요청을 보냅니다. 스킬 매니저가 저장된 프롬프트와 액션 중에서 적합한 것을 선택합니다. Git, Docker, Python 인터프리터, Shell 같은 도구가 실행됩니다. 스킬 데이터가 LLM으로 돌아가서 최종 출력이 나옵니다.

핵심은 이겁니다. Skills가 없으면 매 프롬프트마다 반복 지시로 부풀립니다. Skills가 있으면 에이전트가 필요한 것만, 필요한 시점에 로드합니다.

언제 쓰나요. 재사용 가능하고 토큰 효율적인 액션을 만들어서, 에이전트가 매번 새로 지시받지 않아도 실행할 수 있게 하고 싶을 때입니다.

세 기둥의 관계

이 세 가지는 서로 경쟁하는 게 아니라, 각각 다른 문제를 해결합니다.

MCP는 '손'입니다. 에이전트가 외부 세계의 도구를 잡을 수 있게 해줍니다. RAG는 '기억'입니다. 에이전트가 학습하지 않은 지식도 정확하게 꺼내 쓸 수 있게 해줍니다. Skills는 '습관'입니다. 에이전트가 반복 작업을 매번 처음부터 배우지 않아도 되게 해줍니다.

실제로 잘 작동하는 AI 에이전트는 이 세 가지를 조합해서 씁니다. MCP로 슬랙과 데이터베이스에 연결하고, RAG로 회사 내부 문서를 검색하고, Skills로 코드 리뷰나 보고서 작성 같은 반복 작업을 모듈화합니다.

왜 지금 이 구조가 중요한가

AI 에이전트가 실험실에서 나와 실제 업무에 투입되기 시작하면서, "챗봇에 프롬프트 잘 쓰기"만으로는 부족한 시대가 됐습니다. 에이전트가 실제로 쓸모 있으려면 외부 도구에 접근하고(MCP), 정확한 정보를 기반으로 답하고(RAG), 효율적으로 반복 작업을 처리(Skills)할 수 있어야 합니다.

이 세 가지 구조를 이해하는 것은 개발자만의 일이 아닙니다. AI 도입을 기획하는 PM, 자동화를 검토하는 팀 리더, AI 서비스를 평가하는 의사결정자 모두에게 해당합니다. 어떤 AI 에이전트 서비스를 보더라도 "이 제품은 MCP, RAG, Skills 중 어떤 문제를 풀고 있는가?"라고 물으면 구조가 보이기 시작합니다.

AI 에이전트의 겉모습은 "알아서 해주는 AI"이지만, 안쪽은 이 세 개의 기둥이 떠받치고 있습니다. 기둥이 튼튼해야 에이전트가 실무에서 버팁니다.