ChatGPT Work 출시: Codex와 분리해서 봐야 할 에이전트 작업 흐름

왜 개발팀이 ChatGPT Work를 뉴스로 봐야 하나

ChatGPT 안에 Work라는 별도 작업 공간이 들어오면, 개발팀 입장에서는 “또 다른 채팅 탭”이 하나 생긴 정도로 보일 수 있습니다. 그렇게 보면 놓치는 지점이 있습니다. OpenAI 도움말 기준으로 Chat은 빠른 질의응답, Work는 긴 다단계 작업과 완성 산출물, Codex는 소프트웨어 개발과 기술 작업에 초점을 둡니다. 즉 같은 ChatGPT 계정 안에서도 작업 단위가 더 명확하게 갈라지는 흐름입니다.

실무에서는 이 구분이 중요합니다. 지금까지 많은 팀이 리서치, 문서 작성, 코드 수정, 테스트 계획을 한 대화창에서 섞어 처리했습니다. 처음에는 편하지만, 작업이 길어질수록 맥락이 흐려지고 결과물의 책임 경계가 애매해집니다. “이 대화는 의사결정 문서용인가, 코드 변경용인가, 단순 검색용인가”가 섞이는 순간 리뷰 비용이 커집니다.

OpenAI 문서에서 Work는 보고서, 문서, 스프레드시트, 프레젠테이션, Site 같은 완성 산출물을 만드는 작업에 배치됩니다. 반면 Codex는 로컬 폴더, 저장소, 터미널, 개발 도구와 연결된 기술 작업에 남습니다. 이 구분은 에이전트 도입을 고민하는 팀에게 하나의 운영 힌트를 줍니다. AI 도구를 모델 이름으로만 고르지 말고, 산출물의 책임 범위로 나누라는 뜻입니다.

문제는 모델 성능보다 작업 경계입니다

에이전트 도입 실패는 모델이 약해서만 생기지 않습니다. 더 흔한 원인은 작업 경계가 흐릿한 것입니다. 예를 들어 한 명의 개발자가 “결제 모듈 장애 원인 조사, 패치, 릴리즈 노트, 고객 안내문”을 한 번에 AI에게 맡긴다고 가정해보겠습니다. 이 요청은 리서치, 코드 작성, QA, 커뮤니케이션이 섞여 있습니다.

이 상태에서 AI가 만든 결과물은 좋아 보여도 리뷰하기 어렵습니다. 코드 변경은 테스트로 검증할 수 있지만, 고객 안내문은 법무·CS 톤 검토가 필요합니다. 장애 원인 분석은 로그와 재현 조건이 필요하고, 릴리즈 노트는 실제 배포 범위와 일치해야 합니다. 하나의 대화 안에서 전부 처리하면 “어디까지 믿어도 되는지”가 불분명해집니다.

Work와 Codex를 분리해서 보는 이유가 여기에 있습니다. Codex는 저장소와 실행 환경을 다루는 개발 작업에 적합합니다. Work는 결과 문서나 분석 산출물처럼 저장소 외부의 deliverable에 적합합니다. 물론 둘이 완전히 분리되는 것은 아닙니다. 다만 시작점과 검증 기준은 달라야 합니다.

Work, Codex, Chat을 이렇게 나누면 운영이 단순해집니다

팀에서 바로 적용하려면 세 가지 분류만 먼저 정하면 됩니다. 첫째, Chat은 빠른 질문과 짧은 탐색에 둡니다. API 옵션 확인, 용어 비교, 에러 메시지 해석처럼 결과물이 짧고 다시 만들기 쉬운 작업입니다.

둘째, Work는 문서형 산출물에 둡니다. 요구사항 초안, 회의 요약, 경쟁사 분석, 장애 회고 문서, QA 체크리스트처럼 사람이 읽고 승인하는 결과물입니다. Work가 긴 다단계 작업을 맡을 수 있다고 해도, 바로 운영 정책을 바꾸기보다는 문서 산출물부터 시작하는 편이 안전합니다.

셋째, Codex는 저장소와 연결된 작업에 둡니다. 버그 수정, 테스트 추가, 리팩터링, 코드 리뷰, 로컬 명령 실행처럼 diff와 로그로 검증 가능한 작업입니다. 개발팀에서는 Codex 결과를 “완성 코드”가 아니라 “검토 가능한 변경 세트”로 취급해야 합니다.

