Codex CLI와 Codex Cloud 사용법: 재사용 환경과 모바일 작업 관리

Codex CLI와 Codex Cloud 중 무엇을 쓸지 고민한다면, 자리를 비운 뒤에도 작업이 계속되어야 하는지부터 생각해 보면 좋습니다. 자리를 비우기 전에 Codex에 실패하는 테스트를 맡기면 노트북을 꺼도 작업이 이어집니다. Codex Cloud에서는 프로젝트 환경을 재사용할 수 있고, 웹과 휴대폰으로 진행 상황을 확인하거나 방향을 잡아 주고 결과를 검토할 수 있습니다.

9월 30일, 무엇이 달라졌나요?

이번 개편으로 클라우드 작업을 반복하기가 한결 수월해졌습니다. 다음 작업을 시작하기 전에 저장소와 의존성, 스크립트, 설정을 준비해 둘 수 있습니다. 휴대폰이나 다른 컴퓨터에서도 Codex의 진행 상황을 확인하고 작업 방향을 조정할 수 있습니다. 익숙한 데스크톱 사용 경험도 웹과 모바일로 확장됩니다. OpenAI가 2026년 9월 30일 발표에서 소개한 변화입니다.

환경은 미리 준비해 둔 작업장이라고 생각하면 됩니다. 도구와 재료는 갖춰 놓고, 작업마다 별도의 작업대를 쓰는 방식입니다. 여기서 의존성이란 프로젝트에 필요한 소프트웨어 패키지를 뜻하고, 저장소는 코드와 그 버전 이력을 모아 둔 곳입니다.

실질적인 이점은 코딩 작업을 계속하기 위해 내 컴퓨터를 켜 둘 필요가 없어진다는 점입니다. Codex Cloud는 OpenAI가 관리하는 컴퓨터에서 실행됩니다. 데스크톱이나 웹에서 환경을 만들고 게시하면 지원되는 기기에서 사용할 수 있습니다. 각 작업에는 독립된 작업 파일이 할당됩니다. 이 구분은 OpenAI의 Cloud 도움말에서 설명합니다.

저는 결과를 직접 확인할 수 있는 작은 작업부터 시작하기를 권합니다. 백그라운드 에이전트는 어떤 결과가 나와야 성공인지 미리 정해 두었을 때 가장 유용합니다.

Codex Cloud를 사용할 수 있는 요금제는 무엇인가요?

Cloud를 쓰려면 이용 자격이 있는 Plus, Pro, Business, Enterprise, Healthcare 또는 Education 계정이 필요합니다. 실제 이용 가능 여부는 기능 제공 단계와 워크스페이스 설정에 따라 달라집니다. Free와 Go에서도 Codex를 사용할 수 있지만 Codex Cloud는 포함되지 않습니다. Guest, K-12, Enterprise의 보기 전용 시트는 클라우드 환경을 만들 수 없습니다. 이 구분은 OpenAI의 요금제별 이용 안내를 근거로 합니다.

위 구독 요금은 2026년 10월 7일 확인한 Codex 요금 안내 페이지를 기준으로 합니다. Cloud 이용 자격이 있다고 해서 모든 구성원이 모든 제어 기능을 사용할 수 있는 것은 아닙니다.

클라우드 작업은 사용 한도를 어떻게 차감하나요?

출시 시점에는 표준 환경에 별도의 가상 머신 요금이 붙지 않습니다. 가상 머신은 작업을 실행하는 원격 컴퓨터입니다. 다만 모델 사용량은 일반 Codex 한도에 반영되며, 해당하는 크레딧이나 과금 체계도 적용됩니다. 사용량 풀을 공유하는 요금제에서는 기능이 제공되는 경우 Codex, ChatGPT Work, ChatGPT for Excel, Workspace Agents 간에 사용량을 공유할 수 있습니다. 토큰 기반 Enterprise 계약은 크레딧 대신 USD로 과금합니다. 자세한 계산 방식은 OpenAI의 사용량 규정에 나와 있습니다.

로컬 메시지와 클라우드 채팅은 같은 요금제 한도를 사용하며, 주간 한도가 적용될 수도 있습니다. 클라우드 작업은 로컬 메시지보다 한도를 더 많이 소모할 수 있습니다. 요금 페이지의 메시지 수 추정치는 로컬 사용 기준이며, 그만큼의 클라우드 작업을 보장한다는 뜻은 아닙니다. 이용 자격이 있는 Plus와 Pro 사용자는 요금제를 올리지 않고도 크레딧을 추가 구매할 수 있습니다. 현재 한도와 초기화 시점은 사용량 대시보드에서 확인하면 됩니다. 관련 변수는 Codex 요금 및 사용량 안내에서 설명합니다.

