[OpenAI][Responses API] remote MCP 서버 응답이 흔들릴 때 file search와 web search fallback 순서를 어떻게 나누나

IT 리서치 노트

[OpenAI][Responses API] remote MCP 서버 응답이 흔들릴 때 file search와 web search fallback 순서를 어떻게 나누나

Responses API에서 remote MCP를 붙여 두면 사내 시스템이나 외부 서비스에 바로 닿을 수 있지만, 서버 응답이 흔들리는 순간 어떤 질문부터 built-in 도구로 우회할지 정해 두지 않으면 대기와 재시도가 한꺼번에 불어난다. 2026년 7월 12일 기준 OpenAI 공식 문서를 다시 보면 MCP는 mcp_list_tools import와 approval 흐름을 따로 갖고, file search는 vector store와 metadata filter로 내부 문서를 좁힐 수 있으며, web search는 최신 공개 정보를 위한 기본 built-in 경로다. 이 글은 remote MCP 장애가 날 때 file search, web search, MCP 재시도를 어떤 순서로 나누는 편이 실무적으로 덜 꼬이는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 remote MCP 서버가 흔들릴 때는 질문의 근거 위치를 먼저 나누는 편이 맞다. 사내 runbook, 내부 문서, 제품 정책처럼 이미 우리가 가진 근거라면 file search를 먼저 붙이고, 최신 공개 사실 확인이라면 web search를 먼저 붙인다. 상태 변경이나 민감 조회처럼 built-in 도구가 대신할 수 없는 질문일 때만 MCP 재시도를 마지막으로 좁혀 여는 편이 안전하다.

이 순서가 중요한 이유는 MCP가 tool list import, approval, 원격 호출까지 한 단계 더 갖기 때문이다. 이미 built-in tools 웹 검색·파일 검색·MCP 구조 글이 도구 구조를 설명했다면, 이번 글은 장애 시 fallback 순서를 구체화한 후속편이다.

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

실무에서 자주 꼬이는 패턴은 네 가지다. 첫째, remote MCP가 흔들리는데도 무조건 같은 tool call을 다시 시도한다. 둘째, 내부 문서로 충분한 질문인데 web search까지 같이 열어 정보 폭을 불필요하게 넓힌다. 셋째, 공개 최신 사실 질문인데 굳이 MCP 서버를 통해 같은 웹 데이터를 우회 조회한다. 넷째, write 가능 MCP를 fallback 첫 단계에 두어 approval 정체와 서버 오류를 한 덩어리로 만든다.

OpenAI MCP 가이드는 remote server의 tools/list 결과가 mcp_list_tools item으로 문맥에 적재되고, tool invocation은 mcp_tool_call과 approval 흐름을 가질 수 있다고 적는다. 반면 file search와 web search는 built-in 도구라서 질문에 맞는 범위만 비교적 짧게 붙이기 쉽다. 따라서 장애 상황에서 가장 먼저 해야 할 일은 '다시 붙일 도구가 무엇인가'가 아니라 '이번 질문의 근거가 어디에 있는가'를 다시 판별하는 일이다.

• 증상: MCP 호출 재시도만 늘고 답변 복구는 늦다.
• 실패: 내부 문서 질문과 공개 사실 질문을 같은 fallback으로 처리한다.
• 막힘: write 가능 MCP를 read-only fallback보다 먼저 연다.
• 누락: file search의 filter와 max result로 내부 문서 범위를 먼저 줄이지 않는다.

질문	먼저 붙일 도구	이유
사내 운영 기준이나 내부 정책이 답의 출처인가	file_search	vector store 범위를 좁혀 더 빠르게 복구할 수 있다
최신 공개 정보가 필요한가	web_search	최신성 확보와 citation이 쉽다
실제 상태 변경이나 외부 시스템 조회가 필요한가	narrow MCP	built-in 도구가 대신할 수 없는 영역이다

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

가장 덜 꼬이는 순서는 네 단계다. 먼저 질문이 internal-doc question인지 public-latest question인지 action question인지 라벨링한다. 두 번째로 internal-doc question이면 vector store 하나와 metadata filter만 좁게 붙인 file search부터 시도한다. 세 번째로 public-latest question이면 web search만 단독으로 붙이고, 그 결과로도 부족할 때만 MCP를 다시 연다. 마지막으로 action question일 때만 allowed_tools를 최대한 좁힌 MCP를 approval 정책과 함께 붙인다.

1. 질문의 근거 위치를 먼저 분류한다.
2. 내부 문서 질문은 file search만 붙여 좁게 시작한다.
3. 공개 최신 질문은 web search만 붙여 답을 확인한다.
4. 상태 변경이 필요할 때만 narrow MCP를 다시 연다.

