병렬·클라우드 운영

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

이 문서를 읽으면

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

오늘 바로 해볼 일

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

나누어 맡기는 기준

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

병렬 작업 보드

긴 목표를 여러 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 (보조 에이전트 및 /agent 전환, codex agents 대시보드), TUI 디렉토리 이동(/cd, /pwd), 세션 간 메시지 큐잉(codex queue), 웹 검색, cloud task (클라우드 작업), MCP, approval mode (승인 모드), remote-control을 터미널에서 다룹니다.
IDE extension: 열린 파일과 선택 영역 맥락, 명령 팔레트, slash command, cloud delegation, goal mode, 클라우드 변경점(cloud diff) 적용까지 편집기 안에서 처리합니다.
Codex web / cloud: GitHub 및 GitLab (Beta) 저장소와 연결해 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만 배포하는 흐름으로 다룹니다. (팀원 초대 공동 편집 및 도메인 재배포 없는 URL 변경 지원)

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

반복 작업을 자동화할 때는 “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, 임시 파일, 외부 상태 변경을 회수하는 절차가 있습니다.

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

Subagent(서브에이전트) 격리와 컨텍스트 관리

최신 Codex 릴리즈에서는 병렬 서브에이전트 워크플로우가 기본으로 활성화(Enabled by default)되어 있습니다. 모델의 컨텍스트 창이 커졌더라도, 탐색 메모, 긴 테스트 출력, 중간 스택 트레이스를 메인 대화창에 쏟아부으면 다음 두 가지 문제가 발생합니다:

컨텍스트 오염(Context Pollution): 본래 요구사항, 제약조건, 핵심 아키텍처 결정이 방대한 중간 디버깅 로그 속에 파묻힙니다.
컨텍스트 부패(Context Rot): 대화가 길어지고 덜 중요한 정보가 누적될수록 모델의 추론 일관성과 작업 지시 준수 능력이 떨어집니다.

서브에이전트 분리 원칙

graph TD
    M["🧠 메인 에이전트 (Main Thread)<br/>- 요구사항 및 제약조건 집중<br/>- 설계 및 아키텍처 결정<br/>- 최종 결과물 및 Handoff 종합"]
    
    M -->|"1. 독립 조사 위임"| S1["🔍 서브에이전트 A (탐색)<br/>대규모 코드베이스 흐름 분석"]
    M -->|"2. 테스트 위임"| S2["🧪 서브에이전트 B (검증)<br/>단위 테스트 실행 및 로그 분석"]
    M -->|"3. 트리아지 위임"| S3["📋 서브에이전트 C (요약)<br/>외부 문서 및 이슈 대조"]
    
    S1 -->|"정제된 요약 반환"| M
    S2 -->|"통과/실패 핵심만 반환"| M
    S3 -->|"핵심 변경점 요약 반환"| M

    style M fill:#157048,stroke:#0c3a25,stroke-width:2px,color:#ffffff
    style S1 fill:#eaf1eb,stroke:#157048,stroke-width:1.5px
    style S2 fill:#eaf1eb,stroke:#157048,stroke-width:1.5px
    style S3 fill:#eaf1eb,stroke:#157048,stroke-width:1.5px

읽기 중심(Read-heavy) 작업 우선 위임: 저장소 탐색, 실패 로그 분석, 문서 대조, 이슈 트리아지 같은 읽기 작업은 서브에이전트에 위임하기에 최적입니다.
쓰기 중심(Write-heavy) 작업 분리 주의: 여러 서브에이전트가 동시에 동일한 파일이나 인접 모듈을 수정하게 하면 Git 충돌과 조정 비용이 급증합니다. 쓰기 작업은 단일 스레드가 순차 소유하거나 명확히 분리된 worktree(작업 책상)로 격리해야 합니다.
제어 표면:
- TUI (CLI): /agent 명령을 입력해 백그라운드에서 동작 중인 서브에이전트 스레드를 검사하고 즉시 전환합니다. 대화형 codex agents 대시보드를 통해 여러 작업을 검색, 전환, 중단할 수 있습니다.
- IDE extension: 입력창 상단에 백그라운드 에이전트 패널이 표시되며, 상태 확인 및 개별 스레드 열람/전체 중단이 가능합니다.
- ChatGPT Desktop: 서브에이전트별 별도 스레드가 표시되며, 최종적으로 메인 창에 축약된 결과만 취합됩니다.

병렬 작업의 안전선

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

실패 양상

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

남길 증거

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

병렬 작업 요청 템플릿

아래 템플릿을 그대로 복사해 새 thread (작업 대화)나 작업 요청서 상단에 붙여넣으면 병렬 실행을 안전하게 시작할 수 있습니다.

# 병렬 작업 시작 요청

## 목표 (goal)
[이 작업 전체에서 달성하려는 것 한 줄]

