에이전트 병목은 모델 아닌 데이터 이동

에이전트 워크플로가 느린 진짜 이유가 대형 언어 모델의 추론 속도가 아니라 데이터가 오가는 방식에 있다는 연구 결과가 나왔다. 미국 연구진 6명이 발표한 논문 AAFLOW는 에이전트 파이프라인의 데이터 처리 구조를 바꾸는 것만으로 전체 처리 속도를 최대 4.64배 끌어올렸다고 보고했다. 5월 4일 아카이브(arXiv)에 등록된 10쪽 분량 사전 공개본이며 고성능컴퓨팅 학회 SC2026 제출본이다.

무슨 일인가

연구진의 문제의식은 현장 경험과 맞닿아 있다. 지금의 에이전트 프레임워크는 검색과 추론, 기억을 한데 묶어 주지만 데이터 조율이 여기저기 흩어져 있고, 단계마다 데이터를 직렬화했다가 다시 풀어내는 비용이 붙으며, 실행 결과가 매번 달라져 재현이 어렵다는 것이다. 유연성은 늘었지만 고성능컴퓨팅 관점의 형식적 실행 모델이 없다는 지적이다.

해법으로 제시된 것이 통합 분산 런타임이다. 에이전트 워크플로를 연산자 추상화로 모델링해 통신 효율이 높은 실행 계획을 미리 만든다. 데이터 처리에는 아파치 애로우(Apache Arrow)와 사일런(Cylon)을 써서 복사 없는 데이터 평면을 구성했고, 전처리와 임베딩, 벡터 검색이 직렬화 과정 없이 서로 데이터를 주고받는다. 여기에 자원 사용이 예측 가능한 스케줄링과 비동기 일괄 처리를 더해 조율 비용을 낮췄다.

핵심 짚어보기

측정 결과가 이 논문의 요점이다. 전체 파이프라인은 최대 4.64배, 임베딩과 벡터 저장 단계는 2.8배 빨라졌다. 반면 언어 모델이 답을 생성하는 처리량 자체는 기존과 비슷한 수준을 유지했다. 즉 속도 향상은 모델을 더 빠르게 돌려서가 아니라, 데이터 흐름과 일괄 처리, 통신 효율을 개선해서 얻어졌다는 뜻이다.

이 구분은 실무자에게 특히 중요하다. 자동화가 느릴 때 대부분은 더 빠른 모델이나 더 큰 장비를 먼저 떠올린다. 그러나 이 연구가 가리키는 지점은 정반대다. 모델 호출 사이사이에 끼어 있는 파일 읽기, 형식 변환, 저장, 재조회가 전체 시간을 먹고 있을 가능성이 크다.

1인기업 실전 적용 포인트

• 자동화 스크립트에 단계별 시간 측정부터 넣어 보자. 수집·정제·임베딩·모델 호출·저장 다섯 구간의 소요 시간을 로그로 남기면, 대개 모델 호출이 아닌 다른 구간이 범인으로 드러난다.
• 임베딩과 벡터 저장은 건건이 호출하지 말고 일괄 처리로 묶는다. 논문에서 가장 큰 개선이 나온 구간이 바로 여기이며, 문서 100건을 한 번에 처리하는 방식만으로도 체감 차이가 크다.
• 단계 사이에 JSON 파일을 매번 쓰고 다시 읽는 구조라면 파케이(Parquet)나 애로우 형식으로 바꾸는 것을 검토할 만하다. 수천 건 이상을 다루기 시작하면 형식 변환 비용이 무시할 수 없는 크기가 된다.
• 실행 결과가 매번 달라 재현이 안 되는 파이프라인은 개선 자체가 불가능하다. 입력·중간 산출물·출력을 날짜별로 남기는 습관이 성능 개선의 전제 조건이다.

전망 / 주의점

다만 이 연구는 고성능컴퓨팅 환경을 전제로 한 사전 공개본이고 아직 동료 심사를 거치지 않았다. 노트북 한 대나 소형 서버에서 돌리는 개인 자동화에 4.64배 같은 수치가 그대로 재현될 것으로 기대하기는 어렵다.

그럼에도 시사점은 규모와 무관하게 유효하다. 에이전트 시스템의 성능 문제를 모델 탓으로만 돌리는 습관을 버리면, 돈을 더 쓰지 않고도 줄일 수 있는 시간이 생각보다 많다. 더 좋은 모델을 기다리기 전에 내 파이프라인의 시간 분포부터 재 보는 편이 빠르다.

출처: 해커뉴스 경유 — 아카이브 논문 arXiv:2605.02162 (https://arxiv.org/abs/2605.02162)