Claude Code는 언제 웹 검색을 할까? 세션을 기록하여 알아봤습니다

2026년 10월 12일, AWS가 Lambda Web Functions를 출시했습니다. 이제 최대 128개의 동시 요청으로 실행 환경에서 일반 Express 또는 Next.js 앱을 Lambda에서 실행할 수 있습니다.

이틀 후 저는 Claude Code에 세 가지 모델에게 질문했습니다. "우리 Express 앱은 app.js에 있어요. 가장 적은 변화로 AWS Lambda에 배포하는 데 필요한 파일을 추가해 주세요."

여섯 번의 시도 모두 10월 11일 이전까지는 serverless-http, serverless-express 또는 Lambda Web Adapter를 설정했습니다. 그중 다섯 개는 아무것도 검색하지 않았습니다. 여섯 번째만 npm에서 serverless-http의 최신 버전을 확인했습니다.

그런 다음 "이달 기준으로 AWS Lambda에서 Express 앱을 실행하는 가장 새로운 방법은 무엇인가요?"라고 물었습니다. 모든 시도가 웹을 검색했습니다. 여섯 개 중 다섯 개가 Web Functions를 언급했습니다.

주제는 같았습니다. 단지 표현만 바뀌었을 뿐입니다. 저는 이것이 얼마나 멀리까지 가는지 알고 싶었습니다. Claude Code는 언제 정보를 찾아보고, 언제 학습 데이터에서 답변할까요? 그리고 학습 데이터에서 답변할 경우, 그 답변은 얼마나 자주 구식이 될까요?

설정

모델의 학습 차단 시점 이후 변경된 7가지 주제. 저는 테스트 당일에 공식 소스와 비교했습니다:

각 실행 전에 저장소(repo)는 git으로 초기화되며 프로젝트 메모리는 없습니다.

웹 호출로 간주되는 것: WebFetch, WebSearch, 그리고 네트워크에 접근하는 셸 명령어입니다. 마지막 그룹이 중요합니다. Claude는 종종 WebFetch를 건너뛰고, PyPI JSON API에 대해 gh api, curl을 사용하거나, pip index versions, 또는 git ls-remote --tags를 호출합니다.

평가(Grading). Sonnet 서브 에이전트가 126개의 비제어 답변 각각을 정답 테이블과 비교하여 다음 세 가지 등급 중 하나로 평가했습니다:

• current: 현재 사실을 사실로 사용함.
• hedged: 오래되었거나 불확실하지만, 사용자에게 최신 정보가 아닐 수 있음을 알림.
• stale: 오래된 정보를 현재인 것처럼 제시함.

코딩 작업의 경우 모델이 작성한 파일도 평가했습니다. 제가 직접 등급을 확인하고 네 가지를 수정했습니다 (Limits 참조).

발견 1: 트리거는 주제가 아니라 단어입니다

웹 호출이 적어도 한 번 포함된 실행 비율:

중간 열들이 흥미로운 부분입니다. 그 안에서 패턴은 질문의 _종류_에 따라 달라집니다:

• **"어떤 버전을 사용해야 하나요?"**라는 질문은 일반적으로 버전 조회를 유발합니다. setup-node, Lambda Python 런타임, Stripe API 버전의 경우, 18개 중 18개의 중립적인 실행 결과가 확인되었습니다.
• **"이 API를 어떻게 사용하나요?"**라는 질문은 그렇지 않습니다. "프록시가 있는 사용자 지정 httpx 클라이언트를 OpenAI Python SDK에 어떻게 전달하나요?"라는 질문은 6회 실행에서 0회의 조회만 기록했습니다. 버전 3의 존재는 언급된 적이 없습니다. 6회 중 5회에서 httpx.Client를 사용했는데, 이는 현재 SDK의 새로 설치된 환경에서는 실패합니다 (자세한 내용은 아래 참조). 한 Opus 실행은 SDK의 DefaultHttpxClient를 사용했으며, 이 역시 작동했습니다.
• **"이 서비스가 X 기능을 수행할 수 있나요?"**는 모델에 따라 다릅니다. "AWS Lambda가 하나의 실행 환경에서 많은 동시 HTTP 요청을 처리할 수 있나요?"라는 질문에 대해 Haiku와 Sonnet은 매번 기억 속의 정보("아니요, 환경당 요청 1개")로 답변했습니다. Opus는 두 번 모두 검색을 시도했습니다. 발견한 내용은 아래에서 더 자세히 다룹니다.

