서론

여러 AI CLI(Codex CLI, Gemini 계열 CLI, Claude 서브 에이전트)와 연계하는 멀티 에이전트 (Multi-agent) 구성으로 개발하다 보면, 다음과 같은 세 가지 과제에 직면하게 됩니다.

위임 대상의 고착화: 규칙에는 "분산시키라"고 적혀 있음에도, 실제 운용에서는 하나의 CLI(성능이 높고 익숙한 것)로 위임이 집중됨 -
편향을 인지할 메커니즘 부재: 집중되고 있다는 사실을 쿼터(Quota) 고갈이나 실행 시간 증가로 인해 사후에야 깨닫게 됨 -
규칙 문서와 실행 행동의 괴리: 규칙 문서에 적어두는 것만으로는 매 턴(Turn)의 행동이 바뀌지 않음

본 기사는 이러한 과제들을 「측정→설계→구현→검증」의 자기 개선 루프(Self-improvement loop)로 해결한 실화입니다. 여러 AI CLI나 서브 에이전트를 조합하여 개발하고 있는 분들을 위해, 실측값과 코드 예시를 바탕으로 위임의 편향을 가시화하고 시정하는 방법을 전달합니다.

실측: 편향을 수치화하기

먼저, 편향이 어느 정도인지 파악합니다. 위임 로그(JSONL 형식: 타임스탬프, 종류, 모델, 실행 시간)를 집계하는 것만으로도 진실이 보입니다.

최근 집계 결과:

위임 건수: 429건 중 Codex에 399건(93%)이 집중 -
실행 시간: Codex의 실행 시간은 주당 668분 (중앙값 258초/건) -
발견: 이 편향은 로그를 집계하고 나서야 비로소 가시화됨 (체감으로는 알 수 없었음)

로그가 있다면 다음과 같이 집계할 수 있습니다 (Python 의사 코드):

import json
from collections import defaultdict
def analyze_delegation(jsonl_file):
...

설계: 역할 기반의 분산 라우팅

"93% Codex 집중"이라는 편향이 발견되었다면, 다음은 "어떻게 분산시킬 것인가"에 대한 설계입니다.

라우팅(Routing)의 사고방식은 태스크의 특성과 필요한 리소스 품질을 분리하는 것입니다:

구현 계열: 제로 코스트 CLI(저가형·경량 모델)를 1차로 사용. 실패 시에만 경량 서브 에이전트, 마지막 수단으로 고가 CLI 사용 -
리뷰·감사: 고가 CLI + 상위 모델을 병렬로 사용. 의사결정을 서브 에이전트 스스로에게 맡기지 않음 (구현자≠리뷰어의 독립성 원칙) -
기계적 처리: 분류, 포맷팅, 패턴 탐지 → 최경량 모델

이 설계를 통해 쿼터를 「의사결정·감사」라는 정말 가치 높은 상황에 보존할 수 있으며, 일상적인 구현·조사는 경량 리소스로 충당할 수 있습니다.

구현: 매 턴 경고를 주입하는 모니터링 루프

설계를 "쓰는" 것만으로는 실행 행동이 바뀌지 않습니다. 매 턴 강제적으로 눈에 들어오는 메커니즘이 필요합니다.

포인트 1: 집계 스크립트와 매 턴 주입

집계 스크립트는 최근 7일을 JSONL로부터 집계하여, 하루에 한 번 캐시(Cache)하고, UserPromptSubmit 훅(사용자가 프롬프트를 보낼 때마다 발화)의 출력 끝에 한 줄을 주입합니다.

#!/bin/bash
# ~/.claude/scripts/check-delegation-balance.sh
CACHE="/tmp/delegation-balance-cache.txt"
...

포인트 2: 정수 연산으로 반올림 버그 방지

집계 로직에서 자주 발생하는 버그는 부동 소수점의 반올림 오차입니다.

# ❌ 버그 예시: 80.4% 에서는 경고가 나오지 않음
threshold = 80
ratio = count / total * 100
...

정수 연산을 사용하면 반올림 오차가 없고, 멀티 프로세스 환경에서도 안전합니다.

포인트 3: 파일 쓰기의 원자성

매 턴 읽히는 캐시 파일은 병렬 세션에서 손상되면 모든 턴에 파급됩니다. 원자적 교체(Atomic replacement)를 사용합니다.

#!/bin/bash
# 캐시의 안전한 업데이트
CACHE="/tmp/delegation-balance.txt"
...

mktemp로 신규 파일을 만들고, 쓰기가 완료된 후에 mv로 교체합니다. 이를 통해 읽는 도중의 손상이나 불완전한 캐시가 읽히는 일을 방지할 수 있습니다.

포인트 4: JSONL의 필드 결손과 타입 안정성

위임 로그의 JSONL 행에는 필드 결손이나 null이 혼재합니다.

# JSONL 행 파싱
with open(delegation_log) as f:
    for line in f:
        ...

row.get()과 or를 조합하면, 결손된 행에서도 크래시(crash) 없이 정확하게 집계할 수 있습니다.

빠지기 쉬운 함정 모음

구현과 운용 과정에서 마주쳤던 함정들을 공유합니다.

요약

위임의 편향을 시정하기 위해 취한 조치들을 정리합니다.

루프는 "만들고 끝"이 아니라, 경고가 줄어들지 않는다면 임계값(threshold)과 라우팅을 주 단위로 재검토하는 것이 중요합니다. 초기 설계가 완벽한 경우는 드물기 때문에, 측정 → 조정 → 측정이라는 반복이 지속 가능한 자동화의 핵심입니다.

멀티 에이전트(Multi-agent) 운용에서 "무엇을 측정할 것인가", "어떻게 유도할 것인가"라는 자기 개선 루프가 확립되면, 새로운 위임 대상의 추가나 역할의 재편을 시행착오 없이 진행할 수 있게 됩니다.

Discussion