목차 · 4개 장
- 1부지금 하고 있는 작업에 바로 붙이기
- 2부매 프로젝트마다 순서대로 밟을 것
- 3부절대 하지 말 것
- 덧붙임이 저장소가 이미 하고 있는 것 · 아직 안 하는 것
영상의 교훈 12가지를 지금 하고 있는 작업에 바로 붙일 것 / 매 프로젝트마다 순서대로 밟을 것 / 절대 하지 말 것 셋으로 나눴습니다.
1부지금 하고 있는 작업에 바로 붙이기
1지금 진행 중인 자동화 하나를 골라 "전·후 숫자"를 적어 둔다
- 왜
- 포트폴리오("이걸 만들었다")는 증빙("이게 실제로 얼마를 아꼈다")을 못 이깁니다. 아주 작은 작업이라도 걸린 시간이나 놓친 건수를 전·후로 숫자화해 두면, 나중에 이걸 팔거나 보여줄 때 그 숫자가 곧 설득력이 됩니다. [01:05]
- 지금 예
- 이 저장소의
정리실행.sh도 마찬가지로 잴 수 있습니다 — 영상 하나를 손으로 정리할 때 걸리던 시간 대비, 자동화 이후 걸리는 시간을 한 번 재서 적어 두면 그 자체가 증빙입니다.
2지금 쓰는 지시문(프롬프트·스킬·CLAUDE.md)에 "하지 마라" 한 줄을 더한다
- 왜
- 네거티브 프롬프트는 이미 밟아본 실수를 기록해 두는 것입니다. 처음 만드는 사람은 절대 알 수 없는, 오직 실패해 본 사람만 아는 지식입니다. [03:47]
- 단서
- Anthropic 자신도 이 방식을 권장하지만 가볍게, 필요한 만큼만 쓰라고 덧붙입니다. 너무 세게, 너무 많이 금지하면 오히려 그 행동을 유도할 수 있습니다. 영상에 없음 — 정리.html 5장 참고
2부매 프로젝트마다 순서대로 밟을 것
3만들기 전에 — 병목·누수부터 찾는다
- 순서
- 상대(고객·상사)가 말하는 요청("챗봇 만들어 주세요")을 그대로 받지 않습니다. 먼저 업무 과정을 따라가며 어디서 막히고(병목) 어디서 새는지(누수)를 직접 찾습니다. [11:25]
- 왜 먼저
- 상대가 요청한 것은 상대가 생각하는 해결책일 뿐, 진짜 제약이 아닙니다. 진짜 제약을 겨냥해야 사업이 실제로 자랍니다.
4만들기 전에 — 북극성 지표 하나를 먼저 합의한다
- 방법
- "지금 A가 X인데, 이걸 Y로 올리면 성공이라고 할 수 있나요?"를 만들기 전에 상대에게 묻고 답을 받습니다. [12:32]
- 얻는 것
- 배포 후 그 숫자 하나로 성공·실패를 누구나 판단할 수 있고, 이 숫자가 다시 1번(증빙)의 재료가 됩니다.
5만드는 동안 — AI에게 완료 기준을 먼저 주고, 여러 인격으로 검증받는다
- 순서
- 바로 "만들어 줘"라고 시키지 않고, AI가 먼저 질문하게 해서 요구사항을 확실히 이해했는지 확인합니다. 계획이 나오면 회의적인 고객·경쟁사·유지보수 엔지니어 같은 다른 인격으로 그 계획을 공격하게 시킵니다. [05:25]
- 왜
- 모델은 사용자를 만족시키도록 훈련돼 있어 "계획 어때?"라고 물으면 그냥 좋다고 답하는 경향이 있습니다. 각도를 다르게 공격시켜야 그 사각지대가 드러납니다.
6넘겨받기 전에 — AI 스스로 검증하게 한다
- 물어볼 질문
- "사람이 이 결과물을 검토한다면 어떻게 검토했을까?" 스크린샷을 찍어 보게 하거나, 실제로 클릭해 동작을 확인하게 하거나, 테스트를 짜서 돌리게 시킵니다. [06:31]
- 얻는 것
- 보통 60~70%에서 시작해 여러 번 피드백을 주고받아야 도달하던 90~95%를, 한 번의 요청으로 받게 됩니다.
7실제로 넘기기 전에 — 골든 데이터셋으로 Eval을 돌린다
- 최소
- 사람이 이미 잘했다고 확인한 예시를 20개라도 모아서, 프롬프트·도구·모델을 바꿀 때마다 그 예시들에 다시 돌려 채점합니다. [10:21]
- 왜
- 이 모델들은 비결정적이라, 한 번 잘 작동한 걸 봤다고 100번 중 몇 번 성공할지는 알 수 없습니다. "느낌상 좋아졌다"가 실제로는 점수를 떨어뜨리는 경우도 있습니다.
8비용이 걱정되면 — 모델 라우팅부터 본다
- 기준
- 단순 요약·정리 같은 작업은 값싸고 빠른 모델로, 전략적 판단이 들어가는 마지막 단계만 비싼 모델로 보냅니다. [13:05]
- 효과
- 같은 결과물 품질을 유지하면서 비용이 10배 이상 줄어들 수 있다고 해설자는 말합니다(경험적 수치, 부록 B 참고).
3부절대 하지 말 것
프롬프트로만 막아 놓고 도구 권한은 그대로 두지 않는다
"이메일은 절대 보내지 마라, 초안만 써라"라고 프롬프트에 적어 둬도, 에이전트에게 여전히 이메일 발송 도구 자체가 쥐어져 있다면 언젠가 실제로 보낼 거라고 가정해야 합니다. 프롬프트에 적힌 규칙은 제안일 뿐이고, 진짜 제한은 도구 안에, API 키의 권한 범위 안에 있어야 합니다. [08:09]
지금 굴리고 있는 에이전트마다 "이게 스스로 무엇까지 할 수 있는가? 보낼 수 있는가, 쓰기만 할 수 있는가?"를 스스로 물어보고, 답이 무서우면 프롬프트가 아니라 접근 권한을 고칩니다.
한 번 잘 됐다고 그 성공률을 믿지 않는다
에이전트가 한 번 작동하는 걸 봤다면 증명된 건 "한 번의 결과물에서 한 번 작동했다"는 것뿐입니다. 실제 사용 앞에서 처음 성공률을 확인하지 말고, Eval로 먼저 확인합니다. [08:59]
덧붙임이 저장소가 이미 하고 있는 것 · 아직 안 하는 것
이미 하고 있는 것 — 교훈 7 (권한 스코프)
이 프로젝트의 CLAUDE.md는 이렇게 적어 둡니다 — "정리실행.sh가 자막 받기·변환·배포를 직접 하고, 모델에게는 읽기와 쓰기만 시킨다." 실제로 claude -p를 부를 때 --allowedTools Read Write Edit Glob Grep WebSearch WebFetch만 열어 두고 셸(Bash)은 주지 않습니다. 이게 정확히 이 영상 8장의 원칙입니다 — 프롬프트로 "이러지 마라"라고 적는 대신, 도구 자체를 못 쥐게 만드는 것.
이미 하고 있는 것 — 교훈 4 (네거티브 프롬프트)
사용자의 전역 CLAUDE.md와 이 프로젝트 CLAUDE.md 자체가 네거티브 프롬프트로 가득합니다. "표는 처음 설명하는 것을 밀어 넣지 않는다", "새로 디자인하지 않는다", "손으로 고치지 않는다" 같은 문장들이 전부 이 영상 5장이 말하는 "하지 마라 목록 = 자기 실패의 기록"과 같은 방식입니다.
점검해 볼 만한 것 — 교훈 8·10 (Eval과 북극성 지표)
이 저장소는 정리 하나하나가 잘 됐는지 사람이 매번 눈으로 확인하는 구조입니다. 영상 9장 방식대로라면, 이미 잘 나온 정리 몇 개를 "골든 데이터셋"처럼 기준으로 남겨 두고, 다음 정리들이 그 기준(부록 B 네 항목을 다 채웠는가, 0장이 있는가 등)을 얼마나 만족하는지 점검하는 절차를 넣어볼 수 있습니다. 지금은 이 점검이 정리다듬기.py의 기계적인 부분(목차·상단바)에만 있고, 내용 품질 쪽은 사람 눈에 의존합니다.