ChatGPT 예약 작업에서 Custom MCP 승인 줄이는 방법: Never ask, OAuth, 권한 설정

가장 먼저 확인할 설정: App permissions

개인 계정이라면 ChatGPT Web에서 대체로 다음 경로에서 기본 앱 승인 정책을 바꿀 수 있습니다.

Settings → Apps → App Preferences → Ask permission

여기서 제공되는 옵션에는 환경에 따라 Always ask, Any changes, Important actions, Never ask가 포함될 수 있습니다. 전체 기본값에서 Never ask가 보이지 않더라도 개별 연결 앱의 Preferences → Ask permission에서는 선택할 수 있는 경우가 있습니다.

실행 중 승인 카드가 표시될 때 Always allow가 제공된다면, 현재 작업을 허용하는 동시에 해당 연결 앱의 향후 작업도 다시 묻지 않도록 저장할 수 있습니다. 다만 UI 명칭과 제공되는 선택지는 계정 유형과 롤아웃 상태에 따라 달라질 수 있습니다.

OpenAI 공식 문서: Apps in ChatGPT

Business / Enterprise / Edu에서는 관리자가 더 중요합니다

관리형 워크스페이스에서는 멤버가 항상 영구 승인을 직접 설정할 수 있는 것은 아닙니다. 앱 사용 가능 범위와 지속 승인 정책이 워크스페이스 설정에 의해 제한될 수 있습니다.

현재 공식 문서가 안내하는 워크스페이스 기본 권한 경로는 다음과 같습니다.

Workspace settings → Permissions & roles → Connected data → App permissions

특정 published app만 별도로 바꾸려면 워크스페이스의 Apps 관리 화면에서 해당 앱의 메뉴를 열고 App permissions를 선택합니다. 여기서 환경에 따라 Always ask, Any changes, Important actions, Never ask 등을 설정할 수 있습니다.

OpenAI 공식 문서: Admin Controls, Security, and Compliance in apps

App permissions와 Action control은 다른 설정입니다

이 둘은 역할이 다릅니다.

• App permissions: ChatGPT가 앱 작업 전에 언제 사용자에게 확인을 요청할지 결정합니다.
• Action control: 해당 앱이 어떤 작업 자체를 수행할 수 있는지 결정합니다.

따라서 Never ask를 설정했다고 해서 관리자가 비활성화한 write/delete action이 자동으로 활성화되는 것은 아닙니다. 반대로 Action control에서 작업이 허용되어 있어도 App permissions 정책에 따라 승인 카드가 뜰 수 있습니다.

왜 Scheduled Tasks에서는 승인창이 특히 문제가 되나

OpenAI의 현재 Scheduled Tasks 문서는 예약 작업이 Gmail 같은 Apps를 사용할 수 있다고 설명하고 있습니다. 동시에 관리형 워크스페이스에서는 앱 권한 때문에 작업 실행 시 승인이 필요하거나 일부 작업을 수행하지 못할 수 있다고 명시합니다.

또 예약 작업은 추가 사용자 동작이 필요한 상태가 되면 일시 중지될 수 있습니다. 즉 새벽에 실행되는 작업이 MCP 호출 중 승인 카드를 요구한다면, 예약 작업이 스스로 그 승인 버튼을 대신 눌러 주는 구조라고 기대하면 안 됩니다.

OpenAI 공식 문서: Scheduled Tasks in ChatGPT

OpenAI 문서가 “Scheduled Tasks는 모든 Custom MCP 구성을 지원한다”는 식으로 별도의 포괄적 호환성 문장을 제공하는 것은 아닙니다. 다만 MCP 기반 통합은 ChatGPT에서 custom app으로 배포되고, Scheduled Tasks는 계정 또는 워크스페이스에서 이용 가능한 Apps의 권한을 따릅니다. 따라서 실제 무인 실행 여부는 해당 custom app이 그 워크스페이스에서 사용 가능하고, 승인·작업 권한·인증 조건을 모두 만족하는지를 기준으로 확인하는 편이 안전합니다.

허용하기가 떠도 원인이 모두 같은 것은 아닙니다

사용자가 보는 승인 또는 허용 화면은 크게 세 종류로 나눠 볼 수 있습니다.

특히 두 번째는 예약 작업에서 놓치기 쉽습니다. App permissions를 Never ask로 바꿔도 OAuth access token이 만료된 뒤 재인증이 필요하면 무인 실행은 끊깁니다.