발견 2: 조회가 없다는 것은 오래된 답변이며, 보통 경고가 없음

웹 호출 여부에 따라 분류된 모든 평가된 답변은 다음과 같습니다.

웹 호출을 사용하지 않은 세 개의 "현재" 답변 모두 OpenAI 주제에 대한 Opus의 답변이었습니다. 각 답변은 버전 3가 여전히 지원하는 SDK 자체의 DefaultHttpxClient 헬퍼를 사용했습니다. 두 가지 코딩 실행에서 Opus는 또한 설치된 패키지(우연히 현재 버전이었음)를 대상으로 코드를 실행했습니다. 세 답변 모두 버전 3의 존재를 알지 못했습니다. 코드가 작동한 이유는 SDK가 이전 이름을 유지했기 때문입니다. 이 경우를 제외하고, 학습 데이터만으로 얻은 답변 중 '현재'인 것은 없었습니다.

이는 커트라인 이후 변경된 사실에 대해서는 예상되는 결과입니다. 제가 예상하지 못한 부분은 모델들이 그 사실을 얼마나 드물게 언급하는지였습니다. 35개의 오래된 답변 중 28개에서는 경고가 전혀 제공되지 않았습니다. 나머지 7개는 어떤 주의 사항(caveat)이 있었지만, 종종 매우 좁거나 일반적인 내용이었습니다. 예를 들어, 한 답변은 Lambda Web Adapter 레이어 버전을 확인할 것을 경고했지만, Web Functions의 존재는 알지 못했습니다.

Sonnet이 신중하게 답했을 때, 그 망설임은 정확했다. "Django 6.1이 출시되었다면 모르겠다", "기억에 의존하여 답변했고 확인하지 않았다"와 같은 식이었다. Sonnet이 주저할 때는 그것이 진실을 의미했다.

발견 3: 코딩 작업은 사각지대이다

'가장 최신(newest)'이라는 단어를 언급하지 않은 코딩 작업을 위해 파일에 기록된 내용은 다음과 같다.

Stripe 행이 이를 가장 잘 보여준다. Opus는 두 번의 실행 모두에서 검색을 수행했고 현재 버전을 고정했다. Haiku는 두 번의 실행 중 한 번에서만 검색하여 그 한 번에 정확하게 포착했다. Sonnet은 검색을 전혀 하지 않았고 2025년 버전들을 고정했다.

두 가지 코딩 작업("Django를 가장 최신 안정화 버전으로 고정" 및 "가장 최신 안정화 Python용 Dockerfile")에서는 매번 검색이 트리거되었다. 12개 중 12개였다. 코딩 작업에 포함된 '가장 최신(newest)'이라는 단어만으로 충분했다.

OpenAI 행에는 주석이 필요하다. 왜냐하면 "오래된(outdated)"이라는 것이 "여전히 작동한다"는 의미일 수 있기 때문이다. 나는 openai==3.31.0만 설치된 깨끗한 가상 환경에서 이를 확인해 보았다. Haiku와 Sonnet의 코드는 첫 줄에서 실패한다:

ModuleNotFoundError: No module named 'httpx'

openai 3.x는 httpx2에 의존하며 더 이상 httpx를 가져오지 않는다. 여전히 httpx가 있는 구형 환경에서는 동일한 코드가 실행된다. Opus 버전은 SDK 자체의 DefaultHttpxClient를 사용하는데, 이는 3.x에서 httpx2 기반으로 별칭(alias)을 유지한다. 이 방식은 새로 설치된 환경에서도 작동한다.

