OpenAI Responses API web search image results Jun 9 2026: 웹 검색 API 이미지 결과 추가

 

OpenAI 웹 검색 API에 이미지 결과 추가: 검색형 AI 앱이 달라지는 지점

2026년 6월 9일 공식 changelog 기준, 텍스트 검색에 이미지 결과 메타데이터가 붙는 변화입니다.

 

OpenAI 웹 검색 API에 이미지 결과가 붙었다

 

OpenAI는 2026년 6월 9일 API changelog에서 Responses API의 web_search가 텍스트 결과와 함께 이미지 결과를 반환할 수 있다고 안내했습니다. 이 변화는 이미지 생성 기능이 아니라, 검색형 AI 앱이 상품 사진, 장소, 이벤트, 레퍼런스 이미지를 출처와 함께 다루기 쉬워졌다는 뜻입니다.

OpenAI Responses API web search image results Jun 9 2026 업데이트를 처음 보면 “이미지를 만들어 준다는 말인가?” 하고 헷갈리기 쉽습니다. 제가 보기에는 생성 기능보다 검색 결과의 모양이 바뀐 쪽에 가깝습니다. 웹에서 찾은 이미지 결과와 관련 메타데이터가 응답 안으로 들어옵니다.

한국 사용자 입장에서는 상품 비교, 여행지 추천, 전시·행사 검색, 디자인 레퍼런스 조사처럼 글만으로 판단이 어려운 화면에서 먼저 차이가 납니다. 요약 문장만 보여주는 앱보다 이미지 후보와 원출처 페이지를 함께 보여주는 앱이 사용자의 확인 시간을 줄입니다.

실제로 확인할 부분은 네 가지입니다. `search_content_types`에 무엇을 넣는지, `image_result`를 어디서 읽는지, 출처 URL을 어떻게 저장하는지, 그리고 받은 `image_url`을 서비스 화면에 어디까지 노출할지입니다.

 

 

언제 무엇이 바뀌었나

 

Responses API와 내장 web search 도구는 2025년 3월 11일 공개됐고, 2026년 6월 9일에는 web_search 결과에서 image_result를 받을 수 있는 업데이트가 추가됐습니다. 날짜를 나눠 보면 오래된 web_search_preview 설명과 이번 기능을 섞어 이해할 위험이 줄어듭니다.

기준일은 2026년 6월 9일입니다. OpenAI Responses API web search image results Jun 9 2026이라는 긴 검색어가 필요한 이유도 여기에 있습니다. 같은 웹 검색이라도 예전 preview 통합 설명과 새 Responses API 문서가 검색 결과에서 섞입니다.

날짜	확인할 변화	독자가 봐야 할 지점
2025-03-11	Responses API와 web search, file search, computer use 공개	Responses API가 도구 호출 중심으로 넓어진 시점
2026-06-09	web_search가 텍스트와 함께 이미지 결과를 반환 가능	search_content_types, image_settings, web_search_call.results 확인 필요

여기서 볼 부분은 내 코드가 어떤 도구 이름과 응답 구조를 쓰는지입니다. legacy `web_search_preview`를 기준으로 만든 코드는 새 `web_search` 문서의 필터, 이미지 결과, include 구조를 그대로 기대하면 안 됩니다.

 

이미지 생성이 아니라 검색 결과 확장이다

 

모델이 새 이미지를 만드는 변화가 아닙니다. 웹 검색 결과에서 image_url, thumbnail_url, source_website_url, caption 같은 이미지 결과 메타데이터를 받을 수 있게 된 업데이트입니다.

이 기능은 프롬프트로 새 그림을 만드는 이미지 생성 API가 아닙니다. 검색 도구가 웹에서 찾은 이미지 결과를 응답 구조 안에 넣어 줍니다.

