목표: 논문을 모으는 사람이 아니라 연구 맥락을 운영하는 사람이 되기
AI 분야를 따라가기 어려운 이유는 자료가 부족해서가 아니다. 오히려 자료가 너무 많아서 어렵다. 매일 새로운 논문, 모델 카드, 벤치마크 결과, 기술 블로그, 릴리스 노트가 나온다. 문제는 "무엇을 읽을 것인가"보다 "읽은 것을 어떤 구조로 남길 것인가"에 있다.
AI 리서치 위키의 목표는 단순한 논문 요약 모음이 아니다. 목표는 논문과 기술 자료를 축적해 모델, 개념, 기법, 데이터셋, 벤치마크, 논쟁, 타임라인이 서로 연결된 연구 지식층을 만드는 것이다.
Karpathy가 제안한 LLM Wiki 패턴의 핵심은 원문을 그대로 보관하는 raw/, LLM이 관리하는 wiki/, 그리고 운영 규칙을 담은 CLAUDE.md 또는 AGENTS.md를 분리하는 데 있다. 원문은 증거이고, 위키는 해석이다. LLM은 원문을 읽고 위키를 업데이트하지만, 원문을 고치지는 않는다.1
AI 리서치에서는 이 분리가 특히 중요하다. 어떤 모델이 어떤 벤치마크에서 더 좋았다는 주장은 시간이 지나면 쉽게 뒤집힌다. 어떤 기법이 유망하다는 평가도 새 논문이 나오면 바뀐다. 따라서 위키에는 결론만 적으면 안 된다. 주장, 실험 조건, 한계, 비교 대상, 출처가 함께 남아야 한다.
1단계: AI 리서치용 폴더 만들기
먼저 하나의 연구 주제를 정한다. 너무 넓게 "AI 전체"로 시작하지 말고, 다음처럼 좁게 잡는 편이 좋다.
LLM 추론 능력 향상
멀티모달 모델
RAG와 장기 메모리
오픈소스 LLM 경쟁
에이전트 평가 방법
코드 생성 모델
AI 안전성과 정렬 기법
폴더는 다음처럼 시작한다.
ai-research-wiki/
raw/
papers/
articles/
model-cards/
benchmarks/
release-notes/
assets/
wiki/
papers/
models/
concepts/
methods/
datasets/
benchmarks/
timelines/
debates/
syntheses/
index.md
log.md
outputs/
reports/
briefs/
slides/
reviews/
CLAUDE.mdraw/papers/에는 논문 PDF, arXiv 초록, 저자 페이지에서 받은 보충 자료를 넣는다. raw/articles/에는 기술 블로그와 해설 글을 넣는다. raw/model-cards/에는 모델 카드와 시스템 카드, raw/benchmarks/에는 리더보드 스냅샷이나 평가표, raw/release-notes/에는 모델 또는 API 릴리스 노트를 넣는다.
중요한 규칙은 하나다.
raw/는 절대 수정하지 않는다.wiki/는 LLM이 읽고 고치고 연결한다.
원문을 고치기 시작하면 나중에 무엇이 원래 자료였고 무엇이 해석인지 구분하기 어렵다. 반대로 wiki/는 계속 바뀌어야 한다. 새 논문이 들어오면 기존 모델 페이지가 바뀌고, 벤치마크 페이지가 갱신되고, 논쟁 페이지에 새로운 반론이 추가되어야 한다.
2단계: 페이지 유형을 먼저 정한다
AI 리서치 위키는 페이지 유형을 분리해야 오래 간다. 모든 자료를 "논문 요약"으로만 저장하면 나중에 질문하기 어렵다. 논문은 출처이고, 개념과 모델과 기법은 재사용되는 지식 단위다.
기본 페이지 유형은 다음 여섯 가지면 충분하다.
논문 페이지
논문 하나당 하나의 페이지를 만든다. 단순 요약보다 다음 항목이 중요하다.
어떤 문제를 다루는가
핵심 아이디어는 무엇인가
기존 방법과 무엇이 다른가
실험 조건은 무엇인가
어떤 벤치마크를 사용했는가
한계는 무엇인가
관련 모델, 기법, 데이터셋은 무엇인가
모델 페이지
모델 페이지는 특정 모델이나 모델 계열을 추적한다.
공개 주체
공개 시점
입력·출력 형태
주요 능력
학습 또는 후처리 방식에 대한 공개 정보
비교 대상 모델
알려진 한계
관련 논문과 릴리스 노트
개념 페이지
개념 페이지는 자주 반복되는 용어를 설명한다. 예를 들어 chain-of-thought, tool-use, context-window, retrieval-augmented-generation, preference-optimization 같은 항목이다.
좋은 개념 페이지는 정의만 담지 않는다. "왜 중요한가", "어떤 문제를 해결하려는가", "어떤 오해가 있는가", "관련 기법은 무엇인가"까지 담는다.
기법 페이지
기법 페이지는 연구에서 반복 사용되는 방법을 다룬다. 예를 들어 RLHF, DPO, instruction tuning, speculative decoding, mixture-of-experts, reranking 같은 항목이다.
기법 페이지에는 반드시 비교 기준을 넣는다.
이 기법이 해결하려는 병목
필요한 데이터
장점
비용
실패 조건
대체 기법
벤치마크 페이지
AI 연구에서 벤치마크는 자주 오해된다. 점수만 보면 안 된다. 어떤 데이터셋인지, 무엇을 측정하는지, 평가 방식이 바뀌었는지, 오염 가능성은 없는지 함께 봐야 한다.
벤치마크 페이지에는 다음 항목을 둔다.
측정 대상
입력과 출력 형식
평가 지표
대표적으로 비교되는 모델
주의해야 할 해석
최근 논쟁
논쟁 페이지
AI 연구는 합의보다 논쟁이 빠르게 움직인다. 따라서 논쟁 페이지를 따로 두면 좋다.
예를 들어 다음과 같은 페이지를 만들 수 있다.
rlhf-vs-dpo.mdopen-models-vs-closed-models.mdscaling-vs-data-quality.mdlong-context-vs-retrieval.mdbenchmark-saturation.md
논쟁 페이지에는 찬반을 나란히 둔다. 어느 쪽이 맞는지 성급히 결론 내리지 말고, 근거와 한계를 함께 기록한다.
3단계: AI 리서치용 Schema 작성하기
CLAUDE.md에는 LLM이 위키 관리자로 행동하기 위한 규칙을 적는다. 너무 복잡할 필요는 없다. 처음에는 다음 정도면 충분하다.
# AI Research Wiki Schema
## 원칙
- raw/의 파일은 절대 수정하지 않는다.
- wiki/에는 원문에서 추출한 요약, 메타데이터, 해석, 연결만 기록한다.
- 모든 중요한 주장은 raw/ 출처로 역추적 가능해야 한다.
- 확실한 사실, 저자 주장, 내 해석, 추정을 구분한다.
- 새 자료를 ingest할 때 기존 페이지를 먼저 찾아 업데이트한다.
## 페이지 유형
- paper: 논문 요약과 실험 조건
- model: 모델 또는 모델 계열
- concept: 핵심 개념
- method: 반복 사용되는 기법
- dataset: 데이터셋
- benchmark: 평가 기준과 리더보드
- debate: 주요 논쟁
- timeline: 연도별 흐름
## Ingest 규칙
1. raw/의 새 자료를 읽는다.
2. wiki/papers/ 또는 wiki/sources/에 출처 요약을 만든다.
3. 관련 model, concept, method, dataset, benchmark 페이지를 업데이트한다.
4. 필요한 경우 debates/와 timelines/를 업데이트한다.
5. index.md를 갱신한다.
6. log.md에 작업 일시, 입력 자료, 변경된 페이지, 발견한 모순을 기록한다.
## 신뢰성 규칙
- 벤치마크 수치는 실험 조건과 함께 기록한다.
- 출처 없는 성능 비교는 confidence: low로 표시한다.
- 서로 다른 출처의 결과가 충돌하면 결론을 덮어쓰지 말고 contradiction 항목에 기록한다.이 Schema의 목적은 LLM을 "요약기"가 아니라 "연구 위키 관리자"로 만드는 것이다. LLM Wiki의 장점은 매번 검색 결과를 다시 조립하는 것이 아니라, 자료가 들어올 때마다 구조화된 위키를 업데이트한다는 데 있다.2
4단계: 논문 하나가 여러 페이지를 갱신하게 하기
AI 리서치 위키에서 가장 중요한 감각은 이것이다.
좋은 ingest는 파일 하나를 요약하는 일이 아니라, 위키 전체의 관련 지점을 업데이트하는 일이다.
예를 들어 새로운 멀티모달 모델 논문 하나를 넣었다고 하자. 이때 LLM이 해야 할 일은 논문 요약 하나를 만드는 데서 끝나면 안 된다.
다음 페이지들이 함께 바뀌어야 한다.
wiki/papers/새-논문.mdwiki/models/해당-모델.mdwiki/concepts/multimodal-reasoning.mdwiki/methods/vision-language-alignment.mdwiki/benchmarks/관련-벤치마크.mdwiki/timelines/2026-ai-timeline.mdwiki/debates/benchmark-saturation.md
이렇게 해야 지식이 복리로 쌓인다. 다음에 "최근 멀티모달 모델 성능 향상의 원인은 무엇인가?"라고 물었을 때, LLM은 원문 PDF를 처음부터 다시 뒤지는 대신 이미 갱신된 모델, 기법, 벤치마크, 타임라인 페이지를 읽고 답할 수 있다.
실제 ingest 프롬프트는 다음처럼 쓴다.
raw/papers/에 새 논문을 추가했다.
AI Research Wiki Schema에 따라 ingest해줘.
요구사항:
1. raw 파일은 수정하지 마라.
2. 논문 요약 페이지를 만들어라.
3. 관련 모델, 개념, 기법, 데이터셋, 벤치마크 페이지를 업데이트하라.
4. 기존 주장과 충돌하는 내용이 있으면 contradiction으로 기록하라.
5. 연도별 타임라인에 한 줄을 추가하라.
6. index.md와 log.md를 갱신하라.
7. 모든 핵심 주장에 출처 경로를 남겨라.5단계: 타임라인, 계보, 논쟁을 운영한다
빠르게 변하는 분야에서는 개별 사건보다 흐름이 중요하다. 그래서 AI 리서치 위키에는 세 가지 장기 페이지가 필요하다.
첫째, 연도별 타임라인이다. 타임라인은 단순 뉴스 목록이 아니다. 각 사건이 어떤 연구 흐름과 연결되는지 적는다. 예를 들어 Transformer 이후 구조 변화, 대규모 사전학습, instruction tuning, RLHF, DPO, 장문맥, 도구 사용, 멀티모달 모델 발전을 이어서 볼 수 있어야 한다.
둘째, 모델 계보다. 모델 계보 페이지는 "어떤 모델이 더 최신인가"를 보여주는 표가 아니다. 어떤 모델이 어떤 아이디어를 계승했고, 무엇을 바꾸었고, 어떤 평가에서 강점을 보였는지를 추적한다.
셋째, 주요 논쟁 페이지다. AI 연구에서는 같은 현상을 두고 다른 해석이 나오는 경우가 많다. 성능 향상이 모델 크기 때문인지, 데이터 품질 때문인지, 후처리 학습 때문인지, 평가 방식 때문인지 바로 결론 내리기 어렵다. 논쟁 페이지는 이런 불확실성을 보존하는 장소다.
좋은 리서치 위키는 모든 것을 확정된 지식처럼 쓰지 않는다. 오히려 무엇이 확실하고, 무엇이 논쟁 중이며, 무엇을 더 확인해야 하는지 구분한다.
6단계: Query와 Lint를 함께 둔다
AI 리서치 위키는 질문을 잘해야 살아난다. 다음과 같은 query를 정기적으로 던진다.
이 위키를 기준으로 최근 2년간 LLM 성능 향상의 주요 원인을 정리해줘.
모델 크기, 데이터 품질, 후처리 학습, 추론 기법, 평가 방식으로 나누고,
각 주장마다 관련 위키 페이지와 원문 출처를 연결해줘.DPO와 RLHF의 차이를 초심자도 이해할 수 있게 설명하되,
수학적 차이, 필요한 데이터, 실무 비용, 한계를 비교표로 정리해줘.
새로운 내용이면 wiki/debates/rlhf-vs-dpo.md도 업데이트해줘.질문 결과가 가치 있으면 outputs/에만 두지 말고 다시 위키로 편입한다. 비교표는 비교 페이지가 되고, 좋은 설명은 개념 페이지가 되고, 새로운 의문은 연구 질문 페이지가 된다.
반대로 lint는 위키를 건강하게 유지한다. 리서치 위키의 lint 항목은 다음과 같다.
오래된 주장 찾기
출처 없는 설명 찾기
상충하는 벤치마크 결과 찾기
고아 페이지 찾기
같은 개념을 다른 이름으로 쓴 페이지 찾기
모델 성능 표의 기준 시점 확인하기
논쟁 페이지에 한쪽 주장만 있는지 확인하기
실행 프롬프트는 간단하다.
AI Research Wiki를 lint해줘.
특히 오래된 주장, 출처 없는 성능 비교, 충돌하는 벤치마크 결과,
고아 페이지, 중복 개념을 찾아 outputs/lint-YYYY-MM-DD.md에 보고서로 저장해줘.
수정해도 안전한 항목과 사람 검토가 필요한 항목을 구분해줘.LLM Wiki 계열 도구들이 강조하는 ingest, query, lint의 반복 구조는 연구 위키에서도 그대로 작동한다. 일부 연구 플랫폼은 이 구조를 논문 추천, 지식 그래프, 아이디어 생성, 실험 설계, 논문 초안 작성까지 확장하고 있다.3
7단계: 위키에서 산출물을 만든다
AI 리서치 위키의 최종 가치는 산출물에서 드러난다. 잘 운영된 위키는 다음 결과물을 빠르게 만든다.
연구 질문 목록
논문 비교 보고서
기술 브리핑
강의안
블로그 초안
논문 리뷰 메모
투자자나 경영진을 위한 기술 동향 요약
팀 내부 세미나 자료
단, 산출물에는 반드시 역추적성이 있어야 한다. "이 설명은 어느 논문에서 왔는가?", "이 비교는 어느 벤치마크를 기준으로 했는가?", "이 결론은 위키의 어느 페이지에서 합성되었는가?"를 확인할 수 있어야 한다.
산출물 생성 프롬프트는 다음처럼 쓴다.
wiki/를 기준으로 '오픈소스 LLM 경쟁의 최근 흐름' 기술 브리핑을 작성해줘.
대상 독자는 AI 제품 기획자다.
조건:
1. 5쪽 분량의 Markdown 보고서로 작성한다.
2. 모델 계보, 주요 벤치마크, 라이선스 이슈, 제품 적용 가능성을 포함한다.
3. 모든 핵심 주장 옆에 관련 위키 페이지와 raw 출처를 남긴다.
4. 확실한 사실과 해석을 구분한다.
5. outputs/briefs/에 저장할 초안 형태로 작성한다.이렇게 하면 위키는 단순 보관소가 아니라 연구 생산 시스템이 된다.
운영 루틴: 하루 한 자료, 주간 lint, 월간 synthesis
처음부터 거대한 AI 연구 데이터베이스를 만들려고 하면 실패한다. 작게 시작해야 한다.
하루에 하나의 자료만 넣는다. 논문 하나, 기술 블로그 하나, 모델 카드 하나면 충분하다. 중요한 것은 많이 넣는 것이 아니라, 넣을 때마다 기존 위키가 갱신되게 하는 것이다.
주 1회는 lint를 실행한다. 오래된 주장, 출처 없는 설명, 충돌하는 벤치마크를 찾는다. 이때 모든 문제를 즉시 고치려 하지 말고, 중요한 것부터 처리한다.
월 1회는 synthesis를 만든다. 지난 한 달 동안 들어온 자료를 바탕으로 "무엇이 바뀌었는가", "어떤 질문이 새로 생겼는가", "다음 달에 무엇을 읽어야 하는가"를 정리한다.
AI 분야는 너무 빠르게 변한다. 그래서 완벽한 정리는 불가능하다. 대신 좋은 구조는 가능하다. 원문은 증거로 남기고, 위키는 해석으로 갱신하고, 질문과 lint로 건강을 유지하면 된다.
AI 리서치 위키의 목적은 모든 논문을 아는 것이 아니다. 중요한 변화가 들어왔을 때, 그것이 기존 지식의 어디를 바꾸는지 즉시 알 수 있는 구조를 갖는 것이다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.