Codex와 Claude 플러그인 생태계

Codex와 Claude 플러그인 생태계

Jira·Confluence·Figma부터 GitHub·Worktree·공유드라이브까지 개발 업무는 어디까지 연결될까

처음 Codex나 Claude Code를 사용할 때는 역할이 단순했습니다.

Repository
    ↓
AI Agent
    ↓
코드 수정
    ↓
Build / Test

하지만 2026년의 AI 개발환경은 여기서 상당히 멀리 왔습니다.

이제 Agent가 연결되는 범위는:

Jira
Confluence
Figma
GitHub
Slack
Teams
Google Drive
SharePoint
OneDrive
Notion
Linear
Database
사내 MCP

까지 넓어졌습니다.

여기에:

Plugin
Connector
Skill
MCP
Subagent
Worktree
Hook
Cloud Agent

가 결합합니다.

그래서 이제 단순히:

Codex가 코드를 더 잘 짜나, Claude가 더 잘 짜나?

만 비교해서는 부족합니다.

개발자가 실제로 봐야 할 것은:

어떤 Agent가 요구사항부터 디자인, 코드, QA, 문서까지 우리 개발 Workflow 전체를 얼마나 자연스럽게 연결하는가

입니다.

---

1. Plugin, Connector, Skill, MCP부터 구분하자

이름이 많지만 개발자 관점에서는 네 가지 정도로 나누면 이해하기 쉽습니다.

Plugin

여러 기능을 하나의 업무 Workflow로 묶은 Package입니다.

예를 들어:

Atlassian Plugin

├─ Jira 연결
├─ Confluence 연결
├─ 관련 Skill
└─ 업무 Workflow

처럼 구성할 수 있습니다.

현재 OpenAI Plugin은 Skill, Connected App, App Template 등을 하나의 재사용 가능한 Workflow 단위로 묶을 수 있고 Codex의 지원되는 Task View에서도 직접 사용할 수 있습니다.

Claude Plugin 역시 MCP, Skill, Tool 등을 한 번에 설치하는 형태로 확장되고 있습니다.

---

2. Connector와 App은 외부 서비스를 연결한다

Connector는:

GitHub

Jira

Confluence

Figma

Google Drive

Slack

SharePoint

같은 외부 서비스에 Agent가 접근할 수 있도록 연결합니다.

중요한 것은 기존 서비스 권한을 그대로 사용한다는 것입니다.

내가 접근 가능한 Jira Issue
→ Agent도 접근 가능

권한 없는 Confluence Space
→ Agent도 접근 불가

입니다.

Plugin을 설치했다고 회사 시스템의 권한이 자동으로 확장되는 것은 아닙니다.

---

3. Skill은 ‘어떻게 일할지’를 알려준다

Tool이 무엇을 할 수 있는지 알려준다면 Skill은:

이 작업을 어떤 순서로 처리할 것인가?

를 정의합니다.

예를 들어:

iOS Release Skill

1. Build
2. Unit Test
3. Simulator Smoke Test
4. Version 확인
5. Release Note 작성
6. Jira Release Issue 업데이트
7. Confluence 변경사항 정리

같은 방식입니다.

Agent가 바뀌더라도 팀의 작업 절차는 Skill로 유지할 수 있습니다.

---

4. MCP는 AI와 Tool을 연결하는 공통 규격이다

MCP는 Plugin이 아니라 Protocol입니다.

예를 들면:

Codex
 ↓
Figma MCP
 ↓
Figma

또는:

Claude
 ↓
Atlassian Rovo MCP
 ↓
Jira / Confluence

또는 iOS 개발에서:

Codex
 ↓
XcodeBuildMCP
 ↓
Xcode / Simulator

처럼 사용합니다.

정리하면:

Plugin
→ 업무 Package

Connector / App
→ 외부 서비스 연결

Skill
→ 반복 작업 방법

MCP
→ Tool 통신 규격

입니다.

---

이제 실제 개발업무에 넣어보자

5. 개발업무의 시작은 GitHub보다 Jira인 경우가 많다

회사 개발은 대부분 코드부터 시작하지 않습니다.

먼저:

신규 기능
Bug
고객 요청
운영 이슈
개선사항

이 생기고 Jira Task가 만들어집니다.

예를 들어:

MOB-210

iOS 결제 화면에서
중복 결제 가능성 수정

이라고 해보겠습니다.

기존에는 개발자가 직접:

Jira 확인

↓
Confluence 검색

↓
Slack 검색

↓
Figma 확인

↓
Repository 확인