발견 4: 학습 데이터가 커트라인보다 오래되었다

이 모델들은 2026년 6월을 학습 커트라인으로 한다. 하지만 코딩 작업들이 작성한 내용을 보라:

• Lambda는 커트라인보다 7개월 앞선 2025년 11월 18일에 python3.14를 추가했다. 모든 여섯 개의 SAM 템플릿은 3.13 또는 3.12를 사용했다.
• actions/setup-node v6는 2025년 10월에 출시되었다. Haiku와 Sonnet은 v4 (2023)를 작성했다. Opus는 v5 (2025년 9월)를 작성했다.
• Haiku는 Stripe API 버전을 2024-06-20로 고정했다.

따라서 "모델은 지식 마감일까지의 내용을 알고 있다"는 설명은 코딩 기본값에 대해서는 너무 관대한 표현입니다. 제가 추측하는 이유는 다음과 같습니다. 모델이 메모리에서 버전을 작성할 때, 훈련 과정에서 가장 많이 본 버전을 작성하기 때문입니다. 이는 기존 코드들이 가장 많이 사용했던 버전이며, 종종 지식 마감일보다 일 년 또는 그 이상 뒤처진 버전인 경우가 많습니다. 최신 버전들은 아직 코드가 적게 사용되었기 때문에 훈련 데이터 내에 충분하지 않습니다.

실질적인 영향은 이렇습니다. 무언가가 지식 마감일 이후에 변경되었는지 확인하는 것만으로는 충분하지 않습니다. 메모리에서 고정된 버전은 그것보다 훨씬 이전에 출시된 항목의 경우에도 구식이 될 수 있습니다.

발견 5: 조회(lookup)가 현재 답변과 같지 않다

웹 호출을 수행한 후에 네 개의 구식 답변이 나왔습니다. 이는 검색이 실패할 수 있는 두 가지 다른 방식을 보여줍니다.

검색은 모델이 이미 알고 있던 것에 대해 질문했다. "AWS Lambda가 하나의 실행 환경에서 여러 동시 HTTP 요청을 처리할 수 있습니까?"라는 질문에 Opus는 두 번 모두 검색했습니다. 두 경우 모두 쿼리는 다음과 같았습니다:

AWS Lambda Managed Instances multi-concurrency execution environment

Lambda Managed Instances는 2025년 후반의 실제 기능입니다. Opus는 훈련을 통해 이 기능을 알고 있었고, 이를 확인하기 위해 검색했으며, Managed Instances에 대한 좋고 출처가 명시된 답변을 얻었습니다. 하지만 두 달 전에 출시된 Web Functions는 찾지 못했는데, 이것이 질문에 대한 직접적인 답변이었습니다. 검색은 모델의 메모리를 기반으로 구축되었기 때문에, 그저 메모리 속 내용을 확인할 수만 있었습니다.

검색 인덱스가 뒤처져 있었다. Python 3.15.0 버전은 10월 9일에 출시되었습니다. 10월 14일, Sonnet은 "latest stable Python release python.org downloads"를 검색했고, python.org가 3.14.8을 최신 버전으로, 3.15를 프리릴리스로 나열한 캐시된 스냅샷을 받았습니다. 그리고 Dockerfile에 python:3.14-slim을 작성했습니다. 다른 실행에서는 "latest stable Python release version October 2026"이라는 쿼리가 3.15를 찾아냈습니다. 월(month)이 포함된 검색은 작동했지만, 월이 없는 검색은 오래된 스냅샷을 가져왔습니다.

솔직히 말해서, Sonnet은 웹 검색을 통해 버전을 얻었다고 했습니다. 그리고 단순한 질문("오늘 가장 최신 안정화된 Python 버전은 무엇인가요?")을 했을 때도 똑같이 오래된 스냅샷을 가져왔습니다. 두 번 모두 검색 결과가 의견이 다르다고 했고, 한 번은 3.15가 "나온 것일 수 있다"는 내용까지 추가했습니다. 이 간극에 대해서는 솔직하게 이야기했습니다. Dockerfile 실행에서도 여전히 이전 버전을 작성했습니다.

