오픈클로(몰트봇) 아키텍처 분석: 게이트웨이와 채널 어댑터, 메모리로 살펴본 모듈형 AI 에이전트

핵심 메시지

• 이 에이전트는 게이트웨이를 중심으로 채널·에이전트·플러그인이 바퀴살처럼 붙는 허브 앤 스포크 구조를 따른다.
• 텔레그램 같은 메신저를 채널 어댑터로 추상화해, 새 메신저를 붙여도 게이트웨이 쪽은 바뀌지 않는다.
• 메시지는 개인 전용 에이전트부터 팀, 계정, 채널 순으로 좁은 범위부터 배정된다.
• 설정을 바꾸면 파일 감시가 이를 감지해 재시작 없이 전체 모듈에 전파된다.
• 대화 기억을 디스크에 저장해 도구별로 파편화되던 맥락을 한곳에 모으는 것이 실사용에서 가장 큰 이점으로 꼽혔다.

쉽게 이해하기

AI·머신러닝·퀀트 스터디의 아키텍처 회차에서, 한 참가자가 최근 화제가 된 오픈소스 에이전트를 직접 설치해 운영한 경험을 발표했다. 처음 접했을 때와 이름이 바뀔 만큼 빠르게 움직이는 프로젝트인데, 발표자는 소스 코드를 한 줄씩 읽기보다 아키텍처 수준에서 구조를 이해하는 데 초점을 맞췄다고 밝혔다. 문서를 만들 때 AI에게 근거가 되는 코드 조각을 함께 붙이게 한 것도 설명이 지어낸 내용으로 흐르지 않게 하기 위해서였다.

구조는 클라이언트, 게이트웨이, 비즈니스 로직, 통합, 인프라 계층으로 나뉜다. 중심에 있는 게이트웨이는 중앙 제어 평면 역할을 하며 채널과 에이전트 사이를 조율하고 시스템의 생명주기를 관장한다. 발표자는 이를 중앙 거점에 여러 스포크가 붙는 허브 앤 스포크 형태로 설명했다. 설정은 CLI, 환경 변수, 설정 파일 등 여러 경로로 줄 수 있고 우선순위가 정해져 있다.

통합 계층에서는 채널 어댑터가 텔레그램이나 디스코드 같은 외부 메신저를 추상화한다. 어댑터로 감싸두었기 때문에 다른 메신저를 새로 붙여도 게이트웨이 쪽 구현은 손댈 필요가 없다는 점이 설계의 요지다. 발표자는 어디서든 접근할 수 있다는 이유로 텔레그램을 주로 쓰고 있으며, CLI는 주로 설정할 때만 쓴다고 했다.

라우팅에는 흥미로운 규칙이 있다. 메시지가 들어오면 보낸 사람, 플랫폼, 대화방 같은 맥락을 추출한 뒤 개인 전용 에이전트, 팀, 계정, 채널 순서로 좁은 범위부터 대응되는 에이전트를 찾아 배정한다. 발표자는 콜센터처럼 일반 창구가 먼저 받고 전문 부서로 넘기는 방식과 반대라며, 왜 이렇게 설계했는지는 공개된 문서만으로는 알기 어렵다고 덧붙였다.

설정 변경을 파일 감시로 감지해 재시작 없이 각 모듈에 전파하는 점도 특징으로 꼽혔다. 운영을 멈추지 않아도 되는 대신, 검증이 형식 수준에 그치면 잘못된 설정도 순식간에 퍼질 수 있다는 양날의 검이라는 평가가 뒤따랐다. 에이전트 내부는 러너와 컨텍스트, 도구로 구성되며 생각하고 도구를 호출한 뒤 결과를 관찰해 반복하는, 익숙한 리액트 방식으로 돌아간다.

주요 인사이트

• 발표자가 실사용에서 가장 크게 체감한 이점은 성능이 아니라 맥락의 연속성이었다. 코딩 도구와 챗봇마다 대화가 흩어져 예전 대화를 찾아다녀야 했는데, 이 구조에서는 주제와 무관하게 하나의 에이전트가 계속 기억한다.
• 기억을 디스크에 저장하는 설계 덕분에 용량만 넉넉하면 장기 기억을 계속 쌓을 수 있다. 다만 발표자 스스로 모든 대화가 한곳에 축적되는 것이 조금은 무섭다며 권한을 너무 많이 주지 않는 편이 좋겠다고 말했다.
• 비용 문제가 현실적인 걸림돌로 드러났다. API 방식으로 붙였더니 금액이 빠르게 줄어 다른 모델의 구독 인증 방식으로 바꿨는데, 이번에는 하루 만에 쿼터가 소진돼 사용이 막혔다는 경험이 공유됐다.
• 모델을 바꾸면 대화의 결이 눈에 띄게 달라진다는 관찰도 나왔다. 참가자들 사이에서는 속도는 조금 느려도 사용량이 넉넉한 대안 모델의 코딩 플랜을 쓴다는 이야기가 오갔다.
• 발표자는 개인 저장소와 원본 저장소를 나눠 관리하며, 업데이트와 문서 갱신을 스킬로 만들어 명령 한 줄로 처리하도록 해두었다. 코드가 바뀌면 설명 문서도 함께 갱신되게 한 점이 눈에 띈다.

자주 묻는 질문

관련 AI 소식