Codex Cloud 출시: 여전히 에이전트를 로컬 컴퓨터에서 실행해야 하는 경우는 언제일까?

지난 9월 29일 열린 DevDay에서 OpenAI는 개발자들이 “컴퓨터에서든, 스마트폰에서 원격으로든, 클라우드에서 어떤 기기로든 필요한 곳 어디서나 Codex를 실행할 수 있다”고 밝혔습니다. 하지만 개발 팀의 입장에서 DevDay 요약 글 중 가장 주목해야 할 문장은 바로 그 다음에 이어지는 내용입니다. 재사용 가능한 개발 환경은 “작업을 빠르게 시작할 수 있도록 돕고, 승인된 설정 및 권한이 적용된 공유 환경을 팀에 제공합니다.” Codex cloud는 Plus, Pro, Business, Healthcare, Education, Enterprise 플랜에서 사용할 수 있습니다.

개인 개발자 한 명에게는 이것으로 고민이 해결될 수 있습니다. 하지만 워크스테이션에서는 Claude Code를, 빌드 서버에서는 Codex를, 누군가의 노트북에서는 Gemini를 이미 실행하고 있는 팀이라면 작업 위치가 하나 더 늘어난 셈입니다. 이제 작업은 OpenAI의 클라우드, 사내 자체 하드웨어, 심지어 이동 중 스마트폰에서도 시작되며, 각 위치마다 실행된 작업 목록이 따로 관리됩니다. 어떤 에이전트가 어떤 작업을 처리 중인지, 무엇이 완료되었는지, 어떤 작업이 리뷰어를 기다리고 있는지 확인해야 할 곳이 하나 더 늘어난 것입니다. 따라서 지금 던져야 할 유용한 질문은 “클라우드냐 로컬이냐?”가 아닙니다. 어떤 작업을 어디서 처리해야 하며, 그 작업의 기록은 어디에 남겨야 하는가입니다.

요약 (TL;DR)

Codex cloud는 빠르게 시작해야 하거나, 노트북이 절전 모드에 들어가도 계속 실행되어야 하거나, 모바일 기기에서 시작해야 하는 Codex 작업에 더 적합합니다. 또한 팀원 각자가 자체 호스트를 준비하는 대신 모두가 승인된 단일 환경을 공유하고자 하는 팀에도 최선의 선택입니다. 반면, 작업에 Claude Code나 기타 비(非) Codex 런타임이 필요하거나, 플랜의 기본 VM 사양을 넘어서는 하드웨어가 필요하거나, 현재 OpenAI의 클라우드 환경 문서에 지원되지 않는 것으로 명시된 항목(GitLab 리포지토리, 브라우저 조작, SSH 또는 데이터베이스 프로토콜을 통한 프라이빗 서비스 접근 등)이 필요할 때는 자체 Computer가 훨씬 유리합니다. 다만 두 방식 중 어느 쪽을 선택하더라도 누가 작업을 할당하고 최종 승인할 것인지는 결정되지 않습니다. 그 권한은 여전히 팀과 개별 Task에 남아 있습니다.

Codex 클라우드 환경이 제공하는 것

OpenAI 공식 문서에 따르면 클라우드 환경이란 “리포지토리, 종속성, 도구, 접근 설정 등 작업이 사용하는 재사용 가능한 환경”을 의미합니다. 사용자가 GitHub 리포지토리를 선택하면, Codex가 이를 분석하여 종속성과 도구를 설치하고 워크플로를 테스트한 뒤 자체적으로 유추할 수 없는 항목에 대해 질문합니다. 설정 보고서를 검토한 후 게시(Publish)하면, 이후의 모든 새로운 작업은 이렇게 게시된 파일 시스템을 바탕으로 각자의 격리된 워크스페이스에서 시작되며, 작업은 “컴퓨터가 절전 모드에 들어가도 계속 진행될 수 있습니다.”

접근 모델은 토큰을 직접 붙여 넣은 설정 스크립트보다 훨씬 정교하게 설계되어 있습니다. 환경 변수는 프로그램에 직접 전달되지만, 네트워크 시크릿은 프로세스에 직접 도달하지 않습니다. 프로그램에는 플레이스홀더만 전달되며, 허용된 HTTPS 대상에 대해서만 프록시가 실제 자격 증명으로 대체합니다. 인터넷 접근은 활성화한 후 패키지 관리자 프리셋이나 사용자 지정 도메인 목록을 통해 접근 범위를 좁힐 수 있습니다. 프라이빗 서비스는 VPN을 통해 접근할 수 있으며(현재 지원되는 프로바이더는 Tailscale), Enterprise 워크스페이스에서는 수명이 짧은 임시 클라우드 자격 증명을 위한 OIDC 연결을 요청할 수 있습니다.

