LLM은 어제 일을 모른다 — OpenClaw가 에이전트에 웹 검색을 붙인 방법

오픈소스 개인 AI 어시스턴트 OpenClaw를 집 서버에 올려 쓰면서 도구(tool) 목록을 들여다봤다. 그중 가장 "당연한데 의외로 손이 많이 가는" 것이 web_search(웹 검색 도구)였다. 거대 언어 모델(LLM, Large Language Model — 대량의 텍스트로 미리 학습한 언어 생성 모델)은 학습이 끝난 시점 이후의 일을 전혀 모른다. 어제 발표된 라이브러리, 오늘 아침 뉴스, 방금 바뀐 가격은 모델 안에 없다. 그래서 에이전트에 "지금 웹을 검색해 오는" 손발을 붙여야 하는데, OpenClaw는 이걸 단순히 검색 API 하나 꽂는 식으로 풀지 않았다. 어떤 검색 제공자(provider)를 고를지, API 키는 어디에 두고 누가 가져갈지, 프라이버시는 어떻게 지킬지, 같은 질문을 또 받으면 어떻게 할지 — 이 네 가지를 함께 다뤘다. 이 글은 그 설계를 따라간다.

배경 — 학습 시점에 갇힌 모델에게 "지금"을 알려줘야 한다

LLM의 지식은 학습 데이터를 모은 시점에서 멈춰 있다. 이걸 흔히 knowledge cutoff(지식 컷오프 — 모델이 학습한 데이터의 마지막 시점)라고 부른다. 컷오프 이후의 사실은 모델이 "모른다"고 답하면 그나마 다행이고, 더 나쁜 경우엔 그럴듯하게 지어낸다(환각, hallucination). "OpenClaw 최신 버전이 뭐냐"고 물으면, 모델은 학습 당시 알던 버전을 자신 있게 말하거나 존재하지 않는 버전을 만들어낸다.

해결책은 단순하다. 모델이 답을 짓기 전에 실제 웹을 검색해서 최신 사실을 prompt(모델에게 주는 입력 텍스트)에 끼워 넣는 것이다. 이 패턴을 도구 호출(tool calling)이라 부른다 — 모델이 "이건 내가 모르니 검색 도구를 써야겠다"고 판단하면, 에이전트가 대신 검색을 실행하고 결과를 모델에게 돌려준다.

다이어그램 설명. 이 그림은 웹 검색 도구가 없을 때와 있을 때 답변이 어떻게 갈리는지 보여준다. 사용자 질문이 들어오면 모델이 먼저 "내 학습 지식으로 답할 수 있는가"를 판단하는데, 왼쪽 분기처럼 옛 지식만으로 곧장 답하면 낡은 정보거나 지어낸 답이 나오기 쉽다. 오른쪽 분기가 핵심이다 — 모델이 "최신 정보가 필요하다"고 판단하면 검색 도구를 호출하고, 그 결과를 입력 텍스트에 끼워 넣은 뒤 근거 있는 답을 만든다. 이 패턴이 중요한 이유는 모델 자체를 다시 학습시키지 않고도(그건 수개월·수억 원짜리 작업이다) 검색이라는 외부 손발 하나로 "지금 이 순간"을 알게 만들기 때문이다. 놓치기 쉬운 함정은 검색이 자동이 아니라는 점이다 — 모델이 "검색이 필요하다"고 스스로 판단해야 호출되므로, 도구를 켜 두는 것과 모델이 실제로 쓰는 것은 다른 문제다.

핵심 문제 — 검색 API 하나만 꽂으면 안 되는 이유

"그냥 검색 API 하나 연결하면 되는 것 아닌가?" 처음엔 그렇게 보인다. 하지만 개인용 에이전트를 실제로 운영하려고 하면 단일 제공자에 고정하는 순간 네 가지 현실 문제가 동시에 터진다.

다이어그램 설명. 이 그림은 검색 제공자를 하나로 못 박았을 때 갈라지는 네 가지 문제를 한눈에 보여준다. 첫째 다양성 — 어떤 사용자는 Brave 검색 키가 있고 어떤 사용자는 Perplexity 구독만 있으며 또 누구는 아무 키도 없으니, 하나로 강제하면 절반은 못 쓴다. 둘째 API 키 — 상당수 제공자는 유료 키가 있어야만 검색이 되므로 키 발급·결제가 진입 장벽이 된다. 셋째 프라이버시 — 검색어 한 줄 한 줄이 외부 검색 회사 서버로 날아가는데, 집에 둔 개인 에이전트라면 "내 모든 질문을 남의 회사가 본다"는 부담이 크다. 넷째 비용과 속도 — 같은 질문이 반복돼도 매번 외부 호출이 일어나면 돈과 시간이 새어 나간다. 이 패턴(문제를 갈래로 펼치기)을 쓴 이유는 뒤에 나올 해결책이 정확히 이 네 갈래를 하나씩 막기 때문이다. 함정은 "유명한 검색 API 하나면 충분하다"는 직관인데, 운영을 시작하면 위 네 가지가 거의 항상 같이 온다. 그래서 OpenClaw는 "어떤 제공자를 쓸지"를 사용자가 고를 수 있게 만드는 데서 출발한다.

