[OpenAI][Responses API] web search incident를 같은 티켓에서 다룰 때 request config, answer diff, retrieval drift를 어떤 diff 템플릿으로 남기나

IT 리서치 노트

[OpenAI][Responses API] web search incident를 같은 티켓에서 다룰 때 request config, answer diff, retrieval drift를 어떤 diff 템플릿으로 남기나

OpenAI Responses API의 web search incident를 티켓 한 장에서 다루다 보면 request config 차이, answer diff, retrieval drift가 한 댓글에 뒤섞이기 쉽다. 2026년 7월 26일 기준 OpenAI 공식 문서를 다시 보면 citations가 붙은 answer layer와 web_search_call.action.sources, web_search_call.results는 같은 URL처럼 보여도 서로 다른 층이다. 이 글은 incident를 같은 티켓에서 다룰 때 무엇을 어떤 칸으로 남겨야 다음 사람이 request config부터 answer, retrieval까지 같은 순서로 조회하고 비교하고 저장할 수 있는지 정리한다.

목차

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

1. 개요

결론부터 말하면 OpenAI web search incident 티켓은 네 칸으로 고정하는 편이 가장 빠르다. 먼저 request config를 적고, 그다음 answer layer를 적고, 이어서 action.sources를 적고, 마지막에 raw results를 적는다. 같은 URL이 두 칸에 보이더라도 answer와 retrieval을 같은 배열에 합치지 않는 것이 핵심이다.

즉 ticket template의 기본 순서는 config, answer, trace, raw results다. 이 순서를 고정해 두면 incident 허브 글에서 잡은 큰 분기를 실제 운영 티켓으로 옮길 수 있고, raw results 저장 범위 글과도 자연스럽게 이어진다.

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

현장에서 먼저 꼬이는 지점은 네 가지다. 첫째, query 문자열이 같다는 이유로 request config를 생략한다. 둘째, assistant text와 cited URL을 적지 않고 raw results 비교부터 시작한다. 셋째, action.sources와 citations를 모두 sources라는 한 칸에 넣는다. 넷째, 분류가 끝난 뒤에도 다음 사람이 다시 조회할 수 있게 값이 저장되지 않는다.

OpenAI 문서는 층을 분리해 둔다. web search guide는 output과 citations를 사용자에게 보이는 answer layer로 설명하고, Responses reference와 items list reference는 web_search_call.action.sources, web_search_call.results를 별도 include 값으로 제공한다. 즉 config와 answer와 tool trace와 retrieval 후보는 처음부터 다른 구조다. 티켓 메모도 이 구조를 따라가야 사람이 바뀌어도 같은 판단을 재현할 수 있다.

이 분리를 안 하면 두 가지 비용이 생긴다. 첫 번째는 answer가 실제로 달라졌는데 retrieval diff만 길게 조사하는 비용이다. 두 번째는 request config가 달랐는데도 persistence 버그처럼 오해하는 비용이다. 둘 다 조회 순서가 없어서 생긴다.

• 증상: 같은 incident 티켓 안에 query, answer, source URL, candidate URL이 한 문단으로 섞인다.
• 실패: request config를 저장하지 않아 비교 기준이 사라진다.
• 막힘: answer layer와 action.sources를 같은 칸에 적어 user-visible change와 tool-trace change를 구분 못 한다.
• 누락: raw results는 적는데 cited URL과 assistant text hash는 안 적는다.

섞이기 쉬운 값	따로 적어야 하는 이유	먼저 볼 위치
query 문자열과 실제 request config	user_location, search_context_size, include가 다르면 같은 호출이 아니다	request config 칸
cited URL과 action.sources URL	하나는 answer layer, 하나는 tool trace다	answer 칸과 trace 칸
action.sources와 raw results	retrieval 후보 전체와 실제 참조 source는 다르다	trace 칸과 raw results 칸

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

가장 실용적인 순서는 여섯 단계다. 1단계에서 request config를 조회하고 저장한다. 2단계에서 assistant text hash와 cited URL을 비교한다. 3단계에서 action.sources를 조회하고 저장한다. 4단계에서 raw results를 조회하고 저장한다. 5단계에서 classification을 한 줄로 적는다. 6단계에서 follow-up 글 또는 runbook 링크를 붙인다.

1. request config를 먼저 조회하고 같은 티켓에 저장한다.
2. assistant text hash와 cited title을 비교한다.
3. action.sources를 조회해 trace 칸에 붙인다.
4. raw results를 조회해 후보 칸에 붙인다.
5. answer diff인지 retrieval drift인지 분류를 입력한다.
6. 후속 runbook 링크를 저장해 다음 작업자를 연결한다.

