Codex MCP 도구 범위 설정: 필요한 도구만 안전하게 보이게 만드는 방법 | DAKER 커뮤니티
Codex에 MCP 서버를 연결하면 곧바로 할 수 있는 일이 많아집니다. 문서, 브라우저, 디자인 도구, 내부 시스템까지 한 번에 열리기 때문입니다. 하지만 연결이 많아질수록 정말 필요한 도구가 무엇인지, 어떤 도구는 승인을 거쳐야 하는지 기준이 흐려지기 쉽습니다.
그래서 첫 목표는 연결 성공 자체가 아니라 필요한 도구만 안전하게 보이는 상태를 만드는 데 있습니다. MCP란 Codex가 외부 문서와 개발 도구에 접근하도록 연결해 주는 도구·맥락 연결 방식이며, 이 글은 그 연결을 실제 업무에 맞게 좁히는 방법에 초점을 둡니다.
왜 도구 범위 설정을 먼저 봐야 할까요?
Codex MCP 도구 범위 설정은 외부 도구 연결 뒤 가장 먼저 점검할 안전 기준입니다. MCP 서버는 저장소 밖의 맥락을 Codex에 열어 주기 때문에, 팀에서는 어떤 도구를 보여 줄지와 어떤 도구는 승인을 거쳐야 하는지를 먼저 정하는 것이 좋습니다.
연결을 많이 하는 것보다 필요한 도구만 노출하고 쓰기 도구에는 승인 기준을 붙이는 것이 먼저입니다.
이 글은 2026년 7월 21일 KST에 OpenAI Codex 공식 MCP 문서와 설정 레퍼런스, DAKER 코덱스 최근 게시물을 확인한 기준으로 작성했습니다. 확인된 공식 문서 기준으로 Codex는 설정 파일에서 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를 꺼 두거나 프로젝트 범위 안에서만 켜는 편이 안전합니다.
- 비밀값은 본문 프롬프트가 아니라 안전한 환경 변수 경로로 전달합니다.
- 도구 이름을 모르면 먼저 목록 확인만 하고, 실제 쓰기 요청은 실행하지 않는 것이 좋습니다.
- 설정을 바꾼 뒤에는 작은 작업으로 도구 노출과 승인 표시를 다시 확인합니다.
자주 묻는 질문
enabled_tools만 쓰면 disabled_tools는 필요 없나요?
작은 서버라면 enabled_tools만으로도 충분합니다. 다만 플러그인이나 서버가 업데이트되면서 도구 구성이 바뀔 수 있다면 제외 목록을 함께 두는 편이 점검하기 쉽습니다.
쓰기 도구는 전부 꺼야 안전한가요?
항상 꺼야 하는 것은 아닙니다. 업무에 필요한 쓰기 도구는 남기되, 실행 전 승인과 초안 확인 기준을 붙이는 편이 실무적으로 더 낫습니다.
프로젝트마다 MCP 설정을 다르게 가져갈 수 있나요?
가능합니다. 공식 문서 기준으로 전역 설정과 프로젝트 범위 설정을 나눌 수 있으므로, 신뢰한 프로젝트에서는 필요한 서버만 좁게 켜는 방식이 좋습니다.
도구 범위 설정 후 첫 테스트는 무엇이 좋나요?
먼저 읽기 전용 조회를 실행하고, 그다음 쓰기 도구가 필요한 요청을 일부러 작게 만들어 승인 표시가 뜨는지 확인하면 됩니다.
참고 자료
공식 확인은 OpenAI Codex의 MCP 안내, 설정 레퍼런스, 커스터마이징 개요를 기준으로 했습니다. 함께 보면 좋은 DAKER 글은 아래와 같습니다.
오늘 Codex에 MCP 서버를 새로 붙였다면, 여러분은 어떤 기준으로 읽기 도구와 쓰기 도구의 범위를 나누고 계신가요?