AI 핵심 개념 (2): Fine-tuning / RAG / Function Calling / MCP#

이번 장에서는 미세 조정(Fine-tuning), RAG, Function Calling, MCP를 중심으로 “사전 학습된 LLM을 서비스에 붙여 쓸 때” 자주 마주치는 핵심 개념들을 정리합니다. 네 가지는 모두 같은 질문에서 출발합니다. “모델이 원래 모르는 것을 어떻게 다루게 할 것인가?” 모델 자체를 바꾸는 방법(Fine-tuning), 읽을거리를 붙여 주는 방법(RAG), 일을 시키는 방법(Function Calling), 그리고 그 일을 시키는 방식을 표준화한 규약(MCP)의 순서입니다.

미세 조정(Fine-tuning)#

미세 조정(Fine-tuning)은 사전 학습된(Pre-trained) 모델을 특정 목적에 더 잘 맞도록 추가로 학습시키는 과정입니다. 오픈 소스 문화 덕분에 학습용 데이터셋과, 그 데이터셋으로 사전 학습된 모델이 공개되는 경우가 많고, 이를 바탕으로 성능을 향상시키거나 특정 분야에 더 특화시키기 위해 미세 조정을 적용할 수 있습니다. 예를 들어 의류를 판매하는 전자상거래 시스템에서 AI 챗봇을 만들 때 공개 모델을 그대로 사용하면, 일반적인 대화는 가능하더라도 해당 서비스의 상품 / 정책 같은 내부 정보를 모르기 때문에 제품 문의에 대해 만족스러운 답변을 못 할 수 있습니다. 이럴 때 미세 조정이 하나의 대안이 될 수 있습니다.

미세 조정에는 모델 전체를 다시 학습시키는 방법(Full Fine-tuning)과, 일부 파라미터만 효율적으로 학습시키는 방법(Parameter Efficient Fine-tuning, PEFT)이 있습니다. 전자는 비용과 시간이 많이 들고 모델이 원치 않는 방향으로 변형될 위험도 있어, 최근에는 후자에 대한 연구와 활용이 활발합니다.

다만 1인 스타트업 관점에서 솔직하게 말하면, 미세 조정이 첫 번째 선택지가 되는 경우는 드뭅니다. 미세 조정은 “말투나 형식을 일관되게 만들기”, “특정 분류 작업을 작은 모델로 싸게 처리하기"처럼 행동 방식을 바꾸는 데 강하고, “최신 정보나 내부 문서를 알게 하기"에는 약합니다. 후자는 다음에 설명할 RAG가 훨씬 싸고 안전합니다.

RAG(Retrieval-Augmented Generation, 검색-증강 생성)#

RAG는 LLM 모델이 답변을 생성할 때, 먼저 외부의 관련 자료를 “검색” 하고, 그 결과를 질문과 함께 “참고자료로 붙여” (컨텍스트) 답변을 “생성” 하는 방식입니다. 다시 말해서, LLM이 외부 문서(지식)를 직접 참고할 수 있도록 해 최신성, 정확성, 근거 제시 측면에서 출력을 개선하는 접근입니다.

ChatGPT가 출시되고 엄청난 속도로 사용자가 늘면서, 동시에 자주 언급되던 한계는 학습 범위(학습 시점) 밖의 최신 정보나 조직 / 도메인 내부 지식에 대해 정확하거나 근거 있는 답변을 보장하기 어렵다는 점이었습니다. LLM을 이용하는 서비스는 기본적으로 사전 학습된 모델을 기반으로 구축되기 때문에, 모델이 직접 학습하지 않은 최신 데이터나 특정 영역의 전문 데이터에 대해서는 답변의 정확도가 흔들리거나 근거를 제시하지 못할 수 있습니다. 이러한 한계를 보완하기 위해 등장한 대표적인 접근 중 하나가 RAG입니다.

RAG의 동작은 앞 장에서 설명한 임베딩 위에 세워집니다. 문서를 잘게 나눠 임베딩으로 바꿔 저장해 두고(색인), 질문이 들어오면 질문의 임베딩과 가까운 조각을 찾아(검색), 그 조각을 프롬프트에 붙여 모델에게 보냅니다(생성).