↓
Agent에게 Context 전달

해야 했습니다.

이제 이 단계 자체를 Agent에 연결할 수 있습니다.

---

6. Codex에서도 Atlassian Rovo Plugin을 사용할 수 있다

OpenAI Plugin Directory에는 Atlassian이 만든 Atlassian Rovo Plugin이 있습니다.

이 Plugin은:

Jira

Confluence

Compass

Context를 가져오고 Action까지 연결할 수 있습니다.

예를 들어:

MOB-210의

Description
Acceptance Criteria
Subtask
Owner

를 정리해줘.

또는:

이번 Incident 관련
Confluence 문서를 찾아서

Root Cause와
Mitigation을 정리해줘.

같은 요청이 가능합니다.

OpenAI의 Plugin 구조는 ChatGPT뿐 아니라 지원되는 Codex Task View에서도 설치된 Plugin을 Source로 선택할 수 있습니다.

---

7. 대화를 Jira Task로 바로 만들 수도 있다

예를 들어 회의 중:

로그인 실패가 5회 이상이면
계정을 30분 동안 잠그자.

관리자가 수동으로
해제할 수도 있어야 한다.

라는 결정이 나왔다고 해보겠습니다.

Agent에게:

이 내용을 Jira Task로 정리해.

Title
Description
Acceptance Criteria
Subtasks
Owner 후보

까지 만들어줘.

라고 요청할 수 있습니다.

즉:

회의 / 아이디어

      ↓

AI 정리

      ↓

Jira Work Item

로 바로 이어집니다.

---

Confluence는 ‘왜’를 담당한다

8. Jira와 Confluence의 역할은 다르다

개발자가 둘을 이렇게 생각하면 편합니다.

Jira

무엇을 할 것인가

누가 할 것인가

언제 할 것인가

현재 상태는 무엇인가

Confluence

왜 이렇게 설계했는가

Architecture

Decision

Requirement

Meeting Note

Runbook

Migration Guide

입니다.

즉:

Jira
→ What

Confluence
→ Why

라고 볼 수 있습니다.

---

9. Jira만 보는 Agent와 Confluence까지 보는 Agent는 결과가 다르다

Jira에:

Payment API v3 적용

이라고만 적혀 있다고 해보겠습니다.

반면 Confluence에는:

Payment Architecture v3

- 인증 방식 변경
- Retry 정책
- Error Code
- Migration 순서
- 기존 API 종료 일정

가 있습니다.

Jira만 보면 Agent가:

Task
→ 바로 코딩

할 수 있습니다.

하지만 Confluence까지 확인하면:

Task
+
Architecture
+
Decision History

      ↓

Impact Analysis

      ↓

Implementation Plan

부터 만들 수 있습니다.

AI Agent 시대에는 이 Context 차이가 생각보다 큽니다.

---

이제 Figma가 들어온다

10. Jira가 ‘무엇’, Confluence가 ‘왜’라면 Figma는 ‘어떻게 보여야 하는가’다

UI 개발에서는 요구사항과 설계 문서만으로 부족합니다.

실제 구현해야 하는 모습은 Figma에 있습니다.

Jira
→ 무엇을 만들지

Confluence
→ 왜 그렇게 설계했는지

Figma
→ 실제 UI가 어떻게 보여야 하는지

GitHub
→ 실제로 무엇을 만들었는지

입니다.

이 네 가지가 연결되면 Agent가 보는 Context가 훨씬 완성됩니다.

---

11. Codex와 Figma는 양방향 연결이 꽤 강하다

2026년 OpenAI와 Figma는 Codex–Figma 직접 연동을 발표했습니다.

Figma MCP Server를 Codex와 연결하면:

Figma Design
     ↓
Codex
     ↓
Implementation

뿐 아니라:

현재 Code
   ↓
Codex
   ↓
Figma / FigJam

방향도 사용할 수 있습니다.

즉 단순한 Design-to-Code가 아닙니다.

Code
↔
Design Canvas

사이를 오가는 Workflow를 목표로 합니다.

OpenAI와 Figma의 공식 연동은 Figma Make, FigJam까지 연결합니다.

---

12. Codex에서 Figma Plugin 자체도 활용할 수 있다

Figma Plugin은 단순 디자인 파일 읽기보다 범위가 넓습니다.

예를 들어:

Wireframe

Storyboard

Flow Diagram

Gantt Chart

Slide Deck

Design Asset

을 생성할 수 있습니다.

예를 들어 PRD가 있다면:

Google Drive
    ↓
PRD
    ↓
