FUSE, LLM 에이전트의 만능 열쇠가 될 수 있을까?

커뮤니티에서는 FUSE를 사용하여 LLM 에이전트에게 파일 시스템 접근 권한을 부여하는 방식에 대해 성능 저하(Performance Degradation) 문제를 지적한다. 특히, grep 명령을 사용한 파일 검색 시 다수의 파일 열기로 인해 API 호출 횟수가 증가하여 속도가 느려진다는 점을 강조한다. 또한, FUSE 기반의 파일 시스템은 기존 API를 직접 사용하는 방식보다 구현 복잡도(Implementation Complexity)가 높고, 캐싱(Caching)을 적용하더라도 초기 접근 속도가 느리다는 단점이 있다.

논의에서는 LLM 에이전트가 데이터베이스, 이메일 등 다양한 리소스에 접근할 때 FUSE를 거치지 않고 직접 API를 호출하는 방식이 더 효율적이라고 주장한다. 특히, cgroups/namespaces를 활용하여 접근 권한을 제어하는 것이 FUSE보다 더 안전하고 간결한 방법이라고 강조한다. 이러한 접근 방식은 데이터 격리(Data Isolation)를 유지하면서도 LLM 에이전트가 필요한 리소스에 안전하게 접근할 수 있도록 한다.

일부 개발자는 FUSE 대신 NFS(Network File System) 또는 9P 프로토콜을 활용하는 방식을 제안한다. 이러한 방식은 FUSE보다 더 안정적이고, 다양한 장점을 제공한다고 주장한다. 특히, NFS/9P는 네트워크 파일 시스템(Network File System)을 구축하는 데 특화되어 있어, 분산 환경에서의 파일 접근에 유리하다. ZeroFS 프로젝트를 예시로 들며, NFS/9P의 실용성(Practicality)을 강조한다.

FUSE 기반 파일 시스템은 다양한 기술적 문제와 유지 보수(Maintenance)의 어려움으로 인해 실용성이 떨어진다는 비판이 제기된다. 특히, 플랫폼 간 호환성(Cross-Platform Compatibility) 문제와 라이선스 이슈는 FUSE의 활용을 더욱 어렵게 만든다. 따라서, 데이터베이스 직접 접근, cgroups/namespaces 활용, NFS/9P 프로토콜 등 대안적인 아키텍처(Alternative Architecture)를 고려해야 한다.