병렬·클라우드 운영

Codex의 차별점은 로컬 패치만이 아닙니다. 긴 작업을 여러 실행 단위로 나누고, 다시 사람이 합칠 수 있게 만드는 운영 능력이 중요합니다.

이 문서를 읽으면

클라우드 작업, worktree (작업 책상), subagent (보조 에이전트)를 언제 나눠 쓰는지 이해합니다.
goal mode (목표 모드)와 remote-control (원격 제어)을 긴 작업의 운영 표면으로 다룹니다.
병렬 작업에서 같은 파일을 동시에 건드리지 않게 합니다.
automation (자동화)와 Skill (반복 절차)을 만들기 전에 확인할 조건을 정합니다.
Sites처럼 호스팅까지 이어지는 작업은 저장, 검토, 배포를 분리합니다.

오늘 바로 해볼 일

큰 작업 하나를 골라 “읽기 전용 조사”, “로컬 패치”, “리뷰” 세 단계로 쪼개보세요. 각 단계마다 수정 가능한 파일 범위를 다르게 적습니다.

나누어 맡기는 기준

단위	쓸 때	주의할 점
goal mode (목표 모드)	몇 시간 또는 며칠 이어지는 목표를 Codex가 계속 붙잡아야 할 때	objective, 완료 기준, 중간 보고, 중단 조건을 먼저 고정
클라우드 작업	긴 분석, 비동기 구현, 환경 분리 작업, PR 후보 생성	로컬 비밀정보와 로컬 전용 검증을 넘기지 않음
worktree (작업 책상)	같은 저장소에서 여러 diff (변경점)를 병렬로 만들 때	write scope (수정 범위)를 분리
subagent (보조 에이전트)	좁은 조사나 보조 구현을 병렬로 맡길 때	명시적으로 요청하고, 토큰 비용과 승인 흐름을 감안
automation (자동화)	반복 점검, 정기 리뷰, CI/이슈 후속 처리	실패 시 사람이 볼 요약이 있어야 함
non-interactive/CI (비대화형 실행)	`codex exec`나 GitHub Action으로 반복 작업을 파이프라인에 넣을 때	최소 권한, 좁은 프롬프트, 재검증 명령을 함께 둠
Sites	Codex app에서 웹사이트, 대시보드, 내부 도구, 게임을 OpenAI 호스팅으로 저장·배포할 때	저장된 version (검토 후보)과 production deployment (공개 배포)를 분리
remote connection (원격 연결)	모바일이나 다른 기기에서 연결된 컴퓨터(host)의 Codex를 이어서 제어할 때	실행 환경은 현재 기기가 아니라 연결된 host라는 점을 명확히 함
Appshots/browser-use	다른 앱 화면, 웹페이지, 이미지 자산, 구조화 데이터를 작업 맥락으로 넘길 때	화면과 도구 출력은 참고 자료이지 자동 승인 근거가 아님
Skill (반복 절차)	반복 절차가 명확할 때	입력, 출력, 검증 기준이 있어야 함
Plugin/MCP (기능 묶음/외부 연결)	외부 앱, 문서, 사내 도구와 연결할 때	연결 앱의 권한, 개인정보, 승인 정책을 따로 확인

병렬 작업 보드

긴 목표를 여러 thread (작업 대화)로 나눌 때는 “누가 무엇을 하는가”보다 “어떤 write scope (수정 범위)를 소유하는가”를 먼저 보입니다. 아래 표를 그대로 복사해 작업 시작 전에 채우면 병합 비용이 줄어듭니다.

작업 이름	실행 표면	write scope (수정 범위)	금지 범위	완료 증거	합치기 기준
읽기 전용 조사	Web/Cloud	없음	파일 수정	흐름 지도, 위험 목록	patch 후보가 3개 이하로 좁혀짐
로컬 patch	CLI 또는 IDE extension	관련 모듈과 테스트	설정 완화, lockfile 변경	diff (변경점), 테스트 결과	리뷰 가능한 작은 commit 후보
UI 확인	CLI + 브라우저	관련 page와 CSS	새 UI 라이브러리 설치	데스크톱/모바일 스크린샷	overflow와 콘솔 에러 없음
PR 리뷰	Codex app review	없음	코드 수정	review note (리뷰 메모)	blocker와 follow-up 분리

