🔍 본질 — 90% 사장이 잘못 고른다

🛠 워크플로우 — 풀 사이클 5 단계

발견(Code) → 프로토타입(Code) → 검증(사람) → 자율화(Code→Cowork) → 운영(Cowork) → 루프.

Cowork는 Code가 만든 코드를 운영한다. Code는 Cowork가 운영하는 시스템을 분석한다.

💼 실무 — JANDA 6개월 비용

🎯 Claude Code · Cowork 장점과 융합 — 잔다의 결합 패턴

강.4 본문에서 3 인터페이스를 봤다. 그 중 Code와 Cowork의 결합이 잔다의 핵심이다. 각자 잘하는 것이 다르고, 리미트리스맨은 둘을 융합해서 진짜 시스템을 만들었다.

💻 Claude Code의 장점 — 동료 AI

• 빠른 프로토타입 — 시안·HTML·코드를 5분에 만들고 즉시 시운전. 사장이 옆에서 함께 보면서 조정.
• 사람 개입 가능 — 매 단계마다 멈추고 확인 가능. 안전·정확도 최상.
• MCP 직접 연결 — IDE에서 노션·GitHub·Figma·Supabase 모두 read·write.
• 창의 작업 강함 — 새 시안·새 기획·새 디자인은 Code가 최강.
• 회고·분석 — 운영 로그 분석, 다음 사이클 개선, 메모리 정리.

🤖 Claude Cowork의 장점 — 직원 AI

• 24/7 자율 — 사람 없이 cron·webhook으로 작동. 잠든 새벽에도 일한다.
• 무한 확장 — PM2 워커 1개 → 24개 동시 가동.
• 이벤트 응답 — 슬랙·디스코드·메일·webhook 받자마자 즉시.
• 비용 균질 — 셋업 후 운영비 평탄. 잔다 = 일 $30.
• 정형 반복 — 콘텐츠 발행·CS 응대·KPI 추적은 Cowork이 최강.

🎭 두 인터페이스의 진짜 차이

🔄 잔다의 융합 — 5 단계 풀 사이클

둘을 따로 쓰면 50%. 융합하면 100%. 핵심 룰 — Cowork는 Code가 만든 코드를 운영한다. Code는 Cowork가 운영하는 시스템을 분석·개선한다.

[1단계 · 발견] Claude Code (동료)
   CEO와 사용자 인터뷰·데이터 탐색·문제 정의
       ↓
[2단계 · 프로토타입] Claude Code
   HTML·Python·Figma로 빠른 시안 (5분~30분)
       ↓
[3단계 · 검증] Claude Code + CEO
   결과 보고 조정 — 1~3 라운드
       ↓
[4단계 · 자율화] Code → Cowork 전환
   검증된 패턴을 Agent SDK·PM2 워커로 변환
   배포 (Render·로컬·VPS)
       ↓
[5단계 · 운영] Claude Cowork (직원)
   24/7 자율 작동 → 슬랙·메일·디스코드 결과 송신
       ↓
[루프 ← 4] Code로 다시 운영 로그 분석 → 개선 → Cowork 재배포

💎 운영 실측 — 1주 콘텐츠 사이클

Code 단독 = 주 5편 발행 가능하지만 매일 사람 필요. Cowork 단독 = 매일 자동이지만 새 시안 X. 융합 = 5편 발행 + 7일 자동 게시 + CS 자율 + 로그 학습.

🎯 결정 가이드 — 어느 쪽을 쓸까

리미트리스맨은 — Code로 짜고, Cowork로 운영하고, Code로 분석하고, Cowork로 재배포한다. 이 루프가 잔다의 핵심이다.

📂 출처: 운영 기록 [기록] 20260523_코드_코워크_최적_조합_기획안.md, [기록] 20260523_클로드코워크_vs_클로드코드_동료vs직원.md.

💡 "같은 Claude, 다른 인터페이스. 잘못 고르면 비용 3배."

🔍 본질 — API vs MCP, 같은 듯 다른 두 표준

🛠 워크플로우

// claude_desktop_config.json
{
  "mcpServers": {
    "notion": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-notion"],
      "env": {"NOTION_API_KEY": "secret_xxx"}
    }
  }
}

🎨 리미트리스맨이 Figma MCP로 한 일 — 디자인 외주 없이

리미트리스맨은 디자이너가 없다. 그런데 AITF API 19상품 판매 페이지(1440×11,686px, 12 섹션)를 만들어야 했다. Figma MCP가 답이었다.

흐름: CEO 요청 → Claude Code가 Figma MCP의 generate_figma_design 호출 → 12 섹션 자동 생성 → HTML 변환 → 디스코드 #design 게시 → CEO가 Figma에서 직접 수정. 기획 1시간 + Figma MCP 30분 + 검토 30분 = 2시간 완성. 디자이너 외주 시 200만원 + 2주.

단 — 5 함정이 있었다. (1) 이미지 import 불가, (2) atomic 작업 실패 시 일부만 생성, (3) Pretendard 폰트 기본 없음, (4) 디자인 토큰 자동 매핑 불완전, (5) 한국어 줄바꿈 어색. 모두 우회 가능하지만 — "Figma MCP는 만능이 아니다"를 알고 들어가야 한다.

그래서 잔다의 규칙: 빠른 텍스트 페이지는 노션, 디자인 정교한 제안서는 Figma MCP, B2B 인쇄 자료는 Figma MCP + PDF.

📂 출처: 운영 기록 [기록] 20260522_피그마_판매페이지_AI_디자인_시스템.md, [기록] 20260522_피그마_MCP_장단점_분석.md. 외부 참조: modelcontextprotocol.io (Anthropic 공식, 2024-11).

📓 노션 + AI 에이전트 풀 사이클 — 체크·기록·검색·보고

5권 본문에서 자주 나오는 "시황이 노션에 자동 기록한다." 그게 어떻게 작동하는지 풀 사이클 — 리미트리스맨이 6개월 만든 것이다.

🔌 API + MCP 동시 사용

리미트리스맨은 노션을 두 방식으로 동시에 다룬다. 자동화는 API로, 대화형 검색은 MCP로.

🗄 DB 에이전트가 수집하고 테이블로 저장하는 흐름

