10일 만에 짜인 코드가 3천만 위안의 투자를 받기까지: 다중 에이전트 예측 엔진 'MiroFish' 아키텍처 딥다이브

요즘 GitHub 트렌딩을 보다 보면 참 기가 막힙니다. ‘주말 동안 AI로 뚝딱 만든 프로젝트입니다’라는 글이 심심치 않게 올라오는데, 그게 수만 개의 스타를 받고 심지어 수백억 원의 투자를 유치하는 시대가 되었죠. 최근 제 눈길을 끈, 아니 정확히 말하면 제 개발자로서의 자존심을 살짝 건드린 프로젝트가 하나 있었습니다. 바로 중국의 한 학부 졸업반 학생이 단 10일 만에 ‘바이브 코딩(Vibe Coding)’으로 완성했다는 ‘MiroFish(미로피쉬)’입니다.

처음엔 ‘또 그저 그런 LLM API 래퍼(Wrapper) 툴이겠거니’ 생각했어요. 이전 작인 감성 분석 툴 BettaFish로 일주일 만에 2만 개의 스타를 받으며 재미를 보더니, 이번엔 스케일을 키워 ‘예측 엔진’을 만들었다고 하더군요. 게다가 샨다(Shanda) 그룹의 천톈차오 회장으로부터 24시간 만에 3천만 위안(약 55억 원)의 투자를 이끌어내고 하루아침에 AI 스타트업의 CEO가 되었다는 기사를 읽었을 때는, 솔직히 트렌드에 편승한 마케팅의 승리가 아닌가 의심했습니다. 하지만 퇴근 후 프로젝트를 클론(Clone) 받고 코드를 뜯어보는 순간, 생각이 조금 달라졌습니다. 이 친구가 코드를 짜는 방식은 거칠지 몰라도, 다중 에이전트(Multi-Agent) 시스템이 나아가야 할 아키텍처적 방향성을 아주 정확하게 짚고 있었거든요. 오늘 커피 한 잔 하면서, 이 흥미로운 프로젝트의 밑바닥에 도대체 어떤 기술이 숨 쉬고 있는지 진짜 현업 개발자의 시선으로 한 번 딥다이브 해보려고 합니다.

TL;DR (The Core) MiroFish는 수많은 LLM 에이전트들에게 현실의 뉴스나 데이터(시드 정보)를 주입해 가상의 ‘디지털 모래상자(Sandbox)’를 만들고, 이들이 상호작용하며 만들어내는 결과를 통해 미래의 정책, 여론, 심지어 소설의 결말까지 시뮬레이션하고 예측하는 군집 지능(Swarm Intelligence) 엔진입니다.

Deep Dive: Under the Hood (핵심 아키텍처 분석)

이 프로젝트가 단순히 프롬프트를 잘 깎아서 만든 장난감이 아닌 이유는, 데이터 주입부터 에이전트의 사회적 진화까지 이어지는 파이프라인을 꽤나 체계적으로 구축했기 때문입니다. 현업에서 LLM 여러 개를 체인으로 엮어본 분들이라면 뼈저리게 아시겠지만, 에이전트 수가 늘어날수록 환각(Hallucination)은 기하급수적으로 증폭되고 상태(State) 관리는 말 그대로 지옥이 됩니다. MiroFish는 이 복잡도를 어떻게 풀었을까요?

1. GraphRAG 기반의 초기 세계관 및 ‘장기 기억’ 구축 에이전트 수천 개를 무작정 띄우면 녀석들은 각자 컨텍스트를 잃고 헛소리를 하기 시작합니다. MiroFish는 시뮬레이션을 시작하기 전, 입력된 시드 데이터(예: 정책 초안, 재무 신호, 속보)를 바탕으로 엔티티(Entity) 간의 관계를 추출해 GraphRAG(그래프 기반 검색 증강 생성) 구조를 만듭니다. 단순한 벡터 기반의 유사도 검색(Vector Search)을 넘어, 인물 A와 인물 B의 적대적 관계, 특정 사건이 금융 시장에 미치는 파급력 등을 지식 그래프로 엮어 각 에이전트의 ‘장기 기억(Long-term Memory)’으로 초기 주입하는 것이죠. 이때 기억의 지속성을 관리하기 위해 외부 메모리 솔루션인 Zep Cloud를 적극적으로 파이프라인에 통합한 점도 현업 관점에서는 매우 합리적인 선택이었습니다.

