ChatGPT Work의 Tool/Skill 내부 구조 모음
ChatGPT Work 세션에 노출된 Codex Tool과 Skill 인터페이스를 정리한 사이트
2026-08-31 기준
232개 Tool 인터페이스
44개 Skill
description, TypeScript declaration,
SKILL.md원문 확인 가능GitHub 관련 Tool만 89개
Repo/Issue/PR/Review/Workflow 작업이 상당히 세분화되어 있음
Gmail 21개, Google Calendar 15개 등 코딩 외 업무용 Tool도 대거 포함
spawn_agent로 Sub-agent를 띄우고 병렬 작업을 분배 가능Sub-agent가 다시 Agent를 생성하는 구조도 지원
Automations
Gmail/Slack/GitHub 이벤트를 Trigger로 Agent Workflow를 실행
Sites Skill
사이트 생성부터 검증, 배포까지 이어지는 Workflow가 정의되어 있음
Plugin Management
Agent가 직접 탐색하고 확장하는 구조 확인 가능
Zillow 같은 비개발 Tool도 포함되어 있어 Codex가 점점 Coding Agent보다 범용 Work Agent Runtime에 가까워지는 모습
어떤 Tool을 우선할지, 언제 사용자 확인을 받을지, 실패 시 어떻게 fallback할지 같은 운영 규칙 포함
Agent를 만들고 있다면 API 목록보다 Tool granularity, orchestration, permission boundary, fallback 설계를 참고하기 좋은 자료
단, 고정된 공개 API 명세는 아니며 세션 설정, 권한, 연결된 앱, 설치된 Plugin에 따라 Tool 목록은 달라질 수 있음
source https://codex-tool-reference.simonw.chatgpt.site/
HN에서는 도구와 스킬의 개수보다, 필요한 지침을 언제 불러오고 어디에 둘 것인지가 더 큰 관심을 끌었다. 브라우저 제어 스킬은 상세 사용법을 스킬 파일에 모두 넣지 않고, 실제 실행 단계에서 문서를 받아온다. 브라우저와 실행 환경에 맞는 안내를 제공하고, 사용하지 않을 지침이 대화 맥락을 차지하지 않게 하려는 설계로 볼 수 있다.
스킬이 많다고 작업이 곧바로 효율적이 되는 것은 아니다. 일부 사용자는 스킬을 읽고도 실제로 쓰지 않는 경우가 있으며, 도구 호출이 속도를 늦추고 토큰을 낭비하기도 한다고 지적했다. 반면 세부 지침을 필요할 때만 가져오면 문맥 사용량을 줄이고, Playwright가 바뀔 때 여러 문서를 따로 관리해야 하는 부담도 덜 수 있다. 결국 실사용 품질은 기능 수보다 호출 조건과 지침 관리 방식에 좌우된다.
ChatGPT Work와 Codex를 어떻게 구분해야 하는지도 주요 쟁점이었다. 데스크톱 앱에서는 로컬 파일을 다루는 방식이 Codex와 사실상 비슷하다는 설명이 나왔다. 웹과 모바일에서는 클라우드에서 실행되므로 사용 경험이 달라진다. 같은 기능처럼 보여도 실행 위치, 로컬 파일 접근 여부, 세션을 이어 쓸 수 있는지가 제품 선택의 기준이 된다.
