“오늘 서울 날씨 어때?”에 AI는 뭐라고 답할까
2023년쯤 ChatGPT에게 “오늘 서울 날씨 어때?”라고 물으면 이런 답을 받았다.
“죄송합니다. 저는 실시간 정보에 접근할 수 없어서 오늘 날씨를 알려드릴 수 없습니다. 기상청이나 날씨 앱에서 확인해 주세요.”
물론 맞는 말이다. 모델은 과거 데이터로 학습된 ‘박제된 지식’이고, 실시간 세상과 연결되어 있지 않으니까.
그런데 요즘은 다르다. ChatGPT에게 같은 질문을 하면 실제 서울 날씨를 알려준다. Claude에게 “이 PDF 요약해줘”라고 파일을 올리면 요약해 준다. Cursor는 내 코드를 직접 읽고 수정한다.
같은 AI가, 같은 “다음 토큰 예측” 원리 위에서, 어떻게 이런 일을 하게 됐을까? 답은 ‘외부 세계와 연결하는 기술’이 붙었기 때문이다.
이 글에서는 LLM을 텍스트 생성기에서 ‘일하는 에이전트’로 바꿔주는 기술들을 정리한다. 핵심 용어는 네 가지다. 함수 호출(Function Calling), 도구 사용(Tools), MCP, A2A.

