Codex 플러그인 디렉터리, 앱·스킬 권한을 헷갈리지 않는 점검법 | DAKER 커뮤니티

Codex에서 새 플러그인을 발견했을 때 가장 먼저 드는 생각은 대개 설치와 활용입니다. 그런데 2026년 7월 9일 기준 OpenAI가 앱 디렉터리를 Plugin directory로 전환하면서, 이제는 플러그인이 보인다는 사실과 우리 워크스페이스에서 안전하게 쓸 수 있다는 사실을 분리해 확인할 필요가 생겼습니다.

특히 팀에 새 기능을 안내하거나 배포할 때는 설치 화면만 보고 판단하면 실행 단계에서 막히기 쉽습니다. 플러그인 자체보다, 그 안에 무엇이 들어 있고 어떤 권한으로 연결되는지를 먼저 보는 편이 실무에서 더 중요합니다.

왜 플러그인이 보여도 바로 쓰면 안 될까요?

Codex에서 어떤 플러그인이 보여도 실제 사용 가능 여부는 하나로 결정되지 않습니다. 플랜, 워크스페이스 설정, 역할, 지원 표면, 포함된 앱 권한, 원본 시스템 권한이 함께 맞아야 합니다.

플러그인이 보인다는 것과 실제로 안전하게 실행할 수 있다는 것은 다릅니다.

한 줄로 정리하면, 플러그인은 기능 묶음이고 앱은 외부 시스템 연결이며 스킬은 반복 절차입니다. 그래서 새 기능을 검토할 때는 설치 가능 여부보다 포함된 앱과 액션 권한까지 함께 확인하는 것이 좋습니다.

Plugin, App, Skill은 어떻게 다를까요?

Plugin은 여러 capability를 묶어 배포하는 패키지입니다. App은 GitHub, Drive, Slack 같은 외부 시스템과 연결되는 통합이고, Skill은 Codex가 반복 절차를 안정적으로 따르도록 만든 작업 지침입니다. 여기에 MCP는 Codex와 외부 도구·컨텍스트를 잇는 연결 방식입니다.

이 구분은 용어 설명에 그치지 않습니다. 실제로는 권한 점검 순서를 정하는 기준이 됩니다. 작성 기준일은 2026년 7월 12일 KST입니다.

새 플러그인은 어떤 순서로 점검하면 좋을까요?

새 플러그인은 설치 버튼보다 포함 요소, 앱 권한, 원본 시스템 권한, 낮은 위험 테스트 순서로 보는 편이 좋습니다. 이 순서를 따르면 설치는 됐는데 실행이 안 되는 문제를 권한, 연결, 표면 차이 가운데 어디서 막히는지 더 빨리 좁힐 수 있습니다.

플러그인 점검은 설치보다 포함 요소와 권한 확인이 먼저입니다.

우선 Plugin listing에서 Skills만 있는지, app이 필요한지, app template 설정이 필요한지 확인하면 됩니다. 그다음 Workspace settings의 Plugins에서 설치 정책을 봅니다. 여기서 Available과 Installed는 설치 정책이지 데이터 접근 권한이 아니라는 점을 구분해야 합니다.

이후 Workspace settings의 Apps에서 포함 앱의 권한을 확인합니다. 역할 접근, 읽기/쓰기 액션, 승인 필요 여부, 동기화 범위를 함께 보는 것이 좋습니다. 마지막으로 원본 시스템 권한도 따로 확인해야 합니다. ChatGPT에서 앱이 허용되어 있어도 GitHub 저장소, Drive 폴더, Slack 채널 권한이 없으면 Codex는 실제 데이터에 접근할 수 없습니다.

테스트는 낮은 위험 작업부터 시작하는 편이 안전합니다. 조회 전용 작업으로 먼저 확인하고, 쓰기 작업은 action confirmation과 되돌리기 방법을 확인한 뒤 확장하면 됩니다.

외부 시스템이 들어오면 프롬프트보다 연결 상태와 권한 경계가 먼저입니다. 관련 흐름은 코덱스 툴 사용법 18: MCP와 앱 연결을 먼저 확인하기에서 이어서 볼 수 있습니다.

팀 도입 시에는 어떤 식으로 요청하면 좋을까요?

예를 들어 GitHub 관련 플러그인을 팀에 도입한다면, 단순히 설치를 요청하기보다 포함 요소와 테스트 범위를 함께 묻는 방식이 더 유용합니다. 원문 예시는 다음과 같습니다.

