SW/인공지능

Ollama로 로컬 LLM 에이전트 만드는 법: MCP와 Zapier 연동까지 한 번에 정리

얇은생각 2026. 5. 3. 07:30

Ollama, MCP, Zapier로 로컬 LLM 에이전트 구축하기 — 무료로 시작하고, 프라이버시를 지키면서, 실무에도 쓸 수 있게

로컬 언어 모델을 돌리는 것과 실제로 일을 해내는 로컬 AI 에이전트를 만드는 것은 완전히 다른 이야기입니다.

로컬 모델은 대화할 수 있습니다. 요약도 할 수 있고, 글도 쓸 수 있습니다. 여기까지도 충분히 유용하죠. 하지만 분명한 한계가 있습니다.

반면 로컬 AI 에이전트는 한 단계 더 나아갑니다. Notion 워크스페이스를 뒤지고, 캘린더를 확인하고, 일정을 만들고, 연결된 도구에서 데이터를 가져오고, 사용자를 대신해 작업까지 수행할 수 있습니다. 게다가 이 모든 과정이 내 컴퓨터 안에서, 내 통제 아래 돌아갑니다.

바로 이 지점이 핵심입니다.

그리고 2026년 기준으로 많은 사람들에게 가장 매력적인 균형점도 여기에 있습니다. 클라우드급 활용성과 로컬 중심의 통제력을 동시에 얻는 구성이기 때문입니다.

LLM이 두뇌라면, 에이전트는 두뇌에 손발이 달린 시스템입니다.

이 글에서는 다음 구성으로 그 흐름을 차근차근 설명합니다.

로컬 추론 엔진으로 Ollama
Qwen 3.5 같은 tool calling 지원 모델
외부 서비스 연동을 위한 Zapier MCP 서버
Ollama가 MCP를 기본 지원하지 않기 때문에 필요한 MCP client bridge
터미널을 넘어 실제 제품 코드까지 확장하고 싶을 때 사용할 수 있는 LangChain 같은 오케스트레이션 도구

이 조합을 쓰면 무료로 시작할 수 있고, 프라이버시 친화적이며, Google 서비스, Notion, Meta 계열 도구, 캘린더 등 수천 개의 외부 도구와 상호작용할 수 있는 로컬 AI 스택을 만들 수 있습니다.

보호막 안의 노트북이 여러 업무 도구 아이콘과 연결된 로컬 AI 에이전트 개념 이미지

왜 이 구성이 중요한가

로컬 AI에 대한 관심은 단순한 유행이 아닙니다. 꽤 현실적인 세 가지 이유가 있습니다.

1. 클라우드 비용은 생각보다 빨리 불어납니다

고성능 호스팅 모델에 의존하면 사용량이 누적될수록 비용도 빠르게 커집니다. 특히 아래 같은 흐름이 많아질수록 더 그렇습니다.

반복적인 프롬프트 호출
외부 API 호출
자동화 작업
여러 단계를 거치는 에이전트 실행

로컬 구성을 쓰면 이 계산식이 바뀝니다. 더 이상 토큰마다 같은 방식으로 비용을 내는 구조가 아니기 때문입니다. 결국 내 하드웨어를 활용하는 방식으로 넘어가게 됩니다.

2. 프라이버시는 이제 선택 옵션이 아닙니다

AI가 다음 데이터를 다루기 시작하면 이야기가 달라집니다.

사내 문서
개인 메모
캘린더
광고 데이터
고객 정보
여행 기록
업무 자동화 흐름

이쯤 되면 프라이버시는 더 이상 추상적인 가치가 아닙니다. 운영과 보안의 문제로 바뀝니다.

모델을 내 컴퓨터에서 직접 돌리면, 연산이 어디서 이뤄지는지와 데이터가 어떤 경로로 노출되는지에 대해 훨씬 강한 통제권을 가질 수 있습니다.

3. 통제력 자체가 기능입니다

로컬 스택에서는 다음을 직접 결정할 수 있습니다.

어떤 모델을 돌릴지
어떤 버전을 쓸지
메모리를 얼마나 쓸지
어떤 외부 도구를 노출할지
어떤 권한을 줄지
자동 실행할지, 승인 후 실행할지

이 정도 수준의 통제권은 쉽게 대체하기 어렵습니다.

로컬 AI는 대개 클라우드보다 느립니다. 하지만 중요한 것은 속도만이 아닙니다. 통제력 자체가 강력한 기능입니다.

먼저 이해해야 할 핵심: LLM과 에이전트의 차이

이 부분에서 많이 헷갈립니다.

LLM은 실제로 무엇을 하는가

대형 언어 모델은 본질적으로 다음 토큰을 예측하는 엔진입니다. 입력을 읽고, 그에 맞는 출력을 생성하죠. 그래서 다음 같은 일들을 할 수 있습니다.

대화
설명
요약
초안 작성
텍스트 기반 추론
시스템에 따라 이미지, 코드, 멀티모달 결과 생성