Codex + Figma
    ↓
User Flow
    ↓
Figma Wireframe

처럼 연결할 수 있습니다.

또 기존 서비스 Flow를 코드에서 분석한 다음 FigJam Diagram으로 만들 수도 있습니다.

---

13. Claude Code에도 Figma Plugin이 있다

Claude도 Figma가 약한 것은 아닙니다.

Figma가 직접 만든 Claude Code Plugin이 있습니다.

이 Plugin은:

Figma Frame

↓
Layout

Typography

Color

Design Token

Component

↓
Claude Code

↓
Production Code

흐름에 상당히 잘 맞습니다.

특히:

/implement-design

/create-design-system-rules

/code-connect-components

같은 Skill이 제공됩니다.

Figma Component와 실제 Code Component를 매핑하고 Design Token을 읽어 기존 Design System에 맞춰 구현하는 Workflow가 꽤 구체적입니다.

---

14. Figma만 놓고 보면 둘의 성격이 조금 다르다

Codex

Code
↔
Figma

Design 생성
Diagram 생성
Slide 생성
FigJam
Implementation

까지 넓게 연결되는 느낌이 강합니다.

Claude Code

Figma
 ↓
Design Context
 ↓
Existing Codebase
 ↓
Implementation

즉 정확한 Design-to-Code와 Design System 준수에 강점이 있습니다.

그래서 단순히:

누가 Figma를 지원하나?

가 아니라,

어떤 방향으로 Figma를 쓰고 싶은가?

를 봐야 합니다.

---

여기서 Worktree가 등장한다

15. Git Worktree는 Plugin이 아니다

GitHub Plugin과 Worktree는 완전히 다른 개념입니다.

GitHub
→ 원격 Repository / Issue / PR

Worktree
→ 로컬 작업공간 분리

입니다.

예를 들어:

Repository

├─ Worktree A
│   → MOB-210

├─ Worktree B
│   → MOB-211

└─ Worktree C
    → MOB-212

처럼 만들 수 있습니다.

Multi-Agent 개발에서 상당히 중요한 기능입니다.

---

16. Codex는 Local / Worktree / Cloud를 하나의 실행 선택지로 제공한다

Codex에서는 작업을:

Local

Worktree

Cloud

형태로 나눌 수 있습니다.

예를 들어:

Codex A
→ Login Refactoring

Codex B
→ Swift 6 Migration

Codex C
→ Unit Test

를 각각 다른 Worktree에서 돌릴 수 있습니다.

Main Working Directory를 직접 건드리지 않고 작업을 분리할 수 있다는 것이 장점입니다.

Codex에서는 이 Worktree Workflow가 Desktop 개발 경험 안에 상당히 자연스럽게 들어와 있습니다.

---

17. Claude Code도 Worktree를 지원한다

Claude Code에서도:

claude --worktree

를 이용할 수 있고 Subagent를 Worktree에 격리하는 것도 가능합니다.

예를 들면:

Main Claude

├─ Agent A
│   → Worktree A

├─ Agent B
│   → Worktree B

└─ Agent C
    → Worktree C

입니다.

Claude는 특히 Subagent + Worktree 조합이 강점입니다.

---

GitHub까지 연결하면 코드 Workflow가 완성된다

18. GitHub Plugin은 Issue부터 PR·CI까지 이어진다

GitHub 연결을 하면 Agent가:

Repository

Issue

PR

Review Comment

CI Check

Context를 가져올 수 있습니다.

예를 들어:

현재 PR의 Review Comment를 처리해.

실패한 CI Check 원인을 조사하고

필요한 수정을 한 뒤
관련 Test를 다시 실행해.

같은 Workflow를 만들 수 있습니다.

전체는:

Jira
 ↓
Requirement

Confluence
 ↓
Architecture

Figma
 ↓
UI

Codex / Claude
 ↓
Worktree

GitHub
 ↓
PR / CI

가 됩니다.

---

Slack과 Teams도 빼기 어렵다

19. 실제 최신 정보가 Slack에만 있는 경우가 많다

Jira와 Confluence가 항상 최신 상태인 것은 아닙니다.

실제 회사에서는:

"Backend API Response가
오늘 오전에 다시 바뀌었습니다."

같은 중요한 정보가 Slack Thread에만 있을 수 있습니다.

그래서 Agent에게:

MOB-210 Jira와
관련 Confluence 문서를 확인하고

최근 Slack 논의에서
변경된 요구사항이 있는지도 찾아줘.

라고 요청할 수 있습니다.

---

