[Codex Agent]
│
├─[MCP]── GitHub API / DB / Browser
│ (실시간 외부 도구 연결)
│
├─[Plugin]── MCP 묶음 패키지
│ (설치·배포 단위)
│
└─[Skill]── .md 작업 흐름 파일
(재사용 단위)
각 층의 역할은 아래 섹션에서 하나씩 살펴본다.
목차
MCP가 왜 중요한가
MCP 서버 등록 — STDIO와 HTTP
CLI ↔ TOML 매핑 빠른 참조
권장 MCP 서버 후보 3종
도구 권한과 타임아웃 제어
Skills — 이론과 실제 설치
Plugins — 배포와 실제 설치
정리와 의사결정 트리
개념
한 줄 설명
언제 쓰나
MCP 서버
Codex가 외부 도구·데이터에 접근하는 연결 통로
GitHub 이슈, 라이브러리 문서, 브라우저 등 저장소 밖 자원이 필요할 때
Plugin
Skills·앱 연동·MCP 서버를 묶어 설치 가능한 형태로 배포하는 단위
팀 전원에게 동일한 확장 묶음을 배포해야 할 때
Skill
반복 작업 절차를 SKILL.md 파일로 정의해 Codex가 재사용하는 지침
릴리스 노트 작성, 보안 점검 등 팀 내 반복 작업을 표준화할 때
STDIO 서버
로컬 프로세스를 실행해 MCP 서버와 표준 입출력으로 통신하는 방식
네트워크 설정 없이 로컬에서 빠르게 MCP 서버를 테스트할 때
HTTP 서버
URL로 접근하는 외부 MCP 서버 — 인증 토큰으로 연결
Figma, GitHub 등 외부 SaaS 서비스를 Codex 작업에 연결할 때
1. MCP가 왜 중요한가
Codex의 기본 능력은 현재 프로젝트를 읽고, 코드를 수정하고, 셸 명령을 실행하는 데 있다.
하지만 실제 개발 업무는 저장소 안에서만 끝나지 않는다. 이슈 트래커, 문서 사이트, 디자인 파일, 브라우저, 로그 시스템까지 함께 봐야 할 때가 많다.
나도 처음에 Codex로 코드만 고치다가, "그래서 이 라이브러리 최신 문서대로 맞췄나?"가 늘 걸렸다. 외부 문서·이슈를 같이 보게 만드는 통로가 바로 MCP다.
MCP 공식 문서는 Codex에서 MCP 서버를 설정하는 방법을 다룬다. 여기서 중요한 점은 MCP를 "또 하나의 플러그인 이름"으로 보는 것이 아니라, Codex가 외부 도구나 공유 정보에 접근하는 서버 연결 방식으로 이해하는 것이다.
MCP 연결할 때 자주 듣는 두 단어
tool discovery: 에이전트가 MCP 서버에 "너 어떤 기능 있어?"라고 묻는 과정. 서버가 지원하는 도구 목록을 자동으로 파악한다.
capability negotiation: 연결 초기에 에이전트와 MCP 서버가 서로 지원 기능을 확인하고 맞추는 협상 과정. 두 사람이 만나기 전에 "나는 영어, 너는 한국어 가능해?"부터 맞추는 것과 같다.
MCP 서버가 많을수록 Codex가 더 유능해질까?
툴킷이 많을수록 더 유능하다는 직관은 MCP에서 그대로 통하지 않는다. 오히려 반대로 작동하는 상황이 있다.
MCP tool result를 통한 prompt injection — MCP 서버가 반환하는 텍스트 안에 지시문이 숨어 있으면 Codex가 그것을 다음 행동의 지시로 읽을 수 있다. 공식 문서는 이 공격 벡터를 별도로 다루지 않는다. 하지만 외부 MCP 서버가 반환하는 데이터를 신뢰 경계 밖 입력으로 취급해야 하는 이유가 여기 있다.
MCP가 진짜 필요한 3가지:
① 저장소 밖 데이터를 Codex가 직접 읽어야 할 때 (문서, 이슈 트래커)
② Codex 작업 결과를 외부 시스템에 써야 할 때 (GitHub PR 생성)
③ 브라우저·로그 같은 런타임 상태를 확인해야 할 때. 이 3가지 중 하나가 아니면 MCP 없이 프롬프트로 충분하다.
실전에서는 "라이브러리 문서를 확인하고 그 기준으로 코드를 고쳐라" 같은 요청이 대표적이다.
이때 context7 같은 문서 MCP 서버를 붙이면 Codex가 기억에만 기대지 않고 외부 문서를 직접 읽는다.
MCP를 한 줄 비유로 다시 말하면
노트북 충전기·외장 모니터·외장 SSD가 다 다른 단자를 쓰던 시절을 USB-C가 정리한 것과 같다. 도구마다 다른 통신 방식을 만들지 말고, AI 에이전트와 외부 도구가 공통 규약 하나만 알고 있으면 된다는 발상이 MCP다. Codex가 GitHub에 붙든, Notion에 붙든, 사내 DB에 붙든 같은 문법으로 도구를 호출한다.
잠깐 — 어려운 문법 외우기 전에 이것부터
MCP를 설치하지 않아도 Codex는 이미 CLI를 직접 호출할 수 있다.
초보자라면 이 세 가지만 알고 시작해도 충분하다.
codex "React 최신 useEffect 규칙대로 수정해" — context7 MCP를 등록하면 Codex가 공식 문서를 직접 참조하며 수정한다
aws s3 ls · gh pr view 123 — MCP 없이도 Codex가 CLI를 직접 호출한다. "aws mcp 안 깔아도 클로드 코드가 알아서 aws cli로 처리한다"는 실무 사례가 있다 (GeekNews @jamsya, 2026-03)
등록 후에는 터미널 UI에서 /mcp 명령을 사용하거나, 셸에서 codex mcp --help로 관련 명령을 확인할 수 있다.
공식 문서가 확인해주는 범위는 여기까지이며, 서버별 헬스체크 절차는 각 MCP 서버 문서를 함께 봐야 한다.
따라 해보는 MCP 설정
세 패턴 — STDIO 1종, HTTP 2종
STDIO는 로컬에서 프로세스를 직접 실행한다. HTTP는 외부 서비스 엔드포인트에 직접 연결한다. 두 방식 모두 TOML에 기록되며 공통 원칙은 같다.
인증 정보는 환경변수 이름만 — 토큰 값은 config에 절대 남기지 않는다
enabled_tools로 범위를 좁혀 시작 — 서버 전체보다 필요한 도구만 먼저 열고 확인해가며 추가한다
Goal·Completion을 주석으로 먼저 적는다 — 설정 의도가 파일에 남으면 다음 사람이 맥락을 이해한다
예시 A — 로컬 STDIO (문서 확인용, 인증 없음)
낯선 라이브러리를 쓸 때마다 공식 문서와 Codex를 번갈아 보는 흐름이 있다면, context7을 붙이면 그 왕복이 줄어든다.
# Goal: 라이브러리 문서를 Codex가 직접 참조하게 한다
# Setup: npx가 설치된 환경, 인터넷 연결
# Constraints: 읽기 전용. 코드 수정은 Codex 자체가 한다.
# Completion: codex mcp add 실행 후 "React 최신 useEffect 규칙 기준으로 수정해" 요청이 되면 완료
codex mcp add context7 -- npx -y @upstash/context7-mcp
- 추가 한 후 접속하면 새로 추가한 context7 mcp가 로드 되고 있는것을 볼 수 있다.
- 로드된 이후 /mcp 입력해보면 잘 설치되어 있음을 확인 가능하다.
- 사용방법 관련해서는 하기 섹션에서 다루지만, 미리 잠깐 살펴보자면, 다음과 같이 명시적으로 context7을 사용하라는 지시를 내려 사용해보았다.
- context7 을 사용하려는 시도와 결과
- 이후 질문들은 우리 글과 상관은 없지만, codex기본기를 다루는 상황에 이력을 공유 하려고 한다. 시간이 없으신분들은 빠르게 넘어가자.
줄별 해설
Goal: "외부 문서를 Codex가 읽는다"가 목적이다. 코드 수정을 자동화하는 게 아니다. 이 구분이 없으면 Codex 행동 범위에 대한 기대가 어긋난다.
npx -y: 매번 최신 버전을 내려받는다. 팀 환경에서는 버전 고정(@버전)을 추가하지 않으면 동일 서버 버전을 보장하기 어렵다.
Constraints 없음: context7은 읽기 전용이므로 Rules 파일에 별도 제한이 없어도 쓰기 사고가 없다. 쓰기 가능한 서버는 이 단계에서 명시해야 한다.
Completion: 실제 요청을 날려봐야 연결이 됐는지 안 됐는지 알 수 있다. "등록 완료" 메시지만으로 동작 확인이 된 건 아니다.
예시 B — Figma HTTP (디자인 조회, OAuth 토큰)
Figma 컴포넌트 목록·레이어 정보를 Codex가 직접 읽어오게 하려면 Figma MCP를 쓴다. Figma는 공식 HTTP 엔드포인트를 제공하므로 로컬에 서버를 설치하지 않아도 된다. STDIO가 로컬 프로세스를 띄우는 방식이라면, HTTP는 SaaS가 운영하는 서버에 직접 붙는 방식이다.
Codex가 아래 TOML 블록을 ~/.codex/config.toml에 자동으로 추가한다.
이후 안내에 따라 token등록은 별도로 진행 하자.
수동 설치 (TOML 직접 편집)
# Goal: Codex가 Figma 컴포넌트·레이어 정보를 직접 조회하게 한다
# Setup: Figma Personal Access Token → FIGMA_OAUTH_TOKEN 환경변수 설정
# Constraints: 읽기 전용. 파일 수정은 Figma 앱에서 직접 한다.
# Completion: "현재 파일의 컴포넌트 목록 보여줘" 요청이 성공하면 완료
# ~/.codex/config.toml 에 추가
[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"
줄별 해설
url: Figma가 공식 제공하는 HTTP MCP 엔드포인트. SaaS가 직접 운영하므로 로컬에 서버를 설치·실행할 필요가 없다.
bearer_token_env_var: 토큰 값이 아닌 환경변수 이름만 기록한다. config.toml이 저장소에 올라가도 실제 토큰은 노출되지 않는다.
Constraints에 읽기 전용 명시: Figma MCP는 쓰기 도구도 포함할 수 있다. 처음에는 읽기만 허용하고, 필요가 확인된 뒤 enabled_tools를 넓힌다.
CLI 보조 방법: codex mcp add figma --url https://mcp.figma.com/mcp으로 URL만 먼저 등록한 뒤, TOML에서 bearer_token_env_var를 수동 추가하는 방법도 있다.
예시 C — HTTP 범용 패턴 (모든 HTTP MCP 서버에 적용)
Linear, Stripe, Notion 등 "MCP HTTP 지원"을 발표한 SaaS 서비스는 모두 이 패턴으로 등록한다. 서비스마다 엔드포인트 URL과 인증 방식이 다르므로 각 서비스의 공식 MCP 문서를 먼저 확인하는 것이 첫 번째 단계다.
아래 URL과 토큰 형식은 템플릿 예시다. 실제 서비스 공식 MCP 문서에서 정확한 엔드포인트를 확인한 뒤 사용한다.
자연어 설치 (Codex 세션 안에서)
"Linear MCP를 설치해줘"
Codex가 해당 서비스의 MCP 문서를 참조해 TOML 블록을 자동으로 작성한다.
수동 설치 (TOML 범용 템플릿)
# Goal: <서비스>가 제공하는 데이터를 Codex가 직접 조회하게 한다
# Setup: <서비스> API 키 → <TOKEN_ENV_VAR> 환경변수 설정
# Constraints: 필요한 도구만 enabled_tools에 명시한다
# Completion: "<서비스> 데이터 조회" 요청이 성공하면 완료
# ~/.codex/config.toml 에 추가
[mcp_servers.<service-name>]
url = "https://<service-mcp-endpoint>/mcp"
bearer_token_env_var = "<SERVICE_API_TOKEN_ENV>"
enabled_tools = ["<read-tool-1>", "<read-tool-2>"]
필드 해설
url: 서비스가 공식 발표한 HTTP MCP 엔드포인트. 해당 서비스가 공개하지 않았다면 STDIO 방식을 사용한다.
bearer_token_env_var: HTTP MCP의 표준 Bearer 인증 방식. OAuth 방식인 서비스는 서비스 문서를 별도로 확인한다.
enabled_tools: 처음엔 읽기 도구만 열어 동작을 확인한 뒤 범위를 넓힌다. 도구 이름은 서비스 MCP 문서에서 확인한다.
적용 사례: 예시 B의 Figma가 이 패턴 그대로다. Linear, Stripe 등이 HTTP MCP를 공식 발표했거나 준비 중이다.
세 예시 공통 패턴
Goal/Constraints/Completion을 주석으로 먼저 적었다 — 설정 의도가 파일에 남으면 다음 사람이 왜 이렇게 설정했는지 이해한다
인증 정보는 환경변수 이름만 썼다 — 실제 값은 파일에 없다
enabled_tools로 먼저 좁혔다 — 서버가 제공하는 전부를 여는 게 아니라 필요한 것부터 시작한다
STDIO는 로컬 시작, HTTP는 외부 인증 — 두 유형의 구분이 설정 패턴에 드러난다
3. CLI ↔ TOML 매핑 빠른 참조
CLI로 등록한 서버는 자동으로 TOML에 기록된다.
두 방식은 같은 결과다.
팀 저장소에 커밋할 때는 TOML을 직접 관리하고, 빠른 테스트는 CLI를 쓴다.
( 사실 Codex에게 context7 MCP 설치 해줘 라고 하면 한번에 끝날 것 이다. 이를 이론적으로 살펴보고 가는 시간이라고 생각하고 빠르게 넘어가도 무방하다. )
세 서버 모두 초보자가 처음 시도해볼 수 있는 공식 예시가 있다. context7은 읽기 전용이라 가장 안전하게 시작할 수 있고, GitHub·Playwright는 토큰 및 실행 환경 확인 후 추가한다.
초보자는 MCP까지만 읽어도 충분하다. Skill·Plugin·CLI는 팀 합류자가 생기거나 반복 작업이 쌓일 때 다시 봐도 늦지 않다.
5. 도구 권한과 타임아웃 제어
MCP 서버를 붙이면 Codex가 사용할 수 있는 도구가 늘어난다. 그래서 등록보다 더 중요한 것이 권한 제어다.
MCP 공식 문서는 공통 옵션으로 startup_timeout_sec, tool_timeout_sec, enabled, required, enabled_tools, disabled_tools를 제시한다. 처음 보는 이름이 많지만, 결국 서버를 켤지, 기다릴 시간을 얼마로 둘지, 어떤 도구만 열지를 정하는 값들이다.
startup_timeout_sec의 기본값은 10초, tool_timeout_sec의 기본값은 60초로 문서에 제시되어 있다. 느린 서버를 붙일 때는 타임아웃을 늘릴 수 있지만, 너무 크게 잡으면 Codex 작업이 멈춘 것처럼 보일 수 있다.
초심자용으로 풀면 startup_timeout_sec는 서버가 켜질 때까지 기다리는 시간이고, tool_timeout_sec는 MCP 도구 하나가 응답할 때까지 기다리는 시간이다.
위 enabled_tools 값은 필드 형태를 보여주는 템플릿이다.
실제로는 해당 MCP 서버가 노출하는 도구명을 확인해 넣어야 한다. 공식 문서 기준으로 enabled_tools는 허용 목록이고, disabled_tools는 차단 목록이다.
보수적으로 운영하려면 처음에는 필요한 도구만 enabled_tools로 열고, 실제 사용하면서 넓히는 방식이 낫다.
MCP 서버는 Codex의 행동 반경을 넓힌다. 특히 GitHub, 브라우저, 로그 시스템처럼 외부 상태를 바꿀 수 있는 도구는 처음부터 넓게 열지 말고 필요한 도구만 확인해가며 연다.
MCP 서버를 켜기 전 체크리스트
서버 출처와 설치 명령이 공식 문서나 신뢰 가능한 저장소에서 확인되는가?
서버가 노출하는 도구 목록을 보고 읽기 전용과 쓰기 가능 도구를 구분했는가?
토큰 값 자체가 아니라 환경변수 이름만 config에 남기는가?
응답이 느린 서버를 위해 timeout을 늘리더라도 Codex 전체 작업이 멈추지 않을 범위인가?
문제가 생겼을 때 enabled = false나 disabled_tools로 빠르게 좁힐 수 있는가?
5.5 MCP 운영 3원칙
MCP 서버를 처음 도입하는 팀이 같은 실수를 반복한다. 세 원칙은 그 실수를 예방하는 데서 나왔다.
쓰기 가능 도구는 읽기 가능 도구와 반드시 분리한다 — 같은 서버라도 읽기·쓰기 도구는 다른 환경에서 관리한다
MCP tool result를 사용자 입력과 같은 수준으로 다룬다 — 외부 서버가 반환하는 텍스트는 신뢰 경계 밖에서 온다. 그 안에 지시문이 있으면 Codex가 따른다.
장애 시 빠르게 좁힐 수 있는 구조를 미리 만든다 — enabled = false 또는 disabled_tools로 즉시 차단 가능한 상태를 유지한다
초보자 졸업 체크리스트
☐ context7 MCP 1개 등록해봤다
☐ Skill 1개 직접 작성해봤다 (SKILL.md frontmatter + 지시문)
☐ 토큰을 config에 직접 쓰지 않고 환경변수로 분리했다
☐ 자연어 한 줄 요청 — 원하는 결과가 나왔다
☐ Plugin은 팀 합류자가 생길 때 다시 봐도 늦지 않다
6. Skills — 이론과 실제 설치
MCP를 이해한 뒤에는 Plugin과 Skill의 경계를 잡아야 한다.
Plugins 공식 문서를 풀어 쓰면 Plugin은 GitHub에 올려두면 다른 팀도 설치해서 쓸 수 있는 MCP·Skill 묶음 패키지다. 이 묶음의 정보지가 manifest(plugin manifest — 이름·버전·포함된 MCP 서버 목록을 담은 설정 파일, 앱스토어 앱 정보지에 가깝다)다.
반면 Skills 공식 문서는 Skill을 SKILL.md 파일과 optional scripts, references를 가진 디렉터리로 설명한다.
즉 Skill은 작업 절차를 작성하는 형식이고, Plugin은 그것을 설치 가능한 형태로 배포하는 단위에 가깝다.
개념을 추상 비교표로 외우는 건 잘 안 남는다. 같은 작업을 세 방식으로 구현해보면 차이가 더 빨리 손에 잡힌다.
아래는 "GitHub 이슈 #42에 'bug' 라벨 붙이기"를 MCP·Skill·Plugin 세 방식으로 짠 예시다.
읽는 순서를 MCP → Skill → Plugin으로 잡아두면 차이가 더 잘 보인다. 가장 낮은 층(MCP)에서 시작해서, 그걸 흐름으로 묶고(Skill), 다시 묶음을 배포 가능한 패키지로 감싼다(Plugin).
방식 1 — MCP로 직접 도구 호출
# MCP tool call (코드 또는 Codex 세션에서 직접 호출)
result = codex.tools.call("github_add_label", {
"repo": "myorg/myrepo",
"issue": 42,
"label": "bug"
})
한 번 쓰고 끝낼 작업, 또는 다른 코드 안에서 호출해야 할 때 적합하다. 매번 같은 인자를 입력해야 하므로 반복하면 피곤해진다.
방식 2 — Skill로 작업 흐름 저장
---
name: label-bug
description: 지정된 이슈에 'bug' 라벨을 추가
---
GitHub 이슈 #{{issue_number}}에 'bug' 라벨을 추가해라.
팀에서 자주 반복하는 작업이라면 Skill로 저장한다. 다음에 @label-bug 42처럼 호출만 하면 된다. 내부에서는 결국 MCP 도구를 호출한다.
방식 3 — Plugin으로 묶어 배포
# Plugin manifest 안에 위 GitHub MCP 서버 + label-bug Skill 번들링
# 팀원 누구든 한 줄로 설치
codex plugin install github-tools
팀 전체가 같은 MCP·Skill 조합을 써야 할 때 Plugin으로 묶는다. 설치 한 줄로 MCP 서버 등록과 Skill 배치까지 끝난다.
셋의 관계는 사실 직렬이다. Skill은 안에서 MCP 도구를 호출하고, Plugin은 Skill·MCP를 한 묶음으로 배포한다. 하나만 골라야 하는 게 아니라, 작업 빈도와 공유 범위에 따라 층을 쌓는다.
6.1 Skill은 로컬·저장소 워크플로에 강하다
Skill의 최소 단위는 SKILL.md다. 공식 문서의 최소 포맷은 YAML frontmatter(마크다운 파일 상단에 ---로 감싼 메타데이터 블록 — 이름, 설명 같은 구조적 정보를 기술함)의 name, description과 실제 지시문으로 구성된다.
---
name: skill-name
description: Explain exactly when this skill should and should not trigger.
---
Skill instructions for Codex to follow.
예를 들어 PR description에 breaking changes 항목을 강제로 챙기게 하는 커스텀 Skill은 다음과 같이 쓴다. 추상 "코드 리뷰 스킬" 대신 실제로 검증할 수 있는 항목 한 개에 집중하는 게 핵심이다.
---
name: pr-review-breaking
description: PR description에 breaking changes 섹션 체크
---
이 PR의 description을 확인하고:
1. '## Breaking Changes' 섹션이 없으면 추가 요청
2. breaking change 항목이 있으면 각 항목의 마이그레이션 가이드 확인
3. 없으면 '없음'으로 명시 요청
완료 기준: PR description에 Breaking Changes 섹션 존재 여부 리포트
위 예시는 직접 작성하는 커스텀 Skill 구조를 보여 주는 것이다. openai/skills 공개 저장소에 등록된 Skill이 아니므로 $skill-installer로 설치할 수 없다.
문서에 따르면 Skill 디렉터리는 필수 SKILL.md 외에 선택적으로 scripts/, references/, assets/, agents/openai.yaml을 둘 수 있다.
반복되는 릴리스 노트 작성, 보안 점검, 디자인 QA 같은 작업도 같은 패턴으로 Skill로 만들 수 있다.
※ k-skill 31개(NomaDamas/k-skill)는 Claude Code / OpenClaw 타깃이므로 Codex 비대상. Claude Code의 Plugin · Skill 생태계는 필자의 Claude Code Plugin · Skill 가이드를 참고.
6.2 공개 Skill 설치 — 자연어와 수동 명령
OpenAI 공식 openai/skills 저장소에는 큐레이션된 Skill이 있다. 설치 명령은 $skill-installer를 사용한다. Codex 세션 안에서 자연어로 요청해도 된다.
자연어 설치 (Codex 세션 안에서)
"gh-fix-ci 스킬 설치해줘."
Codex가 $skill-installer 명령을 대신 실행해 Skill을 설치한다. 설치 후 Codex를 재시작해야 새 Skill이 인식된다.
ex) gh-fix-ci 스킬 설치해줘
- 중간에 네트워크 오류가 있었는데 의도를 파악하고 다른 방법으로 설치 시도 하는 과정도 공유
수동 설치 (CLI)
# openai/skills 큐레이션 목록에서 이름으로 설치
$skill-installer gh-fix-ci
# GitHub URL로 직접 지정 (서드파티 저장소 등)
$skill-installer install https://github.com/<owner>/<repo>/tree/main/<skill-path>
큐레이션 Skill: 이름만으로 설치 가능. openai/skills/skills/.curated/에 등록된 목록만 이름으로 찾는다. 목록에 없는 이름을 지정하면 설치에 실패한다.
외부 도구 1회만? → MCP | 같은 작업 반복? → Skill | 팀 전체 배포? → Plugin | gh · aws · kubectl 있음? → 그냥 CLI
MCP, Plugin, Skill은 서로 경쟁하는 개념이 아니다.
Codex 확장을 세 층으로 나누면 이해가 쉽다.
셋을 동시에 쓰는 경우 팀 개발 환경을 예로 들면 GitHub MCP + Jira MCP 두 도구를 묶어 Plugin으로 배포하고, PR 리뷰 절차를 Skill로 저장해두면 팀원 전체가 동일한 환경을 유지할 수 있다. MCP는 도구 연결, Plugin은 환경 복제, Skill은 작업 방식 표준화라는 세 문제를 각각 담당한다.
해야 할 일
먼저 볼 것
이유
외부 문서나 외부 도구를 붙인다
MCP server
Codex가 호출할 도구 접근 통로가 필요하다
반복 작업 절차를 저장한다
Skill
지침, 참고자료, 스크립트를 한 디렉터리에 묶을 수 있다
여러 팀원에게 확장 묶음을 배포한다
Plugin
Skills, apps, MCP servers를 설치 가능한 단위로 묶을 수 있다
도입 순서는 단순하게 잡는다. 먼저 context7처럼 읽기 전용 MCP 서버를 하나 붙인다. 그다음 팀에서 반복되는 작업을 Skill로 정리한다. 여러 사람이 같은 묶음을 써야 할 때만 Plugin 배포를 고려한다.
다음 편에서는 Codex를 실제 팀 운영에 붙일 때 생기는 문제를 다룰 예정이다. 설정 파일을 만들고, 도구를 붙이고, Skill을 늘리는 것보다 더 어려운 일은 "어떤 권한과 검증 기준으로 운영할 것인가"를 정하는 일이다.
다음 글 예고: Part 6 — Codex 자동화
반복 작업을 Codex로 자동화하는 실전 패턴
스케줄링, 훅, 이벤트 기반 트리거 설계
CI/CD 파이프라인과 Codex 통합 사례
자주 묻는 질문
MCP는 Codex에서 어떤 역할을 하나?
MCP는 Codex가 저장소 밖의 도구나 데이터 소스와 연결되는 통로다. 이슈 트래커, 문서, 브라우저, 내부 API 같은 외부 맥락을 작업에 포함할 때 필요하다.
Plugins와 Skills는 어떻게 구분하면 되나?
Plugin은 여러 기능이나 도구 묶음을 제공하는 확장 단위에 가깝고, Skill은 특정 작업 절차나 실행 패턴을 재사용하기 위한 지침 단위로 이해하면 쉽다.
MCP 서버를 추가할 때 가장 조심할 점은 무엇인가?
인증 정보, 네트워크 접근, 사용 가능한 도구 범위, 타임아웃을 확인해야 한다. 외부 도구 연결은 편리하지만 권한 경계가 넓어질 수 있기 때문이다.