OAuth를 쓴다면 refresh token을 반드시 확인해야 합니다

현재 OpenAI의 Developer Mode / MCP 앱 문서는 OAuth 또는 OpenID Connect provider가 refresh token을 발급하도록 구성되어 있는지 확인하라고 명시합니다.

OpenID Connect에서 일반적인 방법은 authorization request에 offline_access scope를 포함하고, provider가 discovery metadata에서 해당 지원을 광고하도록 설정하는 것입니다. provider가 refresh token을 발급하지 않거나 offline_access를 지원하지 않으면 최초 인증이 만료된 후 다시 사용자 인증이 필요할 수 있습니다.

즉 무인 예약 실행을 원한다면 다음 두 가지는 별개의 조건입니다.

1. ChatGPT의 앱 작업 승인 정책이 사람 확인을 요구하지 않아야 합니다.
2. MCP 인증 자체도 access token 만료 뒤 사람 재로그인 없이 갱신되어야 합니다.

OpenAI 공식 문서: Developer mode and MCP apps in ChatGPT

Custom MCP의 tool annotation도 정확해야 합니다

MCP 서버가 반환하는 tool annotation은 실제 동작과 맞게 설정하는 것이 중요합니다. 현재 OpenAI 개발자 문서는 다음 세 annotation이 ChatGPT와 Codex의 confirmation 및 safety 동작에 영향을 주는 힌트라고 설명합니다.

• readOnlyHint: 외부 상태를 전혀 변경하지 않는 도구일 때만 true
• destructiveHint: 삭제·취소 등 되돌리기 어렵거나 파괴적인 결과를 만들 수 있으면 true
• openWorldHint: 공개 또는 외부 시스템에 영향을 줄 수 있으면 true

예를 들어 예약 작업이 내부 데이터에서 오늘의 신규 항목을 읽어 요약만 하는 도구라면 실제 동작이 그 의미와 일치하는 범위에서 다음처럼 선언할 수 있습니다.

annotations: {
  readOnlyHint: true,
  destructiveHint: false,
  openWorldHint: false,
}

반대로 메일 전송, 외부 시스템 업데이트, 파일 삭제 같은 도구인데 승인창을 줄이기 위해 거짓으로 readOnlyHint: true를 주면 안 됩니다. annotation은 실제 효과와 일치해야 하며, OpenAI 문서도 이것이 서버 측 authorization, validation, confirmation을 대체하지 않는다고 명시합니다.

이 부분이 중요한 이유는 단순 조회 도구인데도 write-capable 또는 외부 영향이 큰 도구처럼 정의되어 있다면 필요 이상으로 보수적인 확인 흐름이 나타날 수 있기 때문입니다.

OpenAI 개발자 문서: Build an MCP server

Never ask도 안전 계층 전체를 끄지는 못합니다

Never ask는 일반적인 앱 승인 요청을 줄이는 가장 강한 설정이지만, ChatGPT의 모든 안전 계층을 비활성화하는 기능은 아닙니다.

외부 콘텐츠에 의심스럽거나 숨겨진 지시가 발견되거나, 특히 위험도가 높은 작업이라고 판단되거나, 워크스페이스 정책으로 제한된 동작이라면 ChatGPT가 다시 승인을 요구하거나 작업을 차단할 수 있습니다. 공식 문서도 덜 제한적인 App permissions를 선택해도 특정 safety 또는 workspace protection은 우회되지 않는다고 설명합니다.

그래서 **“예약 작업은 어떤 입력이 들어와도 MCP의 모든 tool을 아무 확인 없이 실행한다”**라는 보장을 ChatGPT Web에서 만드는 것은 좋은 목표가 아닙니다.

무인 예약 실행에서는 execute_anything 같은 범용 도구 하나보다, 예약 작업에 필요한 좁은 권한의 tool을 별도로 두는 편이 안정적입니다.

제가 이 용도로 구성한다면

다음 순서로 범위를 줄여 구성하겠습니다.

1. 관리형 워크스페이스라면 custom MCP를 장기 운영용으로 사용할 경우 published app 상태를 기준으로 권한을 관리합니다. 현재 관리 문서의 앱별 App permissions 절차가 published app을 기준으로 설명되기 때문입니다.
2. 워크스페이스 전체가 아니라 가능하면 **해당 custom app 하나에만 Never ask**를 적용합니다.
3. Action control에서는 예약에 필요한 action만 허용하고 delete/send/admin처럼 불필요한 작업은 꺼둡니다.
4. 조회 tool은 실제 동작에 맞게 readOnlyHint: true 등 정확한 annotation을 사용합니다.
5. OAuth를 사용한다면 refresh token과 offline_access가 실제로 동작하는지 확인합니다.
6. 예약 write가 필요하다면 범용 쓰기 API보다 save_daily_report, update_specific_record처럼 목적이 좁고 idempotent한 tool을 만듭니다.
7. 서버 측에는 idempotency key나 중복 실행 방지 장치를 두어 재시도 시 같은 작업이 두 번 처리되지 않게 합니다.