문서 기준으로 `image_result`에는 `image_url`, `source_website_url`, `thumbnail_url`, `caption` 같은 필드가 들어갈 수 있습니다. 다만 `thumbnail_url`과 `caption`은 항상 있다고 쓰기 어렵습니다. 가능한 경우에만 쓰이는 값으로 처리해야 합니다.

앱 화면에서는 `image_url`만 크게 보여주기보다 `source_website_url`을 같은 데이터로 남기는 편이 안전합니다. 사용자가 이미지를 보고 어디서 온 자료인지 바로 확인해야 답변 신뢰도와 권리 검토가 같이 따라옵니다.

 

 

어떻게 켜고 어디를 파싱해야 하나

 

이미지 검색을 쓰려면 web_search 도구 설정에 search_content_types를 넣고 image를 포함해야 합니다. 원시 이미지 결과가 필요하면 include에 web_search_call.results를 넣은 뒤, assistant 본문이 아니라 output 안의 web_search_call.results 배열에서 image_result 항목을 읽어야 합니다.

코드에서 확인할 때는 요청과 응답을 따로 봐야 합니다. 요청 쪽에서는 `tools` 안의 `web_search` 설정에 `search_content_types`를 넣고 `image`를 포함합니다. 텍스트 근거와 이미지 후보를 같이 보고 싶다면 `image`와 `text`를 함께 둡니다.

공식 문서에는 `image_settings`도 나옵니다. `max_results`는 이미지 결과 개수를 작게 시작할 때 유용하고, `caption`은 제공 가능한 경우 짧은 설명을 요청하는 옵션으로 보면 됩니다. 실제 반환 보장이나 완전한 대체 텍스트로 해석하면 곤란합니다.

응답 쪽에서 자주 놓치는 부분은 파싱 위치입니다. 기존 앱이 assistant message의 텍스트만 저장했다면 이미지 결과가 빠집니다. `include`에 `web_search_call.results`를 넣고, `output` 배열 안에서 `type`이 `web_search_call`인 항목을 찾은 뒤 `results`의 `image_result`를 읽어야 합니다.

 

검색형 AI 앱에서 달라지는 지점

 

상품 검색, 여행지 추천, 장소·이벤트 탐색, 디자인 레퍼런스 조사처럼 시각 확인이 중요한 앱은 텍스트 요약만으로 부족합니다. 이미지 결과가 들어오면 사용자는 답변의 설명, 이미지 후보, 원출처를 한 화면에서 대조할 수 있습니다.

텍스트 검색은 무엇인지 설명하는 데 강하지만, 지금 실제로 어떻게 보이는지 판단하는 데는 한계가 있습니다. 신제품 색상, 전시장 분위기, 매장 외관, 행사 포스터, 레퍼런스 디자인처럼 이미지를 확인해야 하는 검색 의도는 따로 있습니다.

한국 서비스에 붙인다면 저는 아래 순서로 테스트하겠습니다.

• 쇼핑 리서치: 최신 상품 사진과 출처 페이지를 함께 보여주고, 가격·스펙 요약은 텍스트 결과로 분리합니다.
• 여행·장소 추천: 랜드마크, 카페, 숙소, 전시 이미지를 보여주되 원출처 이동 경로를 같이 둡니다.
• 이벤트 탐색: 행사 포스터나 현장 사진 후보를 답변 옆에 배치하고 날짜 정보는 텍스트 근거로 다시 검증합니다.
• 디자인·마케팅 조사: 레퍼런스 이미지를 내부 메모에 넣기 전에 source_website_url을 남겨 권리 확인 경로를 보존합니다.

앱 품질이 자동으로 좋아진다는 뜻은 아닙니다. 사용자가 답변을 믿어도 되는지 판단할 때 필요한 시각 단서를 API 응답에서 더 직접적으로 다룰 수 있게 된 변화입니다.

 

 

 

실무 도입 체크리스트: 첫 테스트부터 운영 로그까지

 