## 이번 thread의 역할 (role)
[조사 전용 / 로컬 패치 전용 / 리뷰 전용 / 배포 확인 전용 중 하나]

## write scope (수정 범위)
허용: [수정해도 되는 파일 또는 디렉터리 경로]
금지: [절대 건드리지 말아야 할 파일]

## 다른 thread와 겹치지 말아야 할 파일
[이미 다른 작업이 소유한 파일 목록]

## 완료 증거 (done criteria)
- [ ] [기대하는 출력 1]
- [ ] [기대하는 출력 2]

## 승인이 필요한 행동
[패키지 설치 / 네트워크 접근 / lockfile 변경 등]

## 멈출 조건
[이 조건이 발생하면 즉시 멈추고 보고]

사용 예: 기능 추가 작업을 세 thread로 나눈다면, 첫 thread에는 역할: 조사 전용, write scope: 없음을 적고, 두 번째에는 역할: 로컬 패치, write scope: src/checkout/** 와 tests/checkout/**를 적습니다. 세 번째에는 역할: PR 리뷰, write scope: 없음을 넣어 서로 write scope가 겹치지 않게 합니다.

실전 예시: 결제 기능 추가를 세 표면으로 나누기

시나리오

“결제 흐름에 쿠폰 할인 로직을 추가하고 싶다. 기존 checkout 코드를 먼저 이해한 뒤, 수정 범위를 확정하고, 실제 패치를 만들어야 한다.”

이 작업을 하나의 대화에서 처음부터 끝까지 처리하면 조사→수정→리뷰가 뒤섞여 어디서 문제가 생겼는지 좁히기 어렵습니다. 세 표면으로 나눠 관리하면 각 단계의 결과물이 다음 단계의 입력이 됩니다.

1단계 — 클라우드 작업으로 조사

실행 표면: Codex Web (cloud task) write scope: 없음 (읽기 전용)

# 클라우드 조사 요청

목표: 쿠폰 할인 로직을 추가하기 위한 코드 흐름 지도 작성
역할: 읽기 전용 조사 전용
write scope: 없음 (파일 수정 금지)

조사할 것:
1. src/checkout/ 안에서 금액 계산이 일어나는 함수와 파일
2. 현재 할인 관련 타입이나 DTO가 있는지
3. 연결된 테스트 파일 목록
4. 수정 시 영향받을 수 있는 파일 (범위 추정)

완료 증거:
- 함수 호출 흐름도 (텍스트 또는 mermaid)
- 수정 후보 파일 목록 (최대 5개)
- 리스크 항목 (lockfile 변경 필요 여부, 외부 API 연관 여부)

멈출 조건: 파일 수정이 필요하다고 판단되면 즉시 멈추고 보고

클라우드 작업을 쓰는 이유: 이 단계는 수정 없이 저장소 전체를 넓게 읽어야 합니다. 로컬 환경을 점유하지 않으면서 긴 조사를 백그라운드로 돌릴 수 있고, 조사 결과가 명확한 파일 목록으로 좁혀지면 다음 단계 입력으로 바로 씁니다.

2단계 — worktree로 로컬 패치

실행 표면: CLI worktree (coupon-discount 브랜치) write scope: src/checkout/, tests/checkout/

# 로컬 패치 요청 (worktree: coupon-discount)

목표: 쿠폰 할인 로직 추가
역할: 로컬 패치 전용
write scope:
  허용: src/checkout/**, tests/checkout/**
  금지: package.json, package-lock.json, src/payment/**, .env*

이전 단계 결과:
- 수정 대상 파일: [1단계 조사 결과 붙여넣기]
- 리스크 항목: [1단계 조사 결과 붙여넣기]

구현할 것:
- OrderTotal 계산 함수에 couponCode 파라미터 추가
- 할인율 적용 및 최소 금액 보정 로직
- 기존 테스트가 깨지지 않는 선에서 새 테스트 케이스 추가

승인 필요: 패키지 설치, 네트워크 접근, lockfile 변경
금지: 테스트 삭제, 보안 설정 완화

완료 증거:
- [ ] 변경된 파일 목록과 diff 요약
- [ ] npm test 또는 pytest 결과 (통과)
- [ ] 수정 범위 밖 파일이 변경되지 않음

멈출 조건: 결제 외부 sandbox 인증이 필요하거나 package.json 수정이 필요하면 즉시 멈추고 보고

worktree를 쓰는 이유: 메인 브랜치(main)와 분리된 브랜치에서 작업하므로 조사 thread가 아직 열려 있어도 충돌이 없습니다. 수정 범위를 src/checkout/으로 좁히면 결제 모듈(src/payment/)을 다루는 다른 worktree와 write scope가 겹치지 않습니다.

3단계 — 리뷰 thread로 병합 전 확인

실행 표면: Codex app 리뷰 write scope: 없음

# PR 리뷰 요청

목표: coupon-discount 브랜치 병합 전 최종 확인
역할: 리뷰 전용 (파일 수정 금지)

확인할 것:
1. write scope 밖 파일이 변경되지 않았는지
2. 테스트가 삭제되지 않았는지
3. 새 테스트가 엣지케이스(음수 금액, 쿠폰 중복 적용)를 다루는지
4. 외부 API나 secret 관련 코드가 들어갔는지
5. blocker / follow-up 분리

완료 증거:
- blocker 목록 (있으면 수정 후 재요청)
- follow-up 목록 (다음 이슈로 넘길 것)
- "병합 가능" 또는 "재작업 필요" 결론

세 단계 요약

단계	표면	write scope	주요 결과물
1. 조사	클라우드 작업	없음	파일 흐름도, 수정 후보 목록
2. 패치	CLI worktree	`src/checkout/`, `tests/checkout/`	diff, 테스트 결과
3. 리뷰	Codex app 리뷰	없음	blocker/follow-up, 병합 판단

실행 표면 선택 기준 (이유 포함)

표만 보면 “상황에 맞게 쓰면 된다”는 말과 다르지 않습니다. 아래는 각 표면을 선택하는 이유와 선택하지 말아야 할 시점을 함께 적은 기준입니다.

클라우드 작업을 쓸 때

선택 이유: 로컬 환경을 점유하지 않고 긴 분석이나 PR 후보 생성을 백그라운드로 돌릴 수 있습니다. 저장소 전체를 넓게 읽는 조사, 다른 브랜치와 비교, 여러 파일에 걸친 리팩터링 계획처럼 “로컬이 아니어도 되는” 작업이 적합합니다.

이때는 쓰지 마세요: 로컬에서만 재현되는 버그, 브라우저 로그인이 필요한 확인, 사내망 접근이 필요한 작업. 클라우드 환경은 기본적으로 인터넷이 꺼진 격리 환경이라 로컬 전용 검증을 맡기면 조용히 실패하거나 틀린 결론이 나옵니다.

worktree를 쓸 때

선택 이유: 같은 저장소에서 두 가지 이상의 diff를 동시에 만들어야 할 때 브랜치 전환 없이 각 작업이 독립적인 write scope를 가질 수 있습니다. 예를 들어 main에서 긴급 버그 수정과 신규 기능 개발을 동시에 진행할 때, 두 worktree가 서로 다른 파일 영역을 소유하면 충돌 없이 병렬 작업이 가능합니다.

이때는 쓰지 마세요: 두 worktree가 같은 파일(예: package.json, schema.prisma)을 모두 수정해야 하는 경우. 이 상황은 병렬이 아니라 충돌입니다. 먼저 한 작업이 끝나고 나머지 작업이 그 결과 위에서 시작해야 합니다.

goal mode를 쓸 때

선택 이유: 단일 대화 안에서 “목표에 도달할 때까지 계속 작업”이 필요할 때 씁니다. 테스트가 통과할 때까지 수정을 반복하거나, 여러 파일에 걸친 리팩터링을 단계별로 완료해야 할 때 중간 보고와 완료 기준을 고정해두면 방향을 잃지 않습니다.

이때는 쓰지 마세요: 목표가 추상적이거나 완료 기준이 없는 경우. “최대한 좋게 만들어줘”처럼 끝이 없는 목표는 goal mode를 거는 순간 토큰과 시간 소모만 늘어납니다. 완료 기준을 먼저 측정 가능한 형태로 만든 뒤 goal mode를 겁니다.

subagent를 쓸 때

선택 이유: 좁고 독립적인 조사나 보조 구현을 병렬로 처리해야 할 때 씁니다. 예를 들어 같은 API의 Python 예시와 TypeScript 예시를 동시에 작성해야 할 때, 두 subagent가 각각 다른 언어 버전을 만들면 부모 작업이 기다리는 동안 두 결과를 동시에 받을 수 있습니다.

이때는 쓰지 마세요: 부모 작업이 subagent 결과를 즉시 기다려야 하는 경우. subagent가 끝나기 전에 부모 작업도 멈춰야 한다면, 직접 처리하는 것보다 복잡도만 올라갑니다. 또한 subagent는 토큰 비용이 별도로 발생하므로 단순한 보조 작업에는 직접 처리가 낫습니다.

automation을 쓸 때

선택 이유: 사람이 매번 보지 않아도 되는 반복 점검(링크 검사, 번역 일관성 확인, 의존성 취약점 스캔)을 정해진 시점에 실행해야 할 때 씁니다. 실패 시 사람이 볼 요약이 자동으로 생성되어야 automation이 의미가 있습니다.

이때는 쓰지 마세요: 실패 시 원인을 좁힐 수 없거나, 사람이 볼 받은함 항목이 없는 경우. 알림만 쌓이는 automation은 팀이 무시하기 시작하면 오히려 위험 신호를 덮습니다.