AI 주요 개념 (2)#

이번 장에서는 미세 조정(Fine-tuning), RAG, Function Calling, MCP를 중심으로 “사전 학습된 LLM을 서비스에 붙여 쓸 때” 자주 마주치는 핵심 개념들을 정리합니다.

미세 조정(Fine-tuning)#

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

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

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

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

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

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

Function Calling#

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

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

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

둘을 한 문장으로 요약하면 이렇게 볼 수 있습니다.

• RAG = 읽어서 답하기(문서를 참고)
• Function Calling = 실행해서 답하기(시스템을 호출)

예시 1) 매출 요약(업무/비즈니스)#

사용자의 요청이 “이번 달 매출을 요약해줘"라면, LLM은 다음과 같은 일을 할 수 있습니다.

• DB/BI 조회 도구 호출 → 이번 달 매출 데이터 가져오기
• 계산/집계 도구 호출 → 합계/평균/증감률 계산
• 결과를 자연어로 요약 → 사람이 읽기 쉬운 보고서 형태로 출력

예시 2) 누구나 이해하기 쉬운 생활/업무 예시#

• 예약/일정: “내일 오후 3시에 회의 잡아줘” → 캘린더 생성 도구 호출 → 결과 확인 후 안내
• 고객지원: “환불 규정 알려줘” → (RAG로) 환불 정책 문서 검색·인용 → 규정 요약
  “환불 처리도 해줘” → (Function Calling으로) 주문/결제 시스템 호출 → 처리 결과 안내
• 실시간 정보: “오늘 서울 날씨 알려줘” → 날씨 API 호출 → 현재/예보 요약
• 문서 작성: “이 계약서 초안을 우리 템플릿으로 채워줘” → 템플릿/문서 생성 도구 호출 → 초안 생성 후 검토 요청

왜 중요한가?#

Function Calling의 장점은 모델이 “말로만 그럴듯하게” 답하는 것을 줄이고, 실제 시스템의 데이터나 외부 서비스(API) 결과를 기반으로 더 정확하고 일관된 답변을 만들 수 있다는 점입니다. 또한 RAG와 결합하면, 정책/매뉴얼/지식은 문서 검색으로 근거를 보강하고(RAG), 실시간 조회/계산/업무 처리는 도구 호출로 수행해(Function Calling) 더 실용적인 AI 애플리케이션을 구축할 수 있습니다.

MCP(Model Context Protocol)#

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

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

실제로 ChatGPT나 Gemini 같은 LLM 서비스의 API 스펙에는 오래전부터 Function Calling 기능이 포함되어 있었습니다. 다만 각 서비스별로 “함수 정의를 어떻게 전달하고, 호출 결과를 어떤 형식으로 다시 넣을지” 같은 프로토콜이 제각각이었고, Function Calling이라는 개념 자체가 대중적으로 크게 주목받던 시기가 길지 않았기 때문에 관련 기능의 확산 속도는 (MCP 등장 이후에 비해) 빠르지 않았습니다.

하지만 MCP가 등장하면서, 도구 연결 방식이 표준화되고 “연결 가능한 도구 생태계”가 빠르게 만들어지기 시작했습니다. 그 결과 Function Calling은 단순히 특정 벤더 API의 부가 기능이 아니라, 다양한 서비스/시스템을 LLM에 붙이는 기본 인터페이스에 가까운 위치로 올라오며 확산 속도가 크게 빨라졌습니다. 그리고 MCP를 통해 붙일 수 있는 도구의 폭과 깊이가 넓어지면서, LLM을 활용하는 서비스들도 단순한 Q&A를 넘어 조회·계산·업무 처리·자동화까지 더 폭넓은 기능을 수행할 수 있게 되었고, 결과적으로 “서비스의 능력”이 크게 향상되었습니다.

Function Calling API의 실행 흐름(예)#

아래는 개념을 이해하기 위한 간단한 흐름입니다.

• (사용자) “오늘 날씨가 어때? (참고로 호출 가능한 함수는 getWeather(), getStock()이 있어)”
• (LLM) “getWeather() 호출 결과가 필요합니다.”
• (시스템) getWeather() 실행 결과: “맑음, 강수확률 10%, 온도 27도”
• (LLM) “오늘의 날씨는 맑고, 강수확률은 10%이며, 온도는 27도예요!”

핵심은, Function Calling이 **RAG만으로는 해결하기 어려운 ‘외부 시스템과의 커뮤니케이션(조회/계산/처리)’**을 가능하게 해 준다는 점입니다.

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

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

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

MCP 클라이언트 / MCP 서버#

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

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

많은 경우 사용자는 MCP 클라이언트가 들어 있는 앱을 사용하면서, 필요한 MCP 서버를 찾아 연결합니다. 예를 들어 https://smithery.ai/ 같은 곳에서 목적에 맞는 MCP 서버를 탐색해 연결하는 방식이 있을 수 있습니다.

실행 흐름 예(개념)#

예를 들어 사용자가 **클로드 앱(= MCP 클라이언트가 내장된 LLM 클라이언트 앱)**에 “노션 관련 MCP 서버를 연결해 놓고, 특정 노션 문서를 찾아 요약해 달라”라고 요청한다면, 흐름은 대략 다음과 비슷합니다.

• (사용자) “나에게 요청된 노션 작업 중 챗봇 관련 작업을 찾아서 요약해줘”
• (앱/클라이언트) 연결된 MCP 서버들의 기능 명세를 포함해 LLM이 판단할 수 있도록 요청을 구성
• (LLM) “노션 MCP 서버의 문서 탐색/조회 기능 호출이 필요합니다.”
• (클라이언트) MCP 서버의 해당 기능을 호출하고 결과를 받아옴
• (LLM) 결과를 바탕으로 요약을 작성
• (앱) 최종 결과를 사용자에게 출력

정리하면, 우리는 이미 존재하는 MCP 클라이언트/서버를 조합해 기능을 빠르게 활용할 수도 있고, 우리가 자체적으로 구현한 백엔드에 MCP 클라이언트를 구현해 외부 기능을 붙일 수도 있으며, 반대로 우리 데이터/기능을 외부에 제공하기 위해 MCP 서버를 구현하는 방향도 가능합니다.