LLM 혼자서는 할 수 없는 것들
‘한 줄 요약: 모델은 학습이 끝난 시점의 지식만 가지고 있다. 실시간 정보나 내 데이터는 별도로 연결해 줘야 한다.’
LLM이 혼자서 할 수 있는 일과 없는 일을 나눠 보면 선명해진다.
| LLM 혼자 할 수 있는 것 | 할 수 없는 것 |
|---|---|
| 학습 시점까지의 일반 지식 답변 | 오늘의 주가, 날씨, 뉴스 |
| 주어진 글에 대한 요약/번역/분석 | 내 이메일 확인, 내 캘린더 일정 조회 |
| 일반적인 코드 작성 | 내 프로젝트 파일 읽기/수정 |
| 수학 개념 설명 | 실제 복잡한 계산 (큰 숫자 곱셈 등) |
오른쪽 열에 있는 일들은 모두 ‘외부 세계’에 정보가 있다. LLM이 이것을 하려면 다리가 필요하다. 그 다리를 놓는 기술이 이 글의 주제다.
함수 호출: AI가 직접 “~해줘”라고 말하게 하기
‘한 줄 요약: AI가 모르는 정보는 “이 함수를 써서 알아봐줘”라고 대신 요청하게 만드는 방법이다.’
가장 기본이 되는 기술은 ‘함수 호출(Function Calling)’이다. 아이디어는 단순하다. AI에게 “쓸 수 있는 도구 목록”을 미리 알려주고, 필요할 때 AI가 직접 “이 도구를 써서 답을 알아줘”라고 요청하게 만드는 것이다.
예시로 날씨 질문을 다시 보자. (아래는 개념 설명용 의사 코드다. 실제 API 메시지 형식은 공급자마다 다르다.)
[1단계] 개발자가 AI에게 사용 가능한 함수를 알려준다.
"getWeather(city, date) 함수가 있어. 도시와 날짜를 넣으면 날씨를 돌려줘."
[2단계] 사용자가 질문한다.
사용자: "오늘 서울 날씨 어때?"
[3단계] AI가 직접 답하는 대신, 함수 호출을 요청한다.
AI: "getWeather('서울', '2026-04-17')을 실행해 줘."
[4단계] 프로그램이 그 함수를 실제로 실행하고 결과를 AI에게 돌려준다.
프로그램 → 날씨 API → 결과: "맑음, 18도"
프로그램: AI에게 결과 전달
[5단계] AI가 결과를 보고 자연스러운 답을 만든다.
AI: "오늘 서울은 맑고 18도예요. 야외 활동하기 좋은 날이네요."
중요한 점은, AI가 함수를 직접 실행하는 게 아니라 ‘함수를 실행해달라고 요청’한다는 것이다. 적어도 ‘커스텀 함수(내가 만든 도구)’ 기준으로는 실제 실행은 내 애플리케이션이 한다.
왜 이렇게 해야 할까? 안전과 통제 때문이다. AI가 마음대로 모든 API를 호출할 수 있다면, 잘못하면 돈을 쓰거나 데이터를 날리거나 이메일을 보내버릴 수 있다. 개발자가 “이 함수만 쓸 수 있어”라고 제한하고, AI의 요청을 검증한 뒤 실행하는 구조가 기본이다.
실행 위치에 대한 주의: 위 설명은 ‘커스텀 함수’ 기준이다. 공급사가 제공하는 ‘내장 도구(built-in tools)’ — 예를 들어 OpenAI/Anthropic/Gemini가 제공하는 웹 검색, 코드 실행, 파일 검색 등 — 는 공급사의 서버 인프라에서 실행된다. 결과만 우리 앱으로 돌아온다. 그래서 “AI가 직접 실행하지 않는다”는 커스텀 함수에 한정된 이야기다.
더 깊이 보기: 실제 wire format은 공급자마다 다르다 (개발자용)
세 주요 공급자 모두 “모델이 구조화된 호출을 내고 → 앱이 실행하고 → 결과를 모델에 되돌린다”는 루프는 공통이지만, 메시지 형식은 다르다.
| 공급자 | 함수 요청 | 함수 결과 |
|---|---|---|
| OpenAI Responses API | function_call output item | function_call_output |
| Anthropic | tool_use 블록 | tool_result 블록 |
| Gemini | functionCall 파트 | functionResponse 파트 |
부르는 이름도 다르다. OpenAI/Gemini는 ‘Function Calling’, Anthropic은 ‘Tool Use’. 개념은 같지만 코드 레벨에서는 각 SDK의 방식을 따라야 한다.
도구(Tools): 함수 호출의 일반화된 개념
‘한 줄 요약: 함수 호출과 거의 같은 말. AI가 쓸 수 있는 모든 외부 기능을 통칭해서 “도구”라고 부른다.’
처음 이 개념이 나왔을 때는 ‘Function Calling(함수 호출)’이라고 불렀지만, 요즘은 ‘Tools(도구)’라는 더 넓은 용어를 쓴다. 왜일까?
함수 하나를 호출하는 것에서 시작해서 점점 기능이 커졌기 때문이다.
| 단계 | 할 수 있는 것 |
|---|---|
| 함수 호출 | 지정된 함수 하나를 호출 |
| 도구 사용 | 웹 검색, 코드 실행, 파일 읽기, 이미지 생성 등 내장 도구 세트 |
| 도구 + 복합 작업 | 여러 도구를 순서대로 조합해서 복잡한 작업 완수 |
예를 들어 요즘 ChatGPT는 질문에 답할 때 ‘웹 검색 도구’나 ‘코드 실행 도구’를 스스로 판단해서 쓴다. 사용자가 “이거 계산해줘”라고 하면 내부적으로 Python 코드 실행 도구를 쓰고, “최신 뉴스 알려줘”라고 하면 웹 검색 도구를 쓰는 식이다. 개발자가 일일이 함수를 정의해주지 않아도, 공급사가 제공하는 내장 도구 세트가 있다.
MCP: 도구·데이터·프롬프트를 표준으로 연결하기
‘한 줄 요약: AI와 외부를 연결할 때 “USB 규격”처럼 표준을 만들어둔 것. 한 번 만들면 여러 AI 앱이 같은 방식으로 쓸 수 있다.’
도구 사용이 일반화되면서 새로운 문제가 생겼다. 각 회사마다 “AI와 외부 시스템을 연결하는 방식”이 달라서, OpenAI용 도구와 Claude용 도구를 따로 만들어야 했다.
이 문제를 풀기 위해 Anthropic이 2024년 11월에 공개한 것이 ‘MCP(Model Context Protocol)’다. 이름은 어렵지만 개념은 간단하다.
“AI 앱이 외부의 도구·데이터·프롬프트를 같은 규격으로 연결하도록 표준을 만들자.”
흔히 “도구 연결 표준”으로만 소개되지만, MCP는 그보다 범위가 넓다. 한 MCP 서버는 세 가지를 노출할 수 있다.
- ‘Tools(도구)’: AI가 호출해서 실행할 수 있는 기능 (파일 쓰기, API 호출 등)
- ‘Resources(자원)’: AI가 읽어서 참고할 수 있는 데이터 (문서, DB 레코드 등)
- ‘Prompts(프롬프트)’: 미리 정의된 프롬프트 템플릿
비유하자면 USB 같은 거다. USB 표준이 생기기 전에는 회사마다 다른 케이블을 썼지만, 표준이 생긴 뒤로는 아무 장치든 아무 컴퓨터에 꽂을 수 있다. MCP가 AI 앱과 외부 세계 사이에 그 역할을 한다.
실제로 쓰는 MCP 서버 예시를 보면 이런 것들이 있다.
- ‘filesystem’: 로컬 파일 읽고 쓰기
- ‘github’: GitHub 저장소 조작
- ‘slack’: Slack 메시지 전송
- ‘postgres’: DB 조회
Claude Desktop, Claude Code, Cursor 같은 앱이 MCP를 지원해서, 원하는 MCP 서버만 설치하면 AI가 해당 기능을 자동으로 쓸 수 있다.
벤더 중립 표준으로 이동 중
MCP는 Anthropic이 시작했지만, 지금은 벤더 중립적인 오픈 표준으로 굳어가고 있다. 2025년 12월에는 Linux Foundation 산하 Agentic AI Foundation에 기부되면서 특정 회사 소유가 아니게 됐다.
주요 AI 회사들이 각자 다른 방식으로 MCP를 채택하고 있다.
- ‘OpenAI’: Responses API에서 remote MCP servers와 connectors를 built-in tool 타입으로 지원
- ‘Anthropic’: Claude Desktop/Code에 로컬 MCP + Messages API에 beta MCP connector
- ‘Google’: Gemini SDK/CLI/ADK에서 MCP 정의와 로컬 MCP 지원, Google Cloud는 managed MCP endpoints 제공 (Gemini API 자체의 remote MCP는 아직 로드맵 단계)
- ‘Microsoft’ 등도 채택 중
정리하면, 2026년 시점의 MCP는 “Anthropic의 것”이 아니라 “업계가 공용으로 쓰는 AI-외부 연결 표준”에 가깝다. 다만 공급자별로 지원 방식과 완성도는 차이가 난다.
더 깊이 보기: MCP의 구조 (개발자용)
MCP는 3층 구조로 동작한다.
[호스트 앱] [MCP 클라이언트] [MCP 서버] Claude Desktop ←→ 내장된 클라이언트 ←→ filesystem 서버 Claude Code ←→ github 서버 Cursor ←→ 내가 만든 도구
호스트 앱(AI 도구)이 MCP 클라이언트를 내장하고, 원하는 MCP 서버를 연결한다. 서버는 tools/resources/prompts를 선언하고, AI가 호출하면 실행하거나 데이터를 돌려준다. 프로토콜은 JSON-RPC 2.0 기반이다.
MCP 서버는 누구나 만들 수 있고, 공식 레지스트리에 공개된 것도 많다. “Claude Code에서 내가 만든 MCP 서버를 연결해서 커스텀 도구를 AI가 쓰게 하기” 같은 것이 흔한 실무 패턴이다.

