[OpenAI][Responses API] file search와 code interpreter를 한 요청에 붙일 때 어떤 결과를 저장하고 무엇을 재실행 기준으로 삼나

카테고리 없음 2026. 7. 13. 09:12

IT 리서치 노트

[OpenAI][Responses API] file search와 code interpreter를 한 요청에 붙일 때 어떤 결과를 저장하고 무엇을 재실행 기준으로 삼나

Responses API에서 file search와 code interpreter를 한 요청에 같이 붙이면 답변 품질은 좋아지기 쉽지만, 운영 로그를 한 덩어리로 남기면 나중에 무엇을 다시 돌려야 하는지 모호해진다. 2026년 7월 13일 기준 OpenAI 공식 문서를 다시 보면 file search는 vector store와 metadata filter로 근거 범위를 좁히는 도구이고, code interpreter는 Python 실행과 생성 파일을 포함한 계산 도구다. 이 글은 두 도구를 함께 쓸 때 어떤 결과를 저장하고, 어떤 경우에 검색만 재실행하고 어떤 경우에 계산까지 다시 돌릴지 기준을 정리한 것이다.

1. 개요

결론부터 말하면 file search와 code interpreter를 같은 응답 안에서 썼더라도 저장 단위는 분리하는 편이 맞다. file search는 어떤 문서 집합과 필터로 근거를 찾았는지가 핵심이고, code interpreter는 어떤 입력 파일을 바탕으로 어떤 생성 파일을 만들었는지가 핵심이다. 따라서 재실행도 '검색만 다시 할지'와 '계산까지 다시 돌릴지'를 따로 판단해야 운영 비용이 줄어든다.

이미 remote MCP fallback 글이 도구 장애 시 어떤 근거 경로를 먼저 고르는지 다뤘다면, 이번 글은 built-in tool 둘을 같이 쓸 때 저장과 재실행 기준을 다룬다. 질문 routing 다음 단계의 운영 로그 설계라고 보면 된다. vector store를 갱신했는데도 답변이 그대로 보일 때 search freshness와 generated file 재사용을 어디서 나눌지는 후속 글에서 이어서 볼 수 있다.

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

실무에서 가장 자주 생기는 문제는 세 가지다. 첫째, file search가 찾은 근거 문서와 code interpreter가 만든 차트나 CSV를 하나의 final answer 텍스트만 남기고 끝낸다. 둘째, 결과가 이상할 때 검색 범위를 다시 좁혀야 하는지, 계산 입력 파일을 다시 바꿔야 하는지 구분하지 못한다. 셋째, 응답을 재생성할 때 처음부터 모든 도구를 다시 돌려 불필요한 토큰과 실행 시간을 낭비한다.

OpenAI 문서는 file search를 vector store 기반 검색 도구로 설명하고, metadata filtering과 결과 개수 제어를 예시로 보여 준다. 반면 code interpreter는 모델이 Python을 실행하고 필요하면 생성 파일을 응답 일부로 반환할 수 있다고 설명한다. 즉 file search는 '무엇을 근거로 삼았는가'를 남겨야 하고, code interpreter는 '무엇을 계산했고 어떤 산출물이 나왔는가'를 남겨야 한다. 둘을 같은 필드 하나로 뭉치면 재현성과 감사성이 동시에 떨어진다.

증상: 결과가 이상한데 검색 문제인지 계산 문제인지 바로 안 갈린다.
실패: final answer 텍스트만 저장하고 근거 문서 id나 생성 파일 id를 안 남긴다.
막힘: 같은 응답을 재실행할 때 모든 도구를 처음부터 다시 돌린다.
누락: 검색 범위 변경과 계산 입력 변경을 다른 이벤트로 기록하지 않는다.

이상 신호	먼저 볼 층	이유
엉뚱한 근거를 인용한다	file_search filter와 selected file ids	검색 범위가 잘못됐을 수 있다
차트나 CSV 결과가 틀리다	code_interpreter input/generated files	계산 입력이나 산출물 검증이 필요하다
재실행 비용이 너무 크다	도구별 재실행 기준	검색과 계산을 같이 다시 돌릴 필요가 없을 수 있다

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

실무에서 가장 덜 꼬이는 순서는 다섯 단계다. 먼저 file search와 code interpreter를 각각 어떤 질문에 쓰는지 라벨을 분명히 한다. 두 번째로 file search는 vector store ids, filters, 선택된 파일 id를 응답 로그에 남긴다. 세 번째로 code interpreter는 입력 파일 id, 생성 파일 id, 검증 실패 시 재실행 조건을 별도 필드로 남긴다. 네 번째로 사용자에게 보여 준 최종 답변과 도구별 근거/산출물 로그를 분리한다. 마지막으로 이상 신호가 생기면 검색 재실행과 계산 재실행 중 하나만 선택해 먼저 돌린다.

도구별 역할을 먼저 라벨링한다.
file search는 범위와 선택 근거를 남긴다.
code interpreter는 입력 파일과 생성 파일을 남긴다.
최종 답변 텍스트와 도구 로그를 분리 저장한다.
이상 신호에 따라 검색만 또는 계산만 재실행한다.

이 구조를 쓰면 예를 들어 근거 문서가 바뀌었을 때는 vector store나 filter만 조정해 file search만 다시 돌릴 수 있다. 반대로 문서는 맞는데 차트 축이 이상하면 code interpreter 입력 파일과 생성 파일만 다시 점검하면 된다. 두 도구를 분리하지 않으면 이런 선택이 안 되고, 결국 토큰과 실행 시간을 매번 전체 재실행에 써 버리게 된다.

재실행 판정 메모

