Codex Sites와 플러그인: 사내 도구가 URL로 배포될 때 개발팀이 봐야 할 것
AI 에이전트가 만든 산출물이 더 이상 “로컬에서 열어본 데모”에 머물지 않습니다. OpenAI가 2026년 6월 2일 발표한 Codex 업데이트는 role-specific plugins, Sites preview, annotations를 한 번에 묶었습니다. 개발자에게 중요한 부분은 새 기능의 화려함보다, Codex가 만든 앱과 대시보드가 워크스페이스 URL로 공유되는 순간부터 그것이 실제 배포 표면이 된다는 점입니다.
무슨 일이 있었나
OpenAI 발표에 따르면 Codex는 이제 팀의 도구와 업무 방식에 맞춘 플러그인, 선택한 부분만 고치는 annotations, 그리고 Business/Enterprise 워크스페이스에서 interactive hosted websites와 apps를 공유하는 Sites preview를 제공합니다. Codex changelog도 같은 날 Sites가 Codex app preview로 들어왔고, 웹사이트·대시보드·사내 도구·웹 앱·게임을 만들고 저장하고 배포하고 inspect할 수 있다고 설명합니다.
여기서 중요한 표현은 “create”보다 “deploy”입니다. Sites 문서는 배포 URL을 공유하기 전에 audience를 정하고, 처음에는 owner와 workspace admin에게만 제한한 뒤, content와 data handling, expected audience를 검토하라고 안내합니다. 런타임 환경값과 secrets는 source 파일이나 .openai/hosting.json에 넣지 말고 Sites panel에서 관리하라는 지침도 나옵니다.
왜 중요한가
지금까지 AI 코딩 도구의 위험은 주로 “틀린 코드가 들어온다”에 가까웠습니다. Sites가 붙으면 위험의 성격이 바뀝니다. 에이전트가 만든 대시보드가 실제 URL로 공유되고, 플러그인이 Salesforce, Snowflake, Figma, HubSpot 같은 업무 시스템의 맥락을 가져오며, annotations로 특정 UI나 문서 조각을 계속 수정한다면 개발팀은 생성 품질뿐 아니라 배포 권한, 데이터 경계, 변경 이력, 소유권을 봐야 합니다.
OpenAI Help Center의 plugin 문서도 이 지점을 분명히 합니다. plugin은 workflow guidance, skills, apps, app templates를 묶을 수 있지만, 그 자체가 새 데이터 접근 권한을 주지는 않습니다. 사용자는 ChatGPT/Codex 워크스페이스에서 app access가 있어야 하고, 동시에 원본 시스템에서도 적절한 권한을 가지고 있어야 합니다. 결국 “Codex가 접근했다”가 아니라 “어떤 사용자의 어떤 원본 시스템 권한으로 접근했는가”를 추적해야 합니다.
커뮤니티 신호
Reddit의 Codex Sites 논의에서는 두 반응이 동시에 보입니다. 한쪽은 “이제 localhost 데모가 아니라 바로 공유 가능한 웹 앱이 된다”는 기대를 보이고, 다른 쪽은 “서버와 네트워크를 모르는 사람이 앱을 만들어 호스팅하면 무엇이 잘못될 수 있는가”라는 우려를 제기합니다. 이 글에서는 커뮤니티 반응을 사실 출처로 쓰지 않습니다. 다만 실무자가 실제로 걱정하는 지점이 생산성보다 운영 책임이라는 신호로 봅니다.
개발팀에 생기는 변화
- 프로토타입과 운영 도구의 경계가 흐려집니다. URL이 생기는 순간 스크린샷이나 로컬 데모보다 훨씬 쉽게 조직 안으로 퍼집니다.
- 권한 검토가 코드 리뷰 밖으로 확장됩니다. 소스 diff뿐 아니라 workspace audience, plugin app access, source-system permission을 같이 봐야 합니다.
- secrets 관리가 제품 요구사항이 됩니다. API key나 DB URL은 generated source에 넣는 것이 아니라 hosted environment value로 관리해야 합니다.
- 비개발자 산출물이 개발 운영 이슈가 됩니다. 분석가나 마케터가 만든 dashboard도 데이터 노출, 유지보수, 폐기 기준이 필요합니다.
지금 할 일: 실무 체크리스트
- Sites 사용 범위를 “개인 초안”, “팀 내부”, “전사 공유”, “외부 공개 가능”으로 분류합니다.
- 첫 배포 기본값은 owner/admin 전용으로 두고, 리뷰 후 workspace 전체나 custom group으로 넓힙니다.
- plugin별로 읽기 전용, 쓰기 가능, action confirmation 필요 여부를 표로 관리합니다.
- generated source에 secret이 들어가지 않았는지, runtime secret은 Sites panel에만 들어갔는지 확인합니다.
- 대시보드가 원본 시스템 권한을 우회하지 않는지 테스트 사용자 계정으로 검증합니다.
- Codex가 만든 Site마다 소유자, 만료일, 데이터 출처, 마지막 검토일을 남깁니다.
위험과 반론
가장 큰 위험은 Sites를 “빠른 배포 버튼”으로만 보는 것입니다. 내부 도구는 작아 보여도 실제 고객 데이터, 재무 데이터, 운영 지표를 붙이는 순간 감사 대상이 됩니다. 특히 generated app이 임시 목적이었는데 계속 사용되는 경우, 소유자가 사라지고 의존성 업데이트와 접근 회수가 누락되기 쉽습니다.
반대로 모든 hosted agent output을 막는 것도 생산성을 놓치는 선택입니다. 작은 project board, launch hub, customer review dashboard, scenario planner는 기존 앱 개발 프로세스로 만들기에는 과하지만 문서보다 상호작용이 필요합니다. 그래서 핵심은 금지가 아니라 등급화입니다. 어떤 Site는 개인 초안으로 충분하고, 어떤 Site는 security review가 필요하며, 어떤 Site는 정식 제품 배포 프로세스로 넘어가야 합니다.
결론
Codex Sites와 plugins는 개발자를 대체한다는 단순한 이야기가 아닙니다. 오히려 개발팀의 책임 영역이 넓어졌다는 신호입니다. 앞으로 조직 안에는 “누가 만들었는지 애매하지만 모두가 쓰는 작은 앱”이 늘어날 가능성이 큽니다. 개발팀이 지금 정해야 할 것은 더 좋은 프롬프트가 아니라, URL로 배포되는 에이전트 산출물의 접근권한, 비밀값, 리뷰, 소유권, 폐기 기준입니다.