발견점 6: CLAUDE.md의 한 줄이 대부분을 해결합니다

만약 간극이 코딩 작업 자체가 검색을 유발하지 않기 때문이라면, 명백한 해결책은 모델에게 정보를 찾아보라고 지시하는 것입니다. 저는 이 CLAUDE.md를 리포지토리에 추가하고 7가지 코딩 작업을 다시 실행했습니다. (3개 모델 x 2회 시도):

Your training data may be out of date. Before you write any version number, runtime identifier, GitHub Action version, API version, or SDK usage pattern into a file, look up the current value (web, package registry, or official ...

웹 검색을 수행하는 코딩 작업은 42회 중 16회에서 42회 중 42회로 증가했습니다. 최신 값으로 평가된 답변은 42회 중 15회에서 42회 중 33회로 증가했습니다.

작업별로 현재 값을 포함한 파일 (각 6회 실행):

규칙이 완전히 해결하지 못한 두 가지 사항:

Haiku는 API가 아닌 버전을 검색했습니다. OpenAI 작업에서 Haiku는 두 번 모두 PyPI의 최신 버전을 확인했습니다. 그리고 이전과 동일한 import httpx 코드를 작성했습니다. 이는 "검색하라"를 "버전 번호를 찾아라"로 해석했을 뿐, "현재 SDK 사용법을 알아내라"로 해석하지 않았습니다. Sonnet과 Opus는 SDK README를 읽고 DefaultHttpx2Client를 작성했습니다.

버전 번호를 넘어 읽는 모델에 대해서만 접근 방식이 변경되었습니다. Haiku와 Sonnet은 이미 메모리에서 선택한 접근 방식을 위해 버전을 조회하는 규칙을 사용했습니다. 즉, npm의 최신 serverless-http, 최신 Lambda Web Adapter layer, 최신 Node runtime을 각각 확인했습니다. 한 번의 Sonnet 실행에서는 AWS 웹 함수(Web Functions) 페이지도 열었습니다. 이후 웹 함수를 대안으로 명시하고 왜 그것들을 사용하지 않았는지 설명했는데, 'app.js'에 작은 변경이 필요하며 SAM이 아직 이를 지원하는지 확실하지 않다는 내용이었습니다. 이는 합리적인 판단입니다. 다른 Haiku와 Sonnet 실행에서는 웹 함수에 대해 언급한 적이 없습니다.

Opus는 더 나아갔습니다. 두 번의 실행 모두에서 Lambda 런타임 페이지가 웹 함수로 이어졌습니다. 이후 웹 함수 런타임 페이지, 샘플, "생성(create)" 가이드, 그리고 aws lambda-web deploy CLI 참조 문서를 읽었습니다. 명확하게 새로운 접근 방식을 향하고 있었습니다. 그러다가 두 실행 모두 파일 작성 전에 제 10턴 제한에 도달했습니다. 따라서 무엇을 작성했을지는 말할 수 없고, 단지 이 규칙이 사흘 전에 출시된 기능을 찾게 만들었다는 것만 말할 수 있습니다.

규칙의 비용: 총 42회의 코딩 실행 동안, 비용은 $2.51에서 $4.47로 증가했으며 (+78%) Sonnet의 평균 시간은 10초에서 18초가 되었습니다. 버전 고정(pins versions)을 위한 설정 작업이라면 저렴합니다. 하지만 작은 편집마다 이 규칙이 필요할지는 미지수입니다.

비교된 모델들

Opus는 가장 많이 정보를 조회하며, 주로 중립적인 질문(14개 중 12개)에 대해 검색했고, 다른 모델들(7~8개)보다 많았습니다. 또한 Opus만이 두 번의 기회 모두에서 Stripe 코딩 과제에 대해 검색했습니다. Haiku가 Sonnet보다 더 많이 검색했습니다. Sonnet은 기억에 의존하여 답변할 가능성이 가장 높았으며, 그렇게 말할 가능성도 가장 높았습니다.