ChatGPT Work와 Codex,
무엇을 선택해야 할까?
보고서·슬라이드부터 코드 수정·테스트까지
상황별 선택 기준을 공식 문서로 정리했습니다.
2026년 7월 15일 기준 · OpenAI 공식 문서 반영
안녕하세요, SCV입니다.
결론부터 딱 정하겠습니다. 결과물이 업무 자료인지, 검증된 코드 변경인지 보면 선택은 어렵지 않습니다.
결론부터: 업무별로 딱 정하면
시장조사 · 자료 분석 · 보고서 · 제안서 · 발표자료 · 스프레드시트 · 회의록 · 정기 리포트
버그 수정 · 기능 구현 · 리팩터링 · 테스트 · 빌드 오류 · 코드 리뷰 · PR 검토 · CI · 배포 준비
질문 · 개념 설명 · 짧은 요약 · 아이디어 정리 · 문장 다듬기
시장조사, 자료 분석, 보고서, 제안서, 발표자료, 스프레드시트, 회의록 정리, 정기 리포트, 업무용 사이트 초안은 ChatGPT Work를 선택하세요. 여러 자료를 읽고 사람이 검토할 수 있는 완성된 업무 산출물을 만드는 일이기 때문입니다.
버그 수정, 기능 구현, 리팩터링, 테스트 작성·실행, 빌드 오류 해결, 코드 리뷰, PR 검토, CI 점검, 배포 준비는 Codex를 선택하세요. 실제 코드베이스를 읽고 파일을 변경한 뒤 명령과 테스트로 결과를 검증해야 하기 때문입니다.
질문, 개념 설명, 짧은 요약, 아이디어 정리, 한두 문장 다듬기는 Chat을 선택하세요. 파일을 만들거나 프로젝트를 실제로 바꿀 필요가 없다면 가장 가볍고 빠른 선택입니다.
한 문장으로 정리하면 완성된 업무 자료가 필요하면 Work, 검증된 코드 변경이 필요하면 Codex, 답변만 필요하면 Chat입니다.
선택 기준을 이렇게 보는 이유
ChatGPT 데스크톱 앱의 모드 선택 메뉴를 열면 ‘ChatGPT Work — 작성하고, 배우고, 탐색하기’와 ‘Codex — 빌드, 디버깅, 배포’가 나란히 보입니다. 이름만 보면 Work는 일반 업무용이고 Codex는 개발자용이라고 이해하기 쉽습니다. 방향은 맞지만 실제 선택 기준은 조금 더 구체적입니다. 핵심은 질문의 주제가 아니라 내가 원하는 최종 결과입니다. 조사 자료를 모아 보고서, 발표자료, 스프레드시트처럼 검토 가능한 산출물을 받고 싶다면 Work가 자연스럽고, 코드베이스를 읽고 파일을 수정한 뒤 테스트까지 통과시키고 싶다면 Codex가 자연스럽습니다.
이 글은 2026년 7월 15일 기준 OpenAI 공식 문서를 바탕으로 두 모드의 공통점과 차이점, 상황별 선택법, 프롬프트 작성법을 정리합니다. 기능은 계정, 요금제, 앱 버전, 조직 정책에 따라 다르게 표시될 수 있습니다.
ChatGPT Work는 ‘무엇을 완성할 것인가’를 중심으로 움직입니다. 고객 인터뷰 20개를 분석한 보고서, 비교 기준이 들어간 구매 의사결정표, 회의 자료로 만든 발표자료, 매주 갱신되는 동향 브리핑처럼 사람이 검토하고 바로 활용할 결과가 목적입니다.
Codex는 ‘어느 작업공간에서 무엇을 바꾸고 어떻게 검증할 것인가’를 중심으로 움직입니다. 저장소 구조 파악, 버그 재현, 소스 수정, 테스트 실행, 코드 리뷰, 배포 전 점검처럼 코드베이스와 개발 도구가 결과의 일부인 작업에 맞습니다.
둘 사이에 절대적인 벽이 있는 것은 아닙니다. 공식 문서는 비개발 업무에 Codex를 사용해 왔다면 그대로 사용해도 되고 Work로 전환해도 된다고 설명합니다. Work는 동일한 핵심 역량을 일상 업무에 맞춘 경험으로 제공한다는 뜻입니다. 반대로 Work도 파일과 도구를 다룰 수 있지만, 저장소의 실제 변경과 테스트가 성공 조건이라면 Codex를 고르는 편이 작업의 맥락과 검증 흐름을 더 명확하게 전달합니다.
ChatGPT Work란?
ChatGPT Work는 단순히 긴 답변을 작성하는 모드가 아니라, 분명한 결과가 있는 업무를 ChatGPT에 위임하는 방식입니다. 파일, 플러그인, 승인된 도구를 이용해 정보를 수집하고 여러 단계를 수행한 뒤 사용자가 검토할 수 있는 결과물을 만듭니다. 진행 상황을 확인하고, 중간 질문에 답하고, 방향을 바꾸거나 중요한 동작을 승인하는 흐름도 포함합니다.
잘 맞는 결과물은 보고서, 브리프, 발표자료, 분석표, 스프레드시트, 프로젝트 계획, 반복 업데이트, 사이트 등입니다. 공통점은 결과의 형태와 품질 기준을 사람이 설명할 수 있다는 점입니다. 예를 들어 ‘시장조사 해줘’보다 ‘공식 자료와 첨부한 인터뷰 기록만 사용해 국내 협업 도구 5개를 가격·보안·도입 난이도로 비교하고, 경영진용 10장 발표자료와 근거표를 만들어줘’가 Work에 더 적합한 요청입니다.
Work의 강점은 자료가 흩어져 있을 때 더 분명해집니다. 로컬 문서, 업로드한 파일, 웹 검색, 연결된 서비스, 플러그인에서 필요한 내용을 모아 하나의 산출물로 정리할 수 있습니다. 문서·프레젠테이션·스프레드시트·PDF는 대화 옆 미리보기에서 검토하고 특정 부분을 지목해 수정 요청을 이어가는 흐름이 특히 편합니다.
또한 반복 업무에도 잘 맞습니다. 매주 업계 뉴스를 수집해 정해진 형식으로 요약하거나, 일정한 자료원을 확인해 상태 변화를 보고하는 일은 예약 작업과 결합할 수 있습니다. 다만 메일 전송, 게시, 외부 시스템 수정처럼 되돌리기 어려운 동작은 ‘초안을 만든 뒤 멈추기’, ‘보내기 전에 승인받기’처럼 승인 지점을 프롬프트에 명시하는 것이 안전합니다.
Codex란?
Codex는 소프트웨어 개발과 기술 작업을 위한 코딩 에이전트입니다. 단순히 코드 조각을 답변으로 보여주는 데 그치지 않고, 선택한 폴더나 저장소를 작업 맥락으로 읽고 실제 파일을 수정하며 명령과 테스트를 실행할 수 있습니다. 버그 수정, 기능 구현, 리팩터링, 테스트 추가, 풀 리퀘스트 검토, 빌드 오류 분석이 대표적인 작업입니다.
Codex의 요청에는 작업 위치와 성공 조건이 중요합니다. ‘로그인 버그를 고쳐줘’보다 ‘현재 저장소에서 비밀번호 재설정 뒤 세션이 만료되는 문제를 재현하고 원인을 수정해줘. 관련 회귀 테스트를 추가하고 기존 인증 테스트도 실행해줘. 데이터베이스 스키마는 바꾸지 마’가 좋은 요청입니다. 이렇게 말하면 Codex는 탐색, 수정, 실행, 검증, 결과 보고의 흐름을 잡기 쉽습니다.
작업공간과 권한도 핵심 차이입니다. Codex는 선택한 프로젝트 디렉터리를 기준으로 파일을 읽고 쓰며, 샌드박스와 승인 정책에 따라 명령 실행 범위와 네트워크 접근이 제한됩니다. 저장소 밖의 파일이나 외부 네트워크가 필요하면 승인이 요구될 수 있습니다. 따라서 처음부터 올바른 폴더를 열고 필요한 실행 방법, 테스트 명령, 금지 영역을 알려주는 것이 결과 품질에 직접 영향을 줍니다.
Codex는 결과를 ‘설명’만 하는 것이 아니라 변경된 파일, 코드 차이, 테스트 결과로 증명해야 하는 작업에 강합니다. 반면 CLI에는 문서나 슬라이드를 시각적으로 미리 보고 주석을 다는 인터페이스가 없으므로, 그런 산출물이 중심이라면 Work가 더 편합니다. 데스크톱 앱이나 IDE에서는 생성 파일을 열어볼 수 있지만 개발 흐름의 중심은 여전히 작업공간과 검증 명령입니다.
두 모드의 차이를 한눈에 보기
| 비교 기준 | ChatGPT Work | Codex |
|---|---|---|
| 핵심 목표 | 검토 가능한 업무 결과 완성 | 검증된 기술 변경 완성 |
| 주요 맥락 | 문서, 웹, 플러그인, 연결 서비스 | 저장소, 소스, 로그, 터미널 |
| 대표 결과 | 보고서, 슬라이드, 표, PDF, Sites | 코드 변경, 테스트, 리뷰, 빌드 결과 |
| 검토 기준 | 내용, 구조, 출처, 시각적 완성도 | diff, 테스트, 타입 검사, 실행 결과 |
| 좋은 요청 | 대상 독자·형식·자료·품질 기준 명시 | 재현 조건·제약·검증 명령 명시 |
비교 기준은 모델의 이름보다 작업의 기본 단위에 있습니다. Work의 기본 단위는 자료와 산출물이고, Codex의 기본 단위는 작업공간과 변경 사항입니다.
목표: Work는 검토 가능한 업무 결과를 완성하는 데 초점을 둡니다. Codex는 소프트웨어 또는 기술 작업을 실제 프로젝트에서 완료하는 데 초점을 둡니다.
주요 입력: Work는 문서, 메모, 웹 자료, 플러그인, 연결 서비스가 중심입니다. Codex는 저장소, 소스 파일, 설정, 로그, 터미널 명령, 테스트가 중심입니다.
주요 출력: Work는 보고서, 발표자료, 스프레드시트, PDF, 사이트, 반복 보고서가 대표적입니다. Codex는 코드 변경, 테스트, 리뷰 결과, 실행 가능한 프로젝트 상태가 대표적입니다.
검토 방식: Work는 파일 미리보기와 특정 영역 피드백이 편리합니다. Codex는 변경 파일과 diff, 터미널 출력, 테스트 결과를 확인하는 방식이 자연스럽습니다.
권한의 의미: Work는 파일과 플러그인, 승인된 도구를 이용하고 중요한 외부 동작 전에 사용자의 검토가 필요할 수 있습니다. Codex는 로컬 작업공간의 파일·명령·네트워크 범위를 샌드박스와 승인 정책으로 통제합니다.
지속 업무: Work는 프로젝트의 공유 자료와 연결 소스를 활용하고 예약·반복 업무에 적합합니다. Codex는 작업 기록과 작업 디렉터리를 연결하고, 지속 규칙은 AGENTS.md나 저장소 문서에 남기는 방식이 적합합니다.
공통점도 많다
두 모드는 모두 자연어로 목표를 전달하고, 필요한 파일과 도구를 제공하고, 결과를 검토해 수정 방향을 줄 수 있습니다. 복잡한 작업에서는 계획을 세우고 여러 단계를 거치며, 지원되는 계정에서는 하위 에이전트를 사용해 독립적인 조사나 탐색을 병렬로 수행할 수도 있습니다. 플러그인과 연결 도구를 통해 외부 맥락을 가져올 수 있다는 점도 공통적입니다.
따라서 ‘Work는 글만 쓰고 Codex는 코드만 쓴다’는 설명은 너무 단순합니다. Work도 기술 보고서를 만들 수 있고, Codex도 마크다운 문서나 분석 결과를 만들 수 있습니다. 중요한 질문은 산출물의 중심이 무엇인지, 어떤 환경에서 검증해야 하는지, 완료를 무엇으로 판단할지입니다.
또 하나의 오해는 메뉴를 바꾸면 무조건 완전히 다른 기반 모델로 바뀐다고 생각하는 것입니다. 공식 문서에서 Work 또는 Codex의 선택은 우선 작업 경험과 도구 맥락의 선택으로 설명됩니다. 모델과 지능 수준은 별도의 선택 요소가 될 수 있으므로, 모드 선택을 단순한 모델 성능 비교로 해석하면 안 됩니다.
상황별 추천 1: 조사해서 보고서 작성
추천은 ChatGPT Work입니다. 웹 자료, 내부 문서, 첨부 파일을 함께 읽고 출처가 달린 보고서나 브리프를 완성하는 일이기 때문입니다. 자료 범위, 기준 날짜, 제외할 출처, 대상 독자, 분량, 표의 항목, 인용 방식까지 지정하면 결과가 좋아집니다.
프롬프트 예시: ‘첨부한 고객 인터뷰 12개와 회사 소개서, 2026년 7월 1일 이후의 공식 발표만 사용해 이탈 원인을 분석해줘. 원인별 빈도와 대표 사례를 표로 만들고, 제품팀이 다음 분기에 검증할 가설 5개를 우선순위와 함께 제안해줘. 3쪽 분량의 보고서로 작성하고 근거가 부족한 결론은 별도로 표시해줘.’
단, 보고서의 주제가 특정 저장소의 아키텍처 분석이고 최종 결과가 코드 변경까지 이어진다면 Codex가 더 적합합니다. 읽기 전용으로 저장소를 조사한 뒤 개선안을 문서로 만들 수도 있고, 승인받아 실제 수정과 테스트로 연결할 수 있기 때문입니다.
상황별 추천 2: 발표자료와 스프레드시트 만들기
추천은 ChatGPT Work입니다. 슬라이드 구성, 표, 차트, 시트 구조처럼 시각적 결과를 대화 옆에서 확인하고 특정 페이지나 셀 범위를 지목해 수정하기 쉽습니다. ‘예쁘게 만들어줘’보다는 청중, 발표 시간, 핵심 메시지, 슬라이드 수, 브랜드 규칙, 반드시 포함할 수치와 출처를 알려주세요.
프롬프트 예시: ‘첨부한 설문 CSV를 분석해 15분 발표용 10장 자료를 만들어줘. 1장은 결론, 2~4장은 핵심 지표, 5~7장은 세그먼트 차이, 8장은 한계, 9~10장은 권고안으로 구성해줘. 모든 차트의 원본 수치가 들어 있는 스프레드시트도 함께 만들고, 발표자료와 수치가 일치하는지 검증해줘.’
스프레드시트 자동 생성 코드 자체를 저장소에 추가하거나 데이터 파이프라인 테스트까지 해야 한다면 Codex가 맞습니다. 완성된 표가 목적이면 Work, 표를 만드는 프로그램이 목적이면 Codex라고 기억하면 쉽습니다.
상황별 추천 3: 버그 수정과 기능 구현
추천은 Codex입니다. 현재 코드베이스를 읽고 문제를 재현한 다음 파일을 바꾸고 테스트해야 하기 때문입니다. 재현 조건, 기대 동작, 관련 로그, 실행 명령, 변경하면 안 되는 영역, 완료 조건을 주면 좋습니다.
프롬프트 예시: ‘현재 작업공간에서 모바일 화면의 결제 버튼이 두 번 눌리는 문제를 재현해줘. 원인을 찾은 뒤 최소 범위로 수정하고 회귀 테스트를 추가해줘. 공개 API와 결제 이벤트 이름은 변경하지 말고, 관련 단위 테스트와 타입 검사를 실행한 뒤 변경 파일과 검증 결과를 요약해줘.’
기술에 관한 질문이라고 무조건 Codex를 선택할 필요는 없습니다. ‘React의 상태 업데이트 원리를 쉽게 설명해줘’처럼 설명만 필요하면 Chat이 빠릅니다. ‘우리 저장소의 상태 관리 코드를 분석해 개선 보고서를 만들어줘’는 Codex가 좋고, ‘여러 프레임워크를 조사해 경영진용 비교표를 만들어줘’는 Work가 좋습니다.
상황별 추천 4: 코드 리뷰와 배포 준비
추천은 Codex입니다. 변경 diff를 읽고 위험을 찾고 테스트를 실행하며, 필요하면 수정안을 실제 코드에 반영할 수 있습니다. 기준 브랜치, 리뷰 범위, 중점 항목, 허용되는 수정 범위를 분명히 하세요.
프롬프트 예시: ‘현재 브랜치를 main과 비교해 회귀 가능성, 인증·권한 문제, 데이터 손실 위험을 우선 검토해줘. 발견 사항은 심각도와 파일 위치를 포함해 보고하고, 확실한 문제만 최소 수정해줘. 전체 테스트를 실행하기 전에 예상 시간과 범위를 알려줘. 커밋과 푸시는 하지 마.’
배포 공지문, 릴리스 노트, 고객 안내 메일처럼 여러 이해관계자용 산출물을 만들 때는 Work로 넘기는 방식도 좋습니다. Codex에서 변경 내역과 테스트 결과를 정리한 후 Work에서 이를 바탕으로 발표자료와 공지를 작성하면 각 모드의 장점을 살릴 수 있습니다.
상황별 추천 5: 반복 모니터링과 정기 보고
추천은 ChatGPT Work입니다. 지정한 출처를 주기적으로 확인하고 정해진 형식으로 업데이트하는 업무는 Work의 예약 작업과 잘 맞습니다. 무엇을 확인할지, 변화가 없을 때도 보고할지, 어떤 조건에서 알림을 보낼지, 외부 메시지는 승인 후 보낼지를 정하세요.
프롬프트 예시: ‘매주 월요일 오전 9시에 경쟁사 5곳의 공식 블로그와 가격 페이지를 확인해 지난주 변경 사항만 표로 정리해줘. 변화가 없으면 “변경 없음”이라고 기록하고, 가격이나 이용약관 변경은 상단에 표시해줘. 외부로 전송하지 말고 이 작업 안에 초안만 남겨줘.’
반면 저장소의 CI 실패를 감시하고 실패한 테스트를 재현해 수정하는 업무라면 Codex의 프로젝트·자동화 흐름이 더 적합할 수 있습니다. 모니터링 대상이 웹과 업무 자료인지, 코드와 빌드 시스템인지로 나누면 선택이 쉬워집니다.
상황별 추천 6: 웹사이트 만들기
이 경우는 최종 목적에 따라 갈립니다. 내용을 조사하고 비개발자가 검토할 수 있는 소개 사이트를 빠르게 완성·호스팅하는 것이 목적이면 Work의 Sites 흐름이 편합니다. 기존 저장소의 프론트엔드에 기능을 넣고 테스트·빌드·배포 파이프라인까지 관리해야 한다면 Codex가 맞습니다.
예를 들어 ‘행사 자료와 사진으로 공개용 소개 사이트를 만들고 문구와 배치를 검토하고 싶다’는 Work가 자연스럽습니다. ‘Next.js 저장소에 행사 페이지를 추가하고 기존 디자인 시스템을 사용해 반응형과 접근성 테스트까지 통과시켜라’는 Codex가 자연스럽습니다.
선택이 애매할 때 쓰는 5가지 질문
첫째, 최종 결과가 문서·슬라이드·표처럼 사람이 검토할 업무 산출물인가, 아니면 실행 가능한 코드 변경인가? 전자는 Work, 후자는 Codex입니다.
둘째, 완료를 미리보기와 내용 검수로 판단하는가, 테스트·빌드·diff로 판단하는가? 미리보기 중심이면 Work, 개발 검증 중심이면 Codex입니다.
셋째, 핵심 자료가 여러 문서와 연결 서비스에 흩어져 있는가, 하나의 저장소와 터미널 환경에 모여 있는가? 전자는 Work, 후자는 Codex입니다.
넷째, 결과가 반복 보고나 업무 흐름인가, 지속적으로 유지될 소스 변경인가? 전자는 Work, 후자는 Codex입니다.
다섯째, 지금 필요한 것이 빠른 답인가? 그렇다면 Work나 Codex보다 Chat이 더 적절할 수 있습니다. 큰 산출물이나 실제 변경이 필요할 때만 에이전트 작업을 시작하면 시간과 사용량을 줄일 수 있습니다.
Work에서 좋은 결과를 얻는 요청 공식
Work에는 ‘결과물 + 자료 범위 + 대상 독자 + 형식 + 품질 기준 + 승인 지점’을 넣으세요. 예를 들면 ‘이사회용 8장 발표자료를 만들어줘. 첨부한 3개 파일과 정부 공식 통계만 사용하고, 각 수치에 출처를 달아줘. 첫 장에는 결론 3개, 마지막 장에는 의사결정 항목을 넣어줘. 근거가 불충분한 내용은 추정이라고 표시하고 외부 전송 전에 멈춰줘’와 같습니다.
자료를 자유롭게 찾게 할지 제한된 출처만 쓰게 할지도 분명히 해야 합니다. 최신성이 중요하면 기준 날짜를 숫자로 적고, 이해관계가 큰 결론은 반대 근거와 한계를 함께 요구하세요. 파일을 만들 때는 페이지 수, 시트 이름, 열, 차트, 검증 규칙까지 알려주면 첫 결과부터 검토하기 쉬워집니다.
Codex에서 좋은 결과를 얻는 요청 공식
Codex에는 ‘작업 위치 + 문제 또는 변경 목표 + 재현 방법 + 제약 + 검증 명령 + 보고 형식’을 넣으세요. 예를 들면 ‘현재 저장소의 사용자 검색 API가 빈 검색어에서 500을 반환한다. 관련 테스트를 먼저 찾아 재현하고 400 응답으로 수정해줘. 공개 응답 스키마와 데이터베이스는 바꾸지 말고 단위 테스트와 린트를 실행해줘. 완료 후 원인, 변경 파일, 테스트 결과, 남은 위험을 알려줘’와 같습니다.
수정 권한도 분명히 하세요. 원인만 진단할지, 코드까지 바꿀지, 새 의존성을 추가해도 되는지, 마이그레이션이 허용되는지, 커밋과 푸시가 필요한지를 적으면 불필요한 중단을 줄일 수 있습니다. 큰 작업은 탐색과 계획을 먼저 요청한 뒤 수정 범위를 확인하고 구현으로 넘어가는 방식이 안전합니다.
함께 쓰는 현실적인 워크플로
두 모드 중 하나만 고집할 필요는 없습니다. 개발 기능 출시를 예로 들면 Codex가 저장소를 분석하고 기능을 구현하며 테스트 결과와 변경 내역을 정리합니다. 그 결과를 Work에 전달해 릴리스 노트, 고객 공지, 내부 교육 자료, 성과 지표 스프레드시트를 만들 수 있습니다.
반대 방향도 가능합니다. Work가 사용자 조사와 경쟁 제품 분석을 통해 요구사항 문서와 우선순위표를 만들고, 사람이 범위를 승인한 뒤 Codex가 해당 요구사항을 저장소에서 구현합니다. 이때 Work의 산출물에는 모호한 표현 대신 수용 기준과 제외 범위를 넣고, Codex에는 그 문서 경로와 검증 명령을 알려주는 것이 좋습니다.
결국 Work는 업무 맥락을 ‘검토 가능한 결과물’로 압축하고, Codex는 기술 맥락을 ‘검증된 변경’으로 압축합니다. 두 결과 사이에 사람의 승인 지점을 두면 조사에서 구현, 구현에서 커뮤니케이션으로 이어지는 흐름이 훨씬 안정적입니다.
중간에 모드를 바꿔야 할 때
처음 선택이 완벽할 필요는 없습니다. 조사로 시작한 일이 구현으로 커지면 Work에서 결정한 요구사항, 출처, 수용 기준을 파일로 정리한 뒤 Codex 작업에 전달하면 됩니다. 반대로 Codex에서 수정한 기능을 조직에 설명해야 한다면 변경 파일, 테스트 결과, 알려진 제한을 요약해 Work의 입력으로 사용하세요.
전환할 때 가장 중요한 것은 대화 전체를 막연히 넘기는 것이 아니라 ‘확정된 사실’과 ‘아직 결정하지 않은 것’을 구분하는 일입니다. 기준 문서의 파일명과 버전, 대상 저장소와 브랜치, 성공 조건, 제외 범위, 승인된 결정, 남은 질문을 짧은 인수인계 목록으로 만드세요. 그러면 새 모드가 이전 과정의 추측을 사실처럼 받아들이는 위험을 줄일 수 있습니다.
예를 들어 Work가 만든 제품 요구사항 문서에는 사용자 시나리오, 수용 기준, 비기능 요구사항, 제외 기능을 넣고, Codex에는 ‘이 문서를 기준으로 먼저 구현 계획과 영향 파일을 보고하고 승인 후 수정하라’고 요청할 수 있습니다. Codex가 완료한 뒤에는 커밋 범위, 변경된 동작, 테스트 결과, 배포 주의사항을 Work에 넘겨 고객 안내와 내부 교육 자료를 만들 수 있습니다.
자주 하는 실수
첫 번째 실수는 주제만 보고 모드를 고르는 것입니다. 기술 주제의 발표자료는 Work가 더 좋을 수 있고, 비기술 부서가 요청한 자동화 스크립트 수정은 Codex가 더 좋을 수 있습니다. 주제보다 결과 형태와 검증 방식을 보세요.
두 번째 실수는 ‘알아서 해줘’라고만 쓰는 것입니다. 두 모드 모두 목표, 자료, 제약, 성공 기준이 구체적일수록 좋습니다. 특히 외부 전송, 게시, 삭제, 결제처럼 영향이 큰 동작은 승인 전에 멈추도록 명시하세요.
세 번째 실수는 작업공간을 확인하지 않고 Codex를 시작하는 것입니다. 잘못된 폴더를 열면 관련 없는 파일을 탐색하거나 필요한 테스트를 찾지 못합니다. 현재 프로젝트와 쓰기 권한, 네트워크 필요 여부를 먼저 확인하세요.
네 번째 실수는 빠른 질문까지 Work나 Codex에 맡기는 것입니다. 개념 설명, 짧은 요약, 문장 다듬기, 아이디어 비교는 Chat이 더 가볍습니다. 산출물 완성과 실제 변경이 필요할 때 Work 또는 Codex로 확장하세요.
다섯 번째 실수는 생성된 결과를 검토 없이 사용하는 것입니다. 출처, 숫자, 코드 변경, 테스트 범위, 보안과 개인정보를 확인해야 합니다. 법률·의료·재무·보안처럼 위험이 큰 결정은 전문가 검토를 대신할 수 없습니다.
업무별 빠른 결정표
회의록 10개를 읽고 의사결정과 후속 조치를 정리한다면 Work가 기본입니다. 회의 자료와 참석자별 메모가 여러 파일에 있고, 결과를 실행 항목 표나 주간 보고서로 만들어야 하기 때문입니다. 단순히 한 장의 회의록을 5줄로 줄이는 일이라면 Chat만으로 충분합니다.
채용 후보자의 과제 파일을 공통 기준으로 비교해 평가표를 만든다면 Work가 어울립니다. 다만 개인정보와 채용 규정을 확인하고, 최종 판단을 AI에 맡기지 말아야 합니다. 후보자가 제출한 프로그래밍 과제를 저장소에서 실행하고 테스트 실패 원인을 기술적으로 검토한다면 Codex가 더 적합합니다.
월별 매출 CSV를 분석해 경영진용 차트와 스프레드시트를 만든다면 Work를 선택하세요. 같은 CSV를 매일 수집·정제하는 데이터 파이프라인을 저장소에 구현하고 자동 테스트를 추가해야 한다면 Codex를 선택하세요. 데이터 자체의 분석이 결과인지, 데이터를 처리하는 프로그램이 결과인지가 경계입니다.
경쟁 제품 8개의 가격과 기능을 조사해 구매 제안서를 만든다면 Work가 좋습니다. 회사 내부 서비스의 의존성 버전을 비교하고 안전하게 업그레이드한 뒤 빌드와 회귀 테스트를 실행한다면 Codex가 좋습니다. 둘 다 ‘비교’지만 전자는 의사결정 자료, 후자는 검증된 기술 변경입니다.
블로그 글, 보도자료, 고객용 FAQ 초안을 만들고 여러 출처를 대조한다면 Work가 편합니다. 저장소 안의 API 문서가 실제 코드와 일치하는지 확인하고 불일치한 문서 또는 코드를 함께 수정해야 한다면 Codex가 편합니다. 문서라는 출력 형식만 보지 말고 문서의 진실을 무엇으로 검증하는지 확인해야 합니다.
웹페이지의 문구와 정보 구조를 기획하고 시각적 시안을 검토한다면 Work와 Sites 흐름을 고려할 수 있습니다. 기존 디자인 시스템과 컴포넌트를 사용해 페이지를 구현하고 반응형·접근성·브라우저 테스트를 통과시켜야 한다면 Codex가 기본입니다.
운영 장애 보고서를 여러 로그와 채팅 기록에서 정리하는 일은 Work가 맡을 수 있습니다. 그러나 실제 저장소와 실행 환경에서 장애를 재현하고 패치를 만들어 테스트하는 일은 Codex가 맡아야 합니다. 현실적인 흐름은 Codex가 원인과 수정 근거를 만들고 Work가 이를 비기술 독자에게 맞는 사후 보고서로 바꾸는 것입니다.
계약서 여러 버전의 조항 차이를 표로 정리하거나 검토 질문을 준비하는 일은 Work가 도울 수 있지만 법률 판단은 전문가가 해야 합니다. 라이선스 검사 도구를 저장소에 추가하고 정책 위반 시 CI가 실패하도록 구현하는 일은 Codex가 어울립니다.
사용량과 시간까지 고려하는 선택법
공식 문서에 따르면 ChatGPT Work와 Codex는 사용량을 공유합니다. 긴 조사, 여러 도구 호출, 하위 에이전트, 대용량 파일 분석은 짧은 대화보다 더 많은 사용량과 시간이 들 수 있습니다. 따라서 큰 작업을 시작하기 전에 범위를 줄이고, 필요한 출처와 결과 형식을 정하고, 완료 조건을 적는 것이 좋습니다.
Work에서는 ‘공식 출처 5개만 비교’, ‘상위 후보 3개까지만’, ‘초안을 만든 뒤 검토를 기다리기’처럼 자료와 단계의 상한을 두세요. Codex에서는 ‘관련 모듈만 조사’, ‘새 의존성은 추가하지 않기’, ‘먼저 빠른 단위 테스트를 실행하고 전체 테스트는 승인 후 실행’처럼 탐색과 실행 범위를 제한할 수 있습니다.
복잡한 작업을 한 번에 맡길 때는 중간 산출물을 정하는 것도 효과적입니다. Work에는 자료 목록과 개요를 먼저 보여달라고 하고, Codex에는 재현 결과와 수정 계획을 먼저 보고하게 할 수 있습니다. 방향이 맞는지 확인한 뒤 다음 단계로 진행하면 잘못된 전제에서 긴 작업이 이어지는 위험을 줄일 수 있습니다.
보안과 승인 관점에서의 차이
Work가 플러그인이나 연결 서비스를 사용할 때는 어떤 계정과 자료에 접근하는지 확인해야 합니다. 외부 서비스에 쓰기 작업을 수행할 수 있다면 읽기와 초안 작성, 실제 전송을 구분하세요. ‘메일 초안만 만들고 보내지 마’, ‘캘린더 변경 전에 승인받아’, ‘이 문서 밖의 자료는 사용하지 마’처럼 경계를 자연어로 적는 습관이 중요합니다.
Codex에서는 작업 폴더, 파일 읽기·쓰기, 명령 실행, 네트워크 접근 범위가 중요합니다. 기본 권한을 무작정 넓히기보다 현재 작업에 필요한 최소 범위로 시작하세요. 비밀키와 환경 파일, 운영 데이터, 저장소 밖의 개인 문서를 읽지 않도록 하고, 데이터 삭제·마이그레이션·배포·푸시 같은 동작은 별도 승인 단계로 두는 것이 좋습니다.
두 모드 모두 사용자가 제공한 맥락이 결과의 경계가 됩니다. 민감한 자료를 넣기 전에 조직의 데이터 정책과 계정 설정을 확인하고, 결과물에 개인정보나 내부 정보가 남지 않았는지 검토해야 합니다. AI가 도구를 사용할 수 있다는 사실과 그 동작이 조직 정책상 허용된다는 사실은 같지 않습니다.
FAQ
Q1. ChatGPT Work가 기존 ChatGPT와 같은가요?+
같지 않습니다. Chat은 질문, 설명, 브레인스토밍, 짧은 초안에 적합하고 Work는 명확한 결과가 있는 여러 단계 업무를 끝까지 수행해 검토 가능한 산출물을 만드는 경험입니다.
Q2. 개발자가 아니면 Codex를 쓰면 안 되나요?+
그렇지 않습니다. 폴더의 파일을 대량 정리하거나 기술 프로젝트를 분석하는 등 작업공간과 명령 실행이 중요한 일에는 유용할 수 있습니다. 다만 문서·발표자료 중심의 일상 업무는 Work가 더 편합니다.
Q3. Work에서도 코드를 만들 수 있나요?+
가능합니다. 하지만 기존 저장소를 읽고 여러 파일을 수정하며 테스트·빌드까지 수행하는 것이 성공 조건이라면 Codex가 더 적합합니다. 짧은 예제나 기술 설명은 Chat으로도 충분합니다.
Q4. Codex에서도 보고서나 문서를 만들 수 있나요?+
가능합니다. 특히 저장소 분석 보고서, 마이그레이션 계획, 코드 리뷰 결과처럼 코드베이스가 핵심 자료인 문서는 Codex가 잘 맞습니다. 슬라이드나 스프레드시트를 시각적으로 반복 검토하는 일은 Work가 더 편합니다.
Q5. 둘 중 어느 쪽이 더 성능이 좋은가요?+
모드 이름만으로 우열을 정하기 어렵습니다. Work와 Codex는 작업 경험, 도구, 맥락의 기본값이 다릅니다. 선택 가능한 모델과 지능 수준, 제공한 자료, 권한, 성공 기준도 결과에 영향을 줍니다. 목적에 맞는 모드를 선택하는 것이 가장 중요합니다.
Q6. 같은 프로젝트에서 Work와 Codex를 함께 쓸 수 있나요?+
가능합니다. Work로 조사·기획 산출물을 만들고 Codex로 구현하거나, Codex의 변경·테스트 결과를 Work에서 릴리스 자료로 바꾸는 흐름이 실용적입니다. 전달할 때는 파일 경로, 기준 버전, 완료 조건을 명확히 적으세요.
마무리
ChatGPT Work와 Codex의 차이는 ‘글쓰기 AI와 코딩 AI’라는 한 문장보다 넓습니다. Work는 여러 자료와 도구를 이용해 사람이 검토할 업무 결과를 만드는 데 초점을 두고, Codex는 실제 프로젝트 환경에서 파일을 변경하고 명령과 테스트로 결과를 검증하는 데 초점을 둡니다.
선택이 망설여진다면 이렇게 기억하세요. 완성된 보고서·슬라이드·표가 필요하면 Work, 검증된 코드 변경이 필요하면 Codex, 빠른 답과 대화가 필요하면 Chat입니다. 그리고 복잡한 일에서는 Work로 요구사항을 정리하고 Codex로 구현하거나, Codex로 기술 결과를 만든 뒤 Work로 전달 자료를 완성하는 조합이 가장 강력합니다.
'AI > OpenAI' 카테고리의 다른 글
| GPT-Red 자동 안전 레드팀은 무슨 역할을 할까? (0) | 2026.07.17 |
|---|---|
| GPT-5.6 Sol Ultra로 한 줄 프롬프트만 넣어 뱀파이어 서바이버류 게임 만들어보기 (0) | 2026.07.10 |
| GPT-5.6 출시 총정리: Codex 앱은 ChatGPT로 통합됐다 (0) | 2026.07.10 |
| ChatGPT Live 사용 후기 (0) | 2026.07.10 |
| GPT-Live 소개 및 후기: 비서처럼 쓰는 ChatGPT 음성 (2) | 2026.07.09 |
