로드맵이 “동네 지도”, PRD가 “지을 집의 도면”이라면 이 문서는 공정표다.
PRD에서 정한 요구사항(R1R7)과 성공 기준(S1S5)을 어떤 순서로, 하루에 하나씩
만들어갈지만 여기서 정한다. 무엇을·왜는 다시 정하지 않는다.
짜기 전에 다시 조사한 이유
계획을 AI의 기억으로 짜면 학습 시점에 굳은 옛 방식이 나온다. 그러면 초보가 괜히 어려운 길로 간다. 그래서 순서를 짜기 전에 “지금 제일 적은 노력으로 되는 방법”을 먼저 확인했다. 결과로 PRD보다 쉬운 길이 세 군데 나왔다.
① PDF 변환 도구를 지금 깔지 않는다
PRD는 Marker·MinerU·Docling 중 하나를 2주차에 실측해 고르기로 했다. 그런데 세 도구 모두 파이썬 환경 구성과 모델 내려받기가 먼저라, 도구를 쓸 수 있게 만드는 데만 하루가 넘는다.
논문 10편 규모에서는 그 값을 못 한다. 학습메이트가 PDF를 직접 읽어 마크다운으로
옮기면 설치 없이 같은 결과가 나온다. 변환 도구는 손이 아파질 때 — 논문이 30편을
넘거나 표·수식이 자주 깨질 때 — 붙인다. 그때 Marker가 첫 후보다. 파이썬 도구
중 CPU에서 가장 가볍고, pip install marker-pdf 한 줄이며 OCR을 끈 모드가
CPU만으로 돈다.
이 판단은 미루기가 아니라 순서 바꾸기다. 도구는 문제가 생긴 뒤에 붙이면 되고, 문제가 안 생기면 안 붙여도 된다.
② 검색창 설치는 명령 한 줄이고, Astro를 올릴 필요가 없다
astro-pagefind 최신 버전(2.0.1)이 pagefind와 @pagefind/component-ui를
이미 품고 있어 npm i astro-pagefind 하나면 끝난다. 인터넷 글 대부분이 둘을 따로
설치하라고 하지만 그건 옛 버전 기준이다.
더 중요한 것은 이 패키지가 어울리는 Astro 버전을 ^2 || ^3 || ^4 || ^5 || ^6 || ^7로
선언해 두었다는 점이다. 지금 사이트의 Astro 4.16을 올리지 않아도 된다. 새 기능을
붙이려다 프레임워크부터 올려 사이트를 깨는 것이 초보가 가장 많이 하는 헛수고인데,
이 한 줄 확인으로 건너뛴다. 빌드 뒤 색인도 통합이 알아서 해서 별도 스크립트가 없다.
③ 지식베이스는 사이트 콘텐츠 폴더 밖에 둔다
src/content/ 안은 config.ts가 정한 네 종류(위키·프로젝트·저널·랜딩)만 받는다.
그 파일은 손대지 않기로 했으므로, 논문 PDF와 논문 노트를 그 안에 넣으면 규칙과 부딪친다.
프로젝트 맨 위에 knowledge/를 따로 둔다. 사이트 빌드와 완전히 분리되고,
“논문 노트를 사이트에 띄울지”를 나중에 결정할 여지가 남는다. 띄우기로 정하면
그때 사이트 폴더로 옮기면 되고, 안 띄우기로 정하면 그대로 둔다.
knowledge/
raw/ 논문 원본 PDF + 옮긴 마크다운 (한번 넣으면 고치지 않는다)
wiki/
papers/ 논문 노트 (논문 1편 = 1장)
concepts/ 개념 페이지 (여러 논문에서 뽑혀 합쳐진다)
SCHEMA.md 위 폴더의 규칙 — 어떤 항목이 들어가고 어떻게 잇는지
순서를 이렇게 잡은 이유 네 가지
검색창을 논문보다 먼저 붙인다. 검색창이 이미 돌고 있으면 논문 노트를 넣는 순간 자동으로 잡힌다. 반대로 논문을 다 넣은 뒤에 붙이면, 안 잡힐 때 원인이 논문 쪽인지 검색 쪽인지 갈라 봐야 한다. 고장 원인을 하나씩만 남기는 순서가 초보에게 훨씬 싸다.
1편을 10편보다 먼저 끝까지 통과시킨다. 논문 노트 양식이 틀린 채로 10편을 넣으면 10편을 다 고쳐야 한다. 1편으로 처음부터 끝까지 한 번 통과시켜 양식을 굳힌 뒤 늘린다.
개념 페이지는 주제가 갈린 4편이 모인 뒤에 뽑는다. 1편으로는 이을 것이 없다. 소재·바이오·AI가 섞인 3~4편이 모여야 PRD의 S2(서로 다른 주제의 논문을 잇는 개념)가 실제로 시험된다.
채점하는 자를 벡터보다 먼저 만든다. 벡터를 붙인 뒤에 평가 질문을 만들면, 자를 벡터에 유리하게 만들 위험이 있다. 질문 10개와 채점 방식을 먼저 확정하고 점수를 기록해 둔 다음 벡터를 얹는다. 결과를 부풀리지 않는다는 원칙이 여기서 순서로 나타난다.
12단계 공정표
각 단계는 하루 안에 될 크기다. 됐다는 기준을 눈으로 확인할 수 있게 적었다.
1주차 남은 것
| # | 무엇을 | 채우는 요구사항 | 됐다는 기준 |
|---|---|---|---|
| 1 | knowledge/ 폴더 뼈대와 SCHEMA.md 규칙 1장 만들기 | R1 착수 | 폴더가 생기고, 논문 노트에 어떤 항목이 들어가는지 규칙으로 적혀 있다 |
2주차 — 위키 층
| # | 무엇을 | 채우는 요구사항 | 됐다는 기준 |
|---|---|---|---|
| 2 ✅ | 논문 1편을 PDF부터 논문 노트까지 끝까지 통과시켜 양식 굳히기 | R2 | 논문 노트 1장에 서지정보·연구문제·방법·데이터·결과·한계·원문 인용이 다 있다 |
| 3 ✅ | 사이트 검색창 붙이기 (npm i astro-pagefind) + 미룬 결정 2건 확정 | R6 | 검색창에 단어를 넣으면 기존 위키 글이 목록으로 뜬다 |
| 4 ✅ | 논문 넣기를 /논문넣기 같은 정해진 명령으로 고정하고, 논문 3편 더 넣기 (총 4편) | R7, S1 진행 | 같은 명령으로 3편이 같은 양식으로 들어간다 |
| 5 ✅ | 논문 노트에서 개념 뽑아 개념 페이지 만들고 [[위키링크]]로 잇기 | R3, R4 | 개념 페이지가 생기고, 그중 하나가 주제 다른 논문 2편에 걸린다 |
| 6 ✅ | 논문 6편 더 넣기 (총 10편) | S1 | knowledge/raw/에 10편, 논문 노트 10장 |
| 7 ✅ | 점검 명령 만들기 — 끊긴 링크·빈 항목·원문에 없는 인용 잡아내기 | R7 | 명령 한 번에 문제 목록이 나온다 |
| 8 ✅ | 질문 명령 만들기 — 답 + 출처 논문 + 원문 인용을 함께 돌려주기 | R5 | 질문 하나에 세 가지가 다 나온다 |
3주차 — 검색 층과 비교
| # | 무엇을 | 채우는 요구사항 | 됐다는 기준 |
|---|---|---|---|
| 9 ✅ | 평가 질문 10개와 채점 방식 확정, 가벼운 검색으로 먼저 채점 | S3 기준선 | 10문항 점수와 “원문에 없는 인용” 건수가 기록돼 있다 |
| 10 ✅ | 벡터 검색 얹기 | R8 착수 | 같은 질문이 벡터 쪽으로도 답된다 |
| 11 ✅ | 같은 10문항으로 가벼운 검색 대 벡터 비교·측정 | R8 | 두 점수가 표로 나란히 있고, 어느 쪽이 왜 나은지 적혀 있다 |
| 12 ✅ | 논문 1편 넣는 과정 다듬어 손 가는 시간 줄이기 | S5 | /논문넣기 스킬에 21편 넣으며 겪은 사고 4건을 반영. 병렬 위임 방식(raw+노트를 한 에이전트가 같이 맡기)이 “손 가는 시간”(대기 아닌 실제 조작 시간)을 10분 내로 줄임 — 단, 전문 옮기기 자체(요약 금지)는 시간이 걸려 총 소요시간은 논문 분량에 비례 |
4주차
새로 만들지 않는다. 회고·발표자료·전자책 정리만 한다.
미리 짚어두는 것 둘
논문 원본 PDF는 저장소에 올리지 않는다. knowledge/raw/*.pdf를 .gitignore에
넣고 옮긴 마크다운만 커밋한다. 논문 PDF는 대개 출판사 저작권이 있어 저장소에 담아두면
나중에 공개 전환을 검토할 때 위험이 커지고, 용량도 는다. 원본 보존(R1)은 내 컴퓨터
폴더로 지키고, 어느 논문인지는 노트에 적힌 서지정보와 DOI로 되짚는다.
단계 3의 결정 2건, 2026-08-05에 확정했다.
① 논문 노트를 사이트에 띄운다. R5·R6(사이트 검색창에서 질문하면 답+출처+
인용이 같이 나오는 것)이 논문 노트가 사이트 밖에 있으면 애초에 성립하지 않는다.
그래서 knowledge/wiki/papers/에 있던 논문 노트를 src/content/papers/로 옮기고
전용 페이지(/papers)와 헤더 메뉴까지 연결했다. 원본 PDF와 raw 마크다운은
그대로 knowledge/raw/(사이트 빌드 밖)에 남는다 — 옮긴 건 정제된 노트뿐이다.
② 논문 10편의 주제 배분은 소재 4·바이오 3·AI 3으로 확정한다. 지향점 3갈래(데이터 사이언티스트·소재 AI 개발자·바이오헬스케어 AI 개발자)와 이미 맞물려 있고, 오늘 넣은 BNNT 논문이 소재 1편으로 바로 카운트된다. S2(서로 다른 주제 논문을 잇는 개념 페이지) 검증에도 세 갈래가 고루 섞여야 유리하다.
PRD 요구사항이 어디서 채워지나
빠뜨린 것이 없는지 거꾸로 확인한다.
| 요구사항 | 채우는 단계 |
|---|---|
| R1 원본 보존 | 1, 2 |
| R2 논문 노트 | 2 |
| R3 개념 페이지 | 5 |
| R4 위키링크 연결 | 5 |
| R5 답 + 출처 + 인용 | 8 |
| R6 사이트 검색창 | 3 |
| R7 정해진 명령 | 4, 7, 8 |
| R8 벡터 비교 (3주차) | 9, 10, 11 |
| R9 그래프 (범위 밖) | 안 함 |
성공 기준은 S1이 단계 6, S2가 단계 5, S3이 단계 9와 11, S4가 단계 3, S5가 단계 12에서 확인된다. 빠진 칸이 없다.
참고한 근거
- astro-pagefind 2.0.1 — 의존성에
pagefind·@pagefind/component-ui포함, 어울리는 Astro 버전^2 || ^3 || ^4 || ^5 || ^6 || ^7. npm 등록 정보 · 저장소 - Pagefind — 정적 사이트 전문검색. 1.5.0부터 UI를 컴포넌트로 제공. 공식 문서
- PDF 변환 도구 비교 (2026) — Marker가 CPU에서 가장 가볍고 설치가 단순. MinerU는 GPU 권장, Docling은 기업용 RAG 지향. 비교 1 · 비교 2 · Marker v2 벤치마크
- Astro 위키링크 — 기본 기능이 아니고 remark 플러그인으로 붙인다. 논문 노트를 사이트에 띄우기로 정할 때만 필요하다. remark-wiki-link · Astro 적용 사례
- 앞선 조사(Karpathy LLM 위키 패턴, 「Keyword search is all you need」)는 PRD의 근거 목록에 있다.