잔다 노션엔 5 카테고리 DB가 있다. 각 DB는 — 전담 에이전트가 매일 자동 수집·분류·저장한다.

매일 자동 수집 흐름:

[새벽 00:30] overnight 워커
   ↓ 마크다운 22 기록 스캔 → 새 기록 자동 노션 변환
[새벽 06:00] knowledge-ingestion
   ↓ 외부 지식 수집 → 노션 RAG DB 청크
[08:00] silent-trend → 영업 DB 신규 5건
[10:00] silent-security → 보안 점검 → 결정 로그
[12:00] silent-insight → CX 패턴 → 결정 로그
[17:00] silent-data → KPI 추적 → 결정 로그
[19:00] lead-collector → GitHub·원티드·TheVC 신규 리드
[매주 월 09:00] weekly-pmo-report → 종합 보고서

📥 마크다운 → 노션 자동 변환 (운영 22 기록의 진짜 흐름)

리미트리스맨은 매일 [기록] *.md 파일을 남긴다. 사람이 노션에 옮기지 않는다. AI 에이전트가 자동 변환한다.

def md_to_notion(md_text, parent_id):
    blocks = []
    for line in md_text.split("\\n"):
        if line.startswith("# "):    blocks.append({"type":"heading_1", ...})
        elif line.startswith("## "): blocks.append({"type":"heading_2", ...})
        elif line.startswith("- ["): blocks.append({"type":"to_do", "checked":..., ...})
        elif line.strip():           blocks.append({"type":"paragraph", ...})
    requests.post("https://api.notion.com/v1/pages",
        headers={"Authorization":f"Bearer {TOKEN}", "Notion-Version":"2022-06-28"},
        json={"parent":{"page_id":parent_id}, "children":blocks})

6개월간 22 마크다운 기록 → 22 노션 페이지 자동 변환. 잔다 손 X.

🎨 풀 워크플로우 — 피그마 + 노션 + 이메일 통합 (제안서 작성·발송·승인)

리미트리스맨이 새 고객사에 제안서를 보내는 풀 사이클이다. 사장 손은 마지막 PIN 입력 한 번만.

[Step 1] 디스코드 #sales 채널에서 사장이 짧게 입력
   "신발 OEM 80인 회사 제안서 만들어줘"
       ↓
[Step 2] PMO 봇이 시황에게 위임
   시황이 18 tool 중 mcp_notion_search 호출
   → 노션에서 같은 산업 (제조) 과거 결정 로그 5건 검색
   → 제안 패턴 학습
       ↓
[Step 3] Figma MCP — 디자인 에이전트 호출
   generate_figma_design (12 섹션 자동)
   → Hero · 문제 정의 · 솔루션 · 6 도메인 · 케이스 · 가격 · 다음 단계
   → 30분 안에 1440×11,686px 제안서 생성
       ↓
[Step 4] 노션 API — 결정 로그에 자식 페이지 자동
   "신발 OEM 제안서 v1 — 2026-05-27"
   → Figma 공유 링크 + 핵심 내용 자동 임베드
   → L 등급 = L3 (외부 효과)
       ↓
[Step 5] 이메일 자동 본문 작성 (Claude Sonnet)
   "안녕하세요, OO 대표님. 잔다 리미트리스맨입니다.
    저희가 6개월간 신발 OEM 사례를 정리한 ..."
   → preview_mail tool로 본문만 생성 (발송 X)
   → 디스코드 #preview 채널에 게시
       ↓
[Step 6] CEO 검토 + 수정 코멘트
   "가격을 한 줄 빼고, 첫 줄에 케이스 추가해줘"
   → 시황이 본문 수정 → 2차 preview
   → 2~3 라운드 가능
       ↓
[Step 7] CEO 최종 PIN 입력
   send_mail_with_pin tool
   PIN = "잔다 합니다" (회사명 정확 일치)
   → 오타 시 발송 X. 정확 일치 시 SMTP 발송
       ↓
[Step 8] 발송 후 자동 기록
   · 노션 결정 로그: "발송 완료, 2026-05-27 14:32"
   · 디스코드 #cs: "📧 OO 회사 제안서 발송"
   · 영업 리드 DB: 상태 "제안중"으로 자동 업데이트
   · 5분 watchdog: 응답 없으면 follow-up 알람

1단계 (디스코드 한 줄 입력)부터 8단계 (자동 기록)까지 — 사장 시간 총 7분 (Step 1 30초 + Step 6 5분 + Step 7 10초 + 검토 1분). 같은 작업을 디자이너+카피라이터+영업 매니저 3명이 분담하면 평균 2~3일.

이게 노션 + AI 에이전트의 진짜 풀 사이클이다. 각 도구가 자기 역할만 하면 — 전체가 사장 손에서 자유로워진다.

📁 구글 드라이브 → 회의록 → 노션 자동 라우팅

리미트리스맨은 회의 녹음 파일을 — 구글 드라이브에 그냥 떨어뜨린다. 그 다음 자동 라우팅이 작동한다.

[Step 1] CEO가 회의 끝나고 모바일에서 — Google Drive 폴더에 wav/mp3 업로드
   ↓ Drive API webhook (또는 1분 polling)
[Step 2] meeting_processor 워커 감지
   → Drive API: 새 파일 메타데이터 + 다운로드 URL
[Step 3] Whisper API STT (시간당 $0.36)
   → 텍스트 전문 + 화자 분리
[Step 4] Claude Haiku 4.5 — 5 카테고리 분류
   → 결정 · 할일 · 이슈 · 기회 · 리스크
[Step 5] 노션 API → 회의록 DB 자식 페이지 자동 생성
   → 제목·참가자·5 카테고리·원본 텍스트·원본 wav 링크
[Step 6] 결정·할일 추출 → 결정 로그 DB + 작업 DB 자동 등록
[Step 7] 디스코드 #ceo-briefing 알람 ("회의 1건 자동 정리 완료")

회의 1시간 = STT $0.36 + Haiku 분류 $0.001 + 노션 API 무료 = $0.37. 같은 작업을 비서가 하면 1시간. 잔다 회의 잊는 비율 87% → 0%.