정리해 보면, 사전 학습된 범위를 벗어나는 내용에 대해 모델의 출력을 개선하는 방법에는 크게 미세 조정과 RAG 두 가지가 있습니다. 미세 조정은 모델 자체를 추가 학습시키는 것이고, RAG는 모델은 그대로 두되 검색으로 찾은 외부 문서를 컨텍스트에 포함시켜 참조하도록 하는 것입니다. 사람에 비유해 보면, 미세 조정은 상담원이 회사에서 교육을 더 받아 지식과 역량을 강화하는 것이고, RAG는 상담원에게 인터넷 검색이 가능한 노트북을 지급해 주는 것과 같습니다. RAG는 검색 / 컨텍스트 구성 과정이 추가되므로 상황에 따라 지연이 늘 수 있다는 단점이 있지만, 모델을 다시 학습시키는 비용과 위험 부담 없이도 최신 정보나 도메인 지식을 유연하게 반영해 출력을 개선할 수 있다는 장점이 있습니다. 두 기술은 서로 배타적인 관계가 아니므로, 상황과 목적에 따라 섞어서 사용하는 것도 가능합니다.

Function Calling#

RAG가 “참고할 자료를 찾아서 붙여 주는 방식” 이라면, Function Calling(Tool Calling이라고도 부릅니다)은 “필요한 작업을 실제로 실행해 결과를 가져오는 방식” 입니다. 즉, LLM이 답변을 만드는 도중에 스스로 판단하여 미리 정의된 도구(함수)를 호출하고, 그 실행 결과를 받아 최종 답변을 완성하는 접근입니다. 여기서 “도구"는 개발자가 미리 연결해 둔 API 호출, DB 조회, 계산 함수, 사내 시스템 동작 등을 의미합니다.

한 가지 오해를 미리 풀어 두면, LLM이 함수를 직접 실행하는 것이 아닙니다. LLM은 “이 함수를 이런 인자로 호출해야 한다"는 요청을 텍스트(구조화된 JSON)로 출력할 뿐이고, 실제 실행은 개발자의 서버가 합니다. 실행 결과를 다시 모델에게 넣어 주면 모델이 최종 답변을 만듭니다. 이 왕복 구조를 알고 있어야 뒤의 MCP와 에이전트가 이해됩니다.

언제 RAG를 쓰고, 언제 Function Calling을 쓰나?#

• RAG: “어떤 것이 맞는지 / 정책이 무엇인지 / 설명이 필요한지"처럼 문서나 지식을 바탕으로 답해야 할 때
• Function Calling: “지금 데이터가 얼마인지 / 무엇을 실행해야 하는지"처럼 조회 · 계산 · 실행이 필요할 때

둘을 한 문장으로 요약하면 RAG는 읽어서 답하기, Function Calling은 실행해서 답하기입니다. 고객지원 챗봇을 예로 들면, “환불 규정 알려줘"는 RAG로 환불 정책 문서를 검색해 인용하고, “환불 처리도 해줘"는 Function Calling으로 주문 / 결제 시스템을 호출해 처리 결과를 안내합니다. 실제 서비스에서는 둘을 함께 씁니다. 정책 / 매뉴얼 / 지식은 문서 검색으로 근거를 보강하고, 실시간 조회 / 계산 / 업무 처리는 도구 호출로 수행하는 식입니다.

Function Calling의 장점은 모델이 “말로만 그럴듯하게” 답하는 것을 줄이고, 실제 시스템의 데이터나 외부 서비스(API) 결과를 기반으로 더 정확하고 일관된 답변을 만들 수 있다는 점입니다. 그리고 모델이 도구를 여러 번 반복해서 호출하며 일을 끝까지 밀고 가도록 만든 것이 4장에서 다룰 에이전트입니다.

MCP(Model Context Protocol)#

Function Calling을 실제 서비스에서 폭넓게 활용하려면, 결국 “어떤 도구를 어떤 방식으로 연결할 것인가?“라는 문제가 생깁니다. MCP(Model Context Protocol)는 이를 해결하기 위해 등장한 표준 연결 방식(프로토콜) 로, LLM이 다양한 도구 / 데이터 소스에 접근할 수 있도록 일관된 규격을 제공합니다.

