Project Overview · v2

swarm56 — 프로젝트 개요

핵심: 이종 멀티에이전트(hetero-multi-agent) 협업 워크플로우 — swarm56.com은 그 산출물
문서 v2
기준일 2026-07-09
라이브 swarm56.com
이전 버전 PROJECT_OVERVIEW.html (보존)
v2 변경 요약 (2026-07-09) — 백오피스 프로젝트 카드 추가 기능으로 아키텍처 3건 변경: ① Work/Projects 카드 하드코딩 → SQLite ProjectCard 테이블 ② 프로젝트 문서 HTML 서빙 Next public/ → nginx /docs/ alias(런타임 업로드) ③ "웹=볼트 읽기전용" 원칙에 project/ 한정 쓰기 예외 신설. + 온디맨드 클리핑 트리거 유닛 설치 완료(2026-07-03).
1 · 프로젝트 개요
목적 — 흩어진 활동을 모으는 퍼스널 소셜미디어 허브. 원종석은 네이버블로그·GitHub·YouTube·Notion·Instagram·Swarm 등 여러 채널에 글·코드·영상·메모를 흩어 발행한다. swarm56.com은 이 흩어진 활동을 한 곳에 자동으로 모아, 방문자가 "원종석이 무엇을 생각하고 무엇을 하는가" — 철학과 활동 흐름을 한눈에 보게 한다. 채널마다 쪼개진 정체성을 하나의 큐레이션된 피드로 통합하는 것이 1차 목적이다.

두 층위① 산출물(Product): 위 목적을 구현한 swarm56.com(8채널 → 자동 수집 → 통합 카드 피드 + Work/Projects 문서 카드). ② 핵심 주제(Process / 연구): 그것을 만드는 과정 자체 — 이종 멀티에이전트 워크플로우(Peter의 평소 연구 주제와 직결).

산출물의 목적은 "흩어진 나를 한 곳에 모으는 허브", 그 과정의 핵심은 "이종 에이전트들이 협업해 만든 방법" — 요구사항 정리부터 디자인·구현·검증까지 전 과정을 에이전트들이 릴레이로 수행했다.

2 · ★ Hetero-Multi-Agent Workflow (핵심)

단일 AI에 전부 맡기지 않고, 이종(異種)의 AI 에이전트·도구오케스트레이션 / 디자인 / 구현 / 검증으로 나눠 협업. 강점이 다른 모델·도구를 조합하고 역할 간 견제·검증으로 신뢰성 확보.

2.1 협업 변천사 (실제 진행)

1
요구사항·초기 설계 — Antigravity
Peter 요구사항을 Antigravity(Google Gemini 에이전트)가 청취·정리 → 워크플로우 설계 + 디자인툴(Relume·V0) 선정. 초기 오케스트레이터·아키텍트.
2
오케스트레이터 공석
협업 중 Antigravity 교체·하차 → 오케스트레이터 자리 비움.
3
체제 재편 — Peter + ChatGPT(Simone) + Claude
이전 프로젝트처럼 Peter+ChatGPT 공동 오케스트레이션, Peter가 에이전트 간 릴레이, Claude가 구현.
4
1차 검증 → 미완 발견 — Codex
화면엔 카드가 떠 "완료" 보고됐으나, 독립 검증서 구현 미완·재현불가·배포 미연결 다수 발견(Prisma P3005, /vault Nginx 누락, systemd 트리거 부재, lint 미실행, 세션 secret fallback 등). "보이는 완료 ≠ 실제 완료."
5
Opus 교체 → 재구현·재검증
구현 모델을 Opus로 올려 미완분 수정·재검증. 이 경험이 Agentic Engineering Execution Protocol(구현·동결·검증·수정·재검증 절차)을 낳음.
6
운영 클로징 → 백오피스 확장 v2
라이브 후 트리거 버튼 미작동 발견(2026-07-03) — 검증이 남긴 "서버 실행 미검증" 후속 항목의 미이행이 원인(체크리스트·검증은 정확했음) → 복구 + 배포 후 서버 스모크 테스트 교훈. 이어 프로젝트 카드 추가를 백오피스 기능화(2026-07-09).
요구사항·디자인·구현·검증 전 과정이 멀티에이전트 협업(사람 Peter가 릴레이). 핵심 교훈: 에이전트 말=가설 · commit=검증대상 · 실행로그=증거 · 독립검증=판정 · Owner=최종승인. 좋은 구현 = Functional·Conformance·Reproducibility·Operational 4기준 충족. (Notion "'완료했습니다'를 믿지 않게 된 날") — Peter의 연구 Context-Preserving Multi-Assistant Collaboration Layer(맥락 + 책임·증거의 연속성)와 직결.
검증 자체도 멀티에이전트 — Claude가 검증 기준(VERIFICATION_CHECKLIST_v2.md) 작성 → Codex가 그에 의거 독립 검증(라운드별 commit SHA 고정·증거 기반·delta 재검증) → ChatGPT(Simone)가 Peter 자문역(체크리스트·진단 검토). 구현뿐 아니라 검증 절차 자체가 역할 분담된 멀티에이전트.

