Google Apps Script로 만든 휴가자/일정 알림 봇을 MCP + Function Calling 기반 Agent Tool로 확장하기

📅 캘린더 알림 봇을 ‘Agent Tool’로 확장하게 된 계기

사내 구성원들은 매일 아침 “오늘 휴가자가 누구인지”, “주요 회의 일정이 무엇인지”를 각자 캘린더를 열어 직접 확인해야 했고, 이로 인해 중요한 정보가 공유되지 않거나 뒤늦게 인지되는 경우도 종종 발생했습니다.

이 문제를 해결하기 위해 처음에는 Google Apps Script와 Webhook을 활용한 ‘오늘의 일정·휴가자 알림 봇’을 제작했습니다.

구글 캘린더의 정보를 주기적으로 수집해 Slack 혹은 Mattermost 와 같은 메신저로 자동 알림을 전송하는 구조였습니다.

해당 방식은 “매일 아침 자동 알림”이라는 목적에는 충분히 효과적이었지만, 시간이 지나면서 몇 가지 한계가 분명해졌습니다.

정해진 시간·정해진 포맷의 푸시 알림 중심 구조
사용자가 “내일 일정”, “특정 날짜 휴가자”, “곧 시작하는 회의”처럼 상황에 맞게 질의하기 어려운 구조

마침 동시에, IDE와 에이전트 환경에서 자연어로 도구를 호출하는 AI 워크플로우가 빠르게 보편화되기 시작함에 따라 “캘린더 정보 역시 알림을 받는 대상이 아니라, 필요할 때 질문하고 바로 답을 얻는 도구(Agent Tool) 로 제공할 수 있지 않을까?”라는 생각이 들었습니다.

이러한 문제의식과 변화된 환경을 바탕으로, 기존 알림 봇을 단순히 개선하는 대신 캘린더 기능을 공용 도구로 분리하고, MCP(Model Context Protocol)와 Function Calling을 활용해 AI 시대에 맞는 형태로 재구성하는 프로젝트를 시작하게 되었습니다.

그 결과물이 바로 Google Calendar 도구를 MCP(stdio)와 Slack(Function Calling) 두 방식으로 제공하는 mcp-calendar 프로젝트입니다.

1. Function Calling과 MCP Server란 무엇인가요?

기존의 Webhook 기반 자동화는 “정해진 이벤트가 발생하면, 미리 정해진 동작을 수행하는 방식”에 적합했습니다.

하지만 AI/Agent 환경에서는 다음과 같은 요구가 새롭게 등장했습니다.

사용자가 자연어로 질문하면 AI가 의도를 이해하고 상황에 맞는 도구를 선택해 실행 결과를 즉시 응답 함으로서 이러한 흐름을 가능하게 하는 대표적인 방식이 Function Calling과 MCP(Model Context Protocol) 입니다.

1-1. Function Calling: AI가 ‘어떤 기능을 쓸지’ 판단하는 방식

Function Calling은 LLM(Gemini, GPT 등)이 사용자의 자연어 입력을 해석한 뒤, 미리 정의된 함수(도구) 중 어떤 것을 호출해야 하는지 구조화된 형태로 반환하는 기능입니다.

중요한 점은, AI가 함수를 “실행”하는 것이 아니라 어떤 함수를 어떤 인자로 실행해야 하는지 “결정”만 한다는 것입니다.

Function Calling 흐름 예시 (Slack 기준)

사용자: "내일 휴가자 알려줘"
 
↓ (자연어 이해)
 
LLM(Gemini):
{
  "name": "get_vacations",
  "arguments": {
    "target_date": "2025-01-23"
  }
}
 
↓ (실행 책임)
 
애플리케이션 코드:
- get_vacations 실행
- Google Calendar 조회
- 결과를 Slack에 응답

이 방식은 Slack과 같은 대화형 UI에서 매우 직관적인 UX 제공 하기 때문에 기존 애플리케이션 구조에 비교적 쉽게 도입 가능한 장점이 있습니다.

