FAST CAMPUS · CHAPTER 06 · KEYNOTE 2026

CHAPTER 06 · HARNESS ENGINEERING

6장. AI Native 팀으로 가는 길

개인의 하네스에서 팀의 생태계로

Fast Campus Harness Engineering Chapter Deck · decks/chapter-06.html

챕터 이동 이전 · 5장. MCP형 하네스 프로젝트 현재 · 6장. AI Native 팀으로 가는 길 목차 · 3 클립 2006-1-1 · 코드를 도구로 보는 법 2006-1-2 · Zeude 케이스 스터디 2006-1-3 · 플레이그라운드 로드맵

COVER01 / 17

● SPEAKER NOTESSLIDE 01 / 17

오프닝

1~5장에서 만든 건 개인의 하네스다. 6장은 그걸 팀 전체가 같이 쓰고, 누가 못 쓰는지 보고 돕고, 비개발자까지 스킬을 만들어 쓰는 운영 구조로 넓힌다. 한 시간, 세 클립으로 진행한다.

척추는 "왜 팀 하네스인가" 세 동기다 — ① 공유해도 아무도 설치 안 한다 ② 잘 못 쓰는 사람을 모니터링으로 케어한다 ③ 비개발자가 만든 스킬이 랭킹에 오르며 엔지니어 마인드가 퍼진다. 이 셋이 AI 전환을 만든다.

케이스 스터디는 Zeude(zep-us/zeude) — claude·codex 둘 다 감싸는 팀 하네스. 설치·실행 성능은 주장하지 않고 공개 구조와 공개된 세팅 절차만 다룬다.

Primary source: curriculum.md rows 62-64. Reference repo: github.com/zep-us/zeude (observation only). Supporting source: interview.md team playground framing.

FAST CAMPUS · CHAPTER 06 · KEYNOTE PART 6-1

MODULE · 6-1

6-1. 팀 단위 아키텍처 확장

개인 하네스를 팀이 같이 쓰는 운영 구조로 넓힌다.
왜 그래야 하는지, 세 가지 동기에서 출발합니다.

동기 공유→설치 → 모니터링→케어 → 빌더→랭킹→전환

SECTION BREAK02 / 17

● SPEAKER NOTESSLIDE 02 / 17

섹션 전환 · 세 동기

6장은 한 모듈(6-1), 세 클립이다. 클립마다 ~20분, 합 한 시간. 각 클립은 동기 하나에 대응한다.

2006-1-1 · 코드를 도구로 보는 법 → 동기1(공유한 게 팀에 안 남는다)을 개인 마인드셋으로 푼다. 산출물: AI Native 마인드셋 체크리스트.
2006-1-2 · Zeude 케이스 스터디 → 동기1·2·3이 코드로 어떻게 풀리는지 본다. 산출물: 팀 AI 인프라 요구사항 명세.
2006-1-3 · 플레이그라운드 로드맵 → 동기3(빌더·랭킹·전환)까지 끌고 가는 실행 계획. 산출물: 우리 팀 플레이그라운드 로드맵.

전환 멘트는 반복한다 — "코드를 더 잘 쓰는 수업이 아니라, 팀이 AI를 같이 쓰고 같이 키우게 만드는 수업".

Primary source: curriculum.md rows 62-64. Supporting source: interview.md playground framing.

FAST CAMPUS · CHAPTER 06 · KEYNOTE 2006-1-1 · 동기

왜 팀 하네스인가: 개인 루틴이 팀에 남지 않는다

동기 1

공유했는데 안 쓴다

좋은 스킬·프롬프트를 올려도 아무도 설치하지 않는다. 개인 루틴이 팀 자산으로 남지 못한다.

동기 2

잘 못 쓰는 사람

누가 AI를 어디서 헤매는지 안 보여 도와줄 수가 없다. 격차가 그대로 굳는다.

동기 3

빌더가 안 생긴다

비개발자가 스킬을 만들고 그게 쓰이는 경험이 없으면, 엔지니어 마인드도 AI 전환도 시작되지 않는다.

그래서

코드보다 운영

코드 실력이 아니라 공유·관측·확산을 팀이 같이 소유하는 문제다.

6-1. 팀 단위 아키텍처 확장03 / 17

● SPEAKER NOTESSLIDE 03 / 17

동기 / 문제 상황 — 클립 1 도입

