요약: 멀티 에이전트 시스템은 보통 텍스트로 대화한다. 한 에이전트가 긴 분석을 자연어로 쓰고, 다른 에이전트가 다시 읽어 토큰으로 인코딩한다. 이 방식은 단순하지만 느리고 정보 손실이 있다. 최근 arXiv의 Latent Cache Flow(LCF)는 모델 간 정보를 텍스트가 아니라 압축된 cache 표현으로 전달하는 접근을 제안한다. 논문은 13MB LCF adapter가 956MB C2C adapter보다 공유 컨텍스트에서 더 정확하고, 다른 컨텍스트에서는 텍스트 통신보다 23% 정확하고 8.5배 빠르다고 보고한다. 당장 제품에 쓰기보다는 멀티 에이전트 아키텍처에서 어떤 통신 비용을 줄여야 하는지 보는 자료로 유용하다.
에이전트 시스템을 만들다 보면 역할을 나누고 싶어진다. 리서치 에이전트, 코딩 에이전트, 리뷰 에이전트, QA 에이전트, 보안 에이전트가 각각 맡은 일을 하게 만든다. 문제는 이들이 서로 정보를 전달하는 방식이다. 대부분은 텍스트 요약을 주고받는다.
텍스트 통신은 디버깅이 쉽고 모델 API와 잘 맞는다. 하지만 비용이 크다. 첫 번째 에이전트가 내부 상태를 긴 문장으로 디코딩하고, 두 번째 에이전트는 그 문장을 다시 인코딩한다. 중간에 빠진 뉘앙스는 복구되지 않는다. 또 에이전트가 많아질수록 같은 맥락이 여러 번 반복되어 토큰 비용과 지연 시간이 늘어난다.
검색 의도로 보면 이 글의 핵심 키워드는 멀티 에이전트 통신, Latent Cache Flow, AI 에이전트 아키텍처다. 실무 목표는 논문 구현을 바로 따라 하는 것이 아니라, 지금 운영 중인 에이전트 시스템에서 텍스트 전달 병목을 찾고 줄이는 기준을 세우는 것이다.
LCF는 모델 간 통신을 텍스트가 아닌 latent cache 형태로 처리하려는 접근이다. 기존 Cache-to-Cache(C2C)는 sharer 모델의 KV cache를 receiver 모델로 옮기기 위해 adapter를 학습하지만, adapter가 크고 개별 token 번역에 가깝다. 또한 target context가 동일해야 하는 제약이 있어 실제 에이전트 통신에는 맞지 않는다고 논문은 지적한다.
LCF는 key와 value를 함께 번역하고 압축해 adapter 크기를 줄인다. 논문 설명 기준으로 C2C 대비 약 4% 크기의 adapter를 사용한다. 또한 receiver 모델이 이미 가진 정보가 아니라 새 정보의 요약을 전달하도록 설계해 서로 다른 컨텍스트에서도 동작하게 한다. 초기 실험에서는 13MB adapter가 956MB C2C adapter보다 정확했고, 다른 컨텍스트에서는 텍스트 기반 통신보다 23% 정확하고 8.5배 빠른 결과를 보였다.
이 숫자를 제품 성능으로 바로 일반화하면 안 된다. 논문은 초기 실험이고, 모델 조합, task, 학습 데이터, 보안 조건에 따라 달라진다. 그래도 방향은 중요하다. 에이전트가 늘어날수록 자연어 메시지가 항상 최적의 내부 통신 포맷은 아닐 수 있다.
대부분의 팀은 LCF adapter를 직접 학습하지 않는다. API 모델을 쓰고, 내부 KV cache에 접근할 수 없기 때문이다. 그럼에도 얻을 수 있는 교훈이 있다. 첫째, 모든 에이전트 간 메시지를 사람이 읽는 prose로 만들 필요는 없다. 둘째, receiver가 필요한 정보만 전달해야 한다. 셋째, 반복 전달되는 컨텍스트는 캐시하거나 구조화해야 한다.
예를 들어 리서치 에이전트가 20개 문서를 읽고 코딩 에이전트에게 넘긴다고 하자. 긴 요약문 하나보다 구조화된 evidence table이 낫다. claim, source_url, confidence, relevant_files, open_questions 같은 필드로 전달하면 receiver가 덜 추측한다. 코드 리뷰 에이전트에게는 전체 대화가 아니라 변경 파일, 테스트 결과, 위험 라벨, 재현 명령을 넘기는 편이 낫다.
즉 실무에서의 첫 단계는 latent cache가 아니라 structured handoff다. 자연어 요약을 줄이고, 다음 에이전트가 실제로 쓰는 필드만 남긴다. 이것만 해도 토큰 비용과 오류가 줄어든다.
멀티 에이전트 시스템에는 API 계약처럼 handoff 계약이 필요하다. 역할별로 입력과 출력을 정한다. 리서치 에이전트는 출처와 근거를 남긴다. 플래너는 작업 분해와 종료 조건을 남긴다. 코딩 에이전트는 변경 파일, 실행 명령, 실패 로그를 남긴다. 리뷰 에이전트는 위험도와 승인 여부를 남긴다.
계약이 없으면 에이전트는 매번 장문의 설명을 생성한다. 이 설명은 보기에는 그럴듯하지만 후속 작업에는 불필요한 경우가 많다. 또한 누락이 생겨도 시스템이 잡기 어렵다. 예를 들어 테스트 명령이 빠졌는데 “전체적으로 검증했습니다”라는 문장이 있으면 사람이 속기 쉽다.
handoff schema에는 필수 필드와 선택 필드를 둔다. 필수 필드가 없으면 다음 에이전트를 실행하지 않는다. 또한 source pointer를 포함한다. 어떤 파일, URL, 로그, diff에서 나온 정보인지 추적할 수 있어야 한다. 이는 비용 최적화이면서 안전장치다.
에이전트 통신을 최적화하려면 먼저 측정해야 한다. 각 에이전트가 받은 입력 토큰, 출력 토큰, 처리 시간, 실패율, 재시도 횟수, 사람이 수정한 비율을 기록한다. 많은 팀이 모델 성능만 보지만, 실제 비용은 handoff에서 새는 경우가 많다.
특히 반복되는 컨텍스트를 찾는다. 같은 PR 설명, 같은 요구사항, 같은 API 문서가 에이전트마다 반복 입력된다면 캐시 또는 공유 context object로 빼야 한다. 반대로 한 번만 필요한 세부 로그가 전체 체인에 계속 전달된다면 잘라야 한다.
보안도 봐야 한다. 텍스트 handoff에는 민감정보가 섞이기 쉽다. 로그 전체를 다음 에이전트에게 넘기면 토큰에 API 키나 고객 정보가 포함될 수 있다. 구조화된 handoff는 필요한 필드만 넘기게 만들어 데이터 노출면을 줄인다.