첫 테스트는 image와 text를 함께 요청하고 image_result 개수, image_url, thumbnail_url, source_website_url, caption 존재 여부를 기록하는 방식이 적합합니다. 운영 단계에서는 도메인 필터, tool_choice, 캐시 키, 렌더링 실패 URL, 출처 저장 정책까지 같이 점검해야 합니다.

처음부터 큰 화면 개편을 할 필요는 없습니다. 작은 테스트 쿼리 하나로 Responses API가 어떤 구조를 돌려주는지 확인하는 편이 낫습니다. 예를 들어 `2026 서울 AI 전시 포스터와 공식 행사 정보`처럼 텍스트 근거와 이미지 후보가 둘 다 필요한 질의를 잡고, `search_content_types`를 `image`, `text` 조합으로 호출합니다.

체크할 항목은 다음 정도면 충분합니다.

• 요청: `tools`의 `type`이 `web_search`인지, `search_content_types`에 `image`가 들어갔는지 확인합니다.
• 응답: `web_search_call.results` 안에 `image_result`가 있는지, `image_url`과 `source_website_url`을 따로 저장할 수 있는지 봅니다.
• UI: 썸네일이 깨질 때 대체 표시가 있는지, 출처 링크가 이미지 옆에 남는지 확인합니다.
• 운영: `filters.allowed_domains` 또는 `filters.blocked_domains`로 출처 품질을 좁힐 필요가 있는지 실험합니다.
• 호출 제어: 검색이 반드시 필요한 화면이라면 `tool_choice`를 `auto`로만 둘지, required 또는 특정 도구 선택을 쓸지 검토합니다.

운영 로그에는 민감한 검색어보다 response id, tool call 상태, image_result 개수, source_website_url 목록, 렌더링 실패 URL 같은 진단 필드를 중심으로 남기는 쪽이 실용적입니다.

 

주의할 점: 결과 보장, 저작권, 캡션 한계

 

max_results는 실제 반환 개수를 보장한다는 뜻으로 쓰면 안 되고, caption도 항상 제공되는 완전한 대체 텍스트로 보면 안 됩니다. 특히 image_url을 받았다고 해서 블로그나 서비스에서 이미지를 자유롭게 재사용할 권리가 생기는 것은 아닙니다.

다만 이미지 결과가 모든 쿼리에서 항상 나온다고 쓰면 안 됩니다. 검색 가능성, 도구 호출 여부, 외부 웹 접근 설정, 결과 품질에 따라 달라집니다.

`caption`을 접근성 문구나 법적 설명처럼 고정하는 것도 위험합니다. 문서상 caption은 가능한 경우의 짧은 설명으로 보는 편이 맞습니다. 실제 서비스에서는 별도 alt text 정책과 검수 흐름이 필요합니다.

가장 중요한 경계는 image_url입니다. image_url은 사용권이 아닙니다. 콘텐츠 발행 앱이라면 이미지를 직접 재게시하기 전에 source_website_url, 원문 이용 조건, 썸네일 표시 정책을 확인해야 합니다. 특히 블로그 자동화나 쇼핑 큐레이션처럼 외부 이미지를 화면에 노출하는 서비스는 이 구분을 문서로 남겨야 합니다.

제가 이 업데이트를 긍정적으로 보는 이유는 이미지를 마음대로 쓸 수 있어서가 아닙니다. 출처가 있는 이미지 후보를 검색 응답 안에서 구조적으로 다룰 수 있게 됐기 때문입니다. OpenAI Responses API web search image results Jun 9 2026 업데이트의 실무 가치는 그 경계선을 지킬 때 생깁니다.

 

 

 

누가 바로 확인해야 하나

 

이미 텍스트 기반 AI 검색 앱을 운영하면서 상품, 장소, 이벤트, 디자인 레퍼런스처럼 시각 근거가 필요한 화면을 가진 팀은 먼저 확인할 만합니다. 반대로 이미지 생성, 폐쇄망 검색, 저작권 검토 없는 재배포가 목표라면 이번 업데이트만으로 요구사항을 해결하기 어렵습니다.