같은 파일을 두 작업이 동시에 소유하면 병렬이 아니라 충돌입니다. 먼저 읽기 전용 조사로 좁힌 뒤 하나의 작업만 수정권을 갖게 합니다.

공식 기능을 운영 단위로 해석하기

Codex app: thread (작업 대화), worktree (작업 책상), 리뷰, 터미널 작업, in-app browser, Chrome extension, Computer Use, automation (자동화), Skills, Plugins를 한 운영 화면으로 모읍니다.
Goal mode: Codex app, IDE extension, CLI에서 긴 objective를 여러 turn 동안 유지하는 작업 표면입니다. 목표, 완료 기준, 증거, 남은 위험을 계속 갱신하게 해야 합니다.
Codex CLI: 로컬 터미널 화면(TUI), 모델·추론 설정, 이미지 입력, 로컬 코드 리뷰, subagent (보조 에이전트), 웹 검색, cloud task (클라우드 작업), MCP, approval mode (승인 모드), remote-control을 터미널에서 다룹니다.
IDE extension: 열린 파일과 선택 영역 맥락, 명령 팔레트, slash command, cloud delegation, goal mode, 클라우드 변경점(cloud diff) 적용까지 편집기 안에서 처리합니다.
Codex web: GitHub 저장소와 연결해 cloud 환경에서 백그라운드 작업을 만들고, 인터넷 접근과 환경 설정을 제어합니다.
Appshots와 browser-use: 앱 화면, 브라우저 화면, 이미지 자산, 구조화 데이터를 더 빠르게 작업 맥락으로 가져오는 보조 표면입니다. 시각 증거와 입력 맥락을 늘리지만, 승인선과 신뢰 경계는 그대로 둡니다.
Skills와 Plugins: Skill은 반복 절차의 작성 형식이고, Plugin은 Skill, 앱 연결(app integration), MCP server를 묶어 설치하는 배포 단위입니다. Plugin sharing은 팀이 재사용 가능한 묶음을 배포하는 방향이므로, 권한과 회수 기준을 함께 둡니다.
Sites: Codex app의 Sites plugin으로 웹사이트나 앱을 만들고 OpenAI 호스팅에 저장·배포하는 표면입니다. 모든 배포 URL은 production deployment로 보므로, 먼저 save version (검토 후보)을 만들고 승인된 version만 배포하는 흐름으로 다룹니다.

자동화와 원격 연결은 환경부터 확인합니다

반복 작업을 자동화할 때는 “Codex가 무엇을 할 수 있는가”보다 “어떤 환경에서, 어떤 권한으로, 어떤 결과를 남기는가”를 먼저 정합니다.

codex exec는 CI, 병합 전 검사(pre-merge check), 예약 작업(scheduled job)처럼 대화형 터미널 화면(TUI)이 필요 없는 반복 실행에 둡니다.
goal mode (목표 모드)는 긴 작업을 맡길 때 유용하지만, “계속 해줘”가 아니라 완료 기준, 보고 주기, 멈출 조건을 포함한 objective로 시작해야 합니다.
codex remote-control은 준비 상태와 machine status를 확인하고 명시적인 start/stop 경계를 남기는 원격 운영 명령으로 다룹니다.
CI에서 자동 수정까지 허용한다면 실패 commit 확인, 의존성 설치, 좁은 프롬프트, 최소 sandbox 권한, 테스트 재실행, PR 생성 순서로 닫습니다.
GitHub Action은 CLI 설치와 실행을 workflow 안에 넣는 방식이므로, workflow 권한과 secret 노출 범위를 PR 리뷰 대상에 포함합니다.
remote connection (원격 연결)은 휴대폰이나 다른 기기에서 지시를 보내더라도 파일, 명령, Plugin, MCP, 브라우저, Computer Use는 연결된 컴퓨터(host) 설정을 따릅니다.
remote computer use (원격 컴퓨터 사용)는 잠긴 Mac에서도 이어질 수 있지만, 신뢰된 computer-use turn, 짧은 승인, 화면 보호, 재잠금 같은 조건이 붙는 민감한 작업으로 봅니다.
연결된 컴퓨터(host)가 로그인된 웹사이트나 사내 도구에 접근할 수 있다면, 그 접근은 별도 승인선과 감사 대상으로 봅니다.
Sites 배포는 “사이트가 보인다”가 완료가 아닙니다. source diff (변경점), build 성공, 저장된 version, 접근 대상, 환경 변수와 secret (비밀값), production URL을 확인한 뒤 공유합니다.
Amazon Bedrock 같은 관리형 모델 제공자 설정은 개인 API 키 편의가 아니라 조직 인증, 계정 통제, 과금 경계가 걸린 운영 설정으로 보고 별도 승인선에 둡니다.