2.2 역할별 참여 에이전트

에이전트 / 도구종류역할시기/단계
AntigravityGoogle Gemini 에이전트초기 오케스트레이터·아키텍트: 요구사항 정리·워크플로우 설계·디자인툴 선정초기 (교체됨)
Peter (원종석)인간오케스트레이터(공동)·결정권자·릴레이전 단계
ChatGPT (Simone)OpenAI GPT공동 오케스트레이터 + Peter 자문역(설계·체크리스트 검토)오케스트레이션·자문
Relume DESIGN디자인 AI사이트 구조·와이어프레임·컴포넌트디자인
V0 by Vercel DESIGN디자인 AIUI 컴포넌트 생성(React/Tailwind)디자인
Claude (투투/OpenClaw)코딩 AI구현·통합·문서화 + 검증 체크리스트 작성구현·검증
Codex검증 AI체크리스트 의거 독립 검증(증거 기반)검증
Hermes (헤라)코딩 AI(별도 Claude)연구 보조보조

"이종(hetero)" = 서로 다른 벤더·종류의 AI(Antigravity·Relume·V0·Claude·Codex·GPT)를 한 워크플로우에 조합.

2.3 설계 철학 — Boris Cherny "Loop Engineering"

이 워크플로우·시스템은 Boris Cherny의 Loop Engineering 철학을 설계 단계에서 반영했다 — 그래서 단계별 상태저장 + 지속 검증을 계속한다.

  • 상태 영속성 — 각 단계 출력을 외부 기록, 체크포인트로 재개 가능. (옵시디언 볼트 = 메인 DB이자 상태 저장소)
  • 단계별 검증 — 다음 단계 진입 전 검증(Codex 게이트, 검증 체크리스트) + 배포 후 서버 스모크 테스트(v2 추가 — 2026-07-03 교훈).
  • 탈출/재시도 규칙 · 멱등성·재개 가능(클리퍼 재실행 안전) · 단방향 흐름 + 부작용 격리.

2.4 거버넌스 (신뢰성 장치)

CLAUDE.md 헌법: 승인 추론 금지 · 계획≠실행 · 행위자 명시 · 실행증거 없는 완료보고 금지 · 메모리 무결성 · 구현(Claude)/검증(Codex) 분리. 문서는 버전 신규 작성 + 원본 보존.

2.5 협업 통신

Slack #all-agent-collab(핸드오프 실험) · Notion Journal(업무일지·위반사례·Work Note) · 검증 산출물(VERIFICATION_CHECKLIST_v2.md).

3 · 요구사항

3.1 목적·배경 (왜 만드나)

  • 통합(Hub) — 8개 채널에 흩어진 글·활동을 한 곳에 모아 보여준다.
  • 정체성 — 방문자가 원종석의 철학·관심사·활동 흐름을 한눈에 파악.
  • 최신성 — 새 글이 손 안 대고 자동(일 1회) 반영.
  • 소유·통제 — 원본은 옵시디언 볼트에 영속 보관, 노출은 내가 통제(삭제/복원/편집).
  • 자가 운영 v2 — 프로젝트 문서 카드를 개발자 손 없이 백오피스에서 직접 추가(코드 수정·재배포 불필요).

3.2 기능

  • 채널별 카드 피드 + 채널 필터, 카드 → 원문 링크(본문 이미지 포함).
  • Work/Projects 프로젝트 카드 v2 — 백오피스에서 추가(제목·요약·HTML 문서·MD 문서·태그), 홈은 DB에서 렌더링.
  • 백오피스(/admin): 로그인, 피드 카드 삭제/복원/편집, 프로젝트 카드 추가, 수집 이력(SyncRun), "지금 클리핑"/"강제 갱신" 수동 트리거(요청 접수 배너), 감사 로그(KST).
  • 삭제 의도 영속(재수집해도 부활 안 함), 일 1회 자동 수집.

3.3 비기능

단방향 데이터 흐름 · 멱등성·재개 가능 · 볼트 쓰기 = 에이전트(raw/) + 백오피스 업로드(project/ 한정 예외), 웹의 raw/ 접근은 코드상 불가 · 비밀은 env로만 · 개인 규모(1GB VPS) 운영.

