[OpenAI][Responses API] web search에서 user_location만 바뀌었는데 action.sources가 그대로일 때 어떤 diff 로그부터 먼저 남기나

IT 리서치 노트

[OpenAI][Responses API] web search에서 user_location만 바뀌었는데 action.sources가 그대로일 때 어떤 diff 로그부터 먼저 남기나

Responses API web search를 운영하다 보면 지역 문맥만 바꿨는데 답변에 달린 출처가 그대로라서 당황하는 경우가 있다. 2026년 7월 17일 기준 OpenAI 공식 문서를 다시 보면 `user_location`, `search_context_size`, `web_search_call.results`, `web_search_call.action.sources`는 각각 다른 역할을 가진다. 이 글은 user_location만 바뀌었는데 action.sources가 그대로일 때 어떤 diff 로그부터 남겨야 원인을 짧게 가를 수 있는지 정리한 것이다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 user_location을 바꿨는데 action.sources가 그대로라면 먼저 web_search_call.results까지 같이 받아 후보 집합이 바뀌었는지를 확인해야 한다. sources만 보면 최종 답변에 반영한 출처만 보이기 때문에, 검색 후보 자체가 안 바뀐 것인지 후보는 바뀌었는데 최종 근거가 같았던 것인지 분리되지 않는다.

그다음 순서가 search_context_size다. 지역 문맥이 충분한데도 후보 폭이 좁아 보일 때만 context 범위를 조정해야 한다. 반대로 지역 입력이 너무 넓거나 모호하면 context를 키워도 같은 출처만 반복될 수 있다.

2. 어디서 실제로 막히는가

실무에서 먼저 꼬이는 지점은 세 가지다. 첫째, 지역별 가격이나 정책을 묻는 질문인데 user_location을 바꿔도 답변 링크가 같으면 곧바로 모델 품질 문제로 본다. 둘째, sources만 저장하고 results는 저장하지 않아 검색 후보 변화가 있었는지 자체를 모른다. 셋째, 이 상태에서 search_context_size만 키워 토큰 비용만 올린다.

하지만 OpenAI 문서는 results와 action.sources를 서로 다른 include 값으로 나눈다. 이는 후보 집합과 최종 출처가 다를 수 있다는 뜻이다. 또 web search 가이드는 approximate user location과 search_context_size를 별도 설정으로 설명한다. 즉 지역 문맥, 검색 폭, 최종 출처 선택은 서로 다른 축이다.

예를 들어 미국 기준 가격표를 묻는 질문에서 user_location을 한국으로 바꿨는데도 sources가 그대로라면 최소 세 가지 가설이 가능하다. 질문 자체가 지역 비의존이었을 수 있고, 후보는 달라졌지만 모델이 동일한 전역 문서를 최종 근거로 골랐을 수 있고, 지역 입력이 city나 timezone까지 충분히 들어가지 않아 후보 변화가 거의 없었을 수 있다.

• 증상: user_location을 바꿨는데 답변 출처가 그대로다.
• 실패: action.sources만 보고 검색 후보가 안 바뀌었다고 단정한다.
• 막힘: results를 안 남겨 후보 집합 diff를 복원하지 못한다.
• 누락: country만 넣고 region, city, timezone을 비워 둔다.

증상	먼저 볼 값	판단 기준
sources가 그대로다	results + action.sources	후보 집합과 최종 근거를 분리한다
후보도 그대로다	user_location 상세값	country만 넣지 말고 region, city, timezone까지 본다
후보는 달라졌는데 답변이 얕다	search_context_size	문맥 폭을 그다음에 키운다

3. 실무에서 적용하는 순서

실무 점검 순서는 다섯 단계면 충분하다. 먼저 동일 프롬프트로 두 번 호출하되 user_location만 바꾼다. 두 번째로 include에 results와 action.sources를 같이 넣는다. 세 번째로 같은 요청 ID 기준으로 후보 집합이 달라졌는지 본다. 네 번째로 후보까지 그대로면 user_location 상세값을 넓힌다. 마지막으로 그래도 후보 폭이 좁으면 search_context_size를 조정한다.

1. 프롬프트는 고정하고 user_location만 바꿔 두 번 호출한다.
2. results와 action.sources를 같이 include한다.
3. 같은 질문의 후보 집합 diff를 먼저 본다.
4. 후보까지 같으면 region, city, timezone을 보강한다.
5. 마지막에만 search_context_size를 조정한다.

user_location diff 메모

prompt_fixed=true
compare_by=request_id
us_location=US/California/San Francisco
kr_location=KR/Seoul/Seoul
include_results=true
include_sources=true
search_context_size=medium

이 순서가 좋은 이유는 지역 문맥 실패와 출처 선택 실패를 분리해 주기 때문이다. 후보 집합 diff를 먼저 보면 user_location이 실제로 검색층에 반영됐는지 확인할 수 있고, 그 다음에야 왜 최종 답변 출처가 같았는지를 읽을 수 있다.

