휴대폰에서 17개 에이전트 AI 스웜을 구축한 방법

휴대폰에서 17개 에이전트 AI 스웜을 구축한 방법

자, 준비하세요. 깊은 내용으로 들어가겠습니다. 지난 몇 주 동안 저는 터무니없게 들릴 수 있는 아이디어에 집착해 왔습니다. 바로 다중 에이전트 AI 시스템, 심지어 _스웜(swarm)_을 제 휴대폰에서 직접 실행할 수 있을까 하는 것이었습니다. 단순한 챗봇 수준이 아니라, 각기 다른 역할을 가진 상호작용하는 에이전트 네트워크가 복잡한 목표를 달성하기 위해 소통하고 협력하는 시스템 말입니다. 놀랍게도 답은… 예였습니다. 그리고 정말 흥미진진한 여정이었습니다.

이것은 순수한 처리 능력에 관한 것이 아니었습니다 (제 휴대폰은 아주 괜찮은 Pixel 7이지만, 데이터 센터는 아닙니다). 이것은 영리한 아키텍처, 리소스 관리, 그리고 온디바이스 머신러닝(on-device machine learning)의 발전을 활용하는 것에 관한 것이었습니다. 제가 어떻게 17개 에이전트 AI 스웜을 구축했는지, 애정을 담아 “Project Nightingale”이라고 명명하고 안드로이드에서 완전히 실행되도록 했는지 설명하겠습니다.

목표: 분산형 정보 수집 및 요약

기술적인 내용으로 들어가기 전에, 목표를 정의해 보겠습니다. 저는 특정 주제(현재는 web3 보안의 새로운 트렌드)에 대한 정보를 자율적으로 수집하고, 이를 여러 각도에서 분석하며, 간결하게 요약된 보고서를 제시할 수 있는 시스템을 원했습니다. 모든 것을 하려고 하는 거대한 하나의 LLM 대신, 저는 전문화된 에이전트들의 스웜을 구상했습니다:

• Scrapers (스크래퍼, 4개 에이전트): 특정 출처(뉴스 사이트, 블로그, Twitter, Reddit 등)에서 웹 스크래핑을 담당합니다.
• Analyzers (분석기, 6개 에이전트): 이 에이전트들은 스크랩된 콘텐츠에 대해 감성 분석(sentiment analysis), 주제 추출(topic extraction), 주요 구문 식별 등을 수행합니다. 이들은 전문화되어 있어, 일부는 기술적 세부 사항에 초점을 맞추고, 다른 일부는 시장 영향 등에 초점을 맞춥니다.
• Validators (검증기, 3개 에이전트): 이 에이전트들은 출처와 정보의 신뢰도를 평가합니다. 데이터를 교차 참조하고 잠재적인 허위 정보를 표시(flag)합니다.
• Summarizers (요약기, 2개 에이전트): 최종 단계로, 분석된 데이터를 받아 응집력 있는 요약 보고서를 생성합니다.
• Coordinator (코디네이터, 2개 에이전트): 두 개의 중복 코디네이터 에이전트는 워크플로우를 관리하고, 작업을 분배하며, 결과를 수집합니다. 이러한 중복성은 견고성(robustness)에 핵심적입니다.

기술 스택: Python, llama.cpp, 그리고 약간의 마법

제 시스템 전체는 Python을 사용하여 구축되었습니다. 이는 프로토타이핑과 필요한 라이브러리에 접근하는 데 가장 유연한 옵션이기 때문입니다. 각 에이전트의 핵심은 llama.cpp를 활용합니다. 이것은 제한된 리소스를 가진 장치에서도 대규모 언어 모델(LLMs)을 로컬에서 실행할 수 있게 해주는 훌륭한 라이브러리입니다. 저는 성능과 크기의 균형을 위해 Mistral 7B의 양자화 버전(구체적으로 Q4_K_M)을 선택했습니다.

다음은 llama.cpp를 사용하여 분석기 에이전트가 LLM을 초기화하는 간소화된 예시입니다 (Python 바인딩 사용):

from llama_cpp import Llama

llm = Llama(model_path="./models/mistral-7b-instruct-v0.1.Q4_K_M.gguf", n_ctx=2048) # 휴대폰 RAM에 따라 n_ctx 조정