클립 1의 출발은 "AI를 쓰느냐"가 아니라 개인이 만든 좋은 루틴이 팀 기준으로 남지 않는 상황이다. 세 동기로 연다.

동기1: 스킬을 공유해도 설치하는 사람이 없다. 프롬프트·스킬·검수 기준이 개인 기억에 닫혀 재사용이 안 된다. 다음 클립 Zeude의 자동 동기화(zero-touch)가 이 동기를 푼다.
동기2: 누가 AI를 잘 못 쓰는지 안 보이면 케어할 수 없다. 모니터링은 감시가 아니라 헤매는 사람을 돕기 위한 관측이라고 분명히 한다.
동기3: 비개발자·빌더가 스킬을 만들고 그게 실제로 쓰이며 랭킹에 오르면, 엔지니어적 사고가 퍼지고 그게 조직의 AI 전환으로 이어진다. 이 클립의 마인드셋이 그 출발점이다.

전환: 이 세 동기를 풀려면 먼저 개인이 "코드가 아니라 무엇을 소유하는가"를 다시 봐야 한다 — 다음 슬라이드.

Primary source: curriculum.md row 62. Supporting source: interview.md problem-definition framing.

FAST CAMPUS · CHAPTER 06 · KEYNOTE 2006-1-1 · 개념

코드는 목적을 실행하는 도구다

항목	강의 정의	팀 기준으로 남길 값
purpose	AI에게 맡기는 이유와 성공 기준을 먼저 정한다	문제 한 문장, 완료 기준, 검수자
pipeline	입력, 실행, 검수가 반복되는 순서를 설계한다	입력 위치, 실행 절차, 검수 흐름
impact	코드 밖의 업무 가치와 공유 대상을 설명한다	업무 변화, 공유 대상, 다음 사용 장면
operation	실패를 알아채고 되돌릴 기준을 남긴다	실패 신호, 멈춤 기준, 다음 질문

6-1. 팀 단위 아키텍처 확장04 / 17

● SPEAKER NOTESSLIDE 04 / 17

핵심 개념 — 코드가 아니라 파이프라인·임팩트를 소유

curriculum.md 2006-1-1의 핵심 문장 "코드가 아니라 파이프라인과 비즈니스 임팩트를 소유해야 한다"를 네 항목으로 푼다. 본문 표는 짧게 읽고, 각 항목이 왜 팀 기준으로 남아야 하는지 말로 채운다.

purpose는 코드 요청문이 아니라 문제 정의다. 이 값이 없으면 결과가 좋아 보여도 팀은 완료 여부를 같은 기준으로 판단하지 못한다.
pipeline은 입력·실행·검수의 순서다. 개인은 머리로 보완하지만 팀은 순서가 남아야 같은 하네스를 다시 돌린다.
impact는 코드 밖 업무 가치다. 새 외부 수치를 붙이지 말고 그 팀의 업무 변화·공유 대상으로만 말한다. operation은 실패 신호·멈춤 기준·다음 질문이다.
이 네 항목이 곧바로 다음 실습 AI Native 마인드셋 체크리스트의 칸이 된다.

Primary source: curriculum.md row 62. Supporting source: interview.md problem-definition and operation-sense framing.

FAST CAMPUS · CHAPTER 06 · KEYNOTE 2006-1-1 · 워크스루

워크스루: 개인 AI 업무를 팀 하네스 요청서로

순서	팀이 남길 질문	산출 값
업무 선택	반복되는 AI 업무는 무엇이며 누가 검수하나?	업무 이름, 목적, 검수자
purpose	왜 AI에 맡기며 어떤 상태를 성공으로 보나?	문제 한 문장, 완료 기준
pipeline	입력, 실행, 검수는 어디서 이어지나?	입력 위치, 실행 절차, 리뷰 흐름
impact · operation	어떤 업무 변화와 실패 신호를 팀이 봐야 하나?	공유 대상, 실패 신호, 멈춤 기준

6-1. 팀 단위 아키텍처 확장05 / 17

● SPEAKER NOTESSLIDE 05 / 17

적용 워크스루 — 추상 개념을 요청서로 낮춘다

한 팀원이 개인적으로 반복하던 AI 업무(예: 회의 메모를 검토 가능한 초안으로 정리)를 팀에 공유하려는 장면으로 잡는다. 지금은 프롬프트·검수 기준이 개인 기억에만 있어 팀이 목적·완료 기준·실패 신호를 다시 확인할 방법이 없다.