하지만 LLM만으로는 바깥세상에서 실제로 뭔가를 “실행”하지 못합니다.

외부 도구가 전혀 연결되지 않은 기본 모델은 결국 텍스트만 돌려줄 수 있습니다.

이건 로컬 모델이든 클라우드 모델이든 마찬가지입니다. 상용 AI 서비스도 도구가 붙지 않으면 진짜 실무 능력은 제한적입니다.

무엇이 AI 에이전트를 만드는가

모델에 행동 수단이 붙는 순간 에이전트가 됩니다.

즉, 모델이 다음을 할 수 있어야 합니다.

어떤 도구를 써야 할지 고르고
올바른 인자를 넘기고
도구를 호출하고
결과를 읽고
다음 행동을 결정하고
답변을 반환하거나 다음 작업을 이어가는 것

쉽게 말해, LLM은 텍스트 안에서 생각합니다. 에이전트는 생각하고, 행동합니다.

가장 이해하기 쉬운 비유는 이렇습니다.

LLM은 두뇌
도구는 손
에이전트는 둘을 결합한 전체 시스템

그래서 목표가 실제 자동화라면 로컬 모델만으로는 부족합니다.

순수 로컬 모델은 챗봇입니다.
도구가 연결된 로컬 모델은 워크플로 엔진이 됩니다.

필요한 전체 스택

이 구성을 제대로 만들려면 핵심적으로 세 가지 계층이 필요합니다.

1. 로컬 추론 엔진

모델을 내 컴퓨터에서 실제로 구동하는 계층입니다. 여기서는 Ollama가 이 역할을 맡습니다.

2. tool calling을 지원하는 모델

모든 모델이 도구를 호출할 수 있는 것은 아닙니다. 이 기능이 없으면 제대로 된 에이전트처럼 동작할 수 없습니다.

3. 모델과 외부 서비스를 이어주는 브리지

여기서 MCP가 등장합니다.

MCP는 Model Context Protocol의 약자입니다. 모델이 외부 도구를 발견하고 사용하는 방식을 구조화한 표준 계층이라고 이해하면 됩니다.

이 구성에서는 Zapier MCP 서버가 허브 역할을 합니다. 하나의 연결 지점으로 수천 개의 통합을 노출해 주는 구조입니다.

그런데 여기서 중요한 문제가 하나 있습니다.

Ollama는 MCP를 기본으로 처리하지 않습니다

즉, 한 계층이 더 필요합니다.

4. Ollama용 MCP client bridge

이 브리지는 MCP 서버에 접속해서 사용 가능한 도구를 찾아내고, 그 정보를 Ollama에서 돌아가는 모델에 실시간으로 노출합니다. 쉽게 말해 두 시스템 사이의 번역기이자 프록시 역할을 합니다.

이 브리지가 없으면 모델은 고립된 상태로 남습니다.

반대로 이 브리지가 있으면 로컬 모델이 다음과 같은 서비스에 접근할 수 있습니다.

Notion
Google Calendar
Google 계열 도구
Meta 연동 서비스
Facebook Ads 관련 서비스
그 밖의 Zapier 지원 앱 수천 개

1단계: Ollama 설치와 동작 확인

먼저 Ollama를 설치합니다.

설치가 끝나면 터미널을 엽니다.

macOS: Spotlight에서 Terminal 실행
Windows: PowerShell, cmd, 또는 Windows Terminal 실행

그다음 아래 명령으로 Ollama가 정상적으로 잡히는지 확인합니다.

ollama

처음 사용하는 환경이라면 Ollama 애플리케이션 자체가 백그라운드에서 돌아가고 있는지 확인해야 할 수 있습니다. 어떤 시스템에서는 앱을 한 번 직접 실행해 주면 서비스가 제대로 초기화됩니다.

최신 버전에서는 처음 실행 시 온보딩 형태의 화면이 보일 수도 있습니다. 그런 경우에는 다시 터미널 흐름으로 돌아와 모델 설정을 진행하면 됩니다.

이 단계의 목표는 단순합니다. 명령줄에서 Ollama가 문제 없이 실행되는지 확인하는 것입니다.

2단계: 내 환경에 맞는 로컬 모델 고르기

이 전체 과정에서 가장 중요한 의사결정은 바로 여기입니다.

모델 선택이 멋져 보여서 중요한 게 아닙니다. 잘못 고른 모델 하나가 전체 경험을 못 쓸 정도로 느리게 만들어버릴 수 있기 때문입니다.

무엇을 봐야 하나

Ollama에서 모델을 볼 때 단순히 인기 모델만 고르지 마세요. 아래 기준으로 하나씩 따져봐야 합니다.

tool calling 지원 여부
파라미터 크기
다운로드 크기
RAM 또는 VRAM 사용량
내 장비에서의 실제 응답 속도

특히 마지막 항목이 생각보다 훨씬 중요합니다.

기술적으로 실행된다고 해서 실무에서 쓸 수 있는 것은 아닙니다.

로컬 모델의 현실

