Codex 플러그인 디렉터리 사용법: 앱·스킬 권한을 헷갈리지 않는 점검법 | DAKER 커뮤니티
Codex 플러그인 디렉터리란 ChatGPT와 Codex에서 반복 업무 기능을 찾고 설치하는 진입점입니다. 2026년 7월 9일 기준 OpenAI는 앱 디렉터리를 Plugin directory로 전환했기 때문에, 이제 실무자는 “플러그인이 보인다”와 “우리 워크스페이스에서 안전하게 쓸 수 있다”를 분리해 확인해야 합니다.
문제 상황: Codex 플러그인이 보이는데 왜 바로 쓰면 안 될까요?
한 줄 요약: 플러그인은 기능 묶음, 앱은 외부 시스템 연결, 스킬은 반복 절차입니다. Codex에서 어떤 플러그인이 보여도 실제 사용 가능 여부는 플랜, 워크스페이스 설정, 역할, 지원 표면, 포함된 앱 권한, 원본 시스템 권한에 따라 달라집니다. 그래서 새 기능을 팀에 안내할 때는 설치 화면만 보지 말고 포함된 앱과 액션 권한까지 확인해야 합니다.
핵심 개념: Plugin, App, Skill은 어떻게 다를까요?
Plugin은 여러 capability를 묶어 배포하는 패키지이고, App은 외부 데이터와 액션에 연결되는 통합이며, Skill은 Codex가 반복 절차를 안정적으로 따르도록 만든 작업 지침입니다. 이 구분은 설치 실패를 설명하기 위한 용어 정리가 아니라, 실제 권한 점검 순서를 정하는 기준입니다. 작성 기준일은 2026년 7월 12일 KST이며, 공개 본문에는 DAKER 정책에 따라 DAKER 내부 링크만 남겼습니다.
| 구분 | 역할 | 먼저 확인할 것 |
|---|---|---|
| Plugin | 워크플로 기능을 발견하고 설치하는 묶음 | 어떤 skills, apps, app templates가 포함됐는지 |
| App | GitHub, Drive, Slack 같은 외부 시스템 연결 | 역할 접근, OAuth, 읽기/쓰기 액션, 원본 시스템 권한 |
| Skill | Codex가 따르는 반복 절차와 리소스 | 언제 트리거되는지, 어떤 MCP나 앱 의존성이 있는지 |
| MCP | Codex와 외부 도구·컨텍스트를 잇는 연결 방식 | 현재 세션에 서버와 도구가 실제로 노출됐는지 |
단계별 사용법: 새 플러그인은 어떤 순서로 점검해야 할까요?
새 플러그인은 설치 버튼보다 포함 요소, 앱 권한, 원본 시스템 권한, 낮은 위험 테스트 순서로 확인해야 합니다. 이 순서를 지키면 “설치는 됐는데 실행이 안 된다”는 문제를 권한, 연결, 표면 차이로 빠르게 좁힐 수 있습니다. 특히 팀 전체 배포 전에는 pilot group에서 읽기 전용 작업부터 검증하는 편이 안전합니다.
- 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인지 확인했나요?
브라우저 화면에서 연결 버튼이 회색으로 보일 수도 있습니다. 이때는 우회하지 말고 플랜, 지역, 워크스페이스 설정, 관리자 비활성화 여부를 확인해야 합니다. 브라우저 작업 표면 자체가 헷갈리면 코덱스 툴 사용법 13: 브라우저 작업을 어디에 맡길지 고르는 법을 함께 보면 좋습니다.
공식 출처: 2026년 7월 12일 기준 어디를 확인했나요?
OpenAI 공식 Help Center와 Codex 개발자 문서에서 app directory의 Plugin directory 전환, plugin이 skills·apps·app templates를 포함할 수 있다는 설명, app permission이 plugin에도 적용된다는 설명, Codex skill과 MCP의 역할을 확인했습니다. 공개 링크는 DAKER 정책에 따라 DAKER 내부 링크만 남깁니다. 외부 공식 문서는 작성 전 검증용으로 확인했지만, 독자가 눌러야 할 실무 연결은 DAKER 코덱스 글로 이어지게 구성했습니다.
DAKER 코덱스의 다른 글은 DAKER 코덱스 디렉터리에서 이어서 확인할 수 있습니다.
자주 묻는 질문
Codex 플러그인을 설치하면 포함 앱도 자동으로 쓸 수 있나요?
항상 그렇지 않습니다. 플러그인이 보이거나 설치되어도 포함 앱이 워크스페이스와 사용자 역할에서 활성화되어야 하고, 원본 시스템 권한도 필요합니다.
Skill만 있는 플러그인도 있나요?
있을 수 있습니다. 이런 경우 외부 데이터 연결 없이 반복 절차와 지침만 제공할 수 있습니다. 다만 스킬이 MCP나 앱 도구를 전제로 한다면 해당 의존성도 확인해야 합니다.
Available과 Installed는 데이터 접근 권한인가요?
아닙니다. Available은 사용자가 설치할 수 있다는 뜻이고, Installed는 특정 역할에 자동 설치한다는 뜻입니다. 데이터 접근과 액션 권한은 포함 앱과 원본 시스템 권한을 따로 봐야 합니다.
새 플러그인을 팀 전체에 바로 켜도 되나요?
민감 데이터나 쓰기 액션이 연결되는 플러그인은 pilot group에서 먼저 테스트하는 편이 안전합니다. 읽기 전용 조회, 제한된 폴더나 저장소, 낮은 위험 테스트 프롬프트부터 시작하세요.
Codex에서 플러그인이 계속 보이는데 앱을 비활성화한 이유는 무엇인가요?
앱을 비활성화하면 app-backed capability는 막히지만 이미 설치된 plugin package가 목록에 남을 수 있습니다. 이 경우 skills만 남아 보이거나, 실제 실행 시 app 연결 단계에서 막힐 수 있습니다.
오늘 새 플러그인을 열어 보기 전, “이 플러그인이 무엇을 포함하고 어떤 권한으로 실행되는가”를 한 번만 먼저 확인해 보세요.