VibeWorks Thinking and How

AI 에이전트 시대, 내 일로 계속 성장하는 법

발행일: 2026-06-20

이 책은 AI를 잘 쓰는 요령 목록이 아니다. 내 실제 업무 하나를 골라 더 분명하게 보고, 더 작게 나누고, 더 나은 기준으로 판단한다. 그렇게 판단한 과정을 다음 업무와 팀이 다시 쓸 자산으로 남기는 교과서다. 각 장은 개념 설명, 시각 맵, 예시, 실습, 자기 업무 적용, 평가 기준으로 이어진다.

먼저 하나의 업무 장면에서 시작한다

다음 주 교육 신청 안내를 준비한다고 해보자. 일정, 대상, 신청 링크, 자주 묻는 질문, 안내 화면 초안이 흩어져 있다. AI에게 “안내문 써줘”라고 하면 문장은 빨리 나오지만, 실제 업무는 아직 남는다. 누가 읽는지, 어디에 붙일지, 무엇을 확인해야 하는지, 수정 흔적은 어디에 남길지 다시 사람이 정리해야 한다.

VibeWorks는 이 장면을 “좋은 질문 하나”로 끝내지 않는다. 먼저 업무를 작게 나누고, AI가 맡을 일과 사람이 판단할 일을 가른 뒤, 검토 가능한 산출물로 남긴다.

이 책의 모든 장은 이 감각에서 출발한다. 용어와 기술은 뒤에서 따라오지만, 출발점은 늘 “내 일이 실제로 굴러가게 만들 수 있는가?”라는 질문이다.

이 책으로 만들게 될 것

이 책을 끝까지 따라오면 독자는 AI에게 질문을 잘하는 사람에서 멈추지 않는다. 자기 업무를 AI가 이해하고 실행하고 점검할 수 있는 구조로 바꾸는 사람이 된다. 처음에는 작은 문서 하나를 만들고, 뒤로 갈수록 지식, 도구, 역할, 평가 기준이 연결된 작업 시스템을 만든다.

처음부터 모든 용어를 외울 필요는 없다. 이 책에서는 용어를 먼저 암기하기보다, “내가 지금 무엇을 만들고 있는가?”를 먼저 잡고 필요한 말만 그때그때 붙인다.

낯선 말, 처음엔 이렇게만 읽으세요

이 책에는 영어 약어와 파일 이름이 나온다. 처음 읽을 때는 정확한 기술 정의보다 역할을 먼저 잡으면 된다. 아래 표는 초반 독자가 문장을 놓치지 않도록 돕는 읽기용 해석이다.

정확한 정의는 뒤에서 다시 다룬다. 초반에는 “이 말이 지금 어떤 일을 돕는가?”만 붙잡고 읽어도 충분하다.

용어 고정 — 정확한 정의는 여기서 확정한다

• RAG (Retrieval-Augmented Generation): 질문 시점에 외부 문서를 검색해 근거로 삼는 방식이다.
• MCP (Model Context Protocol): AI 애플리케이션이 외부 도구와 데이터에 연결되는 표준 프로토콜이다.
• AgentOps: 에이전트 실행 품질, 비용, 실패, 로그를 운영 기준으로 관리하는 활동이다.
• Handoff: 한 에이전트나 역할이 다음 역할로 작업 맥락을 넘기는 방식이다.

이 책을 읽는 방법

1. 먼저 각 장의 “현실 업무 상황”을 읽고 자신의 업무와 비슷한 장면을 찾는다.
2. 장별 학습 장면으로 지금 할 일과 판단 흐름을 먼저 확인한다.
3. Worked Example을 본 뒤 Guided Practice를 따라 쓴다.
4. My Work Application에 자기 업무 파일명과 팀 상황을 적는다.
5. 평가 루브릭으로 산출물이 실제로 쓸 수 있는지 확인한다.

책 전체 지도

VibeWorks의 기본 사이클은 감지(Sense) → 틀 잡기(Frame) → 꺼내기(Externalize) → 받침대(Scaffold) → 역할 나누기(Orchestrate) → 근거 붙이기(Ground) → 점검(Evaluate) → 배포(Publish)다. 아래 전체 맵은 이 사이클과 0-8단계 교과서 장, 기술 지식, 산출물, 운영 기준을 함께 보여준다.

출처와 최신성 경계

이 교과서는 Naturalistic Decision Making, Cognitive Task Analysis, Cognitive Apprenticeship, Deliberate Practice, Learning Transfer, Human-Centered AI, Sociotechnical Systems 같은 학문과 이론을 근거 축으로 삼고, 그 위에 AI 에이전트, 지식관리, 워크플로 자동화 분야의 공개 자료를 결합해 구성했다. VibeWorks의 고유성은 Sense -> Frame -> Externalize -> Scaffold -> Orchestrate -> Ground -> Evaluate -> Publish 흐름, 장별 학습 장면, 실습 템플릿, 운영 루브릭에 담았다.

이 발행본은 2026-06-21 eBook 판으로 제공한다. 빠르게 바뀌는 AI 도구 기능, 제품 화면, 공식 문서 세부사항은 고정 지식으로 단정하지 않고 후속 eBook 버전에서 갱신한다. 수업이나 공개 발행에는 판 번호와 갱신일을 함께 제공한다.

AI는 정말 업무를 바꾸는가 — 증거와 한계

이 책의 출발점(“AI를 잘 쓰는 요령 목록이 아니다”)은 정서가 아니라 증거에 기댄다. 실증 연구는 효과가 분명하면서도, 그 효과가 사람의 판단에 달려 있다는 것을 함께 보여준다.

두 가지가 반복된다. 첫째, 들쭉날쭉한 경계(jagged frontier) — AI가 잘하는 일과 못하는 일이 비슷한 난이도에서도 갈린다. 최고 성과자는 AI에 다 맡긴 사람이 아니라 그 경계를 알고 자기 판단을 얹은 사람이다. 둘째, 도입과 성과는 다르다 — 조직이 학습·운영 체계를 갖추지 않으면 도구를 써도 손익이 바뀌지 않는다. 이 책이 “사람이 판단 한 칸을 더 얹는다”를 반복하는 이유가 여기에 있다.

교과서 설계 원리

이 교과서가 키우려는 것은 도구 사용법이 아니라, 복잡한 현장에서 스스로 판단하는 힘이다. 우리가 일하는 상황과 문제를 푸는 상황은 대부분 복잡하고, 정보가 불완전하며, 사람과 도구와 제약이 계속 바뀐다. 그래서 이 교과서는 정답을 외우는 방식보다 현장을 감지하고, 상황에 맞게 대응하고, 그 대응을 AI가 실행 가능한 구조로 바꾸는 방식을 다룬다. 목표는 AI를 실제 상황에 쓰면서 전문가로서의 판단력과 실행력을 계속 높이는 것이다.

읽고 이해하는 책이 아니라, 각 장마다 직접 판단하고, 작성하고, 실행하고, 자기 업무에 옮겨보는 워크북/템플릿형 교과서를 지향한다.

여기서 VibeWorks는 “vibe를 감지하고, works로 구현한다”는 뜻의 작업 철학이다. 즉, 아직 명확히 언어화되지 않은 의도, 문제감, 흐름, 가능성을 먼저 감지한 뒤, 그것을 문서, 지식체계, 에이전트, 자동화, 평가 가능한 산출물로 바꾸는 방식이다.

그래서 Vibe Working의 핵심 경험은 “무언가가 실제로 되기 시작한다”는 감각에 가깝다. 막연한 요청이 작업 단위로 나뉘고, 흩어진 지식이 파일과 기준으로 묶이며, AI가 따라 할 수 있는 구조가 생기고, 마지막에는 사람이 다시 판단하고 개선할 수 있는 결과물이 남는 경험이다.

이론적 근거

VibeWorks는 “AI를 잘 쓰는 법”보다 “복잡한 현장에서 전문가가 어떻게 보고, 판단하고, 구조화하고, 반복해서 개선하는가”를 중심에 둔다. 이 관점은 현장 판단 연구, 전문가 암묵지 분석, 인지적 도제, 학습 전이 연구와 맞닿아 있다.

이론을 VibeWorks 사이클로 옮기는 법

위 이론들은 장식용 배경지식이 아니라, VibeWorks의 각 단계가 왜 필요한지를 설명하는 설계 근거다. 먼저 NDM과 RPD는 사람이 모호한 상황에서 단서를 읽고 실행 가능한 방향을 잡는 과정을 설명하므로 Sense와 Frame의 근거가 된다. CTA는 전문가의 숨은 판단을 질문과 기준으로 드러내는 방법이므로 Externalize에 해당한다. Cognitive Apprenticeship은 보여주기, 따라 하기, 독립하기의 학습 흐름을 만들기 때문에 Scaffold와 Orchestrate를 지탱한다. Deliberate Practice는 작은 과제와 즉시 피드백을 통해 수행을 개선하게 하므로 Evaluate와 연결된다. Learning Transfer는 배운 것을 실제 업무와 팀 자산으로 옮기는 기준이므로 Publish의 교육적 이유가 된다.

이 교과서의 핵심 관점

Vibe는 단순한 기분이 아니라, 복잡한 상황에서 아직 말로 정리되지 않은 압력, 모호함, 가능성, 변화의 방향을 감지하는 출발점이다. Thinking, How, Works는 그 감지를 판단, 구조, 반복 가능한 실행으로 바꾸는 단계다.

교육 설계 원리

VibeWorks 교과서는 기술 개념을 나열하는 방식이 아니라, 학습자가 자신의 업무와 판단 상황에서 AI를 실제로 다루게 만드는 방식으로 설계한다. 아래 원리는 장별 상황, 예시, 실습, 평가 루브릭이 왜 필요한지를 설명하는 설계 기준이다.

참고 근거

학습과학 근거 — 이 교재의 교수설계가 기대는 1차 문헌이다.