장애 대응 메모도 같은 순서로 남겨야 한다. 먼저 question_class를 기록하고, 다음으로 primary_tool을 기록하고, 이어서 file search filter나 web search scope를 제한하고, 마지막으로 MCP 재시도 여부와 approval 대기 여부를 분리해 확인한다. 이 네 동작을 적어 두면 다음 호출자가 같은 순서로 재현하고, 줄이고, 건너뛸 수 있다.

이 순서가 좋은 이유는 fallback이 도구 재시도 전략이 아니라 근거 재선택 전략이 되기 때문이다. file search는 vector store를 직접 제한할 수 있고, web search는 최신 공개 정보용으로 설계되어 있다. 반면 MCP는 도구 목록 import와 approval, 원격 호출이 함께 있으므로 불안정 시점에 가장 비싼 복구 경로가 된다. 따라서 '무조건 MCP 재연결'은 기본값이 되면 안 된다.

운영 메모 예시

question_class=internal_doc|public_latest|action
primary_tool=file_search|web_search|mcp
mcp_retry_allowed=true|false
allowed_tools=getIncident
fallback_reason=mcp_timeout|approval_wait|server_unavailable

특히 remote MCP가 사내 SaaS나 티켓 시스템 wrapper일 때는, 그 SaaS 사용법이나 내부 장애 대응 문서 자체를 file search로 먼저 읽는 편이 더 빠를 수 있다. 반대로 가격, 정책, 릴리스처럼 외부 최신성이 중요한 질문은 web search를 먼저 붙여야 한다. 그 뒤에도 액션이 필요하면 그때 MCP를 최소 범위로 열면 된다.

• fallback 첫 단계는 도구 재시도가 아니라 질문 분류다.
• file search와 web search는 각각 내부 근거와 공개 근거를 담당한다.
• MCP는 built-in 도구로 대체할 수 없을 때만 마지막에 좁게 연다.

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

첫 자료는 OpenAI MCP and Connectors 가이드의 도구 목록 import 설명이다. 여기서는 runtime이 MCP 서버의 tools/list를 불러와 mcp_list_tools item으로 문맥에 넣고, 같은 item이 살아 있는 동안 다시 목록을 가져오지 않는다고 적는다. 즉 remote MCP는 단순 RPC가 아니라 도구 목록 import와 캐시가 한 번 더 들어가는 계층이다.

OpenAI MCP 가이드는 remote MCP 도구를 <code>mcp_list_tools</code> item으로 문맥에 적재하고 같은 item이 유지되는 동안 재호출을 줄인다고 설명한다.

이 특성 때문에 remote MCP가 불안정할 때는 무조건 재시도부터 붙이기보다, 이번 답변에 정말 MCP가 필요한지 먼저 다시 보는 편이 낫다. 공개 정보는 web search, 내부 문서는 file search로 우회할 수 있다면 MCP 재연결보다 먼저 비용과 지연을 줄일 수 있다.

두 번째 자료는 OpenAI cookbook의 MCP tool guide에서 MCP를 다른 hosted 도구와 함께 쓰는 예시다. 여기서는 MCP와 web search, code interpreter를 한 요청 안에서 역할별로 나눠 쓰는 흐름을 보여 준다. 즉 remote MCP가 있다고 해서 모든 근거를 MCP 하나로 몰아넣을 필요는 없고, 공개 정보와 계산 단계는 built-in 도구로 분리할 수 있다.

OpenAI cookbook은 MCP를 web search 같은 built-in 도구와 함께 배치해 질문별로 다른 근거층을 나누는 흐름을 예시로 보여 준다.

그래서 fallback 순서에서는 side effect가 적은 도구를 먼저 둬야 한다. file search나 web search로 충분한 질문인데도 write 가능 MCP를 먼저 열면, 장애가 도구 부족이었는지 approval 정체였는지부터 다시 갈라야 한다. 반대로 근거층을 분리해 두면 MCP 장애가 나도 공개 조사와 내부 문서 확인은 계속 진행할 수 있다.

세 번째 자료는 file search 가이드의 metadata filtering 예시다. file search는 vector store 범위와 filters, max_num_results를 직접 줄일 수 있어서, 우리가 이미 보유한 운영 문서나 장애 회고에서 답을 찾을 때 모델의 탐색 폭을 먼저 좁히기 좋다.

OpenAI file search 가이드는 vector store 범위와 metadata filter, 결과 개수를 조정해 내부 문서 탐색 범위를 좁히는 방법을 보여 준다.

즉 fallback 첫 단계는 '내가 가진 문서로 답할 수 있는가'다. 내부 runbook이나 제품 정책이 authoritative source라면 web search보다 file search가 먼저다. 특히 remote MCP 서버가 사내 시스템 wrapper라면, 같은 사내 문서를 file search로 바로 읽는 편이 더 단순할 때가 많다.

네 번째 자료는 web search 가이드의 integration 선택 구간이다. OpenAI는 Responses API에서 web_search를 새 통합 기본값으로 제시하고, 최신 공개 정보를 sourced citations와 함께 가져오도록 안내한다. MCP가 느릴 때 공개 사실 확인만 필요한 질문은 굳이 원격 서버를 다시 붙이지 않아도 된다.

