아버지의 사업을 운영하는 멀티 에이전트 AI 팀 구축 — 여기 아키텍처를 공개합니다

본 글은 Hacktoberfest Weekend Challenge: Build for a Friend 제출물입니다.

제가 구축한 것

저는 아버지의 사업을 운영하는 AI 팀을 만들었습니다. 챗봇이나 단일 에이전트가 아니라, 운영, 콘텐츠, 고객 지원, 코드, 분석을 처리하는 전문화된 AI 에이전트들로 구성된 팀입니다. 모든 것은 중앙 작업 시스템을 통해 조정됩니다. 그리고 모두 오픈 소스 AI 위에서 구동됩니다.

이번 챌린지에서 '친구'는 제 아버지입니다. 아버지는 작은 사업체를 운영하시는데, 반복적인 업무에 파묻혀 계셨습니다. 동일한 고객 질문에 답하고, 소셜 미디어를 관리하며, 제품 목록을 업데이트하고, 주문을 추적하고, Google Business Profile의 댓글을 검토하는 일들이었습니다. 일이 어렵지 않았던 것이 아니라, 그저 끊임없이 반복되는 것이 문제였습니다.

그래서 저는 아버지를 위해 AI 에이전트 팀을 만들어 드렸습니다.

팀을 소개합니다:

Kodi: 디스패처(dispatcher). 작업을 할당하고, 진행 상황을 추적하며, 병목 현상(blockers)을 감지하고, 인계(handoffs)를 처리하며, 인간의 주의가 필요한 경우에만 저에게 알림을 보냅니다.
Stark: 엔지니어. Git 프로젝트, 포트폴리오 웹사이트, 사이드 프로젝트, 배포 및 PR 검토를 관리합니다.
Edith: 마케터. Amazon 스토어프론트, Google Business Profile, 소셜 미디어 콘텐츠 및 광고 캠페인을 처리합니다.
Friday: 지원 에이전트(support agent). 분석 대시보드를 유지하고, 고객 문의를 처리하며, 시스템을 효율적으로 유지합니다.

이들은 단순히 프롬프트에 응답하는 것에 그치지 않습니다. 능동적으로 작업을 맡고, 서로 협력하며, 보고합니다. 마치 실제 팀처럼 작동하지만 회의는 없습니다.

데모

시스템은 로컬 서버에서 구동됩니다. 실제로 어떻게 작동하는지 보여드리겠습니다:

→ 새로운 고객 문의 감지
→ Friday가 이를 맡아 응답 초안 작성
→ Kodi가 Stark에게 기술 세부 사항 검토를 할당
...

대시보드에는 실시간 에이전트 상태, 작업 큐(task queues), 그리고 실시간 활동 피드가 표시됩니다. 마치 Jira 보드를 가진 것 같지만, 일하는 사람이 AI입니다.

구축 방법 (How I built it)

핵심 구성 요소: 오픈 소스 에이전트 프레임워크 (The Core: Open-Source Agent Framework)

시스템 전체는 오픈 소스 AI 에이전트 프레임워크인 Hermes Agent를 기반으로 작동합니다. 각 에이전트는 독립적인 인스턴스로, 다음 요소를 가집니다:

시스템 프롬프트 (System prompt): 페르소나, 역할, 제약 조건
도구 접근 권한 (Tool access): 수행할 수 있는 작업 (GitHub, 데이터베이스, API, 파일 시스템)
메모리 (Memory): 세션 간 지속적인 컨텍스트
스킬 (Skills): 호출할 수 있는 재사용 가능한 절차

폐쇄형 API나 블랙박스는 없습니다. 모든 조각은 검사(inspectable)가 가능하고, 수정이 가능하며, 로컬에서 실행됩니다.

조정 계층: SQLite + MCP (The Coordination Layer: SQLite + MCP)

에이전트들은 서로 직접 대화하지 않습니다. 대신 공유된 SQLite 데이터베이스를 통해 통신하며, 이 데이터베이스는 다음 항목들의 단일 진실 공급원(single source of truth) 역할을 합니다:

작업 할당 및 상태 (Task assignments and status)
에이전트 가용성 및 현재 작업 (Agent availability and current work)
승인 워크플로우 (Approval workflows) (누가 무엇을 승인할 수 있는지)
이벤트 기록 (Event history) (추가 전용 감사 추적(append-only audit trail))

이는 의도적인 선택이었습니다. 저는 어떤 SQLite 브라우저로든 검사하고, 간단한 쿼리로 디버깅하며, cp 명령어로 백업할 수 있는 무언가를 원했습니다. 메시지 브로커(message broker)도 없고, Redis도 없고, Kafka 클러스터도 없습니다. 그저 데이터베이스만 있습니다.

이 데이터베이스는 MCP (Model Context Protocol)를 통해 외부에 노출됩니다. MCP는 AI 에이전트가 외부 도구에 접근할 수 있도록 하는 개방형 표준입니다. 각 에이전트는 MCP 클라이언트를 가지고 있어 다음 작업을 수행할 수 있습니다:

# 에이전트가 작업을 가져옴
tasks = mcp.get_tasks(status="available", agent="stark")
mcp.acknowledge_task(tasks[0].id, agent="stark")
...

승인 시스템: 에이전트가 취할 수 있는 결정

모든 결정에 인간의 개입이 필요한 것은 아닙니다. 저는 각 에이전트에게 자율성의 범위를 가진 승인 시스템을 구축했습니다:

Friday는 일반적인 고객 질문에 대한 응답을 승인할 수 있습니다.
Stark는 모든 검사를 통과한 PR(Pull Request)을 병합할 수 있습니다.
Edith는 브랜드 보이스와 일치하는 콘텐츠를 게시할 수 있습니다.
Kodi는 누군가 작업이 막혔을 때 작업을 재할당할 수 있습니다.

에이전트가 자신의 범위를 벗어나는 것을 감지하면, 이는 상위 단계로 에스컬레이션(escalates)됩니다. Kodi는 이를 처리할지 아니면 저에게 알림을 보낼지 결정합니다. 저는 무언가가 고장 났거나, 제 주의가 필요하거나, 승인이 필요한 경우에만 통보를 받습니다. PR 병합, 에스컬레이션, 그리고 블로커(blockers)입니다. 그게 전부입니다.

이것이 시스템을 실제로 유용하게 만든 핵심이었습니다. 이것이 없었다면, 저는 모든 사소한 것들을 승인해야 했을 것입니다. 이것 덕분에 팀이 스스로 운영되고, 제가 개입하는 경우는 정말 중요한 순간에만 하게 됩니다.

메모리 시스템: Mnemosyne

에이전트들은 것을 잊어버립니다. 짜증 납니다. 그래서 저는 모든 에이전트에게 다음을 제공하는 'Mnemosyne'라는 영구 메모리 계층을 구축했습니다:

작업 기억(Working memory): 현재 세션 컨텍스트
일화적 기억(Episodic memory): 과거 경험, 배운 교훈
의미론적 기억(Semantic memory): 사실, 관계, 선호도
페르소나 메모리(Persona memory): 절대 삭제되지 않는 안정적인 정체성과 선호도

메모리 시스템은 3단계 아키텍처를 사용합니다:

핫 티어(Hot tier): 인메모리(in-memory), 항상 사용 가능, 작음
웜 티어(Warm tier): 의미론적 검색을 위한 벡터 검색 (FAISS)
콜드 티어(Cold tier): 정확한 일치를 위한 전체 텍스트 검색 (SQLite FTS5)

에이전트가 무언가를 기억해야 할 때, Mnemosyne에 질의합니다. 시스템은 하이브리드 점수(hybrid score)로 순위가 매겨진 관련 메모리를 반환합니다: 벡터 유사도 50%, 텍스트 일치도 30%, 중요도 20%.

이는 제가 Stark에게 '지난주 로그인 버그 수정'을 요청할 때, 단순히 '로그인 버그'를 검색하는 것이 아니라, 제가 의미하는 바를 의미론적으로 이해하고 일주일 전의 관련 컨텍스트를 끌어온다는 것을 의미합니다.

RAG 시스템: 하이브리드 검색 (Hybrid Retrieval)

에이전트들은 방대한 지식에 접근해야 합니다: 문서화 자료, 과거 결정 사항, 코드 패턴, 고객 FAQ, 제품 카탈로그, 경쟁사 데이터. 저는 다음을 인덱싱하는 검색 증강 생성(Retrieval-Augmented Generation, RAG) 시스템을 구축했습니다:

지식 기반에서 8,500개 이상의 청크(chunks)
180개 이상의 에이전트 스킬 및 절차
과거 프로젝트에서 얻은 22개의 공유된 회고 학습(retro lessons)

검색은 하이브리드 접근 방식을 사용합니다:

벡터 유사도용 FAISS (의미론적 검색, semantic search)
키워드 매칭용 BM25 (정확한 검색, exact search)
α = 0.6 블렌딩 계수(blending factor) (의미론에 약간 더 가중치 부여)