• Worked Examples / Cognitive Load (이 책의 「예시 풀이」 구조의 근거). 초심자는 직접 풀기보다 풀이가 다 나온 예시를 학습할 때 더 빠르고 정확하게 배운다. 불필요한 인지부하가 줄어 스키마 획득에 집중하기 때문이다. Sweller & Cooper (1985), Cognition and Instruction 2(1); Sweller (1988), Cognitive Science 12(2); Renkl (2002), Learning and Instruction 12(5).
• Naturalistic Decision Making / RPD. 전문가는 대안을 비교하기보다 상황을 패턴으로 인식해 곧장 그럴듯한 행동안을 떠올린 뒤 머릿속 시뮬레이션으로 검증한다. Klein (1998), Sources of Power, MIT Press; Klein, Orasanu, Calderwood & Zsambok (1993), Decision Making in Action.
• Cognitive Task Analysis. 전문가는 자기 전략을 자동화해 말로는 잘 설명하지 못하므로, 구조화 인터뷰로 암묵지를 끌어낸다. Clark & Estes (1996), International Journal of Educational Research 25(5); Crandall, Klein & Hoffman (2006), Working Minds, MIT Press.
• Cognitive Apprenticeship. 보이지 않는 사고를 modeling → coaching → scaffolding → articulation → reflection 순으로 가시화해 가르친다. Collins, Brown & Newman (1989), in Resnick (Ed.), Knowing, Learning, and Instruction, 453–494.
• Deliberate Practice. 수행 차이는 명확한 목표·즉각 피드백·약점 교정이 있는 의도적 연습으로 대부분 설명된다. 단순 반복이 아니다. Ericsson, Krampe & Tesch-Römer (1993), Psychological Review 100(3).
• Learning Transfer / Situated Learning. 학습은 실천공동체 참여 과정이며, 교실 지식은 실제 업무 맥락으로 옮겨 써야 오래 남는다. Lave & Wenger (1991), Situated Learning, Cambridge University Press. 원거리 전이(far transfer)가 쉽게 일어나지 않는다는 점은 Barnett & Ceci (2002), Psychological Bulletin 128(4), 612–637.
• Human-Centered AI. 높은 자동화와 높은 인간 통제를 동시에 달성하는 설계가 신뢰·안전한 AI다. Shneiderman (2020), International Journal of Human–Computer Interaction 36(6) (arXiv:2002.04087).
• Sociotechnical Systems. 기술과 사람·조직은 따로 떼어 설계할 수 없다 — Trist & Bamforth (1951), Human Relations 4(1), 3–38.

AI 에이전트 기술 — 각 기술 장의 1차 출처다.

• 에이전트 추론·행동 루프: ReAct — Yao et al. (2022), arXiv:2210.03629. 보조: Reflexion — Shinn et al. (2023), arXiv:2303.11366.
• RAG: Lewis et al. (2020), “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, NeurIPS, arXiv:2005.11401.
• 온톨로지·지식그래프: Gruber (1993), “A Translation Approach to Portable Ontology Specifications”, Knowledge Acquisition 5(2), 199–220.
• 서브에이전트·멀티에이전트: Anthropic (2025), “How we built our multi-agent research system”. 보조: AutoGen — Wu et al. (2023), arXiv:2308.08155.
• MCP: Anthropic 발표(2024-11-25); 정식 사양은 modelcontextprotocol.io/specification.
• 평가·AgentOps: LLM-as-a-Judge — Zheng et al. (2023), arXiv:2306.05685; AgentBench — Liu et al. (2023), arXiv:2308.03688.

각 장의 표준 구성

모든 장은 같은 학습 리듬을 따른다. 이 구조는 학습자가 설명을 읽는 데서 멈추지 않고, 실제 자기 업무에서 쓸 수 있는 산출물을 만들게 하기 위한 표준이다.

# VibeWorks 장 설계 템플릿

## 이 장에서 만들 것

## 현실 업무 상황

## 핵심 개념

## 전문가의 사고 과정

## Worked Example

## Guided Practice

## My Work Application

## 표준 템플릿

## 평가 루브릭

## 이번 주에 적용할 한 가지

VibeWorks 기본 사이클

VibeWorks의 기본 사이클은 다음 8단계다. 영어 이름은 외울 항목이 아니라 흐름 이름이다. 처음에는 감지하기 → 틀 잡기 → 밖으로 꺼내기 → 받침대 만들기 → 역할 나누기 → 근거 붙이기 → 점검하기 → 배포하기로 읽어도 된다.

1. Sense(감지하기): 문제의 분위기, 의도, 맥락을 감지한다.
2. Frame(틀 잡기): 문제를 학습 가능하고 실행 가능한 프레임으로 바꾼다.
3. Externalize(밖으로 꺼내기): 머릿속 판단과 암묵지를 문서, 표, 개념어, 규칙으로 꺼낸다.
4. Scaffold(받침대 만들기): AI가 따라갈 수 있는 파일, 템플릿, 절차를 만든다.
5. Orchestrate(역할 나누기): 에이전트와 서브에이전트가 역할을 나누어 일하게 한다.
6. Ground(근거 붙이기): 문서, 출처, 지식 구조로 답변의 근거를 붙인다.
7. Evaluate(점검하기): 품질, 안전성, 재현성, 비용을 평가한다.
8. Publish(배포하기): 교재, 플레이북, 제품, 자동화 시스템으로 배포한다.

단계별 전체 커리큘럼

마지막 네 열은 각 단계에서 배우는 AI 주제, 학습 키워드, 관련된 AI 기술 용어와 키워드, 그리고 그 개념을 써서 직접 작성해 남기는 결과물을 구분한다.

0단계. AI 작업관 전환

한 문장 메시지: AI는 답변기가 아니라 모호한 의도와 문제감을 작업 가능한 구조로 바꾸는 협업 시스템이다.

이 장에서 만들 것

이 장을 끝내면 독자는 AI 작업 지도를 남긴다. 이 산출물은 다음 장에서 AI가 읽거나, 사람이 다시 판단하거나, 팀 표준으로 옮길 수 있어야 한다.

AI 관련 주제와 키워드

현실 업무 상황

팀 안에서 “AI 관련해서 알아야 할 것을 정리해 달라”는 요청을 받았다. 그냥 용어를 나열하면 자료는 생기지만, 교육과 실행으로 이어지는 구조는 남지 않는다.

학습 장면

막연한 요청이 AI 작업 지도로 바뀌는 장면을 먼저 본다. 독자는 AI를 답변 생성기가 아니라 목적, 맥락, 도구, 평가가 연결된 작업 구조로 이해한다.

전문가의 사고 과정

전문가는 요청 문장보다 먼저 요청이 놓인 장면을 본다. 이 요청은 정보 수집이 아니라 앞으로 반복해서 쓸 작업 기준을 만들려는 움직임이다.

학습 목표

이 단계의 목표는 AI를 단순한 답변 생성기가 아니라, 사람의 의도를 작업 가능한 구조로 바꾸는 협업 시스템으로 이해하는 것이다. 학습자는 AI에게 질문을 던지는 수준을 넘어, AI가 일할 수 있는 환경, 문맥, 규칙, 도구, 평가 기준을 설계하는 관점을 갖게 된다.

핵심 개념

핵심 개념을 쉽게 보기

기존에는 사람이 컴퓨터가 이해하는 언어와 절차를 배워야 했다. VibeWorks에서는 그 방향을 뒤집어, AI가 사람의 판단 과정 안으로 들어와 상황을 정리하고 실행 가능한 구조를 함께 만든다.

기존 컴퓨팅
사람 -> 코드/도구 언어를 배움 -> 기계의 작업 흐름 안으로 들어감

VibeWorks
사람의 판단 상황 -> AI가 감지/정리/제안/검증을 도움 -> 사람이 책임지고 결정

이렇게 생각한다

처음부터 “무슨 프롬프트를 써야 하지?”라고 묻지 않는다. 먼저 “지금 이 문제의 vibe는 무엇인가?”를 묻는다. 여기서 vibe는 감정적 분위기만이 아니라, 문제의 압력, 불확실성, 숨은 의도, 원하는 변화의 방향을 포함한다.

예를 들어 “AI 관련해서 알아야 할 것들 목록화”라는 요청의 vibe는 단순한 용어 정리가 아니다. 그것은 앞으로 강의, 교재, 커뮤니티, 프로젝트 운영에 쓸 지식 지도를 만들고 싶은 움직임이다. 이때 AI는 답변자가 아니라 지식 지도 제작자가 되어야 한다.

How

1. 사용자의 표현을 그대로 잡는다.
2. 표현 안에 있는 목적, 대상, 산출물, 긴장감을 분리한다.
3. 문제를 하나의 작업 단위로 다시 쓴다.
4. 이 작업을 반복 가능한 형식으로 만든다.

예시 풀이 (Worked Example)

상황

이번 달에도 새 교육이 하나 열린다. 팀장이 지나가며 “이번 교육 안내 좀 정리해줘”라고만 했다. 안내문을 새로 쓰라는 건지, 지난 공지를 다듬으라는 건지, 사람들이 자꾸 묻는 걸 모아 달라는 건지 분명하지 않다. 아직 만들어 둔 도구도, 정리된 파일도 없다. 이 모호한 한마디를 AI에게 그대로 던지기 전에, 먼저 표면 요청과 실제 목적을 갈라서 “무슨 작업인지”부터 한 장으로 잡으려 한다.

① AI에게 이렇게 요청한다 (그대로 따라 써도 된다)

나는 사내 교육 운영을 혼자 맡고 있어. 방금 팀장한테
"이번 교육 안내 좀 정리해줘"라는 요청을 받았는데, 뭘 만들라는 건지 모호해.

이 요청을 바로 실행하지 말고, 표면 요청과 실제 목적을 갈라서
아래 형식의 'AI 작업 지도'로 정리해 줘.

- 감지한 vibe / 사용자의 실제 목적 / 작업 대상 /
  필요한 지식 범주 / 산출물 / 다음 단계

조건:
- 내가 주지 않은 사실(마감일, 대상자 수 등)은 지어내지 말고 `# 미정`으로.
- 산출물은 "안내 정리"처럼 모호하게 말고, 다음에 바로 손댈 수 있게 구체적으로.

② AI가 이렇게 답한다 (초안)

③ 사람이 이렇게 점검하고 고친다

VibeWorks의 핵심은 AI 답을 그대로 쓰지 않고, 사람이 판단 한 칸을 더 얹는 것이다. 초안에서 세 군데가 걸린다.

④ 최종 AI 작업 지도

이제 “안내 정리”라는 모호한 한마디가, 무엇을 만들고 무엇이 아직 비었는지가 보이는 한 장으로 바뀌었다. 다음 달에도 같은 요청이 오면 이 지도부터 채우고 시작하면 된다.

자주 하는 실수

• 모호한 요청을 받자마자 산출물부터 만든다. “정리해줘”를 안내문 작성으로 바로 점프하면, 정작 팀장이 원한 게 FAQ였을 때 처음부터 다시 한다.
• AI가 채운 빈칸을 사실로 믿는다. “참가비”, “강사 이력”처럼 그럴듯하게 채워진 항목을 확인 없이 두면, 지어낸 정보가 안내문까지 흘러간다.
• 다음 단계에 사람 승인 칸을 안 넣는다. “작성 → 발송”으로 직행하면 검토 없이 나가고, 목적·승인을 사람이 쥔다는 기본값이 깨진다.