📂 출처: 운영 기록 [기록] 20260521_노션통합_실리드RAG_자가발전강화.md, [기록] 20260522_노션통합DB_OpenAI풀세트_회의록자동화.md, [기록] 20260523_시황_채팅_운영실_권한매트릭스_v3.md. 실제 운영 코드: meeting_processor.mjs, cmd_processor.mjs, weekly_pmo_report.mjs. 노션 부모 페이지 ID: 368a9728-88c0-811c-9955-e524eabd1583. Google Drive MCP·API: developers.google.com/drive.

💡 "MCP는 AI 시대의 USB-C. 모르면 5년 뒤 뒤처진다."

🔍 본질 — 모델 라우팅

💼 실무 — 모델 라우터 50줄

def route(task: str) -> str:
    # 1차: Haiku 분류
    cat = haiku_classify(task)
    if cat in ["simple", "format", "extract"]:
        return haiku_respond(task)
    elif cat in ["analyze", "synthesize"]:
        return sonnet_respond(task)
    else:  # "decide", "complex"
        return opus_respond(task)

📊 리미트리스맨이 한 콘텐츠 재활용 — 전자책 4권 → PPT 64장 자동

리미트리스맨은 1·2·3·4권 전자책을 출간한 뒤 — 각 권을 PPT로 변환해야 했다. 강의·발표·SNS 슬라이드용. 직접 짜면 권당 50~100만원 × 4 = 200~400만원, 1~2주. 잔다 방식은 달랐다.

흐름: 책 .md 원본 → Haiku로 강마다 4 슬라이드 자동 요약 → python-pptx로 슬라이드 자동 생성 → matplotlib으로 도식 9개 자동 → HTML 뷰어로 통합. 4권 PPT 4개 (총 64장) + 도식 9개 + 뷰어 = 약 1시간, Claude API $3.

한 자료가 다섯 자료로 늘었다. 전자책 1권 = PPT 1개 = 영상 18편 = 블로그 18편 = SNS 카드 54건. 1년치 콘텐츠를 한 번 만든 책에서 뽑아낸다. 리미트리스맨이 1인이 30명 효과 내는 비결 중 하나다.

📂 출처: 운영 기록 [기획] 20260526_PPT_도식_20개_각권추가.md, slides.json 64장 추출 데이터 (2026-05-26). 라이브러리: python-pptx, matplotlib.

💡 "Sonnet 1건 = Haiku 3건. Opus는 어려운 결정에만."

처음에는 좋았다.

리미트리스맨이 Claude를 알게 되고 한 달. 아침에 일어나면 "오늘 트렌드 정리해줘", 점심엔 "이 회의록 분류해줘", 저녁엔 "내일 콘텐츠 시안 다섯 개", 자기 전엔 "메일 답장 초안". 하루에 서른 번 정도 Claude를 불렀다.

시간이 빨랐다. 결과물이 늘었다. 한 달 만에 사람 직원 한 명 효과를 봤다.

그런데 — 두 달째에 이상한 느낌이 들었다.

리미트리스맨이 휴가를 갔다. 사흘. AI 호출이 0 건이었다. 시스템이 멈춰있었다.
리미트리스맨이 잠들었다. 여덟 시간. 그 동안 AI는 아무 일도 안 했다.
리미트리스맨이 미팅 중이었다. 네 시간. AI는 자고 있었다.

AI가 사장을 기다리고 있었다.

하루 서른 번 호출 중 — 자세히 들여다보니 스물일곱 번이 반복 작업이었다. 트렌드 정리·회의록 분류·메일 초안·KPI 점검. 매일 같은 시간·같은 패턴이었다. 사장이 굳이 입력하지 않아도 AI가 알아서 할 수 있는 일이었다.

Andrew Ng이 어디선가 이런 말을 했다. "수동 AI 호출은 AI 시대 생산성의 병목이다." GitHub Octoverse 2024 통계도 같다 — 개발자 평균 AI 호출 하루 80 건, 그 중 70 퍼센트가 자동화 가능이라고.

리미트리스맨이 그 날 시계를 봤다. 하루 두 시간을 호출에 쓰고 있었다. 한 달 60 시간. 직원 한 명의 풀타임 절반.

AI는 직원 효과를 냈는데, 사장 시간은 직원 한 명 분 늘었다. 이상한 일이다. AI를 쓰면서 시간이 더 들었다.

"AI가 사장을 기다리면 — 사장이 병목이다."

그래서 다음 도메인이 자동화다. PM2 · webhook · silent_activator — 사장이 자는 시간에도 AI가 일하게 만드는 도구들.

🔍 본질 — "노트북 끄면 멈춤"은 자동화가 아니다

자동화의 정의는 — 사람이 자고 있어도 작동하는 것. 사람과 분리되어야 24/7이 가능하다.

심리학에 Always-On Bias — 사장이 모든 일을 본인이 관리해야 한다는 강박. PM2는 이 강박을 깬다.

🛠 워크플로우 — PM2 4 가치

• 죽으면 살림 (process.exit(1) 자동 재시작)
• 부팅 시 살림 (시스템 재부팅 후 자동)
• 메모리 보호 (max_memory_restart)
• 로그 누적 (~/.pm2/logs/)

pm2 start ecosystem.config.cjs
pm2 save              # 현재 상태 저장
pm2 startup           # 부팅 시 자동 가동 등록
pm2 list              # 가동 워커 목록

🛠 리미트리스맨이 실제로 자동화한 24 워커 — 풀 명세

리미트리스맨이 6개월 동안 차근차근 만들어 지금도 24/7 돌고 있는 워커들이다. 오케스트레이션 = 24 워커가 서로 시간·이벤트로 연결된 시스템.

이 24 워커가 서로 다른 시간·다른 이벤트로 돌면 — 회사가 리미트리스맨은 동안 4시간 30분 동안만 직접 일한다. 나머지 19시간 30분은 시스템이 일한다. 이게 "오케스트레이션의 실측"이다.

📂 출처: 운영 기록 [기록] 20260522_시황_자율운영_체계_구축.md, [기록] 20260525_보안체계_구축_17silent_진단_3봇_아카이브.md, [기록] 20260526_시황_월1_patcher가속_70목표.md. 부록 C에 ecosystem.config.cjs 풀 코드.

💡 "노트북 끄면 멈추는 건 자동화가 아니다."