표를 위에서 아래로 시연한다 — 업무 선택(검수자 포함) → purpose(성공 한 문장) → pipeline(입력·실행·리뷰 순서) → impact·operation(업무 변화·실패 신호·멈춤 기준). 이 요청서가 다음 실습 체크리스트의 입력이 되고, 클립 2의 Zeude 관찰과 만나 팀 인프라 요구사항으로 확장된다.

Primary source: curriculum.md row 62. Supporting source: interview.md problem-definition framing.

FAST CAMPUS · CHAPTER 06 · KEYNOTE 2006-1-1 · 실습

[실습] AI Native 마인드셋 체크리스트

실습 목표

코드가 아니라 파이프라인과 비즈니스 임팩트를 소유한다.

수행 과제

개인 업무 하나를 AI Native 팀 운영 기준으로 번역한다.

산출물

AI Native 마인드셋 체크리스트

완료 기준

purpose·pipeline·impact·operation의 부족 항목과 다음 행동이 보인다.

AI Native 마인드셋 체크리스트

purpose해결할 문제와 성공 기준을 한 문장으로 정했나
pipeline입력, 실행, 검수 흐름이 반복 가능하게 이어지나
impact업무 가치와 공유 대상이 코드 밖까지 설명되나
operation실패를 알아채고 되돌릴 기준이 남아 있나

6-1. 팀 단위 아키텍처 확장06 / 17

● SPEAKER NOTESSLIDE 06 / 17

2006-1-1 · 20분 운영 (코드를 도구로 보는 법)

클립 제목은 코드를 '목적'이 아닌 '도구'로 보는 법, 핵심은 코드가 아니라 파이프라인과 비즈니스 임팩트를 소유, 산출물은 AI Native 마인드셋 체크리스트.

00:00-03:00 · 동기 열기: 슬라이드 03의 세 동기로 "왜 팀 하네스인가"를 깐다.
03:00-07:00 · 개념: 슬라이드 04로 purpose·pipeline·impact·operation을 정의한다.
07:00-11:00 · 워크스루: 슬라이드 05로 개인 업무 하나를 요청서로 시연한다.
11:00-17:00 · 실습 작성: 최근 AI 업무 하나로 네 항목의 현재 상태·부족 항목·다음 행동을 한 줄씩 적게 한다.
17:00-20:00 · 자기 검수 / 전환: 비어 있는 책임 하나를 표시하고, 다음 클립 Zeude에서 관측·공유·동기화 요구사항으로 바꿀 값을 고른다.

운영 포인트

한 번에 한 칸만 채우게 한다. 네 칸을 동시에 채우면 산만해진다.
새 외부 사례·검증 안 된 수치는 넣지 않는다. 자기 업무 안에서만 설명한다.
완료 확인: 네 항목의 부족 항목과 다음 행동이 적혀 있으면 실습 완료로 본다.

Primary source: curriculum.md row 62. Supporting source: interview.md problem-definition and operation-sense framing.

FAST CAMPUS · CHAPTER 06 · KEYNOTE 2006-1-2 · CASE STUDY

[Case Study] Zeude: 팀 단위 모니터링과 동기화

무엇

팀 하네스 (claude · codex)

claude·codex CLI를 감싸는 shim + 대시보드. 조직을 AI Native로 만드는 운영 플랫폼.

왜

Intention-Action Gap

좋은 AI 도구가 있어도 채택률이 낮고 best practice가 개인 사일로에 갇힌다 — 세 동기 그대로.

관찰

구조와 세팅을 본다

성능은 주장하지 않고, 공개 repo 구조와 공개된 세팅 절차로 공유·모니터링·동기화 경계를 읽는다.

산출물

팀 AI 인프라 요구사항 명세

관찰을 우리 팀 요구사항으로 번역한다.

6-1. 팀 단위 아키텍처 확장07 / 17

● SPEAKER NOTESSLIDE 07 / 17

Zeude 케이스 스터디 도입

Zeude(github.com/zep-us/zeude)는 "Enterprise Monitoring & Configuration Management Platform" — claude와 codex를 둘 다 감싸는 팀 하네스다. 기능 목록을 외우는 시간이 아니라, 앞에서 본 세 동기가 코드로 어떻게 풀리는지 관찰하는 시간이다.

