개발자로 일하면서 읽는 글, 정리한 메모, 프로젝트에서 얻은 교훈은 대부분 흩어진다. 북마크에 묻히고, 노트앱 어딘가에 잠들고, 대화 기록 속으로 사라진다. in9yu-cosmos는 이 문제를 해결하기 위해 만든 저장소다. AI 에이전트가 원본 소스를 읽고, 핵심을 추출하고, 서로 연결된 위키 페이지로 정제한다. 한번 넣은 지식은 사라지지 않고 복리로 쌓인다.
왜 만들었는가
지식은 쌓이지 않았다
기술 블로그 글을 읽고 "나중에 써야지" 하고 북마크한다. 프로젝트를 끝내고 회고를 쓴다. 면접을 준비하면서 경력기술서를 정리한다. 이 모든 활동에서 지식이 생기지만, 각각 다른 곳에 저장되고 서로 연결되지 않는다.
SSE 구현 경험이 이력서에도 있고, 기술 블로그 메모에도 있고, 프로젝트 분석 보고서에도 있다. 하지만 "내가 SSE에 대해 아는 모든 것"을 한 곳에서 볼 수 없다.
RAG는 답이 아니었다
RAG(Retrieval-Augmented Generation)는 질문할 때마다 원본 문서를 검색해서 답을 만든다. 편리하지만 근본적인 한계가 있다.
매번 재발견한다. 같은 질문을 해도 원본에서 다시 찾는다. 이전에 발견한 연결이나 모순은 기억하지 못한다.
교차참조가 없다. "이 개념은 저 개념과 연결된다"는 사실을 추적하지 않는다.
지식이 축적되지 않는다. 좋은 분석을 했어도 대화가 끝나면 사라진다.
Karpathy의 LLM Wiki 패턴
Andrej Karpathy가 제안한 LLM Wiki 패턴은 다른 접근을 취한다. LLM이 위키를 직접 유지·관리한다. 소스를 읽으면 위키 페이지로 정제하고, 기존 페이지와 교차참조를 만들고, 모순이 있으면 표시한다. 시간이 지날수록 위키는 더 촘촘해진다.
in9yu-cosmos는 이 패턴을 Claude Code + Obsidian 위에 구현한 것이다.
어떻게 작동하는가
전체 구조
in9yu-cosmos/
├── .claude/
│ ├── agents/ # AI 에이전트 정의
│ │ ├── source-analyst.md
│ │ ├── wiki-writer.md
│ │ └── wiki-reviewer.md
│ └── skills/ # 워크플로우 스킬
│ ├── wiki-ingest/
│ ├── wiki-lint/
│ ├── obsidian-markdown/
│ └── ...
├── wiki/ # 지식이 축적되는 공간
│ ├── raw/ # 원본 소스 (불변)
│ ├── sources/ # 소스 요약
│ ├── entities/ # 인물, 조직, 제품
│ ├── concepts/ # 개념, 패턴, 방법론
│ └── syntheses/ # 비교 분석, 종합
└── output/ # 발행하는 글 (이 글이 있는 곳)
wiki는 Obsidian vault이기도 하다. [[wikilinks]]로 페이지를 연결하고, Obsidian에서 그래프 뷰로 지식의 관계를 시각화할 수 있다.
3명의 에이전트 팀
소스를 위키에 통합하는 작업은 3명의 AI 에이전트가 파이프라인으로 처리한다.
Source Analyst는 원본을 읽고 핵심 엔티티, 개념, 사실, 주장을 구조화하여 추출한다. Wiki Writer는 추출된 정보를 위키 페이지로 변환한다. 새 페이지를 만들거나 기존 페이지에 정보를 추가하고, 교차참조를 양방향으로 설정한다. Wiki Reviewer는 결과물의 품질을 검증한다. 모순, 누락된 교차참조, 구조적 문제를 찾아낸다.
지식이 쌓이는 흐름
하나의 소스를 인제스트하면 여러 위키 페이지에 영향을 준다. 실제 사례를 보자.
함인규의 이력서와 경력기술서를 인제스트하면:
raw/에 원본을 보존한다sources/함인규 이력서 v2,sources/함 인규 경력기술서 v3요약 페이지를 생성한다entities/함인규엔티티 페이지를 생성한다entities/마이다스인조직 페이지를 생성한다기존
concepts/Claude Code Automation페이지에 실무 사례를 추가한다
나중에 SSE 분석보고서를 인제스트하면:
concepts/SSE (Server-Sent Events)개념 페이지를 새로 만든다entities/함인규페이지에 SSE 구현 상세를 추가한다entities/마이다스인페이지에 기술 스택 정보를 추가한다
이렇게 소스가 쌓일수록 기존 페이지는 더 풍부해지고, 페이지 간 연결은 더 촘촘해진다. 먼저 넣은 지식이 나중에 넣는 지식의 맥락이 된다.
세 가지 운영 모드
모드
목적
작동 방식
Ingest
새 소스를 위키에 통합
3명 에이전트가 파이프라인으로 처리
Query
위키 기반 질의응답
위키를 검색하여 답변을 합성하고, 유용한 답변은 syntheses/에 저장
Lint
위키 건강 점검
모순, 고아 페이지, 깨진 링크, 누락된 교차참조를 탐지
Query 모드가 중요하다. 좋은 질문에 대한 좋은 답변은 위키에 저장되어 다음 질문의 맥락이 된다. 예를 들어 "SSE 구현에서 무엇을 개선해야 하는가?"라고 물으면, 답변이 syntheses/채용공고 에디터 SSE 개선 방안 페이지로 저장된다. 다음에 SSE 관련 질문을 하면 이 분석 결과가 맥락으로 활용된다.
wiki와 output의 관계
wiki는 원재료를 정제하고 축적하는 내부 공간이다. 구조화되어 있지만 독자를 위해 쓴 글은 아니다.
output은 wiki의 지식을 독자가 읽을 수 있는 형태로 가공하여 내보내는 발행 공간이다. 블로그 글, 기술 아티클, 발표 자료의 원고가 여기에 들어간다.
wiki가 밀가루, 설탕, 버터를 정리해둔 식재료 창고라면, output은 그 재료로 만든 빵을 진열하는 진열대다.
현재 상태
2026년 4월 7일 기준, wiki에는 58개 페이지가 있다.
8개 엔티티: 함인규, 마이다스인, React, Claude Code 등
19개 개념: SSE, React Concurrent Rendering, CSS Native UI Controls, Technical Writing 등
28개 소스 요약: 기술 블로그, 공식 문서, 이력서, 분석 보고서 등
2개 종합 분석: SSE 구현 심층 Q&A, 개선 방안
아직 초기 단계다. 소스를 더 넣을수록, 질문을 더 할수록, 위키는 더 촘촘해진다.
이 글은 in9yu-cosmos의 output 첫 번째 글이다. wiki에 축적된 지식을 바탕으로 작성했다.