if (evidence_changed) rerun = ["file_search"];
if (chart_validation_failed) rerun = ["code_interpreter"];
if (both_changed) rerun = ["file_search", "code_interpreter"];

운영 로그에서 도구 경계를 명확히 남겨 두면 나중에 structured output을 붙이든, MCP를 추가하든, 도구별 감사 범위를 더 쉽게 확장할 수 있다. built-in tool이 많아질수록 저장 경계를 먼저 나누는 편이 오히려 단순하다.

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

첫 자료는 Responses API 소개 구간이다. 여기서는 web search, file search, code interpreter, remote MCP가 같은 built-in tool 층에서 소개된다는 점을 먼저 본다. 오늘 주제는 그중 file search와 code interpreter를 함께 쓸 때 어떤 결과를 남겨야 나중에 재실행 범위를 줄일 수 있는가다.

Responses API 문서는 file search와 code interpreter를 같은 built-in tool 층에서 소개한다.

같은 tools 배열에 들어간다고 해서 저장 전략까지 같지는 않다. file search는 근거 문서 검색 결과를, code interpreter는 계산 과정과 생성 파일을 남겨야 하므로 감사 포인트가 다르다.

두 번째 자료는 file search의 metadata filtering 구간이다. file search는 vector store 범위와 metadata filter, 결과 개수로 근거를 좁혀 나가는 도구다. 재실행이 필요할 때도 대개 '어떤 문서를 찾았는지'와 '어떤 필터를 썼는지'가 가장 중요하다.

file search 가이드는 vector store 범위와 metadata filter를 저장해 근거 검색을 재현할 수 있음을 보여 준다.

즉 file search는 결과 텍스트 전체보다 검색 범위와 필터, 선택된 근거 문서 id를 남기는 편이 실무적으로 더 유용하다. 그래야 나중에 같은 문서셋으로 재질문할지, 다른 문서셋으로 넓힐지 판단이 선다.

세 번째 자료는 Code Interpreter 가이드다. 여기서는 모델이 Python을 실행하고, 경우에 따라 이미지나 CSV 같은 생성 파일까지 돌려줄 수 있다는 점을 먼저 확인한다. 이 특성 때문에 code interpreter는 단순 텍스트 응답보다 실행 산출물과 입력 파일 버전을 함께 남겨야 한다.

Code Interpreter 가이드는 Python 실행 결과와 생성 파일이 응답 일부가 될 수 있음을 보여 준다.

특히 차트, CSV, 표처럼 재가공 산출물이 생기는 흐름에서는 '최종 답변 텍스트만 저장'으로는 부족하다. 어떤 입력 파일과 어떤 지시로 무엇을 생성했는지를 남기지 않으면 같은 결과를 다시 검증하기 어렵다.

실무에서는 두 도구의 저장 경계를 한 번에 보여 주는 표가 필요하다. file search는 근거 검색 재현성이 핵심이고, code interpreter는 계산 산출물 재현성이 핵심이라는 점을 같은 표에 놓아야 나중에 재실행 비용을 줄일 수 있다.

file search와 code interpreter를 저장 경계와 재실행 기준으로 나눈 표다.

이 표를 기준으로 보면 한 요청 안에서 두 도구를 같이 썼더라도 모든 것을 한 덩어리 로그로 남길 필요가 없다. 이미 built-in tools 구조 글이 도구 묶음을 나눴다면, 이번 글은 저장과 재실행 기준까지 더 좁히는 후속편이다.

마지막 자료는 한 요청에서 file search와 code interpreter를 같이 쓸 때 audit 로그를 어떻게 쪼개는지 예시로 보여 준다. 근거 문서 id와 생성 파일 id를 분리해서 남기면 검색만 다시 할지, 계산까지 다시 할지 빠르게 결정할 수 있다.

file search 결과와 code interpreter 산출물을 따로 기록하는 Responses 감사 로그 예시다.

이 구조는 structured output과 function calling 경계 글과도 닿아 있다. 출력 스키마만 강제해도 검색 근거와 계산 산출물을 섞어 저장하면 운영은 여전히 불투명해진다.

5. 주의사항과 리스크

첫 번째 리스크는 selected file ids를 남기지 않아 근거 검색을 다시 재현할 수 없게 되는 것이다. 두 번째 리스크는 code interpreter가 만든 생성 파일 id를 저장하지 않아 차트나 CSV를 다시 검증할 수 없게 되는 것이다. 세 번째 리스크는 검색과 계산을 항상 같이 재실행해 비용과 지연을 불필요하게 키우는 것이다.

운영 전에 확인할 것은 네 가지다. 어떤 vector store를 썼는지, 어떤 filter를 적용했는지, 어떤 입력 파일을 계산에 넣었는지, 어떤 생성 파일을 사용자에게 보여 줬는지다. 이 네 항목이 빠지면 재현성과 감사성이 함께 약해진다.

file search는 근거 범위와 선택 파일을 남긴다.
code interpreter는 입력 파일과 생성 파일을 남긴다.
재실행은 도구별 조건에 따라 따로 판정한다.

6. 결론

Responses API에서 file search와 code interpreter를 함께 쓸 때 가장 중요한 것은 답변 텍스트보다 도구별 저장 경계를 먼저 나누는 일이다. file search는 근거 검색 재현성이, code interpreter는 계산 산출물 재현성이 핵심이므로 재실행 기준도 따로 가져가는 편이 맞다. 그래야 검색만 다시 할지 계산까지 다시 돌릴지 짧게 결정할 수 있다.

file search는 vector store와 filter, 선택 근거를 저장한다.
code interpreter는 입력 파일과 생성 파일을 저장한다.
재실행은 검색과 계산을 분리해 판정한다.

ABOUT ME

FullStack Lab FullStack Lab