저장 공간만 충분하면 꽤 큰 모델도 실행은 됩니다. 하지만 **“돌아간다”**와 **“쓸 만하다”**는 전혀 다른 말입니다.

응답 하나에 너무 오래 걸리거나 tool call이 지나치게 느리면, 시스템은 금방 답답한 장난감이 됩니다.

그래서 모델 선택은 “가장 큰 모델이냐”가 아니라, 내 환경에 맞느냐가 핵심입니다.

가장 좋은 로컬 모델은 가장 큰 모델이 아닙니다. 내 하드웨어가 무리 없이 감당할 수 있는 가장 큰 모델입니다.

3단계: 하드웨어 규칙 먼저 이해하기

간단하게 정리해 보겠습니다.

Windows나 Linux를 쓰는 경우

이쪽은 대개 GPU VRAM 중심으로 봐야 합니다.

예를 들어 RTX 4090은 24GB VRAM을 갖고 있고, 모델은 그 대부분을 활용할 수 있습니다. 실제로 많은 Windows 환경에서는 시스템 RAM보다 그래픽카드 메모리가 더 중요한 제약 조건이 됩니다.

만약 전용 GPU가 없다면 로컬 모델 실행 자체는 가능할 수 있습니다. 하지만 성능은 극단적으로 느려질 수 있습니다.

조금 불편한 수준이 아닙니다.
응답 하나에 몇 분, 심하면 몇 시간도 걸릴 수 있는 수준입니다.

즉, CPU만으로도 이론상 가능하긴 합니다. 하지만 실무 워크플로를 그 위에 얹는 것은 추천하기 어렵습니다.

4단계: 모델 크기를 내 장비에 맞추기

모델 크기는 보통 파라미터 수와 함께 커집니다.

대표적인 모델 크기 예시는 다음과 같습니다.

0.8B
2B
4B
9B
27B
35B
122B급 대형 모델

파라미터가 많아지면 보통 다음 장점이 생깁니다.

더 나은 추론
더 풍부한 응답
전반적인 성능 향상

하지만 동시에 다음 비용도 같이 따라옵니다.

더 많은 저장 공간
더 큰 메모리 사용량
더 느린 추론
더 긴 대기 시간

구체적인 예시

122B급 모델은 효율적으로 돌리려면 대략 81GB 수준의 메모리가 필요할 수 있습니다.

그러면 32GB unified memory 장비에서는 사실상 비현실적입니다.

반면 35B나 27B는 조건에 따라 도전해볼 수 있습니다. 다만 여기서도 실제 결과는 장비와 상황에 따라 달라집니다.

예를 들어 32GB unified memory를 탑재한 M2 Max MacBook 기준으로 보면:

35B 모델은 기술적으로는 실행되지만, 실사용에는 너무 느렸고
27B 모델은 훨씬 다루기 쉬웠으며
35B는 대략 24GB 수준의 메모리 사용
27B는 대략 17GB 수준에 가까운 체감이었습니다

이런 식의 판단은 결국 직접 테스트해야 알 수 있습니다.

욕심보다 현실부터

많은 사용자에게는 9B급 모델이 가장 현실적인 출발점입니다.

최상위 클라우드 모델보다 잘하느냐고 묻는다면, 그렇지는 않습니다.

하지만 기본적인 자동화, 구조화된 검색, 가벼운 에이전트 워크플로를 처리할 수 있느냐고 묻는다면, 충분히 가능하고 실제로 꽤 유용합니다.

하드웨어가 좋을수록 더 큰 모델을 노릴 수 있습니다. 다만 반응성 좋은 로컬 에이전트가 목표라면, 처음에는 작은 모델로 빠르게 시작하는 편이 훨씬 현명할 때가 많습니다.

5단계: 모델이 tool calling을 지원하는지 반드시 확인하기

이건 선택 사항이 아닙니다.

Notion, Google Calendar, 기타 외부 서비스와 연결하는 것이 목표라면 모델이 반드시 tool calling을 지원해야 합니다.

일부 구형 모델이나 에이전트 지향성이 약한 모델은 챗봇으로는 잘 동작하지만, tool calling 기능이 드러나지 않을 수 있습니다. 이런 경우 대화는 할 수 있어도, 정작 필요한 에이전트 레이어를 만들 수는 없습니다.

유력한 선택지: Qwen 3.5

이 구성에서 실용적인 선택지로 볼 수 있는 모델 계열이 Qwen 3.5입니다. 비교적 최신이고, 도구 사용 능력을 염두에 둔 모델군으로 보기 좋습니다.

좀 더 가볍게 가고 싶다면 Qwen coder next 같은 변형도 매력적일 수 있습니다. 상대적으로 낮은 사양에서도 시도해볼 수 있기 때문입니다.

핵심은 “정답 모델이 하나뿐”이라는 뜻이 아닙니다.
내가 필요한 동작을 명시적으로 지원하는 모델을 골라야 한다는 뜻입니다.

6단계: 모델 다운로드 후 실제로 테스트하기