🔍 본질 — Polling 1,440번 vs Webhook 1번

💼 실무 — 5분 셋업

@app.post("/webhook/payment")
async def payment(req: Request):
    data = await req.json()
    # 노션 등록 + 디스코드 알림
    notion_add(data)
    discord_post(f"💰 {data['customer']} {data['amount']:,}원")
    return {"status": "ok"}

💡 "Polling은 통제 강박, Webhook은 시스템 신뢰."

🔍 본질 — "AI가 일 받기" → "AI가 일 만들기"

사장이 일을 던져야 AI가 작동? 그러면 사장이 단일 장애점.

JANDA의 5 silent 워커가 매일 5건 자동 발화. CEO 안 시킴.

🛠 JANDA 5 silent 워커

💡 "AI를 도구가 아니라 직원으로 만드는 첫 단계."

2026년 5월 20일, 새벽 두 시였다.

리미트리스맨은 그날 밤 — 디스코드에 신규 모듈 열 개를 한 번에 붙였다. 도구 실행 엔진. 메모리 시스템. 평가 토너먼트. 자가진화 루프. 조직 계층. 프로젝트 엔진. RAG 검색까지. 일곱 레이어 풀스택이 새벽 한 시에 자라났다. 명령어가 스물두 개로 늘었다. 모듈은 천 줄을 넘었다.

밤이 늦었지만 한 번만 돌려보고 싶었다. 디스코드를 열고 !프로젝트 목록을 쳤다.

크래시.

import 한 줄을 빠뜨렸다. 이름을 바꾸면서 함수 한 개를 잊었다. 고쳤다. 다시 !프로젝트 생성을 쳤다 — 타입 오류. 시그니처를 바꾼 걸 반영 안 했다. 또 고쳤다. Python 봇을 부르려고 했더니 — 응답이 없었다. spawn()이 timeout 옵션을 무시한다는 걸 그 새벽에 알았다. 그리고 마지막 — RAG 엔진 안에 claude-opus-4-7이 하드코딩되어 있었다. 잔다 자신이 정한 정책 위반.

네 개의 버그가 동시에 터졌다. 새벽 두 시부터 네 시까지 디버깅이었다. 모듈 열 개를 만든 사장이 — 네 개를 동시에 잡고 있었다.

그 새벽에 깨달았다.

자동화 열 개를 만들면 — 그 자동화 열 개가 사장을 잡아먹는다.
모듈은 늘었는데 사장 시간은 줄지 않았다.
오히려 늘었다. 점검·관리·디버깅이 모두 사장 손에 떨어졌다.

처음엔 워커 다섯 개. 점검 오 분이면 끝. 그러다 워커 스물네 개가 되면 — 점검만 한 시간 반. 비선형으로 늘어난다. Stripe 엔지니어링 블로그도 같은 말을 한다. "백 개 워커를 self-healing 없이 운영하면 SRE 풀타임 한 명이 필요하다."

Linear의 창업자는 한 발 더 나간다. "AI 에이전트가 에이전트를 고친다. 그게 일 인당 ARR 백만 달러의 비결이다."

새벽 네 시에 리미트리스맨은 한 줄을 노션에 적었다.

"자동화의 자동화가 필요하다."

그게 AI 에이전트다.

에이전트가 자기 자신을 진단한다. 에이전트가 자기 코드를 고친다. 에이전트가 새벽 두 시에 죽으면 — 다른 에이전트가 그를 살린다. 사장은 잔다.

사장이 자동화를 만드는 단계 — 그게 Domain 3.
자동화가 자동화를 고치는 단계 — 그게 Domain 4.

📂 출처: 잔다 개발기록 07_전자책_출판/개발기록.md 2026-05-20 심야 항목. 디스코드 게이트웨이 22 명령 · 신규 모듈 10개 · 버그 4건 동시 발견.

🔍 본질

LLM 1차 답은 60점. 사람이 모른다. 자기 비평 시키면 결함을 찾아낸다.

"한 번에 끝내지 마라. 다시 봐라." — 한국 베스트셀러 공통 법칙의 LLM 버전.

🛠 6 단계 사이클

1. generate (Sonnet 1차 답)
2. critique (Haiku 자기 비평 — severity)
3. regenerate (severity=high면 재생성)
4. validate (subprocess 검증)
5. apply (commit) 또는 skip
6. reflexion_memory append (학습 누적)

def reflexion_loop(task):
    answer = generate(task)            # Sonnet
    critic = critique(task, answer)    # Haiku
    if critic.severity == "high":
        answer = regenerate(task, answer, critic.defects)
    log_to_memory(critic)
    return answer

💡 "32점 차이 = 비즈니스 5배. Reflexion = AI를 학습자로."

🔍 본질 — 코드 진화의 부채를 AI가 갚는다

코드 안 진화 = 부채. 부채를 사장이 갚으면 사장이 코더로 회귀. AI가 갚으면 사장이 결재자로 진화.

🛠 8 단계 사이클

진단 → generate(Sonnet) → self-critique(Haiku) → 재생성 → subprocess 검증 → confidence scoring → 임계 분기 → git commit → memory append

💡 "코드 진화의 부채를 AI가 갚게 하라."

🔍 본질 — Klarna가 망한 진짜 이유

표면: AI 700명이 무너졌다. 본질: 권한 매트릭스 없었음.

🛠 5 단계 피라미드

💡 "권한 적으면 무력, 많으면 사고. 5 단계가 황금비."

리미트리스맨이 에이전트 열 명을 만든 다음 날이었다.

마케팅 에이전트가 콘텐츠를 만들고 있었다. CS 에이전트가 고객 응대를 하고 있었다. 영업 에이전트가 리드를 분류하고 있었다. 데이터 에이전트가 KPI를 추적하고 있었다. 자가코딩 에이전트가 패치를 시도하고 있었다.

다섯 명이 각자 잘하고 있었다.

그런데 — 일주일이 지났다.

리미트리스맨이 협업 메시지를 세어봤다. 0 건이었다. 다섯 에이전트가 서로 단 한 번도 대화하지 않았다. 각자 자기 일만 했다.

마케팅이 만든 콘텐츠를 — CS는 몰랐다.
CS가 응대한 고객 불만을 — 영업은 몰랐다.
영업이 발견한 신규 리드를 — 데이터는 몰랐다.
데이터가 추적한 KPI 이상을 — 자가코딩은 몰랐다.