2. OASIS 엔진과 이중 플랫폼 병렬 시뮬레이션(Dual-Platform Parallel Simulation) MiroFish 아키텍처의 심장부에는 CAMEL-AI 팀이 구축한 OASIS 시뮬레이션 엔진이 자리 잡고 있습니다. 여기서 눈여겨볼 점은 에이전트들이 단순히 핑퐁 대화를 나누는 1차원적 구조가 아니라는 겁니다. 이들은 환경(Environment) 노드와 에이전트(Agent) 노드를 분리하여, 이중 플랫폼 병렬 시뮬레이션을 돌립니다. 즉, 개별 에이전트들은 시스템이 부여한 독립적인 페르소나와 행동 로직에 따라 자유롭게 사회적 상호작용을 하고, 환경 노드는 이들의 행동이 뭉쳐서 만들어내는 ‘거시적 변수’를 실시간으로 다시 계산하여 에이전트들에게 2차 피드백을 줍니다. 개인의 행동이 군집의 창발(Emergence)로 이어지는 과정을 코드로 구현한 셈이죠.

3. 동적 변수 주입을 위한 ‘신의 시점(God Perspective)’ 인터페이스 제가 가장 인상 깊게 본 아키텍처적 포인트는 바로 런타임 중에 개입할 수 있는 인터페이스 설계입니다. 개발자나 기획자는 시뮬레이션이 한창 돌아가는 중간에 ‘신의 시점’에서 새로운 뉴스나 이벤트를 동적 변수(Dynamic Variable)로 주입할 수 있습니다. 이때 시스템은 무식하게 전체 프롬프트 컨텍스트를 처음부터 재계산하지 않습니다. 대신 동적으로 시계열 기억(Temporal Memory)을 업데이트하여, 해당 이벤트가 그래프 내의 어떤 엔티티에 영향을 미치는지 파급(Cascade)시키는 우회로를 택했습니다.

Hands-on / Pragmatic Use Cases

자, 원리는 어느 정도 알겠고. 그럼 ‘이걸 당장 내일 출근해서 우리 프로젝트에 어떻게 써먹을 수 있을까?’가 가장 중요하겠죠. 공식 데모에서는 우한대학교 여론을 예측하거나 심지어 미완성 소설인 《홍루몽(Dream of the Red Chamber)》의 잃어버린 결말을 추론하는 흥미진진한 용례를 보여주지만, 저는 이걸 신규 프로덕트 런칭 전 리스크 매니지먼트에 당장 도입해보고 싶더라고요.

예를 들어, 우리가 기존에 잘 나가던 구독형 서비스의 요금제를 대폭 개편한다고 가정해 봅시다. 기존에는 기껏해야 일부 유저를 대상으로 AB 테스트를 돌리거나 정성적인 FGI(Focus Group Interview)를 하는 게 다였죠? 이제는 다릅니다. MiroFish 환경 변수(LLM_MODEL_NAME=qwen-plus 등)를 세팅하고, 우리 기존 고객들의 행동 데이터, 불만 접수 내역(CS 로그), 현재 시장의 경쟁사 상황 등을 시드 데이터로 때려 넣습니다. 그러면 엔진은 ‘충성 고객’, ‘가격에 민감한 체리 피커’, ‘이탈 직전의 불만 고객’ 등의 페르소나를 가진 수백 명의 에이전트를 생성합니다. 그 디지털 모래상자 안에 ‘베이직 요금제 20% 인상 및 프리미엄 기능 제한’이라는 폭탄(변수)을 던져보는 겁니다. 에이전트들이 가상의 소셜 미디어에서 어떻게 선동을 시작하는지, 어떤 논리로 경쟁사 서비스로 갈아타는지를 텍스트와 그래프 로그로 생생하게 볼 수 있습니다. 마지막으로 내장된 ReportAgent가 이 난장판을 분석해서 ‘이 요금제 개편은 3일 차에 부정적 여론이 임계점을 돌파할 확률이 85%입니다’라는 심층 보고서를 내놓습니다. 서비스 기획자나 PM 입장에서는 정말 침이 꿀꺽 넘어가는 치트키 아닌가요?

Honest Review (진짜 장단점)

물론 칭찬만 할 수는 없겠죠. 앞서 말했듯 ‘10일 만에 바이브 코딩으로 짠 코드’라는 타이틀은 훈장인 동시에 양날의 검입니다. 실제로 GitHub 리포지토리의 최근 PR(Pull Request)이나 이슈 트래커를 현직자의 매의 눈으로 들여다보면, 이걸 당장 프로덕션 레벨에 투입하기엔 위험천만한 아키텍처적 트레이드오프와 뼈아픈 버그들이 곳곳에 산재해 있습니다.