모델을 골랐다면 로컬로 내려받습니다.

예시:

ollama pull qwen3.5:35b

이 정도 크기의 모델은 다운로드 용량도 큽니다. 예를 들어 35B 기준으로는 약 23GB 정도가 될 수 있습니다.

다운로드가 끝났다면 실행합니다.

ollama run qwen3.5:35b

그다음 간단한 프롬프트를 넣고 응답 속도를 확인하세요.

바로 이 지점에서 이론과 현실이 만납니다.

여기서 확인해야 하는 것은 단순히 “답이 나오느냐”가 아닙니다.

로딩에 얼마나 걸리는지
토큰이 어느 정도 속도로 출력되는지
하드웨어가 얼마나 버거워하는지
실제 사용에서 지연이 감당 가능한 수준인지

너무 느리다면?

과감하게 한 단계 내려가면 됩니다.

실제로 이런 경우가 자주 생깁니다. 35B 모델이 종이 위에서는 매력적으로 보여도, 실제로는 27B가 훨씬 낫다는 판단이 나올 수 있습니다.

이건 실패가 아닙니다.
튜닝입니다.

또 하나, 장비가 다른 작업을 동시에 하고 있을 수 있다는 점도 잊지 마세요. 녹화, 편집, 브라우징, 백그라운드 프로세스는 로컬 추론 성능에 꽤 큰 영향을 줍니다.

그러니 실제 사용하는 환경과 비슷한 조건에서 테스트하는 것이 중요합니다.

7단계: Zapier MCP 서버로 외부 도구 연결하기

이제부터가 진짜 흥미로운 구간입니다.

로컬 모델이 외부 서비스와 상호작용하게 만들려면 Zapier MCP 서버를 사용할 수 있습니다.

왜 Zapier인가

이유는 간단합니다. 8,000개 이상의 통합을 하나의 허브로 묶어주기 때문입니다.

즉, 서비스마다 로컬 모델과 개별 연결을 만들 필요가 없습니다. MCP 서버 하나를 연결하고, 그 서버가 도구들을 노출하게 만들면 됩니다.

구조가 훨씬 깔끔해집니다.

과금과 무료 사용 범위

이 구성은 무료로 시작할 수 있습니다. 사용량이 크게 늘어나면 유료 플랜이 필요할 수는 있습니다.

중요한 것은 MCP를 통해 발생하는 활동이 Zapier의 task 모델과 연결된다는 점입니다. 쉽게 말해 MCP 서버를 쓰는 작업이 Zapier 플랜 안의 액션처럼 계산될 수 있습니다.

그래도 초기 실험이나 중간 정도의 개인 워크플로에서는 충분히 현실적인 범위입니다.

8단계: MCP 서버 생성하고 도구 연결하기

Zapier 안에서 새 MCP 서버를 만듭니다.

에이전트 유형을 고를 때는 다음을 선택하면 됩니다.

Other

Ollama처럼 사전 정의된 에이전트 환경이 아닌 경우 가장 유연하게 쓸 수 있는 선택지입니다.

그다음 필요한 도구를 연결해 나가면 됩니다.

첫 테스트로 좋은 선택: Notion

Notion은 초반 테스트용으로 아주 좋습니다. 결과가 눈으로 검증하기 쉽기 때문입니다.

할 수 있는 일은 다음과 같습니다.

OAuth로 Notion 계정을 연결하고
특정 페이지 또는 페이지 그룹만 선택하고
모델이 접근할 수 있는 문서를 제한하는 것

예를 들어 아래 같은 범위만 노출할 수 있습니다.

개인 페이지
세컨드 채널 페이지
2025년 12월 여행 계획 관련 페이지

이렇게 해 두면 워크스페이스 전체를 열지 않고도, 검색과 요약에 필요한 정보만 에이전트에 제공할 수 있습니다.

또 다른 좋은 테스트: Google Calendar

Google Calendar는 실행형 워크플로 검증에 아주 적합합니다.

다음 두 가지를 모두 시험할 수 있기 때문입니다.

일정 조회 같은 읽기 작업
새 일정 생성 같은 쓰기 작업

더 넓게 확장할 수도 있습니다

원한다면 더 많은 서비스를 연결할 수 있습니다.

통합 카탈로그가 워낙 넓어서 Meta 관련 도구나 다양한 비즈니스 시스템도 검색해 연결할 수 있습니다.

다만 초반에는 많이 붙인다고 좋은 게 아닙니다.

처음에는 검증하기 쉬운 두 가지 서비스부터 시작하는 편이 좋습니다.

9단계: MCP 토큰 URL 생성하고 안전하게 보관하기

도구 연결이 끝났다면 MCP 설정의 Connect 영역으로 가서 새 토큰을 생성합니다.

그러면 토큰이 포함된 URL이 발급됩니다.

중요한 건 이 전체 URL입니다.

나중에 Ollama 쪽 MCP client bridge가 이 URL을 통해 접속하게 됩니다.

