서브에이전트 리뷰는 왜 작업을 멈추게 할까

서브에이전트를 여러 개 띄우면 일이 빨라질 것 같다. 한 에이전트는 요구사항을 검토하고, 다른 에이전트는 테스트 편향을 찾고, 또 다른 에이전트는 구현을 확인한다. 각 결과를 합치면 더 안전한 작업이 될 것처럼 보인다.

그런데 실제로는 리뷰 시스템이 본 작업보다 커질 수 있다.

이 글은 AI 코딩 프레임워크 비교 실험을 준비하다가 6시간 36분 동안 리뷰만 반복하고, 정작 본 실험은 한 번도 실행하지 못했던 사례를 기록한 회고다. 확인 가능한 서브에이전트 세션은 최소 14개였고, 설계와 관련 문서·코드는 4,876줄까지 늘었다. 설계 동결 또는 READY 선언은 네 번 기록됐고, 그 과정에서 검토 범위는 여러 차례 다시 넓어졌다.

결론은 “서브에이전트를 쓰지 말자”가 아니다. 문제는 서브에이전트 수가 아니라 전체 목표와 종료 권한을 가진 조정자가 없었다는 것이었다. 각 리뷰어는 자기 범위에서 타당한 문제를 찾았지만, 아무도 “이제 본 작업을 실행할 만큼 충분하다”고 결정하지 않았다.

바로 적용할 원칙은 네 가지다.

1. 다른 작업의 결정을 계속 읽어야 한다면 독립 작업으로 분리하지 않는다.
2. 전체 작업에 벽시계 시간·리뷰 횟수·재위임 깊이 예산을 먼저 둔다.
3. 새 지적을 차단 이슈(blocker), 개선 사항, 후속 작업으로 분류한다.
4. 최종 완료 산출물과 종료 권한을 한 명의 조정자에게 둔다.

원래 하려던 일

목표는 AI 코딩 프레임워크 비교 실험을 위한 작업 풀을 만드는 것이었다. 공개 저장소의 실제 이슈를 골라 순정 Codex, 짧은 지시를 추가한 Codex, 여러 코딩 프레임워크를 같은 조건에서 비교하려 했다. 실행 전에 과제의 답변 가능성, 공개 테스트의 재현성, 채점기의 편향, 비공개 검증 경계를 확인해야 했다.

이런 검토 자체는 필요했다. 문제는 검토의 완료 조건이 작업 풀보다 늦게 정의됐다는 점이다. 처음에는 “에이전트가 풀 수 있고, 공개 테스트가 빠르게 통과하는 과제”면 충분해 보였다. 이후 리뷰가 진행되면서 다음 기준이 차례로 추가됐다.

• 원래 이슈와 해결 패치의 출처가 정확히 분리되어 있는가
• 에이전트에게 정답 구현의 단서가 새어 나가지 않는가
• 공개 프롬프트와 비공개 검증기가 같은 행동 계약을 측정하는가
• 특정 파일 경로나 심볼 이름을 강제하지 않고도 동작을 검증하는가
• 질문이 구현 전에 나왔는지, 답변이 코드 변경보다 앞섰는가
• 서로 다른 구현도 통과할 만큼 검증기가 편향되지 않았는가

각 기준은 합리적이었다. 그래서 더 위험했다. 기준 하나를 추가할 때마다 작업 풀의 품질은 국소적으로 좋아졌지만, 본 실험을 시작해야 한다는 전역 목표는 뒤로 밀렸다.

아래 기록은 비공개 연구 로그와 Git 시간 기록을 익명화해 재구성했다. 세션명, 로컬 경로, 비공개 검증기와 오라클 답변은 공개하지 않는다. 원인 분석은 이 한 사례에서 도출한 해석이지, 특정 제품의 일반적인 실패율이 아니다.

6시간 36분의 타임라인

“동결”은 실제로는 “현재 검토 범위에서 더 큰 blocker가 없다”는 뜻이었다. 새 리뷰어는 동결을 다시 열 수 있었고, 새 검토 범위도 제안할 수 있었다. 그래서 동결은 종료선이 아니라 다음 리뷰를 위한 중간 표지판이 됐다.

각 리뷰는 맞았는데 전체는 실패했다

1. 국소 최적화와 전역 목표가 달랐다

로그를 돌아보면 리뷰어에게 주어진 국소 목표는 문제를 찾는 일이었다. 전체 작업의 목표는 실험을 실행하고 결과를 기록하는 일이었다. 두 목표 사이에 우선순위가 없었다.