20. Microsoft 환경이라면 Teams + SharePoint다

회사에서 Microsoft 365를 사용한다면:

Slack
→ Teams

Google Drive
→ SharePoint / OneDrive

로 바뀝니다.

OpenAI Plugin 생태계에서도:

Outlook

Teams

SharePoint

OneDrive

를 연결할 수 있습니다.

Claude 역시 Microsoft 365 Connector를 통해 SharePoint, OneDrive, Outlook, Teams를 연결합니다.

---

공유드라이브도 개발 Context다

21. 개발 문서는 Repository 밖에도 많다

실제 프로젝트에서 이런 자료는 Drive에 있는 경우가 많습니다.

API Specification.pdf

Architecture.pptx

QA Checklist.xlsx

Security Policy.pdf

Release Plan.xlsx

Agent에게:

Google Drive의
Payment API v3 문서를 찾아.

현재 Repository 구현과 비교해서
Spec과 다른 부분을 정리해.

라고 할 수 있습니다.

이제:

Code
+
Document

를 동시에 보는 것이 가능합니다.

---

22. Google Drive는 Docs·Sheets·Slides까지 개발 업무에 들어온다

예를 들면:

Docs
→ Requirement / Architecture

Sheets
→ QA Matrix / 일정

Slides
→ Architecture / 발표자료

입니다.

그래서:

Drive
 ↓
Agent
 ↓
Repository
 ↓
Migration Plan

형태로 사용할 수 있습니다.

Claude 역시 Google Drive Connector를 제공하고 있습니다.

---

Confluence는 개발 완료 후 다시 등장한다

23. 코드를 바꿨다면 문서도 같이 바뀌어야 한다

개발팀에서 흔한 문제는:

Code
→ 최신

Confluence
→ 6개월 전

입니다.

Agent에게:

이번 PR에서 Architecture가 변경된 부분을 찾아.

기존 Confluence 문서와 비교해서
수정해야 할 Section을 정리해.

라고 할 수 있습니다.

지원되는 Write Action을 사용한다면 실제 Page 업데이트까지 연결할 수도 있습니다.

Atlassian Rovo MCP는 Jira와 Confluence를 검색하는 것뿐 아니라 지원되는 범위에서 생성·수정까지 제공합니다.

---

24. Incident 대응에도 이 조합이 잘 맞는다

Production 장애가 생기면 Context는 보통 여러 곳에 흩어져 있습니다.

Jira
→ Incident

Slack
→ 대응 내용

GitHub
→ Commit

Logs
→ Error

Confluence
→ Postmortem

Agent가 이를 모아서:

Timeline

Root Cause

Mitigation

Action Items

을 만들 수 있습니다.

그리고 Action Item을 Jira Task로 다시 만들고 Postmortem은 Confluence에 남기는 Workflow도 가능합니다.

---

이제 전체 개발 Workflow를 연결해보자

25. 기능 하나를 개발한다고 하면

새 기능:

Jira

MOB-310
새 결제 인증 방식 적용

이 들어왔다고 해보겠습니다.

1단계 — 요구사항 확인

Jira
+
Confluence
+
Slack

을 Agent가 확인합니다.

---

2단계 — UI 확인

Figma

에서 새로운 화면과 Component를 확인합니다.

---

3단계 — 구현 계획

Agent가:

Repository

Jira

Confluence

Figma

Slack

을 함께 보고 Impact Analysis를 만듭니다.

---

4단계 — Worktree 생성

MOB-310
 ↓
Worktree

로 격리합니다.

---

5단계 — 구현

Codex / Claude Code
      ↓
Implementation

---

6단계 — Build / Test

Build

Unit Test

Integration Test

iOS라면:

XcodeBuildMCP
      ↓
Simulator QA

까지 연결할 수 있습니다.

---

7단계 — GitHub PR

Diff

Test Result

Risk

Screenshot

을 정리해서 PR을 준비합니다.

---

8단계 — CI / Review

실패한 CI가 있으면 다시 Agent가 원인을 분석합니다.

---

9단계 — Jira 업데이트

Status

PR Link

Implementation Summary

QA Result

를 업데이트합니다.

---

10단계 — Confluence 갱신

Architecture가 바뀌었다면 관련 문서를 업데이트합니다.

---

11단계 — 공유

Slack / Teams

Drive / SharePoint

에 Release Note나 변경 내용을 공유합니다.