문제 정의는 Intention-Action Gap이다. 조직이 AI 도구에 투자해도 "무엇이 가능한지 모르고, best practice는 개인 안에 갇히고, 공유할 체계가 없다." 이게 클립 1의 세 동기와 같은 말이다.

source-fidelity: 채택률 수치나 스타 수 같은 변동·검증 밖 주장은 슬라이드에 넣지 않고, 공개 구조(README·디렉토리·API 경로)와 공개된 세팅 절차만 근거로 쓴다.

Primary source: curriculum.md row 63 (2006-1-2). Reference repo: github.com/zep-us/zeude (observation only). Guardrail: decks/approved-source-checklist.md Zeude mapping.

FAST CAMPUS · CHAPTER 06 · KEYNOTE 2006-1-2 · ARCHITECTURE

Zeude 3층: 측정 → 배포 → 제안, 그리고 다시 측정

① 측정 · Sensing

OTEL → ClickHouse

shim이 텔레메트리를 켜고 claude·codex 실행이 OTEL trace로 ClickHouse에 쌓인다. 대시보드가 채택률·미사용자·best practice를 본다.

② 배포 · Delivery

대시보드 → shim 자동 동기화

대시보드에서 정한 skills·hooks·MCP를 shim이 매 실행마다 ~/.claude/로 내려받는다. 설치 0터치.

③ 제안 · Guidance

UserPromptSubmit hook

프롬프트를 보고 2단계 키워드 매칭으로 "지금 이 스킬 써보세요"를 실시간 추천한다.

한 루프로 돈다

인사이트측정이 무엇을 고쳐야 할지 보여준다
스킬고친 것을 스킬·hook으로 배포한다
채택 → 측정쓰임이 다시 측정되며 루프가 돈다

6-1. 팀 단위 아키텍처 확장08 / 17

● SPEAKER NOTESSLIDE 08 / 17

Zeude 3층 아키텍처 (구조 관찰)

Zeude의 한 줄은 "측정해야 보이고, 공유해야 퍼진다"이다. 세 층이 한 루프로 돈다.

① 측정(Sensing): shim이 OTEL 환경변수를 주입해 claude·codex 사용이 trace로 ClickHouse에 들어가고, 대시보드가 토큰·채택률·미사용자·best practice를 보여준다. 동기2(케어)의 근거.
② 배포(Delivery): 대시보드에서 skills·hooks·MCP를 관리하면 shim이 매 실행마다 ~/.claude/skills·hooks·skill-rules.json로 자동 동기화한다. 동기1(공유해도 설치 안 함)을 zero-touch로 푼다.
③ 제안(Guidance): UserPromptSubmit hook이 프롬프트를 보고 skill-rules.json 기반 2단계 키워드 매칭으로 스킬을 실시간 추천한다. 예: "send message to slack" → "/slack-agent 써보세요".
루프: 인사이트 → 스킬 → 채택 → 측정. 이게 동기3(빌더가 만든 스킬이 쓰이며 퍼지는 전환)의 엔진이다.

Reference repo: github.com/zep-us/zeude README 3-layer architecture (observation only).

FAST CAMPUS · CHAPTER 06 · KEYNOTE 2006-1-2 · SHIM

한 shim이 claude·codex를 감싼다 — 스킬은 랭킹된다

shim

명령을 가로챈다

~/.zeude/bin의 shim이 claude·codex를 가로채 빠르게 동기화하고 텔레메트리를 켠 뒤 진짜 CLI를 실행한다.

claude vs codex

둘 다, 단 범위는 다르다

둘 다 OTEL을 같은 ClickHouse로 보낸다(같은 사용자로 묶임). 동기화는 Claude=skills+hooks+MCP, Codex=skills만(hooks·MCP는 Claude 전용).

리더보드

누가 만든 스킬이 얼마나

스킬별 사용량·사용자 수가 랭킹된다. 비개발자가 만든 스킬이 오르면 엔지니어 마인드가 퍼진다 = 동기3.

케어

못 쓰는 사람을 돕는다

채택률·미사용자가 보이니 감시가 아니라 케어로 쓴다 = 동기2.

6-1. 팀 단위 아키텍처 확장09 / 17

● SPEAKER NOTESSLIDE 09 / 17

shim 메커니즘 + Claude∥Codex + 리더보드