리뷰어가 “이 검증기는 특정 구현을 선호할 수 있다”고 말하면 그 지적은 맞다. 그러나 그 지적을 고치는 데 두 시간이 걸리면, 그만큼 최소 실험의 시작은 늦어진다. 우리는 전자의 품질만 세고 후자의 지연을 세지 않았다.

2. 완료의 정의가 진행 중에 움직였다

첫 동결 때의 완료 조건에는 이후 추가된 타이밍 검증이나 대안 구현 검사가 없었다. 새 검토에서 발견한 좋은 요구사항이 곧바로 필수 blocker로 승격됐다. 이전의 READY가 틀렸다고 단정할 수는 없지만, 무엇이 바뀌었는지와 왜 동결을 깨는지에 대한 변경 관리가 없었다.

3. 재위임에는 상한이 없었다

리뷰어가 문제를 찾으면 수정 에이전트가 작업하고, 수정된 결과를 다시 리뷰어가 읽었다. 그 리뷰에서 새 문제가 나오면 또 다른 리뷰가 시작됐다. 재위임 깊이, 최대 리뷰 횟수, 전체 작업 시간의 상한이 없으니 “한 번만 더 확인”이 끝없이 이어질 수 있었다.

4. 독립적이지 않은 작업을 분리했다

답변 가능성, 구현 편향, 검증기 동작은 서로 다른 관점이지만 같은 과제·같은 프롬프트·같은 채점 경계를 공유한다. 각 에이전트가 저장소와 문서를 처음부터 다시 읽으며 같은 맥락을 여러 번 요약했다. 독립 작업의 병렬화가 아니라 공유 상태의 분산 검토에 가까웠다.

5. 오류 비용이 한쪽으로만 기울었다

가능한 편향 하나를 놓치는 비용은 크게 보였지만, 본 실험을 하루 미루는 비용은 숫자로 기록하지 않았다. 그래서 안전을 위한 검토가 언제부터 과도한 지연이 되는지 비교할 수 없었다.

6. 산출물 증가는 진척으로 오인됐다

문서·검증기·리뷰 로그가 늘어났기 때문에 작업이 진전되는 느낌이 들었다. 실제로는 문서가 늘어나는 속도만 보고 있었다. 핵심 진척 지표인 “첫 실험 실행”은 0이었다. 산출물의 품질과 목표 달성에 가까워졌는지를 별도로 측정해야 했다.

7. 동결을 깨는 규칙이 없었다

새 지적이 나왔을 때 동결을 다시 열지, 다음 작업으로 미룰지 판단할 규칙이 없었다. 보안·데이터 유출·검증 불능처럼 동결을 깨야 하는 blocker와, 다음 버전에서 다룰 수 있는 개선 사항을 구분하지 않았다.

공식 문서가 말하는 서브에이전트의 경계

본문에서 인용한 공식 문서의 공통점은 “더 많이 분리하라”가 아니다. 독립적이고 범위가 정해진 작업을 분리하고, 공유 상태와 순차 추론에는 비용을 먼저 계산하라는 쪽에 가깝다.

OpenAI Codex 서브에이전트 문서와 Multi-agent 가이드는 코드베이스 탐색, 문서 비교, 독립 테스트처럼 경계가 분명한 작업에 병렬 위임이 유용하다고 설명한다. 각 서브에이전트가 별도의 모델·도구 작업을 수행하므로 토큰도 더 쓴다. 하나의 순차적 추론에 의존하거나 공유 상태를 자주 바꾸는 작업에서는 이점이 줄고, 결과를 우선순위별로 합치는 메인 에이전트의 역할이 중요해진다. OpenAI의 장기 작업 문서가 목표·제약·검증 기준을 함께 적으라고 권하는 이유도 여기에 있다.

Claude Code 공식 문서는 빠른 표적 수정, 잦은 상호작용, 여러 단계가 같은 맥락을 공유하는 작업은 메인 대화에 두라고 권한다. 반대로 대량 로그나 독립 조사처럼 요약만 돌아오면 되는 작업은 서브에이전트에 맞는다. 이 구분은 이번 사건을 설명하는 좋은 기준이다.

Anthropic의 컨텍스트 엔지니어링 글은 컨텍스트를 유한한 자원으로 다루고, 장기 실행 에이전트 하네스 글은 세션 사이에 진행 기록과 구조화된 산출물을 남기는 방식을 제시한다. 긴 작업에서 중요한 것은 에이전트를 계속 추가하는 일이 아니라 다음 작업자가 현재 상태와 남은 일을 오해하지 않게 만드는 것이다. 프리프린트 연구도 다중 에이전트의 이점이 작업 구조에 달려 있다고 보고한다. 이것은 코딩 프로젝트의 일반 법칙이 아니라, 조정 비용과 작업 구조를 함께 측정해야 한다는 보조 근거다.

