Codex Cloud: GitHub, Slack, Linear에서 작업 위임하기
Codex Cloud는 Codex의 세 가지 실행 환경 중 하나예요(CLI, IDE 확장과 함께). 내 컴퓨터에서 실행되는 대신 격리된 클라우드 컨테이너 안에서 작업을 실행하고, 웹, GitHub, Slack, Linear에서 트리거할 수 있어요. 저장소를 복제하고 백그라운드에서 작업한 뒤, 검토할 수 있도록 요약과 diff 또는 PR을 돌려줘요. 먼저 알아두세요. Codex Cloud는 ChatGPT Plus 이상이 필요하고, Free와 Go에서는 쓸 수 없어요.
- 아래에서 다루는 요금제 제한, 인터넷 접근 기본값, Slack/Linear 트리거 구문은 작성 시점의 공식 문서와 교차 확인했어요. 이 실행 환경은 빠르게 바뀌므로, 여기에 의존하기 전에 최신 문서에서 확인하세요.
Codex Cloud란?
Codex Cloud는 같은 기반 에이전트를 공유하는 세 가지 실행 환경 중 하나예요. 터미널에서 실행하는 CLI, 그리고 IDE 확장과 나란히 있죠. 핵심 차이는 이거예요. 모든 Cloud 작업은 저장소 접근, 셸, 테스트 러너를 갖춘 자체 격리된 컨테이너 안에서 실행되며, 그 어느 것도 내 컴퓨터에 닿지 않아요. 공식 문서는 이렇게 분명히 말해요. "격리된 클라우드 환경에서 Codex에 작업을 위임하세요"(learn.chatgpt.com/docs/cloud).
계속 읽기 전에 세 가지 실행 환경의 전체 그림을 보려면 OpenAI Codex란 무엇인가를 참고하세요. 혼동을 피하기 위한 한마디. Codex Cloud는 Codex의 기능이며, OpenAI 자체의 "AgentKit"(Agent Builder)과는 완전히 다른 것이에요. 세 가지를 구분하는 자세한 설명은 그 허브 글에 있고, 여기서는 반복하지 않아요.
분명히 짚어둘 만한 실무적 함의가 하나 있어요. 각 작업이 자체 컨테이너를 갖기 때문에, Cloud 작업은 사실상 일회용 인프라예요. 설치하거나 캐시하거나 망가뜨린 것은 작업이 끝나면 아무것도 남지 않고, 그 동작이 다른 작업의 컨테이너로 옆으로 새어 나가지도 않아요. 이것이 CLI와 맞바꾸는 부분이에요. CLI에서는 모든 것이 작업 디렉터리와 이미 거기 존재하는 상태에 직접 실행되니까요.
CLI vs Cloud vs IDE ― 어떤 것을 써야 할까
세 가지 실행 환경은 같은 에이전트를 공유하지만 각각 맞는 상황이 달라요. 흩어진 문서에서 짜맞추지 않아도 되도록 결정 표를 준비했어요.
| 실행 환경 | 실행 위치 | 적합한 용도 | 필요한 것 |
|---|---|---|---|
| CLI | 내 터미널, 대화형. | 직접 손대는 세션, 스크립팅, 즉석 디버깅. | Codex CLI 설치하기. Free 등급에서도(제한적으로) 사용 가능. |
| Cloud | OpenAI 서버의 격리된 컨테이너, 웹/GitHub/Slack/Linear에서 트리거. | 백그라운드 작업, 여러 작업을 병렬로 실행, 터미널을 지켜보지 않고 위임하기. | Plus 요금제 이상(아래 표), 연결된 GitHub, 최소 하나의 환경. |
| IDE | VS Code/JetBrains 안의 확장. | 에디터를 떠나지 않고 diff를 검토하고 에이전트를 조종하기. | 확장 설치. CLI/Cloud 계정을 공유. |
간단한 경험칙이에요. 키보드 앞에 있고 결과를 바로 보고 싶다면 CLI나 IDE를 쓰세요. 작은 작업 묶음 ― 의존성 버전 올리기, 작은 버그 수정, 한 모듈의 테스트 ― 을 위임하고 싶고, 기다리는 동안 컴퓨터를 붙잡아 두고 싶지 않다면, Cloud로 넘기고 다른 일을 하세요.
실제로 셋 다 쓰는 사람 대부분은 하나를 골라 고정하지 않고, 작업마다 바꿔 써요. 계속 주고받아야 하는 까다로운 리팩터링은 CLI에 남겨두죠. 작고 독립적인 잡일 더미는 Cloud로 흩뿌려서, 하나씩 차례로가 아니라 다섯 개를 한 번에 돌려요. 그리고 IDE 확장은 작업을 시작하는 용도보다, 바로 그 직후의 순간에 더 많이 쓰여요. 브라우저나 터미널로 넘어가지 않고, Codex가 이미 만들어 낸 diff를 슥 훑어보는 거죠.
Codex Cloud 샌드박스는 실제로 어떻게 동작하나
모든 Cloud 작업은 자체 컨테이너를 받아요. Codex는 연결된 GitHub 저장소를 체크아웃하고, 설정 스크립트를 실행한 뒤(이 단계에서는 의존성을 설치하기 위한 네트워크 접근이 아직 있어요), 그제서야 실제 에이전트 단계가 시작돼요. 그 에이전트 단계 동안 인터넷 접근은 기본적으로 꺼져 있어요 ― 허용 목록 프리셋을 고르세요. none(완전히 꺼짐), common-dependencies(일반적인 패키지 레지스트리 허용), all(완전히 개방) 중 하나예요. 출처: learn.chatgpt.com/docs/cloud/internet-access ― 정확한 프리셋 동작에 의존하기 전에 다시 확인할 가치가 있어요. 바뀔 수 있으니까요.
각 작업을 이런 식으로 격리하는 이유는 꽤 단순해요. OpenAI가 서로 다른 저장소, 서로 다른 사용자, 서로 다른 회사에서 임의의 수의 작업을 동시에 실행하면서도, 한 작업의 의존성 설치나 폭주하는 프로세스가 다른 작업에 영향을 주지 않게 하기 위해서예요. 여러분에게 실무적 이점은, 불안정한 `npm install` 하나가 다음 작업이 의존하는 환경을 망칠까 걱정하지 않고, 오후 한나절에 작은 위임 작업 십여 개를 던질 수 있다는 거예요. 하나하나가 깨끗한 상태에서 시작하니까요.
두 가지 "샌드박스" 의미를 혼동하지 마세요. 여기서 설명한 Cloud 샌드박스(격리된 컨테이너)는 Codex CLI의 로컬 샌드박스 권한 모드(
read-only/workspace-write/danger-full-access― 로컬 CLI 세션이 디스크에서 건드릴 수 있는 범위)와는 완전히 다른 개념이에요. 둘 다 "샌드박스"라는 말을 쓰지만, 서로 무관한 두 가지 메커니즘이에요. 로컬 권한 수준은 로컬 샌드박스 권한 모드를 참고하세요.
Codex Cloud 연결하기 ― GitHub, Slack, Linear
GitHub
GitHub 계정을 연결하고, Codex가 접근할 수 있는 저장소를 고른 다음, 저장소(또는 저장소 그룹)마다 환경을 만드세요. 의존성, 설치할 도구, 환경 변수, 시크릿을 선언해요. 이 환경이야말로 Codex Cloud가 그 저장소에 대해 작업을 실행할 때마다 재사용하는 것이에요 ― 한 번 설정하면 여러 번 재사용하죠. 출처: learn.chatgpt.com/docs/cloud.
저장소당 환경이 하나로 제한되지는 않아요. 예를 들어 프런트엔드와 백엔드 서비스를 가진 모노레포는, 의존성 세트가 다른 두 개의 별도 환경을 두는 것이 합리적인 경우예요. 그래야 프런트엔드로 범위를 좁힌 작업이, 절대 쓰지 않을 백엔드 도구를 설치하는 데 설정 시간을 쓰지 않아요. 이걸 처음에 제대로 맞춰두는 건 몇 분의 추가 시간을 들일 가치가 있어요. 몇 초 만에 작업을 시작하는 작업과, 실행 시간 대부분을 패키지 설치에만 쓰는 작업의 차이를 만드니까요.
Slack
Plus 요금제 이상, 연결된 GitHub 계정, 그리고 이미 설정된 환경이 최소 하나 필요해요. 워크스페이스 관리자가 Slack용 Codex 앱을 설치하고, 그 후에는 누구나 채널이나 스레드에서 @Codex를 멘션해 작업을 위임할 수 있어요 ― 예를 들어 "@Codex fix the null pointer in org/repo"처럼요(이것은 설명을 위한 예시이지 문서의 원문 인용이 아니에요 ― 인용으로 공개하기 전에 정확한 구문을 확인하세요). Codex는 👀 이모지로 반응하고, 작업을 추적할 링크를 올린 뒤, 같은 스레드에서 결과로 답해요. 출처: learn.chatgpt.com/docs/third-party/slack.
여기서 눈여겨볼 부분은, 앱이 설치되면 설정한 사람뿐 아니라 채널에 있는 누구나 작업을 위임할 수 있다는 점이에요 ― 바로 그래서 "관리자가 한 번 설치하고, 누구나 트리거하는" 모델이 팀에 중요해요. 새 팀원이 "Codex에게 물어보기"를 익히는 건 Slack 멘션 하나면 되고, CLI 설치와 인증 절차가 필요 없어요.
Linear
"Codex for Linear" 앱을 설치하고, 이슈 댓글에서 @Codex를 멘션해 계정을 연결하세요. 작업을 트리거하는 방법은 두 가지예요. 이슈를 Codex에 직접 배정하거나, 댓글에서 @Codex를 멘션하는 거예요. 트리아지 자동화를 켜면, 매번 수동으로 하는 대신 새로 트리아지된 이슈를 Codex에 자동 배정할 수도 있어요. 출처: learn.chatgpt.com/docs/third-party/linear. 클라우드에 작업을 위임하는 대신 Linear 데이터를 로컬에서 읽기만 하면 된다면, Codex MCP 설정을 참고하세요.
실제 위임 작업, 처음부터 끝까지
제가 가장 자주 실행하는 걸 소개할게요. Slack으로 보고된 작은 버그를 터미널을 열지 않고 고치는 거예요.
- 트리거. 개발 채널에서
@Codex fix the crash when a user submits an empty email field on org/checkout-service라고 입력해요(설명용이며 원문 그대로의 명령은 아니에요). 터미널은 열려 있지 않고, 로컬에 저장소도 복제하지 않았어요 ― 이 시점에 저는 그냥 휴대폰으로 Slack을 읽고 있을 뿐이에요. - 환경 선택. Codex는
checkout-service저장소용으로 이미 구성된 환경을 골라요 ― 매번 의존성을 다시 선언하지 않아도 되고, 그 서비스가 고정한 Node/Python 버전을 기억할 필요도 없어요. - 컨테이너 시작. Codex는 저장소를 체크아웃하고, 설정 스크립트를 실행해 의존성을 설치한 뒤, 그 환경용으로 제가 고른 프리셋으로 인터넷 접근을 설정한 상태에서 에이전트 단계가 시작돼요.
- 백그라운드에서 실행. 그동안 저는 다른 일을 해요 ― 터미널을 지켜볼 일도, "아직 생각 중인가" 하며 새로고침을 반복할 일도 없어요.
- 결과 검토. Codex는 무엇을 바꿨는지 요약을 diff와 함께 바로 Slack 스레드에 올려요 ― 저는 그걸 대충 훑는 기록이 아니라, 동료의 PR 설명을 읽듯이 읽어요.
- PR 열기. diff를 읽고, 괜찮아 보이면 Codex가 PR을 열게 해요 ― 맹목적인 병합이 아니라 동료의 PR처럼 검토하고, 뭔가 어긋나면 스레드에 답글을 달면 제가 승인하기 전에 수정해줘요.
이점은 순수한 속도가 아니에요(제가 2분이면 직접 칠 수 있는 변경이라면 CLI가 더 빠를 때도 있어요) ― 이점은 제가 Slack을 한 번도 떠나지 않는다는 것이고, 이런 작은 수정을 여러 개 병렬로 위임하면서도 제 컴퓨터를 붙잡거나 매번 터미널로 컨텍스트를 전환하지 않아도 된다는 거예요.
어떤 ChatGPT 요금제가 필요한가
이건 이 가이드에서 가장 쓸모 있는 사실이에요. Free와 Go에서는 Codex Cloud를 쓸 수 없어요. 공식 문서에 따르면, Slack 연동 페이지가 요건을 분명히 밝혀요 ― "Plus, Pro, Business, Enterprise, Edu 요금제"(learn.chatgpt.com/docs/third-party/slack), 이는 learn.chatgpt.com/docs/pricing과 일치해요.
| ChatGPT 요금제 | Codex Cloud 사용 가능? |
|---|---|
| Free | ✗ |
| Go | ✗ |
| Plus | ✓ |
| Pro | ✓ |
| Business | ✓ |
| Enterprise / Edu | ✓ |
Free나 Go를 쓰고 있는데 클라우드 위임 버튼을 눌러도 아무 일이 없다면, 그게 이유예요 ― 버그가 아니에요. 하나 더 알아둘 점. 요금 페이지에 따르면, Cloud와 로컬 CLI 사용량은 별도의 예산이 아니라 같은 롤링 크레딧 창(대략 5시간)을 공유해요 ― 이 수치를 전제로 무거운 사용을 계획하기 전에 다시 확인하세요. 한도는 바뀌니까요. 이 요금제 제한도 영구적이라고 여기지 마세요 ― ChatGPT 요금제 기능은 전에도 바뀐 적이 있으니, 읽고 있는 시점에 다시 확인하세요.
실무적으로 이는, Cloud를 더 많이 쓰는 습관 ― 이를테면 하루에 작은 작업 열 개를 흩뿌리는 것 ― 이 대화형 CLI 세션과 같은 사용량 풀에서 끌어다 쓴다는 뜻이기도 해요. 이미 요금제 한도에 가깝게 긴 CLI 세션을 돌리고 있다면, 그 위에 바쁜 Cloud 워크플로를 더하는 건, 이미 가진 요금제에 무료로 얹히는 여유 용량이라고 단정하지 말고 지켜볼 가치가 있어요.
Codex Cloud vs Claude Code ― 클라우드 위임은 진짜 차별점
과장 없이 솔직히 말할게요. Claude Code의 주된 실행 환경은 로컬/CLI예요 ― 내 컴퓨터에서 실행되고, subagent와 hook을 통해 확장돼요. Codex는 반대 방향으로 가서, GitHub/Slack/Linear를 통한 퍼스트파티 클라우드 위임을 기본으로 제공하며, 따로 만들어야 할 게 없어요. 이건 마케팅이 아니라 진짜 차이예요 ― 팀이 자체 파이프라인을 조립하지 않고 Slack이나 Linear에서 작업을 위임하고 싶다면, 그건 Codex Cloud에 유리한 확실한 점이에요.
반대로, 주된 작업이 단계별로 촘촘한 제어가 필요한 긴 대화형 세션이라면, Claude Code가 여전히 subagent/skill/hook 생태계가 더 깊어요. 전체 비교는 Claude Code vs Codex 전체 비교를 참고하세요 ― 그 글은 아직 Cloud를 구체적으로 다루지 않으니, 이 가이드를 그 짝이 되는 글로 봐주세요.
이게 실제로 가장 크게 작용하는 곳은 개인 사용이 아니라 팀 도입이에요. 팀 전체에 CLI를 설치하게 하고, 인증하게 하고, 플래그를 익히게 하는 건 실제 마찰이에요. 이미 매일 머무는 Slack 스레드에서 @Codex를 치게 하는 건 마찰이 거의 없어요 ― 그리고 그 격차야말로, 어느 에이전트가 기술적으로 더 뛰어난가와 무관하게, 클라우드 위임이 CLI 도구보다 팀에 더 빨리 퍼지는 이유예요.
자주 묻는 질문(FAQ)
Codex Cloud란?
Codex Cloud는 Codex의 세 가지 실행 환경 중 하나로, 격리된 클라우드 컨테이너 안에서 작업을 실행하고, 웹, GitHub, Slack, Linear에서 트리거한 뒤, 검토할 수 있도록 diff나 PR을 돌려줘요.
Codex Cloud에 유료 요금제가 필요한가요?
네. Plus, Pro, Business, Enterprise, Edu가 필요해요 ― 작성 시점의 공식 문서에 따르면 Free와 Go에서는 쓸 수 없어요.
GitHub PR에서 Codex Cloud를 트리거할 수 있나요?
네. GitHub 계정을 연결하고 그 저장소용 환경을 만들면, GitHub는 (Slack, Linear와 함께) 세 가지 공식 트리거 채널 중 하나예요.
Codex Cloud는 인터넷 접근이 되나요?
설정 스크립트 단계에서는 돼요(의존성을 설치하기 위해). 실제 에이전트 단계 동안에는 인터넷 접근이 기본적으로 꺼져 있고, none/common-dependencies/all 허용 목록 프리셋으로 열 수 있어요.
작업이 끝난 뒤 제 코드는 어떻게 되나요?
Codex는 요약을 diff와 함께 돌려주거나, 검토할 수 있도록 PR을 열어요. 작업을 실행한 컨테이너는 그 실행에만 쓰이는 격리된 환경이지, 여러분의 컴퓨터가 아니에요.
Slack/Linear 작업을 병렬로 실행할 수 있나요?
네. 각 작업은 자체 컨테이너에서 실행되므로, Slack, Linear, GitHub에서 여러 작업을 한 번에 위임할 수 있고, 순차적으로 실행되기를 기다릴 필요가 없어요.
결론
짧게 말하면, 직접 손대는 대화형 작업에는 CLI를, GitHub·Slack·Linear를 통한 백그라운드/병렬/팀 트리거 작업에는 Cloud를 쓰세요 ― 그리고 Cloud는 Plus 이상이 필요해요. 세 가지 실행 환경이 어떻게 다른지 아직 명확하지 않다면, 무엇이든 설정하기 전에 OpenAI Codex란 무엇인가로 돌아가 전체 그림을 읽어보세요.