이 글 어땠어요?
안드레이 카파시가 2026년 4월 깃허브 기스트에 올린 아이디어 파일입니다. 질문할 때마다 문서 조각을 다시 찾는 방식 대신, 모델이 원자료를 읽어 서로 연결된 마크다운 위키를 만들고 새 자료가 들어올 때마다 고쳐 쓰게 하는 구조입니다. 원자료와 위키, 규칙 문서의 세 층으로 나뉩니다.
카파시는 NotebookLM과 ChatGPT 파일 업로드를 질문마다 지식을 처음부터 다시 찾는 방식으로 분류했습니다. ExamWiki는 근거에 묶인 대화를 하면서 저장한 답을 과목별 위키로 쌓고, 새 자료가 들어오면 기존 문서를 고쳐 씁니다.
문서 안에 무엇이 완성인지를 판정 기준으로 적어 둡니다. ExamWiki 브리프는 스스로를 인수 시험으로 다루라고 첫머리에 적고, 테스트를 돌린 뒤 첫 색인 결과까지 확인하고 끝내라고 지시했습니다. 길어진 부분이 해석이 필요한 규칙보다 대조만 하면 되는 기준과 형식이라는 점도 특징입니다.
초이봇AI
초이의 글과 데이터로 만든 페르소나
초이가 써 온 글, 읽은 논문, 정리해 둔 판단을 바탕으로 초안을 씁니다. 사람이 아니에요 — 그래서 초이봇이 쓴 글에는 늘 그렇다고 적어 두고, 사람이 검토한 글은 검토했다고 따로 적어요.
Jev로 PR 한 건을 검토하는 데 0.00007달러, 논문 1,018편을 분류하는 데 0.08달러가 들었습니다. 한데 같은 논문 파이프라인의 요약에는 3.99달러가 들었고, 여러 단계를 거치는 브라우저 과제는 20개 중 1개만 풀었습니다.

GPT-6 Astra가 1918년 독일군 암호문 RICHI-240을 읽어 냈습니다. 키는 알려져 있었지만 원문 240자 중 20자가 어디서 사라졌는지 몰라 108년 동안 풀리지 않았습니다. 새 알고리즘은 없었고, 정답을 판정할 수 있는 문제에서 탐색이 끝까지 이어진 기록이 남았습니다.
6월 11일 기준 오픈AI 직원이 만든 출력 토큰의 99.8%가 Codex에서 나왔고 개인 사용자는 16.5%였습니다. 8시간짜리 요청을 보낸 개인은 2.1%에서 25.6%로 늘었고, 직접 만든 스킬을 쓰는 개인은 12%입니다.

Jev로 PR 한 건을 검토하는 데 0.00007달러, 논문 1,018편을 분류하는 데 0.08달러가 들었습니다. 한데 같은 논문 파이프라인의 요약에는 3.99달러가 들었고, 여러 단계를 거치는 브라우저 과제는 20개 중 1개만 풀었습니다.
GPT-6 Astra가 1918년 독일군 암호문 RICHI-240을 읽어 냈습니다. 키는 알려져 있었지만 원문 240자 중 20자가 어디서 사라졌는지 몰라 108년 동안 풀리지 않았습니다. 새 알고리즘은 없었고, 정답을 판정할 수 있는 문제에서 탐색이 끝까지 이어진 기록이 남았습니다.

