핵심 요약
Codex 사용자 5명 중 1명은 이미 개발자가 아닙니다.
OpenAI는 2026년 6월 2일 Codex에 직무별 플러그인, Sites, annotations를 추가한다고 발표했습니다. 공식 발표에 따르면 Codex는 주간 사용자 500만 명을 넘었고, 분석가·마케터·운영 담당자·디자이너·연구자·투자자·뱅커 같은 비개발자 사용자가 전체의 약 20%를 차지합니다. 더 눈에 띄는 숫자는 성장 속도입니다. OpenAI는 비개발자 사용자가 개발자보다 3배 이상 빠르게 늘고 있다고 설명했습니다. 출처: OpenAI 공식 발표.
이번 업데이트의 핵심은 “Codex가 코드를 더 잘 짠다”가 아닙니다. Codex가 회사의 업무 앱, 문서, 데이터, 보고서, 대시보드, 공유용 내부 사이트까지 다루는 생산성 도구로 확장된다는 점입니다. 특히 6개 직무별 플러그인은 62개 앱과 110개 skills를 묶고, Sites는 Business와 Enterprise 워크스페이스에서 인터랙티브 웹사이트와 앱을 만들어 URL로 공유하는 preview 기능으로 시작합니다.
이 글은 직장인·생산성 관심층을 위한 정리입니다. 개발자용 Codex 사용법보다 “마케터, 영업, 분석가, 운영팀이 무엇을 맡길 수 있고, 회사는 어떤 권한표를 먼저 만들어야 하는가”에 초점을 맞춥니다.
이미지 출처: OpenAI 공식 발표, “Codex for every role, tool, and workflow”. 첫 번째 본문 이미지이며 카드 썸네일로도 사용할 수 있는 공식 Sites 예시 화면이다.
무슨 일이 있었나
OpenAI가 공개한 변화는 크게 세 가지입니다.
첫째, Codex에 직무별 플러그인이 들어옵니다. 공식 발표는 data analytics, creative production, sales, product design, public equity investing, investment banking 등 6개 플러그인을 소개했습니다. 각 플러그인은 앱 연결, skills, instructions, workflow를 묶은 패키지입니다. 예를 들어 데이터 분석 플러그인은 Snowflake, Databricks Genie, Hex, Tableau 같은 도구를 활용해 지표 변화 이유를 찾고 보고서와 대시보드를 만들 수 있게 설계됐습니다. 세일즈 플러그인은 Salesforce, HubSpot, Slack, Outreach, Clay 같은 도구와 연결해 고객 미팅 준비, 후속 조치, CRM 업데이트, 리스크 딜 리뷰를 돕습니다.
둘째, Sites가 preview로 열립니다. OpenAI Developers 문서에 따르면 Sites는 Codex가 웹사이트, 웹 앱, 게임을 만들고 저장하고 배포하고 점검할 수 있게 하는 Codex 플러그인입니다. Business와 Enterprise 워크스페이스에서 시작하며, Enterprise는 관리자가 RBAC에서 Sites를 켜야 합니다. Business 워크스페이스는 기본 활성화로 안내돼 있습니다. 출처: OpenAI Developers Sites 문서.
셋째, annotations가 더 넓은 업무 산출물로 확장됩니다. Codex가 만든 사이트의 내비게이션 바를 선택해 폰트를 바꾸라고 하거나, 투자 메모의 특정 주장에 “출처가 어디냐”고 묻거나, 슬라이드의 차트 라벨을 더 명확하게 바꾸라고 지시하는 방식입니다. 초안을 통째로 다시 만들기보다, 사람이 판단한 부분만 찍어서 고치는 편집 흐름에 가깝습니다.
사람들이 실제로 겪는 문제
회사 업무에서 AI가 막히는 지점은 모델 성능만이 아닙니다. 오히려 더 흔한 문제는 “어디에 있는 정보를 가져와서, 어떤 형식으로, 누구에게 보여줄 것인가”입니다.
마케터는 캠페인 브리프, 브랜드 가이드, 이미지 자산, 예산표, 일정표, 리뷰 코멘트를 오갑니다. 영업팀은 CRM, Slack, 이메일, 콜 노트, 가격표, 고객별 이슈를 오갑니다. 분석가는 데이터 웨어하우스, BI 대시보드, 스프레드시트, 임원 보고 문서를 오갑니다. 기존 챗봇은 이 자료를 사용자가 복사해 넣을 때만 잘 작동했습니다. 반대로 Codex 플러그인은 업무 앱 연결을 전제로 합니다. 이 차이 때문에 “AI에게 물어보기”가 아니라 “AI에게 업무 흐름을 맡기기”에 가까워집니다.
예를 들어 분기 매출 보고서를 만든다고 해봅시다. 기존 방식은 데이터를 뽑고, 표를 만들고, 이유를 해석하고, 문서로 옮기고, 팀장 피드백을 반영하고, 다시 그래프를 고치는 순서였습니다. Codex의 새 방향은 이 흐름을 하나의 작업으로 묶으려 합니다. 데이터 분석 플러그인으로 지표 변화를 찾고, Sites로 시나리오 플래너를 만들고, annotations로 특정 차트나 문구를 고치고, 최종 사이트를 워크스페이스 안에서 공유하는 식입니다.
다만 이 편의는 권한 문제를 같이 키웁니다. AI가 Slack과 Google Drive와 CRM과 데이터베이스를 동시에 볼 수 있으면, 사람 한 명이 직접 찾기 어려운 연결도 빠르게 만들 수 있습니다. 좋은 방향으로는 생산성입니다. 나쁜 방향으로는 권한 과다, 민감정보 노출, 검수되지 않은 사이트 공유, 잘못된 데이터 해석이 됩니다. 그래서 이번 업데이트는 “비개발자도 AI로 앱을 만든다”보다 “비개발자 업무에도 개발팀 수준의 권한·검수 루프가 필요해진다”로 읽는 편이 정확합니다.
왜 중요한가
이번 발표에서 가장 중요한 단어는 “플러그인”보다 “직무별”입니다.
지금까지 많은 AI 도구는 범용 채팅창에 가까웠습니다. 사용자가 영업 담당자인지, 제품 디자이너인지, 투자 분석가인지, 운영 매니저인지에 따라 필요한 앱과 산출물이 달라도 같은 입력창에서 시작했습니다. OpenAI가 직무별 플러그인을 꺼낸 이유는 이 한계를 줄이기 위해서입니다. 같은 Codex라도 영업 플러그인은 고객 계정, 딜 리스크, 후속 메일, CRM 업데이트가 중심이고, 크리에이티브 플러그인은 Figma, Canva, Shutterstock, Picsart, Fal 같은 제작 도구와 캠페인 보드가 중심입니다.
이 변화는 회사 안에서 AI 도입 책임자가 봐야 할 기준도 바꿉니다. 예전 질문은 “직원에게 ChatGPT 계정을 줄 것인가”였습니다. 이제 질문은 더 구체적이어야 합니다.
어떤 직무가 어떤 앱을 연결해도 되는가. 어떤 플러그인은 누가 승인하는가. 어떤 데이터는 Sites로 배포하면 안 되는가. 생성된 보고서나 대시보드는 누가 검수하는가. 외부 앱 약관과 개인정보 처리 기준은 누가 확인하는가.
OpenAI Developers의 Plugins 문서도 이 지점을 분명히 합니다. 플러그인은 skills, 앱 연결, MCP 서버를 묶을 수 있지만, 기존 Codex 승인 설정은 계속 적용됩니다. 외부 서비스는 각자의 인증, 개인정보, 데이터 공유 정책을 따릅니다. 즉 Codex에 플러그인을 설치했다고 해서 보안 경계가 자동으로 정리되는 것은 아닙니다. 출처: OpenAI Developers Plugins 문서.
또 하나 중요한 점은 Sites가 단순한 문서 공유가 아니라는 사실입니다. Developers 문서는 모든 Sites deployment URL이 production deployment라고 설명합니다. 리뷰 전에는 deploy가 아니라 saved version으로 남겨야 합니다. 이 문장은 운영적으로 꽤 중요합니다. “AI가 만든 내부 페이지”라도 배포 URL이 열리면 실제 사용자가 접근하는 서비스가 됩니다. 사내 프로젝트 보드, 고객 리뷰 페이지, 재무 시나리오 플래너, 운영 대시보드는 모두 데이터와 권한과 책임 소재가 따라붙습니다.
어떻게 써야 하나
개인 사용자라면 먼저 기대치를 낮춰야 합니다. Codex Sites와 직무별 플러그인은 ChatGPT Business와 Enterprise 워크스페이스 중심으로 시작합니다. 무료 개인 계정에서 바로 모든 기능을 쓰는 생활형 기능이라기보다, 회사 워크스페이스에서 업무 도구를 묶는 기능에 가깝습니다.
회사에서 테스트한다면 “모든 팀에 열기”보다 한 직무, 한 업무, 한 데이터 범위부터 시작하는 편이 낫습니다. 예를 들어 영업팀 전체 CRM을 연결하기 전에, 특정 세그먼트의 고객 리뷰 준비 작업만 실험합니다. 데이터 분석 플러그인도 전체 데이터 웨어하우스보다 읽기 권한이 제한된 테스트 데이터셋부터 연결합니다. Sites도 외부 공개가 아니라 owner and admins 또는 workspace 내부 범위에서 먼저 검수합니다.
실제 프롬프트는 요구사항을 업무 산출물 기준으로 써야 합니다. “대시보드 만들어줘”보다 다음처럼 적는 편이 낫습니다.
@Sites 우리 운영팀용 프로젝트 요청 대시보드를 만들어줘.
팀원이 요청을 제출하고, 담당자와 상태를 볼 수 있어야 해.
필터는 상태, 담당자, 마감일 기준으로 필요해.
워크스페이스 계정으로 로그인한 사람만 접근하게 하고,
요청 데이터는 다음 방문 때도 남아 있어야 해.
배포 전에는 먼저 저장된 버전으로 검수하게 해줘.
이 프롬프트에는 대상 사용자, 핵심 기능, 접근 조건, 데이터 지속성, 배포 전 검수 조건이 들어 있습니다. OpenAI Developers Sites 문서도 새 웹사이트나 내부 도구를 요청할 때 audience, core experience, required data를 포함하라고 안내합니다.
업무 플러그인도 마찬가지입니다. “이번 달 매출 분석해줘”보다 “어떤 데이터 출처를 쓰고, 어떤 기간을 비교하고, 어떤 기준으로 원인을 나누고, 어떤 형식의 산출물을 만들 것인가”를 지정해야 합니다. AI가 업무를 대신할수록 입력은 더 짧아지는 것이 아니라, 책임 경계가 더 명확해져야 합니다.
팀 도입 체크리스트
| 점검 항목 | 먼저 정할 것 |
|---|---|
| 앱 연결 | Slack, Drive, CRM, BI, 데이터베이스 중 어떤 앱을 Codex 플러그인에 연결할지 |
| 권한 범위 | 읽기 전용, 쓰기 가능, 배포 가능 권한을 직무별로 나눌지 |
| 승인자 | 플러그인 설치, 외부 앱 인증, Sites 배포 승인자를 누구로 둘지 |
| 공유 범위 | Sites 접근을 owner/admins, workspace 전체, custom 그룹 중 어디까지 열지 |
| 검수 루프 | 생성된 보고서, 대시보드, 고객 자료의 사실 확인과 출처 확인을 누가 할지 |
| 민감정보 | 고객명, 가격표, 계약 조건, 인사 정보, 내부 재무 데이터를 어떤 규칙으로 제외할지 |
| 변경 이력 | annotations로 수정한 내용과 Sites saved version을 어떻게 기록할지 |
| 비상 대응 | 잘못 공유된 URL, 잘못된 데이터, 외부 앱 권한 오남용을 발견했을 때 누가 끌지 |
특히 Sites는 배포 전후 절차가 중요합니다. Developers 문서는 배포나 접근 범위 확대 전에 Codex review pane에서 source changes와 database migrations를 확인하고, 선택한 saved version이 맞는지 확인하고, 의도한 audience만 접근 가능한지 확인하고, runtime secret values를 source file에 commit하지 않았는지 확인하라고 안내합니다. 이것은 개발팀만의 체크리스트가 아닙니다. 비개발자 팀이 AI로 내부 도구를 만들수록 같은 검수 절차가 필요합니다.
이미지 출처: OpenAI Developers, Codex Sites 문서. Sites가 Codex 안에서 생성·저장·배포되는 hosted site 흐름임을 설명하기 위한 공식 이미지다.
이미지 출처: OpenAI Developers, Codex Permissions 문서. 플러그인과 Sites 도입 전 팀이 권한·승인·실행 범위를 점검해야 한다는 리스크 섹션의 맥락을 보강하는 공식 이미지다.
리스크와 한계
첫 번째 한계는 접근 조건입니다. Sites는 preview이고 Business와 Enterprise 워크스페이스 중심입니다. Enterprise에서는 관리자가 RBAC로 켜야 합니다. 따라서 개인 생산성 앱처럼 바로 켜서 쓰는 도구라고 보면 실망할 수 있습니다.
두 번째 리스크는 데이터 출처입니다. Codex가 여러 앱을 연결해 매끄러운 결과물을 만들수록, 결과가 어디서 왔는지 확인하기 어려워질 수 있습니다. 투자 분석, 영업 제안, 재무 시나리오, 고객 보고서처럼 숫자와 책임이 큰 문서는 “AI가 만든 사이트가 보기 좋다”로 끝내면 안 됩니다. 원본 데이터, 기준일, 계산식, 제외 조건, 수정 이력을 같이 남겨야 합니다.
세 번째 리스크는 권한 과다입니다. 플러그인을 설치하는 순간 bundled skills는 바로 사용할 수 있고, 앱 연결이 포함되면 ChatGPT 쪽에서 인증을 요구할 수 있습니다. OpenAI 문서는 Codex가 외부 앱을 통해 데이터를 보낼 때 해당 앱의 약관과 개인정보 정책이 적용된다고 설명합니다. 회사 입장에서는 OpenAI의 보안만 볼 것이 아니라 연결되는 각 앱의 데이터 처리 조건까지 봐야 합니다.
네 번째 리스크는 “공유 가능한 내부 앱”이라는 표현이 주는 착각입니다. Sites는 문서 링크가 아니라 production deployment URL입니다. 공유 범위를 잘못 열면 내부 대시보드, 고객 계정 정보, 파일 업로드, 임시 분석 결과가 예상보다 넓게 보일 수 있습니다. 처음에는 owner and admins 또는 제한된 custom 그룹으로 시작하고, 검수 뒤 workspace 전체로 넓히는 절차가 필요합니다.
이 문제는 앞서 다룬 Codex Windows 원격 제어나 OpenAI 모델과 Codex의 AWS Bedrock GA와 같은 흐름과도 이어집니다. Codex는 점점 더 많은 업무 표면에 들어오고 있습니다. 그래서 핵심은 “얼마나 많은 일을 맡길 수 있나”가 아니라 “어디까지 맡기고, 어떤 증거를 보고 승인할 것인가”입니다.
관전 포인트
앞으로 볼 지점은 세 가지입니다.
첫째, 직무별 플러그인이 실제 회사의 권한 체계와 얼마나 잘 맞는지입니다. OpenAI는 Corporate Finance, Private Equity Investing, Marketing Strategy, Strategy Consulting, Legal 같은 추가 플러그인을 예고했습니다. 직무가 넓어질수록 다루는 데이터는 더 민감해집니다. 법무, 재무, 전략 컨설팅 플러그인은 단순 편의 기능이 아니라 회사 내부 데이터 거버넌스와 직접 부딪힙니다.
둘째, Sites 파트너 생태계입니다. OpenAI는 Vercel, Wix, Base44, Replit, Lovable, Figma, Webflow, Emergent 같은 초기 파트너를 언급했습니다. 이것은 Codex가 만든 사이트가 OpenAI 내부 hosting에만 머무르지 않고, 기존 웹 제작·배포 도구와 연결될 가능성을 보여줍니다. 비개발자에게는 “프롬프트로 내부 도구를 만든다”는 경험이, 개발팀에게는 “누가 만든 앱을 누가 운영할 것인가”라는 새 숙제가 됩니다.
셋째, annotations와 검수 경험입니다. AI 산출물은 첫 초안보다 수정 과정에서 가치가 갈립니다. 사람이 특정 주장, 차트, 버튼, 문구를 찍어 수정하고 출처를 확인하는 흐름이 매끄러워지면, AI 업무 도구는 더 현실적인 팀 협업 도구가 됩니다. 반대로 수정 이력이 남지 않거나, 출처 확인이 약하거나, 배포와 공유가 너무 쉬우면 생산성보다 리스크가 커질 수 있습니다.
Codex의 다음 전장은 IDE가 아니라 회사 업무 화면입니다. 개발자만 쓰던 도구가 아니라, 마케터의 캠페인 보드, 영업팀의 고객 리뷰 페이지, 분석가의 시나리오 플래너, 운영팀의 프로젝트 대시보드로 들어가고 있습니다. 좋은 소식은 더 많은 사람이 AI로 실제 산출물을 만들 수 있다는 점입니다. 불편한 소식은 그만큼 회사의 권한표, 검수 루프, 공유 정책도 더 빨리 성숙해야 한다는 점입니다.
제목 후보
- 검색형: OpenAI Codex 업무 플러그인과 Sites 정리
- 후킹형: Codex는 더 이상 개발자만 쓰는 도구가 아니다
- 리스크/불안형: 회사 업무를 Codex 플러그인에 연결하기 전 확인할 권한 문제
- 생활 연결형: 마케터·영업·분석가가 Codex로 할 수 있는 일
- 반전형: Codex의 핵심은 코드 생성이 아니라 업무 앱 연결이다
출처와 더 읽을 거리
- OpenAI 공식 발표: Codex for every role, tool, and workflow: 2026년 6월 2일 발표 원문으로, 주간 500만 사용자, 비개발자 20%, 6개 직무별 플러그인, Sites, annotations의 공식 설명을 확인할 수 있다.
- OpenAI Developers: Codex Plugins: Codex 플러그인이 skills, 앱 연결, MCP 서버를 어떻게 묶고 설치·권한·데이터 공유가 어떻게 작동하는지 확인할 수 있는 공식 문서다.
- OpenAI Developers: Codex Sites: Sites의 preview 접근 조건, 저장과 배포 단계, 접근 제어, secrets 관리, 배포 전 검수 체크리스트를 확인할 수 있는 공식 문서다.
- OpenAI Developers: Codex Permissions: Codex에서 실행 권한과 승인 설정을 어떻게 제한하고 운영할 수 있는지 확인할 수 있는 공식 문서다.
- OpenAI Developers: Codex Governance: Enterprise 환경에서 Codex 권한, 감사, 정책 운영을 어떻게 잡아야 하는지 확인할 수 있는 공식 거버넌스 문서다.
- AI Insight Hub: Codex Windows 원격 제어: Codex가 개발 PC와 원격 감독 콘솔로 확장되는 흐름을 함께 이해할 수 있는 관련 글이다.
- AI Insight Hub: OpenAI 모델과 Codex의 AWS Bedrock GA: Codex를 기업 인프라, 권한, 비용, 감사 로그 관점에서 도입하는 맥락을 이어서 볼 수 있는 내부 관련 글이다.