원본 영상은 Karpathy가 실제로 LLM을 어떻게 쓰는지 보여주는 긴 강의입니다. 이 글은 기능 소개가 아니라, 내 블로그의 LLM Wiki와 작업 하니스에 바로 적용할 수 있는 사용 원칙을 뽑아 읽습니다.
영상이 한 말은 클립과 짧은 자막 근거로 남기고, 해석과 내 생각은 분리했습니다.
한눈에 보기
- MECE 위치: LLM 실전 사용법과 컨텍스트 운영.
- 핵심 질문: 좋은 답을 얻는 사람은 프롬프트를 잘 쓰는 사람인가, 컨텍스트를 잘 준비하는 사람인가?
- 블로그 연결: Obsidian, 파일 업로드, 검색 기반 글쓰기,
/youtube와/book스킬.
핵심 클립과 해석
1. [0:23] 도구를 어떻게 쓰는지 보여주겠다
“these tools”
영상의 출발점은 모델 내부 구조가 아니라 실제 사용법이다. 이것이 중요하다. LLM은 API 성능표로만 이해할 수 없다. 질문을 어떻게 쪼개고, 어떤 자료를 넣고, 언제 새 대화를 열고, 어떤 도구를 붙이는지가 실제 성능을 결정한다.
2. [7:42] 컨텍스트 윈도우는 작업 기억이다
“context window”
컨텍스트 윈도우를 작업 기억으로 보는 관점은 내 블로그 전체의 중심이다. 좋은 결과는 모델이 똑똑해서가 아니라, 지금 필요한 정보를 작업 기억 안에 정확히 넣었기 때문에 나온다. Obsidian 노트와 블로그 글도 결국 컨텍스트를 재사용하기 위한 장치다.
3. [31:25] 검색은 가장 유용한 도구다
“internet search”
검색은 LLM을 지식 모델에서 조사 에이전트로 바꾼다. 하지만 검색 결과를 그대로 믿으면 안 된다. 출처, 날짜, 원문 링크, 짧은 인용이 필요하다. 내가 /youtube 글에서 자막 근거를 남기는 이유도 같다. 모델의 말보다 출처의 흔적이 중요하다.
4. [51:35] 파일 업로드는 컨텍스트를 통째로 넣는 일
“file upload”
파일 업로드는 단순 첨부가 아니다. 긴 문서, 논문, PDF, 노트 묶음을 작업 기억 안에 넣는 방식이다. 그래서 업로드할 파일은 정리되어 있어야 한다. 제목, 날짜, 요약, 용어집, 원문 링크가 없으면 모델은 문서를 읽어도 작업 지시를 잃기 쉽다.
5. [1:14:58] 코딩 도구는 코드베이스 컨텍스트를 가진다
“cursor”
코딩에서 중요한 차이는 챗봇이냐 IDE냐가 아니라, 코드베이스 컨텍스트를 얼마나 잘 갖고 있느냐다. Codex, Claude Code, Cursor가 강해지는 이유도 같다. 파일 구조, 테스트, 로그, Git 상태를 읽을 수 있을 때 모델은 조언자가 아니라 작업자가 된다.
6. [1:23:38] 음성은 입력 병목을 줄인다
“voice modes”
음성은 단지 편한 인터페이스가 아니다. 생각의 초안을 빠르게 외부화하는 방법이다. 블로그에서도 비슷한 문제가 있다. 완벽한 문장으로 시작하려고 하면 막힌다. 먼저 말하고, 녹취하고, 구조화하고, 검증하는 루프가 더 생산적일 수 있다.
7. [1:55:36] 메모리와 커스텀 지시
“memory bank”
메모리는 편리하지만 위험하다. 무엇을 기억하고 있는지 사용자가 모르면, 모델의 답변이 왜 그렇게 나오는지 추적하기 어렵다. 그래서 내 시스템에서는 메모리를 숨은 설정으로 두기보다, Obsidian 노트와 스킬 문서처럼 사람이 열어볼 수 있는 형태로 남기는 쪽이 낫다.
내 생각
이 영상은 프롬프트 엔지니어링을 “문장 잘 쓰기”에서 “작업 기억 설계”로 바꿔 읽게 만든다. 내가 블로그에서 하려는 것도 결국 이것이다. 좋은 글을 쓰기 위해 매번 머리에서 다시 시작하지 않고, 노트, 자막, 책, 음성, 이미지, 출처를 컨텍스트로 조립한다.
앞으로는 Obsidian 글 하나에도 질문해야 한다. 이 노트는 나중에 모델이 다시 읽을 수 있는가? 제목만 봐도 범위가 보이는가? 원문 링크와 내 생각이 분리되어 있는가? 이 조건을 만족하면 노트는 단순 기록이 아니라 LLM Wiki의 일부가 된다.
댓글
GitHub 계정으로 의견을 남길 수 있습니다. 댓글은 GitHub Discussions에 저장됩니다.