예방: 위임 전에 계약을 만든다

서브에이전트를 부르기 전에 아래 질문에 답하지 못하면, 먼저 메인 에이전트에서 작업을 쪼개는 편이 낫다.

처음부터 모든 프로젝트에 같은 숫자를 강제할 필요는 없다. 다만 보수적인 시작점은 필요하다. 예를 들어 구현 1회와 독립 리뷰 1회를 기본으로 두고, 추가 리뷰는 “새로운 blocker가 직접 증거로 확인됐고 조정자가 승인한 경우”에만 허용할 수 있다. 예산이 끝나면 품질이 완벽해질 때까지 계속하는 것이 아니라, 남은 위험을 명시한 채 사람에게 판단을 돌려줘야 한다.

위임 계약 템플릿

목표: [한 문장으로 끝나는 작업]
허용 범위: [읽고 수정할 파일 또는 조사할 출처]
금지 범위: [새로운 기능, 다른 모듈, 새 리뷰 기준 추가 금지]
의존성: [반드시 알아야 하는 결정과 입력]
예산: [벽시계 시간] / [최대 상호작용] / [최대 재위임 깊이]
재위임: 허용하지 않음. 필요하면 blocker와 근거를 반환.
완료 산출물: [요약, 변경 파일, 테스트 명령과 결과]
중단 조건: 완료 산출물이 나오거나, 범위를 벗어난 문제를 발견하거나,
           예산을 다 쓰면 즉시 멈추고 조정자에게 반환.

감지: 루프가 과열되고 있다는 신호

다음 신호가 두세 개 함께 보이면 새 리뷰를 추가하기 전에 멈춰야 한다.

• 계획·리뷰 문서가 소스 diff보다 빠르게 늘어난다.
• 여러 에이전트가 같은 파일과 같은 테스트를 다시 읽는다.
• READY와 NOT READY가 반복되지만 원래 요구사항은 바뀌지 않았다.
• 핵심 지표인 첫 실행, 첫 패치, 첫 배포가 움직이지 않는다.
• 매번 새로운 리뷰 범위가 이전보다 넓어진다.
• 요약에는 새 작업만 있고 완료 판단은 없다.
• 결과를 받은 뒤에도 종료되지 않은 에이전트나 프로세스가 남아 있다.

이 신호는 에이전트가 실패했다는 뜻이 아니다. 오케스트레이션 비용이 본 작업보다 커지고 있다는 뜻이다.

특히 “끝날 때까지 계속”은 종료 조건이 아니라 반복 허가로 해석될 수 있다. 시간 상한, 최대 반복 수, 구현 diff가 없을 때의 중단, 사람에게 돌려줄 조건을 함께 적어야 한다.

이미 루프에 빠졌다면 이렇게 복구한다

1. 새 위임과 재검토를 중단한다. 먼저 추가 작업을 만들지 않는다.
2. 현재 상태를 목록화한다. 실행 중인 에이전트·프로세스·문서·미해결 지적을 적는다.
3. 원래 목표를 한 문장으로 다시 쓴다. 이번 경우에는 “작업 풀을 만들고 최소 검증을 통과한 뒤 실험을 실행한다”였다.
4. 지적을 세 종류로 분류한다. 지금 막으면 실험이 틀리는 blocker, 나중에 개선할 사항, 기록만 남길 후속 작업으로 나눈다.
5. 종료 책임자를 한 명 정한다. 새 리뷰어가 범위를 넓혀도 자동으로 따르지 않도록 한다.
6. 남은 blocker와 완료 산출물만 확인한다. 이미 통과한 축을 다시 검사하지 않는다.
7. 본 작업을 먼저 재개한다. 선택적 개선은 첫 실행·패치·배포 뒤에 별도 작업으로 연다.
8. 회고 규칙을 남긴다. 다음 위임 템플릿에 이번에 빠진 예산과 중단 조건을 추가한다.

여기서 “중단”은 결과를 지우라는 뜻이 아니다. 현재 로그와 유용한 산출물을 보존한 채 새 위임을 멈추고, 살아 있는 프로세스와 다시 사용 가능한 결과를 확인하라는 뜻이다.

리뷰 결과 템플릿

판정: READY | BLOCKED | READY WITH FOLLOW-UPS
이번 리뷰에서 직접 확인한 것:
- [파일/명령/출력]
Blocker:
- [없음 또는 실패를 재현하는 근거]
비차단 개선 사항:
- [다음 작업으로 미룰 수 있는 항목]
확인하지 못한 가정:
- [추가 검증이 필요한 내용]
추가 리뷰가 필요한가: 예/아니오
필요하다면, 새로운 blocker와 최대 검토 범위를 한 줄로 적는다.