★ 핵심 의사결정 — 원칙 개정(2026-07-09) — v1 아키텍처 불변식 "홈피/백오피스는 볼트 읽기전용"을 백오피스 카드 추가를 위해 project/(지식그래프, 피드 파생 대상 밖) 한정 쓰기 예외로 개정. 두 안을 비교한 뒤 Owner가 결정: "간단하게 구현했다가 나중에 필요하면 원칙대로 바꾸지 뭐. 이번에는 간단하게."
직접 쓰기 (project/ 한정 예외) — 채택대기폴더+systemd 릴레이 (예외 없음)
원칙한정 예외 1개 생김무손상
구현/부품단순 (코드 몇 줄).path 유닛+스크립트 추가, 반영 수 초 비동기
실질 위험낮음 (raw/ 접근은 코드상 차단)더 낮음 (웹은 볼트 접근 자체가 없음)

복귀 경로: 원칙 무손상이 필요해지면 중립 대기폴더 + systemd .path 릴레이(기존 트리거 패턴 재사용)로 전환 — 재설계 트리거로 정본에 등재. 상세: BACKOFFICE_FEATURE_CONTEXT_v2.md §2-③.

4 · 기술 스펙
영역스택
홈피/백오피스Next.js 16, React 19, TypeScript, Tailwind v4
ORM/DBPrisma 6.19, SQLite
클리핑 에이전트Python 3.12 (requests, beautifulsoup4, markdownify, Pillow)
발췌LLM 다중 provider → truncation fallback
볼트 / 동기화옵시디언(Markdown+이미지) / CouchDB livesync(sync.swarm56.com)
디자인Relume(구조/와이어프레임), V0 by Vercel(UI 컴포넌트)
배포AWS Lightsail(Ubuntu), systemd, Nginx, Let's Encrypt
5 · 아키텍처 — 채널에서 허브까지의 데이터 흐름

이 프로젝트의 심장은 "8개 채널에 흩어진 글이 어떻게 자동으로 홈페이지의 통합 피드가 되는가"다. 흐름은 단방향이며, 각 단계가 파일/DB에 상태를 남겨(상태 영속성) 언제든 재개할 수 있다. v2에서 관리 흐름(프로젝트 카드 추가)이 더해졌고 피드 파이프라인과 격리되어 있다.

5.1 전체 데이터 흐름 (수집 → 허브)

