I Built Another Andrej Karpathy Using Claude

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Claude에 안드레이 카파시의 공개 자료와 출처가 있는 교육 원칙을 연결하고 실행 검증을 강제하면, 그의 설명 방식을 따르는 학습용 에이전트를 만들 수 있다는 것이 영상의 핵심이다.

📌 핵심 요점

1. 목표는 목소리나 인물의 외형을 복제하는 것이 아니라, 카파시의 설명·구현·디버깅 원칙을 Claude 에이전트의 행동으로 옮기는 것이다.
2. 블로그·강의 자막·GitHub·X 자료를 수집한 뒤, 원본은 보존하고 출처·주제·원칙·방법을 연결한 LLM 위키로 정리한다. Obsidian은 선택적인 시각화 도구다.
3. 영상에서 추출한 일곱 규칙은 직접 만들기, 핵심 요소부터 구현하기, 예측·실행·비교하기, 잘못된 버전 보여주기, 주장보다 증명하기, 가정 밝히기, 단순함 우선하기다. 각 규칙에는 원문 인용과 출처를 붙인다.
4. 규칙을 서브에이전트와 호출용 스킬로 만들고, 작성한 코드를 실행하지 않으면 답변 완료를 막는 훅을 추가한다. 설명을 실제 실행 결과와 연결하려는 장치다.
5. 토크나이저 구현과 Windows 터미널 오류 재현으로 동작을 시험한다. 새 자료를 넣으면 관련 위키 페이지와 규칙을 갱신하지만, 최종적으로 이해해야 하는 책임은 사용자에게 남는다.

🧩 배경과 문제 정의

영상은 Claude가 설명보다 코드 생성에 치우치거나, 과도한 설명과 확인되지 않은 가정으로 사용자를 더 혼란스럽게 만들 수 있다는 문제에서 출발한다. 사용자가 이해하지 못한 코드를 고객에게 전달하면 문제가 생겼을 때 수정하거나 설명하기 어렵다는 것이다.

제작자는 카파시의 공개 자료를 모아 지식 위키로 정리하고, 그의 교육 원칙을 실행 가능한 에이전트 규칙으로 바꾸는 방식을 제안한다. ‘카파시의 뇌’라는 표현은 자료와 사고 원칙을 재구성한다는 비유이며, 영상은 목소리 복제와 구분한다. 전체 과정을 네 단계로 설명하면서 실제 구축에는 여섯 프롬프트를 사용한다.

🕒 시간순 섹션별 상세정리

1. 카파시의 설명 방식을 에이전트로 옮기는 이유

• 제작자는 카파시의 경력과 교육 활동을 소개하고, 만들 대상은 그의 목소리가 아니라 설명·구현 원칙을 따르는 Claude 에이전트라고 정의한다. 작은 구현, 실행 전 예측, 오류 공개, 실행한 코드만 전달하기를 예로 든다. [01:07]
• Claude의 과잉 설명과 확인되지 않은 가정, 사용자가 이해하지 못한 코드의 납품 문제를 지적한다. 전문가의 자료를 Claude가 활용할 수 있게 정리하면 학습뿐 아니라 프로젝트의 스킬·에이전트·업무 흐름에도 연결할 수 있다고 보여준다. [02:14]
• 같은 방식을 교육자·저자·코치에게 확장해 ‘세컨드 브레인’을 만들 수 있다고 제안하고, 자신의 무료 AI OS 키트를 소개한 뒤 구축 과정으로 넘어간다. [02:42]

2. 공개 자료를 수집하고 LLM 위키로 정리하기

• Claude Code에서 여섯 프롬프트를 실행한다. 블로그·강의 자막·GitHub·X를 수집 대상으로 삼고, YouTube 자막에는 YouTube Transcript API와 yt-dlp, X에는 유료 twitterapi.io를 사용했다고 보여준다. X 수집 비용은 약 1달러였다고 보고한다. [03:25]
• 출처마다 에이전트를 하나씩 배정해 병렬 수집하고 수집 내역을 기록한다. 제작자는 약 45분∼1시간 후 출처별 하위 폴더에 70만 단어 이상을 확보했다고 드러낸다. [03:49]
• 원시 자료를 그대로 참조하면 찾기 어렵다는 이유로 LLM이 자료를 위키로 컴파일하게 한다. 원본은 보존하고 페이지 간 연결, 색인, 로그를 만들어 질의를 돕는 구상이다. [04:39]

3. 출처 연결과 일곱 가지 행동 규칙 만들기

• 두 번째 프롬프트로 원시 자료를 위키로 만들고 Obsidian에서 시각화한다. 출처·주제·원칙·방법 페이지를 연결하며, 규칙에서 근거로, 근거에서 규칙으로 이동할 수 있게 한다. 새 자료도 기존 개념과 연결한다. [05:36]
• 규칙 추출 시 정확한 인용과 출처를 요구한다. 일곱 규칙은 직접 만들기, 핵심 요소부터 시작하기, 예측·실행·비교하기, 잘못된 버전 먼저 보여주기, 증명하기, 가정 밝히기, 단순함 우선하기다. [06:30]
• 인용을 클릭하면 원문이나 타임스탬프를 확인할 수 있게 한다. 직접적인 출처가 없을 때는 카파시의 발언을 바탕으로 추론한 내용임을 명시하도록 한다. [06:42]