이 상태에서 일회성 예약 작업을 실제로 실행했는데 approval card가 다시 나타난다면 어떤 tool과 어떤 단계에서 발생했는지를 보면 원인을 좁히기 쉽습니다. 읽기 전용 tool에서 앱 작업 승인이 뜬다면 metadata나 제품 동작을 먼저 확인하고, 외부 write tool이라면 action risk와 workspace policy를 함께 봐야 합니다.

Responses API의 require_approval: "never"는 다른 기능입니다

MCP 관련 문서를 찾다 보면 Responses API 예제에서 다음 설정을 볼 수 있습니다.

{
  "type": "mcp",
  "server_label": "my_mcp",
  "server_url": "https://example.com/mcp",
  "require_approval": "never"
}

이것은 실제 공식 기능입니다. Responses API를 호출하는 애플리케이션은 MCP tool 구성에 require_approval: "never"를 지정하거나, 특정 tool에 대해서만 approval을 생략하도록 필터를 줄 수 있습니다.

하지만 이 값을 MCP 서버의 manifest나 tool metadata에 넣는다고 ChatGPT Web Scheduled Tasks의 승인 정책이 바뀌는 것은 아닙니다. require_approval은 Responses API를 호출하는 클라이언트 측 MCP tool configuration입니다.

ChatGPT Web에서 대응되는 운영 설정은 앞서 설명한 App permissions입니다.

OpenAI API 문서: MCP and Connectors

완전한 무인 자동화가 절대 요구사항이라면

정말로 어떠한 ChatGPT UI 승인에도 의존하지 않는 결정적인 서버 자동화가 필요하다면 아키텍처를 바꾸는 방법이 있습니다.

ChatGPT Scheduled Tasks 대신 서버 cron이나 Cloud Scheduler 같은 스케줄러가 Responses API를 호출하고, Responses API의 MCP 설정에서 필요한 tool만 allow-list로 제한한 뒤 적절한 require_approval 정책을 적용하는 방식입니다.

이 구조에서는 승인 정책을 애플리케이션 코드에서 더 명시적으로 제어할 수 있습니다. 다만 이것도 무조건적인 우회가 아니라, 신뢰할 수 있는 MCP 서버, 최소 권한, 서버 측 OAuth, 입력 검증, idempotency, 민감 작업에 대한 별도 보호가 필요합니다. OpenAI API 문서 역시 민감한 작업에는 적절한 승인 구성을 사용하도록 권고합니다.

결론

현재 상황에서 가장 먼저 볼 것은 Custom MCP 앱 자체의 App permissions를 Never ask로 설정할 수 있는지입니다.

Business / Enterprise / Edu 워크스페이스라면 사용자가 아니라 관리자가 published custom app별로 설정해야 할 가능성이 높습니다. 그리고 MCP가 OAuth를 사용한다면 refresh token과 offline_access도 함께 확인해야 합니다. 이 두 조건이 모두 해결되어야 예약 실행이 실제로 사람 개입 없이 이어질 가능성이 높아집니다.

반대로 Never ask가 제공되지 않거나 워크스페이스 정책상 허용할 수 없다면 ChatGPT Web Scheduled Tasks 안에서 승인 버튼을 강제로 자동 클릭하도록 만드는 공식 설정은 없습니다. 절대적인 무인 실행이 필요하다면 Responses API를 호출하는 서버 자동화 구조가 더 제어 가능한 선택입니다.

Custom MCP의 수정 사항이 Web ChatGPT에 언제 반영되는지도 함께 정리하려면 이전 글인 Custom MCP 수정 후 Web ChatGPT에 변경 사항을 반영하는 방법도 참고할 수 있습니다.

참고한 공식 문서

• Scheduled Tasks in ChatGPT
• Apps in ChatGPT / App permissions
• Admin Controls, Security, and Compliance in apps
• Developer mode and MCP apps in ChatGPT
• Build an MCP server
• MCP and Connectors