콘텐츠로 이동

Maintenance — 수록·검증·갱신 규칙

최종 갱신: 2026-09 · owner: Youngjin · volatility: 중간

L0 TL;DR: 수록할 가치, 출시 상태, 근거 수준, 사용 범위, 지원 주체를 분리한다. 자동화는 기록의 누락·불일치를 검사하며 사실 확인과 고객 현장 승인은 사람이 책임진다.

포함 기준 (THE FILTER)

기존 ‘4개 중 2개’는 주제 관련성을 찾는 참고 신호로만 사용한다: 고객 수요, AWS 연결 가능성, 출시 상태, 현장 사례. AWS 매핑과 로드맵만으로 검증을 통과하지 않는다.

본문 수록에는 모두 필요하다: (1) 해결할 고객 문제 또는 R&D 질문, (2) 정확한 1차 출처·확인일·적용 버전, (3) 근거와 한계·허용 사용 범위, (4) 소유자와 실행 가능한 다음 액션. 수치에는 측정 조건·표본·단위를 붙인다. 원문 확인조차 없는 항목은 Radar에 유지한다.

연구 항목은 가설 검증용 R&D 안내에 포함할 수 있지만 고객 운영 성능으로 제안하지 않는다. 운영 확대 권고는 파일럿 카드와 현장 게이트의 근거가 추가로 필요하다.

성숙도·출처·사용 범위

차원 표시 해석
출시 GA / Preview / Research / 해당 없음 제품별 상태. 원리·규제·알고리즘에 GA를 붙이지 않음
근거 벤더 발표 / 원문 대조 / 재현 실험 / 고객 현장 검증 상위 단계로 자동 추론하지 않음
용도 학습·R&D / PoC 검토 / 운영 확대 검토 검증한 범위와 제한을 함께 기록
지원 AWS 서비스 / 모델 공급자 / 파트너·SI / 샘플 유지보수자 각자의 지원 계약과 현장 책임을 분리

[1] 공식 문서·논문, [2] 기록이 있는 재현 실험, [3] 벤더 발표, [4] 미검증은 출처 유형이다. 순위나 AWS 공식 승인 표시가 아니다. [2]에는 실행자·버전·환경·로그·측정 조건을 붙인다. 기존 [2]에 로그가 없으면 재현 근거로 인용하지 않는다. ‘발표’를 GA로, ‘직접 돌려봄’을 프로덕션 검증으로 바꾸지 않는다.

필수 메타데이터와 신선도

페이지는 _owner: 이름 · updated: YYYY-MM · volatility: 높음/중간/낮음_를 유지한다. 이는 페이지 편집·검토 범위의 날짜다. 일부 수정으로 다른 주장의 확인일을 갱신하지 않는다. 페이지 자동 배지는 높음 1개월/중간 3개월/낮음 6개월 초과를 알린다.

갱신 경로 선언. 메타 줄은 책임자만 말한다. nav의 모든 페이지는 저장소 루트 refresh.yml에 무엇이 갱신을 촉발하고 누가 하는가를 선언한다 — mode(routine 스케줄 자동화 / owner 사람 주기 검토 / event 특정 변경 시), by, trigger. 외부 소스를 따라가는 페이지(예: 새 소식 ← AWS Physical AI 블로그 RSS)는 source를 선언하고, 의도적으로 싣지 않는 글은 exclude에 사유와 함께 남긴다. 선언 누락은 배포를 막고(check_refresh_paths.py), GitHub Actions가 매일 실제 소스와 대조해 발행 3일이 지나도 미반영인 글이나 루틴 정지를 source-drift 이슈로 알린다(check_source_drift.py). 배지는 날짜를, 감시는 소스를 본다 — 2026-10 새 소식 3주 누락이 이 규칙의 계기다. 기술 필러처럼 사람이 검토하는 owner 페이지는 review_alert: true를 선언해, 메타 updated가 volatility 기한을 넘으면 배지에 그치지 않고 같은 source-drift 이슈로 올린다. 커밋 날짜가 아니라 owner가 적은 검토월을 보므로 구조 변경·번역 커밋은 검토로 치지 않는다 — 2026-11 필러 2개월 무검토가 계기다.

고객 판단에 영향을 주는 주장에는 근거 기록을 추가한다. checked_on은 실제 원문 대조일, review_after_days는 주장별 검토 주기이며 pages는 영향을 받는 요약·필러를 가리킨다. 기록을 추가하지 않은 기존 주장은 미이관 상태로 남긴다.

표준 템플릿

항목 / 해결할 고객 문제:
출시 상태 / 근거 수준 / 권장 용도 / 지원 주체:
L0: 무엇이고 어떤 조건에서 사용하는가:
대안 / AWS 매핑과 필요한 조건:
근거 ID / 정확한 출처 URL / 버전 / 확인일:
실험이면: 환경·표본·단위·로그 / 재현자:
적용 한계 / 비용·성공·중단 기준:
다음 액션 / 실행 자산 / 운영 인계:
owner / 사람 검토자 또는 대기:

L0를 짧게 유지하고 상세 자료는 링크·접힌 블록에 둔다. 어려운 용어는 첫 등장에 [^용어] 각주, 끝의 <!-- 용어 각주 -->에 1~2문장 설명을 넣는다. 번역에서 각주 ID·URL·구조를 유지한다. 임원 요약은 필러의 조건과 한계를 삭제하지 않는다. 공개 문서에 내부 고객 정보·영업 전략을 넣지 않는다.

playbook 승격 파이프라인

  1. Radar 또는 후보 폼에 주제·1차 출처·고객 문제를 기록한다.
  2. 소유자가 수록 필수 조건과 분야별 검토자를 확인한다. 자동 스캔만으로 승격하지 않는다.
  3. 근거·버전·날짜·측정 조건을 대조하고, R&D/PoC/현장 검증 범위를 명시한다.
  4. 한국어 원문, 영향을 받는 요약, en/zh/ja를 함께 갱신한다.
  5. 근거 표시 생성 → 번역 해시 동기화 → 검사 → 리뷰 후 반영한다.

역할과 미완료 검토

역할 책임
소유자 Youngjin 검토 배정·수록 결정·갱신 관리
분야별 사람 검토자 — 배정 대기 라이선스 / AWS 서비스·리전 / 로봇·안전 / 실험 재현 검토
자동화·대조 도구 후보 수집, 원문 대조 보조, 메타·링크·동기화 검사

단일 소유자 지정으로 검토 병목이 해소되지는 않는다. 분야별 담당자는 실제 수락 후 기록한다. 자동 원문 대조와 사람 승인을 구분하고 미확인 담당자를 만들어 넣지 않는다.

검사와 그 한계

python3 scripts/check_evidence.py
python3 scripts/check_translation_sync.py
python3 scripts/check_nav_index_sync.py
python3 scripts/check_refresh_paths.py
python3 scripts/check_staleness.py --check
mkdocs build --strict

근거 구조·표시 불일치, nav 불일치, 갱신 경로 미선언, 메타 누락, 문서 내부 링크/앵커 오류는 배포를 차단한다. 주장 검토 기한·사람 검토 대기는 보고하고, 번역 표류도 현재 CI에서는 경고다. 커밋 전 번역 불일치 0을 별도로 확인한다. 빌드는 외부 링크 접속·주장 사실·번역 의미·로봇 실행을 검증하지 않는다.

➡️ 다음 액션: 근거 기록의 검토 대기 항목을 분야별로 배정하고, 기한이 빠른 항목부터 출처와 영향 페이지를 함께 검토한다.

owner: Youngjin · updated: 2026-09 · volatility: 중간