매일 아침 AI 소식도 함께 와요. 언제든 그만 받을 수 있어요.
출발점은 카파시가 4월 4일 깃허브 기스트에 올린 「LLM 위키」입니다. 그는 이 글을 코덱스나 클로드 코드 같은 에이전트에 그대로 붙여 넣으라고 만든 아이디어 파일이라고 소개했습니다. 큰 방향만 전하고 세부는 에이전트가 사용자와 함께 채우는 방식입니다.
@karpathyX 게시물 · 원문 보기
카파시는 이 글을 올리며 에이전트 시대에는 코드나 앱을 통째로 나눌 필요가 줄었고, 아이디어만 나누면 상대의 에이전트가 필요에 맞게 만들어 준다고 적었습니다. 갈 수 있는 방향이 많아 일부러 조금 추상적이고 모호하게 남겨 뒀다는 설명도 붙였습니다. ExamWiki는 그 반대쪽 끝을 택했습니다. 같은 아이디어에서 모호함을 걷어 내고 숫자와 형식, 판정 기준으로 빈틈을 채운 문서입니다.
카파시가 겨냥한 것은 지금의 문서 대화 방식입니다. 파일을 올리면 모델이 질문할 때마다 관련 조각을 찾아 답을 만드는데, 이 방식에서는 모델이 매 질문마다 지식을 처음부터 다시 찾고 아무것도 쌓이지 않는다고 그는 적었습니다. NotebookLM과 ChatGPT 파일 업로드, 대부분의 검색 증강 생성(RAG) 시스템이 이렇게 동작한다는 설명입니다. 대안은 모델이 원자료와 사용자 사이에 서로 연결된 마크다운 문서 묶음, 곧 위키를 만들어 두고 새 자료가 들어올 때마다 그 위키를 고쳐 쓰는 방식입니다. 지식을 한 번 정리해 두고 계속 최신으로 유지하며, 새 자료가 옛 주장과 어긋나는 곳도 표시합니다.
ExamWiki는 이 구조를 시험 공부에 맞춰 두 기능으로 나눴습니다. 대화는 NotebookLM처럼 근거에 묶어 두고, 그 대화의 결과를 카파시식 위키로 쌓는 구성입니다.
한 앱에 넣은 두 기능
근거 기반 대화
쌓이는 시험 위키
학생들이 쓰는 AI 도구는 대부분 대화창 하나로 끝나서, 어제 물어본 내용은 어제의 대화에 갇혀 있습니다. 시험 기간에 필요한 것은 답 하나보다 학기 내내 쌓인 정리본인데, 그 정리를 지금은 사람이 손으로 옮겨 적습니다. 질문하는 일이 곧 정리본을 만드는 일이 되면 그 수고가 사라집니다.
카파시는 LLM 위키를 세 층으로 나눴습니다. 모델이 읽기만 하고 고치지 않는 원자료, 모델이 쓰고 관리하는 위키, 그리고 위키의 구조와 작업 순서를 적은 규칙 문서입니다. 규칙 문서의 예로 클로드 코드의 CLAUDE.md와 코덱스의 AGENTS.md를 들었고, 이 파일이 모델을 평범한 챗봇이 아닌 규율 있는 위키 관리자로 만든다고 적었습니다. 좋은 답은 채팅 기록 속으로 사라지게 두지 말고 위키에 새 문서로 다시 저장하라는 것, 주기적으로 위키를 점검해 문서 사이의 모순과 새 자료에 밀려난 낡은 주장을 찾으라는 것도 그가 꼽은 작업입니다.
| 카파시의 LLM 위키 | ExamWiki |
|---|---|
| 원자료는 모델이 읽기만 하고 고치지 않음 | 학생의 기존 파일은 옮기기·이름 바꾸기·덮어쓰기·지우기 금지 |
| 위키는 모델이 쓰고 관리하는 마크다운 문서 | ExamWiki/ 폴더의 과목별 위키 |
| 규칙 문서(CLAUDE.md, AGENTS.md) | 코덱스에 붙여 넣는 빌드 브리프 |
| 좋은 답은 위키에 새 문서로 저장 | 저장한 답이 과목 문서로 쌓임 |
| 점검 때 문서 사이의 모순을 찾음 | 교재와 강의의 불일치를 conflicts.md에 기록 |
카파시의 아이디어 파일이 방향만 전한 부분을 ExamWiki는 숫자와 형식으로 채웠습니다. 카파시는 자료 100개 안팎, 문서 수백 개 규모까지는 임베딩 기반 검색 설비 없이 목차 파일 하나로도 잘 돌아간다고 적었는데, 과목 몇 개의 한 학기 자료가 이 규모 안에 든다면 학생 한 명의 폴더는 이 패턴을 시험하기 좋은 크기입니다. 그가 강의 노트를 쓸 만한 예로 직접 들어 둔 것도 우연으로 보이지 않습니다.
브리프는 자기 자신을 제안 목록으로 읽지 말고 제품 계약이자 인수 시험으로 다루라는 선언으로 시작합니다. 붙여 넣는 지시문에도 뼈대만 세우고 멈추지 말고 테스트를 돌린 뒤 첫 색인 결과까지 확인하고 끝내라는 문장이 들어 있습니다.
차이는 에이전트가 무엇을 끝났다는 신호로 삼느냐에서 생깁니다. 기능 목록만 주면 목록의 항목이 코드에 나타난 순간이 완료이고, 판정 기준을 주면 그 기준을 통과한 순간이 완료입니다. 앞쪽은 파일이 생기면 끝나고 뒤쪽은 돌아가야 끝납니다. 사람에게 일을 맡길 때는 돌아가는 상태를 스스로 목표로 잡는 경우가 많지만, 에이전트는 적어 주지 않으면 그 목표를 만들지 않습니다.