전체를 한 번에 보면:

                   Jira
              무엇을 만들까
                     ↓
                Confluence
                왜 만들까
                     ↓
                  Figma
             어떻게 보여야 할까
                     ↓
        ┌────────────┼────────────┐
        ↓            ↓            ↓
      Slack        Drive        GitHub
     팀 논의        자료          코드
        └────────────┼────────────┘
                     ↓
              Codex / Claude
                     ↓
                 Worktree
                     ↓
                   Code
                     ↓
              Build / Test
                     ↓
             Simulator / QA
                     ↓
                 GitHub PR
                     ↓
                Jira 완료
                     ↓
             Confluence 갱신
                     ↓
           Slack / Drive 공유

이게 현재 AI Coding Plugin 생태계가 만들어가고 있는 개발 Workflow입니다.

---

Codex를 쓴다면 어떻게 구성할까

26. Codex 개발자 기본 구성

처음에는 이 정도면 충분합니다.

Atlassian Rovo
→ Jira / Confluence

Figma
→ UI / Diagram / Design

GitHub
→ Code / PR / CI

Slack 또는 Teams
→ 팀 Context

Google Drive 또는 SharePoint
→ 문서

그리고 Local에는:

AGENTS.md

Skills

Worktree

MCP

를 둡니다.

iOS라면:

XcodeBuildMCP

를 추가합니다.

이렇게 하면:

Requirement
Design
Code
Test
QA
Documentation

이 한 Agent Workspace에 거의 다 들어옵니다.

---

Claude를 쓴다면

27. Claude 개발자 구성도 상당히 강력하다

Claude는:

Atlassian MCP
→ Jira / Confluence

Figma Plugin
→ Design-to-Code

GitHub Plugin
→ Repository / PR

Slack Connector

Google Drive

Microsoft 365

등을 사용할 수 있습니다.

Local 개발에서는:

Claude Code

CLAUDE.md

Skills

Subagents

Worktree

Hooks

MCP

를 조합합니다.

Claude의 Plugin Directory도 현재 상당히 커졌고 GitHub, Figma, Playwright, Linear, Supabase, Vercel, Database Tool 같은 개발 Plugin이 빠르게 늘고 있습니다.

---

그러면 지금은 Codex와 Claude 중 어느 쪽이 더 강할까

28. Plugin 숫자만 보면 둘 다 이미 상당히 크다

단순히:

Plugin이 더 많은 쪽이 좋다.

라고 보기는 어렵습니다.

Claude도 현재 수백 개의 Connector를 제공하고 있고 Claude Code Plugin 생태계도 굉장히 빠르게 커지고 있습니다.

특히:

Subagent

Hooks

Worktree Isolation

Design-to-Code

Plugin 기반 개발 자동화

는 Claude Code의 강점입니다.

---

29. 그래도 전체 개발 Workflow를 묶는 관점에서는 Codex 쪽이 조금 더 강하게 느껴진다

현재 Codex가 특히 재미있는 이유는:

Local

Worktree

Cloud

Plugin

Connected App

Skill

Computer Use

Browser

GitHub

Figma

Atlassian

Drive

문서 제작

이 하나의 제품 환경 안으로 계속 들어오고 있기 때문입니다.

특히 Codex Desktop에서:

Repository
→ Worktree
→ Plugin
→ Tool
→ Cloud Context

를 하나의 Task 흐름으로 연결하는 방향이 상당히 명확합니다.

OpenAI Plugin도 ChatGPT에서만 쓰는 부가기능이 아니라 지원되는 Codex Task 자체에서 Source로 선택할 수 있습니다.

이 부분이 현재 큰 장점입니다.

---

30. Figma에서도 Codex의 범위가 조금 더 넓다

Claude Code의 Figma Plugin은 상당히 좋습니다.

특히:

Figma
→ Design Token
→ Component Mapping
→ Production Code

에서는 오히려 Claude가 굉장히 구체적입니다.

하지만 Codex–Figma 공식 연동은:

Figma
→ Code

뿐 아니라:

Code
→ Figma

까지 양방향 Workflow를 강조합니다.

그리고 별도 Figma Plugin에서:

Diagram

Slide

Asset

Storyboard

Wireframe

까지 생성할 수 있습니다.

개발 + 디자인 + 문서화 전체로 보면 Codex 쪽 범위가 더 넓게 느껴지는 이유입니다.

---

31. 업무 Context 연결도 Codex가 상당히 넓다

Codex 쪽 Plugin 생태계에서는:

Jira / Confluence

GitHub

Slack

Teams

Google Drive

SharePoint

OneDrive

Figma

Outlook

을 하나의 OpenAI Workspace에서 사용할 수 있습니다.