이미 이용 가능한 요금제를 구독 중이라면 용량을 더 구매하기 전에 범위가 명확한 작업부터 시험해 보기를 권합니다. 비용 대비 효과는 줄어든 직접 작업 시간에서 환경 유지보수, 작업 조율, 검토 시간을 뺀 값으로 따져야 합니다. 추가 크레딧 비용은 별도로 계산합니다. 이 계산에서 이득이 있어야 작업을 클라우드에 맡길 가치가 있습니다.

구독과 API 비용을 폭넓게 비교하려면 2026년 Codex 요금 안내를 참고하면 됩니다. Cloud는 ChatGPT 로그인이 필요합니다. API 키를 쓰는 로컬 CLI 세션에는 별도의 API 과금이 적용됩니다. 차이는 인증 방식 안내에서 확인할 수 있습니다.

Codex 사용법: 재사용할 클라우드 환경 설정하기

큰 변경을 맡기기 전에 테스트가 안정적으로 실행되는 프로젝트를 준비합니다. 예전의 레거시 절차 대신 현재의 클라우드 환경 설정 안내를 따릅니다.

1. 저장소를 연결합니다. 웹이나 데스크톱에서 Work in > Cloud > Select environment > Create environment를 선택합니다. GitHub 저장소를 고르고, 연결 안내가 나오면 GitHub를 연결합니다.
2. 프로젝트를 준비합니다. Get started를 선택합니다. Codex가 프로젝트를 살펴보고 설치와 테스트를 수행하도록 합니다. 빠진 정보와 필요한 버전을 알려 줍니다.
3. 설정 스크립트를 검토합니다. Install script에는 의존성 준비 과정이, Start skill에는 서비스 시작과 준비 상태가 기록됩니다. 대화를 통해 설정을 다듬습니다.
4. 설정값을 입력합니다. 환경 변수나 네트워크 시크릿 옆의 Manage를 선택합니다. 네트워크 시크릿에는 키, 값, 허용 도메인을 입력합니다.
5. 인터넷 접근을 설정합니다. 필요하면 Allow Codex to access internet을 켭니다. Package managers 또는 Custom domains only를 선택하고 필요한 호스트를 추가합니다. **All (unrestricted)**를 선택하면 더 넓은 범위에 접근할 수 있습니다.
6. 환경을 게시하고 작업을 시작합니다. 파일, 설정, 검사 결과를 검토합니다. 저장한 뒤 Publish를 선택합니다. Environment published가 표시되면 새 작업을 시작합니다. 나중에 설정을 바꾸려면 Edit와 Republish를 사용합니다.

환경을 준비하는 대화에서는 프로젝트의 실제 설치·테스트 명령, 필요한 런타임 버전, 서비스를 알려 줍니다. 어떤 검사를 통과했고 무엇을 확인하지 못했는지도 보고하도록 요청합니다. 이는 요청 내용에 대한 제안이며, 모든 프로젝트에 그대로 적용하는 설정 스크립트는 아닙니다.

첫 실험에는 합성 테스트 데이터를 쓰고, 작업을 재현하는 데 필요한 최소한의 서비스 접근 권한만 허용하는 편을 권합니다. 패키지 다운로드가 실패하면 인터넷 접근 범위를 바로 넓히기보다 해당 호스트 이름과 인증 상태를 각각 확인합니다.

처음 맡기기 좋은 작업 3가지

출발점이 분명하고 범위가 작으며, 끝난 뒤 근거를 직접 확인할 수 있는 작업을 고릅니다. 아래 요청문은 각 저장소에 맞게 조정해 사용할 수 있습니다.

실패하는 테스트 수정하기

재현 가능한 오류 때문에 출시가 막힌 창업자라면 원인 조사와 해당 문제를 해결하는 패치를 맡길 수 있습니다. 실패하는 명령과 출력을 제공하고, 의도한 동작을 유지하면서 원인을 설명하고 실행한 검사 결과를 보고하도록 요청합니다.

다음과 같이 요청할 수 있습니다.

