ChatGPT, Claude, Gemini 같은 LLM 챗봇은 학습 데이터에 포함된 정보까지만 답할 수 있다. 어제 발표된 금리 결정, 오늘 아침 올라온 보안 패치 노트, 방금 변경된 항공 요금 같은 정보는 모델 안에 없다. 이 문제를 해결하는 가장 직관적인 방법이 실시간 웹 검색 연동이다.
실제로 ChatGPT의 '웹 브라우징', Claude의 도구 사용(tool use), Gemini의 Google Search Grounding이 모두 같은 원리를 쓴다. 사용자가 질문하면 모델이 검색 도구를 호출하고, 돌아온 결과를 읽은 뒤 답변을 생성하는 구조다. 이 글에서는 이 구조를 직접 구현하거나 기존 서비스에 붙이고 싶은 개발자와, AI 도구의 동작 원리를 이해하고 싶은 일반 사용자 모두를 대상으로 핵심 개념부터 서비스 비교, 실무 선택 기준까지 다룬다.
이 글을 끝까지 읽으면 검색 API와 크롤러 API의 차이, Function Calling과 MCP의 관계, 그리고 Tavily·Jina Reader·Brave Search 등 주요 서비스의 가격과 특성을 한눈에 파악할 수 있다.
1. LLM에 실시간 검색이 필요한 이유
LLM은 학습 시점까지의 데이터만 알고 있다. 이를 지식 컷오프(knowledge cutoff)라 부른다. 예를 들어 학습이 2025년 1월까지 진행된 모델에게 2025년 3월 발표된 기술 사양을 물어보면, 모델은 모른다고 답하거나 과거 정보를 기반으로 추측할 수밖에 없다.
이 한계를 넘는 방법은 크게 세 가지다.
1.1 지식 확장의 세 갈래
- 파인튜닝(Fine-tuning): 새 데이터로 모델을 다시 학습시키는 방법이다. 비용이 크고 시간이 오래 걸리며, 매일 바뀌는 뉴스나 가격 정보에는 적합하지 않다.
- RAG(Retrieval-Augmented Generation): 질문이 들어올 때마다 외부 데이터베이스나 문서에서 관련 정보를 검색해 프롬프트에 넣어주는 방식이다. 사내 문서, 기술 위키처럼 범위가 정해진 데이터에 강하다.
- 실시간 웹 검색 연동: RAG의 확장판이다. 검색 대상이 사내 DB가 아니라 인터넷 전체가 된다. 뉴스, 시세, 날씨, 최신 릴리스 노트 등 시시각각 변하는 정보에 대응할 수 있다.
세 번째 방법이 바로 이 글의 주제다. 웹 검색 결과를 LLM 컨텍스트에 삽입하는 기술적 구조를 이해하면, 왜 특정 API가 필요한지 자연스럽게 따라온다.
핵심 포인트: LLM의 지식 컷오프 문제를 실시간으로 해결하려면 웹 검색 연동이 가장 현실적이다. 파인튜닝은 비용과 시간이, RAG는 데이터 범위가 제한되지만, 웹 검색은 인터넷 전체를 대상으로 최신 정보를 가져올 수 있다.
2. 검색 연동의 기술 구조 — Function Calling, Tool Use, MCP
LLM이 직접 인터넷에 접속하는 것은 아니다. 모델은 텍스트를 생성할 뿐이고, 실제 검색은 외부 프로그램이 수행한다. 모델과 외부 도구를 연결하는 방식이 핵심이며, 현재 업계에서 쓰이는 대표적인 세 가지 패턴이 있다.
2.1 Function Calling(함수 호출)
- 개발자가 검색 함수의 이름, 파라미터, 설명을 JSON 스키마로 정의해 모델에게 알려준다. 예를 들어
web_search라는 함수에query(검색어)라는 파라미터가 있다고 선언하는 식이다. - 사용자가 최신 정보가 필요한 질문을 하면, 모델은 직접 답하는 대신 해당 함수를 호출하겠다는 JSON을 출력한다.
- 개발자의 백엔드 코드가 이 JSON을 받아 실제 검색 API를 호출하고, 결과를 모델에게 다시 전달한다.
- 모델이 검색 결과를 읽고 최종 답변을 생성한다.
OpenAI의 Chat Completions API에서 tools 파라미터로 함수를 등록하는 방식, Anthropic Claude의 tool use가 모두 이 패턴이다. 핵심은 모델이 언제 검색할지 스스로 판단한다는 점이다. 단순한 인사말에는 검색을 건너뛰고, 최신 뉴스를 묻는 질문에만 검색 도구를 호출한다.
2.2 MCP(Model Context Protocol)
- Anthropic이 2024년 말 공개한 개방형 프로토콜로, AI 모델과 외부 도구 사이의 연결을 표준화한 규격이다.
- Function Calling이 API 제공사마다 형식이 다른 반면, MCP는 하나의 규격으로 여러 도구를 연결할 수 있다. USB-C 포트처럼 어떤 장치든 같은 케이블로 연결하는 것과 비슷하다.
- MCP 서버를 하나 띄워두면, Claude Desktop, VS Code, Cursor 같은 MCP 호환 클라이언트가 해당 서버의 도구를 바로 사용할 수 있다.
- Tavily, Jina 모두 공식 MCP 서버를 제공하므로, 코드를 한 줄도 쓰지 않고 Claude Desktop에 실시간 검색을 붙일 수 있다.
2.3 전체 흐름 요약
검색 연동의 데이터 흐름을 정리하면 다음과 같다.
| 단계 | 동작 | 담당 |
|---|---|---|
| 사용자 질문 | 최신 정보가 필요한 질문 입력 | 사용자 |
| 도구 판단 | 검색이 필요한지 모델이 스스로 결정 | LLM |
| 검색 호출 | 검색 API에 쿼리 전송 | 백엔드 또는 MCP 서버 |
| 결과 수신 | 제목, URL, 본문 요약 등 수신 | 검색 API |
| 답변 생성 | 검색 결과를 컨텍스트로 활용해 답변 작성 | LLM |
핵심 포인트: Function Calling은 모델이 외부 도구를 호출하는 메커니즘이고, MCP는 그 연결을 표준화한 프로토콜이다. 어떤 방식이든 흐름은 동일하다. 질문 → 도구 판단 → 검색 → 결과 주입 → 답변 생성.
3. 검색 API vs 크롤러 API — 역할이 다르다
AI에 웹 정보를 넣으려면 두 종류의 API가 필요하다. 하나는 무엇을 찾을지 결정하는 검색 API, 다른 하나는 찾은 페이지를 읽는 크롤러 API다. 사람으로 치면 구글에 검색어를 입력하는 행위와, 검색 결과 링크를 클릭해 본문을 읽는 행위의 차이다.
3.1 검색 API의 역할
- 키워드나 자연어 쿼리를 받아 관련 웹페이지 목록을 돌려준다.
- 각 결과에는 제목, URL, 짧은 스니펫이 포함된다.
- Tavily, SerpAPI, Serper.dev, Brave Search API, Exa 등이 대표적이다.
- LLM 전용 검색 API는 스니펫 대신 페이지 본문에서 추출한 요약까지 제공해, 별도 크롤링 없이도 꽤 쓸 만한 컨텍스트를 얻을 수 있다.
3.2 크롤러 API의 역할
- 특정 URL을 입력하면 해당 페이지의 본문을 추출한다.
- HTML 태그, 광고, 내비게이션, 사이드바를 제거하고 깨끗한 텍스트(주로 마크다운)만 돌려준다.
- Jina Reader, Firecrawl, ScrapingBee 등이 대표적이다.
- 검색 API가 돌려준 URL의 전체 내용을 읽어야 할 때, 또는 특정 문서를 정밀하게 파싱해야 할 때 사용한다.
3.3 둘의 조합이 완성형
| 구분 | 검색 API | 크롤러 API |
|---|---|---|
| 비유 | 구글에 검색어 입력 | 검색 결과 링크 클릭해서 읽기 |
| 입력 | 검색 쿼리(키워드, 질문) | URL |
| 출력 | 페이지 목록 + 스니펫/요약 | 해당 페이지의 전체 본문(마크다운) |
| 대표 서비스 | Tavily, Brave Search, Serper, Exa | Jina Reader, Firecrawl, ScrapingBee |
실무에서는 검색 API로 관련 URL을 찾고, 필요하면 크롤러 API로 해당 페이지를 깊이 읽는 2단계 파이프라인을 구성한다. 다만 Tavily처럼 검색 결과에 본문 요약까지 포함하는 API를 쓰면 크롤러 없이도 충분한 경우가 많고, Jina의 Search 모드(s.jina.ai)처럼 검색과 크롤링을 한 번에 처리하는 서비스도 있다.
4. Tavily — AI 에이전트 전용 검색 API
Tavily는 처음부터 LLM과 AI 에이전트를 위해 설계된 검색 API다. 일반 검색 엔진(Google, Bing)은 사람이 보는 용도로 만들어져 있어서, 결과를 LLM에 넣으려면 HTML 파싱과 텍스트 정제가 필요하다. Tavily는 이 과정을 건너뛰고 LLM이 바로 소화할 수 있는 형태로 결과를 돌려준다.
4.1 주요 엔드포인트
- /search: 검색 쿼리를 넣으면 관련 웹페이지의 제목, URL, 본문 요약을 한 번에 돌려준다. 일반 검색 API와 다른 점은 스니펫이 아니라 실제 페이지 본문에서 추출한 내용을 제공한다는 것이다. Basic 검색은 1크레딧, Advanced 검색은 2크레딧이 소모된다.
- /extract: 특정 URL을 넣으면 해당 페이지의 본문을 추출한다. 크롤러 API 역할로, 5개 URL 추출당 1~2크레딧이 든다.
- /research: 복잡한 질문에 대해 여러 번 검색하고 종합해 리서치 보고서를 생성한다. Pro 모델 기준 요청당 15~250크레딧, Mini 모델은 4~110크레딧이 소모되므로 비용 관리에 주의해야 한다.
- /map: 도메인의 사이트맵을 파악하고, /crawl은 맵 + 추출을 결합해 사이트 전체를 크롤링한다.
4.2 가격 체계
| 플랜 | 월 가격 | 크레딧/월 | 크레딧당 단가 |
|---|---|---|---|
| Researcher(무료) | $0 | 1,000 | - |
| Project | $30 | 4,000 | $0.0075 |
| Bootstrap | $100 | 15,000 | $0.0067 |
| Startup | $220 | 38,000 | $0.0058 |
| Growth | $500 | 100,000 | $0.005 |
| Pay As You Go | 종량제 | 쓴 만큼 | $0.008 |
| Enterprise | 협의 | 커스텀 | 커스텀 |
무료 플랜은 신용카드 없이 가입 가능하고, 월 1,000크레딧이면 Basic 검색 기준 하루 약 33회 사용할 수 있다. 개인 프로젝트 테스트용으로는 넉넉한 수준이다. OpenAI SimpleQA 벤치마크에서 93.3% 정확도를 달성했고, LangChain의 공식 추천 검색 도구이며 OpenAI, Anthropic, IBM, Databricks 등이 파트너로 사용 중이다.
5. Jina Reader — URL을 LLM용 마크다운으로 변환
Jina Reader는 웹페이지를 LLM이 읽기 좋은 깨끗한 마크다운으로 바꿔주는 크롤러 API다. HTML 태그, 광고, 내비게이션 같은 불필요한 요소를 제거하고 본문 텍스트만 추출한다.
5.1 두 가지 모드
- Read 모드 (
r.jina.ai/URL): 특정 URL의 본문을 마크다운으로 변환한다. 사용법이 극도로 단순해서, URL 앞에https://r.jina.ai/를 붙이기만 하면 브라우저에서 바로 테스트할 수 있다. - Search 모드 (
s.jina.ai/검색어): 검색까지 수행한 뒤 상위 5개 결과 페이지를 방문해 본문을 추출한다. 이 모드만으로 검색 API + 크롤러 API 역할을 동시에 처리할 수 있어, 간단한 프로젝트에서는 Jina 하나로 충분할 수 있다.
5.2 가격 체계
| 조건 | 분당 요청 한도(RPM) | 비용 |
|---|---|---|
| API 키 없이 사용 | 20 RPM | 완전 무료 |
| 무료 API 키 발급 | 200 RPM | 무료(가입 시 1,000만 토큰 제공) |
| 유료 플랜 | 최대 5,000 RPM | $0.02/1M 토큰 |
2025년 5월 이후 토큰 기반 과금 모델로 전환되었다. 무료 API 키만 발급받아도 분당 200회, 1,000만 토큰까지 쓸 수 있어 개인 개발 용도로는 충분하다.
5.3 고급 기능
Jina Reader는 단순 크롤러치고 옵션이 풍부하다. CSS 셀렉터로 특정 영역만 추출하기, 이미지 캡션 자동 생성, JavaScript 실행 후 추출, iframe과 Shadow DOM 내용 포함, 프록시 서버 경유, 쿠키 전달, robots.txt 준수 여부 설정 등을 지원한다. ReaderLM-v2라는 자체 AI 모델을 사용한 고품질 HTML→마크다운 변환 옵션도 있는데, 이 경우 토큰이 3배 소모된다.
핵심 포인트: Tavily는 검색(구글에 검색하는 것)에 해당하고, Jina Reader는 읽기(페이지를 열어 읽는 것)에 해당한다. 둘을 조합하면 검색 + 읽기의 완성형이 되지만, 각 서비스가 상대 영역까지 커버하는 기능도 갖추고 있어 용도에 따라 하나만으로도 충분할 수 있다.
6. 주요 검색 API 비교 — Tavily 외에 어떤 선택지가 있나
Tavily와 Jina 외에도 AI 에이전트용 검색 API는 여러 가지가 있다. 용도와 예산에 따라 더 적합한 선택이 달라지므로, 대표적인 서비스를 비교해 본다.
| 서비스 | 유형 | 무료 티어 | 유료 시작가 | 특징 |
|---|---|---|---|---|
| Tavily | LLM 전용 검색 | 1,000크레딧/월 | $30/월 | 검색+추출+리서치 통합, LangChain 공식 추천 |
| Jina Reader | 크롤러+검색 | 1,000만 토큰 | $0.02/1M 토큰 | URL 앞에 붙이기만 하면 동작, Search 모드 제공 |
| Brave Search API | 독립 인덱스 SERP | 2,000쿼리/월 | ~$5/월 | Google·Bing과 독립된 자체 인덱스, 프라이버시 중시 |
| Serper.dev | Google SERP | 2,500쿼리(체험) | $1/1,000검색 | Google 결과를 깔끔한 JSON으로, 최저가 수준 |
| SerpAPI | 멀티엔진 SERP | 250검색/월 | $50/월 | Google·Bing·Yahoo·Baidu 등 다중 엔진 지원 |
| Exa | 시맨틱 검색 | $10 크레딧 제공 | 종량제 | 키워드가 아닌 의미 기반 검색, 신경망 인덱스 |
| Perplexity Sonar | 검색+LLM 통합 | 없음 | $1/1M 입력토큰 + $5/1K 요청 | 검색과 답변 생성을 API 한 번 호출로 처리 |
| OpenAI Web Search | 내장 검색 도구 | 없음 | 토큰+검색비용 합산 | Responses API에서 바로 사용, 별도 API 키 불필요 |
6.1 선택 기준별 추천
- 빠르게 테스트하고 싶다: Jina Reader의 Search 모드가 가장 간단하다. API 키 없이도
https://s.jina.ai/검색어만 입력하면 된다. - LangChain이나 LangGraph 기반 에이전트를 만든다: Tavily가 공식 연동되어 있어 설정이 가장 간편하다.
- Google 검색 결과 그대로가 필요하다: Serper.dev가 가격 대비 가장 효율적이다. 1,000회 검색에 $1밖에 안 든다.
- Google에 의존하지 않고 독립적인 결과가 필요하다: Brave Search API가 자체 인덱스를 보유하고 있어 결과 다양성을 확보할 수 있다.
- 검색과 답변 생성을 한 번에 처리하고 싶다: Perplexity Sonar API나 OpenAI Responses API의 내장 웹 검색 도구가 적합하다.
7. 실제 연동 패턴 세 가지
검색 API를 선택했다면, 이를 LLM 애플리케이션에 붙이는 방법을 결정해야 한다. 실무에서 가장 많이 쓰이는 세 가지 패턴을 정리한다.
7.1 직접 Function Calling 구현
- OpenAI Chat Completions API 또는 Anthropic Messages API의
tools파라미터에 검색 함수를 등록한다. - 모델이
tool_calls를 반환하면 백엔드에서 Tavily나 Brave Search API를 호출한다. - 검색 결과를
tool역할의 메시지로 대화에 추가하고 모델에 다시 보낸다. - 자유도가 가장 높지만, 호출 루프와 에러 처리를 직접 구현해야 한다.
7.2 프레임워크 활용 (LangChain, LlamaIndex)
- LangChain에서는
TavilySearchResults도구를 임포트하고 에이전트에 등록하면 된다. 검색 판단, 호출, 결과 주입까지 프레임워크가 처리한다. - LlamaIndex에서도 비슷하게
QueryEngineTool로 검색 API를 감싸 에이전트에 넘긴다. - 코드량이 대폭 줄지만, 프레임워크의 추상화 레이어를 이해해야 디버깅이 가능하다.
7.3 MCP 서버 연결 (노코드에 가까움)
- Tavily 공식 MCP 서버를 Claude Desktop이나 Cursor의 MCP 설정에 추가한다. mcpServers 설정 객체에 서버 이름을 키로, command와 args를 값으로 지정하는 방식이다.
- 환경 변수에 API 키만 넣으면 코드 작성 없이 검색 도구가 활성화된다.
- Jina도
mcp.jina.ai라는 공식 MCP 서버 주소를 제공한다. - 개발자가 아닌 사용자도 Claude Desktop 설정만으로 실시간 검색을 활용할 수 있다는 점이 MCP의 가장 큰 장점이다.
| 패턴 | 난이도 | 자유도 | 적합 대상 |
|---|---|---|---|
| 직접 Function Calling | 높음 | 최대 | 커스텀 에이전트 개발자 |
| LangChain 등 프레임워크 | 중간 | 높음 | 빠른 프로토타이핑, 팀 프로젝트 |
| MCP 서버 연결 | 낮음 | 중간 | 비개발자, Claude Desktop 사용자 |
핵심 포인트: 코드를 쓸 줄 모르더라도 MCP를 통해 Claude Desktop에 Tavily나 Jina 검색을 붙일 수 있다. 개발자라면 직접 Function Calling을 구현하거나 LangChain 같은 프레임워크를 활용하는 것이 자유도 면에서 유리하다.
8. 비용 최적화 전략
검색 API는 호출할 때마다 비용이 발생한다. AI 에이전트가 한 질문에 10번씩 검색하면 비용이 빠르게 누적되므로, 다음 전략이 중요하다.
8.1 비용을 줄이는 다섯 가지 방법
- 검색 판단 최적화: 시스템 프롬프트에서 모델에게 최신 정보가 반드시 필요한 경우에만 검색하도록 지시한다. 일반 상식 질문까지 매번 검색하면 낭비다.
- Basic 모드 우선 사용: Tavily의 경우 Basic 검색(1크레딧)으로 충분한 결과를 얻을 수 있는 경우가 많다. Advanced(2크레딧)는 정말 깊은 정보가 필요할 때만 쓴다.
- 결과 수 제한:
max_results를 3~5개로 설정한다. 10개를 가져와도 LLM이 실제로 활용하는 것은 상위 몇 개뿐이다. - 캐싱 도입: 같은 쿼리가 반복되면 이전 결과를 재사용한다. 환율, 날씨처럼 자주 물어보는 질문은 5~10분 캐시만으로도 크레딧을 크게 아낄 수 있다.
- Jina 무료 티어 활용: 분당 20회 이하로 쓴다면 Jina Reader는 API 키 없이도 완전 무료다. 트래픽이 적은 개인 프로젝트에 적합하다.
9. 마무리
위에서 살펴본 AI 채팅 실시간 검색 연동의 핵심 내용을 정리하면 다음과 같습니다.
핵심 요약:
- LLM의 지식 컷오프 한계를 실시간으로 해결하는 가장 실용적인 방법이 웹 검색 연동이다
- 검색 API(무엇을 찾을지)와 크롤러 API(찾은 페이지를 읽는 것)는 역할이 다르며, 둘을 조합하면 완성형이 된다
- Tavily는 LLM 전용 검색 API로 무료 1,000크레딧부터 시작하며, LangChain 공식 연동과 MCP 서버를 지원한다
- Jina Reader는 URL을 마크다운으로 변환하는 크롤러이면서 Search 모드로 검색까지 가능하다
- MCP를 활용하면 코드 없이도 Claude Desktop에 실시간 검색을 붙일 수 있다
- 비용 최적화의 핵심은 검색 판단 최적화, Basic 모드 우선 사용, 결과 수 제한, 캐싱이다
도입을 검토한다면 먼저 Tavily 무료 플랜(월 1,000크레딧)이나 Jina Reader 무료 티어로 프로토타입을 만들어 보는 것을 권장한다. 두 서비스 모두 신용카드 없이 시작할 수 있으므로, 실제 쿼리를 날려보고 결과 품질과 응답 속도를 직접 확인한 뒤 유료 전환 여부를 결정하면 된다.