학생용 20개 슬라이드와 1:1로 대응합니다. 맛집 챗봇의 할루시네이션을 목격하고, reviewer·MCP·훅·플러그인으로 만드는 AI에 고삐를 채우도록 설계했습니다.
8장은 Part 3의 완결 장입니다. 7장에서 서비스 운영에 채운 다섯 고삐를 개발 과정으로 확장합니다. 학습자는 할루시네이션을 목격하고, 검사 역할을 분리하며, 외부 검색 근거를 연결하고, 개발 AI의 행동을 차단·기록한 뒤 이 장비를 플러그인으로 재사용합니다.
별도 역할과 컨텍스트는 검증을 강화하지만 같은 시스템과 자료를 쓸 수 있습니다. 중요한 결과는 사람이 직접 확인합니다.
외부 근거를 공급해 위험을 줄입니다. 검색 결과의 노후·오류와 AI의 오해 가능성은 남습니다.
변경 전 승인 관문입니다. 망가진 코드를 되돌리는 Git·배포 롤백과는 역할이 다릅니다.
설정된 도구와 경로에서만 작동합니다. 정상 파일 허용과 우회 시도를 함께 시험해야 합니다.
7장의 운영 통제에서 8장의 개발 AI 통제로 관점을 확장한다.
서비스에만 고삐를 채우는 것으로는 부족하다. 이번 장은 검사 역할, 외부 근거, 행동 게이트, 재사용 장비를 만드는 AI 쪽에 배치한다.
‘만드는 AI에게 고삐를 채운다’는 표현이 무엇을 뜻하는지 한 문장으로 예측하게 한다.
도구 네 가지를 새 고삐로 소개하지 않는다. 기존 다섯 고삐를 개발 과정에 구현하는 공식 기능이다.
학습자가 운영 통제와 개발 통제의 차이를 말한다.
출제자=채점자, 형식 검증, 개발 AI 무통제라는 세 한계를 진단한다.
같은 AI의 자기 검증은 편향을 공유할 수 있고, 형식 검사는 사실성을 보장하지 않는다. 가장 큰 파일 권한을 가진 개발 AI에도 물리적 경계가 필요하다.
세 한계 중 실제 프로젝트에서 가장 위험한 하나를 고르고 근거를 말하게 한다.
서브에이전트와 외부 데이터가 오류를 완전히 제거한다고 설명하지 않는다. 최종 확인은 사람의 몫이다.
세 한계를 각각 8.2, 8.3, 8.4의 해결 장치와 연결한다.
20장 수업의 BUILD–SEPARATE–CONTROL 구조를 제시한다.
챗봇을 만들고 할루시네이션을 목격한 뒤 reviewer와 MCP를 붙이고, 훅과 플러그인으로 개발 통제를 재사용한다.
API가 필요한 구간과 없이 가능한 구간을 구분하게 한다.
8.1·8.3은 API 준비가 필요하다. 8.2 일부·8.4·8.5는 대체 실습이 가능하므로 미준비 학습자를 배제하지 않는다.
학습자가 8.1~8.6의 인과 흐름과 API 구간을 설명한다.
Skill.md를 공식 프로젝트 스킬 구조로 전환하는 이유를 이해한다.
description은 자동 호출 판단 기준이고 본문은 필요할 때 읽힌다. 이는 점진적 공개로 컨텍스트를 절약한다.
description에 ‘무엇을’과 ‘언제’를 모두 넣어야 하는 이유를 묻는다.
등록 후 기존 Skill.md를 중복 원천으로 남기지 않는다. .env와 chats는 공개 저장 대상이 아니다.
프로젝트 경로, SKILL.md, frontmatter, description, 기존 파일 삭제를 확인한다.
챗봇을 만들기 전에 기능과 다섯 고삐를 문서화하는 습관을 강화한다.
페르소나·대화 기록·입력 제한·자동 테스트·PM2·대시보드를 한 설계에 묶는다. 완료 선언보다 체크리스트 증거가 우선이다.
‘추천 완료’를 어떻게 측정해야 의미 있는 지표가 되는지 묻는다.
포트가 달라도 기능상 오류는 아니나 수업 일관성을 위해 3200으로 맞춘다. 모델 선택은 비용·속도·정확도 목적에 따라 달라진다.
localhost:3200과 대시보드, 8개 지표, PM2 실행, 체크리스트 증거를 확인한다.
연속 대화의 문맥 유지와 통제 기능을 실제 사용자 흐름으로 확인한다.
3턴 대화, 추가 질문, 추천 구성, 가격 비생성, 음식 외 거절, 새로고침 기록, 375px를 직접 시험한다.
‘맛집 데이터’를 다른 보유 정보로 바꾸면 어떤 챗봇이 되는지 예를 받는다.
친근한 톤과 사실성은 별개다. 대화 저장에는 개인정보 최소화·삭제·gitignore가 필요하다.
7가지 확인과 사이드바의 새 대화·기존 대화 이어가기를 증거로 확인한다.
규칙과 형식 검증으로 잡지 못하는 할루시네이션을 체감한다.
가게를 존재하는 듯 추천한 뒤 주소를 설명하지 못하면 형식은 맞지만 내용 근거가 없는 것이다. 해결은 검사 분리와 실제 데이터 연결이다.
그럴듯함과 사실성을 구분하는 추가 질문을 학습자가 만들게 한다.
실패 장면을 숨기지 않는다. 할루시네이션은 사용자 실수가 아니라 시스템 설계 문제로 다룬다.
추천명·주소·전화·근거를 추궁했을 때 한계 인정 또는 조작 여부를 확인한다.
서브에이전트의 별도 역할·기억·도구 권한을 이해한다.
agents 폴더의 직무기술서는 직원의 역할과 도구를 정한다. 별도 컨텍스트는 만든 과정에 덜 끌려가는 검수 시각을 제공한다.
읽기·실행만 가능하고 수정은 못 하는 검사관의 장점을 묻는다.
서브에이전트는 완전한 외부 감사자가 아니며 여섯 번째 고삐도 아니다. 검증 고삐의 진화다.
역할 분리, 별도 컨텍스트, 수정 도구 제외를 설명한다.
CLAUDE.md·스킬·agents의 역할 차이를 명확히 구분한다.
규정은 어떻게 일하는지, 스킬은 어떤 기준과 지식을 쓰는지, 에이전트는 누가 어떤 권한으로 일하는지를 정한다.
‘독립된 눈’이 필요할 때 스킬이 아니라 에이전트가 필요한 이유를 묻는다.
파일명이나 형식을 암기시키기보다 역할과 질문의 차이를 이해시키는 데 집중한다.
세 문서 유형을 비유·역할·답하는 질문과 1:1로 연결한다.
검사관의 직무·검증 기준·권한 경계를 자연어로 설계한다.
reviewer는 테스트와 답변 품질을 검토하고 심각도와 근거를 보고한다. Read·Grep·Glob·Bash만 주고 Edit·Write는 제외한다.
검사관에게 수정 권한까지 주면 어떤 문제가 생길 수 있는지 토론한다.
화면과 명령은 버전에 따라 달라질 수 있다. /agents 목록과 실제 직무기술서 내용으로 채용을 확인한다.
description, tools, 수정 도구 부재, /agents 표시를 확인한다.
AI가 만든 자동 테스트를 독립 역할이 다시 검토하는 반복 고리를 체험한다.
체크리스트를 실제로 검사하는지, 엣지 케이스가 빠졌는지, 통과시키기 위한 테스트인지 파일 근거와 함께 판정한다.
‘신뢰 가능’ 판정보다 보고서 근거가 중요한 이유를 묻는다.
reviewer는 수정하지 않는다. 만드는 AI가 고치고 reviewer가 재검토해야 역할 분리가 유지된다.
위임 표시, 파일 근거, 심각도, 종합 판정, 수정 후 재검토를 확인한다.
검사 AI가 실제 서비스에 함정 질문을 보내는 적대적 테스트를 이해한다.
비현실 조건·사실 확인 압박·근거 추궁은 할루시네이션을 드러내는 세 층의 질문이다. 질문별 판정과 근거를 기록한다.
세 질문 중 가장 강한 사실성 검사는 무엇인지 고르게 한다.
챗봇 서버와 API가 필요하다. 미준비 학습자는 제공된 보고서를 평가하는 역할로 참여한다.
실제 요청 흔적, 질문별 판정, 근거, 종합 신뢰 판단을 확인한다.
서브에이전트 적용 전후의 구조적 차이와 한계를 정리한다.
깨끗한 컨텍스트와 제한된 권한으로 검증은 강해졌지만 reviewer도 AI이며 실제 장소 데이터는 모른다.
다른 모델을 쓰면 무엇이 개선되고 무엇은 여전히 보장되지 않는지 묻는다.
모델 분리는 편향 감소에 도움을 줄 뿐 독립적 사실 확인을 보장하지 않는다. 사용량 비용도 고려한다.
전후 비교에서 기억·권한·탐지 방식·남은 한계를 설명한다.
MCP의 근거 공급과 Plan 모드의 사람 승인 관문을 결합한다.
MCP는 실제 검색 결과를 제공하고 reviewer는 주장을 검사한다. Plan 모드는 파일 변경 전 계획을 먼저 승인하게 하는 휴먼 인 더 루프다.
검사관과 냉장고 비유에서 각각 누가 무엇을 해결하는지 묻는다.
Plan 모드는 Git 롤백을 대체하지 않는다. 화면 모드 명칭은 버전에 따라 달라질 수 있어 상태 표시를 확인한다.
데이터 소스·MCP 계획·키 미입력 상태·사람 승인 후 실행의 순서를 확인한다.
외부 API 자격정보를 안전하게 연결하고 MCP 등록과 앱 호출을 구분한다.
Claude Code에 MCP를 등록하는 것과 실행 중인 챗봇 서버가 검색을 호출하도록 구현하는 것은 별개다. 둘 다 실제 요청 증거가 필요하다.
①만 완료된 상태에서 챗봇이 자동으로 검색할 것인지 묻는다.
Client ID·Secret을 화면이나 대화에 노출하지 않는다. 로컬 MCP는 Vercel 배포에 자동 승계되지 않으며 외부 API 정책을 확인한다.
두 연결, .env 보관, gitignore, 실제 검색 요청 로그를 확인한다.
동일 조건 재시험으로 외부 근거 연결의 개선 효과를 증명한다.
같은 챗봇·reviewer·함정 질문을 유지하고 재료만 바꿔 판정을 비교한다. AI 보고서에 더해 사람이 지도나 공식 안내로 확인한다.
‘3/3 통과’만으로 충분하지 않은 이유를 묻는다.
‘할루시네이션 0건’을 영구적 무오류로 일반화하지 않는다. 검색 결과도 오래되거나 오해될 수 있다.
비교 보고서, 직접 검색, 챗봇 답변 세 증거를 모두 확인한다.
규칙과 훅의 차이, PreToolUse와 PostToolUse의 역할을 이해한다.
규칙은 AI가 읽고 따르는 부탁이며 훅은 설정된 길목에서 자동 작동한다. 행동 전 차단은 울타리, 행동 후 기록은 CCTV다.
서비스 CCTV와 작업실 CCTV가 각각 무엇을 관측하는지 구분하게 한다.
훅이 모든 도구·경로·외부 프로그램을 자동 보호하지 않는다. 적용 범위와 우회 테스트가 필요하다.
Pre/Post 시점과 고삐 2·5의 매핑, 설정 범위를 설명한다.
.env 보호와 작업 기록 훅을 파괴 테스트로 검증한다.
직접 수정과 우회 명령 모두 차단하되 다른 파일은 정상 수정되어야 한다. 로그에는 시각·행동·파일이 남아야 한다.
‘모든 파일 수정 차단’이 왜 좋은 보안이 아닌지 묻는다.
실제 비밀값을 화면에 노출하지 않는다. .env 변경이 필요하면 사람이 직접 처리한다. 테스트용 파일과 값을 사용한다.
.env 차단, 우회 차단, 정상 파일 허용, 로그 누적과 필드를 확인한다.
서브에이전트와 훅을 플러그인으로 묶어 재사용·공유하는 구조를 이해한다.
harness-kit은 reviewer, 보호 훅, 기록 훅, 스크립트, 신분증, README를 정해진 구조로 포장한다. 새 프로젝트에서 설치 후 기능을 재검증한다.
폴더 복사와 플러그인 설치의 차이를 말하게 한다.
타인 플러그인은 자동 실행 훅을 포함할 수 있다. 출처·구성·스크립트를 확인하기 전 설치하지 않는다.
새 폴더에서 reviewer 존재, .env 차단, 로그 생성 세 가지를 확인한다.
운영 고삐와 개발 고삐의 대응을 종합하고 Lv.5 성장을 회고한다.
규칙·울타리·검증·안전벨트·CCTV가 서비스와 만드는 AI 양쪽에 구현되었다. 자연어로 지시했지만 검증 책임은 사람에게 남는다.
다섯 고삐 중 개발 쪽 적용이 가장 인상적인 하나와 증거를 공유하게 한다.
Lv.5를 완전 무오류나 공식 인증으로 표현하지 않는다. 외부 데이터·훅·서브에이전트에도 한계가 있다.
다섯 고삐를 운영·개발 사례와 정확히 연결하고 사람 확인의 필요성을 말한다.