프로젝트 문서에 적힌 명령으로 이 테스트 실패를 재현해 주세요. 원인을 찾고 올바르게 해결하는 데 필요한 최소한의 수정을 해 주세요. 테스트를 통과시키려고 검증 조건을 완화하지 마세요. 해당 테스트와 관련된 인접 테스트를 실행해 주세요. 변경 파일, 결과, 아직 확인하지 못한 사항을 정리해 주세요.

제가 첫 작업으로 가장 추천하는 이유는 수정 전후의 차이를 눈으로 확인할 수 있기 때문입니다. 테스트가 통과해도 diff는 검토해야 합니다. 패치가 실패를 감추는 데 그치지 않고 실제 동작을 바로잡았는지 확인해야 합니다.

마이그레이션 작성하기

데이터베이스 스키마를 바꾸는 백엔드 개발자라면 마이그레이션 파일, 호환성 검토 사항, 폐기 가능한 데이터를 이용한 테스트를 요청합니다. 마이그레이션은 데이터베이스 구조나 저장된 데이터의 변경을 버전별로 관리하는 방식입니다.

다음과 같이 요청할 수 있습니다.

저장소의 기존 규칙에 맞춰 이 스키마 변경을 위한 마이그레이션 초안을 작성해 주세요. 현재 애플리케이션과의 호환성, 롤백 방법, 데이터 손실 위험을 설명해 주세요. 가능하면 폐기 가능한 픽스처로 테스트해 주세요. 운영 환경에서 실행하거나 배포하지 마세요.

얻을 수 있는 것은 검토 가능한 구현과 더 명확한 배포 계획입니다. 마이그레이션을 작성했다고 해서 운영 환경의 잠금 문제, 백필에 걸리는 시간, 구버전과 신버전 애플리케이션의 공존 가능성까지 해결되는 것은 아닙니다. 이 판단은 배포 담당자가 맡아야 합니다.

풀 리퀘스트 검토하기

동료의 변경 사항을 기다리는 유지보수 담당자라면 PR의 브랜치 또는 커밋과 기준 브랜치를 명시합니다. 작업 파일은 그대로 두고, 근거를 갖춘 검토 결과를 요청합니다.

다음과 같이 요청할 수 있습니다.

이 풀 리퀘스트를 기준 브랜치와 비교해 검토해 주세요. 정확성, 권한 처리, 호환성, 빠진 테스트에 집중해 주세요. 각 지적 사항에 파일 위치, 구체적인 실패 상황, 뒷받침하는 근거를 포함해 주세요. 파일을 수정하거나 PR을 병합하지 마세요.

GitHub에 통합된 리뷰를 쓰고 싶다면 OpenAI 문서에서 안내하는 저장소 연결과 PR 댓글 @codex review를 사용합니다. 해당 절차는 GitHub 리뷰 설정 안내에 나와 있습니다. 전환 기간에는 Code Review, Security Review, 기존 GitHub 및 Linear 연동이 계속 **Codex Cloud (Legacy)**를 사용합니다. 이 구분은 Cloud 도움말에서도 확인할 수 있습니다.

새 클라우드 작업 안에서 리뷰를 요청하는 것과 GitHub 자동 리뷰는 별도의 워크플로입니다.

추가로 맡겨 볼 만한 작업 3가지

실패하는 테스트를 수정해 본 뒤라면, 범위를 정하고 결과를 확인하기 쉬운 순서로 다음 작업들을 권합니다. 모두 제안하는 워크플로이며, 실제 성과를 보고하는 사례는 아닙니다.

요청문에는 완료 조건을 꼭 넣습니다. “이 코드베이스를 개선해 주세요”라는 요청은 정하지 않은 사항이 너무 많아 첫 작업으로 적합하지 않습니다.

휴대폰에서 진행 상황을 확인하고 방향 잡기

하던 작업을 이어가려면 같은 작업으로 돌아가야 합니다. 새 작업을 열면 별도의 작업 공간이 시작되며, 첫 작업에서 커밋하지 않은 변경 사항을 가져오지 않습니다. 중요한 변경은 커밋해 둡니다. 저장된 VM의 기본 복구 가능 기간은 마지막 대화 턴이 시작되거나 작업이 재개된 시점부터 최대 7일입니다. 이는 대화 기록 보관 기간에 대한 규정과는 별개입니다. 어떤 상태가 저장되는지는 OpenAI의 작업 상태 안내에서 설명합니다.

모바일에서 Codex를 열고 게시한 환경을 선택합니다. 기존 작업을 다시 열면 진행 상황을 확인하고 수정 지시를 보낼 수 있습니다. 기기 간 작업 흐름은 Cloud 개요에 나와 있습니다.

