엣지 에이전트와 클라우드의 협업: 실행 전반을 제어하는 새로운 방식

들어가며

엣지와 클라우드의 역할 분담은 그동안 하나의 요청을 로컬에서 처리할지 클라우드로 보낼지 결정하는 라우팅 문제로 설명되는 경우가 많았다. 하지만 장기 작업을 수행하는 LLM 에이전트는 여러 단계에 걸쳐 계획을 세우고, 도구를 사용하며, 중간 결과에 따라 행동을 수정한다. 이 과정에서 클라우드는 한 번만 호출되는 것이 아니라 실행 궤적 곳곳에 개입할 수 있다. 호출이 발생할 때마다 비용뿐 아니라 전송되는 정보의 범위와 이후 의사결정에도 변화가 생긴다.

연구가 평가한 것

연구진은 이러한 문제를 분석하기 위해 EC2-Bench를 제안했다. 이 벤치마크는 디지털 워크스페이스에서 실제로 실행할 수 있는 128개의 장기 과제를 제공하며, 다음 세 가지 지표를 함께 살핀다.

• 과제 성능: 에이전트가 목표를 달성하는지 여부와 결과의 품질
• 자원 사용량: 엣지 추론과 클라우드 API 호출에 드는 비용
• 개인정보 노출: 실행 과정에서 클라우드로 전달되는 정보의 양과 범위

비교 대상은 엣지 전용과 클라우드 전용 실행뿐 아니라 여러 협업 구조다. 외부 라우터가 클라우드 호출 시점을 정하는 방식, 엣지 모델이 직접 도움을 요청하는 방식, 클라우드가 작업을 수행하는 대신 조언만 제공하는 방식 등이 포함됐다.

핵심 결과

첫째, 협업 실행은 성능과 비용, 개인정보 보호 사이에서 현실적인 절충안을 제공할 수 있다. 클라우드 전용 구성은 더 강한 모델을 활용할 수 있지만 원격 연산과 데이터 전송이 늘어난다. 엣지 전용 구성은 데이터의 로컬성을 유지하기 쉽지만 모델 능력의 제약을 받을 수 있다. 제공된 자료에 따르면 9B 엣지 모델을 협업 방식으로 사용했을 때, 전체 클라우드 실행 성능의 약 73%를 달성하면서 클라우드 API 비용은 약 15% 수준이었다.

둘째, 엣지 모델이 강해질수록 협업 실행의 성능은 클라우드 전용 실행에 가까워지고, 전략 간 성능 차이도 줄어든다. 그러나 개인정보 노출은 같은 방식으로 수렴하지 않는다. 어떤 정보를 언제 클라우드에 보내는지, 클라우드가 조언자인지 실행자인지에 따라 노출 수준이 크게 달라진다. 즉, 강한 엣지 모델은 능력 문제를 완화할 수 있지만 데이터 거버넌스 문제까지 자동으로 해결하지는 않는다.

셋째, 엣지 모델의 능력에 따라 적합한 협업 방식이 달라진다. 상대적으로 약한 모델은 외부 라우팅이나 클라우드의 직접 실행에 더 의존한다. 반대로 엣지 모델이 강해지면 엣지가 실행 흐름을 주도하고, 필요한 순간에만 클라우드에 조언을 요청하는 구성이 더 적합해진다.

의미와 영향

이 연구는 엣지-클라우드 협업을 단순한 모델 선택이 아니라 전체 실행 궤적을 설계하는 시스템 문제로 확장한다. 개인 기기나 기업용 작업 환경에서 중요한 것은 로컬 모델의 크기만이 아니다. 에이전트가 언제 원격 도움을 요청할지, 어떤 최소 정보만 공유할지, 조언을 받은 뒤 처리를 다시 로컬에서 이어갈 수 있을지도 중요하다.

EC2-Bench의 장점은 성능, 자원 사용량, 개인정보를 하나의 평가 틀에서 비교한다는 데 있다. 성공률이 높더라도 지나치게 많은 API 호출이나 광범위한 컨텍스트 전송을 요구한다면 실제 배포에는 부적합할 수 있다. 앞으로는 엣지가 상태와 제어권을 유지하고 클라우드를 제한적인 조언자로 활용하는 구조를 다양한 작업과 기기 조건에서 검증해야 한다. 이 접근은 로컬 처리와 클라우드 능력 사이의 균형을 정량적으로 논의할 기반을 제공한다.

출처: Hugging Face Daily Papers