이렇게 나누면 역할 충돌이 줄어듭니다. PM은 Work에서 요구사항과 정책 문서를 정리하고, 개발자는 Codex에서 코드 변경을 만들고, Tech Lead는 최종 diff와 테스트 결과를 봅니다. 같은 AI라도 산출물 단위를 다르게 잡는 것이 핵심입니다.

로컬 작업과 클라우드 작업을 섞을 때의 주의점

OpenAI 문서에 따르면 Work는 웹·모바일·데스크톱에서 제공되고, 데스크톱에서는 플랜과 워크스페이스 설정에 따라 로컬 파일과 앱을 사용할 수 있습니다. Codex는 데스크톱 앱의 별도 뷰로 남고, 로컬 폴더·저장소·터미널·개발 도구와 연결됩니다. 이 차이는 보안 정책에 바로 영향을 줍니다.

민감한 저장소를 다루는 팀은 먼저 “어떤 작업이 로컬에서 실행되고, 어떤 메시지와 작업 맥락이 클라우드에 저장될 수 있는지”를 확인해야 합니다. 문서에는 로컬에서 실행되는 작업이라도 메시지와 작업 맥락은 클라우드에 저장될 수 있다고 설명되어 있습니다. 따라서 소스 코드 접근 권한만 볼 것이 아니라, 프롬프트와 산출물의 보관 정책도 함께 봐야 합니다.

권한도 분리해야 합니다. Work Cloud, Work Local, Codex Local 같은 설정이 있다면 기본 역할에 전부 허용하지 말고, 팀 단위로 점진 적용하는 편이 낫습니다. 문서 산출물과 코드 변경은 실패했을 때의 리스크가 다릅니다. 코드 변경은 테스트로 잡히지만, 잘못 정리된 정책 문서는 조직 전체의 의사결정을 왜곡할 수 있습니다.

개발팀 적용 순서

첫 주에는 Work를 리서치와 문서 초안에만 씁니다. 예를 들어 “OAuth 마이그레이션 영향 범위 정리”, “장애 회고 초안”, “API 변경 공지 초안”처럼 코드 변경이 없는 작업입니다. 이때 산출물마다 출처 링크, 확인 필요 항목, 담당자 질문을 포함하도록 템플릿을 만듭니다.

둘째 주에는 Codex를 작은 저장소 작업에 붙입니다. 테스트 추가, 문서 업데이트, 타입 오류 수정처럼 rollback이 쉬운 작업부터 시작합니다. 작업마다 브랜치, 테스트 명령, 리뷰어를 고정합니다. “AI가 고쳤다”가 아니라 “AI가 만든 PR을 사람이 리뷰했다”는 흐름이어야 합니다.

셋째 주에는 Work와 Codex를 연결합니다. Work에서 요구사항과 체크리스트를 만들고, Codex에서 구현 후보를 만들고, 사람이 둘 사이의 불일치를 확인합니다. 이때 중요한 것은 한 에이전트가 모든 것을 끝내게 하지 않는 것입니다. 산출물별 책임자를 나누면 실패 지점도 빨리 보입니다.

실행 체크리스트

• Chat, Work, Codex의 용도를 팀 문서에 1문단씩 정의합니다.
• Work에는 문서형 산출물, Codex에는 저장소 변경 작업을 우선 배정합니다.
• 로컬 파일 접근, 클라우드 저장, 음성 기능 사용 여부를 워크스페이스 설정에서 확인합니다.
• Codex 작업은 반드시 브랜치, 테스트 명령, 리뷰어를 포함합니다.
• Work 산출물은 출처 링크와 확인 필요 항목을 마지막에 남깁니다.
• 첫 적용 범위는 “되돌리기 쉬운 업무”로 제한합니다.

ChatGPT Work 출시는 단순한 기능 추가라기보다 작업 분류의 신호에 가깝습니다. 다음 분기 AI 도구 운영 기준을 만든다면, 먼저 질문해야 할 것은 “어떤 모델이 제일 센가”가 아닙니다. 우리 팀의 작업은 Chat, Work, Codex 중 어디에서 검증 가능한 산출물로 끝나는가입니다.