만들게 될 플러그인

MCP 기반 플러그인은 세 부분으로 구성됩니다.

• MCP 서버는 도구를 정의하고 데이터를 반환하며 인증 요구사항을 적용합니다. UI 리소스가 있으면 ChatGPT에 해당 위치를 알려 줍니다.
• 선택 사항인 웹 컴포넌트는 ChatGPT의 iframe 안에 표시됩니다. React로 만들거나 HTML, CSS, JavaScript만으로 구현할 수 있습니다.
• 모델은 개발자가 제공한 메타데이터를 바탕으로 플러그인의 도구를 언제 호출할지 결정합니다.

이 세 부분을 구현할 때 다음과 같은 반복 작업을 Codex에 맡기면 효과적입니다.

• 제공할 도구와 메타데이터 설계
• 서버와 위젯의 기본 구조 생성
• 로컬 실행 스크립트 연결
• 인증과 배포에 필요한 변경 사항을 단계별로 적용
• ChatGPT에서 플러그인이 제대로 작동하는지 반복해서 확인하는 검증 절차 작성

플러그인 개발에 Codex가 적합한 이유

• MCP 기반 플러그인은 서버, 선택 사항인 UI, 모델이 결정하는 도구 호출로 명확히 나뉩니다.
• Codex에 보내는 프롬프트는 작업 내용과 범위가 명확하고 결과를 쉽게 검증할 수 있을 때 가장 효과적입니다. 플러그인 개발이 이런 조건에 잘 맞습니다.
• 스킬과 AGENTS.md는 Codex가 프로젝트에 맞게 작업하는 데 필요한 재사용 가능한 지침과 프로젝트 규칙을 제공합니다.

스킬 설치 및 사용 방법은 스킬 문서를 참고하세요.

사용 방법

사전 준비

• 제품 전체를 채팅으로 옮기려 하기보다 사용자가 달성할 핵심 목표 하나부터 정하세요.
• 기술 스택을 미리 선택하세요. 서버에는 TypeScript나 Python을, 위젯에는 React 또는 기본 HTML, CSS, JavaScript를 사용하세요.
• 개발 중 HTTPS로 접속할 방법을 정하세요. 예를 들어 ngrok이나 Cloudflare Tunnel을 사용할 수 있습니다.
• 일부 설정에서는 여전히 MCP 서버 연결을 예전 명칭으로 표시합니다. 로컬 테스트 중에 이런 이름이 보이면 등록된 서버를 가리키는 것으로 이해하세요.

1. 플러그인으로 달성할 구체적인 목표 하나를 정하고, Codex에 이름, 설명, 입력, 출력이 명확한 도구 3~5개를 제안해 달라고 하세요.
2. 첫 버전에서 데이터만 제공해도 되는지, 위젯이 필요한지 결정하세요. 종속성을 추가하기 전에 리포지터리의 기존 패턴에 따라 MCP 서버의 기본 구조를 만들고, 위젯이 필요하면 위젯의 기본 구조도 만드세요.
3. MCP 서버를 로컬에서 실행해 HTTPS로 접속할 수 있게 하세요. ChatGPT에서 사용자 지정 MCP 서버 추가로 연결한 뒤, 도구를 직접 요청하는 경우, 간접적으로 요청하는 경우, 호출하면 안 되는 경우를 소수의 프롬프트로 테스트하세요.
4. 핵심 읽기 플로우가 ChatGPT에서 안정적으로 작동할 때까지 메타데이터, 상태 처리, structuredContent 및 _meta 페이로드를 조정하세요.
5. 사용자별 데이터를 다루거나 쓰기 작업을 수행하는 데 필요한 경우에만 OAuth 2.1을 추가하세요. 익명 또는 읽기 전용 플로우는 단순하게 유지하세요.
6. 안정적인 /mcp 엔드포인트를 갖춘 미리보기 버전을 호스팅하고, 스트리밍과 UI 에셋 호스팅이 제대로 작동하는지 확인하세요. 플러그인을 공유하거나 제출하기 전에 출시 체크리스트를 검토하세요.

추천 프롬프트

이 워크플로우에서 효과적인 프롬프트에는 다음 내용이 들어갑니다.