shim(cmd/claude·cmd/codex, Go): 명령을 가로채 FastSync(캐시, <100ms)로 설정을 맞추고 OTEL env를 주입한 뒤 진짜 바이너리로 exec(프로세스 치환). claude shim이 codex shim을 companion으로 자동 설치하기도 한다.
정확한 경계(코드 확인): 둘 다 OTEL 텔레메트리를 보내되 ServiceName이 claude/codex로 나뉘고, 같은 canonical user identity로 묶여 ClickHouse에서 한 사람으로 본다. 동기화 범위는 다르다 — Claude는 skills+hooks+MCP+agents, Codex는 skills만(~/.claude/skills와 ~/.codex/skills). 과장하지 말고 이 차이를 정확히 말한다.
리더보드(동기3): api/leaderboard·api/admin/analytics/skills가 스킬별 사용량·사용자 수, 팀 cohort 랭킹을 만든다. api/user/skills로 누구나 스킬을 만든다. 비개발자가 만든 스킬이 랭킹에 오르며 쓰이는 경험이 엔지니어 마인드와 AI 전환을 만든다.
케어(동기2): 채택률·미사용자 인사이트는 누군가를 평가하려는 게 아니라 헤매는 사람을 돕기 위한 것이라고 분명히 한다.

Reference repo: github.com/zep-us/zeude — cmd/claude·cmd/codex, api/leaderboard, api/admin/analytics/skills (observation only).

FAST CAMPUS · CHAPTER 06 · KEYNOTE 2006-1-2 · SETUP

실제 세팅: 운영자는 대시보드 한 번, 팀원은 한 줄

운영자 · 1회

대시보드 + 데이터

git clone → .env에 Supabase·ClickHouse 자격증명 → cd zeude/dashboard && pnpm install && pnpm dev → Supabase·ClickHouse 마이그레이션 → OTEL collector 기동(deployments/).

팀원 · 한 줄

shim 설치

curl -fsSL https://<대시보드>/releases/install.sh | ZEUDE_AGENT_KEY=zd_xxx bash → ~/.zeude/bin에 claude·codex shim + PATH 등록 + ~/.zeude/credentials.

그 다음

평소대로 실행

팀원은 새 도구를 안 배운다. 쓰던 claude·codex를 그대로 치면 shim이 가운데서 스킬·hook을 동기화하고 OTEL로 측정한다.

키

agent key로 한 사람

팀원별 agent_key(zd_…)를 대시보드에서 발급. 같은 키가 claude·codex shim을 한 사용자로 묶어 랭킹·케어 데이터가 일관된다.

6-1. 팀 단위 아키텍처 확장10 / 17

● SPEAKER NOTESSLIDE 10 / 17

실제 세팅 — 운영자 1회 + 팀원 한 줄

이 슬라이드는 "그래서 우리 팀에 어떻게 깔지"를 공개된 세팅 절차로만 보여준다. README Quick Start와 releases/install.sh에서 확인한 범위이며, 설치 성공·성능은 주장하지 않는다.

운영자(대시보드, 1회): repo clone → .env에 Supabase(설정·사용자)와 ClickHouse(분석) 자격증명 → zeude/dashboard에서 pnpm install && pnpm dev → Supabase·ClickHouse 마이그레이션 적용 → OTEL collector는 deployments/docker-compose.collector.yaml로 띄운다.
팀원(각 머신, 한 줄): install.sh를 ZEUDE_AGENT_KEY와 함께 실행하면 ~/.zeude/bin에 claude·codex shim이 깔리고 PATH 맨 앞에 등록된다. 키는 ~/.zeude/credentials에 저장된다.
핵심 메시지: 팀원은 새 CLI를 안 배운다. 기존 claude·codex 명령을 그대로 쓰는데, shim이 그 앞에서 동기화·측정을 한다. 이게 동기1(공유해도 설치 안 함)을 zero-touch로 푸는 지점이다.
agent key 하나가 claude·codex를 같은 사용자로 묶어, 어느 CLI로 쓰든 랭킹·케어 데이터가 한 사람으로 모인다.

본인 팀 적용 질문: "운영자는 누구이고, agent key는 어떻게 나눠줄까? 첫 동기화 대상 스킬·hook은 무엇으로 시작할까?" — 다음 실습 요구사항 명세로 넘긴다.

Reference repo: github.com/zep-us/zeude — README Quick Start, releases/install.sh (published setup, observation only). Guardrail: decks/approved-source-checklist.md Zeude mapping.