반복 작업을 자산으로 바꾸는 기준

처음부터 모든 요령을 Skill이나 자동화로 만들 필요는 없습니다. 먼저 사람이 한 번 믿을 수 있게 끝내고, 반복될 때만 더 단단한 자산으로 올립니다.

단계	알맞은 때	남길 기준
작업 요청서	같은 문제라도 매번 맥락이 달라질 때	목표, 수정 범위, 금지 행동, 검증 명령
저장된 템플릿	같은 요청 문장이 반복될 때	좋은 요청 예시, 나쁜 요청에서 바꾼 이유
Skill	입력, 절차, 출력, 검증이 안정적으로 반복될 때	`SKILL.md`, 필요한 참고 파일, 실패 시 멈출 조건
Codex용 CLI	사람보다 명령이 더 정확하게 확인할 수 있을 때	인자, 종료 코드, 기계가 읽기 쉬운 출력(machine-readable), 예시 실행
eval/check (평가/검사)	품질이 회귀하기 쉽고 사람이 매번 읽기 어려울 때	통과 기준, 샘플 케이스, 실패 요약 위치
non-interactive/CI (비대화형 실행)	PR, 예약 작업(scheduled job), 릴리스처럼 자동 실행 시점이 명확할 때	최소 권한, secret (비밀값) 범위, 재실행 명령, 사람에게 갈 요약
Sites 배포	사람이 볼 수 있는 호스팅 결과가 필요할 때	save version, production URL, 접근 범위, runtime secret 설정, 되돌릴 version

이 기준은 “자동화할 수 있는가”보다 “실패했을 때 사람이 원인을 좁힐 수 있는가”를 묻습니다. 원인을 좁히지 못하는 자동화는 팀 속도를 올리기보다 알림만 늘립니다.

자동화 승격 전 질문

작업 요청서를 바로 automation (자동화), Skill, CI로 올리기 전에 아래 질문에 답합니다.

질문	통과 기준
입력이 안정적인가	매번 필요한 파일, 로그, issue, URL이 예측 가능합니다.
실패를 기계가 감지할 수 있는가	종료 코드, 검사 스크립트, 링크 검사, eval처럼 실패 기준이 있습니다.
사람이 볼 요약이 있는가	Telegram, GitHub summary, PR 댓글 등으로 변경 여부와 다음 행동이 보입니다.
권한이 최소인가	읽기/쓰기, secret (비밀값), 외부 서비스 접근이 분리되어 있습니다.
되돌릴 수 있는가	실패 commit, 임시 파일, 외부 상태 변경을 회수하는 절차가 있습니다.

두 개 이상 답이 약하면 자동화보다 저장된 요청 템플릿이나 수동 체크리스트가 먼저입니다.

병렬 작업의 안전선

서로 다른 작업은 서로 다른 write scope (수정 범위)를 가져야 합니다.
worktree (작업 책상)마다 목표, 허용 파일, 병합(merge) 기준을 지정합니다.
automation (자동화)는 무엇을 확인하고 언제 사람에게 열어줄지 명확해야 합니다.
Skill은 개인 요령이 아니라 반복 가능한 절차일 때 만듭니다.
외부 시스템 연결은 접근 범위가 설명 가능할 때만 붙입니다.
subagent (보조 에이전트)는 사용자가 명시적으로 요청할 때만 나누고, 부모 작업이 바로 기다려야 하는 일은 먼저 직접 처리합니다.
Plugin이나 MCP를 붙일 때는 앱 권한, 데이터 공유, 인증 만료, 비활성화 절차까지 같이 남깁니다.

실패 양상

여러 thread (작업 대화)가 같은 파일을 수정해 병합(merge) 비용이 커집니다.
클라우드 작업에 로컬에서만 가능한 검증을 맡깁니다.
automation (자동화)이 실패했는데 사람이 볼 받은함 항목이 없습니다.
Skill이 너무 넓어서 매번 다른 결과를 냅니다.

남길 증거

작업 이름과 실행 표면
소유 write scope (수정 범위)
실행한 검증
병합(merge) 또는 폐기 판단
자동화 실패 시 사람에게 보여줄 요약