멀티에이전트 Q&A — 분할 경계·토폴로지·팬아웃, 그리고 제품 클론 22문답

에이전트를 쪼개는 결정은 되돌리기가 어렵다. 한번 나누면 라우팅 호출이 매 스텝 붙고, 상태 경계가 생기고, 실패 지점이 늘어난다. 그래서 "언제 쪼개는가"보다 **"쪼개지 않고 버틸 수 있는 조건이 무엇인가"**를 먼저 답할 수 있어야 한다.

이 글은 그 판정 기준과, 쪼갠 뒤에 반드시 따라오는 문제들 — 컨텍스트 오염·무한 루프·비용 증가 — 을 다룬다. 뒤쪽 절반은 실제 제품을 뜯어 다시 만들어 본 결과에서 나온 질문들이다.

프레임워크 선택은 기본기 Q&A, 상태·도구·체크포인터는 실행 모델 Q&A, 신뢰성·비용·안전·조직은 운영 Q&A에 있다.

토폴로지 비교

셋의 차이는 다음 순서를 누가 정하고, 끝을 누가 선언하는가에서 갈린다.

구현은 단일 에이전트의 경계와 토폴로지 3종 시리즈에 있다.

Q. 멀티에이전트는 언제 쓰나

단일로 안 되는 이유를 먼저 말할 수 있을 때만 쓴다.

기준은 도구 개수가 아니라 시스템 프롬프트의 충돌이다. 역할마다 지켜야 할 규칙·톤·금지사항이 달라지거나, 프롬프트에 "만약 A라면"이 세 개 이상 쌓이면 그건 이미 여러 에이전트다. 도구만 다르면 도구를 추가하지 에이전트를 늘리지 않는다.

대가가 분명하다.

호출만 늘어나는 것이 아니라 실패 지점도 그만큼 늘어난다.

Q. 에이전트를 몇 개까지 붙일 수 있나

숫자 상한이 아니라 토폴로지마다 무너지는 지점이 다르다.

Network는 연결 수가 제곱으로 늘어 23개에서 이미 통제가 어렵다. Supervisor는 워커가 늘수록 라우터 프롬프트가 비대해져 36개가 현실적이다. Hierarchical은 팀으로 묶어 흡수하므로 팀 2~4개까지 간다.

Q. Supervisor와 Network는 무엇이 다른가

종료 판정 주체다.

Supervisor는 종료를 선택지로 명문화하고 워커가 전원 복귀한다. Network는 아무도 "끝"이라고 말하지 않아 그래프가 닫히지 않는다. 실제로 대화형 멀티에이전트에서 가장 흔한 사고가 이것이다.

Q. 워커 결과를 왜 감싸나

발화자 이름을 남기고, 워커 출력이 관리자 자신의 발화로 오인되는 것을 막기 위해서다.

동시에 마지막 메시지 1개만 취해 컨텍스트를 압축한다. 감싸지 않으면 관리자가 자기가 한 말로 착각해 같은 작업을 다시 배정한다.

Q. Supervisor가 병목 아닌가

맞다. 매 스텝 라우팅 호출이 들어가고 입력이 누적돼 호출당 단가도 오른다.

그래서 라우터는 저가 모델을 쓰고, 순서가 정해진 결정적 구간은 고정 엣지로 뺀다. 대가와 완화책은 Supervisor 구현과 그 대가에 정리돼 있다.

Q. 멀티에이전트가 항상 나은가

아니다. 순서가 고정된 작업은 조건부 엣지 워크플로가 더 싸고 안정적이다.

관리자 없는 정적 파이프라인으로 충분한 경우가 많다. 실제 리포트 생성기가 그런 구조다 — 정적 팬아웃의 한계에서 그 구성과 한계를 함께 다룬다.

Q. 계층 구조에서 상태가 섞이는 문제는 어떻게 푸나

팀마다 별도 State 스키마를 두고 축소 → 확장 → 실행 → 축소 어댑터 3종으로 경계를 만든다.

대가는 정보 손실이다. 상위로 올라갈 때 팀 내부 사정이 잘리므로, 팀 요약을 명시적으로 남기지 않으면 관리자가 판단할 근거가 사라진다. 어댑터 구현은 Hierarchical 계층화에 있다.

Q. Send()가 조건부 엣지와 무엇이 다른가

조건부 엣지는 노드명 하나를 반환해 라우팅하고, Send()는 리스트를 반환해 팬아웃한다.

그리고 각 분기에 전용 payload를 준다. 전체 State에서 인덱스로 꺼내는 방식과 달리 개수 불일치가 생기지 않는다.

Q. Send()를 쓰면 다 해결되나

아니다. 실행 전 그래프 시각화에 분기가 안 보이고 디버깅이 어려워진다.

항목 수가 도메인상 고정이면 정적 팬아웃이 관측성 면에서 낫다. 가변인 경우에만 런타임 생성의 값이 비용을 넘는다. 두 방식의 전환 지점은 Send()로 런타임에 갈래를 만든다에 있다.

Q. 병렬화하면 비용도 주나

지연만 줄고 비용은 그대로다.

