참고 자료 · 심화

더 알아보기

RAG 내부OKF 규격지식 그래프원문

이 자료에 대하여

본 강의 이외에 더 공부하고 싶을 때

강의에서 깊이 다루지 못한 내용을 추가로 공부하실 수 있도록 정리해 두었습니다.

번호	항목	어디와 이어지나
1	RAG 내부 동작	모듈 ① · RAG란 무엇인가
2	OKF 규격 상세	모듈 ① · OKF
3	OKF v0.1 → v0.2	모듈 ① · OKF
4	프론트매터(type)의 종류	모듈 ① · OKF
5	지식 그래프란 무엇인가	모듈 ④ · 그래프 읽는 법
6	Karpathy 원문과 OpenWiki	마무리

1 · RAG 내부 동작

저장은 한 번, 검색은 질문마다

①은 파일을 올릴 때 한 번, ②는 질문할 때마다 반복됩니다

1 · RAG 내부 동작

내부에서는 무슨 일이 일어나나

단계	하는 일
청킹	긴 문서를 문단 정도 크기로 잘게 나눕니다. 문서 전체는 한 번에 넣기엔 너무 길기 때문입니다.
임베딩	글을 숫자 목록으로 바꿉니다. 뜻이 비슷한 글은 비슷한 숫자가 되어서, 컴퓨터가 의미를 비교할 수 있게 됩니다.
벡터 DB	바뀐 숫자들을 모아 두고 "이것과 비슷한 것"을 빠르게 찾아 주는 저장소입니다.
유사도 top-k	질문과 가까운 조각을 k개만 고릅니다. 보통 3~10개 정도입니다.
컨텍스트 주입	고른 조각을 질문 앞에 붙여 AI에게 함께 건넵니다. AI는 이 붙은 내용만 보고 답합니다.

한계는 마지막 두 줄에서 나옵니다. AI가 보는 것은 고른 k개 조각뿐이라, 문서 전체의 흐름이나 자료끼리 어긋나는 지점은 애초에 시야에 들어오지 않습니다. 그리고 이 과정은 매번 처음부터 다시 돕니다. 어제 찾아낸 결과가 오늘 남아 있지 않습니다.

2 · OKF 규격 상세

프론트매터에 쓰는 항목들

OKF에서는 다음과 같은 항목들을 이야기합니다.

항목	무엇을 적나	필수
type	이 문서가 어떤 종류인지 (개념, 규격, 도구 …)	필수
title	문서 제목	선택
description	한 줄 요약	선택
resource	이 문서가 가리키는 실제 대상 (표, 지표, API 등)	선택
tags	분류용 꼬리표	선택

개념 하나가 파일 하나이고, 파일 경로가 곧 그 개념을 가리키는 이름이 됩니다. 개념끼리는 링크로 서로를 가리키고, 이 링크들이 폴더를 관계의 그래프로 바꿉니다. index.md(목차)와 log.md(변경 이력)는 선택입니다.

2 · OKF 규격 상세

항목을 늘려도 되는 이유

규격의 원칙 1

필수는 type 하나

나머지는 만드는 쪽 마음입니다. 규칙이 많으면 아무도 지키지 않는다는 판단입니다.

규격의 원칙 2

모르는 항목이 있어도 거부하지 않는다

규격이 명시한 조건입니다. 그래야 서로 다른 곳에서 만든 위키가 통합니다.

규격의 원칙 3

특정 도구에 묶이지 않는다

읽고 쓰는 데 전용 계정이나 프로그램을 요구하지 않겠다고 명시했습니다.

두 번째 원칙 덕분에 내 분야에 필요한 항목을 그냥 추가해도 됩니다. 논문이면 authors, venue, year 같은 항목을 얹는 식입니다. 그 항목을 모르는 도구도 문서를 그대로 읽습니다.

규격과 예제는 github.com/GoogleCloudPlatform/knowledge-catalog 의 okf/SPEC.md 에 있습니다.

3 · OKF v0.1 → v0.2

"이 문서를 믿어도 되는가"

AI가 문서를 대량으로 만들어 내면서 생긴 질문입니다. OKF v0.2에서는 그 판단 근거를 프론트매터에서 바로 읽을 수 있게 항목을 몇 개 늘렸습니다.

추가된 항목	답하는 질문
sources	어떤 자료에서 나왔나
generated	누가(또는 무엇이) 만들었나
verified	그 뒤에 누가 확인했나
stale_after	언제부터 낡은 것으로 볼까
status	초안인가, 현행인가, 폐기됐나

