지금까지 MCP, A2A, OpenClaw, Ollama 같은 개념을 하나씩 살펴봤다.
각각을 따로 보면 이런 느낌이었다.
MCP = AI가 외부 도구를 사용하는 방식
A2A = AI 에이전트끼리 협업하는 방식
OpenClaw = AI 에이전트를 실행하고 메시징 앱과 연결하는 플랫폼
Ollama = 로컬에서 LLM을 실행하는 런타임
그런데 이제는 이 개념들을 따로 보는 것보다,
하나의 서비스 안에서 어떻게 배치할지를 생각해야 한다.
내가 만들고 싶은 앱은 대략 이런 형태다.
토스증권 Open API를 통해 내 투자 정보를 가져오고,
OpenClaw와 Ollama를 이용해서 AI가 주기적으로 나에게 요약 메시지를 보내주는 앱
즉, 단순히 질문하면 답하는 챗봇이 아니라, 내 투자 정보를 확인하고, 필요할 때 먼저 알려주는 AI 비서에 가깝다.
가장 단순하게 표현하면 이런 구조를 생각할 수 있다.
사용자
↓
OpenClaw
↓
Ollama
↓
Toss Tool Server / MCP Server
↓
토스증권 Open API
↓
Toss Tool Server / MCP Server
↓
Ollama
↓
OpenClaw
↓
사용자
처음 보면 조금 길어 보이지만, 역할을 나누면 꽤 명확하다.
| 구성요소 | 역할 |
|---|---|
| 사용자 | AI에게 요청하거나 알림을 받는 사람 |
| OpenClaw | 사용자와 AI를 연결하는 입구 |
| Ollama | 로컬에서 실행되는 LLM |
| Toss Tool Server / MCP Server | 토스증권 API를 안전하게 감싸는 중간 서버 |
| 토스증권 Open API | 실제 계좌, 시세, 주문 정보를 제공하는 외부 API |
OpenClaw가 토스증권 API를 바로 호출하면 더 간단하지 않나?
금융 API를 다룰 때는 간단함보다 안전한 책임 분리가 더 중요하다. 토스증권 API를 호출하려면 인증 정보가 필요하다.
API Key
Client Secret
Access Token
Refresh Token
계좌 식별 정보
이런 값들을 OpenClaw나 Ollama 쪽에 직접 넣어두는 건 위험하다.
OpenClaw는 에이전트 실행 환경이고, Ollama는 로컬 LLM을 돌리는 런타임이다. 둘 다 금융 API의 권한 검증, 토큰 관리, 주문 제한, 로그 저장을 책임지는 계층은 아니다. 그래서 중간에 Toss Tool Server를 둔다.