해결 방법 — 교체 가능한 제공자 + 자동 감지 + 키 없는 자체호스팅 + 캐싱

OpenClaw는 위 네 문제를 각각 하나씩 막는 네 가지 설계로 풀었다. (1) 검색 제공자를 플러그인처럼 교체 가능하게 만들고, (2) 키가 준비된 제공자를 자동 감지해 고르며, (3) 키가 아예 필요 없는 자체호스팅 옵션(SearXNG 등)을 제공하고, (4) 결과를 15분간 캐싱한다. 하나씩 보자.

설계 1 — 검색 제공자를 교체 가능한 부품으로

OpenClaw의 web_search는 특정 검색 회사에 묶이지 않는다. 설정 파일의 한 줄(tools.web.search.provider)로 제공자를 갈아 끼울 수 있다. docs 기준으로 Brave, DuckDuckGo, SearXNG, Perplexity, Firecrawl, Exa, Tavily, Gemini, Grok, Kimi, MiniMax, Parallel, Ollama, Codex 등 십수 개를 지원한다. 이들은 크게 두 부류로 갈린다.

다이어그램 설명. 이 그림은 에이전트가 검색을 부를 때 OpenClaw 내부에서 어떻게 갈라지는지 보여준다. 에이전트는 그저 query(검색어) 하나만 넘기고, 가운데 라우터가 설정된 제공자에 맞춰 실제 검색을 보낸다. 결과는 두 종류다 — 왼쪽처럼 제목·요약·링크 목록을 그대로 돌려주는 구조화 결과형(전통적 검색 엔진 결과 페이지를 떠올리면 된다)과, 오른쪽처럼 검색 결과를 AI가 한 문단으로 요약하고 출처 링크(citation)를 함께 붙여 주는 AI 종합 답변형이다. 이 분기가 중요한 이유는 에이전트 코드가 제공자마다 달라지지 않기 때문이다 — 검색어만 넘기면 어떤 제공자를 쓰든 동일한 인터페이스로 결과가 돌아온다. 그래서 사용자는 자기 상황(이미 가진 키, 원하는 결과 형태)에 맞는 제공자를 고르기만 하면 된다. 함정은 두 결과형이 미묘하게 다르다는 점이다 — AI 종합형(Gemini·Grok·Kimi)은 결과 개수를 지정하는 count 같은 옵션을 받아도 답 모양이 거의 안 바뀌고 한 덩어리 답을 준다. 이 차이를 모르면 "왜 5개를 요청했는데 문단 하나만 오지" 하고 당황하게 된다.

설계 2 — 자동 감지로 "가진 키"를 알아서 고른다

제공자를 명시하지 않으면 OpenClaw가 환경을 훑어 준비된 제공자를 자동으로 고른다. 핵심은 순서다 — 무작정 아무거나 고르지 않고 정해진 우선순위(precedence)대로 "키가 준비됐는가"를 위에서부터 확인해 첫 번째로 준비된 것을 쓴다.

다이어그램 설명. 이 그림은 제공자를 안 정했을 때 OpenClaw가 어떤 순서로 검색 수단을 고르는지 보여주는 결정 흐름이다. "이 제공자의 키가 준비됐는가"를 순서대로 확인하며, 처음으로 준비된 곳을 쓴다 — "Brave 키 있나?"에서 시작해 그다음이 다른 유료 API 키 제공자들, 그다음이 자체호스팅 검색 주소다. 마지막 칸이 중요한 설계 포인트다. DuckDuckGo처럼 키가 필요 없는 제공자는 자동으로 선택되지 않는다 — 사용자가 설정에서 명시적으로 골라야만 쓰인다. 키가 없으면 검색 제공자를 직접 골라 주는 한 단계가 필요하다.

설계 3 — 키가 아예 필요 없는 자체호스팅, SearXNG

프라이버시와 비용을 동시에 푸는 카드가 SearXNG다. SearXNG는 직접 서버에 띄우는 메타 검색 엔진(meta search engine — 여러 검색 엔진의 결과를 모아 합쳐 주는 중개 서버)이다. Google·Bing·DuckDuckGo 같은 곳에 대신 질의하고 결과를 합쳐 돌려준다. API 키가 없고, 검색어가 외부 검색 회사로 직접 노출되지 않으며(자체 서버가 중개), 호출당 과금도 없다.