좋은 조율 메시지는 아직 정하지 않은 사항을 명확하게 결정해 줍니다.

• “수정은 파서 안에서만 하고, 외부에 공개된 응답 구조는 유지해 주세요.”
• “마이그레이션 테스트에는 폐기 가능한 데이터베이스 픽스처를 사용해 주세요.”
• “패치와 테스트 보고까지 마치고 멈춰 주세요. 배포는 검토 후에 진행하겠습니다.”

저라면 휴대폰으로 작업 범위와 진행 상황을 확인하고, 변경량이 많은 diff는 큰 화면에서 검토하겠습니다. 노트북에서 실행 중인 작업에 원격으로 접속하는 방식은 여전히 그 컴퓨터에 의존합니다. Cloud처럼 노트북을 끈 상태에서도 실행되는 방식은 아닙니다. OpenAI 도움말은 이 둘을 구분합니다.

Codex CLI와 Cloud, 어떤 작업에 무엇을 쓸까요?

범위가 명확한 작업이 독립적으로 계속 실행되어야 한다면 클라우드를 선택합니다. 내 컴퓨터에 있는 파일과 개발 툴이 필요한 작업이라면 로컬 CLI를 사용합니다.

CLI는 로컬 저장소를 살펴보고 파일을 수정하며 설치된 툴을 실행할 수 있습니다. 프로젝트 디렉터리를 열고 codex를 실행한 뒤 ChatGPT로 로그인합니다. codex cloud를 통해 작업을 위임할 수도 있으므로, 처음 사용한 인터페이스가 작업의 실행 위치를 결정하는 것은 아닙니다. 두 방식 모두 CLI 가이드에서 설명합니다.

아래는 제가 권하는 선택 기준입니다.

현재 Cloud 환경은 컴퓨터·브라우저 사용, GitLab, 자체 호스팅하는 GitHub Enterprise Server를 지원하지 않습니다. 개인 로컬 스킬도 동기화되지 않습니다. 클라우드를 선호한다는 막연한 판단보다 현재의 제약 사항을 확인하는 것이 더 중요합니다.

접근 권한을 좁히고 diff 검토하기

환경이 어디에 접근할 수 있는지 파악합니다. 허용 도메인은 VM이 접속할 수 있는 네트워크 목적지를 정합니다. 서비스 권한까지 부여하는 것은 아닙니다. 환경에 속한 네트워크 시크릿에 지정한 도메인도 허용됩니다. Enterprise의 Agent Security 요구 사항은 환경 설정과 함께 적용됩니다. 이러한 제어 방식은 네트워크 설정 안내와 Agent Security 안내에서 설명합니다.

자격 증명을 전달할 방식을 올바르게 선택합니다. 일반 환경 변수의 값은 프로그램에 직접 전달됩니다. 네트워크 시크릿은 환경 설정과 작업 수행 중 443 포트의 승인된 HTTPS 목적지에 프록시 플레이스홀더를 사용합니다. 따라서 원본 자격 증명이 로컬 프로세스나 파일에 노출되지 않습니다. 작동 원리는 시크릿 처리 안내에서 확인할 수 있습니다.

저라면 첫 코딩 작업에 운영 환경의 자격 증명을 넣지 않고, 필요한 범위로 제한한 개발용 접근 권한을 사용하겠습니다. 병합하기 전에는 diff를 읽고 테스트 출력을 확인하며 의존성 변경을 살펴봅니다. 패치가 요청한 내용과 일치하는지도 확인합니다. 테스트 통과는 판단할 근거이지, 검토를 생략해도 된다는 허가는 아닙니다.

Healthcare 계정에 Cloud 이용 자격이 있다고 해서 Cloud가 OpenAI의 보호 대상 건강 데이터 처리 계약인 BAA의 적용을 받는 것은 아닙니다. OpenAI는 Codex Cloud에서 보호 대상 건강 정보를 처리하지 말라고 명시합니다. 이 제한은 Cloud 데이터 처리 제한 안내에 나와 있습니다.

팀 단위 제어에 대해서는 DevDay 이후 Codex 보안 설정 방법을 참고하면 됩니다.

이 워크플로를 바탕으로 어떤 제품을 만들 수 있을까요?

