요약: Anthropic은 2026년 6월 Claude API의 web search와 web fetch 도구에 response_inclusion 파라미터를 추가해, 에이전트 워크플로우에서 이미 소비한 검색 결과 블록을 API 응답에서 제외할 수 있게 했습니다. 긴 리서치 에이전트를 운영하는 팀이라면 응답 크기, 로그 저장량, 후속 턴 비용을 줄이는 데 바로 활용할 수 있는 업데이트입니다.
검색을 붙인 에이전트는 처음에는 간단해 보입니다. 사용자가 질문하고, 모델이 웹 검색을 호출하고, 검색 결과를 읽고, 답변합니다. 문제는 작업이 길어질 때 시작됩니다. 여러 번 검색하고, 각 검색 결과를 도구 블록으로 남기고, 그 블록이 다시 다음 턴 문맥에 포함되면 응답과 로그가 빠르게 커집니다.
특히 리서치, 경쟁사 분석, 문서 QA, 뉴스 모니터링처럼 검색 결과를 많이 쓰는 기능은 한 번의 답변보다 “중간 근거 블록 관리”가 더 중요합니다. 모델은 이미 검색 결과를 읽고 답변에 반영했는데, 애플리케이션은 원본 결과 블록까지 계속 들고 다닙니다. 이러면 저장 비용, 네트워크 전송량, 디버깅 로그 크기, 후속 처리 비용이 모두 늘어납니다.
Anthropic의 2026년 6월 11일 release note에 따르면 web search tool과 web fetch tool은 web_search_20260318, web_fetch_20260318 버전에서 response_inclusion 파라미터를 지원합니다. 이 파라미터는 agentic workflow에서 소비된 result block을 API response에서 떨어뜨리는 용도로 설명되어 있습니다. 베타 헤더 없이 사용할 수 있다는 점도 운영 적용에 유리합니다.
모든 검색 기능에 바로 적용할 필요는 없습니다. 사용자가 검색 결과 원문을 직접 확인해야 하는 제품이라면 결과 블록을 유지해야 합니다. 예를 들어 법률 검색, 논문 검색, 출처 기반 리포트처럼 근거 원문 표시가 핵심인 서비스는 원본 결과를 보존하는 편이 낫습니다.
반대로 모델이 검색 결과를 읽고 요약, 분류, 판단만 해주면 되는 워크플로우에서는 response_inclusion을 적극 검토할 만합니다. 예를 들어 “오늘 AI API 업데이트를 읽고 개발자에게 중요한 변경만 요약해줘”, “경쟁사 가격 페이지를 확인하고 변경 여부만 알려줘”, “문서에서 파라미터 사용법을 찾아 코드 예시로 정리해줘” 같은 작업입니다.
판단 기준은 간단합니다. 사용자 또는 운영자가 원본 result block을 나중에 꼭 다시 봐야 하면 유지합니다. 답변에 필요한 근거만 요약 형태로 남기면 충분하면 제외합니다.
response_inclusion으로 결과 블록을 제외하더라도 출처 추적을 포기하면 안 됩니다. 검색 결과 전체를 저장하지 않더라도 최소한의 감사 정보는 남겨야 합니다. 추천 구조는 “원본 블록은 제외하되, 출처 메타데이터는 별도 저장”입니다.
예를 들어 다음 정보는 가볍게 남길 수 있습니다.
이 정도만 있어도 나중에 답변 품질을 점검할 수 있습니다. 전체 검색 결과 HTML이나 긴 텍스트 블록을 매번 저장할 필요는 없습니다. 저장해야 한다면 압축, TTL, 샘플링을 적용하는 편이 좋습니다.
출처 표시가 필요한 사용자 화면에서는 답변 본문에 핵심 URL만 남기면 됩니다. 사용자가 실제로 클릭할 수 있는 링크 2~5개면 충분한 경우가 많습니다. 검색 결과 20개를 그대로 보여주는 것은 정보가 많아 보이지만 제품 경험은 나빠집니다.
응답 크기 절감은 분명한 장점입니다. 하지만 더 중요한 효과는 문맥 오염을 줄이는 것입니다. 긴 검색 결과 블록이 후속 턴에 남아 있으면 모델은 이미 필요 없어진 정보를 계속 참고할 수 있습니다. 오래된 검색 결과, 낮은 품질의 스니펫, 중복된 문서가 쌓이면 다음 판단의 노이즈가 됩니다.
에이전트 워크플로우에서는 “모든 것을 기억하는 것”보다 “필요한 것만 압축해 남기는 것”이 더 안정적입니다. 검색 결과를 읽은 뒤에는 모델 또는 애플리케이션이 핵심 사실, 출처 URL, 불확실성만 구조화해 저장하고 원본 블록은 버리는 방식이 좋습니다.
이 패턴은 RAG 시스템의 chunk 관리와 비슷합니다. 원문을 무한히 컨텍스트에 넣는 것이 아니라, 현재 작업에 필요한 근거만 추려 넣어야 합니다. response_inclusion은 이 압축 전략을 API 응답 단계에서 도와주는 옵션으로 볼 수 있습니다.
실무 구현은 다음 순서가 현실적입니다.
response_inclusion으로 소비된 result block 제외를 적용한다.이렇게 하면 기본 운영 비용을 낮추면서도 디버깅 가능성을 남길 수 있습니다. 모든 요청을 완전 로그로 저장하는 대신, 문제 있는 요청만 깊게 파는 방식입니다.
품질 테스트도 필요합니다. 원본 블록을 제외하기 전후로 답변 정확도, 출처 누락률, 평균 응답 크기, 평균 지연 시간을 비교해야 합니다. 단순히 비용이 줄었다고 성공은 아닙니다. 출처 누락이 늘거나 답변이 불명확해지면 요약 저장 구조를 보강해야 합니다.
가장 먼저 적용하기 좋은 곳은 내부 운영 에이전트입니다. 예를 들어 매일 릴리즈 노트를 읽고 변경 사항을 요약하는 봇, 경쟁사 페이지 변경 감지 봇, 고객 피드백 분류 봇입니다. 이런 기능은 원본 검색 블록을 매번 사용자에게 보여줄 필요가 적고, 결과 요약과 URL만 있으면 충분합니다.
두 번째는 개발자 문서 검색 도우미입니다. 사용자는 긴 검색 결과보다 정확한 코드 예시와 공식 문서 링크를 원합니다. 원본 블록을 계속 응답에 포함하기보다, 답변에는 사용법과 링크만 남기고 내부 로그에는 참조 URL을 저장하는 편이 낫습니다.
반대로 규제 산업, 법무, 의료처럼 근거 원문 보존이 중요한 곳은 신중해야 합니다. 이 경우에는 result block 제외보다 보존 정책, 감사 로그, 사용자 인용 표시가 더 중요합니다.
response_inclusion 적용을 검토한다.Claude web search와 web fetch의 response_inclusion은 화려한 기능은 아니지만, 검색 에이전트를 오래 운영해본 팀에게는 체감이 큽니다. 검색 결과를 무조건 들고 가는 대신 필요한 근거만 남기는 구조로 바꾸면 비용, 지연 시간, 문맥 오염을 동시에 줄일 수 있습니다. 에이전트 품질은 더 많은 컨텍스트가 아니라 더 잘 정리된 컨텍스트에서 나옵니다.