사람 회사에서 30년 전에 본 풍경이다. 부서 간 사일로. 마케팅팀이 자기 사일로에, 영업팀이 자기 사일로에, CS팀이 자기 사일로에. 각자 잘하는데 — 회사가 아니라 각자 따로 일하는 노예 다섯 명.

Microsoft Work Trend Index 2025 보고서가 정확히 이 말을 한다 — "AI 에이전트의 80 퍼센트는 사일로에 갇혀 ROI 0." OpenAI Agentic Workflows 문서도 같은 결론이다 — "다중 에이전트 통신이 에이전트 ROI의 70 퍼센트를 만든다."

리미트리스맨은 그 다음 주에 디스코드를 켰다. 채널 서른 개를 만들고, 봇 열한 개를 붙이고, 웹훅 서른 개를 발급했다. 일주일 동안 에이전트 다섯 명이 서로 한 마디도 안 하던 회사가 — 디스코드 도입 첫날 이백 건의 협업 메시지를 주고받았다.

사람 회사에 카톡·슬랙이 있듯이 — AI 회사엔 디스코드가 있다.

"에이전트 30 만드는 것은 50 퍼센트. 30 명이 서로 말하면 100 퍼센트."

그래서 다음 도메인이 디스코드다. 에이전트의 사일로를 깨는 인프라.

🔍 본질 — AI 에이전트의 카카오톡

📡 리미트리스맨이 실제로 운영한 양방향 채널 — 디스코드 + 텔레그램 분리

리미트리스맨은 두 채널을 역할 분리해서 동시 운영한다. "AI 협업"과 "CEO 명령선"은 같은 채널에 두면 안 된다 — 리미트리스맨가 6개월간 깨달은 룰이다.

잔다 사용 흐름은 양방향이다.

• CEO → 시황: 텔레그램 모바일에서 /시황아 오늘 우선순위 알려줘 → 시황이 18 tool로 brief 자동 생성 → 텔레그램 답변 12초.
• 시황 → 30 에이전트: 디스코드 #PMO 채널에서 PMO 봇이 delegate_agent("MKT") 호출 → MKT 봇이 디스코드 #mkt 채널에서 결과 게시 → blackboard 자동 누적.
• 30 에이전트 → CEO: 자가 회복·자가 발화 결과가 디스코드 #ceo-briefing 채널에 자동 게시 → CEO가 텔레그램으로 요약 알람 받음 (silent_writer가 매주 월 09:00 정리).

이게 양방향 오케스트레이션이다. 한 채널만 쓰면 사일로 또는 소음 — 두 채널 분리 사용이 잔다의 6개월 결론.

📂 출처: 운영 기록 [기록] 20260520_AGI조직_재편_및_복구.md, [기록] 20260523_시황_채팅_운영실_권한매트릭스_v3.md. discord_agent_gateway.mjs, telegram_agent_bot.py 실제 코드.

💼 실무 — 5분 셋업

1. 디스코드 서버 1개 생성
2. 봇 토큰 발급 (discord.com/developers)
3. 채널 우클릭 → 웹훅 → URL 복사
4. curl로 메시지 1건 보내기

💡 "디스코드는 AI 시대의 운영 채널이다."

🔍 본질 — 시황 운영 노하우 2번

"30명이 아니라 3 허브 (PMO·DATA·OPS) 가 핵심이다."

— 한 명이 6개월 위기를 함께 버텼고, 그래서 직원이 아니라 동료로 남았다. 30 에이전트 조직도의 시작점은 사람을 자르는 표가 아니라, 사람과 AI의 자리를 함께 그리는 표다.

🛠 3 층 조직도

• CEO 리미트리스맨 — 결정자
• 시황 (PMO) — Claude Haiku 4.5 + 18 tool
• PM 5명 — OPS·DEV·MKT·AI·DATA
• 전문가 24명 — silent_activator로 자가 발화

🤝 협업 4 패턴

1. 종 위임 — PMO → 팀장 → 전문가
2. 횡 공유 — Blackboard append-only
3. 자가 발화 — silent_activator 매일 5건
4. 자가 회복 — health-monitor → REVIEWER → AUTO

📅 리미트리스맨의 하루 — 시간순 일지

도구·시스템·아키텍처는 충분히 봤다. 마지막으로 — 실제 어느 하루에 리미트리스맨이 어떻게 일하는지. 가공 X.

00:30 — overnight 자동 시작 (28 라운드 자가 학습)
02:30 — patcher-force: 시황이 본인 코드 진단 (신뢰도 78%)
06:00 — knowledge-ingestion: 외부 지식 12건 노션 RAG
08:00 — silent-trend: "Claude 4.8 출시 예정" 자동 발견 → 디스코드

08:15 — CEO 모바일에서 시황에 질문
   "오늘 우선순위?"
   ↓ 시황 Haiku 4.5가 read_state tool (8초)
   ↓ "AITF API 응답 지연 6552ms — ROI 30, 0.5h. 1순위."

09:30 — Claude Opus (IDE) ↔ 시황 의논
   Opus: "패처 임계 80%, 75%로 낮출까?"
   시황: "75는 위험. amem 실패 사례 3건. 78%로 + 백업 강화 권장."
   Opus: "동의. PR 만들게."
   CEO: "OK" (1-click)

11:30 — 신규 고객 제안서 자동
   CEO: "신발 OEM 제안서 만들어줘"
   ↓ PMO → DESIGN → Figma MCP (12 섹션 30분)
   ↓ 노션 자동 + 디스코드 알림

12:00 — silent-insight: blackboard 종합 → 인사이트
14:00 — preview_mail: CEO 검토 → "가격 빼고 케이스 첫 줄"
14:32 — send_mail_with_pin: CEO PIN "잔다 합니다" → SMTP 발송
17:00 — silent-data: KPI 자동 추적
19:00 — lead-collector: 신규 리드 47건
21:00 — CEO 마무리: 디스코드 5분 훑음
22:00 — health-monitor: 24 워커 정상
자정 — overnight 다시 시작. 잔다 잠들지만 시스템은 계속 일한다.