OpenAI web search 가이드는 최신 공개 정보를 위한 기본 경로로 Responses API의 <code>web_search</code> 도구를 권장한다.

다만 web search는 내부 문서나 사내 결정 로그를 대신하지 않는다. fallback의 핵심은 더 넓은 도구를 먼저 쓰는 것이 아니라, 질문의 근거가 어디에 있는지에 맞춰 더 좁은 도구를 먼저 고르는 것이다.

실무에서는 질문을 세 부류로 나누는 표가 가장 빨리 먹힌다. 공개 최신 사실 확인, 사내 문서 확인, 외부 시스템 상태 변경이 서로 다른 도구층이라는 점을 먼저 고정하면 fallback 순서가 짧아진다.

질문 근거 위치에 따라 file search, web search, remote MCP를 어디에 배치할지 나눈 fallback 매트릭스다.

이 표를 기준으로 보면 MCP 재시도는 마지막에 둔다. 이미 built-in tools 구조 글이 도구 묶음을 나누는 큰 틀을 설명했다면, 이번 글은 장애 시 fallback 우선순위로 그 틀을 더 좁히는 후속편이다.

마지막 자료는 요청 단계에서 fallback 우선순위를 메모로 남기는 예시다. 어떤 질문이 어느 근거를 우선해야 하는지 코드를 통해 보여 주면 장애 중에도 팀이 같은 순서를 재현하기 쉽다.

file search와 web search를 우선 경로로 두고 MCP를 마지막으로 좁혀 여는 요청 설계 예시다.

이렇게 두면 remote MCP가 불안정한 시간대에도 공개 사실 확인과 내부 문서 답변을 바로 이어갈 수 있다. 또 allowed_tools와 approval 글처럼 MCP 범위를 처음부터 좁혀 둔 설계와도 잘 맞는다.

5. 주의사항과 리스크

첫 번째 리스크는 web search를 항상 먼저 붙여 내부 정책 질문까지 공개 웹 결과로 섞어 버리는 것이다. 두 번째 리스크는 file search를 붙였다고 해서 최신 공개 정책까지 내부 문서만으로 답하려는 것이다. 세 번째 리스크는 write 가능 MCP를 fallback 첫 단계에 넣어 approval과 장애 원인 분리를 더 어렵게 만드는 것이다.

운영 전에 확인할 때는 최소한 question_class, primary_tool, mcp_retry_allowed, allowed_tools, fallback_reason 다섯 칸을 같은 표에 남겨 두는 편이 좋다. 이 다섯 칸이 없으면 왜 이번 질문에서 file search를 먼저 썼는지, 왜 MCP를 건너뛰었는지 다음 장애 때 다시 설명해야 한다.

실무에서는 여기서 한 줄 더 나아가야 한다. 오류가 나면 같은 ticket에 retry_count를 기록하고, approval 대기 시간을 분리해서 기록하고, web search citation이 충분했는지 확인하고, file search 결과 개수를 다시 제한해야 한다. 이렇게 적어 두면 도구 문제와 질문 분류 문제를 같은 원인으로 뭉개지 않게 된다.

• file search는 최신 공개 사실을 대신하지 않는다.
• web search는 사내 runbook을 대신하지 않는다.
• MCP fallback은 가장 넓은 도구가 아니라 마지막 도구여야 한다.

6. 결론

remote MCP 서버가 흔들릴 때 가장 실용적인 fallback은 질문 근거를 다시 고르는 것이다. 내부 문서라면 file search, 최신 공개 정보라면 web search, 실제 상태 변경이라면 narrow MCP 순서로 두면 장애 복구가 짧아진다. 도구를 많이 붙이는 것보다, 어떤 근거를 어느 도구로 읽을지 먼저 자르는 편이 latency와 approval 잡음을 함께 줄인다.

그리고 2026년 7월 16일 후속 글로 web search에서 최신성은 맞는데 근거 추적이 약할 때 include와 search_context_size를 먼저 어떻게 고칠지를 따로 정리했다. 이 글이 fallback 순서를 잡는 허브라면, 새 글은 web search 단일 경로 안에서 sources, results, user_location을 어떤 로그 순서로 남길지 더 좁혀 준다.

• 내부 문서 질문은 file search부터 시작한다.
• 공개 최신 질문은 web search부터 시작한다.
• 실제 액션은 마지막에 좁은 MCP로 연다.

7. 참고 링크

1. https://developers.openai.com/api/docs/guides/tools-connectors-mcp
2. https://developers.openai.com/api/docs/guides/tools-web-search
3. https://developers.openai.com/api/docs/guides/tools-file-search
4. https://developers.openai.com/cookbook/examples/mcp/mcp_tool_guide