세션 수십 개 병렬, 그 실익을 둘러싼 논쟁

새벽 1시 28분, 병렬로 세션을 몇십 개씩 돌리는 이유를 캐묻는 질문 하나가 방 안 분위기를 갈랐다.

관찰 — 병렬의 비용을 묻다

"궁금한게 세션/서브에이전트 몇십개씩 병렬로 왜 돌리는 겁니까"라는 질문에 "많아질수록 fan out fan in 하는 비용이 한계 체감하지 않나요"라는 반문이 곧바로 붙었다. 여러 세션을 동시에 돌리는 방식 자체를 문제 삼기보다, 그 규모가 커질수록 관리 비용이 어디까지 늘어나는지를 짚는 질문이었다. 워크트리를 나눠도 "나중에 머지할 때 충돌하는 지점에 대한 처리 복잡도가 지수적으로 상승할거같은데"라는 우려도 곧이어 이어졌다.

관찰 — 하네스 구성이 핵심이라는 반론

"머지시 상승하는게 맞합니다. 그렇게 안나게 하네스 구성하게 제일중요한거고 최적화 잘하는게 결국 실력이죠 제생각이지만 단일로 구성해도 별차이 없다 판단했고 결국은 충돌날꺼라면 빠르게 해서 여러번 점검해버리는걸 선호하기에 이런식을 선호합니다."

한 참여자는 이렇게 답하며 병렬 자체보다 하네스 설계가 관건이라는 입장을 밝혔다. 충돌 복잡도가 오른다는 지적 자체는 인정하면서도, 그걸 줄이는 하네스 구성 능력이 실력을 가르는 지점이라는 반박이었다. 단일 세션으로 구성해도 결과에 큰 차이가 없다고 판단했다는 대목은, 병렬 규모 자체보다 점검 주기를 짧게 가져가는 쪽을 우선한다는 뜻으로 읽힌다.

해석 — 정작 실사용 규모는 크지 않다

정작 실사용 규모를 공개한 참여자는 "목욜 강의 관련한 캡쳐를 들고 왔는데(llm wiki + 위키 활용 멀티에이전트) 저도 에이전트는 진짜 천천히 늘리고 있고 현재는 7개 만들고 2 ~ 3개로 작업 동시에 굴리는 게 다에요(에이전트끼리 저렇게 회의하고 각자 역할정도만 크게크게 다름)"라고 밝혔다. 몇십 개 병렬이 화두에 오른 것과 달리 실제 운용은 소수의 에이전트를 신중하게 늘려가는 쪽에 가깝다는 것을 시사한다.

앞서 오간 fan-out·머지 비용 논쟁이 이론적인 상한을 두고 벌어진 데 비해, 정작 공개된 실사용 규모는 에이전트 7개에 동시 작업 2 ~ 3개로 훨씬 소박했다. 화두와 실전 사이의 이 거리는, 병렬 규모를 키우는 것보다 각 에이전트의 역할을 명확히 나누는 쪽이 실제 운용에서는 더 앞선 고려사항일 수 있다는 것을 보여준다.