▲ 외부 API 제공자 방식

다이어그램 설명. 위 블록은 Brave 같은 외부 상용 검색 API를 쓸 때의 데이터 흐름을 보여준다. 에이전트가 만든 검색어가 그대로 외부 회사 서버로 날아가고, API 키로 신원을 증명하며, 호출 한 번마다 비용이 매겨진다. 장점은 결과 품질·필터(국가·언어·기간 등)가 잘 정돈돼 있다는 점이고, 대가는 "내 검색어를 외부 회사가 본다 + 돈이 든다"는 두 가지다. 개인 에이전트에서 이게 부담스러우면 아래 방식이 대안이 된다.

▲ 자체호스팅 SearXNG 방식

다이어그램 설명. 위 블록은 자체호스팅 SearXNG를 쓸 때의 흐름이다. 검색어가 먼저 내 서버의 SearXNG로 가고, SearXNG가 사용자 대신 여러 검색 엔진에 질의한 뒤 결과를 모아 합쳐 돌려준다. 외부 상용 API 방식과 같은 축에서 비교하면 차이가 분명하다 — 앞의 방식은 검색어가 외부 회사로 직행하고 호출마다 과금되지만, SearXNG 방식은 중간에 내가 통제하는 서버가 끼어들어 키도 과금도 없고 검색 회사에 내 신원이 직접 묶이지 않는다. 대가는 내가 서버를 직접 띄우고 관리해야 한다는 운영 부담이다. 이 자체호스팅 옵션이 "프라이버시 우려 때문에 에이전트에 검색을 못 붙이던" 사용자에게 실질적인 출구를 열어 준다.

설계 4 — 같은 질문은 15분간 캐싱

마지막은 비용·속도 문제를 막는 캐싱(caching — 한 번 가져온 결과를 잠시 저장해 두고 재사용)이다. OpenClaw는 검색 결과를 검색어 기준으로 15분간 저장한다(cacheTtlMinutes 설정으로 조절 가능). 에이전트는 한 작업 안에서 같은 검색을 여러 번 하는 경향이 있는데 — 추론하다 보면 "아까 그거 다시 확인" 같은 반복 호출이 흔하다 — 그때마다 외부 API를 때리면 돈과 시간이 샌다.

다이어그램 설명. 이 그림은 검색 호출이 들어왔을 때 캐시를 먼저 확인하는 흐름을 보여준다. 첫 판단 단계에서 "이 검색어를 최근 15분 안에 이미 검색했는가"를 묻고, 있으면 외부를 전혀 부르지 않고 저장된 결과를 즉시 돌려준다(왼쪽 분기). 없으면 실제로 외부 제공자에 검색하고, 그 결과를 다음 15분 동안 쓰도록 저장한 뒤 반환한다(오른쪽 분기). 여기서 TTL(Time To Live — 저장된 값이 유효한 시간)이 15분인 이유는 트레이드오프다. 너무 길게 잡으면 신선도 문제가 생기고, 너무 짧으면 캐싱 효과가 사라진다. 15분은 "한 작업 세션 동안의 반복 호출"을 거의 다 잡으면서 신선도는 크게 해치지 않는 절충점이다. 이 캐싱 덕에 에이전트가 추론 중 같은 검색을 반복해도 외부 비용이 한 번만 든다.

결과 — 무엇이 좋아졌나

앞서 본 단일 제공자의 네 문제가 네 설계로 이렇게 정리된다.

단일 제공자 고정의 문제	OpenClaw의 대응
사람마다 가진 키가 달라 절반은 못 씀	제공자를 설정 한 줄로 교체 — 십수 개 중 택일
키 없으면 검색 자체가 안 됨	준비된 키를 자동 감지해 선택, 키 없으면 SearXNG·DuckDuckGo
모든 검색어가 외부 회사로 노출	키 없는 자체호스팅 SearXNG로 검색어를 내 서버 안에 가둠
같은 질문 반복 시 매번 과금·지연	검색어 기준 15분 캐싱 — 반복 호출은 외부 비용 0

정리하면, OpenClaw의 web_search는 "검색 API 하나 꽂기"가 아니라 "사람마다 다른 키·예산·프라이버시 요구를 한 도구로 흡수하는" 설계다. 개인이 집 서버에 에이전트를 올려도 "내 검색어가 새거나, 키가 없어 못 쓰거나, 같은 질문에 돈이 줄줄 새는" 걱정 없이 LLM의 지식 컷오프를 메울 수 있다. 화려한 AI 기능 이전에, 모델이 "지금"을 아는 것 — 그게 쓸 만한 에이전트의 바닥 전제다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.