서브에이전트를 병렬로 늘리면 조사 속도는 빨라질 수 있습니다. 그런데 각 자식이 긴 최종 요약을 돌려주면, 일을 맡긴 부모의 대화 문맥이 결과를 받는 순간부터 좁아질 수 있습니다. 다섯 자식이 각각 5만 자를 반환한다면 부모는 판단을 시작하기도 전에 25만 자 가까운 텍스트를 떠안게 됩니다.
여기서 설계자는 불편한 선택을 만납니다. 자식 결과를 그대로 반환하면 정보는 온전히 보이지만 부모 문맥을 압박합니다. 짧게 자르면 부모는 계속 일할 수 있지만, 자식이 마지막에 적어 둔 결과·변경 파일·남은 문제를 잃을 수 있습니다. Hermes의 동결 구현은 둘 중 하나를 고르는 대신 부모에게 즉시 주입하는 분량과 가능하면 전체 결과를 보존하는 위치를 나눕니다.[1][2]
선택 전: 모든 최종 요약을 그대로 합치면 생기는 일
Hermes의 위임 기능은 서로 독립적인 작업을 격리된 서브에이전트에게 나눌 수 있게 합니다. 공식 문서는 하나의 작업뿐 아니라 여러 작업을 한 번에 위임하는 방식과 병렬 실행의 이점을 설명합니다.[1] 여기서 각 자식은 자기 문맥에서 조사하고, 최종적으로 부모가 사용할 요약을 반환합니다.
문제는 요약이라는 이름이 길이를 보장하지 않는다는 데 있습니다. 자식이 소스 분석, 코드 조각, 명령 결과, 파일 목록, 후속 제안을 모두 적으면 하나의 요약도 길어질 수 있습니다. 배치에서는 이 길이가 자식 수만큼 겹칩니다. 더구나 부모에게는 이미 사용자 대화, 시스템 지시, 도구 결과, 자신의 중간 판단이 들어 있습니다. 모델의 최대 문맥 크기만 보고 “아직 빈 칸이 많다”고 가정할 수 없습니다.
가능한 선택은 세 가지입니다.
첫째, 모든 요약을 원문 그대로 부모에게 넣는 방식입니다. 구현은 단순하지만 배치가 커질수록 부모 문맥을 예측하기 어렵습니다. 결과가 너무 커지면 즉시 압축이 필요해질 수 있고, 제공자 한도나 요청 실패와 맞물릴 수도 있습니다.
둘째, 각 요약을 고정 길이로 앞에서부터 자르는 방식입니다. 부모 문맥 사용량은 예측하기 쉬워집니다. 하지만 최종 결론과 변경 파일, 실패 이유는 요약의 끝에 놓이는 경우가 많습니다. 머리만 남기면 자식이 무엇을 했는지는 보이는데 무엇을 끝냈는지는 사라지는 역설이 생깁니다.
셋째, 부모의 현재 남은 여유에 맞춰 보이는 분량을 정하고, 잘린 전문은 디스크에 보존을 시도하는 방식입니다. Hermes는 이 세 번째 선택에 가깝습니다. 이 결정의 장점은 “모든 정보를 매번 문맥에 넣는 것”과 “정보를 폐기하지 않으려는 것”을 동일시하지 않는 데 있습니다.[2][3]
구현을 따라가면 먼저 유효한 문자열 요약만 모읍니다. 그다음 설정에 있는 정적 상한과 부모의 남은 문맥 여유에서 계산한 동적 예산을 구합니다. 둘 다 유효하다면 더 작은 값을 각 요약의 상한으로 사용합니다. 동적 예산은 부모에게 남은 여유를 배치의 요약 수로 나누기 때문에, 같은 길이의 자식 결과라도 부모 문맥이 이미 차 있거나 자식 수가 많으면 한 요약이 즉시 차지할 수 있는 분량은 줄어듭니다.[2]
상한을 넘은 요약은 단순히 앞부분만 남기지 않습니다. 구현은 대략 앞쪽 75%, 뒤쪽 25%의 창을 만들고 가능한 경우 줄 경계에 맞춥니다. 가운데가 생략됐다는 안내와 원래 길이를 붙이며, 전문 저장에 성공하면 전체 파일 위치와 read_file로 중간을 이어 읽는 방법을 꼬리말에 제공합니다. 결과에는 절단 여부와 전문 위치를 나타내는 메타데이터도 남습니다.[2]
앞부분에는 대개 접근 방법과 초기 근거가 있고, 뒷부분에는 완료 상태·산출물·문제점이 있다는 가정이 반영된 절충입니다. 그렇다고 75:25가 모든 작업에 최적이라는 뜻은 아닙니다. 중요한 정보가 가운데에 몰린 요약이라면 부모가 전문을 추가로 읽어야 합니다. 꼬리말의 파일 위치는 바로 그 후속 조회를 위한 손잡이입니다.
이 선택으로 바뀌는 것은 자식의 작업량이 아닙니다. 부모가 당장 보는 결과의 표현 방식입니다. 전문 저장에 성공하면 전체 내용은 파일로 보존되고 부모 문맥에는 앞·뒤와 조회 안내가 들어갑니다. 저장이 실패하면 부모에게 남는 것은 앞·뒤 창뿐이므로, 전문을 회수할 수 있다고 가정하면 안 됩니다. 따라서 절단 표시를 “자식 작업 실패”로 읽어서는 안 되지만, 전문 위치 기록과 파일 readback을 확인하기 전에는 전문 보존도 PASS가 아닙니다. 저장과 검토는 별개의 상태입니다.
안전한 최소 재현과 확인 범위
실제 제공자를 호출하지 않아도 예산 로직은 합성 fixture로 확인할 수 있습니다. 핵심은 자식 에이전트를 정말 다섯 개 실행하는 것이 아니라, 최종 결과와 같은 모양의 딕셔너리 다섯 개와 부모의 합성 문맥 상태를 만드는 것입니다.
- 외부 호출이 없는 임시
HERMES_HOME을 만듭니다. - 각 결과에 작업 식별 정보, 완료 상태, 5만 자가 넘는 최종 요약을 넣습니다.
- 요약 첫 줄에는
HEAD_MARKER, 마지막 줄에는TAIL_MARKER를 둡니다. - 합성 부모에 문맥 최대치, 현재 사용량, 응답 예약량을 지정합니다.
_apply_summary_budget을 호출합니다.- 각 결과에서 보이는 길이, 앞·뒤 표식, 절단 상태, 전문 파일, 전문과 원문이 같은지를 확인합니다.
공식 회귀 테스트만 실행한다면 다음과 같이 범위를 좁힐 수 있습니다.[3]
export HERMES_HOME="$(mktemp -d)"
python -m pytest -o 'addopts=' -q \
tests/tools/test_delegate_summary_budget.py
코드와 테스트가 정하는 기대 결과는 부모의 남은 문맥 여유와 배치 크기가 상한 계산에 반영되고, 상한 이하의 요약은 유지되며, 상한을 넘은 요약은 앞·뒤 창과 안내문으로 바뀌는 것입니다. 전문 저장에 성공하면 해당 파일을 다시 읽을 수 있어야 합니다. 단일 작업과 배치 작업 모두 최종 정리 단계에서 같은 예산 적용을 받습니다.[2][3]
이번 글의 합성 실험안에서는 문맥 최대치, 이미 사용한 양, 응답 예약량, 배치 수, 정적 상한을 고정한 뒤 결과 길이와 전문 파일 일치 여부를 비교할 수 있습니다. 그러나 이 글에는 합성 부모 상태, 다섯 입력 원문, 실행 명령, 정확한 출력 길이, 전문 파일 해시를 담은 공개 영수증이 없습니다. 따라서 특정 설정에서 모두 절단됐거나 부모 가시 문자열이 특정 길이였고 전문 파일이 원문과 같았다는 로컬 관찰값을 제시하지 않습니다.
코드 계약으로 말할 수 있는 것은 남은 문맥 여유와 배치 크기가 상한 계산에 관여하고, 상한을 넘는 요약이 앞·뒤 창과 안내문으로 바뀌며, 전문 저장에 성공한 경우 별도 파일로 회수할 수 있다는 범위입니다.[2][3] 실제 길이는 토큰 계산 방식, 모델 문맥 크기, 현재 사용량, 설정, 줄 경계와 안내문 경로 길이에 따라 달라질 수 있습니다. 이번 글에서는 실제 자식 실행, 문맥 압축, 제공자 요청도 측정하지 않았습니다.
이 결정은 “병렬 위임을 많이 해도 문맥 문제가 사라진다”는 보장이 아닙니다. 전문 파일도 디스크 공간과 보존 주기를 필요로 하고, 부모가 여러 전문을 모두 다시 읽으면 결국 문맥을 사용합니다. 요약 자체가 부실하면 앞·뒤를 잘 보존해도 판단 품질은 좋아지지 않습니다. 자식 수를 무제한으로 늘리는 근거로 삼을 수도 없습니다.
이번 글에서 직접 확인하지 못한 것은 다음과 같습니다.
- 실제 모델 다섯 개를 병렬 호출했을 때의 지연시간과 비용
- 예산 적용 전후 문맥 압축 횟수나 요청 실패율의 변화
- 수십·수백 개 자식이 반환될 때의 디스크 사용량과 정리 정책
- 여러 언어와 코드 블록이 섞인 요약에서 줄 경계 절단의 가독성
- 전문을 부모가 언제 자동 또는 수동으로 다시 읽는 것이 최적인지
그래서 이 설계의 가치는 “요약을 더 짧게 만든다”는 데만 있지 않습니다. 더 정확히는 부모가 지금 판단에 쓸 문맥과, 전문 저장에 성공한 경우 나중에 회수할 수 있는 전체 증거를 서로 다른 저장 층으로 분리한다는 결정입니다. 병렬 위임의 병목이 자식 실행 시간만이 아니라 부모의 결과 수용량에도 있다는 사실을 코드가 직접 다루는 방식입니다.
Sources
[1] Subagent Delegation — Hermes Agent 공식 문서
[2] 위임 실행과 요약 예산 구현