비유하자면, 예전에는 전자기기 포트가 제각각이라 케이블 / 젠더가 복잡했는데, “USB로 표준화합시다!“가 자리 잡으면서 주변기기 생태계가 폭발적으로 성장했던 것과 비슷합니다. MCP는 LLM과 외부 기능을 연결하는 방식을 표준화함으로써, “연결 가능한 도구"를 더 쉽게 만들고 더 쉽게 붙일 수 있는 계기를 제공합니다.

실제로 ChatGPT나 Gemini 같은 LLM 서비스의 API 스펙에는 오래전부터 Function Calling 기능이 포함되어 있었습니다. 다만 각 서비스별로 “함수 정의를 어떻게 전달하고, 호출 결과를 어떤 형식으로 다시 넣을지” 같은 프로토콜이 제각각이었고, 도구를 만든 사람과 도구를 쓰는 앱이 서로 맞춰야 할 것이 많았습니다. MCP가 등장하면서 도구 연결 방식이 표준화되고 “연결 가능한 도구 생태계"가 빠르게 만들어지기 시작했습니다. 그 결과 Function Calling은 특정 벤더 API의 부가 기능이 아니라, 다양한 서비스 / 시스템을 LLM에 붙이는 기본 인터페이스에 가까운 위치로 올라왔습니다.

MCP는 Function Calling과 어떤 관계인가?#

• Function Calling: LLM이 “도구(함수)를 호출한다"는 동작(행위) 자체
• MCP: 그 도구들을 “어떤 규격으로 연결하고 제공할지"에 대한 표준(연결 방식)

즉, Function Calling이 “전화 걸기"라면, MCP는 “전화망 규격"에 가깝습니다.

MCP 클라이언트 / MCP 서버#

MCP를 통해 LLM이 외부와 소통하려면, 크게 MCP 클라이언트와 MCP 서버가 필요합니다.

• MCP 클라이언트: 사용자의 요청을 받아, 연결된 MCP 서버들의 “가능한 기능 목록(명세)“을 포함해 LLM이 이해할 수 있도록 요청을 구성하고, LLM이 선택한 도구 호출을 실제로 실행해 결과를 다시 LLM에 전달합니다. Claude 앱, Cursor, Claude Code 같은 도구들이 MCP 클라이언트를 내장하고 있습니다.
• MCP 서버: 특정 외부 기능(예: 문서 검색 / 수정, 데이터 조회, 업무 처리)을 MCP 규약에 맞춰 노출하는 서버입니다. 외부 서비스가 공식적으로 제공할 수도 있고, 개인 / 팀이 직접 구현해 배포할 수도 있습니다.

많은 경우 사용자는 MCP 클라이언트가 들어 있는 앱을 사용하면서, 필요한 MCP 서버를 찾아 연결합니다. 예를 들어 사용자가 Claude 앱에 노션 MCP 서버를 연결해 놓고 “나에게 요청된 노션 작업 중 챗봇 관련 작업을 찾아서 요약해 줘"라고 요청하면, 앱은 연결된 서버들의 기능 명세를 포함해 LLM에게 요청을 보내고, LLM이 “노션 서버의 문서 탐색 기능 호출이 필요하다"고 판단하면 앱이 그 기능을 호출해 결과를 받아 오고, LLM이 결과를 바탕으로 요약을 작성합니다.

정리하면, 우리는 이미 존재하는 MCP 클라이언트 / 서버를 조합해 기능을 빠르게 활용할 수도 있고, 우리가 자체적으로 구현한 백엔드에 MCP 클라이언트를 구현해 외부 기능을 붙일 수도 있으며, 반대로 우리 데이터 / 기능을 외부에 제공하기 위해 MCP 서버를 구현하는 방향도 가능합니다. 마지막 방향은 1인 스타트업에게 특히 중요합니다. 사용자가 이미 쓰고 있는 에이전트 안으로 내 제품을 들여보내는 유통 경로가 되기 때문이며, 실행 편의 “제품에 AI 기능 넣기"에서 다시 다룹니다.

정리#

네 가지는 경쟁 관계가 아니라 층위가 다른 도구입니다. 다음 장에서는 이 도구들을 모델에게 “어떻게 설명하고 어떤 재료를 넣어 줄지"를 다루는 프롬프트 엔지니어링과 컨텍스트 엔지니어링을 살펴봅니다.