Codex 서브에이전트 병렬 작업으로 코드리뷰 시간을 줄이는 분담 프롬프트 | DAKER 커뮤니티

코드리뷰 한 번에 보안, 테스트, 유지보수성, 로그 확인까지 모두 밀어 넣다 보면 프롬프트는 길어지고 정작 중요한 단서는 놓치기 쉬워집니다. 특히 검토 관점이 서로 다른데도 한 흐름에서 한꺼번에 처리하려 하면, 결과를 읽는 사람도 우선순위를 잡기 어려워집니다.

이럴 때 유용한 방식이 Codex 서브에이전트 병렬 작업입니다. 독립적인 탐색, 리뷰, 테스트 확인을 여러 에이전트에게 나누어 맡기고 마지막에 한 번에 합치는 방식입니다. 지금 코드리뷰나 장애 분석을 한 창에 모두 넣고 있다면, 먼저 나눌 일과 합칠 일을 구분해 보는 것이 좋습니다.

왜 코드리뷰 프롬프트가 길어질수록 놓치는 게 생길까요?

코드리뷰, 테스트 로그, 보안 점검, 유지보수성 검토를 한 번에 맡기면 Codex가 봐야 할 정보가 빠르게 많아집니다. 공식 매뉴얼 기준으로 서브에이전트는 이런 독립 작업을 병렬로 나누고, 메인 대화에는 요약 결과만 돌려보내는 데 적합합니다. 이 글은 2026년 7월 26일 KST에 OpenAI Codex 공식 매뉴얼과 DAKER 코덱스 최근 게시물을 확인한 뒤, 실무자가 바로 쓸 수 있는 분담 프롬프트만 정리한 내용입니다.

병렬화는 빨리 해 달라는 요청이 아니라, 서로 독립적인 질문을 나눠서 증거와 함께 가져와 달라는 요청에 가깝습니다.

기본 도구 루프가 아직 낯설다면 Codex 도구 사용법을 먼저 보고, 반복 규칙은 Codex AGENTS 파일 사용법으로 옮겨 두면 좋습니다.

Codex 서브에이전트는 언제 쓰면 좋을까요?

Codex 서브에이전트는 하위 작업이 서로 독립적일 때 가장 효과적입니다. 예를 들어 한 에이전트는 보안 위험을 보고, 다른 에이전트는 테스트 누락을 보고, 또 다른 에이전트는 유지보수성 문제를 보는 식입니다. 관점이 분리되어 있으면 결과를 병합하기도 수월합니다.

반대로 같은 파일을 동시에 고치는 쓰기 작업은 충돌이 생기기 쉽습니다. 그래서 처음에는 수정 작업보다 탐색과 리뷰에 먼저 쓰는 편이 안전합니다.

병렬 리뷰 프롬프트는 어떤 순서로 쓰면 될까요?

이 순서는 코드리뷰 자동화뿐 아니라 릴리스 전 점검, 테스트 실패 triage, 대규모 문서 검토에도 그대로 적용할 수 있습니다. 핵심은 하위 에이전트가 무엇을 보고 무엇을 돌려줘야 하는지 분명히 적는 데 있습니다.

먼저 작업을 독립적인 관점으로 나누면 됩니다. 보안, 테스트, 유지보수, 성능처럼 서로 다른 질문이면 병렬화하기 좋습니다. 그다음 각 에이전트에게 읽을 범위와 금지할 행동을 함께 줍니다. 예를 들어 수정은 하지 말고 위험만 파일 위치와 함께 보고하라고 적으면 결과가 훨씬 정돈됩니다.

반환 형식도 통일하는 것이 좋습니다. 심각도, 파일, 근거, 추천 조치 순서로 맞추면 메인 Codex가 중복을 합치고 충돌 의견을 표시하기 쉬워집니다. 수정이 필요할 때는 여러 에이전트가 동시에 쓰게 하기보다, 메인 흐름에서 우선순위를 정한 뒤 작은 패치로 진행하는 편이 관리하기 좋습니다. 마지막에는 테스트, 타입체크, 린트, 화면 확인 중 가장 작은 검증을 실행하고 결과를 남기게 하면 됩니다.

바로 붙여 넣어 쓸 수 있는 분담 프롬프트

다음 문장을 상황에 맞게 바꿔 쓰면 됩니다.

현재 브랜치를 리뷰해 주세요. 보안 위험, 테스트 누락, 유지보수성 문제를 각각 독립 서브에이전트로 나누어 확인하고, 모든 결과를 기다린 뒤 중복을 합쳐 심각도 순서로 보고해 주세요. 하위 에이전트는 코드를 수정하지 말고 파일 위치, 근거, 추천 조치만 남겨 주세요. 마지막에는 실제로 고칠 항목 3개와 먼저 실행할 검증 명령을 제안해 주세요.

이 예시는 병렬 실행 자체보다 책임 분리를 먼저 정합니다. 그래서 결과를 받은 뒤에도 사람이 무엇을 먼저 고칠지 판단하기 쉬워집니다.

서브에이전트를 많이 쓰기 전에 확인할 점

서브에이전트가 늘면 토큰과 시간이 늘 수 있으니, 독립적인 작업에만 쓰는 것이 좋습니다. 부모 작업의 sandbox와 승인 정책이 하위 작업에도 이어진다는 전제로, 쓰기 권한이 필요한 일은 분리해 두는 편이 안전합니다.

또 하위 에이전트에게 원본 로그 전체를 그대로 반환하게 하기보다 근거와 요약만 요구하는 편이 효율적입니다. 같은 파일을 동시에 수정하게 하지 말고, 탐색과 리뷰 결과를 먼저 합친 뒤 수정으로 넘어가면 충돌을 줄일 수 있습니다. 서브에이전트 결과가 서로 다를 때는 메인 Codex가 충돌 의견을 숨기지 말고 따로 표시하게 하면 됩니다.

공식 출처는 어디를 확인했나요?

작성 기준일에는 OpenAI Codex 공식 매뉴얼의 서브에이전트 워크플로, 모델·reasoning 선택, 승인과 sandbox 상속 설명을 확인했습니다. 이어서 볼 내부 링크는 코덱스 디렉터리, Codex Plan mode 사용법으로 정리했습니다.

자주 묻는 질문

Codex 서브에이전트는 항상 더 빠른가요?

항상 빠르지는 않습니다. 서로 독립적인 탐색이나 리뷰라면 빨라질 수 있지만, 같은 파일을 고치는 작업은 조율 비용이 더 커질 수 있습니다.

몇 개의 서브에이전트로 나누는 게 적당한가요?

처음에는 2~3개 관점으로 충분합니다. 보안, 테스트, 유지보수처럼 결과를 합치기 쉬운 관점부터 시작하면 됩니다.

서브에이전트에게 코드 수정을 맡겨도 되나요?

가능하지만 처음부터 병렬 수정으로 시작하지 않는 편이 안전합니다. 먼저 읽기와 리뷰를 나누고, 수정은 메인 흐름에서 작은 패치로 진행하는 방식이 관리하기 쉽습니다.

리뷰 결과가 서로 충돌하면 어떻게 해야 하나요?

충돌 의견은 실패가 아니라 좋은 신호입니다. 메인 Codex에게 같은 파일의 상반된 판단을 따로 묶고, 근거와 검증 방법을 비교하게 하면 됩니다.

지금 진행 중인 리뷰가 있다면 보안, 테스트, 유지보수 세 관점으로만 나눠 본 뒤 어떤 차이가 생기는지 살펴보면 어떨까요?