FAST CAMPUS · CHAPTER 06 · KEYNOTE 2006-1-2 · 번역

세 동기를 우리 팀 요구사항으로 번역하기

동기	Zeude는 어떻게 (관찰)	우리 팀 요구사항 질문
① 공유→설치	shim이 매 실행마다 skills·hooks 자동 동기화	무엇을 중앙에서 관리하고, 어떻게 0터치로 깔리게 할까?
② 모니터링→케어	OTEL → ClickHouse → 채택률·미사용자 인사이트	어떤 실행 상태·실패 신호를 보고, 누가 케어할까?
③ 빌더→랭킹	스킬 사용량 리더보드 + 누구나 스킬 빌드	비개발자가 스킬을 만들 통로와 랭킹을 어떻게 둘까?
운영 기준	대시보드·Supabase·배포 설정으로 변경 관리	변경·소유자·검수 시점을 어디에 남길까?

6-1. 팀 단위 아키텍처 확장11 / 17

● SPEAKER NOTESSLIDE 11 / 17

관찰 → 요구사항 번역

Zeude의 구조를 그대로 베끼는 게 아니라, 세 동기를 우리 팀 요구사항 질문으로 바꾼다. 각 행은 "Zeude가 어떻게 했나"(관찰)와 "우리 팀은 무엇을 정해야 하나"(질문)로 나뉜다.

관찰 근거 경로(외우게 하지 말 것): 공유·동기화 = internal/mcpconfig·internal/resolver·api/config; 모니터링 = internal/otelenv·dashboard/clickhouse·api/status; 빌더·랭킹 = api/user/skills·api/leaderboard·api/admin/analytics/skills; 운영 = dashboard/supabase/migrations·deployments.
각 동기에서 우리 팀이 지금 가장 비어 있는 한 줄만 고르게 한다. 네 줄을 다 채우려 하지 않는다.
이 네 줄이 다음 실습 팀 AI 인프라 요구사항 명세의 초안이 된다.

Primary source: curriculum.md row 63. Reference repo: github.com/zep-us/zeude (observation only).

FAST CAMPUS · CHAPTER 06 · KEYNOTE 2006-1-2 · 실습

[실습] 팀 AI 인프라 요구사항 명세

실습 목표

공유·모니터링·동기화·빌더 생태계를 팀 요구사항으로 쓴다.

수행 과제

Zeude 관찰을 세 동기 기준으로 우리 팀 인프라 항목으로 옮긴다.

산출물

팀 AI 인프라 요구사항 명세

완료 기준

각 항목에 데이터·설정·소유자·다음 검수 기준이 있다.

요구사항 명세 — 네 축

공유·동기화중앙에서 관리할 스킬·hook·MCP와 0터치 설치 경로를 정한다
모니터링·케어볼 실행 상태·미사용자 신호와 케어 담당을 정한다
빌더·랭킹비개발자 스킬 빌드 통로와 사용량 랭킹을 정한다
운영 기준변경, 버전, 소유자, 다음 검수 시점을 둔다

6-1. 팀 단위 아키텍처 확장12 / 17

● SPEAKER NOTESSLIDE 12 / 17

2006-1-2 · 20분 운영 (Zeude 케이스 스터디)

클립 제목은 [Case Study] Zeude: 팀 단위 모니터링과 동기화, 핵심은 하네스·스킬을 팀 전체와 공유하고 실행을 모니터링하는 인프라, 산출물은 팀 AI 인프라 요구사항 명세.

00:00-03:00 · 도입: 슬라이드 07로 Zeude가 claude·codex 팀 하네스이고 Intention-Action Gap을 푼다는 점을 깐다.
03:00-07:00 · 아키텍처: 슬라이드 08~09로 측정·배포·제안 3층과 shim, Claude∥Codex 차이, 리더보드를 관찰한다.
07:00-10:00 · 세팅: 슬라이드 10으로 운영자 1회 + 팀원 한 줄 세팅을 보여주고 "우리 팀이면 누가 운영자인가"를 묻는다.
10:00-13:00 · 번역: 슬라이드 11로 세 동기를 우리 팀 요구사항 질문으로 바꾼다.
13:00-17:30 · 실습 작성: 네 축(공유·동기화 / 모니터링·케어 / 빌더·랭킹 / 운영 기준)에 데이터·설정·소유자·검수 기준을 한 줄씩 적게 한다.
17:30-20:00 · 검수 / 전환: 가장 비어 있는 축 하나를 고르고, 다음 클립 플레이그라운드 로드맵의 우선순위로 넘긴다.

