HowToLiveBetter 딥다이브
— Markdown 한 벌로 만드는 지식 출판 시스템

1프로젝트 한줄 요약

HowToLiveBetter는 건강·시간·돈·법적 위험 등 생활 의사결정에 관한 중국어 지식 모음입니다. 항목마다 비용, 쉬운 요약, 기대 이득, 증거 등급, 출처, 비고를 적습니다. 기술적으로는 Markdown 원고를 공통 데이터로 삼아 검색 화면과 여러 출판물을 만드는 정적 지식 시스템입니다.

원본은 book/의 Markdown 34개입니다. index.html이 이 파일들을 읽고 JavaScript 객체로 바꾸어 검색·필터 화면을 만듭니다. 별도의 빌드 도구는 같은 원고를 EPUB, PDF, 오프라인 HTML, Anki 카드로 변환합니다. 따라서 이 저장소를 공부할 때는 원고 → 파싱 → 데이터 객체 → 화면 또는 파일의 흐름을 따라가면 됩니다.

1-1. 사용자가 만나는 다섯 가지 결과

selfcheck.html에는 질문에 답하면 관련 항목을 모아 주는 자기 점검 화면도 있습니다. 이 화면은 원고 전체를 새로 쓰지 않고 기존 항목을 재사용합니다. skills/life-decision-guide/SKILL.md는 AI 도구가 원고를 찾고 출처를 붙여 답하도록 안내하는 문서입니다. 저장소가 자체 LLM 서버나 추론 엔진을 제공하는 구조는 아닙니다.

2왜 주목받는가

2-1. 생활 문제를 비용·이득·근거로 정리한다

2026-10-23 GitHub 기준 스타 68,151개, 포크 5,899개이며 TrendShift Monthly #8에 선정되었습니다. 2026-09-07 생성된 저장소가 10월 하순에 이 규모의 관심을 받았다는 사실은 확인할 수 있습니다. 다만 방문 경로나 소셜 확산 자료 없이 특정 사건이 유행을 만들었다고 단정할 수는 없습니다.

내용과 구현에서 읽히는 매력은 명확합니다. 폭넓은 생활 문제를 짧은 항목으로 정리하고, 비용·이득·출처를 같은 자리에 배치하며, 웹과 오프라인 파일 모두로 접근하게 합니다. 다음 비교는 이런 구성에서 추론한 강점입니다. 제품별 성능이나 실제 이용자 선호를 측정한 결과는 아닙니다.

주목할 기술은 새 프레임워크가 아니라, 같은 지식을 여러 사용 방식에 맞게 재사용하는 연결 구조입니다. 커밋 e2605d3의 본문 767개는 A등급 495개, B등급 220개, C등급 52개로 README의 표시와 같습니다. tools/sync-stats.mjs는 이런 숫자를 계산하고 소개 문구와 배지에 반영하는 역할까지 맡습니다.

2-2. 출처를 공개하는 일과 근거가 강한 일은 다르다

프로젝트 설명은 학술 논문과 공식 문서를 강조합니다. 그러나 README는 공식적으로 공개되지 않은 일부 사건에 기자 이름이 명시된 자체 취재 기사와 웹 아카이브를 예외로 사용한다고 밝힙니다. 따라서 모든 출처가 논문 또는 공식 문서라고 소개하면 실제 기준을 좁혀 전달하게 됩니다.

README의 읽기 안내는 A등급을 메타분석·대형 시험 중심으로 짧게 소개하지만, 자세한 등급 설명은 관찰 연구와 법령·공식 문서도 A에 포함될 수 있다고 설명합니다. A라는 글자만 보고 인과관계가 입증되었다고 해석하면 안 됩니다. 개발자는 이 차이를 데이터 모델에서도 보존해야 합니다. grade는 연구 설계 전체를 대신하지 못합니다.

2-3. 규칙이 보이므로 고치기도 쉽다

가성비 분류는 COST_W와 ratioOf()로 읽을 수 있고, 문장을 나누는 기준은 splitGain()에 공개되어 있습니다. 결과가 이상하면 입력 원고와 규칙을 대조할 수 있습니다. 초보자에게는 “화면 뒤에 숨어 있던 결정”이 짧은 함수로 드러나는 저장소라는 점이 장점입니다.

3기술 스택 전체 지도

3-1. 백엔드: 검색 서버 대신 정적 파일