Guided Practice

다음 문장을 VibeWorks 방식으로 해석하라.

AI를 기술 관점으로 알아야 할 것들을 목록화하고 싶다.

작성해야 할 것:

• 감지한 vibe
• 실제 목적
• 필요한 지식 범주
• 최종 산출물 형식
• 다음 작업 단계

표준 템플릿

## AI 작업 지도

- 감지한 vibe:
- 사용자의 실제 목적:
- 작업 대상:
- 필요한 지식 범주:
- 산출물:
- 다음 단계:

평가 루브릭

이번 주에 적용할 한 가지

자신이 자주 받는 모호한 요청 하나를 골라, 표면 요청과 실제 목적을 분리해 AI 작업 지도로 작성한다.

My Work Application

자기 업무에 옮길 때는 아래 세 문장을 실제 파일명과 상황명으로 채운다.

• 최근 받은 모호한 요청 1개를 적는다.
• 표면 요청과 실제 목적을 나눈다.
• 다음 산출물을 파일명까지 정한다.

1단계. 파일 기반 지시체계

한 문장 메시지: 좋은 AI 협업은 매번 설명하는 대신 프로젝트 맥락과 규칙을 파일로 남기는 데서 시작한다.

이 장에서 만들 것

이 장을 끝내면 독자는 AGENTS.md, CLAUDE.md, SKILL.md 초안을 남긴다. 이 산출물은 다음 장에서 AI가 읽거나, 사람이 다시 판단하거나, 팀 표준으로 옮길 수 있어야 한다.

AI 관련 주제와 키워드

현실 업무 상황

같은 프로젝트에서 AI에게 매번 폴더 구조, 금지 사항, 작업 방식, 산출물 형식을 다시 설명하고 있다. 설명은 반복되지만 결과는 매번 조금씩 흔들린다.

학습 장면

흩어진 프로젝트 규칙이 읽을 수 있는 파일로 고정되는 장면을 보여준다. 독자는 AGENTS.md, CLAUDE.md, SKILL.md를 각각 무엇에 쓰는지 먼저 구분한다.

전문가의 사고 과정

전문가는 프롬프트를 길게 쓰기 전에 AI가 읽을 수 있는 프로젝트 안내판을 만든다. 반복 설명을 파일로 바꾸면 협업 품질이 개인 기억에 덜 의존한다.

학습 목표

이 단계의 목표는 AI가 프로젝트 안에서 일할 때 필요한 맥락과 규칙을 파일로 제공하는 방법을 배우는 것이다. AGENTS.md, CLAUDE.md, SKILL.md, .claude/agents/, settings.json 같은 파일은 AI 작업 시스템의 운영 문서에 해당한다.

핵심 개념

AGENTS.md는 코딩 에이전트를 안내하기 위한 단순하고 열린 형식이다. 사람에게 README가 있듯이, 에이전트에게는 AGENTS.md가 프로젝트 맥락과 작업 지침을 제공한다. 출처: https://github.com/agentsmd/agents.md

Claude Code 문서는 프로젝트 메모리를 ./CLAUDE.md 또는 ./.claude/CLAUDE.md에 둘 수 있다고 설명한다. 출처: https://code.claude.com/docs/en/memory

Claude Code SDK 문서는 Agent Skills를 ./.claude/skills/ 아래의 SKILL.md 파일로 저장한다고 설명한다. 출처: https://code.claude.com/docs/en/skills

따라서 Codex에서 CLAUDE.md에 가장 가까운 파일은 AGENTS.md다. 다만 AGENTS.md는 Claude 전용 메모가 아니라 여러 AI 코딩 에이전트가 읽을 수 있는 공개 형식의 프로젝트 지침 파일이다. MEMORY.md는 이 표준에 포함된 필수 파일이 아니며, 별도 운영 기억 체계를 만들 때만 선택적으로 둔다.

이렇게 생각한다

파일 기반 지시체계의 핵심은 “AI에게 반복해서 설명하지 않아도 되는 구조”를 만드는 것이다. 좋은 프로젝트는 사람에게 온보딩 문서가 있듯이, AI에게도 온보딩 문서가 있어야 한다.

이 단계에서 중요한 질문은 다음과 같다.

• 이 프로젝트에서 AI가 절대 놓치면 안 되는 맥락은 무엇인가?
• AI가 자주 실수할 수 있는 지점은 무엇인가?
• 어떤 명령어, 파일, 폴더, 규칙을 먼저 알려줘야 하는가?
• 이 프로젝트의 작업 철학은 무엇인가?

How

AGENTS.md 표준 구조

# AGENTS.md

## Project Overview

## Directory Map

## Build and Test Commands

## Coding Conventions

## Documentation Conventions

## Security Rules

## Do Not Touch

## Pull Request / Review Rules

CLAUDE.md 표준 구조

# CLAUDE.md

## Project Memory

## Working Style

## Important Decisions

## Repeated Commands

## User Preferences

## Known Pitfalls

## Current Priorities

SKILL.md 표준 구조

---
name: skill-name
description: When this skill should be used
---

# Skill Name

## Purpose

## Scope

## When to Use

## Should Trigger

## Should Not Trigger

## Inputs

## Procedure

## Output Format

## Quality Criteria

## Failure Signals

## References

Skill은 업무 절차 자산이다

SKILL.md는 좋은 문장을 모아 둔 프롬프트 창고가 아니다. 반복되는 업무를 다시 실행할 수 있도록 목적, 호출 조건, 입력, 절차, 산출물, 품질 기준, 실패 신호를 묶은 절차 자산이다.

예시 풀이 (Worked Example)

상황

사내 교육 운영을 맡고 있다. 매달 새 교육이 열릴 때마다 신청 안내문, FAQ, 일정표를 다시 만든다. 그때마다 AI에게 “우리 교육은 정원 20명, 신청 마감 3일 전 리마인드 발송, 노쇼가 생기면 대기자가 자동 승계”라는 규칙을 처음부터 다시 설명하고 있다. 이 반복 설명을 교육운영 프로젝트의 AGENTS.md 한 장으로 고정하려 한다.

① AI에게 이렇게 요청한다 (그대로 따라 써도 된다)

나는 사내 교육 운영을 맡고 있어. 매달 교육 안내문·FAQ·일정표를 만들면서
같은 규칙을 반복해서 설명하고 있어. 아래 규칙을 `교육운영` 프로젝트의
AGENTS.md 초안으로 정리해 줘.

조건:
- 표준 섹션을 써: Project Overview / Directory Map / Conventions /
  Security Rules / Do Not Touch
- 내가 주지 않은 정보는 지어내지 말고 `# 미정`으로 남겨 줘.

규칙:
- 정원 20명, 신청 마감 3일 전 자동 리마인드 발송
- 노쇼가 생기면 대기자가 자동 승계
- 안내문 톤은 존댓말, 사내 메신저용 안내는 3줄 이내

② AI가 이렇게 답한다 (초안)

③ 사람이 이렇게 점검하고 고친다

VibeWorks의 핵심은 AI 답을 그대로 쓰지 않고, 사람이 판단 한 칸을 더 얹는 것이다. 초안에서 세 군데가 걸린다.

④ 최종 AGENTS.md

이제 다음 달 교육 때는 이 규칙을 다시 설명하지 않는다. “이번 교육 안내문 초안 만들어 줘”라고만 하면 AI가 AGENTS.md를 읽고 정원·리마인드·톤을 맞춰 온다.

자주 하는 실수

• AI가 채워준 규칙을 검증 없이 그대로 둔다. 지어낸 항목(“환불 7일 전”)이 진짜 규칙처럼 굳는다.
• 도구 사용 습관까지 AGENTS.md에 넣는다. “나는 표로 받는 걸 좋아한다” 같은 협업 취향은 CLAUDE.md로 분리한다.
• 빈 표준 섹션만 만들고 실제 규칙을 안 적는다. 템플릿은 시작일 뿐, 내 규칙이 들어가야 반복 설명이 준다.

Guided Practice

자기 업무에서 실제로 반복되는 프로젝트 하나를 고른다. 회사명이나 강의명보다, “매주 만드는 보고서”, “고객 문의 대응”, “교육자료 제작”처럼 일이 보이는 이름으로 잡는다. 그 프로젝트를 기준으로 다음 세 파일의 첫 초안을 작성하라.

1. AGENTS.md 또는 작업규칙.md
2. CLAUDE.md 또는 도구사용기준.md
3. .claude/skills/repeated-work/SKILL.md 또는 반복업무절차.md

파일명은 예시다. 중요한 것은 이름이 아니라 “무엇을 반복해서 설명하지 않아도 되는가”를 파일로 남기는 일이다.

표준 템플릿

my-work-project/
├── AGENTS.md              # 프로젝트의 목적, 폴더, 금지사항
├── CLAUDE.md              # 내가 쓰는 AI 도구와 협업할 때의 기준
└── skills/
    └── repeated-work/
        └── SKILL.md       # 반복 업무 한 가지의 절차

평가 루브릭

이번 주에 적용할 한 가지

현재 진행 중인 프로젝트 하나를 골라 AGENTS.md 첫 버전을 작성한다. 완벽하게 만들 필요는 없고, 프로젝트 개요, 폴더 구조, 자주 쓰는 명령어, 주의사항 네 가지만 먼저 적는다.

My Work Application

자기 업무에 옮길 때는 아래 세 문장을 실제 파일명과 상황명으로 채운다.

• 현재 프로젝트의 반복 설명 5개를 적는다.
• 그중 파일로 고정할 규칙 3개를 고른다.
• AGENTS.md 첫 버전에 넣을 제목을 정한다.

2단계. 에이전트 기본기

한 문장 메시지: 에이전트는 목표를 받고 도구를 쓰며 관찰과 수정 루프로 일을 수행하는 실행 단위다.

이 장에서 만들 것

이 장을 끝내면 독자는 Agent task card를 남긴다. 이 산출물은 다음 장에서 AI가 읽거나, 사람이 다시 판단하거나, 팀 표준으로 옮길 수 있어야 한다.

AI 관련 주제와 키워드

현실 업무 상황

AI에게 “이 일 해줘”라고 맡기고 싶지만, 어디까지 맡기고 언제 멈춰야 하는지 정해져 있지 않다. 그러면 AI는 답변자는 될 수 있어도 작업자는 되기 어렵다.