CEO 실제 손에 든 시간 합 = 약 22분. 나머지 23시간 38분 — 24 에이전트와 24 워커가 자기 일을 한다.

이게 1인 사장 + AI 30명의 진짜 하루다. 도구가 아니라 — 협업의 흐름이다. Claude Opus가 동료처럼 의논하고, 시황 Haiku가 직원처럼 운영하고, 30 에이전트가 비동기로 일한다. CEO는 결재만 한다. 22분.

📂 출처: 잔다 2026-05-27 운영 로그. 실제 시간·결정·발화 모두 _sihwang_chat_log.jsonl, _blackboard_log.jsonl, _studio_commands.jsonl 기록.

💡 "사람 30년 = AI 6개월. PM 5명이 사장 뇌 한계 안."

🔍 본질 — Survivorship Bias

디스코드 결정은 1주일 후 못 찾는다. 사장이 같은 실수를 반복하는 이유.

"실패 라운드를 기록해야 AI가 성장한다." — 시황 노하우 5번.

🛠 cmd-processor 흐름

디스코드 결정 → 5초 폴링 → 노션 자식 페이지 자동 → Action Items to-do 블록 → 5분 watchdog → 응답 없으면 CEO 알람

💡 "휘발성과 영구성을 자동으로 잇는다."

본질

30 에이전트가 협업한다. 일 200건 메시지. 그런데 누가 우선순위를 정하는가? 사장이 매번 = 다시 사장 일. 지휘자 없는 30 악기 = 소음. 오케스트라가 답.

실제 팩트

• JANDA 실측: 시황 가동 전 일 200건 발화 → CEO 80% 무시 → 에이전트 가동률 50%. 시황 가동 후 CEO 일 3~5건만 응답 → 가동률 92%.
• Anthropic Agent SDK: "Without orchestrator, multi-agent devolves into noise."
• LangGraph (2024): "DAG orchestration = SOTA for >5 agents."
• Microsoft Agent Framework: "Orchestrator is the heart of enterprise AI."

"30 악기를 음악으로. 지휘자 = 시황. 다음 도메인 = 오케스트라."

🎯 일 잘 시키기 5 원칙 — tool 시스템의 토대

tool 18개를 잘 설계하려면 — 그 전에 "일 잘 시키기 5 원칙"이 있어야 한다. 이 5 원칙이 시스템으로 구현된 게 18 tool이다.

이 5 원칙은 잔다만의 발견이 아니다. 글로벌 권위자 7인이 동일하게 말한다.

5 원칙 + 7 권위자 + 운영 실측 — 이게 18 tool의 설계 토대다. "AI 시대 = 일 잘 시키기"는 잔다 혼자 주장이 아니라 — 세계가 동의하는 사실이다.

📂 출처: Karpathy Twitter 2023, Mollick 「Co-Intelligence」 2024 (Penguin), McKinsey「The Economic Potential of Generative AI」 2024, Microsoft Work Trend Index 2025.

🔍 본질 — Choice Paralysis 한계

tool 30개 → LLM 마비. tool 5개 → 무력. 18이 황금비.

🛠 4 카테고리 18 tool

💡 "18이 황금비. tool 이름은 기능이 아니라 목적."

🔍 본질

"AI 실수의 70%는 운영자 실수다. 권한 매트릭스 없으면 시간 문제."

🛠 L3 메일 게이트 3단계

1. preview_mail — 본문 생성 + 디스코드 미리보기
2. CEO PIN 입력 — 회사명 정확 일치 ("JANDA 합니다")
3. send_mail_with_pin — SMTP 발송 + 로그

🌐 다른 회사 4 사례 — "내 회사에선?"

회의론자 질문: "JANDA니까 가능. 내 회사는?" 4 사례로 답한다. 가장 가까운 1개를 찾으면 됨.

🎬 메타 증명 — 이 책이 어떻게 만들어졌는가

먼저 분명히 한다 — 이 책은 AI가 쓴 책이 아니다.

리미트리스맨이 직접 기획하고, 6개월간 운영한 실측 데이터를 본인이 정리했다. 단 — 검수 과정에 시황 (Claude Haiku 4.5 운영자 AI)를 활용했다. 책의 한 챕터를 외부 편집자가 보는 것처럼, 시황이 운영자 시각으로 약점을 짚었다.

사실 이 책이 그렇게 만들어진 데에는 이유가 있다. 시리즈 4권은 — 매 권마다 제작 방식이 한 단계씩 진화했다. 5권은 그 진화의 결과다.

2권에서 도구를 배웠고, 3권은 에이전트 설계, 4권은 3축 운영을 다뤘다. 5권은 — 그 모든 것을 본인 운영 시스템에 통합해서 책을 만드는 단계다. 그래서 시황 검수가 자연스럽게 들어왔다. 책 가르치는 시스템으로 책을 만들지 않으면 — 책이 거짓이 된다.

왜 이걸 책에 공개하는가? — 5권의 핵심 메시지가 "AI에 일 시키기"이기 때문이다. 책을 쓰면서 그 시스템을 본인이 안 쓰면, 책이 거짓이 된다. 도그푸딩 (Dogfooding) — 본인 도구를 본인이 쓰는 것 — 의 증거다.

다음은 그 검수 과정의 실제 기록:

💡 "AI 실수는 운영자 실수. JANDA 6개월 사고 0회 = 게이트의 증거."

🛠 회사 규모별 매트릭스

🏢 실제 AI 에이전트·오케스트레이션 도입 기업 10선 (2024~2026)

"AI 에이전트가 진짜 회사에 쓰이나?" — 답은 그렇다. 글로벌 기업이 2024년부터 본격 도입. 30 에이전트가 1인 사장 사례라면, 아래는 수만~수십만 직원 회사 사례.

💡 10 기업 사례 → 5권 메시지

위 10 기업을 보면 — 2024~2026이 AI 에이전트 도입의 변곡점이었다. Klarna가 너무 빨리 가서 다시 사람을 뽑은 길도, Salesforce가 Agentforce로 "software가 아니라 agent를 판다"고 선언한 길도, JP Morgan이 36만 시간을 절약한 길도 — 모두 같은 흐름이다.