운영 포인트

구조와 공개된 세팅 절차만 다룬다 — 설치 성공·성능·채택률 수치·스타 수는 말하지 않는다.
경로를 외우게 하지 말고, 각 동기가 어떤 문제를 줄이는지만 말하게 한다.
완료 확인: 네 축에 데이터·설정·소유자·다음 검수 기준이 있으면 실습 완료로 본다.

Primary source: curriculum.md row 63 (2006-1-2). Reference repo: github.com/zep-us/zeude (observation only). Guardrail: decks/approved-source-checklist.md Zeude mapping.

FAST CAMPUS · CHAPTER 06 · KEYNOTE 2006-1-3 · 개념

플레이그라운드: 한 명의 설계가 팀 생산성이 되는 판

단계	핵심 질문	남기는 값
도입	어떤 개인 하네스를 첫 팀 기준으로 삼을까?	첫 하네스·스킬, 공유 규칙, 시작 소유자
관측·케어	실행 기록과 미사용자를 어디서 보고 누가 도울까?	모니터링 위치, 케어 담당
빌더·랭킹	비개발자가 스킬을 만들고 랭킹에 오르게 어떻게 할까?	빌드 통로, 랭킹 기준
확산·전환	한 사람의 설계를 팀 반복 업무로 어떻게 옮길까?	소유자, 다음 산출물, 검수 시점

6-1. 팀 단위 아키텍처 확장13 / 17

● SPEAKER NOTESSLIDE 13 / 17

플레이그라운드 = 확산을 설계하는 운영판

curriculum.md 2006-1-3의 "한 명의 설계가 팀 전체의 생산성이 되는 생태계 설계법"을 네 단계로 푼다. 이 네 단계가 곧 세 동기를 실행 순서로 편 것이다.

도입: 큰 플랫폼을 만들자는 게 아니라, 팀이 같이 볼 첫 하네스·스킬과 공유 규칙, 시작 소유자를 정한다(동기1).
관측·케어: 실행 기록·미사용자를 어디서 보고 누가 도울지 정한다(동기2). 감시가 아니라 케어.
빌더·랭킹: 비개발자가 스킬을 만들 통로와, 쓰임이 보이는 랭킹을 둔다(동기3). 이게 전환의 엔진.
확산·전환: 한 사람의 팁을 팀 반복 업무로 만들기 위해 소유자·다음 산출물·검수 시점을 남긴다.

Primary source: curriculum.md row 64. Supporting source: interview.md team playground framing.

FAST CAMPUS · CHAPTER 06 · KEYNOTE 2006-1-3 · 구조

개인 하네스가 팀 운영판으로 도는 루프

문제 정의

사람이 정한다

요청을 작은 실행 단위와 성공 기준으로 정하고, 목적·임팩트는 사람이 정한다.

팀 실행

하네스가 돈다

공유된 스킬·hook·도구로 실행하고, 실행 기록과 관측 신호를 남긴다.

검토 루프

사람이 되묻는다

결과·실패 지점을 모아 검수 기준과 재질문 기준으로 다음 개선 요청을 만든다.

확산

랭킹으로 퍼진다

잘 된 스킬이 랭킹에 오르며 다른 사람이 가져다 쓰고, 빌더가 늘어난다.

6-1. 팀 단위 아키텍처 확장14 / 17

● SPEAKER NOTESSLIDE 14 / 17

운영판의 반복 구조

팀 플레이그라운드 위에서 AI 에이전트 역할과 사람의 리뷰가 어떻게 도는지 보여준다. 문제 정의(사람) → 팀 실행(하네스) → 검토 루프(사람) → 확산(랭킹).

문제 정의: 에이전트가 요청을 작은 단위로 정리하고, 사람은 목적·임팩트를 정한다. 첫 산출물은 리뷰 가능한 범위로 제한한다.
팀 실행: 공유된 스킬·hook·도구로 실행하고 로그를 남긴다(앞 Zeude 관찰의 동기화·측정과 연결).
검토 루프: 검수 기준·재질문 기준·멈춤 기준을 사람이 정해 다음 개선으로 되돌린다.
확산: 잘 된 스킬이 랭킹에 오르며 퍼지고 빌더가 늘어난다 — 한 번의 성공이 개인 팁으로 끝나지 않는다.