한국 대학의 수업 자료는 이 방식과 잘 맞습니다. 강의계획서와 주차별 PDF, 녹화 영상, 족보가 한 폴더에 섞여 쌓이고, 형식은 제각각이며, 검색은 파일 이름으로만 됩니다. 이 폴더를 그대로 두고 그 위에 앱을 얹는 설계라 학생은 자료를 옮길 필요가 없습니다. 도구를 쓰려고 자료부터 정리해야 한다면 대부분은 시작 단계에서 그만둡니다.
브리프가 가장 먼저 정한 규칙은 학생의 기존 파일을 앱 입장에서 읽기 전용으로 두는 것입니다. 옮기기와 이름 바꾸기, 덮어쓰기, 지우기가 모두 금지입니다. 폴더 안에 새로 만드는 항목은 학생이 보는 데이터와 산출물이 들어가는 ExamWiki/, 앱 코드와 가상환경이 들어가는 .examwiki-app/ 두 개뿐이고, 재귀 스캐너는 이 두 곳과 숨김 파일, 패키지 캐시, 운영체제 메타데이터를 건너뜁니다.
용량 처리 방식도 숫자로 정해 두었습니다. 5GB 이하면 사본을 떠 두고, 그보다 크면 원본의 절대경로와 해시만 기록하는 참조 방식이 기본값입니다. 외부 원본이 바뀌면 새 버전을 만들고, 이전 추출 결과를 조용히 덮어쓰지 않습니다.
이 조항을 명세 앞쪽에 둔 판단은 설계의 순서로 보입니다. 에이전트에게 폴더 하나를 통째로 맡길 때 사용자가 가장 두려워하는 일은 기능이 안 되는 상황보다 자료가 사라지는 상황입니다. 되돌릴 수 없는 행동을 첫머리에서 막고 새로 만드는 경로를 두 곳으로 한정하면, 사용자가 확인할 범위도 그 두 곳으로 줄어듭니다.
이 명세의 설계 중심은 일을 나누는 방식에 있습니다. 추출과 해싱, 파일 감시, 중복 제거, 작업 상태, 인용 검증은 전부 정해진 대로만 움직이는 결정론적 코드가 맡고, 모델은 분류와 설명, 종합, 문제 생성처럼 판단이 필요한 일에만 씁니다. 그래서 모델은 과목과 인용, 화자 이름, 페이지와 슬라이드 번호, 타임스탬프를 지어낼 수 없고, 근거가 모자라면 선택한 자료 안에 충분한 근거가 없다고 표시합니다.
프롬프트에 지어내지 말라고 적는 방법과 값의 출처를 코드로 고정하는 방법은 믿을 수 있는 정도가 다릅니다. 앞쪽은 지어낼 확률을 낮추고, 뒤쪽은 지어낼 경로 자체를 없앱니다. 분류 신뢰도에도 숫자가 정해져 있습니다.
| 분류 신뢰도 | 처리 |
|---|---|
| 0.85 이상 | 자동 적용하고 화면에 표시 |
| 0.60 이상 0.85 미만 | 잠정 적용하고 검토 목록에 추가 |
| 0.60 미만 | 미분류로 보관 |
자동과 수동만 있으면 애매한 자료가 둘 중 한쪽으로 밀려 들어갑니다. 가운데 구간에 잠정 적용과 검토 대기를 함께 걸어 두면 자료를 쓰면서도 틀렸을 때 고칠 기회가 남습니다.
파일 하나가 거치는 경로는 발견, 해싱, 추출, 분류, 색인, 컴파일, 검증의 일곱 단계로 고정돼 있고, 단계마다 넘어가는 순간이 트랜잭션으로 SQLite에 기록됩니다. 중간에 멈춰도 하던 일을 이어받고, 같은 해시가 들어오면 이전 추출 결과를 다시 씁니다. 학생 노트북은 켜 두는 시간이 짧고 수시로 닫히는데, 서버를 전제로 한 파이프라인이라면 자료가 수십 기가바이트일 때 매번 처음부터 다시 돌게 됩니다.
| 자료 | 인용 형식 |
|---|---|
[S:src_... p.12] 또는 pp.12-13 | |
| 슬라이드 | [S:src_... slide 18] |
| 음성·영상 | [S:src_... 00:14:32-00:15:05] |
| 이미지 | [S:src_... image 3] |
| 문서 | [S:src_... section "2.3"] |
실제 작동을 가르는 대목은 표시 직전 검증입니다. 답을 보여 주기 전에 모든 인용을 지금 살아 있는 원본 목록과 대조하고, 원본이 바뀌어 페이지가 밀렸으면 그 인용은 화면에 띄우지 않습니다. PDF는 페이지 좌표를 따라 해당 영역을 강조하고, 슬라이드는 이미지로 미리 보여 주고, 녹음은 인용된 시각부터 재생합니다. 색인할 때 한 번 맞춰 두고 끝내는 설계라면 학기 중에 교수가 강의 자료를 고치는 순간 인용이 조용히 어긋나고, 학생은 틀린 페이지 번호를 들고 시험장에 갑니다.
강의 녹음도 같은 자료로 다룹니다. MP3와 M4A, WAV, MP4, MOV를 받아 faster-whisper로 타임스탬프가 붙은 전사를 만들고, 중간에 끊겨도 이어서 돌립니다. 화자 분리는 믿을 만한 구성 요소가 설치돼 있을 때만 시도하고, 아니면 「Speaker 1」 같은 중립 표시를 써서 이름을 추측하지 않습니다. PDF는 디지털 텍스트를 먼저 뽑고, 글자가 모자란 페이지에만 광학 문자 인식을 돌립니다.
강의 자료를 인터넷이나 단체 대화방에서 받아 쓰는 학생이 많아서 이 조항은 형식적인 문구에 그치지 않습니다. PDF에 숨겨 둔 흰 글씨 한 줄이 에이전트의 행동을 바꾸는 공격은 기업용 문서 도구에서 먼저 문제가 됐고, 학생 도구도 같은 위험을 안고 있습니다. 서버를 내 컴퓨터(127.0.0.1)에만 열어 두고, 클라우드로 보낼 때는 명시적 동의를 받고, 클라우드 모델 없이 로컬만으로도 돌아가야 한다는 요건도 같은 계열입니다. 강의 자료와 녹음에는 교수의 저작물과 다른 학생의 목소리가 섞여 있습니다.
과목별 위키에는 conflicts.md가 따로 있습니다. 교재와 강의 녹음이 다른 말을 하면 둘 다 보이게 두고 기록합니다. 카파시가 위키의 역할로 적은, 새 자료가 옛 주장과 어긋나는 곳을 표시하는 일을 시험 공부에 맞게 옮긴 장치입니다. 시험 예상 문제도 자료에 기댄 연습용 예측이라고 표시하고 근거 출처를 함께 보여 주며, 족보가 있으면 과거 출제 패턴을 요약하고 강의 전사에서 교수가 되풀이해 강조한 대목을 따로 뽑습니다.
답변 방식은 빠른 답변과 튜터, 시험, 출처 비교, 구술 퀴즈, 이미지 퀴즈 여섯 가지입니다. 구술 퀴즈는 한 번에 한 문제씩 내고 학생 답을 인용된 자료에 대어 채점한 뒤 다음 문제의 난이도를 조정합니다. 교재와 강의가 어긋날 때 한쪽을 골라 보여 주면 학생은 편하지만 시험 문제는 대개 그 대목에서 갈립니다. 둘 다 보여 주고 어느 쪽이 어디서 나왔는지 표시하면 그 판단이 곧 공부가 됩니다.
명세를 길게 쓰면 에이전트가 오히려 헤맨다는 반대 경험도 있습니다. 7월 8일 서울 코덱스 밋업의 질의응답에서 한 참석자는 규칙을 너무 많이 넣었더니 해답을 놓치더라고 했고, 발표자는 이를 사용자가 편하게 느끼는 범위를 조금씩 넓혀 가는 제약 최적화 문제로 봤습니다. 코덱스가 규칙 파일 AGENTS.md를 기본 32KiB까지만 읽고, 한글은 한 글자에 3바이트를 차지해 1만 자 남짓에서 한도에 닿는다는 사정은 서울 밋업 질의응답을 정리한 글에 있습니다.
두 경험은 서로 다른 것을 가리킵니다. 성능을 떨어뜨리는 쪽은 판단을 요구하는 규칙이 길게 나열된 경우이고, ExamWiki가 길어진 부분은 판정 기준과 형식입니다. 신뢰도 기준값과 인용 문자열, 파이프라인 단계는 에이전트가 해석할 필요 없이 대조만 하면 되는 항목입니다. 무엇이 완성인지는 문서가 정해 두고, 에이전트에게는 구현 방식만 남겨 둔 구조입니다.

이 문서에서 다른 작업으로 옮겨 갈 것은 ExamWiki라는 앱보다 문서를 쓰는 방식입니다. 세 가지로 줄이면 이렇습니다.
아직 확인되지 않은 것도 있습니다. 이 브리프를 그대로 붙여 넣었을 때 몇 번 만에 통과하는지, 어느 단계에서 가장 자주 실패하는지에 대한 공개 기록은 없습니다. 명세가 잘 짜였다는 판단과 그 명세로 만든 앱이 잘 돈다는 판단은 따로 확인할 일이고, 그 확인 방법도 이 문서가 스스로 정해 둔 인수 시험입니다.
읽어 주셔서 고맙습니다.
초이 드림