Codex에 대한 인상이 아직 초기 버전에 머물러 있다면 지금 다시 보면 꽤 다르게 느껴질 수 있습니다. 단순히 기능이 몇 개 더 붙은 정도가 아니라, 처음의 **“요청을 받아 클라우드에서 작업하는 코드 agent”**에서 점점 **“개발 workflow를 담는 환경”**으로 중심이 이동했습니다.

초기 정의 자체는 명확했습니다. OpenAI는 2025년 5월 16일 Introducing Codex에서 Codex를 cloud-based software engineering agent로 소개했습니다. 당시 사용감도 비슷했습니다. 작업을 주면 격리 환경에서 수행한 뒤 결과를 돌려주는, 실행 능력이 강한 코드 agent였습니다.

그 의미는 지금도 남아 있지만 더 이상 전체를 설명하기에는 부족합니다. 이후 업데이트를 보면 Codex의 관심이 “작업을 할 수 있는가”에서 **“사용자의 실제 workflow를 어떻게 받아들일 것인가”**로 움직이는 것이 보입니다.

2025년 9월 15일 Introducing upgrades to Codex에서는 terminal, IDE, GitHub 같은 진입점을 더 가깝게 묶기 시작했습니다. 2026년 2월 2일 Introducing the Codex app에서는 방향이 더 분명해졌습니다. app, parallel agents, worktrees, task inbox, skills, automations가 한꺼번에 들어오면서 Codex가 단일 대화창보다 command center에 가까워졌습니다.

이 변화는 단순한 제품 포장만은 아닙니다. 사용자 수가 커질수록 매번 prompt로 모든 규칙을 다시 설명하는 방식에는 한계가 생깁니다. reusable workflow, 공유 가능한 설정, 재사용 가능한 integration이 필요해집니다.

Skills보다 더 중요한 변화는 Skills를 패키징하고 배포할 수 있게 된 것

Codex를 몇 달 써 보면 Skills가 왜 필요한지 금방 알게 됩니다.

repository 규칙, 코드 스타일, 테스트 요구사항, release boundary, 위험 작업 확인 형식, 프로젝트 디렉터리 규칙처럼 반복되는 내용을 매번 prompt에 다시 적고 싶지는 않습니다. 긴 prompt로도 가능하지만 쉽게 빠지고, 세션마다 조금씩 달라집니다.

Skills는 이런 작업 방식을 저장해 두고 Codex가 필요할 때 발견해서 사용할 수 있게 하는 계층입니다. 개인 또는 특정 repository의 반복 가능한 작업 설명서에 가깝습니다.

하지만 이번 변화에서 더 큰 부분은 Plugins입니다.

Codex Plugins 공식 문서는 plugin을 reusable Codex workflows를 위한 installable bundle로 설명합니다. 단순한 작은 버튼 하나가 아니라 여러 구성 요소를 하나의 설치·공유 가능한 workflow package로 묶는 단위입니다.

Skills가 개인이나 repository 내부에서 계속 다듬는 도구에 가깝다면, Plugins는 같은 구성과 integration을 여러 프로젝트와 팀에 일관되게 배포하는 방법을 해결합니다.

공식 구조에서 plugin은 여러 계층을 함께 포함할 수 있습니다.

• Skills: Codex가 점진적으로 발견하는 workflow 지침
• Apps: 선택적인 app integration 또는 connector mapping
• MCP servers: workflow가 사용하는 원격 도구나 공유 context

그래서 저는 지금의 Codex를 “코드를 작성하는 chat tool”보다 “개발 환경의 진입점”에 가깝게 봅니다. 모델이 작업을 수행하는 것뿐 아니라 일하는 방식 자체를 저장하고 불러오기 시작했기 때문입니다.

Skills와 Plugins는 같은 것이 아니다

plugin을 처음 보면 “skill 이름만 바꾼 것 아닌가?”라고 생각하기 쉽지만 역할이 다릅니다.

더 단순하게 말하면:

• Skill: 로컬 capability / workflow instruction
• Plugin: 설치하고 공유할 수 있는 distribution unit

Skill은 다음 상황에 잘 맞습니다.

• 한 repository에서만 계속 다듬는 workflow
• 개인적이거나 프로젝트 특화 행동
• 아직 실험 중이라 다른 사람에게 배포할 필요가 없음

Plugin은 다음 상황에 더 맞습니다.

• 여러 프로젝트에서 같은 구성을 재사용
• Skills, MCP 설정, app integration을 하나의 설치 단위로 묶기
• 버전 관리하고 팀에 공유할 수 있는 package가 필요

공식 문서에서도 local skills는 단일 repository나 workflow, 실험적 행동에 적합하고 plugins는 여러 팀과 프로젝트에 같은 skills와 integrations를 공유하는 데 적합하다고 설명합니다.

이 구조에서는 skill이 plugin의 한 구성 요소가 될 수 있지만 외부에 배포하고 설치·활성화하는 단위는 plugin입니다.