30 에이전트는 1인 사장 사례. 위 10 기업은 수만~수십만 직원 사례. 규모는 다르지만 구조는 같다. 도메인 명확화 → 데이터 적재 → AI 활용 → 자동화 → 에이전트 → 디스코드(또는 슬랙·팀즈) → 오케스트라.

5권 6 도메인이 — 1인 사장에게도, Fortune 500 회사에게도, 같이 적용된다. 차이는 도구가 아니라 도메인의 명확함과 권한 매트릭스의 디테일이다.

📂 출처: Salesforce Agentforce 2.0 공식 발표 (2024-10) · CX Today "Klarna Redeploys Staff" (2025) · JP Morgan COIN 공식 (2017~) · Goldman Sachs AI Assistant 발표 (2024-06) · Citi AI Stylus 발표 (2024-09) · Microsoft Build 2026 keynote · Anthropic Customer Stories (Moody's·Shopify) · LinkedIn Engineering Blog (2024).

💡 "프레임워크는 도구. 도구를 도메인이 결정한다."

🏗 기업 도입 9단계 로드맵 — 오케스트레이션 "이전"에 해야 할 일

"우리 회사도 30 에이전트 만들면 되나요?" — 가장 많이 받는 질문. 답은 "아니, 그 전에 8단계가 있다"이다. 오케스트레이션은 9단계 중 마지막에서 두 번째다. 1~7단계를 건너뛰고 8번부터 시작하면 — Klarna가 7만 명 해고 후 다시 채용한 길을 그대로 간다.

아래는 6개월 + Fortune 500 10 기업 + Anthropic·McKinsey·Gartner 리서치를 융합한 — 실패하지 않는 9단계 순서다.

📋 단계별 잔다 매핑 + 외부 검증

같은 9단계를 — 잔다 본 강의, Fortune 500 도입 사례, 학계/벤더 리서치로 삼각 검증한 표.

⚠️ 단계를 건너뛰면 — 4가지 흔한 실패 패턴

📂 출처: McKinsey "The State of AI 2024" · Gartner "AI Strategy Trends 2024" · Anthropic MCP Announcement (2024-11-25) · Anthropic "Building Effective Agents" (2024-12) · OpenAI "A Practical Guide to Building Agents" (2025) · LangChain LangGraph Docs (2024) · Microsoft Agent Framework v1.0 Release Notes (2025) · CrewAI Documentation · Air Canada v Moffatt (BC Civil Resolution Tribunal, 2024-02)

🎨 한 그림 — 6 도메인 × 9단계 통합 매트릭스

💡 9단계는 시간 순서 (데이터부터 권한까지). 6 도메인은 역할 구분 (D1 데이터부터 D6 오케스트라까지). 두 축은 같은 "9"가 아니다 — 9단계 시간축을 6 역할에 매핑하면 — 다음 매트릭스가 된다.

책 전체가 한 장으로 보인다. 가로 9단계 (데이터 → 권한) × 세로 6 도메인 (데이터 → 오케스트라). 각 셀에서 본 책의 어느 강이 그 좌표를 채우는지 표시했다.

한 그림 안에 18강 전부가 있다. 본인 회사가 어느 도메인의 몇 단계인지 — 페르소나 루트맵보다 더 정확히 알 수 있다. 카페 = D1 ①②, 의원 = D1·D2 + ⑨, 쇼핑몰 = D2·D3·D6, JANDA = 6 도메인 9 단계 풀스택.

📂 시각 패턴: James Clear "Atomic Habits 4 Laws × 4 Stages" + James Clear "Atomic Habits 4 Laws × 4 Stages 매트릭스" 톤 참고.

🩸 운영의 실패 1건 — "데이터 모은다 했는데, 6개월 동안 안 모이고 있었다"

return {"total_collected": 0, "agi_learning": "stub"}

📂 출처: 02_AI_에이전트_연구소/에이전트_개발/knowledge_ingestion_engine.py stub 자가 발견 (2026-05-23) · CLAUDE.md ⚠️ 표시 ("현재 STUB ... 시황 실제 학습 = world_monitor + briefing 루프 + 30 디스코드 에이전트") · [기록] 20260523_*.md 시리즈.

💡 "오케스트레이션은 9단계 중 8번째. 시작점이 아니라 — 6개월짜리 결승선이다."

여기까지 왔다. 프롤로그 7박스 + 18강을 다 읽었다. 80%가 1/3 지점에서 책장에 둔다. 당신은 80%가 아니다. 이게 1년 후를 가른다.

🌟 저자의 4 행동

"누구나 활용할 수 있는 AI를 최고로 잘 활용하는 AI 에이전트 기업 잔다.
저자를 목표로 하고 있어. 실행·공부·적용·만남."

— 이 4가지를 지금 묻고 있는 당신은, 이미 실행자다. 책장을 덮고 나서 — 1년 뒤 AI하우스에서 만나자.

🔥 누구나 만드는 시대의 — 새 양극화

— 이 책을 덮고 나서 묻자: 나는 내년 이맘때까지 — 1억 토큰을 쓸 "환경"을 만들 의도가 있는가.
"양"이 아니라 "환경"을 묻는 사람만 — 100 에이전트 오케스트라에 도달한다.

💎 비유 한 줄: "환경 없이 펑펑 쓴 100억보다 — 환경설정한 1억의 누적 곡선이 더 길게 간다."

※ 위 100억·1억 비교는 시스템 누적의 비대칭을 설명하는 비유적 표현. 개별 사용자의 실제 ROI 보장이 아닙니다.

"이 책은 끝이 아니다. 시작이다.
1년 뒤, 우리는 AI하우스에서 만나자."

— 리미트리스맨

🛠 리미트리스맨이 실제로 한 워크플로우 — 6 도메인 세밀 명세

5권은 추상이 아니다. 리미트리스맨이 6개월 동안 단계별로 만든 실제 워크플로우다. 아래는 — 각 도메인에서 무엇을·어떤 순서로·어떤 도구로 했는지 풀 명세.

📌 핵심 산출물 — 6개월 후 리미트리스맨이 가진 것

📂 출처: 운영 기록 22건 (2026-05-20~27) + 개발기록.md (31KB) + 부록 C·D·E·F 풀 명세 + 시황 18 tool schema 전문.

이 표가 잔다 5권의 진짜 결과물이다. 추상이 아니라 — 1주차 노션 부모 페이지 한 개에서 시작해 6개월 뒤 30 에이전트·24 워커·19 상품 SaaS 운영자로. 본인 회사에 같은 표를 그려보라. 1년 뒤 본인이 그 표 안의 리미트리스맨이 된다.

🎯 CEO 에이전트가 연결하는 모든 업무 — 한 그림

5권 마지막 — CEO(또는 CEO 에이전트)가 6 도메인을 한 번에 연결하면 회사는 어떻게 작동하는가? 운영 실측 흐름 한 페이지.

                    [CEO (또는 CEO 에이전트 — 시황)]
                              │
        ┌─────────┬───────────┼───────────┬─────────┐
        ▼         ▼           ▼           ▼         ▼
    [노션 DB]  [디자인]    [디스코드]    [이메일]  [영업·결제]
    에이전트   에이전트     오케스트라    에이전트   에이전트

    │ 노션         │ Figma MCP   │ 30 webhook  │ SMTP        │ jbooking
    │ 450 DB      │ 12 섹션     │ 11 봇       │ preview→PIN │ Stripe
    │ 1,421건     │ 30분 자동   │ 200건/일    │ L3 게이트   │ 영수증

        ↓             ↓             ↓             ↓             ↓
    회사 OS      판매 페이지   AI 30명 협업   고객 응대     매출 자동
    SSoT 검색    제안서·인쇄   비동기 흐름    L3 안전       세금 자동

        └─────────┴───────────┼───────────┴─────────┘
                              ▼
                  [통합 결과 — 매일 자동 작동]
                  · 회의록 자동 노션 등록
                  · 영업 리드 자동 응대 (L3 PIN)
                  · 콘텐츠 자동 발행 (silent 5)
                  · 자가코딩 패처 (78% conf)
                  · 디스코드 200건/일 자율 협업
                  · 자가 회복 92% (사람 개입 일 1~2회)

                              ↓
                       [CEO는 결재만]
                  L0·L1: 시황 자율 (시간당 50건)
                  L2: 1-click 승인 (5분)
                  L3: PIN 입력 (회사명 정확)
                  L4: 사장 직접 (전자책·결제·법무)
      

이게 5권의 결론 그림이다. CEO 1명 + 시황 1명 + 30 에이전트 = 회사 한 채. 1년 운영하면 매출 1억·운영비 2,000만원·인건비 0원·직원 만족도 — 인간이 사람만 할 수 있는 20%에 집중하니까 높음.

📂 출처: 6개월 운영 통합 흐름. 모든 구성 요소는 본문 강.1~18 + 부록 9에서 단계별 가르침. 이 그림은 모든 강을 연결한 마지막 답.

💡 이 책의 부록은 — 책 안에 다 들어있다. 별도 자료를 받아야만 가치가 완성되는 책은 아니다. 이 책을 덮고 오늘 밤 시스템 1개를 가동할 수 있다면 — 그게 부록이고, 그게 완성이다.

📘 본문 부록 — 핵심 3

책을 덮자마자 5분 안에 적용 가능한 핵심 3종. 책 안에 풀 inline.

🌳 시리즈 도메인 매핑 — 1·2·3·4·5권이 채우는 빈자리

5권은 한 권으로도 충분한 책이지만, 시리즈로 봤을 때 메시지의 무게가 달라진다. 각 권이 어떤 도메인을 다루는지 — 객관적인 매핑이다.

◎ = 핵심 챕터로 다룸 · ○ = 일부 다룸 · △ = 도입부 언급 · × = 미수록. 5권만 사면 1~6번 도메인의 시작점이 비고, 1권만 사면 4~7번 도메인이 빈다. 시리즈가 1년 누적 매뉴얼인 이유.

🪞 책을 덮기 전 — 내러티브·자기성찰 톤 자기 점검 3문항

🛰 책의 내용을 — 리미트리스맨이 지금도 운영 중인 3 곳

이 책의 모든 내용은 — 리미트리스맨이 지금 이 순간에도 돌리고 있는 시스템이다. 본문에서 인용한 것을 직접 확인할 수 있는 세 곳을 적어둔다. 판매가 아니라 검증을 위한 링크다.

📂 운영 22 기록 — 5권 본문의 1차 소스

5권은 "강의 책"이 아니라 — 리미트리스맨이 6개월간 운영하면서 남긴 22개 기록을 정리한 책이다. 각 강이 어느 기록에서 나왔는지 다음과 같다.

이게 책 신뢰의 근거다. 모든 강은 리미트리스맨이 그 강을 쓰기 전에 그 일을 직접 한 기록 위에 쓰여졌다.

리미트리스맨 (잔다 JANDA) · 2026년 6월
aiaijungle.github.io/vibe-ebook

강.7~18 + 에필로그 + 부록 9종 미리보기

• Domain 3 자동화 (3강) — PM2·Cron, Webhook, silent_activator
• Domain 4 에이전트 (3강) — Reflexion, 자가코딩 패처, L0~L4 권한
• Domain 5 디스코드 (3강) — 게이트웨이, 30 에이전트 조직도, 결정 로그 아카이브
• Domain 6 오케스트라 (3강) — 18 tool, L0~L4 게이트, LangGraph/CrewAI/Microsoft
• 에필로그 — 저자의 4 행동 (실행·공부·적용·만남), 1년 뒤 AI하우스
• 부록 A~I — 노션 DB·webhook 30·PM2 24워커·시황 18tool·autonomy_policy·6개월 비용·실패 5건·카피 30선·함정 30선·묶음 funnel

🌟 리미트리스맨의 비전 — 저자의 4 행동

"누구나 활용할 수 있는 AI를 최고로 잘 활용하는 AI 에이전트 기업.
저자를 목표로 하고 있어. 실행·공부·적용·만남."

• 실행 (Execute) — 오늘 5분. 사장이 직접 짠다.
• 공부 (Study) — 매주 1책 + 모임. 모르면 물어본다.
• 적용 (Apply) — 매일 1건. 읽기만 하면 잊는다.
• 만남 (Meet) — 매월 모임 + 1명. 혼자 가면 못 간다.

"1년 뒤 AI하우스에서 만나자."
— 리미트리스맨