Codex MCP 도구 범위 설정: 외부 도구 노출을 필요한 만큼만 줄이는 법 | DAKER 커뮤니티
Codex MCP 도구 범위 설정의 핵심은 서버를 많이 붙이는 것이 아니라, 작업에 필요한 도구만 노출하고 쓰기 도구에는 승인 기준을 붙이는 것입니다. MCP란, Codex가 외부 문서와 개발 도구에 접근하도록 연결해 주는 도구·맥락 연결 방식입니다. 지금 외부 도구를 Codex에 붙였다면 첫 목표는 “연결 성공”이 아니라 “필요한 도구만 안전하게 보이는 상태”를 만드는 것입니다.
Codex MCP 도구 범위 설정은 왜 먼저 해야 할까요?
Codex MCP 도구 범위 설정은 외부 도구 연결 뒤 첫 번째 안전 점검입니다. MCP 서버는 문서, 브라우저, 디자인 도구, 내부 시스템처럼 저장소 밖의 맥락을 Codex에 열어 주기 때문에, 팀은 어떤 도구가 보이고 어떤 도구는 승인받아야 하는지 먼저 정해야 합니다. 이 글은 2026년 7월 21일 KST에 OpenAI Codex 공식 MCP 문서와 설정 레퍼런스, DAKER 코덱스 최근 게시물을 확인한 기준으로 작성했습니다.
확인된 공식 문서 기준으로 Codex는 설정 파일에서 MCP 서버를 켜고 끌 수 있고, 서버별 도구 허용 목록과 제외 목록, 기본 승인 모드, 개별 도구 승인 모드를 둘 수 있습니다. 공개 본문에는 DAKER 운영 정책에 맞춰 외부 URL을 노출하지 않고, 실무자가 바로 점검할 수 있는 절차만 남깁니다.
문제 상황: MCP 서버를 많이 연결하면 무엇이 헷갈릴까요?
MCP 서버를 연결하면 처음에는 도구가 늘어난 것처럼 보여 편합니다. 하지만 브라우저, 이슈 트래커, 문서 저장소, 디자인 도구가 한꺼번에 보이면 Codex가 어떤 도구를 써야 하는지, 사용자가 무엇을 승인해야 하는지 흐려질 수 있습니다.
특히 쓰기 도구가 섞여 있으면 위험이 커집니다. 읽기 도구는 맥락 수집에 필요하지만, 외부 시스템을 수정하거나 메시지를 보내거나 파일을 올리는 도구는 작업 범위와 승인 기준이 맞아야 합니다. 그래서 먼저 서버 단위, 도구 단위, 승인 단위로 나누어야 합니다.
핵심 개념: enabled_tools와 disabled_tools는 어떻게 다를까요?
enabled_tools는 해당 MCP 서버에서 Codex에 보여줄 도구 허용 목록입니다. disabled_tools는 그 뒤에 적용되는 제외 목록입니다. 따라서 팀에서는 먼저 필요한 도구만 허용하고, 예외적으로 감춰야 할 도구를 제외 목록으로 한 번 더 막는 방식이 이해하기 쉽습니다.
| 설정 축 | 실무 의미 | 언제 쓰나요? |
|---|---|---|
| enabled | 서버 자체를 켜거나 끕니다. | 연결은 남기되 당분간 쓰지 않을 때 |
| enabled_tools | 보여줄 도구만 고릅니다. | 문서 검색처럼 읽기 중심 도구만 열 때 |
| disabled_tools | 허용 뒤 제외할 도구를 막습니다. | 특정 쓰기 도구만 감출 때 |
| approval mode | 도구 실행 전 승인 방식을 정합니다. | 쓰기 도구와 외부 변경 도구에 기준을 둘 때 |
단계별 사용법: 팀 설정은 어떤 순서로 정하면 좋을까요?
- 먼저 현재 Codex에서 보이는 MCP 서버 목록을 확인하고, 실제 업무에 필요한 서버와 실험용 서버를 분리합니다.
- 각 서버에서 읽기 도구, 쓰기 도구, 인증이 필요한 도구를 세 그룹으로 나눕니다.
- 처음에는 enabled_tools로 필요한 읽기 도구부터 좁게 열고, 쓰기 도구는 바로 노출하지 않습니다.
- 업무상 필요한 쓰기 도구만 남기고, disabled_tools로 위험하거나 중복되는 도구를 제외합니다.
- default_tools_approval_mode와 개별 도구 승인 모드로 쓰기 도구 실행 전 승인 기준을 정합니다.
- 마지막으로 작은 읽기 작업과 작은 쓰기 요청을 각각 실행해, 도구 노출과 승인 표시가 기대대로 보이는지 확인합니다.
짧은 예시: 문서 서버와 이슈 서버를 함께 쓸 때는 어떻게 나눌까요?
예를 들어 팀이 문서 검색 서버와 이슈 관리 서버를 동시에 연결했다고 가정해 보겠습니다. 문서 서버는 검색과 읽기 도구만 열어도 충분합니다. 이슈 서버는 읽기 도구는 자동으로 쓰되, 이슈 생성, 상태 변경, 댓글 작성 같은 쓰기 도구는 승인 모드를 붙이는 편이 안전합니다.
이때 좋은 요청은 “문서 서버에서는 공식 가이드 검색만 사용하고, 이슈 서버에서는 관련 이슈 읽기까지만 먼저 실행해 주세요. 이슈 생성이나 댓글 작성이 필요하면 이유와 초안을 먼저 보여 주세요”입니다. 이 문장은 도구 범위와 승인 기대치를 동시에 알려 줍니다.
실수 방지 체크리스트: 설정 전에 무엇을 확인할까요?
- 서버를 추가하기 전에 같은 목적의 기존 DAKER 코덱스 글이나 내부 지침이 있는지 확인합니다.
- 읽기 도구와 쓰기 도구를 같은 승인 기준으로 묶지 않습니다.
- 테스트용 서버는 enabled를 꺼 두거나 프로젝트 범위 안에서만 켭니다.
- 비밀값은 본문 프롬프트가 아니라 안전한 환경 변수 경로로 전달합니다.
- 도구 이름을 모르면 먼저 목록 확인만 하고, 실제 쓰기 요청은 실행하지 않습니다.
- 설정을 바꾼 뒤에는 작은 작업으로 도구 노출과 승인 표시를 다시 확인합니다.
공식 출처와 함께 볼 DAKER 글은 무엇인가요?
공식 확인은 OpenAI Codex의 MCP 안내, 설정 레퍼런스, 커스터마이징 개요를 기준으로 했습니다. 공개 링크는 DAKER 정책에 맞춰 DAKER와 DACON 도메인만 남깁니다.
자주 묻는 질문
enabled_tools만 쓰면 disabled_tools는 필요 없나요?
작은 서버라면 enabled_tools만으로도 충분합니다. 다만 플러그인이나 서버가 업데이트되면서 도구 구성이 바뀔 수 있다면 제외 목록을 함께 두는 편이 점검하기 쉽습니다.
쓰기 도구는 전부 꺼야 안전한가요?
항상 꺼야 하는 것은 아닙니다. 업무에 필요한 쓰기 도구는 남기되, 실행 전 승인과 초안 확인 기준을 붙이는 편이 실무적으로 더 낫습니다.
프로젝트마다 MCP 설정을 다르게 가져갈 수 있나요?
가능합니다. 공식 문서 기준으로 전역 설정과 프로젝트 범위 설정을 나눌 수 있으므로, 신뢰한 프로젝트에서는 필요한 서버만 좁게 켜는 방식이 좋습니다.
도구 범위 설정 후 첫 테스트는 무엇이 좋나요?
먼저 읽기 전용 조회를 실행하고, 그다음 쓰기 도구가 필요한 요청을 일부러 작게 만들어 승인 표시가 뜨는지 확인하세요.
오늘 Codex에 MCP 서버를 새로 붙였다면, 서버 추가보다 먼저 도구 목록을 읽기, 쓰기, 승인 필요로 나누는 10분 점검부터 시작해 보세요.