조정자 중단 규칙

다음 중 하나면 리뷰 루프를 닫는다.

• 합의한 완료 산출물이 통과했다.
• 새 지적에 직접적인 blocker 증거가 없다.
• 최대 리뷰 횟수나 시간 예산에 도달했다.
• 다음 리뷰가 이미 확인한 축을 반복한다.
• 새 우려를 해결하는 비용이 그 위험 등급에 배정한 예산보다 크다.

메인 에이전트와 서브에이전트 선택표

OpenAI와 Claude Code의 문서가 공통으로 말하는 기준도 이 표와 비슷하다. 독립적인 조사·탐색·테스트·비교에는 서브에이전트를 고려하고, 순차적 추론·공유 파일·짧은 표적 수정에는 메인 에이전트를 우선한다. 여러 에이전트가 필요한 경우에도 root 또는 lead가 결과를 합치고 완료를 선언해야 한다.

자주 묻는 질문

서브에이전트는 몇 개까지 띄워야 하나?

고정된 정답은 없다. 먼저 독립적인 작업의 수를 세고, 각 결과를 합치는 데 드는 비용을 예상한다. 한 명의 에이전트가 순서대로 처리하는 것보다 병렬 실행과 컨텍스트 격리가 분명히 이득일 때만 늘린다. “많을수록 좋다”는 예산 계획이 아니다.

모든 구현에 독립 리뷰를 붙여야 하나?

작고 명확한 수정이라면 테스트와 사람의 빠른 확인으로 충분할 수 있다. 보안·데이터 마이그레이션·공개 API처럼 실패 비용이 큰 작업만 리뷰 예산을 높인다. 리뷰가 반복된다고 품질이 자동으로 증가하지는 않는다.

동결 뒤 새 문제가 나오면 어떻게 하나?

먼저 blocker인지 분류한다. 데이터 유출, 검증 불능, 실행 자체를 깨는 문제라면 동결을 깨고 수정한다. 표현 개선, 추가 사례, 더 넓은 분석처럼 본 작업을 막지 않는 항목은 후속 목록으로 보낸다. 동결을 깨는 권한을 모든 리뷰어에게 주면 동결은 사실상 존재하지 않는다.

이미 실행 중인 루프를 안전하게 멈추려면?

새 위임부터 막고, 살아 있는 에이전트와 프로세스를 확인한 뒤, 로그와 산출물을 보존한다. 그 다음 남은 blocker만 조정자가 재검증한다. 결과를 확인하지 않고 광범위하게 파일이나 작업 공간을 삭제하면 복구에 필요한 증거까지 사라질 수 있다.

결론

AI 코딩 프레임워크와 서브에이전트는 모델 위에 얹는 품질 보너스가 아니다. 특정 실패를 줄이기 위해 시간·컨텍스트·상호작용을 지불하는 제어 장치다.

이번 사례에서 가장 큰 문제는 리뷰어가 부족해서가 아니라, 모두가 문제를 찾을 수 있었고 아무도 전체 작업을 끝낼 수 없었다는 데 있었다. 다음에는 순서를 바꾼다. 먼저 원래 목표와 최소 완료 조건을 고정하고, 그 조건을 충족하는 독립 작업만 위임한다. 리뷰에는 예산을 주고, 새 지적의 등급을 나누고, 한 명의 조정자가 종료를 선언한다.

서브에이전트는 격리가 조정보다 큰 이득을 줄 때만 추가하고, 위임하기 전에 누가 일을 끝낼 수 있는지부터 정해야 한다.

출처 및 참고자료

공식 문서

• OpenAI Codex 서브에이전트 — 독립 작업, 컨텍스트 격리, 토큰 비용, 읽기 중심·쓰기 중심 작업의 구분
• OpenAI Multi-agent 가이드 — 독립 작업에 대한 병렬 위임과 순차 추론·공유 상태에서의 비용
• OpenAI Codex 장기 작업 — 결과·제약·검증 기준과 관련 작업의 컨텍스트 관리
• Claude Code 서브에이전트 — 메인 대화와 서브에이전트의 선택 기준
• Claude Code 병렬 에이전트 — 서브에이전트·에이전트 팀·worktree의 차이
• Anthropic: Effective context engineering for AI agents — 유한한 컨텍스트와 반복 루프의 정제
• Anthropic: Effective harnesses for long-running agents — 여러 세션 사이의 진행 기록과 구조화된 산출물

연구

• Towards a Science of Scaling Agent Systems — 작업 구조와 조정 방식에 따른 다중 에이전트 성능 차이