학습 장면

목표, 입력, 도구, 중단 조건이 하나의 실행 단위로 묶이는 장면이다. 독자는 에이전트를 추상 개념이 아니라 반복 가능한 작업 카드로 본다.

전문가의 사고 과정

전문가는 에이전트를 사람처럼 꾸미지 않고 작업 단위로 정의한다. 이름, 임무, 입력, 도구, 절차, 중단 조건이 있어야 실행 단위가 된다.

학습 목표

이 단계의 목표는 에이전트가 단순한 챗봇과 어떻게 다른지 이해하는 것이다. 에이전트는 목표를 받고, 계획을 세우고, 도구를 사용하고, 결과를 관찰한 뒤, 필요하면 다시 행동하는 실행 단위다.

핵심 개념

Agent와 Skill의 경계

Agent, Skill, Tool을 섞으면 설계가 흐려진다. Agent는 이번 일을 맡아 실행하는 역할이고, Skill은 반복 가능한 절차 자산이며, Tool은 외부 기능이다.

Agent를 설계할 때는 사람 판단과 LLM 도움과 근거 필요 영역을 분리한다.

이렇게 생각한다

에이전트를 설계할 때는 “똑똑한 AI 하나”를 상상하지 않는다. 대신 “이 작업을 잘하는 사람이라면 어떤 절차와 도구와 판단 기준을 가질까?”를 묻는다.

좋은 에이전트 정의는 다음을 포함한다.

• 무엇을 맡는가?
• 무엇은 맡지 않는가?
• 어떤 도구를 쓸 수 있는가?
• 언제 멈추는가?
• 어떤 형식으로 보고하는가?
• 어떤 상황에서 사람에게 물어보는가?

How

Agent task card

# Agent Task Card

## Name

## Mission

## Scope

## Should Trigger

## Should Not Trigger

## Inputs

## Tools

## Procedure

## Stop Condition

## Output Format

## Escalation Rules

## Quality Criteria

## Failure Signals

근거. 에이전트의 추론–행동 루프는 ReAct(Yao et al. 2022, arXiv:2210.03629)에 기초한다. 관찰 뒤 스스로 고치는 부분은 Reflexion(Shinn et al. 2023, arXiv:2303.11366).

예시 풀이 (Worked Example)

상황

지난달 AGENTS.md를 만들어 두니 정원·리마인드·노쇼 규칙을 매번 설명할 일이 사라졌다. 이번 달에는 한 걸음 더 나가, “이번 달 교육 안내문 초안 작성”을 그때그때 말로 시키지 않고 반복 호출 가능한 작업 단위로 굳히려 한다. 목표·입력·도구·절차가 있고, 무엇보다 AI가 어디서 멈춰 나에게 물어봐야 하는지(중단 조건)가 박힌 Agent task card 한 장을 만든다. 앞 장 AGENTS.md의 고정 규칙(정원 20·리마인드 3일 전·노쇼 승계·존댓말)은 이미 전제로 깔려 있다.

① AI에게 이렇게 요청한다 (그대로 따라 써도 된다)

'이번 달 교육 안내문 초안 작성'을 Agent task card로 정리해 줘.
표준 섹션을 그대로 써: Name / Mission / Scope / Inputs / Tools /
Procedure / Stop Condition / Output Format / Escalation Rules.

전제:
- 프로젝트 규칙은 AGENTS.md에 있다(정원 20명, 마감 3일 전 리마인드,
  노쇼 시 대기자 승계, 안내문은 존댓말). 이 카드에서 다시 정의하지 마.
- 이 카드는 '초안 작성'까지만 맡는다. 실제 발송은 사람이 한다.

조건:
- 내가 주지 않은 정보(날짜·장소·강사명 등)는 지어내지 말고 `# 미정`으로.
- 입력에 신청자 개인정보(이름·연락처)는 넣지 마.
- AI가 혼자 판단하면 안 되는 지점은 Stop Condition / Escalation에 적어.

② AI가 이렇게 답한다 (초안)

③ 사람이 이렇게 점검하고 고친다

VibeWorks의 핵심은 AI 답을 그대로 쓰지 않고, 사람이 판단 한 칸을 더 얹는 것이다. 작업 카드는 “AI가 어디까지 혼자 하느냐”를 정하는 문서라, 약점이 그대로 굳으면 실제 사고로 이어진다.

④ 최종 산출물 — Agent task card

이제 다음 달에는 “안내문 카드 돌려줘”만 하면, AI가 정해진 입력만 받아 초안까지만 만들고 발송 직전에 멈춰 선다. 어디서 멈출지가 카드에 박혀 있으니 매번 “발송은 하지 마”라고 덧붙일 필요가 없다.

자주 하는 실수

• 중단 조건을 “다 하면 끝”으로만 적는다. 빠진 값·발송 직전·권한 밖 상황에서 멈출 지점이 없으면, AI는 멈추는 대신 지어내거나 권한을 넘어선다.
• 필요 없는 도구까지 일단 다 열어준다. 초안만 맡길 카드에 발송·등록 권한을 주면, 검토 전 발송 같은 사고가 카드 한 줄에서 시작된다.
• 편하다는 이유로 개인정보를 입력에 넣는다. “톤 맞춤용 참고”처럼 그럴듯한 명분이 붙어도, 작업 입력에 이름·연락처가 들어가는 순간 안전 규칙이 무너진다. 인원수면 충분하다.

Guided Practice

다음 역할 중 하나를 골라 Agent task card를 작성하라.

• AI 기술 리서처
• 강의 커리큘럼 설계자
• RAG 시스템 설계자
• 지식체계 큐레이터
• 교재 검수자

평가 루브릭

이번 주에 적용할 한 가지

반복적으로 AI에게 맡기는 작업 하나를 골라 Agent task card로 정의한다. 예를 들어 “강의안 초안 작성”, “자료 조사”, “코드 리뷰”, “문서 요약” 중 하나를 선택한다.

My Work Application

자기 업무에 옮길 때는 아래 세 문장을 실제 파일명과 상황명으로 채운다.

• 반복되는 업무 1개를 고른다.
• 그 업무의 입력과 출력물을 적는다.
• 에이전트가 멈춰야 할 조건을 쓴다.

3단계. 서브에이전트와 멀티에이전트

한 문장 메시지: 복잡한 일은 하나의 만능 AI가 아니라 역할과 권한이 분리된 에이전트 협업으로 다룬다.

이 장에서 만들 것

이 장을 끝내면 독자는 서브에이전트 설계표를 남긴다. 이 산출물은 다음 장에서 AI가 읽거나, 사람이 다시 판단하거나, 팀 표준으로 옮길 수 있어야 한다.

AI 관련 주제와 키워드

현실 업무 상황

조사, 작성, 검토, 발행이 한 대화 안에서 뒤섞이고 있다. 대화가 길어질수록 기준이 흐려지고, 누가 무엇을 판단해야 하는지 보이지 않는다.

학습 장면

한 사람이 모든 일을 설명하는 대신 역할을 나누고 넘겨주는 장면을 배치했다. 독자는 역할 경계, 호출 조건, 인계 기준을 한 화면에서 잡는다.

전문가의 사고 과정

전문가는 일을 역할로 나누고, 각 역할이 필요한 정보만 받게 한다. 좋은 멀티에이전트 설계는 에이전트 수가 많은 것이 아니라 핸드오프가 선명한 것이다.

학습 목표

이 단계의 목표는 복잡한 작업을 여러 전문 역할로 나누고, 각 역할이 독립 컨텍스트와 도구 권한을 가지고 일하도록 설계하는 것이다.

핵심 개념

Claude Code는 서브에이전트를 특정 목적과 전문성을 가진 사전 구성 AI personality로 설명하며, 각 서브에이전트가 메인 대화와 분리된 컨텍스트 창과 별도 도구 권한을 가질 수 있다고 설명한다. 출처: https://code.claude.com/docs/en/sub-agents

OpenAI Agents SDK는 handoff를 에이전트가 다른 에이전트에게 작업을 위임하는 방식으로 설명한다. 출처: https://openai.github.io/openai-agents-python/handoffs/

LangGraph는 supervisor 구조를 특화된 에이전트를 중앙 supervisor agent가 조정하는 multi-agent architecture로 설명한다. 출처: https://docs.langchain.com/oss/python/langgraph/agent-supervisor

이렇게 생각한다

멀티에이전트 설계의 핵심은 “누가 더 똑똑한가?”가 아니라 “어떤 역할 분해가 문제를 깨끗하게 만드는가?”다.

한 명의 AI에게 리서치, 설계, 작성, 검수, 배포를 모두 맡기면 컨텍스트가 오염되고 판단 기준이 섞인다. VibeWorks 방식에서는 문제의 흐름을 감지한 뒤, 그 흐름을 역할로 나눈다.

How

표준 서브에이전트 구성

.claude/
└── agents/
    ├── researcher.md
    ├── curriculum-designer.md
    ├── technical-reviewer.md
    ├── ontology-curator.md
    ├── eval-designer.md
    └── publisher.md

서브에이전트 템플릿

---
name: curriculum-designer
description: Use proactively when transforming AI concepts into staged learning modules and textbook chapters.
tools: Read, Grep, Glob
model: sonnet
permissionMode: default
---

You are a curriculum designer for AI literacy, agent architecture, and knowledge system education.

Your job is to transform raw technical material into staged lessons.

Always return:
1. Learning objectives
2. Key concepts
3. Sequence
4. Exercise
5. Assessment rubric

근거. 멀티에이전트 역할 분리와 핸드오프 설계는 Anthropic의 멀티에이전트 시스템 구축 사례(2025)와 AutoGen(Wu et al. 2023, arXiv:2308.08155)을 참고했다.

예시 풀이 (Worked Example)

상황

지난달에 만든 “이번 달 교육 안내문 초안 작성” 작업 카드대로 한 번 돌려 봤더니, 한 대화 안에서 안내문도 쓰고 FAQ도 쓰고 일정표까지 짜다 보니 톤과 기준이 자꾸 섞였다. 안내문은 존댓말로 정중하게 갔다가, FAQ 답이 갑자기 반말투가 되고, 일정표 날짜는 안내문 본문과 어긋났다. 그래서 이 일을 안내문 작성 / FAQ 작성 / 일정표 작성 세 역할로 나누고, 각 역할이 무엇을 받아 무엇을 넘기는지(핸드오프) 정하려 한다. 산출물은 .claude/agents/에 올릴 서브에이전트 설계표다.