A2A: AI들끼리 대화하게 하기
‘한 줄 요약: 여러 AI 에이전트가 서로 발견하고 협업하게 만드는 표준. MCP가 AI의 USB면, A2A는 AI의 전화망이다.’
MCP가 ‘AI ↔ 외부 도구’의 표준이라면, ‘A2A(Agent-to-Agent)’는 ‘AI ↔ AI’의 표준이다. Google이 2025년 4월에 발표하고, 같은 해 6월에 Linux Foundation으로 이관해 오픈 표준이 됐다.
왜 필요할까? 최근 AI 에이전트들이 점점 전문화되고 있기 때문이다.
- ‘여행 계획 에이전트’가 있고
- ‘항공권 예약 에이전트’가 있고
- ‘호텔 예약 에이전트’가 있고
- ‘날씨 분석 에이전트’가 있다면
“다음 주 도쿄 여행 계획을 세워줘”라는 요청에 여행 계획 에이전트가 혼자 다 하는 것보다, 항공권/호텔/날씨 에이전트에게 각자 일을 맡기고 결과를 종합하는 게 더 나을 수 있다.
이때 에이전트들이 서로 어떻게 찾고 말을 걸 것인가? A2A가 여기에 표준을 제공한다. 핵심 개념 하나만 소개하면 ‘Agent Card’다. 각 에이전트가 자기가 할 수 있는 일을 JSON 형태로 공개하고, 보통 /.well-known/agent-card.json 같은 표준 URL로 발견된다. 다른 에이전트는 이 카드를 보고 “이 친구에게 이 일을 맡기면 되겠다”를 판단한다.
A2A는 단순 메시지 교환만이 아니라 task, artifact, streaming/async 같은 개념도 포함한다. 2026년 4월 기준 A2A v1.0이 “first stable, production-ready” 단계로 공개되어 있고, 150개 이상 조직이 지지를 표명했다. Google·Microsoft·AWS 플랫폼에 통합되고 있으며 실제 프로덕션 배포 사례도 나오고 있다.
| 프로토콜 | 연결하는 것 | 발표/이관 | 비유 |
|---|---|---|---|
| MCP | AI ↔ 외부 도구·데이터·프롬프트 | Anthropic 2024 → Linux Foundation | AI의 USB |
| A2A | AI ↔ AI 에이전트 | Google 2025 → Linux Foundation | AI의 전화망 |
A2A는 MCP의 경쟁자가 아니라 보완재다. MCP가 에이전트가 도구·데이터를 쓰는 방법을 표준화한다면, A2A는 에이전트끼리 발견하고 협업하는 방법을 표준화한다. 표준 자체는 이미 production-ready 단계지만, 일반 개발자가 체감하는 보급도는 아직 MCP보다 낮은 편이다.
헷갈리기 쉬운 용어의 층위
‘한 줄 요약: 함수 호출 / MCP / A2A / RAG는 같은 레벨이 아니다. 각자 다른 층위의 개념이다.’
이 네 가지는 입문자가 자주 뒤섞는다. 간단히 정리하면 이렇다.
| 개념 | 정체 | 층위 |
|---|---|---|
| 함수 호출 / 도구 사용 | 모델이 외부 기능을 호출하는 ‘방식’ | 모델 API 레벨 |
| MCP | AI 앱에 도구·데이터·프롬프트를 붙이는 ‘연결 규격’ | 통합 표준 레벨 |
| A2A | 에이전트끼리 발견·협업하는 ‘연결 규격’ | 에이전트 협업 레벨 |
| RAG | 검색해서 관련 문서를 찾아 컨텍스트에 넣는 ‘패턴’ | 정보 주입 패턴 |
RAG는 프로토콜 이름이 아니라 ‘검색-주입’이라는 기법의 이름이다. 다음 글에서 자세히 다룬다.
실무 관점: 지금 뭘 쓰게 되나
‘한 줄 요약: 일반 사용자면 ChatGPT/Claude의 내장 도구면 충분, 개발자면 Function Calling + MCP 정도부터 시작하면 된다.’
이 기술들은 계층적으로 쓰인다. 내가 어떤 입장이냐에 따라 신경 쓸 범위가 다르다.
| 입장 | 알아야 할 것 |
|---|---|
| 일반 사용자 | ChatGPT/Claude/Gemini의 내장 도구(웹 검색, 파일 업로드, 코드 실행)를 쓸 줄 알면 충분 |
| 파워 유저 | Claude Desktop/Cursor에 MCP 서버 연결해서 커스텀 도구 추가 |
| 개발자 (간단한 앱) | OpenAI Function Calling이나 Anthropic Tool Use로 내 API 연결 |
| 개발자 (복잡한 에이전트) | MCP로 도구 추상화 + A2A로 에이전트 협업 고려 |
보안과 주의사항
‘한 줄 요약: AI가 외부 도구를 쓸 수 있게 되는 순간, “잘못 말하면 실제 사고가 나는” 세계로 넘어간다.’
외부 세계 연결은 강력하지만 위험도 커진다.
- ‘실수가 현실이 된다’: AI가 환각으로 지어낸 SQL을 그대로 실행하면 DB가 망가진다. 이메일을 잘못 보내면 회수할 수 없다.
- ‘프롬프트 인젝션’: 읽은 문서나 웹페이지에 “너의 권한으로 X를 삭제해”라는 지시가 숨어 있으면 AI가 따라 할 수 있다.
- ‘Confused deputy 문제’: AI가 내 권한을 가지고 있으면 악의적 입력이 AI를 속여 권한 오남용을 유도할 수 있다.
- ‘토큰 전달 금지’: 외부 서비스의 인증 토큰을 MCP 서버나 에이전트에 그냥 프록시처럼 전달하면 안 된다 (MCP 보안 문서에서 명시적으로 anti-pattern으로 분류).
- ‘권한 관리’: AI에게 주는 도구의 권한은 ‘최소한’으로(least-privilege). 예를 들어 읽기 전용 DB 접근만 허용하고 쓰기는 별도 승인을 받게 하는 식.
실무에서는 보통 이런 장치들을 함께 쓴다.
- 위험한 작업(파일 삭제, 결제, 이메일 발송)은 사람의 승인 단계(human-in-the-loop) 필수
- MCP/Tool 연결 시 허용된 도구 목록(allowed_tools)을 좁게 지정
- AI의 도구 호출을 로그로 기록
- 코딩 에이전트처럼 광범위한 권한이 필요한 경우 샌드박스나 VM 환경에서 실행
- 읽기 전용 권한부터 시작, 쓰기 권한은 나중에 확장
마치며: LLM은 이제 “일하는 AI”로 간다
정리하면:
- LLM 혼자서는 학습 시점의 지식만 쓸 수 있다. 실시간 정보, 내 데이터, 실제 작업은 외부 연결이 필요하다.
- ‘함수 호출’은 AI에게 쓸 수 있는 도구를 알려주고, AI가 “이 도구 써줘”라고 요청하게 만드는 방법이다. 커스텀 함수는 내 앱이, 내장 도구는 공급사 인프라가 실행한다.
- ‘도구(Tools)’는 함수 호출의 확장된 개념. 내장 도구와 커스텀 도구 모두 포함.
- ‘MCP’는 AI와 외부(도구·데이터·프롬프트) 사이의 표준 연결 규격이다. Anthropic에서 시작해 Linux Foundation으로 이관된 벤더 중립 표준으로 굳어가는 중.
- ‘A2A’는 AI 에이전트끼리 발견·협업하는 표준. 이미 v1.0 production-ready 단계지만, MCP보다 체감 보급은 느리다.
- 함수 호출, MCP, A2A, RAG는 같은 층위가 아니다. 각자 다른 레벨의 개념이다.
- 연결이 강력할수록 보안/권한 설계도 중요하다. 최소 권한, 허용 도구 제한, human-in-the-loop, 토큰 프록시 금지.
이제 AI는 더 이상 ‘말만 하는 기계’가 아니다. 파일을 읽고, API를 부르고, 코드를 실행하고, 다른 AI와 협업한다. 이런 능력을 제대로 활용하려면 하나가 더 필요하다. AI가 필요한 정보를 ‘스스로 찾아서 가져오게’ 만드는 것이다.
다음 글에서는 ‘RAG(검색 증강 생성)’를 다룬다. AI가 방대한 문서 더미에서 질문과 관련된 내용만 찾아 참고해 답하는 방식이다.