LLM-Wiki Labs: 연구실 위키 운영을 인터랙티브 페이지로 공개한 저장소

요약

joonan30/llm-wiki-labs는 Joonan Lab이 자기 연구실의 AI Native 연구 시스템을 어떻게 만들고 운영하는지를 인터랙티브 웹 페이지로 공개하는 GitHub 저장소다. README는 이 시스템을 LLM-Wiki라고 부르고, 저장소 자체는 그 시스템의 코드가 아니라 시스템을 설명하는 읽기용 페이지의 모음이라고 규정한다.

현재 수록된 페이지는 Evolution 한 편이다. 2026-05-08에 공개되었고, 31일간의 LLM-Wiki 진화 케이스 스터디에 처음 한 시간 가이드와 실제 워크플로 5개가 붙어 있다고 README가 소개한다.

설계상의 특징은 두 가지다. 하나는 학부생부터 PI까지 네 역할의 렌즈로 같은 콘텐츠를 다르게 읽도록 만들었다는 점이고, 다른 하나는 페이지 한 편이 단일 HTML 파일이라 외부 의존성이 Google Fonts 한 줄뿐이라는 점이다. 라이선스는 MIT이며 README는 fork와 remix가 자유롭다고 덧붙인다.

이 페이지가 다루는 범위에는 제약이 하나 있다. 본 ai-wiki가 보관 중인 원본은 README 본문만 담은 스텁이어서, 페이지 실물인 evolution/ 디렉토리의 HTML이 남아 있지 않다. 따라서 아래 서술은 README가 직접 적은 문장에만 근거한다.

배경

연구용 지식 베이스를 만드는 사례는 늘고 있지만, 만든 결과를 남에게 어떤 형태로 보여줄 것인가는 별개의 문제다. 저장소를 그대로 공개하면 파일 수천 개를 마주한 사람이 어디부터 읽어야 할지 알 수 없고, 블로그 글 한 편으로 요약하면 시스템의 전개 과정이 사라진다.

이 저장소가 택한 답은 설명 자체를 하나의 웹 페이지로 만드는 것이다. README는 저장소의 목적을 "연구실의 AI 위키 시스템(LLM-Wiki)을 어떻게 만들고 운영하는지를 인터랙티브 페이지로 보여주는 모음"이라고 적는다. 즉 배포 대상이 지식 베이스 원본이 아니라 그것을 소개하는 읽을거리다.

독자가 여러 층으로 나뉜다는 점도 설계 전제에 들어가 있다. 연구실 안에서 같은 시스템을 쓰더라도 처음 합류한 학부생과 전체를 책임지는 PI는 알아야 할 내용이 다르다. README는 이 차이를 네 역할의 렌즈로 흡수했다고 밝힌다.

지식 베이스를 공개하는 형식은 크게 세 가지로 나눌 수 있고, 이 저장소는 세 번째를 택했다.

본 ai-wiki가 이 자료를 보관하는 이유도 여기에 있다. 같은 주제군의 다른 자료들이 도구와 구조를 설명하는 쪽이라면, 이 저장소는 만든 결과를 어떻게 읽히게 만들 것인가라는 전달 형식의 문제를 다룬다.

핵심 개념

LLM-Wiki는 README가 연구실의 AI 위키 시스템을 가리켜 부르는 이름이다. 이 저장소는 그 시스템 자체가 아니라 시스템의 구축과 운영 과정을 설명하는 페이지 모음이라는 점을 구분해 두어야 한다.

lab은 이 저장소에서 인터랙티브 페이지 한 편을 세는 단위다. README의 Labs 표가 # 열에 01을 매기고 링크를 evolution/이라는 하위 디렉토리로 걸어 두었으므로, lab 한 편이 디렉토리 하나에 대응한다.

네 역할 렌즈는 같은 페이지를 독자의 위치에 따라 다르게 읽히게 만드는 장치다. 다만 README가 이름을 밝힌 역할은 양 끝의 학부생과 PI 둘뿐이고, 중간 두 역할이 무엇인지는 적혀 있지 않다.

단일 HTML 배포는 빌드 산출물이나 서버 런타임 없이 HTML 파일 하나를 그대로 정적 호스팅에 올리는 방식을 뜻한다. README는 각 lab이 이 방식을 따르며 외부 의존성이 Google Fonts 한 줄뿐이라고 명시한다.

정적 호스팅은 서버에서 코드를 실행하지 않고 파일을 그대로 내려주기만 하는 배포 환경을 뜻한다. README가 "어떤 정적 호스팅에서도 그대로 작동한다"고 적을 수 있는 것은 lab이 실행할 코드를 서버에 요구하지 않기 때문이다.