4. 서브에이전트·스킬과 실행 차단 장치 구성하기

• 네 번째 프롬프트는 규칙을 서브에이전트와 스킬 파일로 만든다. 서브에이전트에는 별도의 지침과 문맥, 일곱 규칙, 말하는 방식, 작업 반복 절차를 담는다. [07:10]
• /Karpathy-teach로 학습 과제를 전달하면 에이전트가 규칙에 따라 답하고, 규칙별 체크리스트로 답변을 점검하는 구조를 보여준다. [07:26]
• 다섯 번째 프롬프트로 턴 종료 시 실행되는 훅을 추가한다. 코드를 작성하고도 실행하지 않았다면 답변을 막고 실행을 요구하며, 실행·시험·수정 뒤 결과를 제시하게 한다. [08:05]

5. 실제 과제 검증과 새 자료 반영, 마지막 메시지

• 바이트 페어 토크나이저 과제로 완료 기준 정의, 최소 구현, 예상 출력 제시, 실제 실행, 실패 버전 설명과 수정을 시연한다. 결과에는 실행 내용과 출력, 변경 사항, 적용한 규칙을 함께 정리한다. [08:46]
• 고객 납품 전 검토 사례에서는 YouTube 댓글 수집 스크립트가 일반적인 Windows 터미널에서 이모지 때문에 실패하는 상황을 재현한다. 이후 코드를 정리하고 두 버전을 나란히 실행해 기능을 비교한다. [09:24]
• /Karpathy-ingest에 새 링크를 넣어 출처 페이지와 관련 규칙·색인·로그를 갱신하는 모습을 보여준다. 구축 과정을 다시 정리한 뒤 사고는 외주화할 수 있어도 이해는 외주화할 수 없다는 메시지를 전하고, 시청 감사 인사로 마무리한다. [10:43]

🧾 결론

• 전문가 자료를 많이 모으는 것만으로는 부족하다. 자료를 연결하고, 행동 규칙으로 추출하고, 실제 작업에서 검증하는 과정이 함께 필요하다.
• 인용과 출처를 확인할 수 있게 하고, 직접적인 근거가 없는 설명은 추론이라고 표시하도록 설계한다.
• 코드가 한 환경에서 실행됐다는 사실과 사용자의 실제 환경에서도 작동한다는 사실은 구분해야 한다.
• 영상의 마지막 메시지는 사고를 외주화할 수 있어도 이해까지 외주화할 수는 없다는 것이다.

📈 투자·시사 포인트

• AI 도구의 활용 가치는 코드 생성량뿐 아니라 사용자가 결과를 이해하고 수정할 수 있는지, 실행 근거를 확인할 수 있는지로 평가할 수 있다.
• 전문가 자료를 위키·규칙·스킬로 재사용하는 구조는 지식을 프로젝트와 업무 흐름에 연결하는 방식이다. 영상은 이를 다른 교육자·저자·코치에게도 적용할 수 있다고 제안한다.
• 도입 비용을 판단할 때는 자료 수집 API 비용과 함께 수집 시간, 출처 검토, 규칙 검증, 지속적인 갱신 작업을 살펴볼 필요가 있다.
• 고객 납품 전 실제 사용 환경을 재현하고 기능을 유지한 채 코드를 단순화하는 검증 절차가 실무 평가 기준으로 제시된다.

⚠️ 불확실하거나 확인이 필요한 부분

• 카파시가 Anthropic의 선임 엔지니어이며 해당 연도 5월부터 사전학습 팀에 있다는 소개는 영상의 주장이다. 제공된 자막만으로 경력과 소속을 독립적으로 확인할 수 없다.
• ‘올해 5월’, ‘지난해 8월’, ‘4월’, ‘7월’의 기준 연도와 인용 원문의 링크가 제공되지 않아, 발언 시점과 정확한 문맥을 확인해야 한다.
• 약 70만 단어 수집, 45분∼1시간 소요, X 자료 수집 비용 약 1달러는 제작자가 보고한 사례다. 수집 범위·누락률·실행 조건이 없어 동일한 결과를 보장하지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 수집할 공개 자료와 도구를 정하고, 원본을 출처별로 보존하면서 수집 성공·실패·누락 내역을 기록한다.
• 위키의 규칙과 원문 인용을 대조하고, 출처가 없는 설명에는 추론 표시가 붙는지 확인한다.
• 일곱 규칙을 서브에이전트와 스킬에 반영하고, 규칙별 점검 결과를 답변에서 확인할 수 있게 한다.
• 실행 차단 훅이 미실행 코드의 답변 완료를 실제로 막는지 시험하고, 실행 결과와 오류가 어떻게 기록되는지 확인한다.

❓ 열린 질문

• 규칙의 근거가 서로 충돌하거나 전문가의 견해가 바뀌면, 위키는 어떤 기준으로 기존 규칙을 수정해야 할까?
• 코드를 한 번 실행했다는 사실을 넘어 충분히 검증했다고 판단하려면 어떤 완료 기준이 필요할까?
• 이 에이전트가 사용자의 이해를 개선했는지는 어떤 과제로 측정할 수 있을까?