① 8개 소셜 채널 (가로로 통합 수집) 네이버블로그 · GitHub · YouTube · Notion · Swarm · Instagram · LinkedIn* · Facebook* ② 클리핑 에이전트 ──── collectors/ 채널별 수집기 Phase A 전문 md + 본문이미지(webp) + 링크치환 + LLM 발췌 (dedup = content_hash) ③ 옵시디언 볼트 = 메인 DB ──── raw/<채널>/*.md + _assets/*.webp + project/*.md · 원본 영속 보관 Phase B 파생(raw/만) — 활성 suppression URL 스킵 ④ SQLite 파생캐시 ──── site-v5.db · FeedCard + ProjectCard ├─────────────────────┐ ⑤ 홈페이지 swarm56.com 백오피스 /admin 통합 카드 피드 + Work/Projects 피드: 삭제·복원·편집 / 프로젝트 카드: 추가 ├─ 삭제의도 → SuppressionRecord (DB) ├─ 수동 트리거 파일 → systemd .path → 에이전트 재실행 └─ 카드 추가(v2) ProjectCard insert + HTML→docs디렉토리 + MD→볼트 project/ ⚠️한정 예외

단방향 흐름. Phase A=클립(중복은 content_hash로 제거), Phase B=파생(raw/만 대상). 관리 흐름(v2)=프로젝트 카드 추가 — 피드 파이프라인과 완전 격리(raw/ 무접촉), 감사 로그 PROJECT_ADD. * LinkedIn·Facebook은 현재 빈 채널.

5.2 삭제 영속성 — "방식 B" (tombstone)

[삭제] 카드 삭제 ──▶ FeedCard 제거 + 활성 SuppressionRecord (tombstone) 재파생 / 재수집 시 suppression URL 스킵 ──▶ 부활하지 않음 ✓ [복원] tombstone 해제 + 볼트 md 재삽입 ──▶ 다시 노출

삭제 키 = originalUrl. 모든 변경은 원자적 트랜잭션 — 재실행해도 안전(멱등). 피드 카드에만 해당(프로젝트 카드는 추가 전용).

5.3 배포 토폴로지

방문자 ── HTTPS 443 ──▶ Nginx (+ Let's Encrypt) ├── reverse proxy :3000 ──▶ swarm56-web (Next.js) ──▶ site-v5.db ├── /vault/ alias ──▶ 볼트 이미지 (webp) ├── /thumbnails/ alias ──▶ 썸네일 └── /docs/ alias (v2) ──▶ 프로젝트 문서 HTML · 런타임 업로드 즉시 서빙 swarm56-agent.timer (매일 04:00 UTC) ──▶ 클리핑 에이전트 ──▶ 옵시디언 볼트 ──▶ (파생) site-v5.db swarm56-clip/force.path (온디맨드 · 2026-07-03 설치) ──▶ 클리핑 에이전트

AWS Lightsail VPS (Ubuntu) · 앱 /opt/swarm56/app · 볼트 /var/lib/swarm56/vault-v5 · DB /var/lib/swarm56/web/site-v5.db · 문서 /var/lib/swarm56/web/docs. (서버 주소·SSH는 로컬 전용 문서·메모리 참조)

6 · 모듈별 역할

6.1 클리핑 에이전트 (agent/, Python)

모듈역할
main.pyPhase A/B 오케스트레이터, SWARM56_FORCE=1=강제 재클립
collectors/채널별 수집(naver_blog·github·youtube·notion·swarm·instagram·facebook)
vault.py · db.py볼트 입출력·dedup / frontmatter→FeedCard 파생·suppression·SyncRun
images.py · excerpt.py본문이미지→webp(SSRF·재인코딩) / LLM 발췌→truncation
settings.pyenv 설정(경로·토큰·키·상한)

6.2 홈피/백오피스 (personal-brand-hub/, Next.js)

모듈역할
app/page.tsx · app/admin/홈페이지 / 백오피스(가드·로그인·서버액션·edit-card·카드 추가 폼)
components/hero·about·header·footer·feed-card · projects-section = DB 렌더링 v2
lib/admin-repo.ts삭제(방식B)·복원·편집·트리거·감사로그 + listProjectCards·addProjectCard(업로드 검증·롤백) v2
lib/auth.ts · feed-repository.ts · md-frontmatter.ts인증(bcrypt·세션·rate limit) / 조회 / 볼트 파싱(복원)
prisma/schema.prismaFeedCard · ProjectCard v2 · SuppressionRecord · AdminAudit · SyncRun
7 · 채널 현황
채널상태수집
네이버블로그·GitHub·YouTube·Notion·Swarm·InstagramLIVERSS / API / 스크래핑
LinkedIn · Facebook빈 채널공식 API 제약 → UI 플레이스홀더(자동수집 안 함)
8 · 향후 로드맵

옵시디언 지식그래프 시각화 NEXT

볼트 노드/링크를 홈피에 그래프뷰로 (직접구현 / Quartz / Obsidian Publish). 볼트가 이미 서버에 있어 거기서 추출 — 백오피스 카드 추가가 MD를 project/에 쌓으므로 지식그래프 소스가 자동 축적됨.

RAG NEXT

볼트 임베딩 → 의미검색·질의응답("내 글에게 물어보기").

그 외

  • 미연동 채널(LinkedIn·Facebook) → 백오피스 수동 등록 검토.
  • 프로젝트 카드 편집·삭제 UI(필요 시) · 볼트 쓰기 릴레이 전환(원칙 무손상 필요 시).
  • GitHub 릴리스 수집, 토큰 rotate, SSH 키 repo 밖 이동 · 잠재 이슈는 KNOWN_ISSUES_v2.md.
  • 트리거 path-unit 설치완료(2026-07-03).
9 · 운영 메모
  • 서버: AWS Lightsail(Ubuntu). 앱 /opt/swarm56/app(npm start), DB site-v5.db, 볼트 vault-v5, 문서 /var/lib/swarm56/web/docs, 에이전트 /opt/swarm56/agent. systemd swarm56-web·swarm56-agent.timer·swarm56-clip/force.{path,service}. 접속 정보는 로컬 전용 문서·메모리 참조.
  • 배포: surgical in-place — v5build git pull → 변경 파일만 cp → npm run build → restart → DEPLOYED_SHA 갱신. dir 전체 swap 금지(.env 보호).
  • 프로젝트 카드 추가는 배포 불필요/admin에서 직접(런북: BACKOFFICE_FEATURE_CONTEXT_v2.md §6).
  • 롤백: app.old-*·구 DB·백업 보존. 문구 수정: components/홈피_문구_수정가이드.md.