어제 발표된 금리 인상 소식을 챗봇에게 물었더니, 몇 달 전 자료를 근거로 태연하게 틀린 답을 내놓은 경험이 있으실 거예요. LLM 답변에 최신 정보가 없을 때는 모델 자체를 바꾸기보다, 웹 검색 도구를 연결하는 쪽이 훨씬 빠르고 확실한 해결책입니다. 다만 이 도구를 붙이는 게 항상 정답은 아니라서, 언제 붙이고 언제 다른 방법을 써야 하는지 기준이 필요합니다.
왜 LLM은 최신 정보를 스스로 알지 못할까요?
GPT나 Claude 같은 모델은 특정 시점까지 수집된 텍스트로 학습을 마친 뒤 고정된 파라미터로 배포됩니다. 이 시점을 흔히 ‘학습 컷오프’라고 부르는데, 컷오프 이후에 일어난 사건이나 발표된 수치는 모델 내부에 아예 존재하지 않아요. 그래서 정보가 없을 때 모델은 검색을 하는 대신, 학습 당시 패턴과 비슷한 문장을 그럴듯하게 이어 붙여 답을 만듭니다.
이 과정에서 모델이 그럴듯하게 없는 사실을 지어내는 환각 현상이 나타나는데, 최신 정보를 물었을 때 특히 자주 발생합니다. 사용자 입장에서는 답변이 자신 있게 서술돼 있어서 틀렸다는 걸 알아채기 어렵다는 점이 더 큰 문제입니다.
학습 데이터 이후 생기는 정보 공백
모델마다 컷오프 시점이 다르고, 같은 모델이라도 버전이 올라가면 컷오프도 갱신됩니다. 예를 들어 GPT-4 계열과 Claude 계열 모두 릴리스 시점마다 학습 데이터 기준일을 공식 문서에 명시하고 있는데, 이 날짜 이후의 사건에 대해서는 근본적으로 답할 방법이 없습니다.
문제는 사용자가 이 컷오프 날짜를 매번 확인하지 않는다는 점이에요. 환율, 주가, 법령 개정, 신제품 출시처럼 하루 단위로 바뀌는 정보를 물을 때 이 공백이 그대로 드러나고, 파인튜닝으로 모델을 다시 학습시켜도 다음 날이면 또 뒤처진다는 근본적인 한계가 남습니다.
웹 검색 도구를 붙이면 답변 구조가 달라집니다
웹 검색 도구를 연결하면 모델은 질문을 받는 순간 검색 쿼리를 만들고, 실제 검색 결과 스니펫을 컨텍스트에 끼워 넣은 뒤 그 내용을 근거로 답을 작성합니다. 즉 ‘기억해서 답하는 방식’에서 ‘찾아서 요약하는 방식’으로 동작이 바뀌는 거예요.
Anthropic은 Claude API에 서버사이드 web search 도구를 제공하고 있어서, 별도의 검색 API를 직접 연동하지 않아도 tools 파라미터에 넣기만 하면 모델이 필요할 때 스스로 검색을 호출합니다. 아래는 2025년 기준 anthropic 파이썬 SDK로 호출하는 예시입니다. 실제 파라미터명과 tool 버전 문자열은 공식 문서 기준으로 확인하시는 게 안전합니다.
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
tools=[{
"type": "web_search_20250305",
"name": "web_search",
"max_uses": 3
}],
messages=[
{"role": "user", "content": "오늘 코스피 지수와 주요 등락 종목 알려줘"}
]
)
for block in response.content:
print(block.type, getattr(block, "text", ""))
이 코드를 실행하면 응답 안에 server_tool_use 블록과 web_search_tool_result 블록이 먼저 오고, 그 뒤에 검색 결과를 요약한 text 블록이 이어지는 구조로 출력됩니다. 검색 결과를 인용한 문장에는 출처 URL이 함께 붙어서, 답변이 어느 페이지를 근거로 했는지 사용자가 직접 확인할 수 있어요.
웹 검색 연동 방식별 비교
같은 목적이라도 구현 방식에 따라 비용과 지연 시간, 관리 부담이 크게 달라집니다. 실무에서 자주 검토되는 네 가지 방식을 정리하면 다음과 같습니다.
| 방식 | 연동 형태 | 과금 기준 | 관리 부담 |
|---|---|---|---|
| Claude web search 도구 | API 내장 서버사이드 툴 | 검색 호출 1회당 과금 (토큰과 별도) | 낮음 (API 파라미터만 추가) |
| OpenAI Responses web_search 도구 | API 내장 서버사이드 툴 | 모델·요청 단위 과금 | 낮음 |
| Gemini Grounding with Google Search | API 옵션(그라운딩) | 그라운딩 요청 단위 과금 | 낮음 |
| 자체 구축 RAG (Tavily·SerpAPI 등 + 벡터DB) | 직접 파이프라인 구성 | 검색 API 요금 + 서버 운영비 | 높음 (직접 유지보수) |
내장형 도구는 며칠 안에 붙일 수 있다는 장점이 있고, 자체 구축 RAG는 사내 문서처럼 공개 웹에 없는 자료까지 검색 범위에 넣을 수 있다는 점에서 목적이 다릅니다. 둘 중 하나를 고르기보다, 공개 정보는 내장 도구로 보완하고 내부 자료는 RAG로 따로 처리하는 조합이 실무에서는 더 흔합니다.
웹 검색 연동이 오히려 손해인 경우도 짚어보세요
모든 질문에 검색을 붙이면 응답 속도가 느려지고 비용도 함께 늘어납니다. 간단한 계산이나 코드 문법, 개념 설명처럼 모델이 이미 정확히 알고 있는 질문까지 매번 검색을 태우면, 지연 시간만 늘어나고 답변 품질은 그대로인 경우가 많아요.
검색 결과를 가져와도 모델이 그 내용을 요약하다가 왜곡하는 사례는 여전히 남아 있어서, 검색 도구를 붙였다고 환각이 완전히 사라지는 건 아닙니다. 또한 사내 위키나 비공개 문서처럼 애초에 웹에 존재하지 않는 정보는 검색 도구로는 찾을 수 없고, 이런 경우는 자체 문서를 임베딩한 RAG 구조가 더 맞는 해법입니다. 실시간성이 필요 없고 참조할 정보량이 적은 서비스라면, 검색 도구 대신 하루 한 번 배치로 최신 데이터를 캐시에 갱신해두는 방식이 비용 면에서 더 유리할 때도 있습니다.
결국 판단 기준은 ‘정보의 유효기간’입니다
질문에 담긴 정보가 하루나 한 주 단위로 바뀌는 성격이라면 웹 검색 도구를 붙이는 쪽이 맞고, 개념이나 문법처럼 시간이 지나도 변하지 않는 질문이라면 검색 없이도 충분합니다. 공개 웹에 없는 사내 자료를 다뤄야 한다면 검색 도구보다 RAG 구조를 먼저 검토하시는 게 순서에 맞습니다.
당장 시작해보고 싶다면, 사용 중인 모델 제공사의 콘솔에서 web search 도구를 임시로 켜보고 같은 질문을 검색 있음·없음 두 버전으로 비교해보시길 권해드립니다. 답변에 출처 URL이 달리는지, 지연 시간이 얼마나 늘어나는지 직접 확인하고 나면 이 도구를 상시로 켤지 말지 훨씬 명확하게 판단하실 수 있을 거예요.