작업을 시작하는 방식 역시 유연합니다. Codex Cloud 개요에서는 웹, 데스크톱 앱, 모바일, Codex CLI를 지원한다고 안내하며, Cloud delegation(클라우드 위임) 권한이 있는 Enterprise 워크스페이스는 Slack이나 Microsoft Teams에서 @ChatGPT 멘션을 통해 작업을 시작할 수 있습니다. Enterprise 환경은 워크스페이스 전체에 공유할 수 있으므로, 새로운 팀원이 들어와도 환경을 다시 구축할 필요 없이 이미 승인된 설정으로 바로 시작할 수 있습니다. Codex 작업 관점에서 이는 환경 불일치(setup drift)를 방지하는 실질적인 해결책이 됩니다.

OpenAI의 자체 라인업 역시 실행 위치를 단 하나의 정답이 아닌 워크로드별 선택지로 다룹니다. Dots는 각자 전용 클라우드 컴퓨터를 할당받으며, Agents API는 에이전트는 누가 실행하는가에서 다루었듯이 OpenAI 호스팅 환경 또는 자체 호스팅 환경을 선택할 수 있습니다. 이제 Codex 역시 두 환경 모두에서 실행할 수 있게 되었습니다.

Sharkly Computer가 제공하는 것

Computer는 에이전트가 작업을 실행할 수 있는 연결된 디바이스, 서버 또는 컨테이너입니다. Sharkly Computers 공식 문서에 따르면 Computer는 “에이전트가 필요로 하는 운영체제, 파일, 자격 증명, 네트워크 접근 권한 및 도구를 제공”합니다. 작은 로컬 서비스가 해당 기기를 등록하고, 설치된 런타임(Runtime)을 감지하며, 대기 중인 실행 요청을 수신하고 진행 상황을 스트리밍으로 전달합니다. 이 서비스는 아웃바운드로 연결을 생성하므로 일반적인 설정에서는 인바운드 포트를 열 필요가 없습니다.

비교를 위해 주목해야 할 핵심 특성은 세 가지입니다. 첫째, 하나의 Computer가 여러 런타임을 제공할 수 있습니다. Sharkly는 Claude Code, Codex, Gemini, OpenCode, OpenClaw, Hermes를 기본 지원하며, 로컬 서비스가 자동으로 감지하지 못하는 도구는 커스텀 ACP 런타임으로 커버할 수 있습니다. 또한 하나의 Computer가 여러 에이전트를 지원할 수 있습니다. 둘째, 격리가 Task 단위로 이루어집니다. Temporary 모드에서는 각 Task마다 격리된 디렉터리가 할당되며, 리포지토리 기반 실행은 새로운 워크트리(worktree)를 사용할 수 있습니다. 이것이 바로 병렬 에이전트가 병합 충돌을 방지하는 방법입니다. Specified 모드에서는 이미 구성된 종속성, 캐시, 로컬 서비스가 갖춰진 로컬 디렉터리를 재사용하며 한 번에 하나의 실행만 처리합니다. 셋째, 자격 증명에 대한 완전한 통제권이 사용자에게 있습니다. 에이전트는 일반 환경 변수 및 시크릿 환경 변수를 관리하며, 각 실행에는 허용된 환경과 자격 증명만 전달됩니다. 그리고 개인(Personal) 공개 범위로 설정된 Computer는 소유자 본인만 사용할 수 있습니다.

솔직히 말해 호스트를 직접 관리해야 한다는 부담이 따릅니다. Computer가 오프라인 상태가 되면 새 실행 요청은 다시 연결될 때까지 대기합니다. 데스크톱 앱이 시스템 절전 모드를 방지할 수 있고, macOS에서는 시스템이 허용하는 한 노트북 덮개를 닫아도 계속 실행되도록 유지할 수 있지만, 장시간 사람의 개입 없이 실행되는 작업은 코딩 에이전트 원격 실행하기에서 언급했듯이 직접 제어할 수 있는 서버에서 실행하는 것이 바람직합니다. 비용 구조는 그대로 유지됩니다. Computer와 런타임은 Sharkly 요금제의 시트(Seat)를 차지하지 않으며, Sharkly는 토큰을 판매하지 않습니다. 또한 Codex 에이전트는 Codex CLI에 로그인된 ChatGPT 요금제나 API 키를 그대로 사용합니다.

Codex cloud vs 자체 Computer: 의사결정 비교표

아래 표의 Codex cloud 관련 항목은 9월 30일 기준 OpenAI 클라우드 환경 문서에 기반하며, Computer 관련 항목은 Sharkly 공식 문서를 바탕으로 작성되었습니다.

이를 두 가지 기준의 의사결정으로 요약할 수 있습니다. 작업이 Codex 대상이고, 종속성이 공개되어 있거나 허용 목록에 등록된 HTTPS를 통해 접근 가능하며, 작업을 시작하는 사람이 자리에 없을 수 있다면 Codex cloud를 선택하세요. 반면 작업에 특정 이유로 선택한 런타임, 하드웨어 또는 네트워크가 필요하다면 자체 Computer를 사용하면 됩니다.