실제 운영에서는 response retrieve, items list, 저장된 trace 파일, 내부 incident 티켓 네 군데만 오가면 충분하다. 핵심은 조회 순서를 바꾸지 않는 것이다. answer가 바뀌었는지 확인하기 전에 raw results부터 복사하면 user-visible impact가 늦게 잡히고, config를 안 적으면 같은 query 문자열에 속아 다른 호출을 같은 사건처럼 다루게 된다.

ticket checklist

1. response retrieve에서 request config를 조회한다
2. assistant text hash와 cited URL을 비교한다
3. items list include로 action.sources를 조회한다
4. items list include로 raw results를 조회한다
5. classification 칸에 answer_diff 또는 retrieval_drift를 입력한다
6. follow-up 링크를 저장한다

이렇게 하면 같은 티켓을 여럿이 돌려 보더라도 값이 다시 흩어지지 않는다. 특히 annotations까지 바뀌는 answer diff 글과 request config 분기 글을 follow-up 링크로 붙여 두면 next action도 짧아진다.

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

첫 화면은 answer 층을 어디서 끊어야 하는지 다시 고정한다. OpenAI web search guide는 output text와 citations를 사용자에게 보이는 근거 층으로 설명한다.

OpenAI web search guide는 output text와 citations를 user-visible answer layer로 설명한다.

따라서 같은 incident 티켓 안에서도 answer diff는 이 층부터 적어야 한다. annotations와 assistant text 변화가 있으면 retrieval 후보 변화와 같은 칸에 적지 않는 편이 좋다.

두 번째 자료는 Responses create reference다. 이 문서는 include 값으로 web_search_call.action.sources를 따로 열 수 있다고 보여 준다.

Responses create reference는 action.sources를 별도 include 값으로 여는 구조를 보여 준다.

즉 ticket template에서도 action.sources는 answer 본문과 다른 필드로 남겨야 한다. citations와 같은 URL이 보여도 용도가 다르기 때문이다.

세 번째 자료는 items list reference다. 여기서는 web_search_call.results와 web_search_call.action.sources를 나란히 include할 수 있다.

items list reference는 raw results와 action.sources를 별도 include 값으로 분리한다.

이 분리가 바로 ticket template의 핵심이다. request config, answer layer, action.sources, raw results를 네 칸으로 나누면 같은 티켓에서도 분기 판단이 짧아진다.

실무에서는 긴 자유서술보다 고정 칸이 더 유용하다. 같은 incident 티켓 안에서 무엇을 저장하고 무엇을 비워 둘지 먼저 정해 두면 다음 호출자도 같은 순서로 조회하고 비교하고 저장할 수 있다.

request config, answer layer, action.sources, raw results를 나눠 적는 diff 템플릿 표다.

이미 incident 허브 글이 큰 분기를 잡아 줬다면, 이번 표는 티켓 한 장 안에 그 분기를 실제로 남기는 운영판이다.

마지막 자료는 실제 ticket 메모 예시다. 조회, 비교, 저장, 분류를 한 메모에 남기면 후속자가 raw results만 열지 않고 request config부터 다시 따라갈 수 있다.

같은 incident 티켓에 diff 값을 남기는 예시 메모다.

이 정도 구조만 있어도 answer diff와 retrieval drift를 한 문장으로 섞는 실수가 크게 줄어든다. 또 annotations 기반 answer diff 글과 request config 분기 글로 어디서 더 파고들지도 바로 정해진다.

5. 주의사항과 리스크

첫 번째 리스크는 request config 없이 cited URL만 비교하는 것이다. 두 번째 리스크는 answer layer와 trace layer를 같은 칸에 적어 분류 기준이 섞이는 것이다. 세 번째 리스크는 raw results를 항상 복사해 두고도 classification을 안 적는 것이다.

운영 전에 확인할 때는 최소한 query hash, user_location, search_context_size, assistant text hash, cited URL, action.sources URL, raw results URL을 같은 trace id에 붙여 두는 편이 좋다. 값이 많아 보여도 칸이 분리되어 있으면 읽기는 오히려 짧아진다.

• request config를 빼면 자연스러운 drift도 버그처럼 보일 수 있다.
• answer layer와 action.sources는 같은 URL이라도 역할이 다르다.
• classification 한 줄이 없으면 follow-up이 다시 길어진다.

6. 결론

OpenAI web search incident를 같은 티켓에서 다룰 때는 자유서술보다 네 칸 템플릿이 훨씬 강하다. request config, answer layer, action.sources, raw results를 이 순서로 조회하고 저장하고 분류하면 같은 사건 안에서도 answer diff와 retrieval drift를 짧게 나눌 수 있다.

• config를 먼저 적고 answer를 그다음에 적는다.
• action.sources와 raw results는 retrieval 층 안에서도 따로 저장한다.
• follow-up 링크로 incident 허브 글과 answer diff 글을 붙여 두면 다음 작업이 빨라진다.

7. 참고 링크

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