시스템 아키텍처 개요
STT → PHL Token → MCP Chain → Artifact → Deploy (GitHub Pages + YouTube + Telegram)핵심 컴포넌트
| 계층 | 컴포넌트 | 기술 |
|---|---|---|
| 입력 | STT (음성인식) | Whisper / Gemini / RVC |
| 프로토콜 | PHL 엔진 | Python FastMCP · 6개 도구 · 8단계 사이클 |
| 분석 | 10개 MCP 서버 | Python + JSON-RPC |
| 생성 | 15개 Generator | 프롬프트 템플릿 + LLM |
| 저장 | 28개 GitHub 레포 | Git + GitHub Pages |
| 배포 | YouTube 15채널 | upload.cjs v2.0 + OAuth2 |
| 알림 | Discord 28채널 + Telegram | Webhook + Bot API |
데이터 흐름
- 음성 입력 → STT → 텍스트 로그
- PHL 토큰 자동감지 (phl_detect)
- MCP 체인 실행 (produce_episode)
- 3종 아티팩트 생성 (HTML + Script + Whitepaper)
- GitHub Pages 배포
- YouTube 업로드 (pending → upload → done)
- Telegram 알림
표의 "10개 MCP 서버"는 실측과 다르다 — 갱신
이 명세서 작성 시점엔 10개였지만, 2026-07-09 기준 실제 .mcp.json 등록 서버는 13개(political-mcp, philosophy-counter, football-model, edu-mcp, media-mcp, branch-philosophy-mcp, identity-mcp, terminal-condition-mcp, dollar-system-mcp, parksy-finance-mcp, phl-engine, season1-pipeline, mcp-parksy-module-gallery)다. 스모크 테스트로 12개(Python 서버) 전수 확인 — initialize+tools/list 핸드셰이크 전부 통과. 기술 명세서 같은 "고정 스펙" 문서일수록 숫자가 빠르게 낡는다는 걸 이 문서 자체가 보여준다.
파이프라인의 약한 고리는 5-6단계 사이였다
1~4단계(STT→토큰→MCP체인→아티팩트)는 로컬에서 자동으로 돈다. 5단계(GitHub Pages 배포)까지도 git push 한 번으로 해결된다. 실제로 지연이 생기는 지점은 5→6단계 사이 — GitHub Pages 배포 자체가 즉시 반영되지 않고 "queued → in_progress → success" 3단계 큐를 거치는데, 이 큐 대기시간이 이 파이프라인에서 유일하게 로컬에서 통제 불가능한 구간이다.
PHL-Spec#기술명세#아키텍처