주요 구성 요소:

• 에이전트 클래스 (Agent Class): 메시지 처리, 작업 실행 및 보고와 같은 공통 기능을 정의하는 기본 클래스입니다.
• 태스크 큐 (Task Queue) (Redis): 휴대폰에서 로컬로 실행되는 Redis 서버(경량화된 Redis 구현 사용)가 태스크 큐 역할을 합니다. 코디네이터 에이전트들이 작업("this URL 스크랩하기" 등)을 큐에 넣으면, 워커 에이전트들이 이용 가능한 대로 작업을 가져갑니다. 이는 에이전트들을 분리하고 비동기식 작동을 가능하게 합니다.
• 데이터 저장소 (Data Storage) (SQLite): 스크랩된 데이터, 분석 결과 및 에이전트 로그의 영구 저장을 위해 SQLite를 사용합니다. 가볍고 기기 내(on-device) 사용에 이상적입니다.
• 통신 (Communication) (단순 텍스트 기반 프로토콜): 에이전트는 TCP 소켓을 통해 단순한 텍스트 기반 프로토콜로 통신합니다. 이는 오버헤드를 낮게 유지하고 복잡한 직렬화/역직렬화를 피하게 합니다.

아키텍처: 탈중앙화 메쉬 (The Architecture: A Decentralized Mesh)

이것은 계층적 시스템이 아닙니다. 코디네이터가 작업을 시작하지만, 에이전트들이 엄격하게 순서가 정해져 있지는 않습니다. 예를 들어, 분석기 에이전트는 명확한 설명이 필요할 경우 스크래퍼에게 직접 추가 정보를 요청할 수 있습니다.

에이전트 통신 루프의 예시는 다음과 같습니다:

import socket

class Agent:
...

각 에이전트는 고유 포트에서 리스닝합니다. 코디네이터 에이전트는 중앙 허브 역할을 하지만, 필요할 때 에이전트들끼리 직접 연결할 수도 있습니다. 이 메쉬 네트워크는 복원력을 제공하는데, 하나의 에이전트가 실패하더라도 다른 에이전트들이 종종 보상할 수 있기 때문입니다.

도전 과제 및 최적화 (Challenges and Optimizations)

양자화된 모델이라 하더라도 17개의 LLM을 휴대폰에서 실행하는 것은 매우 어려운 일입니다. 제가 해결한 내용은 다음과 같습니다:

• 메모리 관리 (Memory Management): 매우 중요합니다. 저는 컨텍스트 크기(n_ctx)를 전략적으로 사용했습니다. 긴 텍스트를 다루는 분석기(Analyzers)는 더 큰 컨텍스트를 사용했고, 스크래퍼(scrapers)는 더 작은 컨텍스트를 사용했습니다. 또한 공격적인 가비지 컬렉션(garbage collection)도 구현했습니다.
• CPU 스로틀링 (CPU Throttling): 모바일 CPU는 지속적인 부하가 걸리면 성능이 저하됩니다. 저는 작업 간에 수면 간격(sleep intervals)을 도입하고 동시 LLM 추론(LLM inferences) 수를 제한했습니다.
• 배터리 수명 (Battery Life): 이 시스템은 배터리를 많이 소모합니다. 배터리 잔량을 모니터링하여 배터리 수준이 낮을 때 활성 에이전트의 수를 자동으로 줄이는 배터리 모니터링 모듈을 추가했습니다.
• 컨텍스트 전환 (Context Switching): 이렇게 많은 에이전트가 동시에 실행되면서 컨텍스트 전환 오버헤드(context switching overhead)가 상당해졌습니다. Redis를 작업 큐잉(task queuing)에 사용하고 에이전트 코드를 간결하게 유지하는 것이 이를 완화하는 데 도움이 되었습니다.

코드 스니펫 및 주요 기능성

스크래퍼 에이전트의 단순화된 예시를 살펴보겠습니다:

import requests
from bs4 import BeautifulSoup

...

그리고 분석기(Analyzer)가 LLM을 사용하여 감성 분석(sentiment analysis)을 수행하는 방법에 대한 단순화된 예시입니다:

python
def analyze_sentiment(text):
...