즉 개발 외에도:

문서 작성

PPT

Spreadsheet

메일

회사 Knowledge

까지 같은 제품 생태계 안으로 연결됩니다.

최근 ChatGPT Work와 Codex의 통합 방향까지 생각하면 개발자 업무와 일반 지식 업무 사이의 경계가 상당히 얇습니다.

---

반대로 Claude가 더 좋은 부분도 분명하다

32. Claude Code의 Subagent와 Hook 구조는 여전히 매력적이다

Claude에서는:

Main Agent
   ↓
Subagent
   ↓
Worktree

를 상당히 자연스럽게 만들 수 있습니다.

특히:

Architecture Agent

Research Agent

Review Agent

Implementation Agent

처럼 역할을 명시적으로 나누는 데 좋습니다.

Hook도:

Agent가 특정 명령을 실행하기 전

특정 파일 수정 후

작업 완료 시

같은 자동 제어를 넣는 데 유용합니다.

이쪽은 Claude Code의 특징이 강하게 남아 있습니다.

---

33. Claude의 Figma Design-to-Code는 여전히 상당히 좋다

특히 기존 Design System이 잘 만들어진 회사라면:

Figma Component

↓ Code Connect

실제 Component

↓ Design Token

Production Code

Workflow가 중요합니다.

Claude Figma Plugin은 이 부분이 상당히 구체적으로 설계되어 있습니다.

그래서:

Figma 디자인을 기존 Frontend Design System에 최대한 정확하게 구현한다.

가 핵심이라면 Claude Code가 여전히 좋은 선택입니다.

---

하지만 Claude가 상대적으로 아쉬운 부분도 있다

34. 기능이 여러 Surface에 조금 더 분산돼 있다

Claude는 기능이:

Claude

Claude Code

Cowork

Connector

Desktop Extension

Plugin

MCP

로 나뉩니다.

기능적으로는 강력하지만 처음 사용하는 개발자 입장에서는:

이 Plugin은 어디서 실행되지?

이 Connector는 Claude Code에서도 되나?

이건 Desktop Extension인가?

이 Subagent는 Cowork인가?

를 구분해야 하는 경우가 있습니다.

Codex도 제품 Surface가 여러 개 있지만 최근에는 Desktop의 Codex와 Work, Plugin 체계가 비교적 한 방향으로 통합되고 있습니다.

사용하면서 느끼는 구조적 단순함에서는 현재 Codex 쪽이 조금 유리한 편입니다.

---

35. 개발 외 업무까지 넘어가면 Codex 생태계가 더 자연스럽다

개발자가 실제 하는 일에는:

Architecture PPT

기술 보고서

Spreadsheet

Executive Summary

Release Mail

회의자료

도 포함됩니다.

OpenAI 쪽은:

Codex
+
ChatGPT Work
+
Plugin
+
Document
+
Presentation
+
Spreadsheet

를 같은 계정과 Workspace에서 연결합니다.

그래서:

코드 작성
↓
QA
↓
보고서
↓
PPT
↓
메일

까지 이어가기가 자연스럽습니다.

Claude도 문서와 파일 생성을 지원하지만 현재 전체 Workflow의 연결 범위와 시각·문서 제작까지 합치면 OpenAI 쪽이 조금 더 한 덩어리로 느껴집니다.

---

36. 한 번에 비교하면

영역	Codex / OpenAI	Claude / Claude Code
코드 작성	매우 강함	매우 강함
Repository 분석	매우 강함	매우 강함
Worktree	제품 Workflow에 깊게 통합	강함
Cloud Coding	강함	강함
Subagent	강함	특히 강함
Hooks	가능/Workflow 중심	강점
GitHub	강함	강함
Jira / Confluence	Atlassian Rovo Plugin + MCP	Atlassian MCP
Figma	Code↔Design + Plugin	Design→Code 강점
Slack / Teams	둘 다 연결	Slack + Microsoft 365
Google Drive	강함	강함
SharePoint / OneDrive	강함	강함
문서/PDF	Work 통합 강점	강함
Spreadsheet	Work 통합 강점	강함
PPT/Presentation	Work + Figma 등 강점	가능
이미지 생성	직접 연결 강점	상대적으로 외부 의존
Computer Use	Codex/Work 통합	Desktop/Cowork 계열
개발→업무 전체 연결	현재 특히 강점	강하지만 다소 분산

---

37. 현재 기준으로는 이렇게 정리할 수 있다

순수 Coding Agent 성능만 놓고:

Codex > Claude