Primary source: curriculum.md rows 63-64. Supporting source: interview.md playground, human judgment framing.

FAST CAMPUS · CHAPTER 06 · KEYNOTE 2006-1-3 · 실습

[실습] 우리 팀 플레이그라운드 로드맵

실습 목표

우리 팀을 AI Native로 전환하는 단계별 실행 계획을 만든다.

수행 과제

세 동기를 단계로 펴고 각 단계에 소유자·검수 시점을 붙인다.

산출물

우리 팀 플레이그라운드 로드맵

완료 기준

이번 주에 시작할 첫 단계와 담당자·검수 날짜가 있다.

1 · 공유→설치 보장

첫 공유 스킬 1~2개, 0터치 설치 경로, "개인 루틴 → 팀 자산" 기준, 소유자.

2 · 모니터링→케어

관측 지표(채택률·미사용자), 헤매는 사람 케어 방식(감시 아님), 케어 담당.

3 · 빌더→랭킹→전환

비개발자 스킬 빌드 통로, 사용량 랭킹, 확산 소유자.

6-1. 팀 단위 아키텍처 확장15 / 17

● SPEAKER NOTESSLIDE 15 / 17

2006-1-3 · 20분 운영 (플레이그라운드 로드맵)

클립 제목은 모두가 뛰놀 수 있는 '플레이그라운드' 만들기, 핵심은 한 명의 설계가 팀 전체의 생산성이 되는 생태계, 산출물은 우리 팀 플레이그라운드 로드맵. 로드맵은 세 동기를 그대로 단계로 쓴다 — 추상 "놀이터"가 아니라 월요일에 실행 가능한 AI 전환 계획.

00:00-03:00 · 개념: 슬라이드 13~14로 플레이그라운드 단계와 운영 루프를 깐다.
03:00-06:00 · 입력 정리: 클립 2의 팀 AI 인프라 요구사항에서 로드맵에 넣을 항목만 고른다.
06:00-12:00 · 단계 배치: 세 동기 단계(공유→설치 / 모니터링→케어 / 빌더→랭킹→전환)에 요구사항을 놓고, 각 단계에 "지금 상태 → 다음 한 걸음"을 적는다.
12:00-16:00 · 소유자·검수: 단계마다 담당자(만드는 사람)와 검수자, 검수 시점을 분리해 붙인다.
16:00-20:00 · 마무리: 이번 주에 시작할 첫 단계 하나와 검수 날짜를 확정한다. 강의 이후 첫 실행 항목으로 닫는다.

운영 포인트

세 단계를 다 채우려 하지 말고 가장 먼저 실행할 단계 하나를 완성하게 한다.
"담당자 없음 / 모두가 담당" 같은 표현을 없애고 소유자·검수 시점을 구체화한다.
완료 확인: 첫 단계, 담당자·검수자, 검수 날짜가 있으면 실습 완료로 본다.

Primary source: curriculum.md row 64. Supporting source: interview.md team playground framing. Reference repo: github.com/zep-us/zeude (observation only).

FAST CAMPUS · CHAPTER 06 · KEYNOTE 6-1 · 정리

정리: 세 동기가 세 산출물로, 그게 AI 전환이다

동기	산출물	한 줄
코드보다 운영	AI Native 마인드셋 체크리스트	개인이 purpose·pipeline·impact·operation을 소유한다
공유·모니터링·빌더	팀 AI 인프라 요구사항 명세	Zeude 관찰을 우리 팀 요구사항으로 옮긴다
전환 계획	우리 팀 플레이그라운드 로드맵	설치 보장 → 케어 → 빌더·랭킹 순서로 단계화한다

6-1. 팀 단위 아키텍처 확장16 / 17

FAST CAMPUS · CHAPTER 06 · KEYNOTE END

CLOSING · CHAPTER 06

AI Native 팀으로 가는 길 정리

개인 마인드셋 → 팀 인프라 요구사항 → 플레이그라운드 로드맵

완료: decks/chapter-06.html Cover · 3 클립 · Zeude 아키텍처 · 세팅 · Speaker notes

챕터 이동 이전 · 5장. MCP형 하네스 프로젝트 현재 · 6장. AI Native 팀으로 가는 길 3 클립 2006-1-1 · 마인드셋 2006-1-2 · Zeude 2006-1-3 · 로드맵

WRAP-UP17 / 17