로드맵이 “동네 지도”라면 이 문서는 “지을 집의 도면”이다. 로드맵에서 이미 정한 무엇을·왜·누구를 위해는 그대로 가져오고, 거기에 없던 **“그래서 뭐가 어떻게 생겼는지”**만 여기서 정한다.
한 줄 정의
다양한 주제의 공학 논문을 원본 그대로 보존하고, AI가 그 위에 개념 지식을 합성해, 질문하면 원문 인용과 함께 답하는 나만의 위키.
로드맵에서 그대로 가져오는 것 (다시 정하지 않음)
| 항목 | 확정 내용 |
|---|---|
| 무엇 | 검색되는 나만의 지식체계 — LLM 위키 + 검색 |
| 왜 | 지식이 매번 흩어진다. 도구를 빨리 쓰는 사람이 아니라 개념부터 탄탄한 지식관리자가 되려고 |
| 누구 | 나 자신이 첫 사용자. 다음이 포트폴리오를 보는 사람 |
| 구조 | raw/(원본, 불변) ↔ wiki/(AI가 합성한 지식) — AKM의 Source 레이어 vs Knowledge 레이어 |
| 운영 | 넣고(ingest) → 점검하고(lint) → 질문하는(query) 루프 |
무엇을 넣나 — 자료
다양한 주제의 공학 논문 10편으로 시작한다. 소재·바이오·AI를 일부러 섞는다.
한 주제만 모으면 논문 10편이 다 비슷해서 연결할 것이 없다. 주제가 갈려야 “이 소재 논문의 측정 기법이 저 바이오 논문에도 쓰이네” 같은 교차 연결이 생기고, 그 연결이 위키를 단순 요약 폴더와 갈라놓는다. 지향점 세 갈래(데이터 사이언스·소재 AI· 바이오 헬스케어 AI)를 하나로 좁히지 않는 것과도 맞다.
무엇이 되어야 하나 — 요구사항
MVP에 반드시 들어가는 것:
| 번호 | 요구사항 |
|---|---|
| R1 | raw/에 논문 원본 PDF와 변환된 마크다운을 함께 보존한다. 원본은 절대 수정하지 않는다 |
| R2 | 논문 1편을 넣으면 논문 노트 1장이 생긴다. 서지정보·연구문제·방법·데이터·결과·한계·원문 인용이 들어간다 |
| R3 | 논문 노트에서 개념이 뽑혀 개념 페이지로 새로 생기거나, 이미 있는 개념 페이지에 합쳐진다 |
| R4 | 개념 페이지와 논문 노트가 [[위키링크]]로 서로 연결된다 |
| R5 | 질문하면 답 + 출처 논문 + 원문 인용문이 함께 나온다 |
| R6 | 사이트에 검색창이 있어 단어로 위키 전체를 찾을 수 있다 |
| R7 | 넣기·점검·질문이 정해진 이름의 명령으로 실행된다 (매번 다르게 부탁하지 않는다) |
3주차 이후로 미루는 것:
| 번호 | 요구사항 |
|---|---|
| R8 | 벡터 검색을 얹고, 가벼운 검색(grep·BM25) 대비 품질을 측정해서 비교한다 |
| R9 | 개념 사이의 관계를 그래프로 본다 |
한계(limitations)를 R2에 못박은 이유: 논문 요약 도구 대부분이 결과만 뽑고 한계는 버린다.
그런데 “이 방법을 내가 진짜 쓸 수 있나”를 판단할 때 결정적인 것은 한계다.
결과를 부풀리지 않는다는 원칙을 문서 구조로 못박아 둔다.
화면에 뭐가 보여야 하나
질문하는 자리를 둘 만든다. 하나는 이미 되고, 하나는 새로 붙인다.
① 대화로 묻기 (이미 동작함) — 학습메이트에게 그냥 물어본다. 위키 파일을 읽고 답 + 원문 인용을 돌려준다. 화면이 따로 없다. 추가로 만들 것이 없다.
② 사이트 검색창 (새로 붙임) — 위키 페이지 상단에 입력창 하나. 단어를 넣으면 제목 + 본문 일부 + 일치한 단어 강조가 목록으로 뜬다. 클릭하면 그 글로 이동한다. 백엔드도 API 키도 없다.
두 자리의 역할이 다르다. 검색창은 “어디에 있었지” 를 찾고, 대화는 “그래서 뭐야” 에 답한다. 검색창이 답을 만들어주지는 않는다.
어떻게 만드나 — 2026년 기준으로 다시 조사한 결과
벡터DB는 이제 필수가 아니다
2026년 4월 Karpathy가 공개한 LLM 위키 패턴은 임베딩·벡터DB 없이 마크다운 + grep + frontmatter만으로 개인 지식베이스를 돌린다. 노트 500~1,000편 (약 10만 토큰) 이하면 AI가 목차를 통째로 들고 직접 추론하기 때문이다. AAAI 2026 논문 「Keyword search is all you need」는 같은 조건에서 벡터DB 없이 키워드 검색 + 에이전트 루프만으로 기존 RAG 성능의 90% 이상을 냈다. Claude Code 자체도 초기의 로컬 벡터DB RAG를 걷어내고 이 방식으로 옮겼다.
논문 10편은 이 한계에 한참 못 미친다. 그래서 2주차는 가벼운 검색으로 만들고, 3주차에 벡터를 얹어 둘을 비교한다. “무거운 것을 썼다”보다 “무거운 것이 진짜 필요한지 측정해서 확인했다” 가 더 정직하고, 검증의 엄밀성이라는 원칙에도 맞다.
논문 PDF를 마크다운으로 뽑는 도구 — 2주차에 실측해서 고른다
| 도구 | 강점 |
|---|---|
| Marker | 정확도·속도 둘 다 상위. MinerU보다 약 5배 빠름 |
| MinerU | 다단 편집·LaTeX 수식·밀집 표에 특히 강함 |
| Docling (IBM) | 복잡한 표, 구조화 출력 |
세 도구 모두 문서 개요(다단 제목·섹션 순서) 인식이 부정확해서 손보정이 필요하다는 같은 한계를 갖는다. 논문마다 편집이 달라 미리 하나로 정하면 틀린다. 실제 논문 2~3편으로 붙여보고 2주차에 결정한다.
사이트 검색창
Pagefind. 정적 사이트용 전문검색으로, 빌드할 때 인덱스를 만들어 사이트와 함께 배포하고 검색은 브라우저에서 돈다. 서버가 없고 무료이며, 인덱스는 큰 사이트도 100KB 미만이다. 설치는 개발 의존성 하나와 빌드 명령 한 줄.
4주에 어떻게 나누나
| 주차 | 하는 일 | 그 주 끝의 상태 |
|---|---|---|
| 1주차 (지금) | 로드맵 점검(✅), 이 PRD(✅), 세부계획, raw/+wiki/ 폴더 뼈대 | 폴더 구조가 서고, 논문 1편이 끝까지 통과 |
| 2주차 | PDF 변환 도구 실측·결정, 논문 10편 넣기, 개념 페이지 합성, 가벼운 검색, 검색창 | 논문 10편이 정리된 위키 + 검색창 |
| 3주차 | 벡터 검색 얹고 가벼운 검색과 품질 비교·평가, 넣는 과정 자동화 | 완성형 MVP + 비교 결과 |
| 4주차 | 회고, 발표자료, 전자책 마무리 | 새로 만들지 않고 정리 |
뭐가 되면 “됐다”인가 — 성공 기준
숫자로 확인할 수 있게 잡는다.
| 기준 | |
|---|---|
| S1 | 논문 10편이 raw/에 보존되고, 각각 논문 노트가 있다 |
| S2 | 개념 페이지가 5개 이상, 그중 2개 이상이 서로 다른 주제의 논문 2편 이상에 연결된다 |
| S3 | 미리 만든 질문 10개 중 8개 이상이 정확한 출처·인용과 함께 답된다. 원문에 없는 인용은 0건 |
| S4 | 사이트 검색창에서 단어를 넣으면 관련 글이 나온다 |
| S5 | 새 논문 1편을 넣는 데 내 손이 가는 시간이 10분 이내 |
S2가 이 프로젝트의 진짜 시험대다. 교차 연결이 하나도 안 생기면 위키가 아니라 요약 폴더를 만든 것이다. S3의 “원문에 없는 인용 0건”은 타협하지 않는다. 이 값이 3주차에 벡터와 가벼운 검색을 비교할 때 평가 지표가 된다.
안 하는 것 (범위 밖)
4주 안에 끝내기 위해 의도적으로 뺀다.
- 논문 자동 수집·크롤링 — 논문은 내가 골라 넣는다
- 여러 사람이 같이 쓰기, 실시간 동기화
- 지식 그래프 시각화 (R9로 미룸)
- 학습일지·사례글을 이 위키에 섞기 — 학습 기록과 논문 지식은 끝까지 분리한다
2주차 시작 전에 정할 것
논문 노트를 사이트에 띄울지 정해야 한다. 저장소는 비공개지만 배포된 사이트 주소는 누구나 열 수 있다. 논문 요약과 원문 인용이 그대로 올라가면 공개되는 것이다. 검색창(R6)이 인덱싱하는 대상은 배포된 페이지라서, 이 결정이 검색 범위를 함께 정한다.
선택지는 둘이다. ① 논문 노트를 공개: false로 두고 검색창은 학습위키만 덮는다.
② 배포 접근 보호를 걸고 논문 노트까지 검색 범위에 넣는다.
같이 정할 것: 논문 10편을 어느 주제로 몇 편씩 나눌지 (예: 소재 4 · 바이오 3 · AI 3).
참고한 근거
- LLM 위키 패턴 (Karpathy, 2026-04) — 마크다운 + grep으로 벡터DB 대체. 정리 글 · 판단 기준
- 「Keyword search is all you need」 (AAAI 2026) — 벡터DB 없이 RAG 성능 90%+. 논문
- llm-wiki-plugin — 같은 패턴의 구현체.
raw/+wiki/{sources,concepts,entities,synthesis}구조, BM25 + 벡터 + RRF 융합 (벡터를 끄는--no-embed옵션 있음). 3주차 비교의 참고 구현. 저장소 - 연구 위키 표준 스키마 — source note(요약·핵심 주장·인용·연결) + concept page 구분, 논문에서 뽑는 항목: 연구문제·방법·데이터셋·평가지표·결과·한계·향후과제. 위키 방식 연구 관리 · 논문 지식그래프 구축
- PDF 변환 도구 비교 (2026) — Marker / MinerU / Docling. 비교 1 · 비교 2 · Marker 저장소
- Pagefind — 정적 사이트 전문검색. Astro 적용 안내 · Starlight 문서