가이드 — 이 Playbook은 어떻게 동작하는가¶

최종 갱신: 2026-08 · owner: Youngjin · volatility: 낮음(프로세스 페이지 — 파이프라인 변경 시에만 갱신) ← index로

L0 TL;DR: 이 사이트는 뉴스 아카이브가 아니라 검증 파이프라인이다. 새로 등장한 기술·논문·발표는 곧바로 본문에 실리지 않는다 — 자동 스캔이 후보를 모으고, 사람이 1차 출처로 검증하고, 4개 중 2개 관문(THE FILTER)을 통과한 것만 본문에 오른다. 실린 뒤에도 신선도를 자동 감시하고, 4개 언어로 동기화되며, 빌드 게이트를 통과해야 배포된다.

한눈에 보는 전과정¶

graph TD
    A1["🤖 일간 자동 스캔<br>(매일 02:00 UTC — arXiv·웹)"] --> R
    A2["💬 SA 제보<br>(승격 파이프라인)"] --> R
    A3[🔍 수동 조사] --> R
    R["Radar 대기열<br>전부 '미검증 [4]' — 고객 제안 사용 금지"] --> V["1차 출처 검증<br>사람 + 검증 에이전트 (공식 발표·논문 원문 대조)"]
    V --> F{"THE FILTER<br>ⓐ production 검증 ⓑ AWS 매핑 ⓒ 실제 문의 ⓓ GA"}
    F -- 2개 이상 충족 --> P["필러 본문 승격<br>(owner가 표준 템플릿으로)"]
    F -- 미달 --> K["Radar에 한 줄 유지<br>(승격 조건 명시)"]
    P --> AFTER[실린 뒤에도]
    AFTER --> M1["⏳ 신선도 자동 감시<br>(volatility별 1/3/6개월 초과 시 배지)"]
    AFTER --> M2["🌐 4개 언어 동기화<br>(ko 원본 → ko_hash → en/zh/ja)"]
    AFTER --> M3["✅ strict 빌드 게이트 (앵커·링크 검증)<br>→ GitHub Pages 자동 배포"]

① 어떻게 만들어졌나¶

이 플레이북은 완결된 스펙 문서(마스터 프롬프트)로부터 생성됐다. 정보 구조(5개 필러 + 의사결정 트리 + Radar + 유지보수 규칙)와 포함 기준이 스펙에 고정되어 있고, 페이지마다 적대적 검증(사실 오류·과장을 찾는 별도 검증 단계)을 거쳤다. 실제로 이 단계에서 버전 오기·라이선스 오류 등이 잡혔다 — "생성했으니 믿는다"가 아니라 "생성한 것도 검증한다"가 원칙이다.

② 무엇이 실리고, 무엇이 걸러지나¶

모든 항목은 THE FILTER를 통과해야 본문에 실린다: ⓐ production 검증 ⓑ AWS 매핑 가능 ⓒ 실제 문의 이력 ⓓ GA(또는 로드맵) — 4개 중 2개 이상. "새로 나왔다", "데모가 인상적이다"는 포함 사유가 아니다. 실린 항목에는 성숙도 라벨(🟢 GA / 🟡 Preview / 🔵 Research / ⚪ Hype)과 출처 등급([1] 공식 문서 ~ [4] 미검증)이 붙는다 — 라벨 읽는 법은 홈에 있다.

③ Radar와 일간 자동 스캔¶

필터를 아직 통과하지 못한 것들은 Radar(대기열)에 한 줄로 존재한다. 매일 02:00 UTC에 자동 스캔이 돌아 최신 논문·뉴스를 Radar의 "최신 스캔 유입" 섹션에 채운다(신규가 없는 날은 갱신 없음). 중요한 것: 자동 유입분은 전부 미검증 [4]로 격리되며, 고객 제안에 쓰면 안 된다. 자동화는 후보를 대기열에 올리는 것까지만 한다.

④ 검증과 승격 — 사람의 몫¶

유입 항목의 1차 출처 확인(공식 발표·논문 원문·라이선스 대조)과 승격 판단은 사람이 한다. 자동 스캔은 그럴듯한 오류(예: 존재하지 않는 제품 세대명)를 만들 수 있어, 검증 없이는 승격되지 않는다. 1차 출처 검증은 owner 혼자가 아니라 여러 명이 나눠 할 수 있다 — 참여자는 승격 이슈와 항목 하단의 검증: 필드에 기록한다. 통과하면 owner가 표준 템플릿으로 해당 필러에 편입하고 Radar에서 제거한다. 전체 절차는 승격 파이프라인 참고.