이 URL은 사실상 비밀 키처럼 다뤄야 합니다.

공개된 곳에 붙여넣지 마세요.
가볍게 공유하지도 마세요.
안전한 곳에 보관해야 합니다.

일부 도구 체인에서는 Authorization header를 쓰는 좀 더 표준적인 MCP 구성도 지원할 수 있습니다. 그래도 이 구성에서는 토큰이 포함된 URL 형태가 가장 실용적인 연결 방식입니다.

10단계: Ollama용 MCP 브리지 설치하기

여기서 구조적인 문제가 다시 등장합니다.

Zapier MCP 서버는 도구를 노출하고
Ollama는 모델을 실행하지만
Ollama는 MCP를 기본적으로 이해하지 못합니다

그래서 중간 브리지가 필요합니다.

이 브리지는 다음 역할을 합니다.

MCP 서버에 접속하고
노출된 도구를 찾아내고
그 도구를 로컬 모델에 노출하고
tool call을 중계하고
결과를 다시 모델의 추론 루프로 돌려보내는 것

설치 방식

이런 브리지는 보통 Python 기반 CLI 도구 형태로 배포되고, 설치는 pip로 하는 경우가 가장 단순합니다.

패키지 이름과 실행 명령은 구현체마다 다를 수 있지만, 실질적인 흐름은 대체로 아래와 비슷합니다.

pip install --upgrade <ollama-mcp-client-package>

물론 먼저 Python이 설치되어 있어야 합니다.

설치가 끝나면 보통 터미널에서 실행할 수 있습니다.

구현체에 따라 다음 같은 옵션도 지원합니다.

auto discovery
host 지정
버전 지정
사용할 모델 명시
MCP 서버 URL 명시

11단계: MCP 브리지를 통해 모델 실행하기

핵심 실행 패턴은 아래와 같습니다.

<ollama-mcp-client> --mcp-server-url "<your-tokenized-server-url>" --model qwen3.5:27b

이 명령은 두 가지를 동시에 해 줍니다.

브리지에게 어떤 MCP 서버에 연결할지 알려주고
어떤 로컬 모델을 Ollama를 통해 돌릴지 알려줍니다

원한다면 여러 MCP 서버를 동시에 붙일 수도 있습니다. 하지만 Zapier를 중앙 허브로 쓴다면 하나만으로도 충분한 경우가 많습니다. 이미 수많은 통합을 한 번에 모아주기 때문입니다.

왜 따옴표가 중요한가

서버 URL은 하나의 인자로 정확히 전달되어야 합니다. 그래서 보통 따옴표로 감싸는 것이 안전합니다.

이렇게 해야 파싱 문제가 줄고, 토큰이 포함된 전체 URL이 정확히 전달됩니다.

12단계: 세션과 노출된 도구 확인하기

브리지가 성공적으로 연결되면, 연결된 도구에 접근할 수 있다는 정보를 보여줄 것입니다.

많은 브리지 구현은 다음 같은 상호작용 기능을 제공합니다.

사용 가능한 도구 목록 보기
reasoning 또는 thinking 표시 전환
metrics 확인
세션 상태 점검

어떤 흐름에서는 도구 목록을 열어보고, 확인한 뒤 Q 같은 키로 다시 세션으로 돌아올 수도 있습니다.

정확한 조작 방식은 구현체마다 다르지만, 핵심은 같습니다. 실제 요청을 보내기 전에 Notion과 Calendar 도구가 제대로 보이는지 확인하는 것입니다.

이 확인이 중요한 이유는 명확합니다.
이제 로컬 모델이 더 이상 고립된 챗봇이 아니라, 실제로 행동할 수 있는 도구 레이어를 가진 시스템이라는 뜻이기 때문입니다.

13단계: 읽기 작업부터 실제로 테스트하기

첫 테스트 프롬프트는 현실적이고 검증하기 쉬운 것이 좋습니다.

예를 들면 이런 식입니다.

“내 Notion 문서를 바탕으로 지난 1년 동안 어디를 여행했는지 알려줘.”

이건 아주 좋은 에이전트 테스트입니다. 시스템이 다음을 모두 해야 하기 때문입니다.

사용자의 요청을 해석하고
Notion이 관련 도구라는 것을 판단하고
맞는 페이지를 검색하고
유용한 내용을 추출하고
최종 답을 종합하는 것

실제로는 어떤 일이 일어나나

도구 실행 전에 승인 요청이 뜰 수 있습니다.

이건 좋은 신호입니다. 보안상 매우 중요한 장치이기 때문입니다.

승인하면 브리지가 tool call을 전달하고, Notion이 조회되고, 결과가 다시 모델로 들어갑니다.

실제 예시에서는 2025년 12월의 여행 관련 문서에서 다음 정보들이 추출되었습니다.

방문한 여행지
항공편 정보
문서 안에 들어 있던 기타 여행 관련 내용

즉각적으로 끝나지는 않을 수 있습니다. tool call이 여러 번 일어나면 그만큼 지연도 늘어납니다.

