영상 정리 · AI·개발
7자리 수익(억 단위) AI 에이전시를 키운 해설자가, 도구가 아니라 사람이 쌓아야 하는 것이 무엇인지를 12가지로 짚은 영상
영상의 영어 원어 자막 전체가 근거입니다. 30초 묶음 29개, 21,829자, 끝 시각 15분 16초(영상 길이 15분 23초). 이 영상은 원어가 영어라 원어 자막(en-orig)을 그대로 썼습니다 — 폴더 이름의 "[한글자막]"은 업로더가 영상 화면 안에 직접 박아 넣은 자막을 뜻하며, 유튜브 자막 트랙과는 다른 것입니다. 이 영상에는 en-orig 말고 다른 트랙이 받아지지 않아 비교할 대상이 없었습니다.
영상 안에서 해설자가 "앤스로픽 자신의 프롬프트 문서를 보라"고 말하는 대목(교훈 4)이 있어, 그 문서를 직접 찾아 대조했습니다 — 5장 참고. 그 외에는 해설자 자신의 경험담이라 대조할 별도 원문이 없습니다.
해설자 본인의 이름은 자막으로 확정할 수 없습니다 — 부록 B 참고.
이 영상은 낱말 몇 개를 안다고 전제하고 말합니다. 하나씩 풀고 갑니다.
영상은 해설자의 이력을 짧게 던지며 시작합니다.
"저는 AI를 만드는 데 5,000시간 넘게 썼고, 그걸로 7자리 수익 에이전시를 만들었고, 40만 명 넘게 가르쳤고, 제 사업 전체를 자동화했습니다. 그래서 이 영상에서는 그 5,000시간에서 얻은 가장 큰 교훈들을 드리려고 합니다. 여러분이 저와 똑같은 실수를 하느라 몇 년을 낭비하지 않도록요."
해설자 [00:00]
즉 이 영상은 "AI로 무엇을 만들었나"가 아니라 "만들면서 부딪힌 다음, 다르게 하기로 한 것"을 모은 목록입니다. 그래서 도구 이름이나 사용법은 거의 안 나오고, 대부분이 태도와 판단 기준 이야기입니다.
지금 AI로 뭔가를 하려는 사람에게는 크게 두 갈래 길이 있다고 영상은 말합니다. 직접 에이전시를 차려 고객을 찾는 길, 아니면 지금 다니는 회사 안에서 "AI 담당자"가 되는 길입니다. 해설자 본인은 골드만삭스에 다니면서 사내 AI 담당자가 되고 싶었지만, 회사 안에서는 너무 오래 걸릴 것 같아 퇴사하고 직접 에이전시를 차렸다고 말합니다. [00:16]~[00:32]
두 길 모두에 똑같이 걸리는 문제가 하나 있습니다. 이제는 튀어 보이기가 훨씬 어려워졌다는 것입니다. AI로 뭔가 만드는 일이 너무 쉬워져서, 다들 포트폴리오를 하나씩 갖고 있고 다들 같은 튜토리얼을 보고 같은 데모를 만듭니다. 그래서 고객 입장에서는 진짜 실력자와 지난 주말에 유튜브 보고 급하게 만든 사람을 구분할 수 없습니다. [00:32]
"그래서 튀어 보이는 방법은, 만든 것을 모으는 대신 증빙을 모으는 것입니다. 포트폴리오는 '이걸 만들었다'고 말하지만, 증빙은 '이게 실제로 사업에 어떤 효과를 냈는지'를 말합니다."
해설자 [01:05]
구체적인 방법은 이렇습니다. 무언가를 만들 때마다 결과를 숫자로 기록해 둡니다. "이 작업이 원래 몇 시간 걸렸는데 이제 몇 시간으로 줄었다", "원래 놓치던 잠재 고객이 이만큼이었는데 지금은 하나도 안 놓친다" 같은 식입니다. 아주 작은 프로젝트라도, 심지어 자기 자신을 위해 만든 것이라도 숫자를 적어두고 짧은 화면 녹화를 남겨 둡니다. 워크플로 스크린샷 다섯 장을 든 사람은 다른 사람과 똑같아 보이지만, 진짜 성과 세 개를 든 사람은 눈에 띄기 때문입니다. [01:05]~[01:37]
고객이나 회사가 값을 매기는 것은 "만들 줄 아는가"가 아니라 "그래서 얼마를 벌게(또는 아끼게) 해줬는가"입니다. 증빙은 이 질문에 숫자로 답하는 유일한 방법이고, 그래서 같은 실력이라도 증빙이 있는 쪽이 더 비싸게 팔립니다.
해설자는 자기 유튜브 채널을 거의 도구 한두 개로 키웠다고 말합니다. 오랫동안 주력 도구는 "n8n"이었고 지금은 "Claude Code"입니다. 하지만 요지는 도구 이름이 아니라, 더 좋은 도구는 계속 나올 것이고 그건 절대 멈추지 않는다는 것입니다. [01:39]
"도구가 값어치 있었던 적은 한 번도 없습니다. 값어치 있는 건 여러분이 거기서 배운 것, 그리고 여러분이 생각하는 방식입니다. n8n이 저에게 가르쳐 준 걸 생각해 보세요. API 호출이 뭔지, 어디서 잘 깨지는지, 에러를 어떻게 읽고 실제로 고치는지. 그 어떤 것도 도구를 바꿨다고 사라지지 않았습니다. 저는 그걸 그대로 Claude Code로 들고 넘어왔을 뿐입니다."
해설자 [01:39]~[02:09]
지금 만들고 있는 "AI 운영체제"(폴더와 마크다운 파일과 지시문으로 이루어진 개인 자동화 시스템) 같은 것도 마찬가지입니다. Claude Code에서 돌리든 다음 달에 나올 다른 도구에서 돌리든 그대로 옮겨갈 수 있어야 합니다. 그래서 해설자의 조언은 완벽한 도구가 나오기를 기다리지 말고, 지금 좋아하는 도구가 다른 것으로 대체돼도 스트레스받지 말라는 것입니다. 대신 명확하게 소통하는 법, 문제를 쪼개는 법, 첫 시도가 실패했을 때 더 나은 해법을 찾는 법 같은 밑바탕 기술에 집착하라고 말합니다. [02:09]~[02:41]
"AI 네이티브"하다는 것은 얼마나 많은 모델 이름을 아는지, 얼마나 많은 도구를 써봤는지가 아니라고 영상은 말합니다. 진짜 기준은 무언가 일이 생겼을 때 머릿속에서 무엇을 먼저 떠올리는가입니다. "AI가 이걸 할 수 있을까, 한번 해볼까"가 기본값인지, 아니면 늘 하던 대로 손으로 처리하는지의 차이입니다. [02:41]
"'AI가 이걸 할 수 있나'라는 질문은 예/아니오로 답할 수 있는 게 아닙니다. 진짜 질문은 '어디까지 할 수 있는가'입니다. 70%까지 가져다주고 나머지를 여러분이 처리하면, 그것도 큰 승리입니다. 앞부분 25%만 해치워도, 여전히 100% 수작업으로 하는 사람보다는 훨씬 앞서 있는 겁니다."
해설자 [02:41]~[03:15]
그리고 이 답은 절대 고정되지 않습니다. 지금 나와 있는 모델과 도구들이 말 그대로 앞으로 나올 것 중 가장 성능이 낮은 버전이기 때문입니다. 그래서 "AI 네이티브"는 지식의 양이 아니라 뇌가 반사적으로 무엇을 떠올리는지의 문제라고 영상은 정리합니다. [03:15]
대부분 사람들은 AI 자체가 값어치 있는 부분이라고 생각합니다. 가장 좋은 프롬프트나 가장 좋은 모델, 가장 화려한 스킬을 가진 사람이 이길 거라는 생각입니다. 하지만 영상은 이게 거꾸로 됐다고 말합니다. AI는 모두에게 똑같이 열려 있는 유일한 것이기 때문입니다. 모두가 같은 Opus 모델을 쓸 수 있다면 모두 같은 결과를 얻어야 하는데, 실제로는 그렇지 않습니다. 사람마다 그 AI 위에 얹는 시스템과 전문성이 다르기 때문입니다. 회계사가 예산 짜는 스킬을 만들면, 스프레드시트를 한 번도 안 만져본 사람보다 열 배는 잘 만듭니다. 좋은 예산이 뭔지, 어디서 실수가 나는지를 이미 알고 있기 때문입니다. [03:20]~[03:47]
해설자가 실제로 쓰는 방법이 바로 네거티브 프롬프트입니다. 5,000시간 동안 숱하게 지뢰를 밟아봤고, 이제는 그 지뢰를 다시 안 밟는 법을 압니다. 그래서 자기가 만드는 스킬, 시스템, 지시문마다 "이건 하지 마라"는 목록을 계속 넣습니다. 이 "하지 마라" 목록이 사실은 해설자 자신의 경험과 실패를 그대로 적어 놓은 것이고, 이건 초보자가 알 방법이 없는 것들입니다. [03:47]~[04:19]
"이건 제가 지어낸 요령이 아닙니다. 앤스로픽 자신이 클로드에게 어떻게 프롬프트를 줘야 하는지 정리한 문서를 직접 찾아보세요. 그 예시들 상당수가 네거티브 프롬프트로 가득 차 있습니다. '요청받지 않은 기능은 추가하지 마라', '일어날 수 없는 상황까지 대비한 에러 처리는 넣지 마라' 같은 것들이요."
해설자 [04:19]
해설자가 인용한 두 문장은 실제로 Anthropic이 Claude Code에 심어 둔 시스템 프롬프트에 있는 문장입니다("Don't add features, refactor code, or make 'improvements' beyond what was asked" 등). Anthropic은 이런 네거티브 프롬프트를 공식 프롬프트 가이드에서 실제로 권장하지만, 동시에 "너무 세게, 너무 많이 쓰면 오히려 그 행동을 하게 만들 수 있으니 가볍게 쓰라"는 단서도 붙여 둡니다. 이 단서는 영상에 없음.
그리고 이걸 앞서 나온 낱말로 정리하면, 컨텍스트 엔지니어링이 됩니다. 모두가 같은 모델과 같은 틀(예: Claude Code라는 프로그램)을 받아 시작하지만, 그 위에 무엇을 먹이느냐 — 지식, 프롬프트 방식, 지시문, 시스템, 그리고 네거티브 프롬프트까지 — 가 결과를 가릅니다. 결국 이건 자기 자신의 뇌를 그 AI 모델 위에 얹는 방법이라는 것이 이 장의 결론입니다. [04:19]~[04:51]
대부분 사람은 AI에게 요청을 입력하고, 결과가 나쁘면 "아직 AI가 똑똑하지 않구나"라고 결론 내립니다. 하지만 진짜 좋은 결과를 뽑아내는 사람들은 프롬프트를 더 잘 쓰는 게 아니라 관리를 더 잘합니다. 해설자는 "이거 써줘", "이거 조사해줘"라고 바로 시키는 대신, 문제만 던져 주고 AI가 어떻게 풀고 싶은지 먼저 물어보게 합니다. 그리고 무엇을 만들기 전에, AI가 자신이 원하는 걸 완전히 이해했다고 확신할 때까지 질문을 계속 던지게 만듭니다. [05:00]
여기에 한 가지가 더 붙습니다. 이 모델들은 사람을 만족시키도록 훈련되어 있어서 약간 아첨하는 경향이 있다는 것이 이미 밝혀져 있다고 해설자는 말합니다. 그래서 계획이 어떤지 물어보면, 듣고 싶어 하는 말이라는 이유로 "좋다"고 답할 수 있습니다. 하지만 어떤 계획이든 사각지대가 있기 마련입니다. [05:25]
"그래서 저는 이 AI 모델들에게 일부러 반대 역할을 시킵니다. 서로 다른 AI 모델들이 여러 인물이 되어 제 계획을 공격하게 만듭니다 — 회의적인 고객, 경쟁사, 실제로 이걸 유지보수해야 하는 엔지니어처럼요. 각도가 다르면 다른 각도가 못 잡은 구멍을 잡아내기 때문입니다."
해설자 [05:25]~[05:58]
그렇게 여러 관점으로 공격을 받고 나면, AI 하나에게 "이거 괜찮아?"라고 물어봐서 나오는 답보다 훨씬 촘촘한 결과가 나옵니다. 마지막으로 해설자는 명확한 완료 기준을 정해서 AI에게 줍니다. 무엇이 "다 됐다"는 뜻인지 정확히 알려주고, 절반만 하고 멈추지 않게 하는 것입니다. 이렇게 하면 AI가 다른 하위 AI들에게 일을 나눠 맡길 수 있게 되고, 처음 아이디어부터 검증까지 이어지는 계획 전체를 갖추게 됩니다. 이게 왔다 갔다 하는 시간을 절반으로 줄여준다고 해설자는 말합니다. [05:58]~[06:20]
이 교훈은 AI 에이전트를 만드는 사람에게 가장 중요할 수 있다고 해설자는 짚습니다. AI에게 무언가를 시켰을 때 원하는 건 100% 완성이지만, 실제로 처음 받는 건 보통 60~70%짜리이고, 그때부터 피드백을 주고받으며 90~95%까지 겨우 끌어올리게 됩니다. [06:20]~[06:31]
"그런데 만약 AI가 스스로 자기 작업을 검증할 수 있고, 그 조건이 실제로 충족될 때까지 검증을 멈추지 않는다면 어떨까요? 그러면 프롬프트 하나만 던지고 기다리면, 이미 90~95%짜리 결과물을 돌려받게 됩니다. 이걸 만드는 방법은 생각보다 훨씬 단순합니다. '사람이 이 작업물을 넘겨받았다면 어떻게 검토했을까?' 그냥 스스로에게 물어보면 됩니다."
해설자 [06:31]~[07:04]
브라우저를 조작하거나, 테스트를 여러 개 짜거나, 결과물을 여러 각도에서 분석하는 일 — 사람이 손으로 검토할 때 하는 일이라면 AI도 대부분 대신할 수 있습니다. 해설자는 웹사이트를 만들 때 AI에게 스크린샷을 반복해서 찍게 시켜 화면이 잘리지 않는지, 모바일에서도 괜찮은지 확인하게 하고, 실제로 버튼을 클릭해 보고 양식이 올바른 웹훅으로 제대로 전송되는지까지 확인하게 만든다고 말합니다. [07:04]~[07:32]
이 장은 해설자가 직접 겪은 사고에서 시작합니다.
"AI가 무언가에 접근할 수 있다면, 언젠가 그걸 쓸 거라고 가정해야 합니다. 저는 이걸 아주 어렵게 배웠습니다. 저희 에이전트 하나가 할인 코드를 담아서 약 15만 명에게 이메일을 보낸 적이 있는데, 당연히 그러면 안 되는 일이었습니다. 누구도 그렇게 하라고 시키지 않았습니다. 할 일 목록에 있는 작업 하나를 보고, '할인 코드를 써서 전체 목록에 보내라'는 뜻으로 스스로 해석해서 그냥 실행해 버린 겁니다."
해설자 [07:32]~[08:09]
여기서 얻은 교훈은 프롬프트로 거는 제한과 도구로 거는 제한은 완전히 다르다는 것입니다. "절대 이메일을 보내지 마라, 초안만 써라"라고 에이전트에게 말해 둘 수는 있지만, 그 에이전트에게 여전히 "이메일 보내기" 도구가 쥐어져 있다면 언젠가는 실제로 보낼 수 있다고 가정해야 합니다. 이 모델들은 비결정적입니다 — 같은 걸 100번 돌리면 100번 다른 결과가 나올 수 있다는 뜻입니다. 모델을 바꾸면 시스템 전체가 다르게 행동하고 스킬을 다르게 해석합니다. 그래서 프롬프트에 적힌 규칙은 그냥 제안일 뿐이고, 도구 안에 박힌 규칙만이 진짜 제한입니다. [08:09]~[08:41]
구체적인 방법은 스코프를 좁힌 API 키를 쓰는 것입니다. API 키는 에이전트가 다른 서비스에 로그인할 때 쓰는 비밀번호 같은 것이고, 그 키가 물리적으로 열 수 있는 문의 개수를 제한할 수 있습니다. 예를 들어 이메일 초안은 쓸 수 있지만 발송은 절대 못 하는 키를 줄 수 있습니다.
"신입 직원에게 신용카드를 쥐여주면서 '쓰지 마세요'라고만 말하지는 않을 겁니다. 카드는 실제로 작동하고 뭔가 살 수 있는데 그냥 하지 말라고만 하는 거죠. 아마 그렇게 안 하실 겁니다."
해설자 [08:41]
그래서 에이전트가 손댈 수 있는 도구, 데이터베이스, 파일, 키를 전부 살펴보고 언젠가 그걸 다 쓸 거라고 가정하라는 것이 결론입니다. 직접 만드는 사람이 아니라면, 만드는 사람에게 "이게 스스로 무엇까지 할 수 있나요? 보내기까지 되나요, 초안만 되나요?"라고 물어보라고 조언합니다. 답이 무섭다면, 프롬프트가 아니라 접근 권한을 고쳐야 합니다. [08:41]~[08:59]
에이전트를 하나 만들어서 한 번 작동하는 걸 봤다면, 증명한 건 딱 하나 — 한 번의 결과물에서 한 번 작동했다는 것뿐입니다. 앞서 나온 것처럼 이 모델들은 비결정적이라서, 실제로 100번 돌렸을 때 성공률이 얼마일지는 알 수 없습니다. 그래서 필요한 게 AI Eval(평가)이고, 말처럼 거창한 것이 아니라고 영상은 말합니다. [08:59]
"저희는 고객 응대를 조사해야 하는 지원 에이전트를 만들었습니다. 고객 정보를 찾고, 데이터베이스에서 이것저것 찾아서 답변을 써야 했죠. 그때 저희가 한 일은 실제 사람이 손으로 쓴 좋은 응대 예시 500개를 모은 겁니다. 그게 저희의 정답 기준, 골든 데이터셋이 됐고, 그걸 다시 시스템에 먹여서 에이전트가 그 기준을 몇 번이나 만족시키는지 채점할 수 있었습니다."
해설자 [09:16]~[09:48]
답이 딱 떨어지게 객관적이면 그냥 코드로 채점하면 되지만, "이게 실제로 맞는 답인가"를 판단하려면 약간의 추론이 필요할 때가 많고, 그때는 다른 AI 모델을 심판으로 쓸 수 있습니다. 이 평가를 어떻게 설계할지는 결국 "사람이라면 이걸 어떻게 평가했을까, 성공 기준이 뭘까"로 귀결됩니다. 이렇게 한번 갖춰두면 프롬프트든 도구 설정이든 모델 자체든 작은 걸 하나 바꾸고 전체 평가를 다시 돌려서, 그 변화가 시스템을 실제로 좋게 만들었는지 나쁘게 만들었는지를 확실한 예/아니오로 알 수 있습니다. [09:48]~[10:21]
중요한 건 확실히 개선될 거라고 확신했던 수정이 오히려 점수를 떨어뜨리는 경우도 실제로 있다는 것입니다. 그래서 감으로 판단하지 말고 실제로 증명해야 하고, 이걸 실제 고객 앞이 아니라 자기 테스트 안에서 먼저 잡아내는 게 훨씬 낫습니다. 그래야 개발 단계에서 실서비스로 넘길 때 확신을 갖고 넘길 수 있습니다. 에이전트가 진짜 무언가를 건드리기 전에, 실제 예시를 정답과 함께 모으라는 것이 결론입니다 — 처음엔 좋은 예시 20개로 시작해도 괜찮지만, 골든 데이터셋은 많을수록 좋습니다. [10:21]~[10:51]
사업을 파이프라고 생각해 보라고 영상은 제안합니다. 앞쪽에서 물이 들어오는 것이 트래픽 — 사업으로 들어오는 리드와 관심입니다. 뒤쪽에서 흘러나가는 물이 이익 — 실제로 손에 남는 수익입니다. 이 파이프에서 문제가 생기는 방식은 두 가지입니다. 어딘가 막혀서 물이 뒤로 쌓이는 병목이거나, 옆으로 새서 끝까지 도달하지 못하는 누수입니다. [10:51]
"수백 개를 만들어 보면서 제가 배운 가장 큰 것은, 이해관계자가 요청하는 것은 절대 진짜 제약이 아니라는 겁니다. 이해관계자라는 건 그냥 여러분이 일을 해주는 상대방을 뜻합니다. 에이전시를 운영한다면 고객이고, 회사 안의 AI 담당자라면 상사입니다. 어느 쪽이든 그들은 '챗봇이 필요하다'거나 '이런 자동화가 필요하다'고 말하지만, 그건 그들이 생각하는 해결책일 뿐입니다."
해설자 [10:53]~[11:25]
진짜 값어치는 이해관계자 스스로도 못 본 병목이나 누수를 찾아내는 것입니다. 진짜 제약을 정확히 겨냥하는 것이야말로 사업이 성장하는 유일한 방법이기 때문입니다. 그래서 뭔가 만들기 전에 요청받은 걸 그대로 받아 만들지 말고, 실제 업무 과정을 하나씩 따라가면서 어디서 막히고 어디서 돈이 새는지, 시간이나 돈을 가장 많이 잃는 지점이 어딘지 찾아보라고 조언합니다. 이 시선으로 나타나면, 이해관계자가 여러분을 보는 눈이 바뀝니다 — 시킨 것만 만드는 하청업자가 아니라, 사업의 성장 자체를 신경 쓰는 컨설턴트로 보이게 됩니다. [11:25]~[11:58]
병목이나 누수를 찾았다고 바로 만들기 시작하면 안 됩니다. 모든 프로젝트에는 북극성이 필요한데, 이건 움직이려는 지표 딱 하나를 만들기 전에 미리 정해 두는 것입니다. [11:58]
"사업이 광고 에이전시를 고용할 때는 거래가 아주 명확합니다. '주당 광고비로 1만 달러를 쓰고, 그 광고에서 추가로 주당 5만 달러 매출을 만들어 드리겠습니다.' 누구나 보고 '그럼 그럴 만한 가치가 있었네'라고 판단할 수 있죠. 그런데 AI 프로젝트는 보통 이런 식으로 짜이지 않습니다."
해설자 [11:58]~[12:32]
AI 프로젝트는 대개 시간을 아끼거나 비용을 줄이는 걸 목표로 설계되기 때문에, 매출에 미치는 영향이 좀 불분명해집니다. 그 영향을 분명하게 만드는 것이 여러분의 일이고, 방법은 기준선(지금 상태)을 먼저 정하는 것입니다. 예를 들어 지금 주당 리드가 5개 들어온다면, "이 자동화를 만들어서 두 달 안에 주당 15개로 만들면 성공이라고 할 수 있을까요? 매출이나 마진에 의미 있게 영향을 줄까요?"라고 팀 전체에 먼저 물어봅니다. 모두가 "그렇다"고 답하면, 그 숫자가 이 프로젝트의 북극성이 됩니다. 배포하고 나면 그 숫자가 올랐는지 내렸는지 누구나 확인할 수 있고, 그 대화 하나로 프로젝트에 결승선이 생기고 이해관계자는 자기가 정확히 무엇을 얻었는지 알게 되며, "이거 자동화했어요" 정도가 아니라 실제 숫자가 박힌 훨씬 탄탄한 사례를 갖게 됩니다. [12:32]~[13:05]
9~11장은 사실 하나로 이어지는 순서입니다. 병목·누수를 찾고 → 그중 하나를 골라 → 숫자로 성공 기준을 미리 박아 두는 것. 이 순서를 거치지 않고 바로 "챗봇 만들어 드릴게요"로 들어가면, 다 만들고 나서도 그게 정말 값어치가 있었는지 아무도 증명할 수 없습니다. 반대로 이 순서를 거치면 결과물이 곧 증빙(2장)이 됩니다.
이 교훈은 AI 작업이 돈을 버는지 잃는지를 가르는 지점이라고 해설자는 말합니다. 바로 토큰 이야기입니다. 토큰은 이 AI 모델들이 요금을 매기는 단위이고, 들어가는 말 한마디 한마디, 나오는 말 한마디 한마디에 조금씩 비용이 붙습니다. [13:05]
"많은 사람이 저지르는 실수는, 과정의 모든 단계에 가장 크고 똑똑하고 비싼 모델을 던져 넣고 그 뒤로는 다시 생각을 안 한다는 겁니다. 하지만 똑똑한 방법은 그 특정 작업에 모델을 맞추는 겁니다. 예를 들어 수십만 단어짜리 기사를 읽고 한 문단짜리 요약을 뽑는 일은 단순 노동입니다. 이건 값싸고 빠른 모델이 몇 푼 안 들이고 할 수 있는 일이에요. 그런 일에 가장 비싼 모델을 쓰는 건 과합니다."
해설자 [13:05]~[13:38]
하지만 그 요약을 받아서 실제 사업에 적용하고 전략적인 판단을 내려야 하는 마지막 추론 단계라면, 거기엔 더 비싸고 똑똑한 모델을 쓸 수 있습니다. 이 생각을 시스템에 그대로 박아 넣은 것이 모델 라우팅입니다. 모든 작업이 그 작업을 처리할 수 있는 가장 싼 모델로 자동으로 보내지고, 비싼 모델은 정말 그 일이 필요할 때만 불려 옵니다. 결과물의 품질은 같은데 청구서는 10배 이상 줄어들 수 있습니다. 그리고 로컬에서 돌리는 모델이 갈수록 좋아지고 작아지고 있어서, 아예 완전히 공짜로 돌릴 수 있는 부분도 늘고 있습니다. 그래서 "작업에 모델을 맞춘다"는 이 원칙이 앞으로 더 중요해질 거라고 영상은 말합니다. [13:38]~[14:11]
우리는 모두 비슷한 각본대로 자라 왔습니다. 학위를 따고, 직함을 얻고, 그다음에야 비로소 그 일을 할 수 있다는 각본입니다. 그런데 지금은 이 순서가 거꾸로 뒤집혀 돌아가고 있다고 영상은 말합니다. [14:11]
"제가 지켜본, AI 역할로 뽑히거나 승진한 사람은 전부 예외 없이 그 역할이 생기기도 전에 이미 그 일을 하고 있었습니다. 그리고 일하는 것만이 전부가 아니었습니다. 동료와 관리자들이 그 사람을 회사의 AI 담당자로 보기 시작한 게 나머지 절반이었죠. 이건 그 사람이 지하실에서 모델을 훈련시키는 대단한 전문가라서가 아닙니다. 그냥 건물 안 다른 모든 사람과 비교했을 때, 실제로 실험해보고 작은 테스트를 돌려보고 최신 소식을 계속 따라가면서 AI 프로젝트를 사업에 들여오고 있었던 사람이 그들이었을 뿐입니다. 다른 모두는 그냥 가만히 앉아 있었고요."
해설자 [14:11]~[14:43]
그래서 이제는 증명이 먼저입니다. 매주 하기 싫은 반복 작업 하나를 골라서 자동화를 만들어 보고, 만든 뒤에는 주변에 보여줘야 합니다. 팀에게 보여주고, 상사에게 보여주고, 그게 실제 업무에 미치는 영향을 보여줍니다. 그러면 곧 사람들이 여러분이 이미 하고 있는 일을 중심으로 자리를 만들게 됩니다. 첫 고객을 구하는 중이라면, 자기 자신을 위해 뭔가를 먼저 만들어서 약속이 아니라 증거를 들고 들어가라는 것이 마지막 조언입니다. [14:43]~[15:16]
영상은 이렇게 5,000시간 넘게 AI를 만들면서 배운 12가지 교훈을 마치며, 이 교훈들을 알면 AI를 쓰는 법뿐 아니라 더 빨리 돈을 버는 법도 배우게 될 거라는 말로 끝을 맺습니다. [15:16]
이 영상 자체는 목차 없이 12개를 순서대로 늘어놓지만, 다시 보면 세 덩어리로 묶입니다. 1~4장은 "무엇을 갖춰야 남과 달라지는가"(증빙, 도구 아닌 사고방식, AI를 먼저 떠올리는 습관, 네거티브 프롬프트)이고, 5~9장은 "에이전트를 실제로 안전하고 믿을 만하게 굴리는 법"(관리, 자가 검증, 권한 스코프, Eval)이고, 10~13장은 "그걸 어떻게 돈으로 연결하는가"(병목·누수 찾기, 북극성 지표, 모델 라우팅으로 비용 관리, 성과로 자리를 만들기)입니다.
이 셋 중 어느 하나만으로는 부족합니다. 1~4장 없이 5~9장만 있으면 안전하고 잘 도는 에이전트를 만들 줄은 알지만 아무도 그 값어치를 몰라줍니다. 5~9장 없이 10~13장만 있으면 방향은 맞는데 실제로 믿고 맡길 수 있는 결과물이 안 나옵니다. 영상이 굳이 이 순서로, 안전과 검증 이야기를 사업 이야기보다 먼저 배치한 이유가 여기 있는 것으로 보입니다 — 다만 이 묶음 자체는 영상이 직접 말한 게 아니라, 정리하며 다시 읽고 나눈 것입니다.
| 낱말 | 뜻 | 나온 곳 |
|---|---|---|
| 에이전시 / 에이전트 | 에이전시는 회사(AI 자동화를 팔아 돈 버는 사업체), 에이전트는 스스로 여러 단계를 밟아 일하는 AI 프로그램 | 0장 |
| 네거티브 프롬프트 | AI에게 무엇을 하지 말라고 못 박는 지시 | 0장, 5장 |
| 컨텍스트 엔지니어링 | 모두에게 같은 모델·틀 위에, 사람마다 다르게 얹는 지식·지시·시스템 | 0장, 5장 |
| 권한 스코프 / API 키 | 에이전트가 다른 서비스에 로그인할 때 쓰는 키와, 그 키가 열 수 있는 문의 범위 | 0장, 8장 |
| 골든 데이터셋 / Eval | 정답으로 확인된 예시 모음과, 그걸로 AI 결과를 채점하는 절차 | 0장, 9장 |
| 모델 라우팅 | 작업 난이도에 맞춰 싼 모델·비싼 모델로 자동 분배 | 0장, 12장 |
| 북극성 지표 | 프로젝트 시작 전 미리 정해 둔, 성공을 가르는 단 하나의 숫자 | 0장, 11장 |
| 비결정적(non-deterministic) | 같은 걸 100번 돌려도 100번 다른 결과가 나올 수 있다는 AI 모델의 성질 | 7장, 9장 |
이 영상은 원어가 영어이고, 유튜브 원어 자막(en-orig)이 영상 시간을 거의 다 채웠습니다(29묶음, 21,829자, 15분 16초 시작 지점까지 — 영상 길이 15분 23초). 다른 언어 트랙은 받아지지 않아 비교할 대상이 없었습니다. 폴더 이름의 "[한글자막]"은 업로더가 영상 화면 안에 직접 박아 넣은 자막을 뜻하는 것으로 보이며, 유튜브 자막 트랙과는 별개입니다.
| 자막에 찍힌 것 | 실제로 추정되는 것 | 확인 방법 |
|---|---|---|
| "N and N" (반복 표기) | 자동화 도구 n8n의 오기로 보입니다. 발음이 "엔 에이트 엔"에 가까워 자동 자막이 "N and N"으로 잘못 받아 적은 것으로 보이며, 이 영상 채널의 다른 맥락(자동화·에이전시)과도 맞습니다. 화면을 직접 보지 못해 완전히 확정하지는 못했습니다. | 문맥 + 채널 성격 |
| "Hermes" | 2장에서 "cloud code나 codex나 Hermes나 뭐가 나오든"이라고 말하는 대목의 도구 이름입니다. 실제 AI 코딩 도구 이름인지 오기인지 확인하지 못했습니다. | 확인 못 함 |
| "Fable 5", "Fable" | 모델 이름으로 언급되는데, 문맥상 자연스럽게 읽혀 오기로 보이지는 않습니다. 다만 화면을 보지 못해 실제 표기와 다를 가능성이 있습니다. | 확인 못 함 |
| "Sonic" | 8장 인접 대목이 아니라 12장에서 모델 이름으로 등장하지는 않지만, 자동 자막 특성상 모델명 표기 전반을 화면으로 재확인하는 게 안전합니다. | 확인 못 함 |