하이브리드를 사용하는 이유는 무엇일까요? 순수 벡터 검색은 정확한 일치(

Amazon 스토어: 제품 목록 생성 및 관리, 경쟁사 검색, SEO 키워드 최적화, 제품 이미지 생성
Google 비즈니스 프로필: 게시물 자동 작성, 댓글 응답, 사업 정보 업데이트
소셜 미디어: 콘텐츠 초안 작성, 게시물 예약, 참여도 추적
광고 캠페인: Meta Ads 관리, 헤드라인 A/B 테스트, 전환 최적화

다음 단계는 Instagram, Facebook 및 Meta Ads에 대한 완전 자동 포스팅입니다. Edith가 콘텐츠를 생성하고, 검토하며, 게시하고, 성과를 추적합니다. 인간의 개입이 없습니다.

Stark: 엔지니어

Stark는 모든 기술 작업을 처리합니다:

Git 프로젝트: 저장소 관리, PR(Pull Request) 검토, 코드 병합
포트폴리오 웹사이트: 콘텐츠 업데이트, 버그 수정, 변경 사항 배포
사이드 프로젝트: 기능 구축, 테스트 작성, 인프라 관리
배포: 스테이징 및 프로덕션 환경, 실패 시 롤백

Stark는 제가 스타트업을 만든다면 팀에 두고 싶은 에이전트입니다. 깨끗한 코드를 작성하고, 철저하게 검토하며, 프로덕션을 망가뜨리지 않습니다 (거의).

Friday: 지원 및 분석 에이전트

Friday는 Agent HQ에서 분석 대시보드를 유지합니다:

일일 주문 현황: 주문 건수, 취소 건수, 매출액
소셜 미디어 지표: IG 팔로워 수, 참여율(engagement rate), 도달률(reach)
Google 비즈니스 프로필: 댓글, 평점, 응답률
스킬 학습: 사용하지 않는 보고서 플래그 지정 및 삭제, 시스템을 간결하고 효율적으로 유지

Friday는 또한 고객 문의를 처리하고, 답변 초안을 작성하며, 기술적 문제를 Stark에게 에스컬레이션합니다. 인내심이 강하고, 철저하며, 기분이 상할 때조차 절대 흥분하지 않습니다.

Kodi: 디스패처(Dispatcher)

Kodi가 전체 시스템을 운영합니다. Kodi는 다음 작업을 수행합니다:

적절한 에이전트에게 작업 할당
병목 현상(blockers) 감지 및 에스컬레이션
에이전트 간의 인계 처리
새로운 업무를 찾기 위한 기회 스캔 실행
무언가 고장 날 때 자가 복구(self-healing) 트리거
제가 알아야 할 것이 있을 때만 알림 제공

저는 주로 Kodi와만 상호작용합니다. Kodi가 나머지 모든 것을 처리합니다. 작업이 너무 오래 걸리면 Kodi가 재할당하고, 에이전트가 막히면 Kodi가 이를 격상(escalate)시킵니다. 제가 주의를 기울여야 할 것이 있으면 Kodi가 알려줍니다. 그렇지 않으면 팀으로부터 아무런 소식도 듣지 못합니다.

기회 스캔 및 자가 복구 (Self-Healing)

이 시스템은 단순히 작업을 기다리지 않습니다. Kodi는 새로운 작업을 찾기 위해 정기적인 기회 스캔(opportunity scans)을 실행합니다:

응답이 필요한 신규 고객 문의
참여(engagement)가 필요한 소셜 미디어 언급
최적화가 필요한 제품 목록
분석이 필요한 경쟁사 변경 사항
조사가 필요한 분석 이상 징후(analytics anomalies)

무언가 고장 나면 시스템은 자가 복구합니다. 에이전트가 충돌하면 Kodi가 이를 재시작하고, 작업이 실패하면 Kodi가 다른 접근 방식으로 재시도합니다. 도구가 사용 불가능하면 Kodi가 대안을 찾습니다. 이 시스템은 조각들이 실패할 때조차 계속 실행되도록 설계되었습니다.

Cron 비용 절감

AI 에이전트를 운영하는 것은 비쌉니다. 토큰 하나하나가 중요합니다. 저는 결정론적 단계(deterministic steps)를 사용하여 크론(cron) 비용을 크게 줄일 수 있었습니다:

매분마다 값비싼 AI 쿼리를 실행하는 대신, 시스템은 먼저 저렴한 결정론적 확인 절차를 사용합니다.
결정론적 확인 절차가 무언가를 감지했을 때만 시스템이 AI를 호출합니다.
이를 통해 시스템의 응답성을 유지하면서 토큰 사용량을 70% 줄일 수 있었습니다.

핵심은 AI를 규칙이 아닌 예외로 만드는 것이었습니다. 대부분의 경우, 시스템은 간단한 if/else 로직으로 문제를 처리할 수 있습니다. 할 수 없을 때만 도움을 요청하기 위해 AI를 이용하는 것입니다.

오픈 혁신(open innovation)은 왜 중요할까요?

이 시스템의 모든 부분은 오픈 소스입니다:

Hermes Agent: 에이전트 프레임워크
FAISS: 벡터 유사성 검색
SQLite: 조정 데이터베이스
MCP: 도구 프로토콜
MiniLM-L6-v2: 임베딩 모델

만약 제가 폐쇄형 API를 사용했다면, 저는 다음과 같은 상황에 처했을 것입니다:

아버지의 사업을 운영하는 멀티 에이전트 AI 팀 구축 및 아키텍처

요약

핵심 포인트