하지만 여기서 중요한 건 속도보다 결과의 성격입니다.
로컬 모델이 여행 내용을 지어낸 게 아니라, 실제로 Notion 문서에 들어가서 데이터를 가져왔다는 점입니다.

이건 유용성의 차원이 완전히 다릅니다.

14단계: 이제 쓰기 작업도 테스트하기

다음으로는 외부 시스템의 상태를 바꾸는 작업을 시험해 봅니다.

예를 들면 이런 요청입니다.

“오늘 오후 4시부터 5시까지 ‘eat lunch’라는 이름으로 캘린더 일정을 만들어줘.”

구성이 제대로 되어 있다면 모델은 Calendar 도구를 호출해서 이벤트를 만들 수 있어야 합니다.

현실적인 변수: 시간대

여기서부터 에이전트의 실제 난점이 드러납니다.

한 사례에서는 이벤트가 생성되긴 했지만, 오후 4시~5시가 아니라 오전 4시~5시로 보였습니다.

이런 불일치는 보통 두 가지 이유에서 생깁니다.

모델이나 도구가 잘못된 시간을 넘겼거나
캘린더와 사용자가 서로 다른 시간대를 기준으로 움직이고 있거나

예를 들어 캘린더는 미국 동부 시간으로 설정되어 있고, 사용자는 물리적으로 12시간 앞선 지역에 있을 수 있습니다. 그러면 캘린더 기준으로는 맞게 들어갔더라도, 사용자의 눈에는 엉뚱한 시간처럼 보일 수 있습니다.

이건 로컬 에이전트 설계에서 정말 중요한 포인트입니다.

캘린더에 쓰기 작업을 시킬 때는 시간대 동작을 반드시 명시적으로 검증해야 합니다.

이벤트가 생성됐다고 해서 바로 안심하면 안 됩니다.

15단계: 터미널에서 코드로 확장하기

터미널 흐름이 안정적으로 돌아가기 시작하면, 같은 구조를 애플리케이션 코드로 옮길 수 있습니다.

이게 중요한 이유는 분명합니다. 로컬 에이전트의 장기적인 가치는 단순한 CLI 데모에 있지 않습니다. 제품, 비서, 내부 도구, 자동화 시스템 안으로 들어갈 수 있어야 진짜 가치가 생깁니다.

왜 가능한가

Ollama는 REST API 서버를 노출합니다.

즉, 코드에서 일반적인 추론 제공자를 붙이듯이 로컬 모델과 프로그램적으로 연결할 수 있습니다.

그리고 그 위에 LangChain 같은 오케스트레이션 프레임워크를 얹을 수 있습니다.

전형적인 코드 레벨 구성

상위 수준의 흐름은 대략 이렇습니다.

코드 안에 Zapier MCP 서버 URL을 정의하고
MCP client를 만들고
사용 가능한 도구를 가져오고
ReAct 스타일 에이전트를 생성하고
그 에이전트를 Ollama 모델 백엔드와 연결하고
자연어 요청을 보내 구조화된 tool 사용 결과를 받는 방식입니다

Python 기준으로는 다음 같은 패키지를 조합할 수 있습니다.

LangChain MCP adapters
langchain-ollama
langgraph

이 라이브러리들은 편한 추상화 계층일 뿐, 유일한 방법은 아닙니다.

직접 제어권을 더 원한다면 아래처럼 더 낮은 수준에서 구현해도 됩니다.

Ollama의 HTTP 인터페이스 직접 호출
MCP 서버 직접 호출
자체 에이전트 오케스트레이션 로직 구현

즉, 이 아키텍처는 Python에만 묶여 있지 않습니다. HTTP와 tool calling 패턴을 다룰 수 있는 언어라면 다른 환경에서도 같은 개념을 재현할 수 있습니다.

실전 코드 예시: 앞으로 5일간의 캘린더 일정 가져오기

코드 레벨 검증에 좋은 프롬프트는 이런 형태입니다.

“앞으로 5일 동안 내 캘린더 일정이 뭐야?”

이 요청도 같은 에이전트 루프를 검증합니다.

요청 이해
Calendar 도구 식별
도구 호출
데이터 가져오기
결과 요약

실제로는 응답이 다소 느릴 수 있습니다. 로컬 추론에 tool orchestration까지 얹는다고 해서 갑자기 모든 것이 마법처럼 빨라지지는 않기 때문입니다.

하지만 반환된 회의 목록과 일정 요약이 실제 캘린더 내용과 맞아떨어진다면, 그건 꽤 탄탄한 기반이 있다는 뜻입니다.

중요한 기준은 화려함이 아닙니다.
신뢰할 수 있느냐입니다.

그리고 이걸 제품 안에서 쓸 계획이라면 일정 정보가 민감한 데이터를 포함할 수 있다는 점도 꼭 기억해야 합니다. 로그, 데모 화면, UI 미리보기, 녹화본에서는 필요한 범위만 마스킹하거나 가려주는 것이 좋습니다.

