MiroFish 뜯어보기(2) - 실습편 : 문서 하나로 수천 명의 가상 인간을 시뮬레이션하는 집단 지능 엔진 사용해보기(mcp vs cli)
-
728x90
안녕하세요! 갓대희 입니다.
이번 글은 MiroFish를 실제로 한번 사용해보려 한다.
주제는 요즘 개발자 커뮤니티에서 가장 뜨거운 논쟁 중 하나인 "MCP(Model Context Protocol)가 AI 에이전트 표준이 될 수 있을까?" 골랐다.
시드 파일 하나를 넣으면, 여러명의 가상 전문가(eric_holmes_290, m00nlygreat_495, charles_chen_543, itter_348 등 36명)가 Twitter와 Reddit에서 N라운드 동안 토론하고, 분석 보고서까지 자동으로 나온다는 흐름이다.
목차
준비: 질문 정하고 시드 데이터 만들기
Step 1: 온톨로지 생성 — AI가 문서를 읽는 방법
Step 2: 지식 그래프 구축 — GraphRAG
Step 3: 시뮬레이션 실행 — 가상 토론장
Step 4: 보고서 생성 — ReportAgent의 분석
Step 5: 심층 대화 — 보고서 Agent에게 질문하기
결과 해석: MCP의 미래는?
비용 & 따라하기 가이드
0. 준비: 질문 정하고 시드 데이터 만들기
왜 MCP 논쟁을 골랐나
MCP는 2024년 11월 Anthropic이 공개한 AI 에이전트-외부 도구 연결 프로토콜이다. 2026년 3월 현재 32개 이상의 플랫폼이 공식 지원하지만, "32배 토큰 오버헤드"라는 치명적 비판과 함께 CLI 기반 대안이 빠르게 부상하고 있다. 찬성/반대/조건부가 명확히 갈리는 주제라서 시뮬레이션 소재로 적합했다.
시드 데이터 구조
시뮬레이션에 넣을 시드 데이터는 마크다운 파일 하나다. 핵심은 논쟁 구조를 명확하게 정리하는 것이다.
진영
논거 수
핵심 주장
찬성
5개
사실상 표준(32개+ 플랫폼), 통합 기능 강력, 엔터프라이즈 필수, 토큰 절약 솔루션 등장, 크로스플랫폼 이식성
반대
6개
스키마 블로트(32배 토큰), Perplexity CTO MCP 포기 선언, CLI의 현실적 우위, cmux 터미널 통신, 한국팀 CLI 선택
조건부
상황별
엔터프라이즈는 MCP, 스타트업은 CLI — 하이브리드가 현실적
시드 파일 작성: 소스와 구조
시드 파일(seed_mcp_vs_cli.md)은 직접 작성한 마크다운 문서다. 기존에 블로그에 써둔 MCP 관련 글 6편을 소스로 삼았다.
블로그 전문을 그대로 넣지 않고, 논쟁 구조만 뽑아서 재구성했다. 실제 seed_mcp_vs_cli.md의 섹션 구성은 다음과 같다:
seed_mcp_vs_cli.md 섹션 구성 (3KB) 1. 배경: 두 진영의 충돌 (Eric Holmes vs Charles Chen) 2. CLI 진영 핵심 논거 5가지 3. MCP의 현실적 문제점 (CLI 진영 지적) 4. MCP 진영 핵심 논거 5가지 5. stdio MCP vs HTTP MCP 구분 (핵심 반전) 6. 실제 서비스별 비교 사례 (Supabase/Vercel/Codex/Serena) 7. GeekNews 커뮤니티 핵심 의견 7건 8. Hacker News 핵심 의견 9건 9. 핵심 쟁점 8가지 (토론 포인트) 10. 페르소나 표 + 시뮬레이션 가이드
3KB가 나온 이유: 커뮤니티 인용 16건을 1~2줄로 압축하고, 각 논거도 핵심 문장만 남겼다. "32배 토큰 오버헤드", "월 $55 vs $3" 같은 구체적 수치는 반드시 포함 — LLM이 수치를 보면 에이전트 발언이 훨씬 날카로워진다.
시뮬레이션 요구사항
시드 데이터 외에 별도의 simulation-requirement.md를 작성했다. 시뮬레이션이 답해야 할 질문과 조건을 여기에 정의한다.
5개 핵심 질문
MCP가 사실상 표준으로 유지될까, 경쟁 프로토콜에 밀릴까?
스키마 블로트(32배 토큰 오버헤드) 문제가 해결될까?
CLI 기반 워크플로가 MCP를 대체할까, 보완할까?
엔터프라이즈 vs 스타트업에서 MCP 채택률 차이는?
한국 개발자 커뮤니티의 CLI 선호가 글로벌 트렌드에 영향을 줄까?
6개 페르소나 지정
엔터프라이즈 아키텍트 — 보안/컴플라이언스 중시, 표준화 선호
스타트업 CTO — 비용 민감, ROI 중시
프론트엔드 개발자 — Figma MCP 사용자
백엔드 개발자 — API 설계, CLI 선호 가능
오픈소스 기여자 — 표준화/호환성 중시
AI 도구 평론가/블로거 — 벤치마크 데이터 기반 분석
4개 God's Eye View 변수 (시뮬레이션 중 주입 가능한 충격 시나리오)
"OpenAI가 MCP 대항 프로토콜을 공식 발표하면?"
"MCP 스키마 블로트 해결 업데이트(MCP v2)가 출시되면?"
"Google이 Gemini CLI 전용 프로토콜을 강제하면?"
"주요 MCP 서버 3곳이 보안 취약점으로 동시 다운되면?"
시뮬레이션 시작
ex) 상기 내용대로 준비된 파일 및 프롬프트를 입력하자.
- 온톨로지 생성 시작이 된다.
1. Step 1: 온톨로지 생성 — AI가 문서를 읽는 방법
"엔진 시작" 버튼을 누르면 MiroFish가 시드 데이터를 LLM에게 보내서 엔티티(개체)와 릴레이션(관계)를 추출한다. 사람이 문서를 읽을 때 "누가 등장하고, 서로 어떤 관계인지"를 파악하는 것과 같다.
관계 타입 (8개): WORKS_FOR, PUBLISHES_ON, CRITICIZES, SUPPORTS, RESPONDS_TO, COMPETES_WITH, PROVIDES_MCP_SUPPORT, AFFILIATED_WITH
시뮬레이션 요구사항에서 정의한 6가지 페르소나(엔터프라이즈 아키텍트, 스타트업 CTO 등)가 Developer, TechnicalManager, Researcher 같은 엔티티 타입으로 자동 매핑된다. 시드에 "Perplexity CTO"라고 써두면 LLM이 TechnicalManager 타입 엔티티로 알아서 잡아낸다.
이 단계가 왜 중요한가 : GIGO 원칙
Garbage In, Garbage Out. 온톨로지가 부실하면 이후 모든 단계가 엉뚱한 방향으로 흘러간다. 시드 데이터에 "MCP", "CLI", "Eric Holmes", "Charles Chen", "GeekNews 개발자" 같은 핵심 개체가 명확히 등장해야 LLM이 정확한 엔티티를 뽑을 수 있다. 시드를 3KB로 집중한 이유가 여기에 있다 — 37KB를 넣으면 엔티티가 너무 많아져서 초점이 흐려진다.
2. Step 2: 지식 그래프 구축 — GraphRAG
온톨로지(뼈대)가 만들어졌으면, 이제 실제 데이터로 지식 그래프를 채울 차례다. MiroFish는 이 작업에 Zep Cloud를 사용한다.
시드 데이터를 배치 단위로 나눠서 Zep에 전송하면, Zep이 노드(개체)와 엣지(관계)로 이루어진 지식 그래프를 만든다. 에이전트들은 이후 시뮬레이션에서 이 그래프를 참조해서 발언한다 — 단순 프롬프트 주입이 아니라, 구조화된 지식 위에서 추론하는 셈이다.
노드/엣지 수치와 의미
지식 그래프 구축 결과 노드: 121개 | 엣지: 202개 | 스키마 타입: 10개 비용: $0 (Zep Cloud free tier)
노드 121개는 시드에 등장하는 주요 개체(MCP, CLI, Anthropic, Perplexity, Eric Holmes, GeekNews, tptacek, Supabase, Redis, PostgreSQL, grep, awk 등)다. 엣지 202개는 이들 간의 관계("Perplexity CTO가 MCP를 포기했다", "홈즈가 CLI를 지지한다" 등 구체적 주장)로 구성된다. 그래프 시각화에서 MCP가 중앙 허브 노드로 자리잡고, 찬성/반대 진영 인물들이 주변에 연결된 구조가 보인다.
그래프 시각화에서 볼 것
MiroFish UI에서 그래프를 시각화하면, "MCP"와 "CLI"가 각각 허브 노드로 나타나고 주변에 관련 엔티티가 연결되어 있다. 이 구조가 곧 시뮬레이션의 토론 축이 된다.
ex) 환경 설정으로 이동 클릭
- 시뮬레이션 인스턴스 초기화가 되며
- 에이전트 페르소나 생성을 시작한다. 생성 완료되면 다음섹션으로 넘어 가보자.
3. Step 3: 시뮬레이션 실행 — 가상 토론장
여기가 MiroFish의 핵심이다. 온톨로지와 지식 그래프를 바탕으로 가상 전문가 에이전트를 만들고, 이들이 Twitter와 Reddit에서 토론을 벌인다.
에이전트 프로필 미리보기
MiroFish가 시드 데이터에서 자동 생성한 38명의 에이전트 중 핵심 4명을 보자:
CLI 옹호 · Personholmes_786 (@Holmes) "LLM은 이미 CLI를 매우 능숙하게 사용한다. Charles Chen의 반박에도 핵심 논지는 변하지 않는다. 활동도 75%, 게시 0.25/시간, 응답 지연 2-12분." ex)
하이브리드 · TechCompanycursor_552 (@Cursor) "Cursor의 MCP 클라이언트는 MCP Prompts와 Resources를 제대로 지원하지 않는다. Vercel 사례처럼 배포는 CLI, 에러 진단은 MCP로 나뉜다는 게 현실." ex)
관찰자 · TechMediaitter_504 (@itter) "개인 개발자 vs 엔터프라이즈 엔지니어의 관점 차이를 중계. Eric Holmes의 'MCP vs CLI' 논쟁을 번역·요약하여 한국 개발자 커뮤니티에 소개." ex)
MCP 옹호 · Personhanje3765_320 (@hanje3765) "LLM 지능이 높아지면서 MCP 필요성이 모호해진다는 주장에 반박. 엔터프라이즈에서 1,000개 분산 API 키를 10개로 줄이는 중앙화 인증은 CLI로 대체 불가." ex)
나머지 34명도 각각 고유한 페르소나를 갖는다: jabber86_674(보안 전문가), charles_chen_439(AWS CLI 사례 제시), sonnet_531(MCP 표준화 옹호), 에이전트_개발자_978(제약으로서의 MCP 가치), tptacek, nvardakas, brainer, hulryung, 0xbadcafebee, develosopher, m00nlygreat, aws_cli, acek 등. 시드 데이터에서 언급된 커뮤니티 핸들과 조직을 MiroFish가 알아서 에이전트로 만들어낸 것이다.
50라운드 설정 + 듀얼 플랫폼
시뮬레이션 설정에서 라운드 수를 50으로, 플랫폼을 Twitter + Reddit 듀얼로 잡는다.
Twitter는 빠른 반응과 진영 대립 관찰에, Reddit은 깊은 기술 토론과 벤치마크 비교에 적합하다.
시뮬레이션 중 벌어지는 일: 38개 콘텐츠
시뮬레이션을 시작하면 에이전트들이 알아서 포스트를 쓰고, 서로의 포스트에 반응하기 시작한다.
주요 발언 하이라이트
에이전트들이 실제로 생성한 포스트 원문이다. 사람이 쓴 게 아니라, LLM이 각 에이전트의 페르소나에 맞춰 자동으로 만든 것이다:
ex)
실제 시뮬레이션 포스트 (원문)
CLI 옹호m00nlygreat_495 (@m00nlygreat): "MCP is Dead. LLMs already know how to use CLI perfectly well. The 32x token overhead (44,026 vs 1,365 tokens) is a fatal flaw that no enterprise feature can justify. I've been using Claude Code with raw CLI for months — it's faster, cheaper, and more reliable. The MCP hype was a solution looking for a problem." #MCPisDead #CLI
MCP 옹호 (의외의 반전)eric_holmes_290 (@Eric Holmes): "Holmes는 stdio 전송 문제에 대해 맞습니다. 하지만 'MCP is Dead'는 극단적 결론입니다. MCP의 진정한 가치는 보안 경계, 감사 로그, 엔터프라이즈 컴플라이언스에 있습니다. CLI는 '자유'를 주지만, 기업 환경에서 그 자유는 리스크입니다. MCP is Dead; Long Live MCP!" #MCP #엔터프라이즈
조건부/하이브리드charles_chen_543 (@Charles Chen): "Interesting debate. As someone who evaluated both for our 200-person org: CLI is great for prototyping, but MCP's structured tool boundaries are non-negotiable for production. The token cost is real, but compliance cost is higher. That said, 32x overhead needs to be addressed in v2." #hybrid #enterprise
보안 경고보안_전문가_565 (@보안전문가): "MCP 서버는 새로운 공격 표면입니다. 초기 버전에 보안이 고려되지 않았고, OAuth가 나중에 급하게 붙여진 것은 우려스럽습니다. DPoP와 Workload Identity가 2026 로드맵에 포함되었지만, 아직 검증되지 않았습니다. 엔터프라이즈 도입 전 보안 감사가 필수입니다." #보안 #MCP취약점
조건부brainer_622 (@brainer): "우리 팀은 Figma MCP를 사용 중인데 디자인-개발 연동에서 확실히 유용합니다. 하지만 백엔드 작업에서는 여전히 CLI가 더 빠릅니다. '프론트엔드=MCP, 백엔드=CLI'로 나뉘는 건 아닌데... 상황에 따라 선택하는 게 맞는 것 같습니다." #FigmaMCP #하이브리드
CLI 실사용 경험jamsya_429 (@jamsya): "claude code가 MCP 설치 없이 aws cli를 직접 호출해서 필요한 리소스를 가져오는 걸 봤습니다. 실제로 동작하더라고요. MCP가 필요한 경우가 언제인지 진지하게 고민하게 됩니다." #claudecode #awscli #MCP
MCP 옹호 (플랫폼 독립성)kasey_junk_780 (@kasey_junk): "MCP를 '코딩 에이전트'로만 보면 CLI가 이깁니다. 하지만 코딩 에이전트는 전체 에이전트 유스케이스의 작은 부분일 뿐입니다. iPad, Android 태블릿 사용자들에게 CLI 접근권은 없습니다. MCP는 플랫폼 독립성을 보장합니다." #MCP #플랫폼독립성
주목할 점이 두 가지 정도 나온 것 같다.
첫째, 조건부 입장의 itter 에이전트가 9라운드(Twitter)에서 Charles Chen의 타협적 포스트에 직접 좋아요를 눌렀다 — "CLI는 프로토타이핑에 좋지만, MCP의 구조화된 경계는 프로덕션에서 타협 불가"라는 요지의 포스트에 공감이 모인 것이다.
둘째, Eric Holmes 에이전트(eric_holmes_290)가 원래 캐릭터 설정(CLI 강경론자)과 정반대로 MCP를 옹호하는 발언을 생성했다 — "MCP is Dead; Long Live MCP!"를 외치며 Charles Chen의 반박 관점을 내면화했다. LLM이 시드 문서에서 두 인물의 논거를 읽고 더 설득력 있는 쪽으로 캐릭터를 재해석한 창발적 현상이다.
시뮬레이션이 끝나면 ReportAgent가 모든 에이전트의 포스트와 상호작용을 분석해서 종합 보고서를 만든다.
[ 결과 보고서 생성 시작]을 클릭하자.
ReportAgent가 작동하는 방식: ReACT 패턴
ReportAgent는 단순히 포스트를 요약하는 게 아니다. ReACT(Reasoning + Acting) 패턴으로 돌아간다:
도구 호출: Deep Insight(심층 분석), Panorama Search(전체 검색), Agent Interview(에이전트 인터뷰) 등의 도구를 자동 호출
분석: 도구 결과를 종합해서 패턴과 인사이트 도출
작성: 분석 결과를 구조화된 보고서로 정리
ReportAgent는 섹션별로 6~8명의 에이전트를 심층 인터뷰하면서 보고서를 만든다. 단순 집계가 아니라, 에이전트 개별 관점을 다시 확인하는 과정이 들어가 있다.
보고서 5개 섹션 요약
보고서: "2026 MCP vs CLI 대논쟁: 표준 경쟁과 생태계 분화 예측 보고서" (5섹션 완성) 시뮬레이션 ID: sim_3203834b2934 | 보고서 ID: report_638bb6a90857 요약: MCP는 엔터프라이즈 시장에서 사실상 표준을 유지하지만, 32배 토큰 오버헤드 문제는 CLI-하이브리드 워크플로의 병존을 초래하며 한국 커뮤니티가 의외의 영향력을 행사하는 분화된 미래가 도래한다.
섹션 1: 표준 경쟁의 귀결: MCP의 '불완전한 승리' 엔터프라이즈 MCP 채택률 78% vs 스타트업 34%로 시장이 명확하게 분화됐다. MCP가 엔터프라이즈 표준으로 승인되었지만, CLI는 비용 효율성과 개발자 자율성의 영역에서 강력한 대안으로 존재한다. "2026년의 표준 경쟁은 승자독식이 아니었습니다."
섹션 2: 스키마 블로트와 MCP v2: 기술적 병목의 부분적 해소 MCP v2 출시로 토큰 사용량이 44,026 → 26,415 토큰(40% 감소)으로 줄었지만, CLI 대비 여전히 19배 차이가 난다. 부분적 해소는 됐으나 근본 문제는 해결되지 않았다는 평가.
섹션 3: 시장 분화: 엔터프라이즈-MCP vs 스타트업-CLI 하이브리드 "개발=CLI, 고객대면=MCP" 하이브리드 구조가 사실상의 업계 표준으로 정착됐다. 엔터프라이즈는 보안/컴플라이언스 때문에 MCP를 유지하고, 스타트업은 비용 효율을 위해 CLI 하이브리드를 선택하는 분화가 확인됐다.
섹션 4: 한국 커뮤니티의 의외의 영향력: CLI 선호가 만든 '역수출' 한국 기술 블로그의 토큰 오버헤드 비교 분석과 CLI 워크플로 최적화 가이드가 글로벌 Reddit 토론에서 반복 인용됐다. "한국 기술 블로그의 품질은 예상을 뛰어넘었습니다." 지역 커뮤니티의 실용주의가 글로벌 생태계에 역수출된 사례.
섹션 5: 창발적 위험: 중앙화 구조의 단일 실패점 주요 MCP 서버 동시 다운 사건이 현실화되면서 중앙화 구조의 단일 실패점 위험이 확인됐다. "MCP-CLI 병존 구조는 비효율적으로 보일 수 있지만, 실제로는 생태계의 안전망입니다." 창발적 위험 대비책으로서 하이브리드 구조의 가치가 재평가됐다.
핵심 인사이트 3가지
인사이트 1: "하이브리드 전략"이 합의점으로 수렴 36명의 에이전트가 토론한 결과, "개발 워크플로에는 CLI를, 고객 대면/컴플라이언스 민감 기능에는 MCP를"이라는 하이브리드 전략으로 의견이 모였다. 이 구조는 비효율처럼 보이지만 생태계 안전망으로 재평가됐다.
인사이트 2: MCP v2도 완전한 해결책이 아니다 MCP v2로 토큰이 40% 줄었지만 CLI 대비 19배 차이는 유지된다. 찬성 진영조차 이 문제를 부정하지 못했다. MCP는 엔터프라이즈 전용 도구로 자리잡되, CLI가 개발 영역에서 주류를 유지하는 구조가 굳어지고 있다.
인사이트 3: 한국 개발자 커뮤니티가 글로벌에 역수출 한국 커뮤니티의 실용주의적 CLI 선호가 글로벌 Reddit 토론에서 반복 인용되는 역수출 현상이 발생했다. 시드에 한국 관련 데이터를 구체적으로 넣은 효과가 보고서 독립 섹션(섹션 4)으로 확인됐다.
보고서 생성 결과 섹션: 5개 (100% 완료) | 주요 수치: 엔터프라이즈 78% vs 스타트업 34% 채택률 격차 소요 시간: ~23분 시뮬레이션 ID: sim_3203834b2934 | 보고서 ID: report_638bb6a90857
5. Step 5: 심층 대화 — 보고서 Agent에게 질문하기
보고서가 나온 뒤 "보고서 Agent와 대화" 버튼을 누르면 ReportAgent에게 후속 질문을 던질 수 있다. 단순 FAQ가 아니라, 시뮬레이션 데이터 전체를 참조해서 답한다.
추천 질문 3개와 예상 답변 방향
질문 1: "MCP v2가 토큰 오버헤드를 해결하면 CLI 진영이 전향할까?" → 보고서 섹션 2를 바탕으로, MCP v2가 44,026 → 26,415 토큰(40% 감소)으로 개선했지만 여전히 CLI 대비 19배 격차가 남는다고 설명한다. "완화"는 됐지만 "해결"은 아니므로, CLI 진영의 논거는 계속 유효하며 하이브리드 전략이 오히려 더 정교해지는 방향을 답할 것이다.
ex) 실제 답변
질문 2: "한국 개발자 커뮤니티의 CLI 선호가 글로벌에 영향을 줄 근거는?" → 보고서 섹션 4의 '역수출' 데이터를 인용한다. 한국 기술 블로그의 토큰 오버헤드 비교분석·CLI 워크플로 가이드가 글로벌 Reddit 토론에서 반복 인용되고, 주요 CLI 오픈소스 프로젝트에서 한국 개발자 기여 비중이 인구 비례를 훨씬 상회한다는 내용을 구체적으로 제시할 것이다.
ex) 실제 답변
질문 3: "2027년에 OpenAI가 경쟁 표준을 내놓으면 MCP는 어떻게 되나?" → (예상) 섹션 1 '불완전한 승리' 근거로 네트워크 효과 분석, 스타트업 이탈 리스크 언급할 것으로 예상했다.
ex) 실제 답변 "보고서는 2026년 3월 시뮬레이션으로, 2027년 OpenAI 경쟁 표준 시나리오에 대한 직접적 결과는 없습니다. 추가 검색을 수행하겠습니다."
예상과 달랐다. Agent는 근거 없는 미래 예측 대신, 자신이 가진 데이터의 시간적 한계(2026년 3월 시뮬레이션)를 먼저 솔직하게 밝혔다. 이게 오히려 잘 설계된 RAG Agent의 특징이다 — 데이터 범위를 벗어난 질문에 환각으로 채우지 않는다.
개별 에이전트 인터뷰 vs 보고서 Agent 대화
MiroFish UI에서는 에이전트 프로필 클릭 후 개별 대화를 시도할 수 있는 인터페이스가 있다. 다만 실제 사용 결과:
방법
실제 동작
비고
개별 에이전트 인터뷰
400 에러 발생 — 현재 버전에서 동작하지 않음
시뮬레이션 실행 중에만 가능 — 완료 후에는 프로세스가 종료되어 IPC 연결 불가
보고서 Agent 대화
정상 동작 — 전체 시뮬레이션 데이터를 참조해서 종합 답변
Step 5의 실질적 기능
왜 400 에러가 발생하는가: 개별 에이전트 인터뷰는 살아있는 시뮬레이션 프로세스에 IPC 소켓으로 명령을 전달하는 방식이다. 시뮬레이션이 완료되면 env_status.json의 상태가 "alive" → "stopped"로 바뀌고, 백엔드는 이 상태를 확인해서 즉시 400을 반환한다. 즉, 설계상 시뮬레이션 진행 도중에만 사용 가능한 기능이다. 시뮬레이션이 끝난 뒤 후속 대화는 보고서 Agent 대화를 사용해야 할 것 같다.
ex)
6. 결과 해석: MCP의 미래는?
시뮬레이션이 도출한 핵심 결론 3가지
결론 1: MCP는 "범용 표준"이 아니라 "엔터프라이즈 표준"으로 수렴 MCP가 기술적 한계(토큰 오버헤드)와 비용 문제로 범용 표준이 되기 어렵고, 보안/컴플라이언스가 중요한 엔터프라이즈 환경에 특화될 가능성이 크다.
결론 2: "하이브리드 전략"이 합의점으로 수렴 찬성, 반대 양 진영 모두 "CLI와 MCP는 적이 아니라 역할이 다르다"는 데 의견이 모였다. 개발 워크플로에는 CLI를, 고객 대면/규정 준수에는 MCP를 쓰는 것이 2026년 가장 효율적인 팀의 선택이라는 합의.
결론 3: 거대 기술 기업의 전략이 최대 변수 2027년에 OpenAI나 Google이 경쟁 프로토콜을 내놓으면 MCP 생태계가 파편화될 수 있다. Anthropic이 MCP 표준화를 주도하고 있지만, 독점이 아닌 협력 모델이 필요하다는 게 시뮬레이션의 경고다.
한국 개발자 커뮤니티의 독특한 위치
보고서 섹션 4에서 따로 다룬 내용이다. 한국 개발자 커뮤니티의 CLI 선호는 단순한 지역 특수성이 아니라, "우아한 구조보다 빨리 돌고 토큰을 덜 먹는 구조가 사랑받는 시대"라는 글로벌 실용주의 트렌드의 선행 지표일 수 있다.
보고서 섹션 4에 따르면 한국 기술 블로그의 토큰 오버헤드 비교 분석과 CLI 워크플로 가이드가 글로벌 Reddit 토론에서 반복 인용됐고, 주요 CLI 오픈소스 프로젝트에서 한국 개발자의 기여 비중이 인구 비례를 훨씬 상회하는 것으로 시뮬레이션에서 관찰됐다.
주의: 이 결론들은 MiroFish 시뮬레이션의 결과이지, 확정된 미래 예측이 아니다. MiroFish는 "예측 도구"라기보다 "다양한 관점의 시뮬레이션 토론 엔진"이다. 내가 넣은 시드 데이터를 다양한 전문가 관점에서 재해석하는 것이 진짜 가치를 가져오지 않을까???
주의사항
1. Docker 메모리: Docker Desktop 기본 메모리(7.7GB)로는 36에이전트 장시간 실행이 불안정할 수 있다. Apple Silicon + QEMU 레이어에서는 특히 메모리 압박이 크다. 프로덕션에서는 16GB 이상 할당하거나, x86 네이티브 서버를 권장한다.
결론
3KB 시드 파일 하나로 36명의 가상 전문가가 15라운드 동안 실제 토론을 벌였다.
MiroFish의 가치는 "예측"이 아니라 "내가 미처 생각하지 못한 관점을 발견하는 것"이다. MCP 논쟁에 대해 나는 "하이브리드가 답이겠지"라고 막연히 생각했는데, 시뮬레이션은 그 하이브리드의 구체적 형태(개발=CLI, 고객대면=MCP)와 함께 예상치 못한 반전도 만들어냈다. itter 에이전트가 9라운드에서 Charles Chen의 타협 포스트에 좋아요를 누른 것처럼—시뮬레이션은 사람 논쟁처럼 입장이 흔들린다.
시드 데이터만 바꾸면 어떤 논쟁이든 시뮬레이션할 수 있다. 한번 돌려보길 권한다.
자주 묻는 질문 (FAQ)
Q. MiroFish 시뮬레이션을 시작하기 위한 시드 데이터는 어떻게 준비하나요?
A. 시드 데이터는 마크다운 파일 하나로 준비합니다. 찬성·반대·조건부 진영별 논거를 명확하게 정리하는 것이 핵심입니다. MCP 논쟁의 경우 찬성 5개(32개+ 플랫폼 지원, 엔터프라이즈 필수 등), 반대 6개(32배 토큰 오버헤드, CLI 우위 등), 조건부 논거를 구조화하여 seed_mcp_vs_cli.md 파일로 작성했습니다.
Q. MiroFish의 온톨로지 생성과 지식 그래프 단계는 무엇을 하나요?
A. Step 1 온톨로지 생성에서는 AI가 시드 문서를 읽고 핵심 개념·관계·엔티티를 추출하여 구조화합니다. Step 2 지식 그래프 구축(GraphRAG)에서는 이 온톨로지를 기반으로 개념 간 연결 관계를 그래프로 만들어 가상 에이전트들이 참조할 지식 베이스를 완성합니다. 이 두 단계의 품질이 이후 시뮬레이션 토론의 깊이를 결정합니다.