generated와 verified를 나눈 것은 AI가 만든 문서와 사람이 검토한 문서를 구분하기 위해서입니다. stale_after에 기간이 아니라 날짜를 적게 한 것도 의도적인데, 언제 읽었는지와 무관하게 날짜만 비교하면 판단이 끝나기 때문입니다.

3 · OKF v0.1 → v0.2

늘어난 것은 규칙이 아니라 어휘

OKF v0.1 발표 블로그 — 왼쪽 : v0.1 발표 (2026-06-12) · 오른쪽 : v0.2 발표 (2026-07-24)

OKF v0.2 발표 블로그 — 왼쪽 : v0.1 발표 (2026-06-12) · 오른쪽 : v0.2 발표 (2026-07-24)

항목이 늘었지만 전부 선택이고, 필수는 여전히 type 하나입니다. v0.1로 만든 문서도 그대로 쓸 수 있습니다. Google은 이 업데이트를 "규칙이 아니라 어휘를 늘린 것"이라고 표현했습니다.

4 · 프론트매터의 종류

type 에 무엇을 적나

프론트매터	어떤 문서에 붙나
core-concept	개념 하나를 설명하는 문서. 오늘 실습에서 가장 많이 생깁니다.
standard	규격이나 표준을 다루는 문서
tool	도구나 프로그램을 다루는 문서
query-result	질문에 대한 답을 저장한 문서

프론트매터를 붙이는 값

나중에 골라낼 수 있습니다. "type이 개념인 문서 전부"처럼 조건으로 뽑을 수 있게 됩니다.

내 분야에 맞게 늘리기

논문용 paper, 회의록용 meeting 처럼 필요한 종류를 더해도 규격 위반이 아닙니다.

5 · 지식 그래프

지식 그래프란 무엇인가

개념을 점으로, 개념 사이의 관계를 선으로 나타낸 것입니다. 검색이나 추천 서비스에서 오래 쓰여 온 방식이고, 오늘 만드는 위키도 같은 모양입니다.

점

개념 하나 = 문서 하나

파일 경로가 그 개념의 이름이 됩니다.

선

문서 사이의 링크

본문에 걸어 둔 링크가 그대로 선이 됩니다. 따로 그리는 것이 아닙니다.

모양

중심과 변두리

여러 문서가 가리키는 개념은 크게, 아무도 가리키지 않는 문서는 혼자 떨어져 보입니다.

목록으로는 문서가 몇 개인지만 알 수 있습니다. 그래프에서는 무엇이 중심이고 무엇이 겉도는지가 드러나서, 다음에 무엇을 더 모아야 할지가 보입니다.

6 · 원문

Karpathy의 메모

Karpathy의 LLM Wiki 메모 원문 — Andrej Karpathy, llm-wiki.md (GitHub Gist, 2026-04-04)

원문이 든 비유는 이렇습니다 — "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."

Karpathy는 이 발상이 Vannevar Bush가 1945년에 제시한 Memex와 닿아 있다고 적었습니다. Bush가 풀지 못한 부분이 "그 유지 관리를 누가 하느냐"였는데, 그 자리를 LLM이 맡는다는 것입니다. 원문은 스스로를 "아이디어 파일"이라고 밝히고 있어, 구체적인 폴더 구조나 도구 선택은 각자의 분야에 따라 달라진다고 명시합니다.

6 · 사례

OpenWiki — 같은 구조를 코드 저장소에

LangChain이 공개한 도구입니다. 저장소를 읽어 마크다운 위키를 만들고, 변경이 생길 때마다 갱신합니다.

무엇을

코드 저장소를 문서로

사람이 아니라 AI가 읽을 문서를 따로 만들어 둡니다.

어떻게

오늘 만든 것과 같은 구조

프론트매터, 목차 파일, 변경 기록, 문서 사이의 링크.

왜

프론트매터가 있어야 꺼내 쓴다

문서를 만드는 것보다 필요한 걸 골라내는 게 더 어렵습니다.

개발팀이 밝힌 시행착오가 하나 있습니다. AI만 읽을 것이라 생각하고 만들었는데, 사람도 읽고 싶어 했다는 것입니다. 결국 그림을 넣게 됐다고 합니다.

원문 주소

직접 읽어 보려면

원문	주소
Karpathy의 메모	gist.github.com/karpathy
OKF 규격	github.com/GoogleCloudPlatform/knowledge-catalog 의 okf/SPEC.md
OKF 한국어 정리	discuss.pytorch.kr (v0.1 기준)
OpenWiki	github.com/langchain-ai/openwiki
실습 저장소	github.com/modulabs/okf-wiki-starter