받아들여야 할 현실적인 트레이드오프

로컬 AI 에이전트는 강력합니다. 하지만 마찰이 없는 기술은 아닙니다.

솔직하게 정리해 보겠습니다.

1. 클라우드보다 느립니다

대체로 그렇습니다. 때로는 꽤 많이 느립니다.

모델 자체가 시간을 쓰고, tool call이 시간을 더 먹고, 여러 단계가 겹치면 지연은 더 커집니다.

가장 빠른 경험이 목표라면 아직은 호스팅 시스템이 유리한 경우가 많습니다.

2. 하드웨어 영향이 매우 큽니다

최신 Mac의 unified memory 환경과, 전용 GPU가 없는 보급형 Windows 노트북은 체감이 완전히 다릅니다.

같은 구조라도 어느 장비에서는 매끈하고, 어느 장비에서는 답답할 수 있습니다.

3. 큰 모델이 항상 정답은 아닙니다

거의 응답하지 않는 35B 모델보다, 실제로 일을 처리하는 9B 모델이 더 낫습니다.

4. 브리지 계층이 복잡성을 늘립니다

Ollama가 MCP를 기본 지원하지 않기 때문에, 중간 도구 하나에 더 의존하게 됩니다.

관리 가능한 수준이긴 하지만, 분명히 움직이는 부품이 하나 더 생깁니다.

5. 권한 범위가 너무 넓어질 수 있습니다

수천 개의 앱을 지원하는 허브가 있다 보면, 이것저것 한꺼번에 연결하고 싶은 마음이 듭니다.

하지만 보안 관점에서는 처음부터 좁게 시작하는 게 맞습니다.

필요한 도구만 노출하고
문서 범위를 제한하고
가능하면 테스트 계정을 쓰고
민감한 작업에는 사람 승인 단계를 유지하는 편이 안전합니다

더 안정적인 로컬 에이전트를 위한 실전 팁

실험용을 넘어 실제로 “쓸 만한” 스택으로 만들고 싶다면 아래 습관이 도움이 됩니다.

처음에는 작은 모델부터 시작하세요

9B 정도나, 내 장비가 편하게 돌릴 수 있는 모델부터 시작하세요. 먼저 워크플로가 성립하는지 증명하고, 그다음 키워도 늦지 않습니다.

결과를 검증하기 쉬운 도구를 고르세요

Notion과 Google Calendar는 검증이 아주 쉽습니다. 결과가 맞는지 바로 확인할 수 있기 때문입니다.

쓰기 작업보다 읽기 작업부터 테스트하세요

먼저 이런 것부터 해 보세요.

“내 여행 메모 찾아줘”
“이번 주 회의 목록 보여줘”

그다음 이런 작업으로 넘어가면 됩니다.

“일정 하나 만들어줘”
“레코드 업데이트해줘”
“자동화 실행해줘”

시간대는 의도적으로 점검하세요

특히 캘린더 작업에서는 필수입니다.

권한은 공격적으로 줄이세요

정말 필요한 페이지, 캘린더, 서비스만 노출하는 편이 좋습니다.

토큰 URL은 비밀번호처럼 다루세요

기능적으로 사실상 그렇게 동작합니다.

“똑똑함”보다 “쓸모”를 측정하세요

물어야 할 질문은 “이 모델이 얼마나 똑똑하냐”가 아닙니다.

더 좋은 질문은 이것입니다.

“이 에이전트가 내가 원하는 작업을, 허용 가능한 속도와 정확도로 끝낼 수 있는가?”

바로 그 지점에서 로컬 AI 시스템의 가치가 결정됩니다.

이 구성이 로컬 AI의 미래에 의미하는 것

이건 단순한 취미용 실험을 조금 넘어서는 구조입니다.

사실상 local-first AI 아키텍처의 형태를 보여줍니다.

모델은 내 장비에서 돌고
민감한 데이터는 내 통제 아래 남아 있고
외부 도구는 필요할 때만 연결되고
추론은 로컬에서 이뤄지고
행동은 제한된 권한 범위 안에서 실행되는 구조입니다

이 구조는 다음 가능성을 열어줍니다.

프라이빗 AI 비서
사내 엔터프라이즈 코파일럿
로컬 지식 검색 시스템
캘린더 및 작업 자동화
문서 인식형 에이전트
로컬 추론 기반 개발자 도구
핵심 지능 계층을 완전히 외부에 맡기지 않는 AI 제품

그리고 이 구조의 가장 멋진 점은 분명합니다.
거대한 플랫폼 하나가 모든 것을 허용해 줄 때까지 기다릴 필요가 없다는 것입니다.

직접 조립할 수 있습니다.

AI의 가장 중요한 변화는 단순히 모델이 더 좋아지는 데 있지 않습니다. 모델이 어디서 돌아가고, 무엇에 접근하며, 최종 통제권을 누가 갖는지를 더 잘 통제할 수 있게 되는 데 있습니다.

빠르게 정리하면