가장 치명적인 문제는 역시 LLM 컨텍스트 윈도우의 한계와 폭발하는 비용입니다. 최근 머지(Merge)된 PR 중에 handle API token overflow crash with context length라는 이슈가 눈에 띄더군요. 에이전트들이 상호작용하며 생성하는 컨텍스트가 핑퐁을 거듭할수록 기하급수적으로 늘어나다 보니, 로컬 환경이나 제한된 예산 안에서는 LLM API 호출 비용이 감당 안 될 정도로 폭발하거나 컨텍스트 윈도우 초과로 파이썬 백엔드가 장렬하게 뻗어버리는 현상이 발생합니다.

또한, LLM 기반 시스템의 고질병인 JSON 파싱 및 직렬화(Serialization) 오류도 여전합니다. 여러 에이전트의 상태를 JSON 형태로 직렬화하여 주고받아야 파이프라인이 매끄럽게 돌아가는데, LLM이 뱉어내는 텍스트에 마크다운이나 불필요한 설명이 섞이면서 전체 시스템이 멈추는 버그(robust JSON extraction for mixed LLM responses)가 최근까지도 지속적으로 핫픽스되고 있었습니다. 덧붙여, Node.js 기반의 Vue 프론트엔드와 파이썬(Python) 3.11 백엔드가 분리된 구조 자체는 현대적이지만, 수천 개의 에이전트 상태를 실시간으로 웹에 렌더링하기 위한 소켓 통신이나 상태 동기화 최적화는 아직 토이 프로젝트 수준에 머물러 있습니다. 이걸 진짜 엔터프라이즈에서 쓰려면 백엔드에 카프카(Kafka)나 래빗MQ(RabbitMQ) 같은 견고한 메시지 큐(Message Queue)를 도입하고, 분산 처리 아키텍처로 뼈대부터 대대적으로 리팩토링해야 할 겁니다.

Closing Thoughts

퇴근 후 늦은 밤까지 MiroFish의 코드를 뜯어보면서 참 많은 생각이 들었습니다. 한편으로는 ‘아키텍처의 빈틈이 이렇게 많은데, 나라면 절대 이런 상태로 릴리즈 안 했을 텐데’라는 시니어 특유의 오만한 꼰대 생각도 들었죠. 하지만 다른 한편으로는 ‘나는 과연 10년 동안 개발을 하면서 이런 스케일의 발칙한 상상력을 구현해 보려 한 적이 있었나?’라는 묵직한 씁쓸함도 남았습니다. 천톈차오 회장이 3천만 위안이라는 거액을 투자한 이유는 이 코드가 무결점이라서가 아닐 겁니다. 과거의 데이터를 정적으로 분석하는 데 그치지 않고, AI를 통해 미래를 시뮬레이션하는 ‘예측 가능한 디지털 평행 세계’를 구현하겠다는 그 비전과 실행력 자체에 베팅한 것이겠죠.

AI 도구가 눈부시게 발전하면서 1인 개발자가 세상을 놀라게 하는 ‘슈퍼 개인(Super Individual)’의 시대가 정말로 도래했습니다. 하지만 우리 현업 개발자들이 위축될 필요는 없습니다. 10일 만에 작성된 번뜩이는 아이디어가 시장의 주목을 받을 순 있어도, 그 거친 원석을 깎아내어 수만 명의 트래픽을 견디고, 비용을 최적화하며, 엣지 케이스(Edge Case)를 방어하는 지속 가능한 프로덕트로 만드는 것은 결국 산전수전 다 겪은 우리들의 ‘진짜 엔지니어링’ 몫이니까요.

이번 주말, 늘 하던 뻔한 프레임워크 튜토리얼 대신 깃허브에서 MiroFish를 로컬 환경에 띄워보는 건 어떨까요? 터미널에 docker compose up -d 명령어 한 줄을 치는 순간, 수천 명의 에이전트가 살아서 꿈틀거리는 작은 평행 우주를 창조하는 짜릿한 경험을 하실 수 있을 겁니다. 아, 물론 다음 달에 날아올 폭발적인 API 청구서는 미리 각오해 두시길 바랍니다!

References

• https://github.com/666ghj/MiroFish
• https://36kr.com
• https://phemex.com
• https://reddit.com/r/aiagents
• https://hexmos.com
• https://github.io