• 명확한 목표 하나: 사용자가 ChatGPT 안에서 플러그인으로 무엇을 할 수 있어야 하는지 설명하세요.
• 구체적인 기술 스택: 서버에 TypeScript와 Python 중 무엇을 쓸지, 위젯에 React를 쓸지 가볍게 구현할지 명시하세요.
• 명확한 도구별 역할: 각 도구가 한 가지 작업만 담당하도록 소수의 도구를 제안하거나 구현해 달라고 하세요.
• 인증 요구사항: 첫 버전을 익명으로 사용할 수 있는지, 계정 연결과 쓰기 작업이 필요한지 명시하세요.
• 로컬 개발 환경: ChatGPT에서 HTTPS로 테스트할 때 사용할 터널이나 호스팅 경로를 알려 주세요.
• 검증 단계: 실행할 명령어, 테스트할 프롬프트, 결과와 함께 제시할 근거를 Codex에 알려 주세요.

기획, 구현, 인증, 배포, 제출, 마무리 작업까지 하나의 긴 프롬프트로 한꺼번에 요청하지 마세요. 작업을 더 작은 단계로 나누세요.

기본 구조를 만들기 전에 플러그인 설계하기

실제로 작동하는 첫 버전의 기본 구조 만들기

핵심 플로우가 작동하는지 확인한 뒤 인증 추가하기

플러그인 배포 및 검토 준비하기

출시 준비 점검

• 플러그인의 목표가 하나로 좁혀져 있고 사용자가 쉽게 이해할 수 있습니다.
• 도구 수가 적고 각 도구의 메타데이터, 입력, 출력이 명확합니다.
• MCP 서버가 처음부터 끝까지 정상적으로 작동하고 간결한 structuredContent를 반환하며, 위젯 전용 데이터는 _meta에만 담습니다.
• 위젯이 필요한 경우 ChatGPT 안에서 올바르게 표시됩니다.
• ChatGPT에 사용자 지정 MCP 서버를 연결한 상태에서 로컬 HTTPS 테스트를 반복할 수 있습니다.
• 도구를 직접 요청하는 경우, 간접적으로 요청하는 경우, 호출하면 안 되는 경우를 다루는 소수의 프롬프트로 테스트했을 때 대화 플로우와 도구 페이로드가 모두 예상과 일치합니다.
• 사용자별 데이터나 쓰기 작업에 필요한 곳에만 인증을 적용합니다.
• 플러그인을 공유하거나 제출하기 전에 배포 계획과 출시 준비 검토에서 메타데이터, 도구 힌트, 개인정보 보호, 테스트 프롬프트를 점검합니다.

흔히 하는 실수

• Codex에 제품 전체를 ChatGPT로 옮겨 달라고 요청하는 경우. 사용자의 핵심 목표 하나에 맞춰 도구 3~5개와 기능 범위가 좁은 위젯 하나를 요청하세요.
• 처음부터 하나의 긴 프롬프트로 구현 전체를 요청하는 경우. 작업을 설계, 기본 구조 생성, 인증, 배포, 검토 단계로 나누세요.
• 도구의 동작 규약이 명확해지기 전에 UI부터 작성하는 경우. 제공할 도구와 응답 스키마를 먼저 설계한 뒤 위젯을 만드세요.
• 공식 문서를 활용한 그라운딩을 생략하는 경우. $chatgpt-apps와 $openai-docs를 함께 사용해 최신 플러그인 지침에 맞는 기본 구조를 만드세요.
• 메타데이터 작성을 뒤로 미루는 경우. 도구 설명과 매개변수 문서를 일찍 작성한 뒤, 같은 프롬프트 모음으로 도구가 예상대로 호출되는지 다시 테스트하세요.
• 익명 또는 읽기 전용 플로우를 검증하기 전에 인증을 추가하는 경우. 먼저 핵심 도구 플로우가 작동하는지 확인한 뒤, 실제로 필요한 도구에만 OAuth를 추가하세요.
• ChatGPT에서 테스트하기 전에 플러그인이 완성됐다고 판단하는 경우. ChatGPT에 사용자 지정 MCP 서버를 연결하고 도구 페이로드를 살펴본 뒤 실제 대화 플로우를 검증하세요.