AI 클리셰 회피는 README가 인용한 디자인 철학의 항목 가운데 하나다. 생성형 도구로 만든 페이지에서 반복적으로 나타나는 시각적 인상을 피한다는 뜻으로, 디자인 규격을 README에 적어 둔 이유와도 이어진다.

방법

저장소 구성

README에서 확인되는 구조는 두 층이다. 최상위에 Labs 목록을 담은 인덱스가 있고, 그 아래에 lab별 디렉토리가 놓인다.

Labs 표가 # 열을 두고 번호를 01부터 매긴다는 점이 구조상의 신호다. 편 단위로 계속 추가하는 모음집을 전제한 표기이며, 실제로 README는 저장소를 "모음"이라고 부른다.

수록 lab

현재 목록에 오른 lab은 한 편이다.

세 요소는 독자의 진입 시점이 서로 다르다. 한 페이지 안에 세 시점을 함께 넣고 역할 렌즈로 갈라 읽게 한 구성이 앞서 말한 네 역할 설계와 맞물린다.

세 요소가 각각 다른 시점을 맡기 때문에 한 독자가 전부를 읽을 필요가 없다. 역할 렌즈는 이 선택을 독자에게 맡기지 않고 페이지가 대신 하도록 만든 장치로 볼 수 있다.

배포와 로컬 실행

배포본은 github.io 도메인에서 바로 열린다. 저장소를 내려받아 직접 볼 때도 절차가 세 줄로 끝난다.

git clone https://github.com/joonan30/llm-wiki-labs.git
cd llm-wiki-labs
python3 -m http.server 8000
# open http://localhost:8000/

의존성 설치 단계가 없다는 점이 이 절차의 핵심이다. 패키지 매니저 호출도, 빌드 명령도, 환경 변수 설정도 없다. 파이썬 표준 라이브러리에 들어 있는 정적 서버만 띄우면 된다.

README가 "어떤 정적 호스팅에서도 그대로 작동한다"고 주장하는 근거가 이 표의 오른쪽 열을 전부 비운 데 있다. 호스팅을 옮기거나 몇 년 뒤 다시 열 때 깨질 지점이 그만큼 줄어든다.

디자인 시스템

README는 색과 타이포그래피, 그리고 참고한 디자인 철학의 출처를 각각 한 항목씩 적어 둔다. 기술 저장소의 README가 디자인 규격을 이 정도로 명시하는 경우는 흔하지 않다.

색은 OKLCH라는 CSS 색 표기로 지정한다고 밝히지만, README에 적힌 것은 색 이름 다섯 개뿐이고 실제 좌표값은 없다. 폰트는 용도를 나눠 세 종을 쓴다. 제목에 세리프 계열인 Newsreader를, 본문에 산세리프인 IBM Plex Sans를, 코드에 고정폭인 JetBrains Mono를 배정한 조합이다.

인용한 디자인 철학의 요지로는 세 가지가 적혀 있다.

• AI 클리셰 회피
• 의도된 타이포 대비
• 미세 인터랙션

세 항목이 함께 놓이면 의도가 분명해진다. 폰트 세 종을 용도별로 나눈 것이 두 번째 항목의 실행이고, 팔레트를 다섯 색으로 고정한 것이 첫 번째 항목의 실행에 해당한다.

라이선스와 재사용

라이선스는 MIT이고, README는 여기에 fork와 remix가 자유롭다는 문장을 덧붙인다. 라이선스 이름만 적고 끝내지 않고 재사용 의도를 따로 밝힌 표현이다.

이 조건은 저장소의 성격과 맞물려 실용적인 의미를 갖는다. lab 한 편이 단일 HTML 파일이므로, 다른 연구실이 파일 하나를 가져다 자기 사례로 내용을 바꾸는 작업에 빌드 환경을 갖출 필요가 없다. 디자인 규격이 README에 적혀 있다는 점도 같은 방향으로 작용한다. 색 다섯 개와 폰트 세 종이라는 기준이 문서에 남아 있으면 포크한 쪽이 원본의 인상을 유지하거나 의도적으로 바꾸는 판단을 할 수 있다.

결과

README에는 성능 수치도, 벤치마크 결과도, 사용자 통계도 없다. 소프트웨어 라이브러리가 아니라 읽기용 페이지 모음이라는 성격과 맞는 구성이다. 확인 가능한 정량 정보는 저장소의 구성에 관한 것뿐이다.