라고 단순하게 말하기는 어렵습니다.

둘 다 충분히 강하고 작업 종류에 따라 결과가 달라집니다.

하지만 이번 글에서 본 것처럼:

Jira
+
Confluence
+
Figma
+
GitHub
+
Worktree
+
Slack / Teams
+
Drive / SharePoint
+
MCP
+
문서
+
PPT

까지 개발자의 전체 업무환경을 기준으로 보면 현재는 Codex/OpenAI 쪽이 한 단계 더 넓게 연결되어 있다는 느낌이 강합니다.

특히:

Code

Design

Business Context

Documents

Presentation

Computer Use

가 하나의 Workspace 안에서 연결되는 것이 큰 차이입니다.

---

마치며

예전에는 개발환경을 이렇게 생각했습니다.

IDE

Git

Terminal

CI

지금은 여기에:

Agent

Plugin

Connector

Skill

MCP

Worktree

Company Knowledge

가 추가되고 있습니다.

그리고 실제 업무를 놓고 보면:

Jira
→ 무엇을 해야 하는가

Confluence
→ 왜 그렇게 해야 하는가

Figma
→ 어떻게 보여야 하는가

Slack / Teams
→ 지금 무엇을 논의하고 있는가

Drive / SharePoint
→ 어떤 자료를 참고해야 하는가

GitHub
→ 실제로 무엇이 변경됐는가

Worktree
→ 어디에서 안전하게 수정할 것인가

가 연결됩니다.

이 모든 정보를 Agent가 이해하고 실제 작업까지 할 수 있게 되면서 AI Coding Tool의 경쟁 기준도 달라지고 있습니다.

Claude Code는 여전히:

Codebase 이해

Subagent

Hooks

독립 Agent Workflow

정확한 Design-to-Code

에서 상당히 강력합니다.

반면 현재 Codex는:

Local / Worktree / Cloud

Plugins

Figma 양방향 Workflow

Atlassian

GitHub

회사 문서

Computer Use

ChatGPT Work

까지 범위를 빠르게 넓히고 있습니다.

그래서 개발만 놓고 둘 중 하나를 고르는 문제라면 여전히 취향과 프로젝트에 따라 달라질 수 있지만, 개발부터 디자인·업무·문서·발표까지 하나의 AI Workspace로 묶는 관점에서는 현재 Codex 쪽이 조금 더 앞서 있다고 볼 만합니다.

Claude가 부족하다기보다 차이가 있습니다.

Claude는 여전히 강력한 Coding Agent를 여러 Tool과 조합하는 느낌이 강하고,

Codex는 점점 개발자의 전체 Workspace 자체를 AI가 운영하는 방향으로 가고 있습니다.

앞으로의 경쟁은 모델 하나의 코딩 점수보다:

어느 Agent가 회사의 실제 개발 Workflow 전체를 더 적은 Context Switching으로 연결해주는가

에서 더 크게 벌어질 가능성이 있습니다.

---

참고자료

• OpenAI — ChatGPT 및 Codex의 Plugins
  Codex와 ChatGPT에서 Plugin이 어떻게 구성되는지, Skill·Connected App·App Template이 어떤 역할을 하는지 확인할 수 있습니다. 지원되는 Codex Task View에서는 Sources → Use plugins를 통해 설치된 Plugin을 직접 사용할 수 있다는 점도 공식 문서에 명시되어 있습니다.
  OpenAI Plugin 공식 문서
• OpenAI — Atlassian Rovo Plugin
  Jira, Confluence, Compass의 정보를 ChatGPT/OpenAI 환경에서 검색하고, Jira Task 생성이나 Confluence 기반 Incident 정리처럼 실제 Action까지 연결하는 공식 Plugin입니다. Jira를 업무의 시작점으로, Confluence를 설계·결정 Context로 사용하는 개발 Workflow를 확인하기 좋습니다.
  Atlassian Rovo Plugin
• Atlassian — Rovo MCP Server
  Jira와 Confluence뿐 아니라 Jira Service Management, Bitbucket, Loom 등 Atlassian 제품을 MCP Client와 연결하는 공식 MCP Server입니다. 검색·요약뿐 아니라 Work Item이나 Confluence Page 생성·수정 같은 Action도 지원하며 OAuth 2.1과 기존 Atlassian 권한을 그대로 사용합니다.
  Atlassian Rovo MCP 공식 문서