바로 확인할 팀은 Responses API를 이미 쓰고 있고, 검색 결과를 화면에 렌더링하거나 내부 리서치 도구로 저장하는 팀입니다. 특히 텍스트 요약 옆에 확인 가능한 이미지 후보가 필요한 서비스라면 작은 실험으로 차이를 볼 수 있습니다.

건너뛰어도 되는 경우도 있습니다. 사내 이미지 저장소만 검색하면 되는 팀은 웹 검색보다 파일 검색, 벡터 검색, DAM 연동이 더 맞을 수 있습니다. 이미지 편집이나 스타일 변환이 목표라면 이미지 생성·편집 API를 봐야 합니다. 외부 이미지를 권리 검토 없이 재게시해야 하는 구조라면 이 업데이트는 해결책이 아니라 추가 검토 지점입니다.

첫 확인은 단순합니다. 기존 텍스트 파서에 이미지 결과가 자동으로 들어올 것이라고 기대하지 말고, `web_search_call.results`를 별도 데이터로 저장할 수 있는지부터 확인하는 편이 좋습니다.

 

자주 묻는 질문

 

Q. OpenAI Responses API 웹 검색 이미지 결과는 이미지 생성 기능인가?
A. 아닙니다. 2026년 6월 9일 업데이트는 web_search가 웹에서 찾은 이미지 결과와 출처 메타데이터를 반환할 수 있게 된 검색 도구 업데이트입니다.

Q. search_content_types에 image만 넣는 것과 image, text를 같이 넣는 것은 무엇이 다른가?
A. image만 요청하면 이미지 결과 중심으로 확인하게 되고, image와 text를 함께 넣으면 텍스트 근거와 이미지 후보를 같이 다룹니다. 상품, 장소, 이벤트 검색 화면은 보통 둘을 함께 테스트하는 편이 판단하기 좋습니다.

Q. image_result에는 어떤 값이 들어오나?
A. 공식 문서 기준으로 image_url, source_website_url, thumbnail_url, caption 같은 필드를 확인할 수 있습니다. 다만 thumbnail_url과 caption은 항상 제공된다고 단정하지 말고 가능한 경우의 값으로 처리해야 합니다.

Q. 이미지 URL을 받으면 서비스에서 바로 재사용해도 되나?
A. 그렇게 보면 위험합니다. image_url은 검색 결과 메타데이터이지 사용권 허가가 아니므로, source_website_url과 원문 이용 조건을 확인하고 서비스의 썸네일 표시·재게시 정책을 따로 정해야 합니다.

Q. 기존 web_search_preview 통합도 그대로 쓰면 되나?
A. 기존 통합이 당장 깨진다는 뜻은 아니지만, 새 기능을 쓰려면 Responses API의 hosted web_search 기준으로 마이그레이션 범위를 확인해야 합니다. filters, external_web_access, return_token_budget, search_content_types 같은 제어 기능 차이를 회귀 테스트하는 편이 안전합니다.

함께 읽으면 좋은 글

 

• OpenEnv란 무엇인가: Hugging Face가 밀고 있는 에이전트 RL 실행 환경 표준 — AI UPDATES
• Claude Code 2.1.166 업데이트: fallbackModel과 도구 차단 규칙이 중요한 이유 — AI UPDATES
• Amazon Alexa AI 굿즈 디자인 출시: 프롬프트에서 티셔츠 주문까지 — AI UPDATES

참조 링크

 

• OpenAI API Changelog — 2026-06-09 v1/responses web_search 이미지 결과 업데이트의 원문 출처
• Web search guide — search_content_types, image_settings, web_search_call.results, image_result 필드를 확인한 구현 문서
• Create a model response — Responses API의 POST /v1/responses 요청 구조와 tools, include, tool_choice 확인용 reference