⑤ 신선도 자동 감시¶

실린 항목도 낡는다. 페이지마다 변동성(volatility) 등급이 있고 — 높음 1개월 / 중간 3개월 / 낮음 6개월 — 갱신 없이 기준을 초과하면 배포 시 해당 페이지(4개 언어 전부)에 "⏳ 검토 필요" 배지가 자동 주입된다. 매일 재배포가 돌므로 푸시가 없어도 배지는 최신 상태를 유지한다. 배지가 보이면 그 페이지는 재검토 대기 중이라는 뜻이다.

⑥ 4개 언어 동기화¶

한국어가 원본이고 영어·중국어·일본어는 파생물이다. 각 번역 파일은 번역 시점의 원본 지문(ko_hash)을 기록하고 있어, 원본이 바뀌면 어느 번역이 뒤처졌는지 자동 감지된다(CI¹ 경고). 용어는 공용 용어집으로 4개 언어에서 일관되게 유지된다. 언어 전환은 페이지 우측 상단 드롭다운.

⑦ 배포 파이프라인¶

main에 푸시되면 CI가 신선도 검사·번역 동기화 검사를 돌리고 strict 빌드(깨진 링크·앵커가 하나라도 있으면 실패)를 통과한 경우에만 GitHub Pages로 배포한다. 즉, 지금 보고 있는 모든 페이지는 이 게이트를 통과한 상태다.

⑧ 검토 실무 가이드 (owner · 검증 담당)¶

페이지 owner나 검증 담당으로 지정되면, 아래가 검토의 전부다. 필요한 것은 저장소 접근 권한 + 이 페이지 10분이다.

언제 — 시스템이 알려준다. 라이브 페이지 상단에 "⏳ 검토 필요" 배지가 뜨면 그 페이지 차례다(변동성별 1/3/6개월 초과 시 자동 부착). 미리 보려면 저장소에서 python3 scripts/check_staleness.py --check 한 줄로 전 페이지 현황이 나온다.

어디서 — 저장소의 한국어 원본. GitHub 저장소를 clone해 docs/<페이지>.md(ko)를 검토한다. 라이브 사이트는 확인용, 편집은 항상 저장소에서.

어떻게 — 5단계:

사실 대조 — 각 항목명에 붙은 공식 출처 바로가기(전수 접속 검증됨)를 열어 버전·라이선스·GA 상태가 여전히 맞는지 1차 출처로 확인.
휘발성 블록 갱신 — 접힌 <details> 블록의 버전·가격·리전 수치만 손대면 되게 설계되어 있다. 본문(안정층)은 원리라 잘 안 바뀐다.
메타 갱신 — 검토를 마치면 updated:를 현재 연월로. 이것이 배지를 끄는 유일한 정당한 방법이다(각주·표기 정리 같은 비내용 작업으로는 올리지 않는다).
4개 언어 동기화 — ko를 고쳤으면 en/zh/ja에 같은 변경을 반영하고 ko_hash를 갱신한다(절차: 저장소 CLAUDE.md, 용어는 i18n/glossary.md).
게이트 후 푸시 — python3 scripts/check_translation_sync.py(비동기 0)와 mkdocs build --strict(exit 0)를 통과해야 커밋한다. main 푸시 → 자동 배포.

언어별로 분담하는 경우 — owner는 페이지당 1명(ko 원본 기준)이고, 언어 분담자는 항목 검증: 필드에 기록되는 검증 담당이다. 규칙 하나만 기억하면 된다: 번역 파일을 직접 고치지 말고 항상 ko 원본부터. ko가 바뀌면 동기화 검사가 뒤처진 번역을 알려주며, 번역 검토자는 그 파일만 용어집에 맞춰 갱신하면 된다.

역할별 안내¶

나는…	이렇게 사용하면 된다
그냥 읽는 사람	홈의 FAQ Top 20 또는 필러로 진입. 라벨(🟢🟡🔵⚪)과 출처 등급(`[1]`~`[4]`)만 알면 신뢰 수준을 바로 읽을 수 있다
항목을 제보하고 싶은 사람	승격 파이프라인으로 제보. THE FILTER 4개 중 몇 개를 충족하는지 함께 적으면 빠르다
owner	일간 자동 유입 검토 → 1차 검증 → 승격/유지 판단. 유지보수 규칙 전체 참고

CI (Continuous Integration) — 커밋·푸시마다 검사와 빌드를 자동 실행하는 파이프라인. 이 저장소에서는 신선도 검사·번역 동기화 검사·strict 빌드가 CI에서 돌며, 전부 통과해야만 배포된다. ↩