① AI에게 이렇게 요청한다 (그대로 따라 써도 된다)

`교육운영` 프로젝트의 안내문 제작 일을 서브에이전트로 나누려고 해.
아래 세 역할로 쪼개서 서브에이전트 설계표를 만들어 줘.

역할:
1) 안내문 작성  2) FAQ 작성  3) 일정표 작성

각 역할마다 이 칸을 채워: 역할 / 책임범위(한 가지만) / 입력 / 도구권한 / 핸드오프(다음 역할에 넘길 것).

조건:
- 한 역할에 책임 하나만. 겹치면 나눠.
- 최종 사용자에게 답하는 역할은 딱 하나만 정해.
- AGENTS.md 규칙(정원 20명·3일 전 리마인드·존댓말·개인정보 본문 금지·`sent/` 수정금지)을 따라.
- 내가 안 준 정보는 지어내지 말고 `# 미정`으로 남겨.

② AI가 이렇게 답한다 (초안)

③ 사람이 이렇게 점검하고 고친다

VibeWorks의 핵심은 AI 답을 그대로 쓰지 않고, 사람이 판단 한 칸을 더 얹는 것이다. 초안에서 네 군데가 걸린다.

④ 최종 산출물 — 서브에이전트 설계표

세 역할은 각자 좁은 책임 하나만 맡고, notice-writer가 확정한 교육명·일시를 한 줄 요약으로 넘기면 나머지 둘이 그걸 받아 이어 간다. 발송은 사람이 마지막에 한 번만 한다.

자주 하는 실수

• 한 에이전트에 책임을 몰아준다. “안내문 쓰는 김에 FAQ랑 발송까지” 하면 역할을 나눈 의미가 사라지고 톤·기준이 다시 섞인다.
• 핸드오프에 “넘긴다”만 적고 무엇을 넘길지는 안 정한다. 다음 역할이 빈손으로 이어받아, 결국 사람이 둘 사이를 또 설명한다.
• 모든 에이전트에게 발송 권한을 준다. 최종 응답자가 중복되면 누가 마지막에 내보냈는지 추적이 안 되고, 확정 전 안내문이 새어 나갈 수 있다.

Guided Practice

본인이 가진 업무 설명 문서나 이 책의 AI 기술 용어 표를 기준으로, 한 사람이 혼자 하던 일을 여러 역할로 나누어 본다. 이름은 영어 코드명이 아니어도 된다. 먼저 아래 다섯 역할을 자기 업무 말로 바꾸고, 각 역할이 받을 입력과 남길 산출물을 한 줄씩 적는다.

1. 자료 조사 역할
2. 구성 설계 역할
3. 용어와 분류 정리 역할
4. 품질 검토 역할
5. 발행 또는 공유 역할

평가 루브릭

이번 주에 적용할 한 가지

자신의 업무 흐름에서 최소 세 개의 역할을 분리한다. 예를 들어 researcher, writer, reviewer를 만들고, 각각의 입력과 출력 형식을 한 줄씩 정의한다.

My Work Application

자기 업무에 옮길 때는 아래 세 문장을 실제 파일명과 상황명으로 채운다.

• 복잡한 업무 하나를 3개 역할로 나눈다.
• 각 역할의 입력과 출력물을 적는다.
• 다음 역할로 넘길 때 필요한 요약 형식을 정한다.

4단계. RAG와 검색 기반 지식

한 문장 메시지: AI가 근거 있게 답하려면 문서를 검색 가능한 지식 단위로 준비하고 질문 시점에 회수해야 한다.

이 장에서 만들 것

이 장을 끝내면 독자는 RAG 설계서를 남긴다. 이 산출물은 다음 장에서 AI가 읽거나, 사람이 다시 판단하거나, 팀 표준으로 옮길 수 있어야 한다.

AI 관련 주제와 키워드

현실 업무 상황

AI가 내부 기억만으로 그럴듯하게 답하고 있다. 하지만 팀 문서, 최신 기준, 실제 파일을 근거로 삼지 않으면 답변은 업무 기준이 되기 어렵다.

학습 장면

AI 답변이 기억이 아니라 문서 검색과 근거 확인을 거쳐 만들어지는 장면이다. 독자는 검색, 분할, 인용, 평가가 왜 함께 필요한지 본다.

전문가의 사고 과정

전문가는 “AI가 무엇을 아는가”보다 “질문 순간에 어떤 문서를 어떻게 가져오는가”를 본다. 근거 있는 답변은 문서 준비와 검색 기준에서 나온다.

학습 목표

이 단계의 목표는 AI가 내부 기억만으로 답하지 않고, 외부 문서와 지식 저장소에 근거해 답하도록 만드는 방법을 배우는 것이다.

핵심 개념

RAG는 관련 문서를 검색한 뒤 그 내용을 모델 입력에 넣어 답변을 생성하는 방식으로 설명된다. 출처: https://ai-tldr.dev/learn/rag/rag-fundamentals/what-is-rag/

Answer Block과 근거 레이어

RAG의 목표는 문서를 많이 넣는 것이 아니라, 답변이 어떤 근거에서 나왔는지 독자가 따라갈 수 있게 만드는 것이다. 그래서 검색된 문서는 최종 답변에서 Answer Block과 근거 레이어로 드러나야 한다.

이렇게 생각한다

RAG 설계는 “문서를 넣으면 AI가 똑똑해진다”가 아니다. 핵심은 “어떤 질문에 어떤 지식 조각이 회수되어야 하는가?”다.

따라서 RAG를 설계할 때는 먼저 질문 지도를 만든다.

• 학습자는 무엇을 물을 것인가?
• 운영자는 무엇을 확인할 것인가?
• 에이전트는 어떤 지식을 자주 참조할 것인가?
• 출처가 필요한 답변은 무엇인가?
• 문서의 어떤 단위가 검색되어야 의미가 살아나는가?

How

RAG 설계서 템플릿

# RAG Design Spec

## Purpose

## Users

## Question Types

## Source Documents

## Chunking Strategy

## Metadata Schema

## Retrieval Strategy

## Reranking Strategy

## Citation Policy

## Answer Block Format

## Evidence Layers

## Failure Modes

## Evaluation Set

근거. RAG의 원형은 Lewis et al.(2020), “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, NeurIPS, arXiv:2005.11401.

예시 풀이 (Worked Example)

상황

지난 6개월 동안 매달 교육을 열면서 후기와 문의가 쌓였다. “환불 언제까지 되나요”, “대기자는 언제 알려주나요” 같은 질문이 매달 반복되는데, 그때그때 기억으로 답하다 보니 답이 조금씩 다르다. 이번엔 /faq 폴더의 FAQ 답변을 “근거가 따라붙는” 형태로 다시 만들기로 했다. 각 답에 어느 후기·어느 안내문에서 나온 말인지 출처를 붙여, 다음 담당자가 그대로 재사용할 수 있게 하는 게 목표다.

① AI에게 이렇게 요청한다 (그대로 따라 써도 된다)

지난 6개월 교육 후기·문의 로그를 근거로 우리 교육 FAQ를 다시 만들려고 해.
`교육운영` 프로젝트의 RAG 설계서 형식으로 정리해 줘.

조건:
- 표준 섹션을 써: Purpose / Source Documents / Chunking Strategy /
  Metadata Schema / Citation Policy / Answer Block Format /
  Evidence Layers / Failure Modes
- 각 FAQ 답에는 반드시 출처(어느 문서/후기)를 붙여.
- 근거 문서에 없는 내용은 지어내지 말고 `# 미정`으로 남겨.
- 출처를 못 찾은 질문은 "근거 없음 → 답하지 않음"으로 표시해.

질문 예시(자주 들어옴):
- 환불 언제까지 되나요?
- 노쇼하면 대기자는 언제 연락받나요?
- 정원이 몇 명인가요?

② AI가 이렇게 답한다 (초안)

③ 사람이 이렇게 점검하고 고친다

VibeWorks의 핵심은 AI 답을 그대로 쓰지 않고, 사람이 판단 한 칸을 더 얹는 것이다. 근거가 따라붙는지부터 본다.

핵심 규칙 한 줄: 근거를 못 붙이면 답하지 않는다. 그럴듯함보다 추적 가능함이 먼저다.

④ 최종 산출물 — RAG 설계서 (Answer Block + Evidence Layers)

자주 하는 실수

• 출처 없이 답부터 쓴다. 그럴듯한 한 줄이 근거 없는 사내 기준으로 굳는다. 근거가 먼저, 답은 그 다음이다.
• # 미정인 항목을 AI가 채우게 둔다. 환불 규정처럼 안 정해진 걸 채워 넣으면 환각이 공식 답으로 둔갑한다.
• 문서 날짜를 안 적는다. 옛 안내문을 최신처럼 인용해, 바뀐 정책이 계속 살아남는다.

Guided Practice

자기 팀의 문서 묶음을 검색해서 답하는 작은 지식 시스템으로 만든다고 가정하고 설계서를 작성하라. 문서 묶음은 강의자료, 업무 매뉴얼, 고객 문의 기록, 회의록, 연구 노트 중 하나를 고르면 된다.

필수 포함:

• 문서 종류
• 질문 유형
• chunking 기준
• metadata 필드
• 검색 실패 시 대응
• citation 정책

평가 루브릭

이번 주에 적용할 한 가지

자신이 가진 문서 폴더 하나를 골라 “질문 유형 10개”를 먼저 작성한다. 문서를 어떻게 쪼갤지는 그 다음에 결정한다.

My Work Application

자기 업무에 옮길 때는 아래 세 문장을 실제 파일명과 상황명으로 채운다.

• AI가 참고해야 할 문서 묶음을 정한다.
• 문서를 어떤 단위로 나눌지 적는다.
• 답변에 출처를 어떻게 표시할지 정한다.

5단계. 온톨로지와 지식그래프

한 문장 메시지: 지식은 저장만으로 충분하지 않고, 무엇을 무엇으로 부르며 어떻게 연결되는지 합의해야 재사용된다.

이 장에서 만들 것

이 장을 끝내면 독자는 개념-관계 모델을 남긴다. 이 산출물은 다음 장에서 AI가 읽거나, 사람이 다시 판단하거나, 팀 표준으로 옮길 수 있어야 한다.

AI 관련 주제와 키워드

현실 업무 상황

팀 안에서 같은 단어를 서로 다르게 쓰고 있다. 문서는 많지만 용어와 관계가 합의되지 않아 검색과 재사용이 계속 흔들린다.

학습 장면