원고를 저장하는 데이터베이스나 로그인 API는 없습니다. 정적 호스트가 index.html, README.md, book/*.md, updates.json을 전달합니다. 요청을 받은 뒤 검색하는 쪽은 브라우저입니다. 저장소에서 발견되는 SQLite는 Anki 배포 파일을 만드는 빌드 단계에 쓰이며, 서비스용 DB가 아닙니다.

3-2. 프론트엔드: HTML·CSS·브라우저 기본 API

React·Vue·프론트엔드 번들러에 대한 의존성 선언은 없습니다. EPUB에서 쓰는 marked를 웹 검색 파서에도 쓴다고 오해하기 쉽지만, 검색 화면은 parseReadme()와 자체 텍스트 렌더링 함수를 사용합니다.

3-3. 인프라·빌드: 실제 선언된 버전

tools/epub/package.json에는 "type": "module"과 "build": "node build.mjs"가 있습니다. 루트 package.json, Cargo.toml, pyproject.toml, go.mod, Dockerfile은 없습니다. Python은 README의 간단한 정적 서버 예시에 등장하며 애플리케이션 백엔드 언어는 아닙니다.

“설치 없이 읽을 수 있다”는 말과 “모든 배포 파일을 도구 없이 만들 수 있다”는 말은 다릅니다. 특히 Anki 빌드는 node:sqlite의 DatabaseSync를 사용합니다. README는 Node 22.13 이상을 안내하며, Node 22.13.0 공식 문서에서도 이 API를 확인할 수 있습니다.

3-4. 의존성이 적어도 재현성은 따로 살핀다

lockfile의 marked 다운로드 주소는 registry.npmmirror.com입니다. npm ci는 lockfile을 따라 설치하지만, ubuntu-latest, Node의 주 버전, 액션의 버전 태그, 설치 시점의 시스템 폰트까지 모두 같은 바이트로 고정하지는 않습니다. 또 buildStamp()가 현재 시간을 넣으므로 같은 원고도 빌드 시각에 따라 결과 바이트가 달라질 수 있습니다.

4아키텍처 심화 분석

4-1. 패턴 ① 문서에 스키마를 부여하는 작은 컴파일러

index.html의 parseReadme()는 줄을 순서대로 읽는 파서입니다. 장 제목을 만나면 sec, 항목 제목을 만나면 entry를 바꾸고, flush()로 직전 항목을 배열에 넣습니다. 함수 이름과 달리 실제 본문 입력은 여러 book/*.md를 합친 문자열입니다.

// parseReadme()에서 발췌: 제목의 모양이 데이터 경계를 결정한다.
const flush = () => {
  if (entry && sec) { sec.entries.push(entry); }
  entry = null;
};
// 장 제목: # 또는 ## 뒤에 번호와 마침표
/^#{1,2} (\d+)\. (.+)$/
// 항목 제목: ### 뒤에 번호와 마침표
/^### (\d+)\. (.+)$/

문서 속 비용 태그를 읽어 money, time, will, level, lens, who도 채웁니다. 마지막에는 dispute, todo, 비용 합계 cs, 가성비 ratio, 검색용 문자열 hay를 계산합니다. 사람이 읽는 원고가 기계가 읽는 레코드가 되는 지점입니다.

4-2. 패턴 ② 온라인·오프라인 입력을 같은 처리 흐름에 연결

index.html의 init()은 window.__CORPUS__가 있으면 내장 원고를 쓰고, 없으면 readText()로 정적 파일을 요청합니다. 읽어 온 문자열 뒤의 파싱·화면 생성은 공통입니다. 입력 방식의 차이를 앞단에서 흡수하는 간단한 어댑터 구조입니다.

// init()의 실제 분기
const EMBED = window.__CORPUS__;
const md = EMBED ? EMBED.readme : await readText('README.md');
// 각 장의 내용도 EMBED.parts[f] 또는 readText(f)에서 읽는다.
const sections = parseReadme(parts.join('\n\n'));
build(sections);

tools/offline/build.mjs는 원고·장문·업데이트 정보를 하나의 객체로 묶어 페이지에 내장합니다. 광고 이미지와 후원 QR 이미지도 data URI로 바꾸며, 분석용 GA 구간은 제거합니다. Google Fonts 링크는 남아 있어 폰트를 불러오려는 외부 요청이 발생할 수 있습니다. 알려진 삽입 지점을 찾는 must()가 실패하면 빌드를 중단합니다. 단순 문자열 치환이지만, 페이지 구조가 바뀌었음을 조용히 무시하지 않습니다.

기본 검색 페이지는 로컬 파일 열기를 감지하면 오류를 안내합니다. 반면 원고가 내장된 오프라인 HTML은 파일 요청 없이 본문을 처리합니다. 다만 자기 점검 화면 링크는 온라인 주소로 바뀌므로 모든 연결 화면까지 오프라인에 포함된 것은 아닙니다.

4-3. 패턴 ③ 상태와 파생 결과를 나누어 화면 갱신 줄이기

state는 검색어와 필터별 Set을 갖고, apply()는 원본 항목을 바꾸지 않은 채 카드의 표시 여부를 계산합니다. 가성비·등급·비용 필터는 같은 축의 선택값 중 하나와 일치하면 통과하고, 서로 다른 축의 조건은 함께 만족해야 합니다. 검색어는 공백으로 나누며 terms.every()로 모든 단어의 포함 여부를 확인합니다.

// apply()에서 발췌: 단어가 모두 들어 있는지 검사
const terms = state.q.toLowerCase().split(/\s+/).filter(Boolean);
if (ok && terms.length && !terms.every(t => e.hay.includes(t))) ok = false;
if (el.hidden === ok) el.hidden = !ok;

검색용 hay는 미리 합쳐 두지만 역색인을 만들지는 않습니다. 필터를 적용할 때 카드들을 순회하는 선형 검색입니다. 입력은 120ms 지연해 처리하고, CARD_IO는 rootMargin: '600px 0px'로 화면 가까이 온 카드의 텍스트 갱신을 준비합니다.

카드의 DOM 뼈대 자체는 build()에서 전체 생성합니다. 따라서 이 방식은 화면에 필요한 요소만 남기는 완전한 가상 목록과 다릅니다. card.key와 현재 검색어 키가 달라졌을 때만 텍스트를 다시 만들고, 화면 밖 카드는 스크롤로 가까워졌을 때 갱신하는 방식입니다.

4-4. 패턴 ④ 중복 구현을 계약 검사로 묶기

tools/lib/split-items.mjs와 index.html에는 긴 문장·출처를 나누는 규칙이 각각 있습니다. tools/check-split.mjs는 브라우저 쪽 함수 구간을 node:vm으로 읽어, 도구 쪽 splitGain()·splitSrc()와 결과를 비교하도록 작성되어 있습니다.

출력이 같은지만 보지 않습니다. 이득·비고를 나눈 뒤 다시 붙였을 때 원문과 같은지, 굵은 글씨 표시가 조각 사이에서 끊기지 않는지도 검사합니다. tools/sync-stats.mjs는 비용 규칙의 특정 소스 줄이 유지되는지도 확인합니다. 문자열 모양에 의존하는 검사는 빠르게 만들 수 있지만, 의미가 같아도 형식을 바꾸면 깨질 수 있습니다.

여러 출력물을 유지할 때 중요한 것은 파일을 많이 만드는 능력보다, 출력 사이의 의미가 어긋나지 않게 확인하는 능력입니다. 이 저장소의 중복 규칙과 검사는 “공통 모듈로 합칠지, 복사본을 두고 동등성을 검사할지”를 고민하기 좋은 사례입니다.

5디렉토리 구조 해부

docs/核实记录/는 완성된 설명만 보관하는 곳이 아닙니다. 자료를 어떻게 확인하고 수정했는지 남기는 기록입니다. 반면 tools/lib/book.mjs의 readBook()은 README에 연결된 본문·장문 파일을 골라 출력 목록을 만듭니다. 검증 기록 239개가 모두 전자책에 자동으로 들어가는 구조는 아닙니다.

5-1. 파일 수와 물리적 줄 수

위 수치는 커밋 e2605d3의 추적 파일 기준이며, 빈 줄·주석을 포함한 물리적 줄 수입니다. 이미지와 .git/은 줄 수에서 제외합니다. 본문만 보면 book/는 7,360줄, 검증 기록은 14,455줄입니다. index.html은 1,672줄이며 그 안의 인라인 JavaScript는 약 1,133줄입니다. HTML 줄 수와 내부 JS 줄 수를 더하면 중복 집계가 됩니다.

GitHub의 주 언어 HTML만 보고 이 저장소를 평가하면, 원고 데이터와 출판 자동화 도구라는 두 축을 놓칩니다. 전체 추적 파일은 331개, 이미지 등을 포함한 파일 내용은 약 6.06MiB입니다. 작은 코드로 비교적 큰 지식 자산을 다룬다는 점이 이 프로젝트의 규모를 읽는 기준입니다.

6학습 포인트 (기술별)

6-1. 파서와 데이터 모델: 상태를 기억하며 줄 읽기

parseReadme()는 현재 어느 장과 항목을 읽는지 기억하는 작은 상태 기계입니다. “새 제목이 나오면 이전 항목을 닫는다”는 규칙은 로그 분석, 설정 파일 읽기, CSV 후처리에도 응용할 수 있습니다. 반대로 들여쓰기·여러 줄·인용문까지 허용하려면 정규식 몇 개로 충분한지 먼저 검토해야 합니다.

학습용 변형으로는 원고를 직접 바꾸기 전에 유효성 검사기를 설계해 보세요. 필수 필드가 없을 때 빈 문자열로 둘지 오류로 처리할지, 모르는 비용 태그를 어떻게 표시할지 정합니다. 현재 비용 계산의 ?? 0은 모르는 값을 0점으로 처리하므로, 잘못된 입력이 가장 낮은 비용처럼 보일 수 있다는 점을 생각해 볼 수 있습니다.

6-2. 순수 함수: 판단 기준을 표로 먼저 설명하기

tools/lib/book.mjs의 ratioOf(cost, level)는 입력 두 개로 분류를 돌려줍니다. 비용은 돈·시간·의지의 각 0~2점을 합한 0~6점입니다. 아래 표는 원문의 분류값을 한국어로 풀어 쓴 것입니다.

증거 등급 A/B/C는 이 함수의 인자가 아닙니다. 근거의 신뢰도와 비용 대비 이득을 서로 다른 축으로 보관하기 때문입니다. 분류 기준은 저자의 판단을 코드화한 것이며, 사용자 개인에게 최적인 결정을 수학적으로 증명하는 공식은 아닙니다.

// ratioOf()를 이해하기 위한 학습용 표현: 출력값을 한국어로 바꿨다.
function classify(cost, level) {
  if (level === '큼') {
    return cost === 0 ? '매우 높음' : cost <= 2 ? '높음' : '보통';
  }
  return level === '중간' && cost === 0 ? '높음' : '보통';
}
// 실습: cost 0, 2, 3과 level 세 종류의 결과를 표와 대조한다.

6-3. 비동기 I/O: 재시도할 실패를 구별하기

index.html의 readText(path, tries = 3)는 성공한 텍스트를 메모리 Map에 저장합니다. 실패한 요청은 캐시에 남기지 않아 다시 읽을 수 있습니다. 파일이 정말 없는 404와 잠시 바쁜 서버의 5xx를 똑같이 재시도하지 않는 것도 배울 점입니다.

지원 브라우저에서는 AbortSignal.timeout(20000)을 연결합니다. Promise.all()의 장 하나가 끝내 실패하면 전체 로딩도 실패하지만, 성공한 장은 캐시에 남습니다. 네트워크가 약한 상황에서 “전체를 처음부터 다시 받기”를 줄이는 구조입니다.

6-4. DOM 렌더링: 텍스트와 마크업을 구분하기

renderText()는 링크·굵은 글씨 같은 허용한 표현을 골라 DOM 노드로 만듭니다. mkLink()는 a.textContent에 표시 문구를 넣고, 일반 텍스트는 텍스트 노드와 하이라이트 처리로 전달합니다. 자기 점검의 esc()도 특수문자를 이스케이프합니다.

// mkLink()의 핵심: 표시할 문구를 HTML로 해석하지 않는다.
const a = document.createElement('a');
a.href = href;
a.target = '_blank';
a.rel = 'noopener';
a.textContent = text;

innerHTML을 쓰는 곳도 있으므로 파일 전체가 텍스트 API만 쓴다고 설명하면 틀립니다. 중요한 것은 어떤 값이 외부 입력이며 어느 출력 경로에서 이스케이프되는지를 따라가는 습관입니다. 임의 사용자가 원고를 업로드하는 서비스로 확장한다면 URL과 HTML의 신뢰 경계도 다시 설계해야 합니다.

6-5. 문서 변환과 바이너리: 책과 카드도 파일 포맷이다

tools/epub/build.mjs는 new Marked({ gfm: true })를 만들고, renderer.heading()으로 제목 ID와 목차 정보를 수집합니다. rewriteHref()는 포함된 문서의 상대 링크를 책 내부 링크로 바꿉니다. 원시 HTML과 이미지는 기본 본문 변환에서 제거하고, 표지는 별도로 추가합니다. Marked 확장 문서와 나란히 읽으면 렌더러를 바꾸는 지점을 찾기 쉽습니다.

tools/lib/zip.mjs의 zip()는 CRC32, 로컬 헤더, 중앙 디렉터리, 끝 레코드를 직접 만듭니다. EPUB의 mimetype은 첫 파일이면서 압축하지 않도록 store: true로 넣습니다. 이는 EPUB 표준의 컨테이너 규칙과 연결되는 작은 구현입니다. 직접 ZIP을 만드는 것은 학습 가치가 크지만 범용 압축 도구의 모든 기능을 구현한 것은 아닙니다.

Anki 빌더의 parseSection()은 제목·요약·비용 등을 읽고 DatabaseSync로 collection.anki2를 만듭니다. 이를 빈 미디어 목록과 ZIP으로 묶으면 .apkg가 됩니다. 상세 이득과 모든 출처 원문을 카드에 복제하지 않고, 요약과 온라인 원문 링크를 제공합니다.

6-6. CI와 콘텐츠 품질: 검사가 무엇을 보장하는지 읽기

tools/check-plain.mjs는 쉬운 요약의 길이를 공백 제외 120자로 제한하고, 통계 약어·연구 전문 표현·추상적인 상투어를 검사합니다. 새 숫자를 검사하는 --numbers는 오탐 때문에 기본 CI에서 제외됩니다. 문장 규칙 검사는 할 수 있지만 출처의 참됨을 증명하는 검사는 아닙니다.

.github/workflows/book.yml의 refs, plain, split, stats, selfcheck는 build와 독립된 job입니다. build에 이 검사들을 기다리는 needs가 없으므로, 일부 검사에 실패해 워크플로가 빨갛게 보여도 배포 단계는 별도로 진행될 수 있습니다. 반면 빌드 job 안의 EPUBCheck 실패는 그 뒤 업로드·릴리스 단계의 진행을 막습니다.

정기 링크 검사는 월요일 UTC 01:00, 한국 시간 10:00에 예약됩니다. tools/check-links.mjs는 동시 작업 수 8, 논리적 대기 제한 20초를 쓰고, 확정된 죽은 링크·접속 실패·TLS 오류를 구분해 보고합니다. Promise.race()로 대기 시간을 제한하므로 요청 자체를 취소하는 구현과는 구별해야 합니다. 링크 실패는 보고용이며 그 개수로 실패 종료하지 않습니다.

검사 통과 여부를 읽기 전에, 그 검사가 어떤 오류를 찾고 어떤 배포를 막는지부터 확인해야 합니다. tools/updates.mjs는 Git 이력에서 항목을 추적하므로 완전한 이력을 요구합니다. CI의 stats job에만 fetch-depth: 0이 있는 이유도 이 요구와 연결됩니다.

7하드웨어 / 시스템 요구사항

저장소는 CPU 코어 수·RAM·디스크의 공식 최소 사양이나 처리 속도 벤치마크를 제시하지 않습니다. 검색은 모델 추론이나 벡터 DB를 사용하지 않으므로 GPU를 요구하는 구성 요소도 없습니다. 아래에서 환경 요구는 소스·CI 설정 기준이고, 자원 여유에 관한 설명은 학습 환경을 위한 추정입니다.

7-1. 파일 크기로 예상해 볼 수 있는 범위

본문 Markdown은 합계 2,385,074바이트, 약 2.27MiB입니다. README까지 합하면 약 2.33MiB이며 전송 압축 전 텍스트 크기입니다. 온라인 초기 로딩은 README에서 장 목록을 얻은 뒤 장 34개를 병렬로 읽고, 업데이트 JSON도 별도로 읽습니다. 이미지·폰트·전송 헤더까지 포함한 실제 다운로드 크기와는 다릅니다.

본문은 작은 편이지만 메모리 사용량이 원고 바이트와 같지는 않습니다. 원문 문자열, 항목 객체, 검색 문자열, 전체 카드 DOM이 함께 존재합니다. 저사양 기기에서는 최초 DOM 생성과 검색어에 따른 텍스트 갱신을 따로 관찰하는 것이 좋습니다. 실제 지연 시간은 측정 자료가 없으므로 숫자로 보장할 수 없습니다.

8직접 해볼 수 있는 실습 과제

아래는 학습자가 별도 실습용 사본이나 새 예제로 진행할 과제입니다. 새 생활 조언을 추가하는 대신 파서·상태·ID 같은 소프트웨어 동작을 다룹니다. 각 과제의 완료 기준은 “화면이 보인다”보다 구체적으로 잡았습니다.

좋은 실습은 기능 하나를 더하는 것에서 끝나지 않고, 잘못된 입력과 기존 사용자의 데이터까지 설명할 수 있어야 합니다. 원본 규칙을 그대로 복사하는 과제보다, 그 규칙이 어떤 상황에서 깨지는지 찾는 과제가 더 오래 남습니다.

9관련 기술 심화 학습 로드맵

다음 일정은 공식 학습 기간이 아닌 제안입니다. JavaScript의 변수·함수·배열을 이미 접했다면 1주차부터 시작하고, 아직 낯설다면 문자열·객체·반복문을 먼저 익힌 뒤 진행하세요. 매주 하나의 작은 결과물을 남기면 서로 다른 도구가 어떻게 연결되는지 확인할 수 있습니다.

9-1. 그다음에는 무엇을 더 볼까

검색 쪽이 재미있다면 단순 문자열 포함 검사와 역색인을 비교해 보세요. 현재 구조는 항목 수를 N, 검색어 수를 T, 검색 문자열 길이를 L로 보면 대략 N × T × L에 비례하는 탐색을 수행합니다. 먼저 데이터 규모별 지연과 메모리를 측정하고, 필요할 때 인덱스나 Web Worker 도입을 판단합니다.

콘텐츠 도구 쪽이 재미있다면 Markdown AST와 스키마 검증으로 이어 가세요. 원고의 자유도를 늘릴수록 줄 단위 규칙은 복잡해집니다. 공통 AST나 중간 JSON을 두면 출력별 파서 중복을 줄일 수 있지만, 생성 단계와 데이터 파일을 관리하는 비용이 추가됩니다.

변경 추적 쪽에서는 tools/updates.mjs의 grams(), dice(), step()이 흥미롭습니다. 제목이 같으면 먼저 연결하고, 남은 항목은 인접 두 글자의 집합 유사도로 대응시킵니다. 후보 기준은 0.5 이상이며 본문 유사도에는 0.9 가중치를 줍니다. 영구 ID가 없는 텍스트에서 변경을 추정하는 휴리스틱의 장단점을 배울 수 있습니다.

프레임워크를 추가하기 전에 현재 데이터 흐름을 설명하고 측정할 수 있으면, 다음 기술을 고를 이유도 분명해집니다. 이 저장소는 브라우저 기본 API와 작은 제작 도구가 어디까지 해낼 수 있는지 확인하는 출발점입니다.

10핵심 키워드 사전

11참고 링크

11-1. 공식 저장소와 핵심 구현

• 공식 저장소 · 공식 검색 웹페이지 · 전자책 고정 릴리스
• README: 사용법·근거 등급·라이선스 범위
• index.html: 원고 파싱·검색·상태·렌더링 · selfcheck.html: 답안 저장·질문 조건
• 공통 원고 읽기와 분류 규칙 · 긴 문장·출처 분리 · ZIP 구현
• EPUB 빌더 · PDF 빌더 · 오프라인 HTML 빌더 · Anki 빌더
• 전자책 CI · 정기 링크 검사 CI · 변경 추적
• 분리 규칙 동등성 검사 · 자기 점검 회귀 검사 · AI 도구용 원고 활용 지침

11-2. 관련 기술 공식 문서

• GitHub Pages: 저장소의 HTML·CSS·JavaScript를 전달하는 정적 호스팅 개념
• Intersection Observer API: 요소와 화면의 교차 상태를 관찰하는 방법
• Marked: 렌더러·토크나이저 확장 지점
• Node.js 22.13.0 SQLite API: 이 프로젝트의 Anki 제작 도구와 연결되는 버전 문서
• W3C EPUB 3.3 · Pandoc 사용 설명서 · Typst 레퍼런스: 전자책 포맷·문서 변환·조판을 각각 학습
• Anki 내보내기 문서: 카드 패키지와 복습 데이터의 관계를 이해하는 출발점

11-3. 현재 상태 (2026-10-23 확인)