The Workshop
하나의 작업실
하나의 작업실. 세 개의 작업대.
하나의 에이전트 팀. 가운데에 테이블.
핵심 인사이트 — 에이전트는 사람이 아니라 프로젝트에 귀속된다. CEO가 작업할 때, A 단계의 에이전트가 Designer의 커리큘럼 방향과 Dev의 기술 제약을 이미 알고 있다.
The Team
세 개의 작업대
각자의 전문성으로 판단하되, 같은 에이전트 팀이 세 작업대를 오가며 서비스한다
CEO
시장 현실
팀에 가져오는 것
시장 감각, 고객 관계, 코칭 경험, 전략적 프레이밍
에이전트 풀 사용 방식
H-A-H로 콘텐츠/전략, A-H-A로 코칭 세션 준비
고유 가치
다른 두 사람이 만든 것이 시장에서 작동하는지 판단
없으면
훌륭하지만 팔리지 않는 프로그램
"고객이 이것을 원하는가? 팔 수 있는가?"
Designer
가치 현실
팀에 가져오는 것
학습자 공감, 경험 설계, 커리큘럼 아키텍처, 교육 철학
에이전트 풀 사용 방식
A-H-A로 커리큘럼 설계, H-A-H로 활동 설계
고유 가치
고객이 원하는 것과 학습자가 필요한 것 사이의 차이를 본다
없으면
잘 팔리지만 효과 없는 프로그램
"학습자에게 효과가 있는가? 진정한가?"
Dev
DRI기술 현실
팀에 가져오는 것
기술 가능성, 시스템 사고, 자동화, 인프라
에이전트 풀 사용 방식
H-A-H로 시스템 설계, 에이전트 풀 인프라 구축/유지
고유 가치
다른 두 사람의 비전을 실제로 작동하는 시스템으로 바꾼다
없으면
좋은 설계가 수작업으로만 전달 가능 — 확장 불가
"만들 수 있는가? 유지 가능한가?"
Shared Agent Pool
하나의 에이전트 팀
에이전트는 사람이 아니라 프로젝트에 귀속된다
Coordinator
워크플로 관리, 핸드오프, 의존성 추적
Research
시장, 고객, 프레임워크, 과거 프로젝트 리서치
Production
초안 작성, 자료 제작, 코드 구현
QA
브랜드 보이스, 철학 정합성, 교차 검증
Sentinel
시장 동향, 고객 패턴, 경쟁사, 품질 상시 모니터링
Devil's Advocate
주요 결정 전 반론 자동 생성
Memory
모든 프로젝트의 결정, 결과, 학습 축적
왜 공유인가 — QA Agent는 CEO의 고객 약속과 Designer의 커리큘럼과 Dev의 기술 구현이 서로 모순되는지 확인한다. 이것은 개인 에이전트 모델에서는 불가능하다.
Project Workflow
프로젝트가 흘러가는 방식
기업 교육 프로그램 수주 → 설계 → 납품 예시
수주
H-A-HCEO 중심. Agent Pool이 리서치, 과거 프로젝트 참조, 제안서 초안 지원. 다른 팀원은 아직 관여하지 않지만 에이전트가 컨텍스트를 축적.
방향 결정
The TableTable세 사람이 함께 앉는다. CEO는 고객 약속, Designer는 학습 설계, Dev는 기술 가능성. Agent Pool이 사전 리서치, 반론, 과거 비교를 준비.
병렬 제작
교차 가시성H-A-H / A-H-A세 사람이 동시에 작업하지만, Agent Pool이 교차 가시성을 제공한다.
고객 커뮤니케이션, 코칭 콘텐츠
커리큘럼 설계, 활동 설계
플랫폼 구축, 자동화 설정
QA Agent: "CEO가 고객에게 '실시간 피드백'을 약속했는데, Designer의 커리큘럼에 실시간 피드백 요소가 없습니다"
통합 + QA
QAQA Agent가 세 사람의 결과물을 교차 검증. CEO의 약속 vs Designer의 설계 vs Dev의 구현. Devil's Advocate가 가장 큰 약점을 제기.
납품 + 학습
Sentinel + MemoryCEO가 고객에게 전달. Sentinel이 실행 후 효과 모니터링. Memory가 학습 축적 → 다음 프로젝트의 Research가 참조.
Interaction Modes
두 가지 상호작용 모드
H — A — H
인간이 시작할 때
사용 시점 — CEO가 콘텐츠를 쓸 때, Dev가 시스템을 설계할 때
A — H — A
에이전트가 준비할 때
사용 시점 — Designer가 커리큘럼을 설계할 때, CEO가 코칭 세션을 준비할 때
개인 에이전트 모델과의 차이 — 개인 에이전트 모델에서는 A 단계의 에이전트가 한 사람의 작업만 안다. 공유 에이전트 풀에서는 세 사람의 작업 모두를 안다.
The Table
세 사람이 함께 앉는 순간
The Table은 별도의 레이어가 아니라 프로젝트 워크플로의 일부다
자동 활성화
Coordinator Agent가 트리거
- —프로젝트 시작 시 방향 결정
- —QA Agent가 세 사람의 작업 간 모순 감지
- —Sentinel이 방향 전환이 필요한 시그널 감지
- —프로젝트 완료 시 최종 검토
수동 활성화
아무나 요청
- —"이것은 혼자 결정하기 어렵다"
- —"다른 관점이 필요하다"
정기 활성화
월 1회
- —"BTH는 어디로 가고 있는가?" — 방향 점검
Core Tensions
핵심 긴장
해소하지 않고 안고 가는 것
공유 컨텍스트 vs 개인 공간
에이전트가 모든 것을 알면, 각자의 '생각의 공간'이 줄어든다. 모든 아이디어가 즉시 팀에 노출되면 미완성 상태에서 판단받을 수 있다. 각자의 '초안 공간'은 보호되어야 한다.
에이전트 풀의 통제
Dev가 구축하고 유지하지만, 세 사람 모두가 사용한다. 에이전트의 행동 기준을 누가 정하는가? 에이전트의 판단 기준은 The Table에서 합의.
시장 vs 학습자 vs 기술
이 세 관점은 항상 일치하지 않는다. '빨리 팔아야 한다' vs '제대로 설계해야 한다' vs '유지 가능하게 만들어야 한다.' 이 긴장이 BTH의 품질을 만든다. 해소하면 안 된다.
Non-Negotiables
비협상 조건
Agent Pool의 DRI는 Dev
구축, 유지, 튜닝은 Dev가 담당한다. 그러나 사용 방식은 각자 자율.
Human judgment는 대체 불가
에이전트는 정보를 제공하고 모순을 감지하지만, 결정은 인간이 한다.
The Table은 의무가 아니라 초대
프로젝트 방향 결정은 함께, 실행 방법은 각자.
월간 Blank Canvas Day
매달 한 번, AI 없이 작업물 하나를 처음부터 직접 만든다. 질문 형성 능력 보호.
모든 결과물에 세 관점 검증
QA Agent가 자동 교차 검증. 세 사람의 약속/설계/구현이 일치하는지.
Why Three
세 사람의 판단이 동시에 작동할 때만 가능한 것 — 시장이 원하고 (CEO) + 학습자에게 효과적이고 (Designer) + 기술적으로 지속 가능한 (Dev) 프로그램.
에이전트 풀이 아무리 강력해도, Research Agent는 시장 감각을 가질 수 없고, Production Agent는 학습 경험을 설계할 수 없고, QA Agent는 기술적 트레이드오프를 결정할 수 없다.