낱말 목록이 개념, 관계, 규칙을 가진 지식 구조로 정리되는 장면이다. 독자는 어려운 용어를 외우기 전에 연결 기준을 먼저 본다.

전문가의 사고 과정

전문가는 지식을 문장 더미로 보지 않고 개념과 관계의 네트워크로 본다. 먼저 무엇이 개념이고 무엇이 문서이며 무엇이 도구인지 나눈다.

학습 목표

이 단계의 목표는 문서를 단순 저장하지 않고, 개념과 관계로 연결해 재사용 가능한 지식체계로 만드는 방법을 배우는 것이다.

핵심 개념

이렇게 생각한다

온톨로지는 어려운 철학 용어가 아니라, “우리가 무엇을 무엇으로 부르고, 그것들이 어떻게 연결되는가?”를 합의하는 일이다.

AI 교육 프로젝트에서는 다음 질문이 중요하다.

• Agent와 Subagent는 어떻게 다른가?
• Skill은 prompt인가, procedure인가, package인가?
• RAG는 검색 기술인가, 지식 운영 방식인가?
• AGENTS.md는 문서인가, 정책인가, 실행 지시인가?
• VibeWorks는 방법론인가, 커리큘럼인가, 운영체계인가?

How

개념-관계 모델 템플릿

# Ontology Draft

## Core Entities

| Entity | Definition | Examples |
|---|---|---|

## Relations

| Relation | From | To | Meaning |
|---|---|---|---|

## Rules

## Ambiguous Terms

## Naming Conventions

예시

근거. 온톨로지의 고전적 정의는 Gruber(1993), Knowledge Acquisition 5(2), 199–220.

예시 풀이 (Worked Example)

상황

지난달부터 교육 안내문 초안을 AI에게 맡기는데, 자꾸 헷갈린다. “이번 신청자 명단 정리해 줘”라고 하면 6월 교육에 신청한 사람과 5월 노쇼로 밀려난 대기자를 한 표에 섞어 놓는다. “다음 회차 정원”을 물으면 교육 전체 정원(20명)인지 이번 회차 빈자리인지 답이 매번 달라진다. 같은 단어를 나도 그때그때 다르게 쓰고 있었던 게 원인이다. 그래서 교육운영에서 쓰는 핵심 용어(교육·회차·신청자·대기자·정원·리마인드)의 관계를 한 번 정해 개념-관계 모델(온톨로지)로 고정하기로 한다.

① AI에게 이렇게 요청한다 (그대로 따라 써도 된다)

나는 사내 교육 운영을 맡고 있어. AI가 '신청자'와 '대기자', '교육'과
'회차'를 자꾸 섞어서, 우리 용어 관계를 개념-관계 모델(온톨로지)로
고정하려고 해. 아래 형식으로 정리해 줘.

형식:
- Core Entities: | Entity | 정의 | 예시 |
- Relations: | Relation | From | To | 의미 |  (관계는 동사로)
- Rules / Ambiguous Terms(동의어·헷갈리는 말) / Naming Conventions

대상 용어: 교육, 회차, 신청자, 대기자, 정원, 리마인드

규칙(이미 정해진 것):
- 정원 20명, 신청 마감 3일 전 자동 리마인드, 노쇼 시 대기자 자동 승계

조건:
- 관계 방향(누가→누구)을 분명히 적어.
- 내가 안 준 정보는 지어내지 말고 `# 미정`으로 남겨.

② AI가 이렇게 답한다 (초안)

③ 사람이 이렇게 점검하고 고친다

VibeWorks의 핵심은 AI 답을 그대로 쓰지 않고, 사람이 판단 한 칸을 더 얹는 것이다. 초안에서 네 군데가 걸린다.

④ 최종 산출물 — 개념-관계 모델

이제 “6월 회차 신청자 명단 정리해 줘”라고 하면 AI가 회차 단위로 신청자와 대기자를 분리해 가져온다. 같은 단어를 두 가지로 쓰던 혼선이 사라진다.

자주 하는 실수

• 상위 개념과 실제 단위를 안 나눈다. 교육과 회차를 한 덩어리로 두면 “정원·신청”이 어디에 걸리는지 매번 흔들린다.
• 속성을 Entity로 올린다. 정원처럼 회차가 가진 숫자를 독립 개념으로 만들면 관계도가 쓸데없이 복잡해진다.
• 동의어를 정리하지 않는다. 대기자와 예비신청자를 한쪽으로 통일하지 않으면, 고친 온톨로지에서도 AI가 또 두 명으로 센다.

Guided Practice

AI 에이전트 교육용 온톨로지 초안을 작성하라.

필수 entity:

• Agent
• Subagent
• Skill
• Tool
• Memory
• RAG System
• Source Document
• Ontology
• Eval
• Guardrail

평가 루브릭

이번 주에 적용할 한 가지

자신의 프로젝트에서 자주 쓰는 핵심 용어 10개를 뽑고, 각각을 “개념”, “문서”, “도구”, “역할”, “산출물” 중 하나로 분류한다.

My Work Application

자기 업무에 옮길 때는 아래 세 문장을 실제 파일명과 상황명으로 채운다.

• 프로젝트 핵심 용어 10개를 뽑는다.
• 각 용어를 개념, 문서, 도구, 역할, 산출물로 분류한다.
• 가장 중요한 관계 5개를 동사로 쓴다.

6단계. MCP와 도구 연결

한 문장 메시지: AI가 실제 시스템을 다루려면 어떤 도구를 어떤 권한으로 호출할지 명시해야 한다.

이 장에서 만들 것

이 장을 끝내면 독자는 MCP/tool map을 남긴다. 이 산출물은 다음 장에서 AI가 읽거나, 사람이 다시 판단하거나, 팀 표준으로 옮길 수 있어야 한다.

AI 관련 주제와 키워드

현실 업무 상황

AI가 파일, 브라우저, 데이터베이스, SaaS 도구를 다루게 하고 싶다. 하지만 읽기, 쓰기, 실행 권한이 섞이면 편리함보다 위험이 먼저 커진다.

학습 장면

AI가 외부 도구를 호출하기 전에 권한, 입력, 출력, 기록을 확인하는 장면이다. 독자는 MCP와 API를 기능명이 아니라 안전한 연결 절차로 이해한다.

전문가의 사고 과정

전문가는 도구 연결을 기능 목록이 아니라 권한 설계로 본다. 어떤 도구가 무엇을 읽고 쓰며, 언제 사람 승인이 필요한지가 먼저 보여야 한다.

학습 목표

이 단계의 목표는 AI가 외부 시스템과 안전하게 연결되어 실제 작업을 수행하는 구조를 이해하는 것이다.

핵심 개념

컴퓨터를 몰라도 보는 MCP/API 그림

API는 “한 시스템이 다른 시스템에 요청하는 창구”다. MCP는 AI가 여러 창구를 제각각 외우지 않도록, 도구와 자료와 권한을 한곳에서 정리해 주는 연결 방식이다.

사람의 판단
  "이 고객 기록을 확인하고, 필요한 후속 메일 초안을 만들어줘"
        |
        v
AI 앱(Host)
        |
        v
MCP Client: 요청을 정리해 전달
        |
        v
MCP Server: 도구와 자료의 접수대
        |
        +-- Resource: 읽을 문서와 데이터
        +-- Tool: 실행할 기능
        +-- Permission: 열 수 있는 문과 닫힌 문
        |
        v
외부 시스템: API, 파일, 데이터베이스, SaaS 도구

이 그림에서 중요한 것은 “AI가 무엇이든 하게 만들기”가 아니다. 사람이 판단한 목적 안에서, AI가 어떤 자료를 읽고 어떤 기능을 실행할 수 있는지 안전하게 정하는 것이다.

MCP 공식 사양은 MCP를 LLM 애플리케이션과 외부 데이터 소스 및 도구 사이의 통합을 가능하게 하는 open protocol로 설명한다. 출처: https://modelcontextprotocol.io/specification/2025-11-25

이렇게 생각한다

도구 연결의 핵심은 “AI가 무엇이든 하게 만들기”가 아니라 “AI가 필요한 것만 안전하게 하게 만들기”다.

VibeWorks에서는 도구를 연결하기 전에 다음을 묻는다.

• 이 도구 호출은 읽기인가, 쓰기인가?
• 실패하면 어떤 피해가 생기는가?
• 사용자 승인이 필요한가?
• 로그가 남는가?
• 같은 목적을 더 안전한 방식으로 달성할 수 있는가?

How

Tool map 템플릿

# Tool Map

## Tool Name

## Purpose

## Read / Write / Execute

## Required Inputs

## Output

## Permission Level

## Approval Required?

## Failure Modes

## Audit Log

근거. MCP는 Anthropic이 2024-11-25 공개했고, 표준 트랜스포트·프리미티브는 정식 사양(modelcontextprotocol.io/specification)을 따른다.

예시 풀이 (Worked Example)

상황

교육운영 프로젝트가 자라서, 이제 AI가 직접 사내 시스템을 다루게 하려 한다. AI가 사내 캘린더에서 교육 일정을 읽고, 신청 시트에서 신청 현황을 확인하고, 마감 3일 전 사내 메신저로 리마인드를 보내게 하고 싶다. 문제는 이 셋을 “그냥 연결”하면 AI가 멋대로 일정을 바꾸거나 신청자 전체에게 메시지를 발송할 수도 있다는 것이다. 그래서 어떤 도구를 어떤 권한으로, 언제 사람 확인을 거쳐 호출할지 정한 MCP/tool map을 먼저 만든다. 핵심 원칙은 하나다. 읽기는 자동, 쓰기·발송은 사람 확인 후.

① AI에게 이렇게 요청한다 (그대로 따라 써도 된다)

`교육운영`에서 AI가 다룰 도구 3개를 연결 지도(MCP/tool map)로 정리해 줘.
도구: 사내 캘린더, 신청 시트, 사내 메신저.

조건:
- 각 도구를 종류로 나눠: 읽기 전용 데이터는 Resource, 실행 기능은 Tool.
- 도구마다 read / write / execute 권한과 "사람 승인 필요 여부"를 표시해.
- 핵심 경계: 읽기는 자동 허용, 쓰기·발송은 반드시 사람 확인 후.
- 신청 시트에는 신청자 이름·연락처가 있으니, 어디까지 노출할지 적어.
- 본문 Tool Map 템플릿 필드를 써(Purpose / 권한 / Inputs /
  Output / Approval / Failure Modes / Audit Log).
- 내가 안 준 정보는 지어내지 말고 `# 미정`으로 남겨.