plugin 구조가 이미 제품화 수준으로 들어갔다

OpenAI가 개념만 설명하고 끝낸 것이 아니라 manifest, 디렉터리 구조, 설치 위치, marketplace까지 함께 정리한 부분도 중요합니다.

최소 plugin의 entry point는 .codex-plugin/plugin.json입니다. root 아래에는 다음 구성 요소를 둘 수 있습니다.

• skills/
• .app.json
• .mcp.json
• assets/

즉 개인 메모 파일을 하나 두는 수준이 아니라 일반적인 software package처럼 구성됩니다. manifest, component reference, display metadata, screenshot, logo, default prompt 같은 정보가 함께 들어갑니다.

공식 문서에는 다음 필드도 구체적으로 설명돼 있습니다.

• 식별 정보: name, version, description
• component reference: skills, mcpServers, apps
• 표시 metadata: displayName, shortDescription, category, capabilities, brandColor, screenshots

path는 plugin root 기준 상대 경로이며 ./로 시작하고, visual asset은 ./assets/ 아래에 두는 식의 규칙도 명시돼 있습니다.

실용적인 부분은 내장 @plugin-creator skill을 이용해 local plugin scaffold를 만들 수 있다는 점입니다. “언젠가 만들 기능”이 아니라 이미 직접 workflow package를 만들어 볼 수 있는 단계입니다.

Marketplace가 있어야 팀 workflow로 넘어갈 수 있다

AI 도구에서 흔한 문제는 “커스터마이즈는 가능한데 공유가 어렵다”는 것입니다. 결국 prompt나 규칙 파일을 만든 사람만 정확히 알고, 다른 사람은 복사해서 조금씩 다른 버전을 쓰게 됩니다.

Codex가 marketplace 계층을 넣은 이유도 여기에 있습니다. 공식 문서 기준으로 다음 종류의 marketplace를 읽을 수 있습니다.

• 공식 directory
• repository-level marketplace: $REPO_ROOT/.agents/plugins/marketplace.json
• 개인 marketplace: ~/.agents/plugins/marketplace.json

repository 안에 팀용 marketplace를 두고 공통 plugin 목록을 제공할 수도 있고, 개인 marketplace에 자주 쓰는 workflow package를 모아둘 수도 있습니다.

설치된 plugin은 다음과 같은 cache 경로를 사용합니다.

~/.codex/plugins/cache/$MARKETPLACE_NAME/$PLUGIN_NAME/$VERSION/

local plugin의 version은 local이며 enable/disable 상태는 ~/.codex/config.toml에서 관리됩니다.

설치 위치, cache, local copy, enable 상태 같은 운영 세부가 정해졌다는 사실 자체가 중요합니다. plugin이 단순한 데모 개념이 아니라 팀 workflow의 infrastructure로 들어가기 위한 기반이 만들어지고 있다는 뜻입니다.

공식 Plugin Directory의 self-service publishing은 문서상 계속 확장되는 단계이므로, 현재는 local / repository marketplace를 중심으로 이해하는 편이 좋습니다.

개발자에게 왜 중요한가

저는 이런 변화가 “모델 점수가 조금 더 올라갔다”는 뉴스보다 더 중요하다고 봅니다.

초기 Codex는 매우 강한 일회성 외부 인력에 가까웠습니다. 작업을 하나 주면 잘 처리하지만 다음 세션에는 repository 규칙, 경계, 스타일, toolchain을 다시 설명해야 하는 일이 많았습니다.

지금 Codex가 보완하는 것은 반복해서 설명하던 내용을 장기적인 workflow asset으로 바꾸는 방법입니다.

• Skills: 작업 방식을 저장
• Plugins: skills와 integration을 패키징하고 배포
• Automations: 이런 capability를 미래의 반복 작업이나 조건 기반 실행으로 연결

개발자에게 중요한 질문도 바뀝니다. “이 함수를 작성할 수 있나?”보다 **“우리 팀 방식대로 안정적으로 일을 수행하게 만들 수 있나?”**가 더 중요해집니다.

vibe coding 사용자에게도 마찬가지입니다. 매번 빈 대화창에서 긴 prompt를 다시 쌓지 않고, 잘 작동하는 workflow를 저장하고 설치하고 공유할 수 있습니다.

기존 AI 코딩 도구가 불편했던 이유는 모델이 약해서만이 아니었습니다. 주변 환경이 얇고, workflow가 파편화돼 있고, 재사용성이 낮은 문제가 컸습니다. 최근 Codex 변화는 바로 그 계층을 두껍게 만드는 방향입니다.

그래서 “새 Codex의 가장 큰 변화가 무엇인가”라고 묻는다면 저는 더 이상 “더 강한 코드 agent가 됐다”고 답하지 않습니다.

오히려 반대입니다. Codex는 “단지 agent인 단계”에서 벗어나 Skills, Plugins, Automations와 팀 설정을 담는 workflow platform 쪽으로 이동하고 있습니다.