현재 브랜치를 main과 비교해 병렬 검토해 주세요.
- security risk 담당 1명
- test gap 담당 1명
- maintainability 담당 1명
각자 파일 경로와 근거를 남기고, 모두 끝난 뒤 중복을 합쳐 심각도 순으로 요약해 주세요.

언제 분리하는가

subagent의 목적은 main thread가 요구사항·결정·최종 diff에 집중하도록 하고, 탐색 로그·test output·각 관점의 조사 결과를 별도 thread에서 처리하는 것입니다. 보안, 테스트 누락, 성능, 문서 불일치처럼 결과가 서로 독립적인 read-heavy 작업에 특히 잘 맞습니다.

분할 요청에는 담당 범위, 수정 권한, 종료 조건, 합성 형식을 적습니다. 단순히 “병렬로 해 주세요”라고만 하면 서로 같은 파일을 읽거나 같은 문제를 여러 번 보고할 수 있습니다. 결과는 파일 경로·근거·검증 방법·불확실성을 공통 형식으로 받아 main thread가 하나의 결론으로 합칩니다.

범위: packages/api의 인증 경로만 읽고 수정하지 않는다.
산출물: 심각도, file:line, 재현 조건, 필요한 test를 5개 이하로 정리한다.
종료: 다른 agent의 결과를 기다리지 않고 자신의 근거만 반환한다.

실행 표면과 제어

현재 local Codex는 app, interactive CLI, IDE chat에서 subagent workflow를 지원합니다. CLI에서는 /agent로 active agent thread를 전환하고 진행 중인 결과를 볼 수 있습니다. app과 IDE는 제공되는 background-agent UI에서 상태를 표시하거나 thread를 열 수 있지만, 표시·중지 control은 client 버전과 account access에 따라 다를 수 있습니다.

대부분의 intelligence level에서는 직접 위임 요청 또는 적용 지침이 필요합니다. 일부 higher-autonomy mode는 병렬 작업이 품질이나 속도에 이득일 때 선제 위임할 수 있으므로, “subagent를 쓰지 않는다” 또는 “읽기 전용 agent만 사용한다” 같은 제약도 AGENTS.md 또는 prompt에 명시합니다.

custom agent는 model, reasoning effort, instruction을 달리해 역할을 고정할 수 있습니다. 그러나 model pinning은 기본 선택을 제한하고, reasoning을 높일수록 token과 시간이 늘어납니다. 반복되는 triage에는 가벼운 read-only agent를, 모호한 cross-module 판단에는 더 깊은 reasoning agent를 배치합니다.

쓰기와 합성 경계

여러 agent가 수정할 때는 directory, module, 파일 중 하나를 ownership 경계로 나눕니다. 독립 diff여도 generated artifact, shared lockfile, config, migration은 충돌하기 쉬우므로 main thread 한 곳에서 통합·검증하는 편이 낫습니다. Git worktree는 격리된 구현을 병렬로 할 때 유용하지만, worktree를 만들었다고 자동으로 merge strategy나 test 책임이 생기지는 않습니다.