② AI가 이렇게 답한다 (초안)

③ 사람이 이렇게 점검하고 고친다

VibeWorks의 핵심은 AI 답을 그대로 쓰지 않고, 사람이 판단 한 칸을 더 얹는 것이다. 이 초안은 편의를 위해 권한을 너무 열어 뒀다.

핵심 경계 한 줄: 읽기(Resource)는 자동, 쓰기·발송(Tool)은 사람 확인 후.

④ 최종 산출물 — MCP/Tool Map

자주 하는 실수

• 편하다고 write·execute까지 자동 허용한다. 읽기는 되돌릴 수 있지만 발송·수정은 못 되돌린다. 쓰기 쪽엔 무조건 사람 확인을 건다.
• Resource(읽는 자료)와 Tool(실행 기능)을 한 도구로 뭉뚱그린다. 한 도구가 읽기도 쓰기도 하면 권한 경계가 사라진다. 행동 단위로 쪼개 적는다.
• 신청 시트를 통째로 AI에 넘긴다. 필요한 건 “몇 명 신청했나”인데 이름·연락처까지 노출된다. 출력은 집계값으로 좁히고 개인정보는 마스킹한다.

Guided Practice

자기 프로젝트를 운영하는 데 필요한 도구 목록을 작성하라. “좋아 보이는 도구”가 아니라 실제로 누가, 언제, 어떤 자료를 넣고 꺼내는지를 기준으로 고른다.

예시:

• Google Drive
• GitHub
• YouTube Analytics
• Canva
• Dropbox
• Local Files
• Search
• Browser

각 도구에 대해 읽기/쓰기/실행 권한을 구분하라.

평가 루브릭

이번 주에 적용할 한 가지

현재 사용하는 AI 도구 또는 SaaS 중 하나를 골라 read/write/execute 권한을 구분하고, “사용자 승인 필요 행동”을 따로 표시한다.

My Work Application

자기 업무에 옮길 때는 아래 세 문장을 실제 파일명과 상황명으로 채운다.

• AI에게 연결하고 싶은 도구 3개를 적는다.
• 각 도구의 읽기, 쓰기, 실행 권한을 나눈다.
• 사람 승인이 필요한 조건을 정한다.

7단계. 평가와 운영

한 문장 메시지: AI 시스템은 자연스러운 답변이 아니라 품질, 안전성, 재현성, 비용 기준으로 운영되어야 한다.

이 장에서 만들 것

이 장을 끝내면 독자는 Eval rubric, AgentOps checklist를 남긴다. 이 산출물은 다음 장에서 AI가 읽거나, 사람이 다시 판단하거나, 팀 표준으로 옮길 수 있어야 한다.

AI 관련 주제와 키워드

현실 업무 상황

AI 결과가 좋아 보이지만, 같은 입력에서 다시 좋아질지 알 수 없다. 사람 검토, 회귀 테스트, 비용 기준이 없으면 운영 가능한 시스템이라고 말하기 어렵다.

학습 장면

한 번 잘된 실행을 운영 기준으로 바꾸는 장면이다. 독자는 품질 루브릭, 회귀 테스트, 관찰 기록이 실제 운영을 지탱한다는 점을 본다.

전문가의 사고 과정

전문가는 답변의 인상보다 실패 조건을 먼저 본다. 좋은 운영 기준은 통과 사례만 모으지 않고 깨지는 사례와 다시 확인하는 방법을 함께 둔다.

학습 목표

이 단계의 목표는 AI 시스템을 “잘 되는 것 같다”가 아니라, 실제 기준과 데이터로 검증하고 운영하는 방법을 배우는 것이다.

핵심 개념

이렇게 생각한다

평가는 마지막에 붙이는 채점표가 아니다. 좋은 AI 시스템은 처음부터 평가 가능한 형태로 설계된다.

따라서 다음 질문을 먼저 둔다.

• 좋은 답변이란 무엇인가?
• 위험한 답변이란 무엇인가?
• 실패를 어떻게 발견할 것인가?
• 같은 입력에 대해 재현 가능한가?
• 비용과 속도는 어느 수준이어야 하는가?

How

Eval rubric 템플릿

# Eval Rubric

## Task

## Input

## Expected Output

## Criteria

| Criterion | 1 Poor | 3 Acceptable | 5 Excellent |
|---|---|---|---|

## Failure Cases

## Human Review Required?

## Regression Test Set

Quality gate를 Must/Evidence로 쓰기

Quality gate는 “좋아 보인다”를 “통과했다”로 바꾸는 문장이다. 좋은 gate는 반드시 확인할 항목과 그 근거를 함께 둔다.

운영 체크리스트

# AgentOps Checklist

- [ ] Prompt version is recorded.
- [ ] Tool calls are logged.
- [ ] External sources are cited.
- [ ] Sensitive actions require approval.
- [ ] Failure modes are documented.
- [ ] Cost and latency are monitored.
- [ ] Regression tests exist.

근거. 산출물 자동 평가는 LLM-as-a-Judge(Zheng et al. 2023, arXiv:2306.05685), 에이전트 종합 평가는 AgentBench(Liu et al. 2023, arXiv:2308.03688).

예시 풀이 (Worked Example)

상황

이번 달 교육 안내문 초안을 AI에게 시켜서 받았다. 읽어 보면 멀쩡해 보이는데, 이걸 그대로 신청자 전원에게 발송해도 되는지 판단이 안 선다. 매달 사람마다 “괜찮네/아닌데” 기준이 달라서, 발송 가/부를 누구나 같은 기준으로 판정하는 평가 루브릭(Eval rubric)과, 매월 운영(비용·실패·로그)을 점검하는 AgentOps 체크리스트를 만들기로 했다. 이번에 만들어 두면 다음 달부터 “이 표 통과하면 발송”으로 끝난다.

① AI에게 이렇게 요청한다 (그대로 따라 써도 된다)

교육 안내문 초안을 "발송해도 되는지" 판정하는 평가 루브릭(Eval rubric)과,
매월 운영을 점검하는 AgentOps 체크리스트를 만들어 줘. `교육운영` 프로젝트야.

조건:
- Eval rubric은 표준 형식을 써: Task / Input / Expected Output /
  Criteria 표 / Failure Cases / Human Review Required? / Regression Test Set
- 판정 기준은 "잘 썼나"처럼 느낌으로 쓰지 말고, 무엇으로 확인하는지(Evidence)와
  통과 기준을 한 칸씩 같이 써.
- 실패로 봐야 하는 경우(멈추고 사람을 부르는 조건)도 적어.
- 안 준 정보는 지어내지 말고 `# 미정`으로 남겨 줘.

배경 규칙: 정원 20명, 마감 3일 전 리마인드, 노쇼 시 대기자 승계,
안내문은 존댓말, 신청자 개인정보는 본문에 넣지 않음, 환불 규정은 아직 미정.

② AI가 이렇게 답한다 (초안)

③ 사람이 이렇게 점검하고 고친다

VibeWorks의 핵심은 AI 답을 그대로 쓰지 않고, 사람이 판단 한 칸을 더 얹는 것이다. 평가표 자체가 “느낌”으로 채워져 있어 그대로는 못 쓴다.

④ 최종 산출물

이제 발송 판단이 사람 감(感)이 아니라 표 통과 여부로 바뀐다. 매달 “이 루브릭 통과했나?”만 보면 되고, 못 잡은 실패는 Failure Cases와 회귀 테스트에 한 줄씩 쌓여 다음 달엔 자동으로 걸린다.

자주 하는 실수

• 기준을 “잘 썼나”처럼 느낌으로 쓴다. 측정이 안 되니 사람마다 판정이 갈리고, 결국 루브릭이 안 쓰인다. Evidence와 통과 기준을 숫자·위치로 묶어야 한다.
• 통과 사례만 모으고 실패·중단 규칙을 안 만든다. 깨지는 경우(개인정보 노출, 미정 규칙 단정)와 “멈추고 사람 호출” 기준이 없으면 운영이 아니라 채점이다.
• 체크리스트를 만들고 매월 안 돌린다. 비용·로그·회귀 테스트는 한 번 점검표로 끝나는 게 아니라 달마다 같은 표로 다시 봐야 의미가 있다.

Guided Practice

“AI 기술 개념을 초보자에게 설명하는 에이전트”를 평가하기 위한 rubric을 작성하라.

필수 기준:

• 정확성
• 쉬운 설명
• 구조화
• 예시 품질
• 출처 사용
• 과장 방지

추가로 trigger test 5개와 should-not-trigger test 3개를 만든다. 이 테스트는 에이전트가 언제 호출되어야 하고 언제 호출되면 안 되는지 확인하는 작은 회귀 테스트다.

평가 루브릭

이번 주에 적용할 한 가지

AI가 생성한 답변 3개를 골라 같은 루브릭으로 평가한다. 점수보다 중요한 것은 “무엇이 좋은 답변인가”를 언어화하는 것이다.

My Work Application

자기 업무에 옮길 때는 아래 세 문장을 실제 파일명과 상황명으로 채운다.

• 자주 맡기는 AI 작업 1개를 고른다.
• 좋은 결과의 기준 3개와 실패 기준 3개를 쓴다.
• 다음 실행 때 다시 확인할 테스트 입력을 남긴다.

8단계. VibeWorks 캡스톤

한 문장 메시지: 하나의 실제 문제를 교재, 지식체계, 에이전트, RAG, 평가가 연결된 작업 시스템으로 완성한다.

이 장에서 만들 것

이 장을 끝내면 독자는 VibeWorks project pack을 남긴다. 이 산출물은 다음 장에서 AI가 읽거나, 사람이 다시 판단하거나, 팀 표준으로 옮길 수 있어야 한다.

AI 관련 주제와 키워드

현실 업무 상황

지금까지 배운 요소가 각각 따로 존재한다. 실제 업무에서는 이 요소들이 하나의 프로젝트 폴더와 실행 루프로 묶여야 의미가 생긴다.

학습 장면

문제 감지부터 발행까지 하나의 AI 작업 시스템으로 이어지는 장면이다. 독자는 마지막 과제가 지식, 에이전트, 도구, 평가를 묶는 일임을 확인한다.

전문가의 사고 과정

전문가는 마지막에 새 기술을 더하지 않고 연결 상태를 점검한다. 문서, 에이전트, 지식, 도구, 평가가 같은 문제를 향해 놓였는지가 캡스톤의 핵심이다.

학습 목표

