감사 에이전트가 낸 수치를 그대로 부채 표에 옮겼는데, 저장소에 사실로 박히는
값이라 직접 재현해 확인했다.
architecture 라벨 임계: 19·20자 통과, 21·22자 하드 실패 — 주장대로였다.
lifecycle 캐스케이드: 상태 1개 + 전이 1개 추가에 오류 5건, 그중 손대지 않은
기존 t-reject 관련이 3건. 표에는 4건으로 적혀 있었다.
검증 조건(waiting 레인 col 1)도 함께 적어 다음 사람이 같은 실측을 재현할 수
있게 했다. 캐스케이드가 실재한다는 결론은 그대로다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
용도를 내부 문서로 못박았다. 고객 인수물이 아니므로 납품 품질 기준을 적용하지
않는다 — 감사에서 나온 한글 폰트 미번들과 영어 뷰어 UI 는 archify 한계라 spec
으로는 못 고치는데, 사내 머신에는 한글 폰트가 있으므로 low 로 내렸다. 승격
조건(그 둘이 먼저 blocker)을 PROJECT_MAP 다이어그램 절에 적어 두었다.
그 위에 두 번째 게이트를 올린다. 기존 test_diagram_sync 가 "산출물이 spec 보다
낡았나"를 본다면, test_diagram_facts 는 "spec 이 코드보다 낡았나"를 본다.
그림에는 코드에서 뽑은 상수가 라벨과 카드 문장으로 하드카피돼 있어서,
SCORER_VERSION 을 올리거나 믹스인을 하나 추가하면 코드는 통과하고 그림만
조용히 틀려졌다. CLAUDE.md 가 그 값들을 규칙으로 못박아 두었는데 정작 같은
값을 그린 다이어그램에는 보호가 없었다.
SCORER_VERSION · SCHEMA_VERSION · 믹스인 개수 · app-*.js 개수 · 바디 상한
· 인증 실패 10회/60초 · 프롬프트 12행 상한 · 풀 상한 60/20 · 기본 모델
· 런타임 의존성 3종
"지문 유사도 0.9+ -> 80점" 은 이름 있는 상수가 아니라 risk_scoring 안의 인라인
리터럴이라, import 대신 실제로 채점해서 확인한다. 라벨이 주장하는 값과 스코어러가
내는 값이 같은지를 직접 본다.
차단을 실증했다 — SCORER_VERSION v3->v4 로 3건, MAX_PROMPT_EVIDENCE 12->16 으로
2건이 실패한다. 영향받는 다이어그램 전부에서 잡힌다.
발견 가능성도 정리했다. 감사에서 "3.3MB 산출물이 어떤 문서 색인에도 없다"가
나왔으므로 README 색인에 등재하고, PROJECT_MAP 까지 가지 않아도 되도록
docs/diagrams/README.md 에 직접 수정 금지·재생성 명령·CSP 주의를 두었다.
검증: ruff clean, pytest 619 passed (사실 게이트 +19).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
감사에서 나온 결론은 "그림은 지금 정확하지만 정확함을 지킬 장치가 없다" 였다.
코드 유래 리터럴 18개가 전부 코드와 일치하고 deliver 는 바이트 결정적인데,
드리프트를 막는 게이트·테스트·훅이 0개였고 문서에 적힌 재생성 절차는 그대로는
실행되지 않았다 — `archify` 실행 파일은 PATH 에 없고 실제로는 저장소 밖 전역
스킬을 node 로 불러야 한다. 다음 사람은 첫 명령에서 막혔을 것이다.
scripts/rebuild-diagrams.ps1 validate -> deliver -> visual-check -> manifest
scripts/update_diagram_manifest.py 수신증의 단일 작성자
docs/diagrams/manifest.json spec/html sha256 + generator 버전
tests/test_diagram_sync.py 게이트 14건
게이트는 브라우저도 Node 도 archify 도 없이 돈다. 산출물이 바이트 결정적이라
수신증 대조만으로 충분하고, 그래서 폐쇄망 CI 에서도 돈다. 두 사고 시나리오를
실제로 만들어 차단을 확인했다 — HTML 의 단어 하나를 고치면 html sha 가,
spec 의 태그 하나를 고치면 spec sha 가 어긋나 verify 가 실패한다. 노드 id 가
HTML 에 data-node-id 로 박히므로 의미적 연결도 함께 본다.
git 위생 두 건도 같이 정리했다. *.visual-check.json 이 개발 머신 절대 경로와
크롬 설치 경로를 평문으로 담은 채 미추적·비ignore 상태였다(24개) — 납품
저장소가 removable media 로 건너가는 구조라 한 번 커밋되면 제거가 어렵다.
그리고 15,000줄 생성 HTML 을 텍스트로 머지하려 드는 것을 막았다.
재생성해도 4종 sha256 이 전부 불변이라 바이트 결정성을 다시 확인했다.
감사에서 나온 나머지 부채(한글 폰트 미번들, 영어 뷰어 UI, architecture 좌표
하드코딩, lifecycle 손튜닝 8개소, 콘솔 CSP 비호환)는 PROJECT_MAP 부채 표와
다이어그램 절에 등재했다. 폰트와 UI 는 archify 쪽 한계라 spec 으로는 못 고친다.
검증: ruff clean, pytest 600 passed (게이트 +14).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
아키텍처 · 운영자 심사 워크플로 · 제출물 상태 전이를 신설하고, 기존 증거
데이터 흐름까지 4종의 범례를 한글화했다. 렌더러 기본 범례가 "User UI /
Agent logic / Context-trace" 나 "policy / PII" 처럼 타 도메인 문구였다 —
legend.entries 로 라벨만 바꿨고 종류와 개수는 그대로다.
system-architecture 폐쇄망 경계와 그 밖의 외부 검색 API. 나가는 경로는
store_remote_fetch 하나뿐이고 앞에 호출 게이트가 있다
operator-review-workflow 4레인(제출·자동·심사·차단). 비상 차단이 걸려도
커버리지 부족 표시로 심사가 이어지는 경로 포함
submission-lifecycle 분석 실패와 보류가 종료가 아니라 분석 중으로
돌아오는 두 고리, 판정 후 보존 상태
작성 중 내린 고도 판단 두 개를 남긴다.
아키텍처에서 analyzer/scorer 를 "분석 · 채점" 한 컴포넌트로 합쳤다. 이
고도에서 그 분리는 엣지를 벌지 못하고, store 노드에 엣지 7개가 몰려
통로가 부족해졌다. 채점 내부는 dataflow 다이어그램이 담당한다.
라이프사이클에서 "재분석 요청"을 상태에서 뺐다. decisionStatus 값이 아니라
운영자 액션이고, 보류가 같은 의미를 담아 긴 복귀 엣지를 하나로 줄인다.
검증: 4종 모두 showcase 통과(아티팩트 검사 9/9 · 합성 오류 0 · 경고 0),
visual-check 통과(1440x900 · 2048x1320 각 Light/Dark, 오버플로 0).
html sha256 — dataflow a62f0f5c / architecture f5a4b6e1 /
workflow 402914a3 / lifecycle 62e934a3
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
수집 → 경계 검사 → 정규화·채점 → 영속화 → 소비 5단으로, 9/18 리뷰 수정에서
나온 불변식을 그림으로 고정한다.
제공자별 풀·버킷(RiskScorer v3) · 라운드트립이 원 점수를 재현
(_evidence_payload <-> _domain_evidence_from_ui) · host 는 저장 시 해석하고
복원 시 우선 반환 · 지식DB 지문 매칭이 풀링 밖 유일한 high 승격 경로
작성 중 확인한 사실도 반영했다: 프로덕션 LLM 경로는 영속화된 payload 를
_domain_evidence_from_ui 로 복원해 넣는다(store_operations.py:487). 그래서
프롬프트가 host 를 보는 것은 복원 경로 덕분이다 — analysis/evidence_enrichment.py
의 EvidenceEnricher 는 테스트에서만 쓰인다.
소스는 evidence-dataflow.dataflow.json (archify dataflow v1). 그림을 고치려면
JSON 을 고쳐 재생성한다. 산출물은 자체 완결 HTML 로 외부 요청이 없다.
검증: archify showcase 통과(아티팩트 검사 9/9 · 합성 오류 0 · 경고 0),
visual-check 통과(1440x900 · 2048x1320 각 Light/Dark, 오버플로 0,
최소 투영 텍스트 6.71px >= 6px). html sha256 268f3352 (822,655 B).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
INDEX 에 반증 1건 포함 결과를 기록하고, PROJECT_MAP 부채 표에 "테스트가 로컬
ollama 에 실접속" 항목을 추가했다 — 이번 작업에서 발견했지만 15건 범위 밖이라
수정하지 않았다. 풀 캘리브레이션 부채 행의 v2 표기도 v3(제공자별)로 갱신.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
기능 실효성 평가에서 확정된 판별력 붕괴를 고친다. 신호조합 224개 전수에서
77.7% 가 high, 56% 가 정확히 100점에 붙고 low 는 3.6% 뿐이었다. 큐 기본 정렬이
riskScore 내림차순인데 전건이 100 이면 정렬이 no-op 이므로, 점수가 운영자에게
주는 우선순위 정보가 0비트였다.
동인은 하나가 아니라 둘이었고 둘 다 "같은 사실을 여러 행으로 센다"는 같은
형태다.
라벨 풀 (WEB_ENTITY_MAX_POINTS = 20)
category 없는 raw Vision 웹 엔티티가 이름별 버킷이라 서로 dedup 되지 않고
round(40*conf) 씩 무한 누적됐다. Vision 은 maxResults=10 이라 모든 이미지에
라벨을 붙이므로, 이미지 매칭이 0건이어도 0.8 짜리 라벨 3개면 100/high 였고
웹에 전혀 없는 오리지널 사진이 66/medium 이었다. 모집단 전체에 상수로
존재하는 신호는 판별에 기여할 수 없다. medium 임계(30) 아래로 묶어 라벨이
케이스를 물들일 수는 있어도 밴드를 정하지는 못하게 했다.
category(character/celebrity/work) 가 붙은 엔티티는 풀에서 제외한다 — 그것은
raw 라벨이 아니라 권리 분류이고 엔티티별 +45 를 유지한다. 조사 단계에서
"test_two_distinct_web_entities_stack_into_high_risk 가 이 동작을 고정하므로
함께 개정해야 한다"고 봤으나 틀렸다. 그 테스트는 category 있는 엔티티를
다루므로 두 분기를 가르면 개정 없이 통과한다.
웹 존재 풀 (WEB_PRESENCE_MAX_POINTS = 60)
Vision 응답 1회가 "이 이미지가 웹에 있다"는 하나의 사실을 full / partial /
page / visual 4개 상관된 뷰로 동시에 보고하는데, 스코어러가 이를 독립 신호로
합산해 45+35+35+10 = 125 -> 상한 100 이 됐다. 널리 게시된 평범한 이미지와
명백한 침해물이 같은 100/high 로 수렴한 이유다. high 임계(70) 아래로 묶었다.
원칙: 웹에 존재한다는 사실만으로는 high 가 되지 않는다. high 가 되려면 두
번째 종류의 신호(인물, 지식DB 지문 매칭, 승격된 검색 히트)가 필요하다. 존재
자체는 침해가 아니고 그 판단은 운영자의 몫이다.
측정 (224조합, v1 -> v2)
웹 신호만으로 high 가 되는 조합 2/7 -> 0/7
100점 포화 66.5% -> 51.3%
웹에 없는 오리지널 사진, 라벨만 100/high -> 20/low
이미 안전 확인한 자산(cleared) 100/high -> 20/low
웹 존재 광범위(4개 매치 타입) 100/high -> 60/medium
완전일치 사본 + 식별가능 인물 80/high -> 80/high (불변)
명백한 침해(전 신호) 100/high -> 100/high (불변)
전체 high 비율은 82.6% -> 76.3% 로 크게 안 움직인다. 이 격자는 신호 축을 균등
샘플링하므로(지식DB 강매칭이 1/4) 실제 큐 분포의 대리값이 아니며, 실 DB 6건도
100x4 -> 95x4 로 밴드가 바뀌지 않는다 — 그 4건은 전부 "완전일치 사본 + 인물"
이라 high 가 맞다. 고친 것은 거짓 high 이지 진짜 high 가 아니다.
두 상한은 신호의 구조적 성질에서 나온 값이지 캘리브레이션 결과가 아니다.
판정 30~50건이 쌓이면 decision_stats 교차표로 임계와 함께 재조정해야 한다.
라운드트립 버킷 보존 테스트(test_review_fixes.py)는 신뢰도 1.0 에서 두 엔티티가
모두 캡에 붙어 성질이 가려졌다. 검증 대상은 점수가 아니라 엔티티 이름 버킷이
직렬화를 넘어 살아남는가이므로, 풀 아래(신뢰도 0.2)에서 재작성하고 동일 엔티티
반복이 여전히 1건으로 접히는지도 함께 본다.
테스트 5건 추가. pytest 570 passed(착수 전 565), 린트 클린.
"이 도구가 실제 업무에 도움이 되는가"를 6축으로 조사하고 축마다 결론을
반증시켰다(docs/reviews/2026-08-08-utility-assessment.md). 결론은 "검색·기록
노동은 줄여주나 심사 건수는 못 줄인다"이고, 그 과정에서 실행으로 확정된
P0 결함 4건을 여기서 고친다. 판별력 붕괴(P1)는 별도 작업이다.
폴더 정리가 판정 기록을 지웠다 (sqlite_store.py)
_prune_missing_submission_files 가 원본 파일이 없는 submission 행을 판정
여부와 무관하게 delete 했고, foreign_keys=on 이라 evidence 가 cascade 로
함께 사라졌다. 심사 끝난 이미지를 아카이브로 옮기는 평범한 운영 행위가
승인/반려를 DB 와 내보내기 양쪽에서 지운다. 실증: rejected 판정 후
export 1행 -> 파일 제거 -> submissions 0행 / evidence 0행 / export 0행.
판정된 케이스는 파일이 없어도 보존하고 assetMissing 마커를 남긴다. 마커가
필요한 이유는 이 스윕이 매 리로드마다 돌기 때문이다 — 표시 없이 보존만
하면 같은 감사 이벤트가 리로드마다 쌓여 500행 캡을 먹는다.
비상 차단 스위치가 아무것도 막지 않았다 (store_enrichment.py)
emergency_disable_external_providers 는 DB 의 enabled/operatorDisabled 만
쓰는데 자동 보강 경로가 그 플래그를 아예 읽지 않았다. 게이트가 걸린 곳은
수동 검색뿐이라, 버튼을 눌러도 폴더 리로드·업로드·rerun-enrichment 가
그대로 Naver/Google 로 나갔다. 스텁 어댑터 대조실험에서 CONTROL 5회 /
차단 후 5회로 완전히 동일했다.
_external_calls_blocked(provider_id) 를 신설해 자동 외부 호출 5개 경로에
배선했다: auto naver, auto CSE, rerun Vision, 얼굴 크롭 웹탐지, 시드 배치
(후자는 ExternalApiPolicy(disabled=True) 로 전환).
enabled 가 아니라 operatorDisabled 를 본다. enabled 는 연결성/헬스에도
반응하므로 운영자가 멈추라고 한 적 없는 트래픽까지 죽인다. 얼굴 크롭은
생체 파생물을 전송하므로 상위 게이트에 의존하지 않고 독립 게이트를 건다.
생체 크롭이 보존기간을 넘겨 살아남았다 (store_backup.py)
스냅샷이 face-crops 를 통째로 담는데 프루닝은 나이가 아니라 개수 10개
기준이라, 90일에 파기됐어야 할 크롭이 암호화 없는 zip 안에 남았다. 복구는
더 나빴다 — copyfileobj 로 새로 쓰므로 mtime 이 리셋되고, purge 가 mtime 을
보므로 파기 대상이 복구 직후부터 다시 90일을 살았다.
스냅샷에서 제외하고, 복구 시에도 레거시 아카이브의 크롭을 건너뛴다. 크롭은
원본에서 재분석으로 재생성되므로 손실 비용이 없다.
오프라인 설치 문서가 계약 위반 모델을 지목했다 (offline-install.md)
qwen2.5:0.5b-instruct 반입을 지시했는데, 같은 리포가 이 모델을 55.7초 +
프롬프트 형식 예시 반향(출력 계약 위반)으로 기록해 두고 기본값을 7b 로
고정해 뒀다. 문서대로 반입하면 타깃에서 요약이 조용히 죽는다. 모델명을
정정하고, 반입물 목록에 없던 ollama 바이너리와 GPU 전제를 추가했으며,
"env 를 비우면 LLM 없이 돈다"는 서술을 실측으로 정정했다 — 실제로는
127.0.0.1:11434 로 폴백해 provider 가 enabled=True 로 보고된다.
회귀 테스트 3건 추가. pytest 565 passed(착수 전 562), 린트 클린.
세션 진입 문서가 없어 41.6k 라인 · 70모듈 구조를 매번 재발견하고 있었다.
- CLAUDE.md: 진입점 + 이 프로젝트에만 해당하는 규칙(폐쇄망 의존성 금지,
app-*.js 로드 순서 계약, SCORER_VERSION 갱신 의무, 직렬화 라운드트립 불변식,
LLM 은 실모델로 프로브, cp949 비ASCII 출력 주의)
- docs/PROJECT_MAP.md: 파일·라우트·스키마 위치, app-*.js 로드 순서, 알려진 부채
- README: verify 명령, app-*.js 구조, 인증 스로틀 동작 설명
7/11 리메디에이션 체크리스트를 코드와 대조해 갱신했다. 미체크 항목 중 6건은
이미 수정돼 있었고(naver 멀티페이지 쿼터, #10 Origin/Referer CSRF, env_file
BOM, daily-limit fail-open, __main__ 경로 앵커링, 그리고 Batch 8 전체가
Batch 6 과 중복) 각 줄에 확인 근거를 남겼다. 남은 미체크는 전부 근거가 기재된
명시적 연기다.