• Atlassian — Rovo MCP v2
  2026년 9월 GA된 Rovo MCP v2의 최신 변경사항을 확인할 수 있습니다. Jira·Confluence Tool이 개선됐고 Bitbucket, Loom, Sprint, Attachment, Whiteboard 등 지원 범위가 확대됐습니다. Atlassian 연동을 새로 구성한다면 v2 기준으로 확인하는 것이 좋습니다.
  Rovo MCP 최신 변경사항
• OpenAI — Figma Plugin
  Figma와 FigJam을 이용해 Wireframe, Flow Diagram, Gantt Chart, Storyboard, Presentation 등을 생성하는 공식 Plugin입니다. 코드 구현뿐 아니라 PRD나 문서를 디자인 결과물과 연결하는 Workflow를 확인할 수 있습니다.
  OpenAI Figma Plugin
• OpenAI & Figma — Codex × Figma Integration
  Codex와 Figma의 공식 양방향 연동 발표입니다. Figma MCP Server를 이용해 Figma 디자인을 Codex에서 구현하는 Design → Code뿐 아니라 현재 코드에서 Figma Design이나 FigJam 쪽으로 이동하는 Code → Design Workflow도 지원하는 것이 핵심입니다.
  Codex × Figma 공식 발표
• Claude — Figma Plugin
  Claude Code에서 Figma Frame의 Layout·Typography·Color·Design Token을 읽고 실제 코드로 구현하는 공식 Plugin입니다. /implement-design, /create-design-system-rules, /code-connect-components 같은 Skill을 제공해 기존 Design System에 맞춘 구현에 특히 유용합니다.
  Claude Code Figma Plugin
• Claude — Atlassian Plugin
  Claude Code와 Cowork에서 Jira와 Confluence를 연결하는 공식 Atlassian Plugin입니다. Jira Issue 검색·생성, Confluence 문서 조회·작성, Sprint 관리, Spec을 Backlog로 변환하는 작업 등을 지원합니다.
  Claude Atlassian Plugin
• Claude — Atlassian Rovo Connector
  Claude, Claude Desktop, Claude Code 및 API에서 Jira와 Confluence를 읽고 쓰는 공식 Connector입니다. Jira Issue 생성, 프로젝트 상태 업데이트, Confluence Page 작성 등 실제 업무 Action을 지원합니다.
  Claude Atlassian Rovo Connector
• Claude — Connectors
  Claude에서 GitHub, Slack, Google Drive, Linear 같은 외부 서비스를 연결하는 기본 구조를 설명합니다. Connector가 각 사용자의 원래 서비스 권한을 그대로 따르며, Claude·Desktop·Claude Code 등 여러 Surface에서 사용할 수 있다는 점을 확인할 수 있습니다.
  Claude Connector 공식 안내
• Claude — Remote Connector와 Desktop Extension 비교
  GitHub·Slack·Notion 같은 Cloud SaaS는 Remote Connector, 로컬 파일·localhost DB·Desktop App처럼 컴퓨터 내부 접근이 필요한 기능은 Desktop Extension을 사용하는 기준을 설명합니다. Claude 개발환경을 구성할 때 Cloud Context와 Local Tool을 구분하는 데 유용합니다.
  Claude Connector 선택 가이드
• Atlassian — Claude Agent for Jira
  Jira Work Item을 Claude Managed Agent에게 직접 할당하고, Claude가 코드를 작성한 뒤 Branch를 Push하고 GitHub Pull Request까지 만드는 Beta Workflow입니다. Jira가 단순 Issue Tracker를 넘어 AI Coding Agent의 업무 할당 지점으로 확장되는 사례입니다.
  Claude Agent for Jira 공식 안내

참고해서 볼 포인트

이번 글에서 중요한 것은 Plugin 개수 자체가 아닙니다.

Jira
→ 무엇을 해야 하는가

Confluence
→ 왜 그렇게 해야 하는가

Figma
→ 어떻게 보여야 하는가

GitHub
→ 실제로 무엇이 바뀌었는가

Worktree
→ 어디에서 안전하게 수정할 것인가

Drive / SharePoint
→ 어떤 자료를 참고하고 공유할 것인가

이 Context들이 하나의 Agent Workflow로 연결된다는 점입니다.

현재 공식 자료를 기준으로 보면 Codex/OpenAI 쪽은 Atlassian Rovo, Figma, GitHub, Drive 등 업무·개발·디자인 도구를 하나의 Plugin 체계로 묶는 방향이 강하고, Claude 쪽은 Atlassian/Figma Plugin과 Connector, Subagent, Worktree, Desktop Extension을 조합해 개발 Workflow를 세밀하게 구성하는 방향이 강합니다.