이 플러그인에 포함된 skills와 apps를 확인해 주세요. GitHub app이 필요한 경우 읽기 전용으로 가능한 작업과 쓰기 액션이 필요한 작업을 나눠 주세요. 현재 사용자가 접근할 수 있는 저장소만 대상으로 낮은 위험 테스트 프롬프트를 실행하고, 권한 부족이면 추측하지 말고 막힌 위치를 보고해 주세요.

핵심은 설치 자체보다 포함 요소, 권한, 테스트 범위를 함께 확인하는 데 있습니다. 문서 설명과 실제 세션 상태가 다를 수 있으므로, 실제 세션에서 보이는 도구와 권한을 기준으로 다시 좁히는 편이 안전합니다. 이 흐름은 OpenAI Docs MCP로 공식 문서 확인하기와도 이어집니다.

도입 전에 꼭 봐야 할 실수 방지 포인트

플러그인 도입 전에는 몇 가지를 함께 확인해 두는 것이 좋습니다. 플러그인이 포함한 app이 워크스페이스에서 활성화되어 있는지, 해당 역할 또는 사용자에게 app access가 배정되어 있는지, app이 읽기만 가능한지 아니면 생성·수정·전송 액션도 가능한지 구분되어 있는지부터 확인해야 합니다.

또한 action confirmation이 필요한 작업과 자동 실행 가능한 작업을 나눠 보고, 원본 시스템의 파일, 저장소, 채널, 레코드 권한도 함께 확인하는 편이 좋습니다. 새 플러그인은 바로 팀 전체에 배포하기보다 pilot group에서 낮은 위험 테스트를 먼저 거치는 방식이 더 안전합니다. Codex에서 보이는 플러그인이 특정 표면에서만 사용 가능한 local 또는 Codex-specific plugin인지도 확인할 필요가 있습니다.

Available과 Installed는 설치 정책일 뿐, 데이터 접근 권한을 뜻하지 않습니다.

브라우저 화면에서 연결 버튼이 회색으로 보일 수도 있습니다. 이때는 우회하기보다 플랜, 지역, 워크스페이스 설정, 관리자 비활성화 여부를 확인해야 합니다. 브라우저 작업 표면이 헷갈릴 때는 코덱스 툴 사용법 13: 브라우저 작업을 어디에 맡길지 고르는 법도 함께 참고할 수 있습니다.

자주 헷갈리는 질문들

플러그인을 설치하면 포함 앱도 자동으로 쓸 수 있나요?

항상 그렇지 않습니다. 플러그인이 보이거나 설치되어도 포함 앱이 워크스페이스와 사용자 역할에서 활성화되어야 하고, 원본 시스템 권한도 필요합니다.

Skill만 있는 플러그인도 있나요?

있을 수 있습니다. 이런 경우 외부 데이터 연결 없이 반복 절차와 지침만 제공할 수 있습니다. 다만 스킬이 MCP나 앱 도구를 전제로 한다면 해당 의존성도 함께 확인해야 합니다.

Available과 Installed는 데이터 접근 권한인가요?

아닙니다. Available은 사용자가 설치할 수 있다는 뜻이고, Installed는 특정 역할에 자동 설치한다는 뜻입니다. 데이터 접근과 액션 권한은 포함 앱과 원본 시스템 권한을 따로 봐야 합니다.

새 플러그인을 팀 전체에 바로 켜도 되나요?

민감 데이터나 쓰기 액션이 연결되는 플러그인은 pilot group에서 먼저 테스트하는 편이 안전합니다. 읽기 전용 조회, 제한된 폴더나 저장소, 낮은 위험 테스트 프롬프트부터 시작하면 됩니다.

Codex에서 플러그인이 계속 보이는데 앱을 비활성화한 이유는 무엇인가요?

앱을 비활성화하면 app-backed capability는 막히지만 이미 설치된 plugin package가 목록에 남을 수 있습니다. 이 경우 skills만 남아 보이거나, 실제 실행 시 app 연결 단계에서 막힐 수 있습니다.

참고 자료

관련 흐름은 코덱스 툴 사용법 18: MCP와 앱 연결을 먼저 확인하기, OpenAI Docs MCP로 공식 문서 확인하기, 코덱스 툴 사용법 13: 브라우저 작업을 어디에 맡길지 고르는 법에서 이어서 확인할 수 있습니다.

DAKER 코덱스의 다른 글은 DAKER 코덱스 디렉터리에 정리되어 있습니다.

여러분의 팀에서는 새 플러그인을 볼 때 설치 가능 여부와 실제 권한 점검 가운데 무엇을 먼저 확인하고 계신가요?