4. 공식 문서와 예시 화면으로 확인하기

첫 자료는 OpenAI web search 가이드의 user location 예시다. 지역별 가격, 법규, 배송 가능 여부처럼 문서 자체가 지역에 따라 갈리는 질문에서는 이 값이 먼저 달라지면 검색 후보가 달라질 수 있다.

OpenAI는 web search 도구에 approximate user location을 넣어 country, region, city, timezone 문맥을 함께 보낼 수 있다고 설명한다.

즉 user_location은 단순 메타데이터가 아니라 검색 후보를 바꿀 수 있는 입력이다. 그런데 이 값을 바꿨는데도 action.sources가 그대로라면, 검색 결과가 실제로 안 바뀐 것인지, 바뀌었지만 답변 출처가 같았던 것인지부터 나눠 봐야 한다.

두 번째 자료는 search context size 설명 구간이다. OpenAI는 모델이 검색 결과에서 미리 읽는 문맥 양을 low, medium, high로 조절할 수 있다고 안내한다.

search_context_size는 검색 문맥의 폭을 조절하지만, 실제로 어떤 출처를 기록으로 되돌려받는지와는 다른 레버다.

그래서 지역 문맥이 의심되는 상황에서 곧바로 context size만 키우면 토큰만 늘고, 왜 sources가 그대로였는지는 여전히 설명되지 않는다. user_location과 include 로그를 먼저 같이 남겨야 순서가 잡힌다.

세 번째 자료는 Responses API create reference다. 여기서는 `web_search_call.results`와 `web_search_call.action.sources`가 서로 다른 include 값으로 분리돼 있다.

Responses API reference는 results와 action.sources를 서로 다른 include 값으로 제공한다.

이 분리가 핵심이다. user_location을 바꾼 뒤 sources가 그대로라면 먼저 results까지 같이 받아 후보 집합이 바뀌었는지 확인해야 한다. 후보도 같다면 지역 입력이 충분하지 않았을 수 있고, 후보는 달라졌는데 sources만 같다면 모델이 같은 문서를 최종 근거로 고른 것이다.

실무에서는 user_location 변경 전후를 어떤 축으로 비교할지 표가 있어야 한다. 같은 프롬프트를 미국과 한국 기준으로 두 번 쳤는데 출처가 같다고 해서 바로 실패라고 보면 안 된다.

user_location 변경 전후를 results, action.sources, search_context_size로 나눠 보는 diff 표다.

이미 include와 search_context_size 순서 글이 큰 갈래를 다뤘다면, 이번 표는 지역 문맥이 섞였을 때 어디부터 로그를 남길지 더 좁힌다.

마지막 자료는 안전한 재현용 호출 예시다. 지역 입력과 include를 한 번에 남겨야 나중에 요청 ID 기준으로 전후 차이를 정확히 비교할 수 있다.

user_location, results, action.sources를 함께 남기는 web search 호출 예시다.

이 정도 구조만 있어도 results와 action.sources 비교 글에서 말한 후보 집합 대 최종 출처 차이를 지역 문맥까지 포함해 재현할 수 있다.

5. 주의사항과 리스크

첫 번째 리스크는 action.sources만 저장한 뒤 지역 문맥이 안 먹었다고 단정하는 것이다. 두 번째는 user_location을 country만 넣고 끝내는 것이다. 세 번째는 지역 diff 재현 없이 search_context_size만 키워 비용을 늘리는 것이다.

운영 전에는 최소한 프롬프트, user_location, search_context_size, results, action.sources 다섯 항목을 공통 로그에 남기는 편이 좋다. 그래야 지역 문맥, 검색 후보, 최종 출처 선택을 같은 요청 묶음으로 읽을 수 있다.

• sources가 같다고 후보까지 같다고 단정하지 않는다.
• user_location은 가능하면 region, city, timezone까지 채운다.
• context size 조정은 include diff 확인 뒤에 한다.

6. 결론

Responses API web search에서 user_location만 바뀌었는데 action.sources가 그대로라면 먼저 results diff를 봐야 한다. 후보 집합과 최종 출처를 분리한 뒤에야 지역 입력 부족인지, 전역 문서를 공통 근거로 고른 것인지, context 폭이 좁은지 판단할 수 있다.

관련 흐름으로는 include와 search_context_size 순서 글, results와 action.sources 비교 글, annotations만 저장하면 부족할 때 results와 action.sources를 같이 남기는 글을 같이 보면 grounding 로그와 지역 문맥 설정, 그리고 turn 저장 설계를 한 줄로 정리하기 쉽다.

7. 참고 링크

1. https://developers.openai.com/api/docs/guides/tools-web-search
2. https://developers.openai.com/api/reference/resources/responses/methods/create/