외부 도구와 실제로 상호작용할 수 있는 로컬 LLM 에이전트를 만들고 싶다면 핵심 레시피는 단순합니다.

Ollama로 모델을 로컬에서 실행하고
tool calling을 지원하는 모델을 고르고
내 RAM 또는 VRAM 현실에 맞게 모델 크기를 정하고
Zapier MCP 서버로 외부 통합을 노출하고
MCP client bridge로 Ollama와 MCP 서버를 연결하고
Notion 검색이나 Google Calendar 작업 같은 실제 시나리오로 테스트하고
이후에는 LangChain이나 직접 구현한 API orchestration으로 코드까지 확장하는 방식입니다

이렇게 하면 “로컬 모델을 돌릴 수 있다”는 상태에서,
“실제로 유용한 일을 하는 프라이빗 로컬 에이전트가 있다”는 상태로 넘어갈 수 있습니다.

그리고 그 차이는 생각보다 훨씬 큽니다.

FAQ

1. 로컬 LLM과 로컬 AI 에이전트는 무엇이 다른가요?

로컬 LLM은 텍스트를 생성할 수 있습니다. 반면 로컬 AI 에이전트는 도구를 사용해 문서를 검색하거나, 캘린더를 확인하거나, 일정을 만드는 식의 실제 작업을 수행할 수 있습니다. 즉, 에이전트는 모델 위에 도구 레이어가 얹힌 구조입니다.

2. Ollama만으로 외부 서비스 연동까지 가능한가요?

이 글에서 설명한 방식으로는 바로 되지 않습니다. Ollama는 로컬 추론에는 매우 좋지만, MCP를 기본적으로 처리하지는 않습니다. MCP 서버와 연결하려면 별도의 MCP client bridge가 필요합니다.

3. 왜 tool calling이 그렇게 중요한가요?

tool calling이 없으면 모델은 외부 서비스와 상호작용할 수 없습니다. 결국 텍스트 응답만 돌려줄 수 있게 됩니다. 실제 자동화를 원한다면 tool calling은 필수입니다.

4. 35B 모델이 항상 9B 모델보다 좋은가요?

실전에서는 꼭 그렇지 않습니다. 더 큰 모델이 더 똑똑할 수는 있지만, 내 하드웨어에서 너무 느리면 오히려 덜 유용해집니다. 안정적으로 응답하는 작은 모델이 운영 관점에서는 더 나은 선택일 때가 많습니다.

5. 로컬 에이전트를 제대로 돌리려면 메모리가 얼마나 필요한가요?

모델에 따라 다릅니다. 예시 기준으로는 32GB unified memory를 가진 Mac에서 35B보다는 27B가 훨씬 현실적이었습니다. Windows나 Linux에서는 GPU VRAM이 더 중요한 제약이 되는 경우가 많습니다. 가장 좋은 방법은 직접 테스트하는 것입니다.

6. 처음에는 Notion, Calendar, 그 밖의 도구 중 무엇부터 연결하는 게 좋을까요?

결과를 검증하기 쉬운 도구부터 시작하는 것이 좋습니다. Notion은 검색과 요약 테스트에 좋고, Google Calendar는 읽기와 쓰기 작업을 모두 검증하기 좋습니다. 두 도구 조합이면 초반 테스트로 매우 강력합니다.

7. 외부 도구를 연결해도 이 구성을 프라이빗하다고 볼 수 있나요?

모델 추론이 로컬에서 이뤄진다는 점은 큰 프라이버시 장점입니다. 다만 외부 서비스를 연결하는 순간, 해당 tool call은 결국 그 서비스와 통신하게 됩니다. 즉, 완전한 오프라인 고립과는 다르지만, 전면적인 클라우드 의존 구조보다는 훨씬 통제력이 높다고 볼 수 있습니다.

8. LangChain은 꼭 필요한가요?

필수는 아닙니다. LangChain은 orchestration을 편하게 해 주는 도구일 뿐입니다. 더 가볍고 직접적인 구성을 원한다면 Ollama의 REST API와 MCP 서버를 직접 붙여도 됩니다.

저작자표시 (새창열림)

'SW > 인공지능' 카테고리의 다른 글

MiniMax M2.7 완전 분석: 자기 자신을 개선하는 AI 코딩 모델의 성능과 한계 (0)	2026.05.05
Claude Mythos란 무엇인가: 사이버 보안을 바꿀 프런티어 AI 모델 완전 해설 (0)	2026.05.04
MiniMax M2.7이 주목받는 이유: 자기 다음 모델을 만드는 AI 코딩 모델인가 (0)	2026.05.02
AI 코딩 도구 시대, 개발자는 무엇부터 배워야 할까? 기본기와 학습 우선순위 정리 (0)	2026.05.01
Cursor 3.0이란 무엇인가: Composer 2 논란부터 AI 에이전트 개발 방식 변화까지 (0)	2026.04.30

현재글Ollama로 로컬 LLM 에이전트 만드는 법: MCP와 Zapier 연동까지 한 번에 정리