-
[OpenAI][MCP] Responses API에 remote MCP 서버를 붙일 때 allowed_tools와 approval을 먼저 줄이는 이유기타개발지식/풀스택개발 2026. 6. 23. 10:47
IT 리서치 노트
[OpenAI][MCP] Responses API에 remote MCP 서버를 붙일 때 allowed_tools와 approval을 먼저 줄이는 이유
Responses API에서 remote MCP 서버를 붙이면 연결은 빨라지지만 권한 범위는 쉽게 넓어진다. 특히 quickstart 예시만 보고 전체 tool을 그대로 열거나 승인 단계를 건너뛰면 모델이 읽기보다 큰 동작을 시도할 수 있다. 이 글은 OpenAI 공식 문서를 기준으로 trusted server 확인,
allowed_tools축소, approval 유지, URL 출력 검토 순서까지 실무 관점으로 정리한다.1. 개요
현재 OpenAI 공식 문서는 새 프로젝트에 Responses API를 권장하고, 그 안에서 remote MCP를 built-in tool처럼 붙일 수 있다고 설명한다. 문제는 연결 가능하다는 사실과 안전하게 운영할 수 있다는 사실이 같지 않다는 점이다. 같은 문서 안에도 승인, tool 제한, trusted server, URL 출력 검토를 따로 보라고 적혀 있다.
실무에서는 보통 세 가지 실수가 먼저 나온다. 첫째, quickstart 코드만 보고 서버 URL과 토큰만 넣은 뒤 전체 tool을 한 번에 연다. 둘째, 읽기와 쓰기 구분 없이 tool description을 통째로 모델에 노출한다. 셋째, 응답 안에 나온 URL이나 첨부 링크를 검토 없이 바로 열거나 임베드한다. 이 셋은 모두 나중에 사고가 난 뒤 로그를 뒤집게 만드는 종류다.
Remote MCP 일반론부터 다시 보고 싶다면 Remote MCP 서버를 붙이기 전에 OAuth와 tool 권한을 확인해야 하는 이유를 먼저 보는 편이 좋다. Responses API의 비동기 운영과 webhook 중복 처리까지 같이 설계해야 한다면 Responses API background mode와 webhook을 같이 쓸 때 놓치기 쉬운 점도 이어서 확인하면 흐름이 맞는다.
2. 어디서 실제로 막히는가
증상은 단순해 보여도 원인은 권한 경계에서 갈린다. 연결 직후에는 응답이 잘 오는데 어느 순간 모델이 예상보다 넓은 tool을 호출하거나, 사용자가 열어 달라고 하지 않은 URL을 따라가거나, 승인 없는 쓰기 동작을 시도하는 식이다. 장애 로그에는 단순히
mcp_call만 남아서 읽기 요청인지 변경 요청인지 바로 안 보이는 경우도 많다.또 하나는 OAuth나 access token이 이미 좁게 발급됐다고 착각하는 경우다. 실제로는 외부 서비스 쪽 scope가 넓고, MCP server 쪽 tool 목록도 넓고, OpenAI 요청에서
allowed_tools제한도 없이 전부 가져오면 세 겹으로 범위가 커진다. 이 상태에서는 모델이 실수했을 때 어느 층에서 막아야 하는지 불분명해진다.실패 패턴은 대체로 아래 다섯 가지로 모인다.
- tool 목록을 한 번도 조회하지 않고 바로 호출해 read, write, delete가 같이 열린다.
- 문서 예시의
require_approval: "never"를 그대로 복사해서 민감 작업 승인 흐름이 사라진다. - tool call output 안의 URL을 검토 없이 열어 외부 도메인이나 이미지 임베드까지 이어진다.
- 공식 서버가 아닌 중계 서버를 연결하고도 데이터 보관 정책과 감사 로그를 확인하지 않는다.
- Responses API 비동기 흐름을 함께 쓸 때 tool 호출 로그와 webhook 결과를 따로 저장하지 않아 재현이 어렵다.
OAuth 연결 방식 자체가 헷갈린다면 Notion API internal connection과 public OAuth를 언제 나눠야 하나처럼 설치형 통합과 단일 워크스페이스 통합을 분리해서 생각하면 정리가 빠르다. MCP도 결국 어느 계정 범위의 어떤 리소스를 읽고 바꿀 것인지 먼저 결정해야 안전해진다.
3. 처음 연결할 때 줄여야 하는 항목
처음 연결할 때는 기능을 늘리는 순서가 아니라 범위를 줄이는 순서로 본다. 아래 다섯 단계만 지켜도 대부분의 사고를 초반에 막을 수 있다.
- 먼저 server host가 공식 서비스 운영 주체인지 확인한다. 프록시형 중계 서버라면 데이터 사용 정책과 로그 보관 정책을 별도로 읽는다.
- 다음으로 OAuth scope와 access token 범위를 확인한다. read/search만 필요한 단계라면 write, delete, admin 범위는 뺀다.
- 이어서 첫 요청에서
allowed_tools로 읽기 tool만 가져온다. 목록 조회 결과를 보고 필요한 tool만 추가한다. - 민감 작업은 승인 흐름을 유지한다. 검토가 끝나기 전에는 승인 생략 설정을 운영 기본값으로 두지 않는다.
- 마지막으로 tool output 안의 URL, 파일, 외부 이미지 경로를 로그에 남기고 바로 열지 않는다.
문서에 나온 quickstart를 그대로 복사하는 대신 아래처럼 도구 범위부터 줄인 예시로 시작하는 편이 낫다. 예제 URL은 placeholder이고, 실제 토큰이나 사내 서버 주소를 공개 문서와 코드 예시에 남기지 않는다.
이 예시에서 중요한 것은 코드 길이가 아니라 범위다. 연결 성공 여부는 나중에 다시 확인할 수 있지만, read-only로 시작할지 아닌지는 첫 설계에서 갈린다. 승인 흐름과 롤백 절차를 아직 갖추지 못했다면 쓰기 tool을 늦게 여는 쪽이 총 비용이 적다.
4. 공식 문서 화면으로 확인하기
첫 화면에서는 Responses API가 왜 기본 출발점인지부터 잡는다. 이 문서에서 Responses가 새 프로젝트 권장 경로이고 remote MCP가 built-in tool 목록에 들어간다는 점을 먼저 확인해야 뒤 설명이 자연스럽다.
강조된 문장처럼 현재 기준으로는 새 프로젝트에 Responses API를 권장한다. 같은 구간에서 web search, file search, computer use, code interpreter와 함께 remote MCP가 같은 층위의 도구로 들어간다는 점을 본다.
이 문장을 먼저 확인해야 Chat Completions 시대의 함수 호출 감각으로 MCP를 붙였다가 상태 관리와 승인 흐름을 놓치는 일을 줄일 수 있다.
다음으로 quickstart 화면에서는 실제 요청에 어떤 필드가 들어가는지 본다. 여기서는
server_url과require_approval가 같이 보이는 지점을 확인한다. 연결만 성공시키는 것이 목적이면 눈에 띄는 예시를 그대로 복사하기 쉽지만, 운영에서는 이 값이 가장 먼저 검토 대상이 된다.코드 블록의 필드 이름을 외우는 것보다 어떤 값이 범위를 넓히는지 읽는 편이 중요하다. 특히 approval을 건너뛰는 예시는 테스트용인지 운영 기본값인지 구분해야 한다.
실무에서는 quickstart를 시작점으로만 쓰고, 바로 아래의 안전 섹션과 tool 제한 섹션까지 함께 읽어야 문맥이 맞는다.
그 다음 확인할 항목이
allowed_tools다. 서버가 수십 개 tool을 제공하면 모델이 모두 가져갈 필요가 없다. 문서의 이 코드처럼 초기 요청에서 읽기 tool만 지정해 import 범위를 줄일 수 있다.여기서 중요한 것은 기능 추가가 아니라 제외다. search, read만 먼저 열고 create, update, delete는 나중에 개별 검토하는 방식이 안전하다.
tool 이름이 길거나 description이 넓다면 더 좁게 줄여야 한다. 이름만 읽지 말고 실제 동사가 read인지 write인지 확인한다.
목록 조회 단계의 출력도 꼭 본다. 이 JSON 출력은 서버가 실제로 어떤 tool을 import했는지 보여 준다. 요청 전 설계와 출력 후 결과가 다르면 그 차이를 로그로 남겨야 이후 오류 재현이 가능하다.
출력 예시를 보면 name, description, input_schema, required 필드가 같이 나온다. 여기를 보고 모델이 어떤 입력을 보낼 수 있는지 판단한다.
문서 예시처럼 schema가 보이기 시작하면 승인 없이 열어도 되는 읽기 tool인지, 아니면 실제 변경으로 이어질 수 있는지 더 분명해진다.
안전 섹션에서는 승인과 URL 처리를 별도로 본다. OpenAI 문서는 민감 동작에 approval을 요구하고, tool output 안의 URL이나 이미지 URL도 바로 쓰지 말라고 적는다. 이 부분은 개발 속도보다 사고 비용이 더 큰 항목이다.
이 구간은 문장 수가 짧지만 운영 기준을 정하는 핵심이다. approval과 allowed_tools를 함께 보라고 적혀 있다는 점이 중요하다.
URL을 바로 열지 말라는 안내는 생각보다 실무적이다. 외부 도메인, 이미지 프록시, 미리보기 임베드까지 모두 이 규칙 안에서 봐야 한다.
마지막으로 trusted server 기준을 확인한다. OpenAI는 서비스 제공자가 직접 운영하는 공식 서버를 우선 고르고, 제3자 프록시형 서버는 데이터 사용 방식을 더 신중하게 검토하라고 적고 있다. 연결 성공만 보고 서버를 고르면 나중에 데이터 경로를 되짚기 어렵다.
이 문장은 OAuth scope보다 앞에 와도 될 정도로 중요하다. 운영 주체를 신뢰할 수 없으면 나머지 권한 축소도 한계가 있기 때문이다.
실제로는 host 이름, 운영 주체, 로그 보관 정책, 삭제 요청 처리, 사고 대응 연락처까지 함께 보는 편이 안전하다.
5. 결론
Responses API에서 remote MCP를 붙일 때 가장 먼저 줄여야 하는 것은 모델이 아니라 권한 범위다. trusted server를 고르고, OAuth scope를 줄이고,
allowed_tools로 읽기 tool만 먼저 열고, 민감 작업 approval을 유지하는 순서가 기본값이 되어야 한다.- 새 프로젝트라면 Responses API를 기본 경로로 잡되 remote MCP를 함수 호출의 확장판처럼 가볍게 취급하지 않는다.
- 처음 연결에서는 read/search만 열고 create, update, delete, deploy 계열은 나중에 분리한다.
- tool output URL과 외부 이미지 경로는 검토 후 사용한다.
- 비동기 흐름과 결과 저장이 걸려 있으면 post 25처럼 webhook과 중복 처리 설계까지 같이 본다.
6. 참고 링크
'기타개발지식 > 풀스택개발' 카테고리의 다른 글