오히려 동시 호출로 레이트리밋에 빨리 닿아 세마포어 제한이 필요해진다. "병렬화했으니 싸졌다"는 잘못된 기대가 예산 계획을 어긋나게 만든다.

Q. 분기 하나가 실패하면 어떻게 하나

전체를 죽이지 않는다. 성공분으로 마감하되 어떤 분석이 빠졌는지 리포트에 명시한다.

실패를 감춘 그럴듯한 리포트가 가장 위험하다. 읽는 사람이 빠진 부분을 모른 채 결론을 신뢰하기 때문이다. 부분 실패 마감 설계는 값이 아니라 경로를 넘긴다에 있다.

Q. 선별 단계를 LLM에 맡길지 고정할지 어떻게 정하나

도메인의 목차 안정성으로 판단한다.

리포트 목차가 업계 표준으로 정해져 있으면 고정한다. 정해져 있지 않으면 LLM이 분해한다. 고정할 수 있는데 LLM에 맡기면 매번 다른 목차가 나와 비교가 불가능해진다.

Q. 출력 포맷은 어떻게 보장하나

용도로 나눈다.

전부를 스키마로 묶으면 문장이 딱딱해지고, 전부를 프롬프트에 맡기면 파싱이 깨진다.

Q. RAG 품질이 낮을 때 어떻게 접근하나

실패를 넷으로 분해한다. 개입 지점이 각각 다르기 때문이다.

"RAG가 안 좋아요"를 하나의 문제로 다루면 어디를 고쳐야 할지 정해지지 않는다.

Q. Agentic RAG에서 검색 필요 여부는 무엇이 판단하나

별도 분류기가 아니라 Tool description이다.

그래서 라우팅 개선 작업이 곧 도구 카탈로그 설계 작업이 된다. 프롬프트를 아무리 고쳐도 도구 설명이 모호하면 검색 여부 판단이 흔들린다. 구조는 판단하는 RAG 4종의 계보에 있다.

Q. Self-RAG와 CRAG는 무엇이 다른가

겨냥하는 실패가 다르다.

Self-RAG는 생성 결과를 의심해 루프를 만들고, CRAG는 지식 커버리지를 의심해 웹으로 보정한다. 하나는 만든 답을 다시 보고, 하나는 애초에 근거가 부족했다고 본다.

위 호출 횟수는 실측 벤치마크가 아니라 코드상 호출 경로를 센 값이다. 지연·비용 실측치는 별도로 재야 한다.

Q. 왜 Pydantic으로 출력을 강제하나

판정 결과가 그래프 경로를 결정하기 때문이다.

"not relevant"라는 문자열에 relevant가 포함되는 식의 오탐이 곧 라우팅 사고다. 문자열 파싱으로 분기하면 언젠가 엉뚱한 노드로 간다. Grader 설계 3요소는 Self-RAG 편에 있다.

Q. 네 변종 중 무엇을 고르나

질문 분포에 달렸다.

전부 붙이면 호출이 N+4회로 뛴다. 판정 하나를 더 붙일 때마다 지연과 비용이 함께 오른다는 점이 선택의 실질적 제약이다. 비교는 CRAG와 Adaptive RAG에 있다.

Q. 완성된 제품을 보고 아키텍처를 어떻게 추론하나

화면에서 관찰되는 것과 거기서 끌어낸 결론을 분리하는 것부터 시작한다.

예를 들어 "출처 목록이 본문보다 먼저 뜬다"는 관찰이고, "검색이 생성보다 선행한다"는 거기서 나온 추론이다. 둘을 섞어 쓰면 추정이 사실처럼 굳는다. 5단계 절차는 제품 화면에서 에이전트 그래프를 역추론한다에 있다.

Q. 클론을 만들었다면 구현 범위를 어떻게 긋나

어디까지 만들었고 어디를 비웠는지를 먼저 말한다.

역추론으로 얻는 것은 "그 관찰을 설명하는 구조 하나가 성립한다"까지다. 원 제품이 실제로 그렇게 만들어졌다는 증거는 아니다. 자기 구현의 출력은 자기 구현에 대한 근거일 뿐이다.

Q. 파일을 왜 여러 개로 쪼개나

변경 축이 다르기 때문이다.

워크플로·프롬프트·도구·UI가 각각 다른 이유로 바뀐다. 한 파일에 있으면 프롬프트 한 줄을 고치려다 그래프를 건드리게 된다. 나눠 두면 그래프 쪽만 떼어 API 서버로 재사용할 수 있다.

Q. 프레임워크 설정 오류는 어떻게 드러나나

조용히 무시되는 형태로 드러난다.

잘못된 인자명이 오타인데도 예외 없이 넘어가거나, 종료 조건이 없어 목표를 달성한 뒤에도 루프가 계속 도는 식이다. 설정을 검증하지 않는 프레임워크에서는 "동작한다"가 "의도대로 동작한다"를 뜻하지 않는다.

용어 정리

쪼개고 나면 비용과 실패가 함께 늘어난다. 환각을 어디까지 막을 수 있는지, 비용을 어디서 줄이는지, 실행 권한을 어디까지 줄 것인지, 그리고 이 모든 것이 조직에 무엇을 요구하는지는 운영 Q&A에서 다룬다.