이 표에서 31일과 워크플로 5개라는 두 숫자는 성격이 다르다. 나머지 항목이 저장소를 열어 보면 확인되는 사실인 반면, 두 숫자는 lab 본문의 내용을 README가 한 줄로 요약한 표현이다. 본문을 읽지 않고는 그 안에서 무엇이 31일 동안 일어났는지, 다섯 워크플로가 각각 무엇인지 알 수 없다.

따라서 이 표가 알려주는 것은 저장소가 무엇을 약속하는가이지 그 약속이 지켜졌는가가 아니다. 후자를 확인하려면 live 페이지를 직접 열어야 한다.

한계

수집 범위에서 오는 한계

• raw가 README 스텁이라 내부 구현 세부는 확인 불가하다. lab 실물인 evolution/index.html이 본 ai-wiki의 원본에 남아 있지 않아, 31일 케이스 스터디의 단계 구분과 실측치, 처음 한 시간 가이드의 항목, 워크플로 5개의 내용을 하나도 인용할 수 없다. 이 페이지가 다룰 수 있는 범위는 저장소의 겉면, 즉 목적과 배포 방식과 디자인 규격까지다.
• 네 역할 가운데 두 역할의 이름을 알 수 없다. README가 밝힌 것은 양 끝의 학부생과 PI뿐이다.
• 케이스 스터디의 관찰 시작일이 없다. 31일이라는 기간과 2026-05-08이라는 공개 날짜만 있어 관찰 구간을 특정할 수 없다.

자료 자체의 한계

• 수록 lab이 1편뿐이다. Labs 표가 번호를 매긴 확장 구조를 전제하지만 현재는 첫 편만 올라 있어, 모음집이라는 형식이 유지될지는 후속 공개에 달려 있다.
• 단일 연구실의 자기 기록이다. README가 연구실 하나의 시스템을 보여주는 자료라고 스스로 규정하므로 표본 수는 1이다. 다른 연구실이 같은 결과를 얻는다는 근거는 README 범위 안에 없다.
• 외부 의존성이 하나라도 네트워크에 걸려 있다. Google Fonts 한 줄이 유일한 외부 의존성이라는 서술은 뒤집으면 그 한 줄이 네트워크 요청이라는 뜻이다. 오프라인이거나 해당 도메인이 막힌 환경에서는 세 종 폰트로 설계한 타이포그래피가 그대로 재현되지 않는다.
• 재현 절차가 없다. README는 무엇을 만들었는지 소개하지만, 케이스 스터디를 어떤 방법으로 관찰하고 기록했는지는 적지 않는다.
• 인터랙티브 페이지라는 형식에는 대가가 따른다. 단일 HTML은 배포와 보존에 유리한 반면, 내용을 문단 단위로 인용하거나 다른 문서에서 참조하기에는 마크다운 문서보다 불리하다. 이 저장소를 본 ai-wiki로 가져오는 과정에서 README만 남고 본문이 사라진 것이 그 대가를 보여주는 사례다.

핵심 용어

관련 페이지

• LLM Wiki 입문 튜토리얼 (Data Science Dojo): LLM Wiki 패턴의 영어권 입문 튜토리얼. 개인 사용자가 처음 시작하는 절차를 다루는 반면, 이 저장소는 연구실 단위 운영 경험을 읽기용 페이지로 공개한다.
• Karpathy LLM Wiki 패턴: 한국어 종합 정리 (kmyu99 Notion): 본 ai-wiki 소유자가 LLM Wiki 패턴을 한국어로 종합한 페이지. 패턴의 구조와 규모 한계를 논하는 쪽이라 이 저장소의 전달 형식 논의와 서로 보완된다.
• LLM Wiki: Karpathy LLM Knowledge Base 패턴의 한국어 레퍼런스 구현: 같은 LLM Wiki 계열의 다른 한국어 구현 사례.
• claude-obsidian: Self-Organizing AI Second Brain for Obsidian + Claude Code: LLM Wiki 형태의 지식 베이스를 Claude Code 스킬과 Obsidian vault로 구현한 사례. 구현 구조를 공개한다는 점에서 공개 대상이 다르다.
• AKB, llmwiki, GBrain 비교 및 AKB 발전 방향: 지식 베이스 세 종을 비교한 페이지.
• Lum1104/Understand-Anything: 코드베이스를 분석해 지식 그래프와 가이드 투어를 만드는 도구. 산출물을 사람이 읽는 형태로 내놓는다는 점이 겹친다.