위 표에서 의도적으로 제외된 항목이 하나 있습니다. 바로 “사내 네트워크 밖으로 나가서는 안 되는 데이터”입니다. 자체 Computer에서 실행하면 리포지토리, 캐시, 시크릿을 직접 제어하는 하드웨어 내에 보관할 수 있습니다. 하지만 그렇다고 해서 프롬프트가 모델 제공자에게 전송되는 것을 막을 수 있는 것은 아닙니다. 런타임이 모델로 보내는 데이터는 여전히 외부로 나가기 때문입니다. OpenAI 역시 자사 제품에 대해 동일한 기준을 적용합니다. Agents API 공식 문서에는 “자체 호스팅 샌드박스를 선택하더라도 Agents API의 ZDR(데이터 무보관 정책) 대상이 되는 것은 아니다”라고 명시되어 있습니다. 실행 위치는 코드와 자격 증명이 어디에 머무는지를 결정할 뿐이며, 데이터 보존(Retention) 정책은 모델 제공자와 맺는 별도의 계약 사항입니다.

혼합 실행 환경에서 보드(Board)의 진가가 드러납니다

대부분의 팀은 두 가지 방식을 모두 활용하게 될 것입니다. 간단한 Codex 수정 작업은 스마트폰에서 클라우드 환경으로 전달하고, 스테이징 데이터베이스 접근이 필요한 마이그레이션 작업은 사내 네트워크 내 Computer의 에이전트로 실행하는 식입니다. 이는 매우 합리적인 분업이지만, 그 결과 작업 목록이 두 군데로 나뉘게 됩니다.

Codex cloud는 설계상 작업들을 격리하여 관리합니다. 문서에 따르면 공유 환경에 접근할 수 있다고 해서 “다른 사람의 작업에 대한 접근 권한까지 부여되는 것은 아닙니다.” 개인정보 보호와 보안 관점에서는 당연히 올바른 기본 설정입니다. 하지만 이는 환경만 공유될 뿐 실제 작업 내역은 공유되지 않는다는 의미이기도 합니다. 따라서 클라우드 작업과 로컬 Computer를 통틀어 “현재 우리 팀의 에이전트들이 무슨 작업을 하고 있는가?”라는 질문에 대한 답은 다른 곳에서 찾아야 합니다. 먼저 라우팅 규칙을 다음과 같이 정리해 볼 수 있습니다.

Where does this Task run?
1. Needs a non-Codex Runtime                          -> Agent on a Computer
2. Needs SSH, a database protocol, or private DNS     -> Computer inside that network
3. Needs GitLab, GitHub Enterprise Server, or browser use -> Computer
4. Codex work, allowlisted HTTPS, started away from a desk -> Codex cloud
5. Someone must accept the result                     -> a Task with an Assignee and a reviewer, wherever it ran

다섯 번째 규칙이야말로 이렇게 분산된 환경을 관리 가능하게 유지해 주는 핵심입니다. Sharkly에서는 Task 자체가 하나의 통합 기록이 됩니다. 진행 상황, 실행 로그, 블로커(이슈), 결과물이 모두 Task로 수집되며, 사람의 검토가 필요한 실행 건은 담당자의 받은편지함(Inbox)으로 전달됩니다. 동일한 Computer에 있는 Codex 에이전트와 Claude Code 에이전트는 각자의 런타임에 구성된 모델을 따르면서도 동일한 보드에 보고합니다. 한편 Codex cloud에서 실행된 작업의 경우 풀 리퀘스트(PR)가 연결 고리가 됩니다. 브랜치 이름이나 PR 제목에 Task ID를 포함하면 Sharkly의 GitHub 연동 기능이 해당 PR을 Task와 연결해 주므로, 작업의 최종 승인은 여전히 한 곳에서 이루어집니다. 장시간 무인 실행의 리뷰 방식에 대해서는 근무 시간보다 오래 걸리는 에이전트 실행 글에서 자세히 다루고 있습니다.

에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 설정하고, 권한을 부여하며, 결과를 검토하고 승인합니다. 실행이 어디에서 이루어졌든 이러한 역할 분담과 계약은 결코 변하지 않습니다.

환경 구성을 위해 기억해야 할 점

Codex cloud는 “Codex를 어디서 실행해야 하는가?”라는 질문에 훌륭한 답이 될 수 있습니다. 하지만 “모든 런타임에 걸쳐 우리 에이전트들이 각자 어떤 작업을 수행하고 있으며, 최종 승인은 누가 했는가?”에 답하기 위해 만들어진 것은 아닙니다. 전용 런타임, 하드웨어 또는 네트워크가 필요한 작업은 Computer에 맡기고, 모바일에서 시작하거나 노트북을 닫고 진행하는 작업은 Codex cloud에 맡기되, 이 두 가지 작업의 기록은 한곳에서 통합 관리하세요.

특정 단일 생태계에 종속되지 않고 여러 코딩 에이전트를 유연하게 함께 활용하고자 한다면, 그것이 바로 Sharkly가 해결하고자 하는 핵심 과제입니다.