MCP, 플러그인, Skills로 Codex 확장하기
Codex는 혼자 일할 때보다 연결될 때 강해진다
지금까지 우리는 Codex에게 코드를 읽히고, 수정하게 하고, 테스트를 돌리게 하고, GitHub PR까지 연결하는 흐름을 익혔다. 이 정도만 해도 이미 훌륭한 개발 파트너처럼 보인다. 그런데 실제 앱 개발은 코드 파일만으로 끝나지 않는다.
기획은 Notion이나 Google Docs에 있고, 디자인은 Figma에 있으며, 이슈는 GitHub나 Linear에 쌓인다. 오류는 Sentry에 기록되고, 배포는 Vercel, Cloudflare, Netlify 같은 도구에서 일어난다. 데이터는 Supabase나 PostgreSQL에 있고, 프론트엔드가 제대로 작동하는지는 브라우저에서 확인해야 한다.
초보자가 처음 Codex를 사용할 때 자주 하는 실수는 "Codex에게 코드만 맡기는 것"이다. 물론 Codex는 코드를 잘 쓴다. 하지만 외부 도구와 연결하면 Codex는 단순한 코드 생성기를 넘어 앱 제작의 허브가 된다. 문서를 읽고, 디자인을 해석하고, 브라우저를 조작하고, 오류 추적 도구에서 원인을 가져오고, GitHub 이슈를 보고 작업 계획까지 세울 수 있다.
이 장에서 다룰 세 가지 확장 방식은 다음과 같이 이해하면 쉽다.
MCP는 Codex가 외부 도구와 대화하는 표준 연결 통로다.
플러그인은 MCP 서버, 앱 연결, Skills 등을 설치 가능한 묶음으로 포장한 것이다.
Skills는 반복되는 작업 절차를 재사용 가능한 "작업 레시피"로 만든 것이다.
비유하자면 MCP는 전기 콘센트, 플러그인은 멀티탭 세트, Skill은 "이 콘센트에 무엇을 꽂고 어떤 순서로 작업할지" 적어 둔 요리법이다. 콘센트만 많다고 요리가 완성되지는 않는다. 어떤 도구를 언제 쓰는지 정리되어 있어야 결과가 안정적이다.
MCP를 아주 쉽게 이해하기
MCP는 Model Context Protocol의 약자다. 이름은 어렵지만 핵심은 간단하다. Codex 같은 AI 모델이 외부 문서, API, 개발 도구와 통신할 수 있도록 만든 표준 방식이다. OpenAI 문서에서도 MCP를 "모델을 도구와 컨텍스트에 연결하는 방식"으로 설명하며, Codex CLI와 IDE 확장에서 MCP 서버를 사용할 수 있다고 안내한다.1
여기서 중요한 단어는 서버다. MCP 서버는 꼭 인터넷 어딘가에 있는 큰 서버를 뜻하지 않는다. 내 컴퓨터에서 실행되는 작은 프로그램일 수도 있다. 예를 들어 Playwright MCP 서버는 Codex가 브라우저를 열고 버튼을 누르고 화면을 검사할 수 있도록 도와준다. GitHub MCP 서버는 Codex가 이슈, PR, 레포지토리 정보를 읽고 다룰 수 있게 해 준다.
작동 흐름은 대략 이렇다.
사용자 요청
↓
Codex가 필요한 도구 판단
↓
MCP 서버의 도구 목록 확인
↓
Codex가 MCP 도구 호출
↓
MCP 서버가 실제 외부 서비스나 로컬 도구 실행
↓
결과를 Codex에게 반환
↓
Codex가 코드 수정, 설명, 테스트, 요약 수행예를 들어 사용자가 이렇게 말한다고 해 보자.
GitHub 이슈 #42를 읽고, 관련 파일을 찾아서 버그를 수정한 다음 테스트까지 실행해줘.GitHub MCP가 연결되어 있다면 Codex는 이슈 내용을 가져올 수 있다. 프로젝트 파일은 기존처럼 로컬에서 읽는다. 테스트는 터미널로 실행한다. 만약 Playwright MCP도 연결되어 있다면 브라우저에서 실제 화면까지 확인할 수 있다. 즉, Codex가 "코드 작성자"에서 "작업 조율자"로 바뀐다.
STDIO 서버와 환경 변수부터 익히기
초보자가 MCP 설정에서 가장 먼저 만나게 되는 방식은 STDIO 서버다. STDIO는 Standard Input/Output의 줄임말로, 프로그램이 터미널 입출력을 통해 서로 대화하는 방식이다. 어렵게 느껴지지만 실제 설정은 "어떤 명령어로 MCP 서버를 실행할지" 적는 것에 가깝다.
Codex의 MCP 설정은 보통 config.toml 같은 설정 파일에 작성한다. 전역 설정은 내 사용자 계정 전체에 적용되고, 프로젝트 설정은 현재 프로젝트에만 적용된다. 실제 위치나 UI는 Codex CLI, IDE 확장, Codex App 버전에 따라 조금씩 다를 수 있지만, 핵심 원리는 같다. 공통 설정에 MCP 서버를 등록하고, 필요한 프로젝트에서만 켜는 것이다.
예를 들어 Context7 MCP를 연결해 최신 라이브러리 문서를 찾게 하고 싶다면 이런 식의 설정을 생각할 수 있다.
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp@latest"]이 설정은 Codex에게 "context7이라는 MCP 서버가 필요하면 npx -y @upstash/context7-mcp@latest 명령으로 실행해"라고 알려 주는 것이다.
GitHub처럼 인증이 필요한 도구는 토큰이 필요하다. 이때 토큰을 프롬프트나 AGENTS.md에 직접 쓰면 안 된다. 보통 환경 변수로 관리한다.
[mcp_servers.github]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-github"]
env_vars = ["GITHUB_PERSONAL_ACCESS_TOKEN"]그리고 터미널이나 비밀 관리 도구에서 환경 변수를 설정한다.
export GITHUB_PERSONAL_ACCESS_TOKEN="ghp_..."여기서 꼭 기억해야 할 점이 있다. 환경 변수 이름은 설정 파일에 적어도 되지만, 실제 토큰 값은 가능하면 설정 파일에 직접 쓰지 않는다. 설정 파일이 Git에 올라가면 토큰이 유출될 수 있기 때문이다.
초보자라면 처음부터 모든 MCP 서버를 연결하려고 하지 말자. 우선 문서 검색용 서버 하나, 브라우저 검증용 서버 하나 정도로 시작하는 편이 좋다.
어떤 MCP를 언제 쓰면 좋을까
MCP 서버는 많고, 각각 역할이 다르다. 중요한 것은 "유명한 서버를 모두 설치하는 것"이 아니라 "내 프로젝트의 병목을 줄여 주는 서버만 선택하는 것"이다.
OpenAI Docs MCP와 Context7: 최신 문서 확인용
프론트엔드 초보자가 Next.js, React, Tailwind CSS, Supabase 같은 라이브러리로 앱을 만들다 보면 가장 흔히 겪는 문제가 있다. 블로그 글은 오래됐고, 예제 코드는 버전이 다르며, Codex가 알고 있는 방식과 현재 공식 문서의 방식이 어긋날 때가 있다.
이때 문서 검색용 MCP가 유용하다. OpenAI Docs MCP나 Context7 같은 문서 컨텍스트 도구를 연결하면 Codex가 최신 문서와 사용법을 근거로 코드를 작성하도록 유도할 수 있다.
실전 프롬프트는 이렇게 쓸 수 있다.
Context7을 사용해서 현재 Next.js App Router의 최신 서버 액션 사용법을 확인한 뒤,
우리 프로젝트의 src/app/actions.ts에 맞는 예제로 회원가입 액션을 구현해줘.
조건:
- 기존 폴더 구조를 유지해줘.
- Zod로 입력값을 검증해줘.
- 문서에서 확인한 근거를 요약해줘.
- 구현 후 npm run lint를 실행해줘.여기서 핵심은 "문서를 찾아봐"라고만 말하지 않는 것이다. 어떤 라이브러리의 어떤 기능을 확인할지, 어느 파일에 반영할지, 완료 기준이 무엇인지 함께 알려 줘야 한다.
GitHub MCP: 이슈와 PR을 작업 흐름으로 연결
GitHub MCP는 이슈, PR, 브랜치, 커밋, 리뷰 코멘트 같은 협업 정보를 다룰 때 유용하다. 지난 장에서 Codex Cloud와 GitHub PR 흐름을 다뤘다면, MCP는 그 흐름을 더 촘촘하게 만든다.
예를 들어 이런 작업이 가능하다.
GitHub 이슈 #18을 읽고 다음 순서로 진행해줘.
1. 이슈가 요구하는 기능을 한 문단으로 요약해줘.
2. 관련 파일을 찾아 구현 계획을 세워줘.
3. 변경 범위를 src/features/billing 안으로 제한해줘.
4. 구현 후 테스트를 추가하고 npm test를 실행해줘.
5. 커밋 메시지와 PR 설명 초안을 작성해줘.초보자에게 특히 좋은 점은 "이슈 내용을 복사해서 붙여넣는 일"이 줄어든다는 것이다. Codex가 이슈를 읽고 코드베이스와 연결할 수 있으면, 요구사항과 구현 사이의 거리가 짧아진다.
다만 GitHub 토큰 권한은 반드시 최소화해야 한다. 개인 실습에서는 특정 레포지토리만 접근 가능하게 하고, 가능하면 읽기 권한부터 시작한다. 이슈를 읽는 작업에 조직 전체 관리자 권한은 필요하지 않다.
Figma MCP: 디자인을 코드로 옮길 때
프론트엔드 작업에서 가장 난감한 순간은 "디자인은 있는데 코드로 어떻게 옮길지 모르겠다"는 때다. Figma MCP를 연결하면 Codex가 디자인 파일의 구조, 색상, 간격, 텍스트 스타일 같은 정보를 가져와 React 컴포넌트나 CSS로 변환하는 데 도움을 줄 수 있다.
좋은 프롬프트는 막연히 "이 Figma를 구현해줘"가 아니다.
Figma MCP로 아래 프레임을 확인하고 PricingCard 컴포넌트를 만들어줘.
대상:
- Figma 파일: [파일 URL]
- 프레임 이름: Pricing / Mobile / Basic Plan
구현 조건:
- React + TypeScript 컴포넌트로 작성
- Tailwind CSS 사용
- 기존 Button 컴포넌트(src/components/ui/Button.tsx)를 재사용
- 픽셀 단위 완벽 복제보다 디자인 토큰과 반응형 구조를 우선
- 375px 모바일 화면에서 먼저 확인여기서 "픽셀 단위 완벽 복제보다 디자인 토큰과 반응형 구조를 우선"이라는 조건이 중요하다. AI가 디자인을 그대로 베끼려다 너무 복잡한 마크업을 만들 수 있기 때문이다. 우리는 앱을 만들어야지, Figma를 HTML로 박제하려는 것이 아니다.
Playwright MCP: 브라우저에서 실제로 확인하기
Codex가 코드를 고쳤다고 해서 앱이 잘 작동하는 것은 아니다. 버튼이 눌리지 않을 수도 있고, 로그인 후 이동이 안 될 수도 있으며, 모바일에서 레이아웃이 깨질 수도 있다. Playwright MCP는 Codex가 브라우저를 조작하고 실제 사용자 흐름을 점검하는 데 도움이 된다.
예를 들어 할 일 관리 앱을 만들었다면 이렇게 요청할 수 있다.
Playwright MCP로 로컬 앱을 열어 실제 사용자 흐름을 확인해줘.
확인할 시나리오:
1. /todos 페이지 접속
2. "우유 사기" 할 일 추가
3. 추가된 항목이 목록에 보이는지 확인
4. 체크박스를 눌러 완료 처리
5. 새로고침 후 상태가 유지되는지 확인
실패하면 원인을 추정하지 말고,
브라우저에서 관찰한 증상과 콘솔 오류를 먼저 정리해줘.초보자는 테스트 코드를 처음부터 완벽하게 작성하기 어렵다. Playwright MCP를 연결하면 "사람처럼 눌러 보며 확인하는 과정"을 Codex에게 맡기고, 나중에 그 흐름을 E2E 테스트 코드로 바꾸게 할 수 있다.
Sentry MCP: 실제 오류를 코드 맥락으로 가져오기
앱을 배포하고 나면 로컬에서는 못 봤던 오류가 생긴다. 사용자의 브라우저, 실제 데이터, 네트워크 상태, 배포 환경이 모두 다르기 때문이다. Sentry 같은 오류 추적 도구는 이런 문제를 기록한다.
Sentry MCP를 연결하면 Codex에게 "오류 화면을 캡처해서 설명"하는 대신, 실제 오류 이벤트와 스택 트레이스, 발생 빈도, 영향을 받은 경로를 바탕으로 분석하게 할 수 있다.
Sentry MCP에서 최근 24시간 동안 가장 많이 발생한 프론트엔드 오류를 확인해줘.
작업 순서:
- 오류 메시지와 발생 경로를 요약
- 스택 트레이스가 가리키는 우리 코드 파일 찾기
- 재현 가능한 입력 조건 추정
- 최소 수정안을 제안
- 수정 전에는 파일을 변경하지 말고 계획부터 보여줘운영 오류를 다룰 때는 바로 수정하게 하지 말고, 먼저 계획을 보여 달라고 하는 것이 안전하다. 실제 사용자에게 영향을 주는 문제일수록 "빠른 수정"보다 "근거 있는 수정"이 중요하다.
데이터베이스와 배포 도구: 읽기 전용부터 시작하기
데이터베이스 MCP나 배포 도구 MCP도 강력하다. Codex가 스키마를 읽고 API 코드를 맞추거나, 배포 로그를 확인하고 실패 원인을 정리할 수 있다. 하지만 그만큼 위험도 크다.
초보자에게 권장하는 시작 방식은 읽기 전용이다.
데이터베이스 MCP를 사용해서 현재 users, projects, tasks 테이블 구조만 읽어줘.
절대 데이터를 수정하거나 삭제하지 마.
그다음 Prisma schema와 실제 DB 구조가 다른 부분이 있는지 비교해줘.배포 도구도 마찬가지다.
Vercel 배포 로그를 확인해서 최근 실패한 빌드의 원인을 요약해줘.
아직 재배포하지 말고, 수정해야 할 파일과 예상 원인만 알려줘.처음부터 "알아서 DB 마이그레이션하고 배포까지 해줘"라고 맡기면 위험하다. 데이터베이스와 배포는 앱의 심장과 출입문이다. 읽기, 분석, 계획, 승인, 실행 순서로 천천히 확장하자.
CLI, IDE, App에서 설정을 어떻게 나눌까
Codex는 CLI, IDE 확장, App처럼 여러 인터페이스에서 사용할 수 있다. 화면은 다르지만 초보자는 다음 원칙으로 정리하면 된다.
전역 설정에는 여러 프로젝트에서 공통으로 쓰는 안전한 기본값을 둔다. 예를 들어 승인 정책, 기본 모델, 자주 쓰는 문서 검색 MCP 정도가 여기에 들어갈 수 있다. 반면 프로젝트 설정에는 해당 프로젝트에서만 필요한 MCP를 둔다. 예를 들어 쇼핑몰 프로젝트의 결제 도구, 회사 내부 문서 MCP, 특정 데이터베이스 연결은 프로젝트 설정에 두는 편이 안전하다.
AGENTS.md는 도구 설정 파일이 아니라 작업 지침 파일이다. 따라서 토큰이나 서버 실행 명령을 길게 넣기보다, "이 프로젝트에서 MCP를 어떻게 사용해야 하는지" 규칙을 적는 데 적합하다.
예를 들어 프로젝트의 AGENTS.md에는 이렇게 쓸 수 있다.
## MCP 사용 규칙
- GitHub MCP는 이슈와 PR 조회에 사용하되, PR 생성 전 사용자 승인을 받는다.
- Playwright MCP는 UI 변경 후 `/login`, `/dashboard`, `/settings` 흐름 검증에 사용한다.
- 데이터베이스 MCP는 기본적으로 읽기 전용으로 사용한다.
- `.env`, `.env.local`, credentials 폴더는 읽거나 출력하지 않는다.
- 운영 배포, DB 마이그레이션, 대량 삭제 작업은 반드시 계획을 먼저 제시한다.이렇게 해 두면 새 채팅을 시작해도 Codex가 프로젝트의 안전 규칙을 다시 읽을 수 있다. 앞 장에서 만든 AGENTS.md가 여기서 더 중요해지는 이유다.
플러그인은 설치 가능한 확장 묶음이다
MCP가 연결 통로라면, 플러그인은 그 연결과 작업 방식을 묶어서 설치 가능한 형태로 만든 것이다. OpenAI 개발자 문서에서는 Codex 플러그인이 Skills, 앱 통합, MCP 서버를 재사용 가능한 워크플로로 묶는다고 설명한다.2
예를 들어 Gmail 플러그인은 Gmail을 읽고 정리하는 연결과 관련 작업 방식을 함께 제공할 수 있다. Google Drive 플러그인은 Docs, Sheets, Slides와 이어질 수 있다. Slack 플러그인은 채널 요약이나 답장 초안 작성에 쓰일 수 있다.
개발 관점에서는 플러그인을 이렇게 이해하면 좋다.
플러그인 = MCP 서버 설정 + 앱 인증 + Skills + 사용 예시 + 설치/제거 단위개인 프로젝트에서는 꼭 플러그인까지 만들 필요가 없다. config.toml에 MCP 서버를 직접 등록하고, .codex/skills나 ~/.codex/skills에 Skill을 넣는 것으로 충분한 경우가 많다. 하지만 팀에서 같은 흐름을 반복해서 써야 한다면 플러그인이 편하다.
예를 들어 팀 전체가 같은 방식으로 PR을 리뷰하고, 같은 Sentry 프로젝트를 확인하고, 같은 배포 전 체크리스트를 수행해야 한다고 해 보자. 이때 각자에게 "이 설정 복사하고, 이 Skill 폴더 만들고, 이 MCP 설치하고…"라고 안내하면 실수가 생긴다. 플러그인으로 묶으면 설치와 업데이트가 쉬워진다.
Skills는 반복 작업을 레시피로 만드는 방법이다
Skills는 초보자에게 특히 유용하다. 왜냐하면 초보자는 매번 좋은 프롬프트를 새로 쓰기 어렵기 때문이다. Skills는 자주 하는 작업의 순서, 기준, 주의사항을 파일로 저장해 두고 필요할 때 Codex가 재사용하게 하는 방식이다.
커뮤니티의 Codex Skills 저장소들은 Skills를 "특정 작업을 원하는 방식으로 수행하도록 하는 모듈형 지침 묶음"으로 설명한다. 일반적으로 Skill은 SKILL.md 같은 Markdown 파일과 선택적인 스크립트, 참고 자료, 템플릿으로 구성된다.3
아주 단순한 Skill은 이렇게 생겼다.
---
name: pre-deploy-check
description: 배포 전에 빌드, 테스트, 환경 변수, 보안 위험을 점검할 때 사용한다.
---
## 목적
배포 전에 앱이 최소한의 품질 기준을 만족하는지 확인한다.
## 절차
1. 변경된 파일 목록을 확인한다.
2. 패키지 매니저를 확인하고 올바른 명령을 선택한다.
3. 린트, 타입 체크, 테스트, 빌드를 순서대로 실행한다.
4. `.env` 값은 출력하지 말고 필요한 변수 이름만 확인한다.
5. 실패한 단계가 있으면 원인, 관련 파일, 수정 제안을 정리한다.
6. 모든 단계가 통과하면 배포 가능 여부를 요약한다.
## 금지 사항
- 사용자 승인 없이 production 배포를 실행하지 않는다.
- 사용자 승인 없이 데이터베이스 마이그레이션을 실행하지 않는다.
- 비밀값을 화면에 출력하지 않는다.이제 매번 긴 프롬프트를 쓰지 않아도 된다.
pre-deploy-check Skill을 사용해서 현재 브랜치 배포 준비 상태를 확인해줘.또는 Codex가 작업 설명을 보고 자동으로 적절한 Skill을 선택할 수도 있다. 다만 초보자라면 처음에는 Skill 이름을 직접 언급하는 편이 예측 가능하다.
실전 Skill 예제: Figma 화면을 React 컴포넌트로 변환하기
프론트엔드 작업을 자주 한다면 Figma 화면을 컴포넌트로 변환하는 Skill을 만들어 둘 수 있다.
---
name: figma-to-react-component
description: Figma 프레임을 React TypeScript 컴포넌트로 변환할 때 사용한다. 디자인 토큰, 반응형 레이아웃, 기존 UI 컴포넌트 재사용을 우선한다.
---
## 입력으로 받아야 할 정보
- Figma 파일 URL 또는 프레임 이름
- 구현할 컴포넌트 이름
- 대상 화면 크기
- 사용할 스타일 방식: Tailwind CSS, CSS Modules, styled-components 등
- 재사용해야 할 기존 컴포넌트 경로
## 작업 절차
1. Figma MCP로 프레임 구조와 디자인 토큰을 확인한다.
2. 프로젝트의 기존 컴포넌트 구조를 읽는다.
3. 새 컴포넌트의 props 타입을 먼저 제안한다.
4. 사용자가 승인하면 컴포넌트를 구현한다.
5. Storybook 또는 예제 페이지가 있으면 미리보기를 추가한다.
6. Playwright MCP 또는 브라우저 미리보기로 375px, 768px, 1280px 화면을 확인한다.
7. 디자인과 다르게 보이는 부분을 목록으로 정리한다.
## 품질 기준
- 하드코딩된 임의 색상보다 프로젝트 토큰을 우선한다.
- 복잡한 absolute positioning은 피한다.
- 텍스트와 이미지는 props로 교체 가능하게 만든다.
- 접근성을 위해 버튼, 링크, 이미지 대체 텍스트를 확인한다.이 Skill이 있으면 프롬프트가 훨씬 짧아진다.
figma-to-react-component Skill을 사용해 Pricing 카드 화면을 구현해줘.
프레임은 "Pricing / Desktop / Pro"이고,
컴포넌트 이름은 PricingPlanCard로 해줘.초보자는 여기서 한 가지를 꼭 기억하자. 디자인 변환 Skill은 "한 번에 완성"이 아니라 "초안을 빠르게 만들고 검증하는 도구"다. 특히 여백, 폰트 크기, 반응형 줄바꿈은 브라우저에서 눈으로 확인해야 한다.
실전 Skill 예제: 배포 전 체크리스트 수행하기
배포 전에는 늘 같은 불안이 생긴다. "테스트 돌렸나?", "환경 변수 빠진 건 없나?", "빌드는 되나?", "로그인이 깨지진 않았나?" 이런 반복 확인은 Skill로 만들기 좋다.
---
name: release-readiness-check
description: PR 병합 또는 배포 전에 앱의 테스트, 빌드, 환경 변수, 주요 사용자 흐름을 점검할 때 사용한다.
---
## 절차
1. 현재 브랜치와 main 브랜치의 diff를 요약한다.
2. package.json을 읽고 lint, test, build 명령을 확인한다.
3. 가능한 경우 lint → typecheck → test → build 순서로 실행한다.
4. 인증, 결제, 대시보드처럼 핵심 경로가 바뀌었는지 확인한다.
5. Playwright MCP가 연결되어 있으면 핵심 사용자 흐름을 브라우저에서 확인한다.
6. 배포 도구 MCP가 연결되어 있으면 최근 배포 실패 로그를 참고한다.
7. 최종 결과를 "통과", "주의", "차단"으로 분류한다.
## 보고 형식
- 요약
- 실행한 명령
- 실패한 항목
- 수정이 필요한 파일
- 배포 전 반드시 확인할 사항사용 프롬프트는 이렇다.
release-readiness-check Skill로 현재 PR이 배포 가능한지 확인해줘.
아직 배포는 하지 말고 결과 보고서만 작성해줘.이 Skill의 핵심은 "배포하지 말고 보고서만"이다. 초보자는 자동화가 편하다고 해서 바로 실행 권한을 넓히면 안 된다. 배포는 되돌릴 수 있더라도, 사용자에게 영향을 준 뒤에는 이미 늦을 수 있다.
실전 Skill 예제: GitHub 이슈 triage하기
프로젝트가 커지면 이슈가 쌓인다. 버그인지 기능 요청인지, 급한지 아닌지, 누가 봐야 하는지 정리하는 일도 시간이 걸린다. GitHub MCP와 함께 이슈 triage Skill을 만들면 반복 업무를 줄일 수 있다.
---
name: github-issue-triage
description: GitHub 이슈를 읽고 유형, 우선순위, 영향 범위, 다음 액션을 정리할 때 사용한다.
---
## 분류 기준
- bug: 기존 기능이 의도대로 작동하지 않음
- feature: 새 기능 요청
- docs: 문서 수정 또는 설명 부족
- question: 사용법 질문
- chore: 유지보수, 설정, 의존성 업데이트
## 우선순위 기준
- P0: 서비스 중단, 데이터 손실, 보안 사고
- P1: 핵심 기능 장애, 다수 사용자 영향
- P2: 우회 가능한 버그 또는 일반 기능 요청
- P3: 개선 제안, 문서, 낮은 영향도 작업
## 작업 절차
1. 최근 열린 이슈 목록을 가져온다.
2. 각 이슈를 2문장 이내로 요약한다.
3. 유형과 우선순위를 제안한다.
4. 재현 정보가 부족하면 필요한 질문을 작성한다.
5. 관련 코드 영역을 추정하되, 확실하지 않으면 UNCONFIRMED로 표시한다.
6. 라벨 변경이나 댓글 작성은 사용자 승인 후에만 수행한다.사용 프롬프트는 이렇게 간단해진다.
github-issue-triage Skill로 최근 10개 이슈를 분류해줘.
라벨은 아직 적용하지 말고 제안만 보여줘.팀 프로젝트에서는 이런 Skill이 특히 효과적이다. 누가 하든 같은 기준으로 이슈를 정리할 수 있기 때문이다.
너무 많이 연결하면 오히려 멍청해진다
MCP와 플러그인, Skills를 배우면 갑자기 모든 것을 연결하고 싶어진다. GitHub, Figma, Playwright, Sentry, Notion, Slack, Google Drive, Gmail, 데이터베이스, 배포 도구, 분석 도구까지 한 번에 붙이고 싶어진다.
하지만 초보자에게 가장 중요한 경고가 있다. 도구를 많이 연결할수록 Codex가 더 똑똑해지는 것은 아니다. 오히려 필요 없는 도구 목록이 너무 많아지면 모델 컨텍스트가 오염되고, Codex가 어떤 도구를 써야 할지 헷갈릴 수 있다. MCP를 많이 연결하면 불필요한 도구 호출과 큰 응답 때문에 컨텍스트가 낭비될 수 있다는 지적도 있다.4
이 문제를 쉽게 말하면 이렇다. 주방에서 라면 하나 끓이려는데 조리대 위에 믹서기, 에어프라이어, 제면기, 제빙기, 커피머신, 토치, 캠핑 버너가 전부 올라와 있는 상황이다. 도구가 많다고 요리가 빨라지지 않는다. 오히려 냄비를 찾는 시간이 늘어난다.
초보자는 다음 순서로 확장하면 안전하다.
문서 검색 MCP 하나로 최신 라이브러리 사용법을 보강한다.
Playwright MCP로 브라우저 검증을 추가한다.
GitHub MCP로 이슈와 PR 흐름을 연결한다.
프론트엔드 비중이 커지면 Figma MCP를 추가한다.
배포 후 운영 단계에서 Sentry MCP와 배포 도구 MCP를 추가한다.
그리고 프로젝트별로 필요한 것만 켠다. 모든 프로젝트에 모든 MCP를 전역으로 켜 두는 방식은 피하는 것이 좋다.
allowlist와 최소 권한 원칙
확장 기능을 연결할 때 보안의 기본은 최소 권한 원칙이다. 필요한 권한만 주고, 필요 없어지면 제거한다.
실전에서 지켜야 할 기준은 명확하다.
GitHub 토큰은 모든 저장소가 아니라 필요한 저장소에만 접근하게 한다.
데이터베이스 연결은 처음에는 읽기 전용 계정으로 시작한다.
배포 도구는 preview 배포 권한과 production 배포 권한을 구분한다.
Figma는 필요한 파일 또는 팀 범위만 허용한다.
Sentry는 오류 조회 권한부터 시작하고 설정 변경 권한은 제한한다.
Codex의 샌드박스 권한도 함께 봐야 한다. MCP 서버가 로컬 프로세스로 실행된다면, 그 프로세스가 네트워크에 접근하거나 파일을 읽을 수 있는지 확인해야 한다. "Codex는 안전하겠지"가 아니라 "Codex가 부르는 도구가 무엇을 할 수 있는지"까지 봐야 한다.
AGENTS.md에는 이런 규칙을 짧게 적어 두면 좋다.
## 보안 규칙
- 운영 DB에 쓰기 작업을 수행하지 않는다.
- production 배포는 사용자 명시 승인 없이는 실행하지 않는다.
- `.env*`, 토큰, 쿠키, 세션 값은 읽거나 출력하지 않는다.
- MCP 도구가 대량 수정, 삭제, 전송 작업을 하려면 먼저 계획을 제시한다.
- 외부 서비스에 댓글, 메시지, 이메일을 보내기 전에는 초안을 보여주고 승인받는다.이 정도만 있어도 사고 가능성이 크게 줄어든다.
초보자를 위한 MCP 설정 실습: 문서 검색과 브라우저 검증만 붙이기
처음 실습은 작게 시작하자. 목표는 "Codex가 최신 문서를 참고하고, 브라우저에서 결과를 확인하는 흐름"을 만드는 것이다.
프로젝트의 .codex/config.toml에 다음처럼 설정한다고 가정해 보자. 실제 파일 위치와 UI는 사용하는 Codex 버전에 맞게 조정하면 된다.
# .codex/config.toml
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp@latest"]
[mcp_servers.playwright]
command = "npx"
args = ["-y", "@playwright/mcp"]그다음 Codex를 재시작하거나 MCP 목록을 새로고침한다. CLI라면 MCP 목록을 확인하는 명령이나 /mcp 같은 인터페이스를 사용할 수 있고, IDE나 App에서는 MCP 설정 화면에서 연결 상태를 확인한다.
이제 작은 작업을 맡겨 보자.
Context7로 React Hook Form의 최신 사용법을 확인한 뒤,
우리 프로젝트의 ContactForm 컴포넌트에 이메일 검증을 추가해줘.
완료 후 Playwright MCP로 /contact 페이지를 열고 다음을 확인해줘.
- 빈 이메일 제출 시 오류 메시지가 보이는지
- 잘못된 이메일 형식에서 오류가 보이는지
- 올바른 이메일 입력 시 제출 버튼이 활성화되는지
파일 변경 전에는 수정 계획을 먼저 보여줘.이 실습의 장점은 위험이 작다는 것이다. GitHub 토큰도 없고, 데이터베이스도 건드리지 않고, 배포도 하지 않는다. 문서를 보고 UI를 확인하는 수준이라 초보자가 MCP 감각을 익히기에 좋다.
MCP와 Skills를 함께 쓰는 실전 흐름
MCP와 Skills는 따로 쓰는 것보다 함께 쓸 때 더 강력하다. MCP는 도구를 제공하고, Skill은 그 도구를 어떤 순서로 사용할지 정한다.
예를 들어 "디자인 기반 프론트엔드 개선" 작업은 다음처럼 구성할 수 있다.
입력: Figma URL, 대상 페이지, 반응형 기준
사용 MCP: Figma MCP, Playwright MCP
사용 Skill: figma-to-react-component
결과: React 컴포넌트 수정, 브라우저 검증 보고서작업 프롬프트는 이렇게 쓸 수 있다.
figma-to-react-component Skill을 사용해 /pricing 페이지의 카드 디자인을 개선해줘.
Figma MCP로 "Pricing / Mobile" 프레임을 참고하고,
Playwright MCP로 375px와 1280px 화면을 확인해줘.
주의:
- 기존 가격 계산 로직은 수정하지 마.
- 스타일과 마크업만 변경해.
- 변경 후 diff 요약과 남은 차이를 알려줘.이 프롬프트는 좋은 확장 사용의 특징을 모두 갖고 있다. 사용할 Skill을 지정했고, 필요한 MCP를 언급했고, 변경 범위를 제한했고, 검증 방법을 제시했다. Codex가 엉뚱한 파일을 대규모로 고칠 가능성이 줄어든다.
확장 기능을 팀에서 관리하는 방법
혼자 공부할 때는 설정이 조금 지저분해도 괜찮다. 하지만 팀에서 쓰기 시작하면 "누구 컴퓨터에서는 되고, 누구 컴퓨터에서는 안 되는" 문제가 생긴다. 그래서 설정을 계층화해야 한다.
전역 설정에는 개인 취향과 공통 도구를 둔다. 프로젝트 설정에는 프로젝트에 필요한 MCP만 둔다. 팀 규칙은 AGENTS.md에 둔다. 반복 절차는 Skills로 만든다. 여러 팀원이 함께 써야 하는 묶음은 플러그인으로 배포한다.
예를 들어 팀 구조는 이렇게 잡을 수 있다.
~/.codex/config.toml
개인 기본 설정, 자주 쓰는 문서 검색 MCP
프로젝트/.codex/config.toml
프로젝트 전용 MCP: GitHub, Sentry, Figma, DB read-only
프로젝트/AGENTS.md
작업 규칙, 금지 사항, 테스트 명령, 승인 기준
프로젝트/.codex/skills/
프로젝트 전용 Skill: 배포 전 체크, 이슈 triage, 디자인 구현
팀 플러그인
여러 프로젝트에서 공유할 MCP + Skills + 앱 연결 묶음이렇게 나누면 설정이 커져도 관리가 가능하다. 특히 AGENTS.md와 Skills는 Git에 포함해 코드 리뷰를 받는 것이 좋다. "AI가 어떤 규칙으로 일하는가"도 이제 프로젝트 품질의 일부이기 때문이다.
연결하기 전에 스스로 물어볼 다섯 가지 질문
새 MCP 서버나 플러그인을 설치하기 전에는 잠깐 멈추고 다음 질문에 답해 보자.
이 도구가 지금 프로젝트의 어떤 반복 작업을 줄여 주는가?
이 도구 없이 프롬프트와 파일 읽기만으로 해결할 수는 없는가?
필요한 권한은 읽기인가, 쓰기인가, 관리자 권한인가?
이 도구가 반환하는 정보가 너무 커서 컨텍스트를 낭비하지는 않는가?
문제가 생겼을 때 토큰을 폐기하거나 연결을 해제하는 방법을 알고 있는가?
이 질문에 답하지 못한다면 아직 연결하지 않는 편이 낫다. 확장은 속도를 높이기 위한 것이지, 불안을 늘리기 위한 것이 아니다.
이 장의 핵심 정리
Codex는 코드만 다루는 도구가 아니다. MCP를 통해 문서, 디자인, 브라우저, GitHub, 데이터베이스, 배포 도구와 연결되면 앱 제작 전체를 조율하는 허브가 된다.
MCP는 외부 도구와 통신하는 표준 연결 방식이다. STDIO 서버는 로컬 프로세스로 실행되며, 환경 변수로 토큰과 설정을 주입하는 경우가 많다. GitHub, Figma, Playwright, Sentry, 문서 검색 MCP는 각각 협업, 디자인 구현, 브라우저 검증, 오류 분석, 최신 문서 확인에 유용하다.
플러그인은 MCP 서버와 앱 연결, Skills를 설치 가능한 묶음으로 만든 것이다. 개인 실습에서는 직접 설정으로 충분하지만, 팀이나 여러 프로젝트에서 반복한다면 플러그인으로 묶는 편이 좋다.
Skills는 반복 작업을 재사용 가능한 절차로 만든다. "Figma 화면을 React 컴포넌트로 변환", "배포 전 체크리스트 수행", "GitHub 이슈 triage"처럼 자주 하는 일을 Skill로 만들면 매번 긴 프롬프트를 쓰지 않아도 된다.
하지만 확장은 조심해야 한다. MCP 서버를 많이 연결할수록 Codex가 더 똑똑해지는 것이 아니라, 도구 목록과 응답이 컨텍스트를 오염시킬 수 있다. 프로젝트에 필요한 서버만 allowlist로 허용하고, OAuth·토큰·권한 범위·샌드박스 권한은 최소 권한 원칙으로 관리하자.
다음 장에서는 이 확장 개념을 한 단계 더 밀어붙인다. 반복적으로 해야 하는 개발 업무를 Automations로 자동화해, Codex가 정해진 시간이나 조건에 맞춰 백그라운드에서 일을 처리하게 만드는 방법을 배운다.
참고
1Model Context Protocol - Codex | OpenAI Developers
2Plugins - Codex | OpenAI Developers
4How to use MCPs with Codex (CLI, IDE, App) for 10x efficient workflows
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.