이 단계의 목표는 하나의 실제 문제를 VibeWorks 방식으로 감지하고, 교재, 지식체계, 에이전트, RAG, 평가, 운영 구조를 포함한 하나의 AI 작업 시스템으로 만드는 것이다.

캡스톤 과제

다음 주제 중 하나를 선택하라.

1. AI 에이전트 입문 교재 만들기
2. 우리 팀 또는 내 업무 지식베이스 만들기
3. 강의자료 RAG 시스템 설계하기
4. 서브에이전트 기반 콘텐츠 제작 워크플로 만들기
5. AI 컨설팅 프로젝트용 AGENTS.md/CLAUDE.md/SKILL.md 템플릿 만들기

VibeWorks Project Pack

최종 제출물은 다음을 포함해야 한다.

project-pack/
├── README.md
├── AGENTS.md
├── CLAUDE.md
├── .claude/
│   ├── agents/
│   │   ├── researcher.md
│   │   ├── planner.md
│   │   ├── reviewer.md
│   │   └── publisher.md
│   └── skills/
│       └── project-skill/
│           └── SKILL.md
├── docs/
│   ├── system-blueprint.md
│   ├── textbook-outline.md
│   └── operating-playbook.md
├── rag/
│   ├── source-map.md
│   ├── metadata-schema.md
│   └── eval-questions.md
├── transfer/
│   ├── team-transfer-card.md
│   └── skill-packaging-backlog.md
└── evals/
    ├── rubric.md
    └── regression-set.md

팀 전이 카드

팀 전이 카드는 “내가 만든 AI 작업 구조를 다음 사람이 어떻게 다시 쓰는가”를 적는 짧은 문서다. 캡스톤은 개인 과제가 아니라 팀의 반복 가능한 업무 자산으로 끝나야 한다.

예시 풀이 (Worked Example)

상황

지난 7개월 동안 교육운영 프로젝트를 혼자 키워 왔다. 0단계 작업 지도부터 시작해 AGENTS.md, Agent 작업 카드, 서브에이전트 설계표, FAQ용 RAG 설계서, 개념-관계 모델, MCP 연결 지도, Eval 루브릭과 운영 점검표까지 산출물이 8개가 쌓였다. 다음 달부터 휴직에 들어가고, 같은 팀 동료가 교육 운영을 이어받는다. 폴더 곳곳에 흩어진 이 산출물을 하나의 project pack으로 묶고, 동료가 “다음 달 교육 안내문 만들어 줘” 한 줄로 바로 시작할 수 있게 인계 메모를 붙이려 한다.

① AI에게 이렇게 요청한다 (그대로 따라 써도 된다)

나는 `교육운영` 프로젝트를 7개월 운영했고, 다음 달부터 동료가 이어받아.
0~7단계에서 만든 산출물 8개(작업 지도, AGENTS.md, Agent 카드, 서브에이전트
설계표, RAG 설계서, 개념-관계 모델, MCP 지도, Eval/운영 체크)를 하나의
project pack으로 묶어 줘.

조건:
- 표준 폴더 트리로 정리해: README / AGENTS.md / .claude(agents·skills) /
  docs / rag / evals / transfer
- transfer/ 안에 "팀 전이 카드"를 만들어: 반복 업무 / 다음 사용자 /
  첫 사용 장면 / 사람 판단 / LLM 도움 / 근거 레이어 / 파일 위치 / 검토일
- README는 다음 사람이 "어디부터 열고 무엇부터 하는지" 순서로 써.
- 내가 주지 않은 정보는 지어내지 말고 `# 미정`으로 남겨.

② AI가 이렇게 답한다 (초안)

③ 사람이 이렇게 점검하고 고친다

VibeWorks의 핵심은 AI 답을 그대로 쓰지 않고, 사람이 판단 한 칸을 더 얹는 것이다. 파일만 모았다고 인계가 끝난 게 아니다. “다음 사람이 어떻게 이어받는가”가 빠지면 꾸러미는 그냥 폴더일 뿐이다.

④ 최종 산출물

폴더 트리

교육운영/
├── README.md                  ← 이어받는 사람이 가장 먼저 여는 파일
├── AGENTS.md                  (1단계) 프로젝트 규칙·보안·수정 금지
├── CLAUDE.md                  협업 취향(표 선호 등)
├── .claude/
│   ├── agents/                (3단계) 안내문·FAQ·일정표 서브에이전트
│   └── skills/notice-draft/SKILL.md   (2단계) 안내문 초안 작업 카드
├── docs/
│   ├── work-map.md            (0단계) 표면 요청 → 실제 목적 분해
│   └── concept-model.md       (5단계) 교육·회차·신청자·대기자·정원 관계
├── rag/
│   ├── source-map.md          (4단계) 후기·문의 로그 6개월치 근거 소스
│   └── eval-questions.md      FAQ 답 검증용 질문
├── mcp-map.md                 (6단계) 캘린더·시트·메신저 권한·확인 경계
├── evals/
│   └── rubric.md              (7단계) 발송 판정 루브릭 + 운영 점검표
└── transfer/
    └── team-transfer-card.md  인계 메모 (아래)

transfer/team-transfer-card.md (팀 전이 카드 완성본)

# 팀 전이 카드 — 교육운영

| 항목 | 내용 |
|---|---|
| 반복 업무 | 매달 새 교육의 안내문·FAQ·일정표 제작·발송. |
| 다음 사용자 | 교육 운영 인계자(동료 1인). 검토일에 휴직자 복귀 시 재인계. |
| 첫 사용 장면 | 다음 달 교육이 잡히면 README를 열고 "이번 교육 안내문 초안 만들어 줘"로 시작. |
| 사람 판단 | ① 환불 규정(# 미정, 총무팀 확인 후 채움) ② 발송 직전 최종 승인 ③ 대기자 승계 예외. |
| LLM 도움 | 안내문·FAQ·일정표 초안, 후기 로그 기반 FAQ 답 근거 정리. |
| 근거 레이어 | rag/source-map.md(후기·문의 6개월), evals/rubric.md(발송 판정). |
| 파일 위치 | 진입 순서 → ① transfer/ ② AGENTS.md ③ .claude/skills/notice-draft. |
| 검토일 | 분기마다(다음: # 미정). 환불 규정 확정되면 즉시 갱신. |

## 인계 주의 (꼭 읽을 것)
- 개인정보: 신청자 이름·연락처는 안내문·FAQ 본문에 절대 넣지 않는다.
- 발송 권한: 캘린더·시트·메신저 쓰기는 사람 확인 후 실행(자동 발송 금지).
  계정 이관 시 MCP 토큰 재발급 필요 → mcp-map.md 참고.
- 수정 금지: 확정 발송된 sent/ 폴더는 손대지 않는다.

이제 동료는 transfer/를 먼저 열어 한 장으로 전체 그림을 보고, README의 진입 순서를 따라 첫 명령을 내린다. 7개월치 판단이 폴더가 아니라 “이어받는 절차”로 넘어간다.

자주 하는 실수

• 파일만 한 폴더에 모으고 인계를 끝냈다고 생각한다. 다음 사람이 “어디부터 여는지” 진입 순서가 없으면 꾸러미는 열리지 않는다.
• 인계 직전에 # 미정을 그럴듯하게 채운다. 환불 규정처럼 끝까지 미확정인 항목은 미정인 채로 넘기고 ’사람 판단’에 적는다 — 지어내 굳히는 게 가장 위험하다.
• 권한·개인정보 인계를 빠뜨린다. 발송 권한과 개인정보 취급은 계정이 바뀌면 다시 점검해야 하는데, “그대로 쓰면 된다”로 넘기면 사고로 이어진다.

최종 평가 루브릭

최종 질문

캡스톤 제출 전 다음 질문에 답하라.

1. 이 프로젝트의 vibe는 무엇이었는가?
2. 그것을 어떤 틀(frame)로 잡았는가?
3. 무엇을 문서화하고 외부화했는가?
4. 어떤 에이전트와 서브에이전트를 설계했는가?
5. 어떤 지식이 RAG 또는 온톨로지로 연결되는가?
6. 어떤 평가 기준으로 품질을 판단할 것인가?
7. 이 작업은 반복 가능한 결과(works)가 되었는가?
8. 다음 사람이 다시 쓰려면 무엇을 남겨야 하는가?
9. 어떤 Skill 후보로 포장할 것인가?

My Work Application

자기 업무에 옮길 때는 아래 세 문장을 실제 파일명과 상황명으로 채운다.

• 실제 업무 문제 1개를 고른다.
• 0-7단계 산출물을 하나의 폴더 구조로 묶는다.
• 다음 사람이 이어서 실행할 수 있는 README를 쓴다.

부록 A. 표준 용어집

부록 B. 수업 운영안

Skill 제작 미니 트랙

교육 설계 Skill과 교육 운영 Skill

강의 자료를 만들 때의 Skill과 수업을 운영할 때의 Skill은 다르다. 설계 Skill은 무엇을 가르칠지 구조화하고, 운영 Skill은 실제 수업 중 질문, 피드백, 시간, 산출물을 관리한다.

4주 압축 과정

8주 정규 과정

부록 C. 강사용 질문

수업 중 강사는 다음 질문을 반복해서 사용할 수 있다.

• 지금 이 요청의 vibe는 무엇인가?
• 표면 요청과 실제 목적은 어떻게 다른가?
• 이것은 문서, 에이전트, 지식체계, 자동화 중 무엇으로 바뀌어야 하는가?
• AI에게 반복해서 설명하지 않으려면 어떤 파일이 필요한가?
• 이 작업을 맡을 서브에이전트가 있다면 어떤 역할이어야 하는가?
• 검색이 필요한 지식과 기억해야 할 지식은 무엇이 다른가?
• 이 시스템이 잘 작동한다는 것을 어떻게 평가할 것인가?
• 어떤 행동은 사람의 승인이 필요한가?

마무리

VibeWorks Thinking and How의 핵심은 AI를 “답을 주는 도구”에서 “사람의 의도와 지식을 작동 가능한 시스템으로 바꾸는 협업 구조”로 보는 것이다. 좋은 AI 활용은 좋은 프롬프트 하나에서 끝나지 않는다. 좋은 맥락 파일, 좋은 서브에이전트, 좋은 지식 구조, 좋은 평가 기준, 좋은 운영 습관이 함께 있을 때 반복 가능한 works가 된다.

발행 정보

발행 묶음: Markdown 원고, 단일 HTML, 전체 구조도와 장별 학습 장면 자산. 독자 검토와 수업 적용 결과는 다음 eBook 판의 개선 항목으로 반영한다.