가장 유망한 기회는 특정 소프트웨어 스택을 위한 출시를 막는 오류 해결 키트입니다. 깨진 테스트 때문에 시간을 낭비하는 팀에 반복 가능한 작업 절차와 검증 방식을 판매하는 것입니다. DataForSEO의 10월 7일 조사에서는 “automated software testing tools”의 미국 Google 월간 검색량을 1,600건으로 추정합니다. 이는 해당 업무에 대한 관심을 보여 주는 수치이며, Codex Cloud 자체의 수요를 뜻하지는 않습니다.

최소한으로 유용한 버전은 저장소 지침, 재현 가능한 픽스처, 범위가 명확한 수정 요청문, 환경 준비 가이드로 구성할 수 있습니다. 제안된 패치가 의도한 동작을 유지하고 검토 부담을 줄이는지 측정합니다. 걸림돌은 테스트 인프라가 제각각이라는 점입니다. 지원 스택을 넓히면 작은 키트도 유지보수 비용이 커집니다.

마이그레이션 검증 패키지는 특정 프레임워크와 데이터베이스를 쓰는 팀을 대상으로 할 수 있습니다. DataForSEO는 “database migration tools”의 미국 월간 검색량을 1,300건으로 추정합니다. MVP에는 마이그레이션 템플릿, 폐기 가능한 테스트 데이터, 호환성 검사, 준비된 환경에서 개발자가 실행하는 검토 프롬프트를 담을 수 있습니다. 문제는 운영 환경의 실제 동작입니다. 재사용 가능한 패키지라고 해도 실제 데이터베이스 변경이 안전하거나 빠르게 끝날 것이라고 보장할 수는 없습니다.

PR 리뷰 근거 패키지는 유지보수 담당자가 검토 결과를 요청하고 평가하는 방식을 표준화하는 데 도움이 될 수 있습니다. DataForSEO는 “ai code review”의 미국 월간 검색량을 1,300건으로 추정하며, 실제 검색 질문에는 “Can ChatGPT do a code review?”(ChatGPT로 코드 리뷰를 할 수 있나요?)도 포함됩니다. 저장소 지침, 리뷰 요청문, 지적 사항의 근거를 정리하는 형식부터 만들 수 있습니다. 이미 기본 리뷰 기능이 있다는 점이 걸림돌입니다. 패키지는 특정 도메인에 맞는 판단과 유용한 검사 항목을 더해야 합니다.

세 가지 모두 문서화된 작업 위임 기능을 바탕으로 제안하는 제품입니다. 검색량은 해당 업무에 대한 관심의 추정치이며, 고객 수나 매출 전망이 아닙니다. 먼저 오류 해결 키트부터 시작하기를 권합니다. 리뷰의 전반적인 품질보다 완료 조건을 측정하기 쉽기 때문입니다.

ChatGPT로 코드 리뷰를 할 수 있나요?

가능합니다. Codex에는 문서화된 GitHub PR 리뷰 워크플로가 있으며, 별도의 검토 작업을 요청할 수도 있습니다. 기준 브랜치와 확인할 위험 요소를 명시합니다. 병합 여부는 사람이 결정해야 합니다.

AI가 작성한 코드는 안전한가요?

실제 패치를 평가해야 합니다. 변경된 동작, 권한 처리, 의존성, 테스트, 확인되지 않은 가정을 살펴봅니다. 설명이 매끄럽거나 테스트가 통과했다고 해서 중요한 모든 상황을 확인했다는 뜻은 아닙니다.

코드 리뷰에 시간을 들일 가치가 있나요?

한 번 더 검토하면 큰 비용을 초래할 실수를 잡아낼 수 있는 작업에 에이전트 리뷰를 사용합니다. 유용한 지적과 잘못된 경고를 기록합니다. 줄여 주는 수고보다 추가 검토 부담이 크다면 범위를 좁힙니다.

다음 월요일에는 이렇게 시작해 보세요

테스트 명령이 안정적으로 실행되는 저장소 하나를 고릅니다. 환경을 준비해 게시하고, 재현 가능한 작은 오류를 맡깁니다. 자리를 비운 뒤에는 휴대폰에서 작업을 확인합니다. 병합 전에 패치를 검토하고, 환경 설정과 검토에 든 노력, 요금제 사용량을 기록합니다. 이 실험이 작업 흐름을 개선했다면 해당 환경을 재사용합니다.

팀의 개발·배포 과정에 이 워크플로를 도입하고 싶다면 AI 프로덕션 시스템 구축을 살펴보세요.