병렬·클라우드 운영

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

이 문서를 읽으면

• cloud task, worktree, subagent를 언제 나눠 쓰는지 이해합니다.
• 병렬 작업에서 같은 파일을 동시에 건드리지 않게 합니다.
• automation과 skill을 만들기 전에 확인할 조건을 정합니다.

오늘 바로 해볼 일

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

나누어 맡기는 기준

단위	쓸 때	주의할 점
클라우드 작업	긴 분석, 비동기 구현, 환경 분리 작업, PR 후보 생성	로컬 비밀정보와 로컬 전용 검증을 넘기지 않음
worktree	같은 저장소에서 여러 diff를 병렬로 만들 때	write scope를 분리
subagent	좁은 조사나 보조 구현을 병렬로 맡길 때	명시적으로 요청하고, 토큰 비용과 승인 흐름을 감안
automation	반복 점검, 정기 리뷰, CI/이슈 follow-up	실패 시 사람이 볼 요약이 있어야 함
non-interactive/CI	codex exec나 GitHub Action으로 반복 작업을 파이프라인에 넣을 때	최소 권한, 좁은 프롬프트, 재검증 명령을 함께 둠
remote connection	모바일이나 다른 기기에서 연결된 host의 Codex를 이어서 제어할 때	실행 환경은 현재 기기가 아니라 연결된 host라는 점을 명확히 함
Skill	반복 절차가 명확할 때	입력, 출력, 검증 기준이 있어야 함
Plugin/MCP	외부 앱, 문서, 사내 도구와 연결할 때	연결 앱의 권한, 개인정보, 승인 정책을 따로 확인

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

• Codex app: thread, worktree, review, terminal action, in-app browser, Chrome extension, Computer Use, automation, skills, plugins를 한 운영 화면으로 모읍니다.
• Codex CLI: 로컬 TUI, 모델·추론 설정, 이미지 입력, 로컬 code review, subagent, web search, cloud task, MCP, approval mode를 터미널에서 다룹니다.
• IDE extension: 열린 파일과 선택 영역 맥락, 명령 팔레트, slash command, cloud delegation, cloud diff 적용까지 편집기 안에서 처리합니다.
• Codex web: GitHub 저장소와 연결해 cloud 환경에서 백그라운드 작업을 만들고, 인터넷 접근과 환경 설정을 제어합니다.
• Skills와 plugins: skill은 반복 절차의 작성 형식이고, plugin은 skill, app integration, MCP server를 묶어 설치하는 배포 단위입니다.

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

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

• codex exec는 CI, pre-merge check, scheduled job처럼 대화형 TUI가 필요 없는 반복 실행에 둡니다.
• CI에서 자동 수정까지 허용한다면 실패 commit 확인, 의존성 설치, 좁은 프롬프트, 최소 sandbox 권한, 테스트 재실행, PR 생성 순서로 닫습니다.
• GitHub Action은 CLI 설치와 실행을 workflow 안에 넣는 방식이므로, workflow 권한과 secret 노출 범위를 PR 리뷰 대상에 포함합니다.
• remote connection은 휴대폰이나 다른 기기에서 지시를 보내더라도 파일, 명령, plugin, MCP, browser, Computer Use는 연결된 host 설정을 따릅니다.
• 연결된 host가 로그인된 웹사이트나 사내 도구에 접근할 수 있다면, 그 접근은 별도 승인선과 감사 대상으로 봅니다.

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

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

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

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

병렬 작업의 안전선

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

실패 양상

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

남길 증거

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

공식 문서

• Codex app
• Codex Web
• Codex Workflows
• Non-interactive mode
• Codex GitHub Action
• Remote connections
• Agent Skills
• Plugins
• Model Context Protocol
• Subagents
• Codex use cases