1-2. MCP Server: AI가 사용하는 ‘공용 도구 서버’

MCP(Model Context Protocol)는 AI가 외부 도구를 표준화된 방식으로 호출하기 위한 프로토콜입니다.

MCP Server의 핵심 역할은 어떤 도구들이 있는지 알려주고 (list_tools), 요청이 오면 해당 도구를 실행함으로서 (call_tool) 결과를 반환 합니다.

중요하게도, MCP Server 자체에는 LLM이 존재하지 않습니다.

MCP Server는 “생각하지 않고”,

오직 “실행만 담당”하는 도구 서버입니다.

MCP(Server–Client) 구조 예시

[ MCP Client (Cursor / Claude / Agent) ]
          │
          │ MCP (stdio)
          ▼
[ MCP Server ]
  - get_vacations
  - get_meetings
          │
          ▼
[ Google Calendar / Vacation Service ]

이 구조를 통해 도구 로직을 한 곳에서 관리로 인하여 재사용성 높아지고 Slack, IDE, Agent 등 여러 환경에서 동일한 도구 사용가능하며 LLM 교체(Gemini → GPT → Claude) 시에도 도구 서버는 그대로 유지가 가능합니다.

1-3. Function Calling vs MCP Server의 역할 차이

두 개념은 경쟁 관계가 아니라, 역할이 다릅니다.

구분	Function Calling	MCP Server
역할	어떤 도구를 쓸지 판단	실제 도구 실행
LLM 포함 여부	⭕ 포함	❌ 없음
실행 책임	애플리케이션	MCP Server
주 사용 환경	Slack, Chat UI	IDE, Agent, 공용 도구

1-4. mcp-calendar에서는 두 방식을 어떻게 활용하나

mcp-calendar 프로젝트는 캘린더 도구를 하나의 도메인 자산으로 분리하고, 사용 환경에 따라 두 가지 방식으로 제공합니다.

MCP(stdio): IDE·Agent 환경에서 질의형 도구로 사용
Slack(Function Calling): 대화형 UX에 최적화된 접근 방식

이를 통해 기존의 “정해진 시나리오 알림 봇”을 넘어, 필요할 때 질문하고 바로 답을 얻는 Agent Tool로 확장할 수 있었습니다.

2. 마무리

이번 mcp-calendar 프로젝트는 거대한 AI 시스템을 만드는 시도라기보다는, 기존에 존재하던 업무 흐름에 LLM과 Agent 개념을 접목해 ‘사용 방식’을 바꿔본 작은 실험에 가깝습니다.

정해진 시간에 알림을 받는 자동화에서 나아가, 필요할 때 자연어로 질문하고 즉시 답을 얻는 도구로 캘린더를 재구성하면서 LLM의 _의도 해석 능력_과 MCP / Function Calling 기반 _도구 분리 아키텍처_가 실제 업무 효율에 어떻게 기여할 수 있는지를 직접 확인할 수 있었습니다.

비록 규모는 크지 않은 프로젝트였지만, LLM을 단순 응답 생성이 아닌 ‘도구 선택자’로 활용한 경험, 도메인 기능을 Agent Tool로 분리·재사용 가능하게 설계한 경험, Slack, IDE, Agent 등 다양한 실행 환경을 고려한 인터페이스 설계 경험 을 통해, AI 도구를 활용한 업무 효율화 및 기능 구현 관점에서 의미 있는 성과를 만들 수 있었습니다.

앞으로도 이와 같은 방식으로 “AI를 도입하는 것”이 아니라, “업무 흐름 속에서 자연스럽게 쓰이게 만드는 것” 에 초점을 둔 작은 실험들을 계속 이어가고자 합니다.

🔗 관련 링크

📘 과거 글

사내 휴가자 및 일정 알림 봇 만들기 (Slack & MatterMost + Google Apps Script)
🧩 개선 프로젝트

mcp-calendar (GitHub)