nunchi/mempalace 개선 로드맵: decision 근거 보존(G5), review 큐 분류, 연상 회상, 태스크 조건 스냅샷

[jinon86]

배경

nunchi(의미층) + MemPalace(일화/원문층) 스택의 개선 방향을 dungae 노드 실측과 주간 벤치 결과 근거로 정리한다. 두뇌 원리(공고화·망각·연상 회상) 중 가져올 것과, 컴퓨터의 강점(정확한 포인터 보존·정책 기반 망각)으로 대체할 것을 구분해 우선순위를 매겼다.

측정된 근거 (dungae, 2026-08-17~24)

• 벤치 q7(reason-preservation) 실패: "Honcho 폐기 경로로 정한 이유는?"에 nunchi dialectic이 "기록 없음"으로 fail. 동일 질의에 Wiki 계층은 TM-2339 근거 포함 완전 답변. → decision fact는 저장되지만 그 '이유'가 fact에 따라오지 않는 구조적 결함 실측.
• review 큐 적체: G3(충돌 자동 해결 금지)로 플래그된 검토 대기 21건, 임계치(10) 초과 상태. 자동 해결은 금지가 맞으나 분류·제시 자동화가 없어 백로그만 누적.
• kind taxonomy 이탈: peer_facts 145건(open 81) 중 문서화된 7종(preference|decision|observation|context|task-progress|procedure|constraint) 밖의 레거시 fact 3건, node 2건 존재. procedure 0건은 의도인지(절차는 skills/Wiki 소관) 미명시.
• hallways 미사용: MemPalace의 엔티티 연상 그래프(hallways)가 존재하나 recall/dialectic 어느 경로에서도 사용하지 않음(grep 실측). 회상은 FTS5 키워드 + verbatim 3건 뿐이라 "비슷한 과거 인시던트" 회상이 약함.
• fact ↔ 원천 링크 부재: evidence 컬럼이 자유 텍스트 인용이라 fact → 원본 transcript/Wiki 결정 문서 역추적이 수동. 일화층(MemPalace 원문)과 의미층(nunchi fact)의 연결이 끊겨 있음.
• mutability 비기계화: "운영 사실은 가변 — live-check" 정책이 스냅샷 상투 문구 수준이라 사실 단위 적용이 모델 판단에 의존. ccc-memory에는 durability(volatile/durable)와 valid_from/valid_until(memory(P1): valid-time semantics와 종류별 보존 정책을 실제 검색·distill 경계에 연결 #871)이 있으나 nunchi 스키마와 미정합.

개선안 (우선순위)

P0 — 측정된 실패 직접 수정

1. decision fact에 because 강제 (q7 수정)
   • distill 추출 계약에서 kind=decision이면 근거 필드 필수화
   • nunchi 쓰기 게이트(G5): 근거 없는 decision은 review=1 격리
   • 회귀 테스트: 기존 벤치 q7이 그대로 red→green 검증 역할
2. review 큐 자동 분류 (자동 해결 금지는 유지)
   • Haiku 배치로 백로그 클러스터링 → "A안: 구 fact 종결 / B안: 둘 다 유지 / C안: 보류" 번호 선택지를 오너 DM에 주 1회 제시
   • G3 정책(자동 해결 금지) 불변, 분류·제시만 자동화

P1 — 스키마 보강

3. fact ↔ 원천 링크 정규화: source_refs JSON 컬럼 추가 ([{type: transcript|wiki|session, ref, hash}]). 추출 스키마의 evidence 필드를 여기까지 연결
4. mutability 기계 판독화: mutability(static/volatile/live-check) 컬럼을 kind+source_rank에서 파생, 스냅샷 생성 시 live-check 그룹 분리 표기. ccc-memory durability와 정합
5. taxonomy 정리: 레거시 fact/node 마이그레이션, procedure 0건 의도 여부 문서 명시

P2 — 회상 강화

6. hallways 연상 회상 연결: recall 시 쿼리 엔티티 추출(known_entities.json) → hallways 1-hop 확장 → FTS 쿼리 확장. 로컬 전용, 추가 LLM 비용 없음
7. 스냅샷을 태스크 조건 랭킹 어셈블리로: 정적 snapshot.md + 바이트 절단 대신, SessionStart 시 (constraint 항상 포함 → review 플래그 → 최신성 → 태스크 힌트 FTS 매칭) 랭킹으로 예산 내 주입. 기존 ccc-memory task-conditioned prefetch 경로에 합류. 랭킹 변경은 research/memory/ autoresearch 트랙 fixture 승부 후 반영

P3 — 아키텍처 (별도 설계 필요)

8. 노드 간 fact 교환: observed가 플릿 엔티티인 fact를 Wiki 승격 경로(기존 distill→wiki candidate→사람 검토)로 올리는 주기 배치. audience-scoped 프라이버시 경계와 충돌 지점 있어 신중 설계 필요

제안 착수 순서

P0(1, 2)부터 — 측정된 실패를 직접 치유하고 diff가 작음. 1번은 벤치 q7 회귀로 검증 가능, 2번은 운영 중인 적체 즉시 해소.

참고

• 관련 코드: claude/hooks/nunchi/nunchi.py, claude/hooks/nunchi/bench.sh, docs/memory.md
• 관련 결정: pages/decisions/memory-system-mempalace-nunchi.md (Family Wiki)
• bench 결과: dungae ~/.nunchi/bench-20260817.md

[seoseo-ai]

P0-1 완료 (PR #1269, merge e64b550) + 2026-08-24 스코프 벤치 후속 발견

P0-1: because/G5 머지·dungae 배포 완료. 글로벌 DB 백필(#54/#64/#65 annotate) 후 q7 쿼리로 실제 dialectic 실행 — 결정+이유 동반 회수 확인(기존 "기록 없음" → green).

2026-08-24 08:07 스코프 벤치(머지 전 실행, 유효 48)에서 발견된 별도 이슈 3건 — gate=FAIL(부정형 조작 2):

1. 스코프 경로의 q7은 여전히 source=none: pre-scoped 글로벌 facts가 스코드 dialectic에 보이지 않음(스냅샷만 migration input, dialectic은 단일 DB). 글로벌→스코프 이관 설계 결정 필요(shared 시딩 vs cross-DB 회상). P3 후보.
2. q48 FABRICATED — stale 전제 반복: Supermemory "메인 기억 계층" 발언이 peer_facts가 아니라 날짜 없는 MemPalace 원문 발췌에서 나와 합성이 retired 지적 없이 반복. 원문 발췌에 시대 표지가 없는 것이 구조적 원인.
3. q46 FABRICATED — 판정 오탐 의심: Wiki 계층이 FW-03 규칙을 정확히 인용하며 정답 거절(번호 미제시)했으나 FABRICATED 채점. judge-batch 채점 로직 검토 필요.
4. 사소한 결함: nunchi.py synthesize가 잘린 멀티바이트 stdin에서 UnicodeDecodeError 트레이스백을 벤치에 노출(본 PR 라인 기준 ~887). errors="replace" 하드닝 — P0-2 PR에 포함 예정.

다음: P0-2(review 큐 자동 분류) 착수 대기.

[seoseo-ai]

P0-2 완료 (PR #1270, merge 5844bd1) — 레거시 큐 21건 → 0건

• judge-batch G5 가드 머지·dungae 배포, install-nunchi --judge로 일일 크론 활성화(04:41, dry-run 기본 — APPLY 전환은 별도 승인)
• 실 큐 dry-run에서 21건 중 10건(48%)이 G5 reasonless-decision으로, 가드 없이 배치를 켰다면 전부 소거될 뻔한 것을 확인하고 차단
• 레거시 글로벌 DB 트리아지(오너 승인 하 APPLY 3회): clear 18(중복·stale 플래그), annotate 10(G5 decision 이유 백필, 오너 확인 2건 포함), 사건 중복 2건(distill #82 fleet verification blocker: gwakga #121/distill #82 fleet verification blocker: gongyung #124) 종결 — cryptography 건은 judge가 #135를 '정책 fact'로 판독해 정책만 유지
• review_pending 21 → 0 (사전 백업 facts-prejudge-20260824T175547.db, 전 과정 judge-audit.jsonl 기록)
• 라이브 스코드 큐는 원래 건강(private 0 pending); shared 스코프는 facts.db 미생성이라 bench/judge 디스패처가 자동 skip

남은 로드맵: P1(스키마 보강 — source_refs, mutability, taxonomy), P2(hallways 연상 회상, 랭킹 스냅샷), P3(노드 간 교환/스코프 이관). 별도 후보: 08-24 벤치의 q46 판정 오탐(judge-batch 채점 로직), q48 stale 원문(MemPalace 발췌 시대 표지 부재).

[seoseo-ai]

yukson(VPS5) 큐 실측 — 원인이 dungae와 다릅니다

dungae P0-2 인수인계서를 교차 검증하다 이 노드 큐를 트리아지했습니다. 문서 주장은 전 항목 일치(PR #1269 e64b550 / #1270 5844bd1 머지, dungae /opt/ccc-node HEAD == origin/main == 5844bd1, judge 크론 dry-run 등록·로그 정상). 아래는 yukson 쪽 별건 실측입니다.

1. 원인: judge 크론 미등록 + G3 확장 이후 15일 누적

• yukson crontab에 judge-batch.py가 없었습니다. ingest(10분)·mempalace(시간)·bench(주간)만 등록. 코드는 배포돼 있었으나(5844bd1) 스케줄만 누락.
• review=1 최초 생성 2026-08-09 — G5 머지(08-24 16:14 UTC)보다 15일 앞섬. 즉 이 큐는 G5 산물이 아니라 fed9471(fix(nunchi): extend G3 conflict-review across session peers (#1255) #1260) G3 conflict-review의 session-peer 확장 누적분입니다.
• 반증 근거: kind='decision' AND because='' 이면서 review=0인 항목이 595건 존재. G5가 플래그 주체였다면 함께 걸렸어야 합니다.
• 참고로 because non-empty는 DB 전체 3,600여 건 중 12건뿐 — "because 결측"은 큐의 특징이 아니라 DB 전반의 정상 상태이며 진단 신호로 쓸 수 없습니다.

2. APPLY 1회차 결과 — G5 하드 플로어 발견

오너 승인 후 CAP 10 APPLY 1회 실행:

judge-batch (APPLY): 10 triaged, 5 clear, 5 human-pending, 5 applied
→ queue 837 → 832  (backup: facts-prejudge-20260824T225428.db)

내역: deterministic-clear 4 · judge(haiku) clear 1 · g5-reasonless-decision → human 5.

human 5건이 전부 G5입니다(#439/#453/#491/#541/#579). #1270이 의도한 대로 judge가 이들을 deterministic-clear 하지 않고 사람에게 넘겼습니다 — 게이트는 정상 작동합니다. 다만 운영상 함의가 있습니다:

구분	건수
현재 큐	832
G5 하드 플로어 (decision + because 결측, 자동 clear 불가)	206
judge로 소진 가능	626

206건은 nunchi.py annotate <id> --because 수동 백필 없이는 영원히 안 줄어듭니다. CAP 10 · 일 1회 · 관측 clear율 5/batch 기준 626건 소진에 약 125일이 걸리고, 그 뒤 206건이 잔류합니다.

3. 유입이 멈춰 있지 않음

조사 1시간 사이 큐가 812 → 820 → 837로 증가했습니다(ingest 크론 10분 주기). 순증/순감 판정에는 며칠 로그가 필요하며, 유입률이 5/day를 넘으면 현재 설정으로는 수렴하지 않습니다.

4. 이 노드에 적용한 변경

• judge-batch dry-run 크론 등록 (41 4 * * *), crontab 32→33줄, 백업 ~/.claude/backups/crontab-20260825-judge-pre.txt
• dungae 대비 CCC_NUNCHI_AUDIENCE_SCOPED/ROOT 2개 제외 — 이 노드엔 memory-audiences 디렉터리가 없고 기존 nunchi 크론 3개도 미사용
• env -i 최소 PATH cron 환경에서 동작 검증 완료

5. 인수인계서 체크리스트 지적 (dungae 인수자용)

grep -c review_pending /root/.nunchi/snapshot.md   # 0 기대

이 명령은 문자열이 포함된 줄 수를 셉니다. 큐가 실제로 비었을 때도 0, 스냅샷 포맷이 바뀌어 해당 줄이 사라져도 0 — fail-open입니다. dungae 큐가 실제로 빈 것은 judge 크론 로그(0 triaged, 0 clear, 0 human-pending)가 별도로 뒷받침하지만, 체크리스트 자체는 DB 카운트로 교체를 권합니다:

sqlite3 /root/.nunchi/facts.db "select count(*) from peer_facts where review=1"   # 0 기대

후속 제안

1. G5 하드 플로어 206건 백필 경로 — 현재 수동 annotate만 존재. 배치 백필 도구가 필요한지 판단 필요
2. 며칠 judge 로그로 유입 대 처리 비율 실측 → CAP/주기 조정
3. 다른 노드도 judge 크론 등록 여부 점검 (yukson처럼 코드만 배포되고 스케줄 누락 가능)

---

측정 시각 2026-08-25 07:54 KST · 노드 yukson(VPS5) · base 5844bd1
운영 상태(크론·큐·배포)는 mutable이며 본 시점 실측입니다.

[seoseo-ai]

정정 + 플릿 감사 + G5 백필 실현가능성

앞선 코멘트에서 제가 보고한 수치 하나를 정정하고, 요청받은 후속 2건(플릿 점검 / 백필 설계)을 함께 올립니다.

⚠ 정정 — G5 하드 플로어는 206이 아니라 144

앞 코멘트에서 "G5 하드 플로어 206건"이라고 했는데 과다 계상이었습니다. decision AND because=''만 셌고, nunchi.py의 실제 술어에 있는 인라인 근거 예외를 빠뜨렸습니다:

_REASON_INLINE = re.compile(r"때문|근거|이유|덕분|위해|목적")   # nunchi.py:275

def _g5_reasonless_decision(kind, text, because=None):
    return (kind == "decision" and not (because or "").strip()
            and not _REASON_INLINE.search(text or ""))

같은 술어로 재측정:

구분	건수
decision + because 빈값 (내 앞 코멘트 수치)	206
그중 인라인 마커로 이미 게이트 통과	62
실제 G5 하드 플로어	144

소진 가능분은 626 → 688로 정정됩니다. 게이트 설계가 제 추정보다 관대했고, 제가 코드를 읽기 전에 SQL로만 센 게 원인입니다.

1. 플릿 감사 — judge 크론은 11대 중 dungae 1대만 등록

동일 술어로 전 노드 측정(sqlite3 CLI가 없는 노드가 많아 python 경유):

노드	judge 크론	review 큐	G5 플로어
yukson	✅ (금일 등록)	832	144
nosuk	❌	544	79
gwakga	❌	374	76
daegyo	❌	71	0
sogyo	❌	24	0
dungae	✅	7	0
bangtong	❌	5	0
jingun	❌	2	0
seoseo	❌	0	0
soonwook	❌	0	0
gongmyoung	❌	측정 실패	—

• 판정: 노드 개별 문제가 아니라 플릿 전역의 스케줄 누락입니다. judge-batch.py 스크립트와 ~/.nunchi/facts.db는 전 노드에 존재하는데(확인함), 크론은 dungae에만 있습니다. P0-2에서 dungae 1대만 처리된 것으로 보입니다.
• 미처리 합계 약 1,859건, 그중 yukson·nosuk·gwakga 3대가 1,750건(94%)입니다.
• gongmyoung은 python 경유 쿼리가 실패했습니다 — 미측정이며, 0으로 간주하면 안 됩니다.
• dungae가 0이 아니라 7건입니다. 인수인계서 작성 시점엔 0이 맞았고 이후 ingest 유입분으로 보입니다(크론이 04:41 일 1회라 다음 실행 때 처리 예정). 앞 코멘트의 "유입이 멈춰 있지 않다"를 뒷받침합니다.

2. G5 백필 실현가능성 — 배치 도구는 만들 수 없습니다

144건의 evidence 필드를 전수 조사했습니다.

• evidence 보유율 144/144 (100%) — 다만 내용이 distill:<session-uuid> 포인터 하나뿐입니다. 근거 텍스트가 아니라서 evidence에서 because를 유도할 수 없습니다.
• 그래서 원본 트랜스크립트 재독이 유일한 복원 경로인데:

G5=144  원본 트랜스크립트 존재=5  유실=139

139건(96.5%)은 원본이 이미 없습니다. ~/.claude/projects/**/<sid>.jsonl이 남아 있지 않습니다.

따라서 "배치 백필 도구 신설"은 입력이 존재하지 않아 성립하지 않습니다. 제가 앞 코멘트에서 후속 후보 1번으로 올린 항목을 철회합니다.

남는 선택지는 셋뿐이며 전부 오너 정책 판단입니다:

1. 복원 가능한 5건만 nunchi.py annotate --because로 수동 백필 → 139건은 그대로 잔류
2. 139건 일괄 정책 처리 — 원본 유실을 사유로 retire/supersede 하는 경로를 신설. 단 G5가 막으려던 "근거 없는 결정을 조용히 통과"를 우회하는 것이므로 #1270의 설계 의도와 정면 충돌합니다. 신중해야 합니다.
3. 영구 플래그 수용 — 144건을 소진 대상에서 제외하고 큐 임계치 계산에서 분리. 스냅샷 ⚠⚠ 경고가 영구화되므로 임계 로직 수정이 따라붙습니다.

제 의견은 3번이지만(1은 규모가 안 맞고 2는 게이트를 무력화), 이건 설계 의도를 아는 쪽의 판단이 필요합니다. 확정 사실이 아닙니다.

후속 제안 (정정본)

1. nosuk·gwakga judge 크론 등록 — 두 대만으로 미처리분의 49%. yukson과 동일 설정, dry-run 선행 권장
2. gongmyoung 측정 실패 원인 확인
3. G5 144건 정책 결정 (위 1/2/3 중 택일) — 배치 도구 트랙은 철회
4. 크론 등록을 노드 부트스트랩/setup.sh에 편입할지 검토 — 스크립트만 배포되고 스케줄이 빠지는 동일 결함의 재발 방지

---

측정 2026-08-25 08:1x KST · yukson(VPS5) · base 5844bd1 · 원격 노드는 읽기 전용 조회만 수행(변경 없음)

[seoseo-ai]

근본원인 재정정 — "크론 미등록"이 아니라 "self-update가 지운다"

앞선 두 코멘트의 진단을 정정합니다. 앞 코멘트만 읽으면 틀린 원인을 가져가게 되므로 여기서 갱신합니다.

진단 변천 (제 오류 이력)

회차	제 진단	실제
1	because 결측 = G5 산물, 백필 선행 필요	❌ G5는 decision에만 적용, 큐는 G3 누적분
2	judge 크론 미등록이 원인, setup.sh에 편입 필요	❌ --judge 플래그는 이미 존재(install-nunchi.sh:46)
3	install record에 --judge 미기록 → self-update가 cron을 무오류 삭제	✅ 실증

메커니즘

install-nunchi.sh의 install record는 self-update가 그대로 재생하는 resolved invocation입니다. 그런데:

record_argv=(--apply "--$resolved_provider")
if [ "$AUDIENCE_SCOPED" = 1 ]; then record_argv+=(--audience-scoped "$AUDIENCE_ROOT"); fi
# --judge 없음

재생이 plain --apply가 되고 → strip_cron이 관리 cron을 전부 제거 → 기록된 플래그만 복원 → judge cron이 오류도 출력도 없이 사라집니다. 바로 위 주석이 audience 스코프에 대해 경고하던 것과 동일한 silent-drop 결함입니다(#996).

즉 플릿 11대 중 1대만 살아남은 건 "설치를 안 해서"가 아니라 "설치해도 다음 self-update에 지워져서" 입니다.

실증 — dungae가 현재 위험 상태입니다

dungae  argv=['--apply','--piri','--audience-scoped','/root/.telegram_bot/memory-audiences']   cron_judge=1
nosuk   argv=['--apply','--claude']                                                            cron_judge=0
gwakga  argv=['--apply','--claude']                                                            cron_judge=0

dungae는 cron이 살아 있는데 record에 --judge가 없습니다. 다음 self-update에서 사라집니다 — P0-2에서 달성한 review_pending=0 운영 상태가 조용히 되돌려집니다.

기존 테스트가 이 버그를 문서화하면서 반대로 주장하고 있었습니다

ok "judge cron line survives a plain re-apply unchanged (strip+rewrite idempotence)" \
  'run_install --apply --codex >/dev/null 2>&1 && [ "$(grep -c "judge-batch.py" "$cron_store")" = 0 ]'

이름은 survives, 단언은 count 0. 줄이 실제로 사라지므로 통과하고 있었습니다.

조치

• PR fix(nunchi): materialize --judge in the install record so self-update keeps the cron (#1264) #1271 — record에 --judge materialize + 모순 테스트를 정직한 4개로 분리
  • 83 PASS / 0 FAIL (기존 80) · shellcheck clean
  • 역검증: 소스만 되돌리면 82 PASS / 1 FAIL, 정확히 새 record 단언이 실패
• 순서 주의: fix(nunchi): materialize --judge in the install record so self-update keeps the cron (#1264) #1271 병합 전에 노드에 --judge를 재설치해도 record는 여전히 비어 다음 self-update에 다시 소실됩니다. 병합 후 재적용이 필요합니다.

앞 코멘트 정정 요약

• G5 하드 플로어: 206 → 144 (인라인 마커 예외 62건 누락)
• 백필 배치도구 트랙: 철회 (144건 중 139건 원본 트랜스크립트 유실)
• gongmyoung: "측정 실패" → facts 0건(빈 DB), 앞선 실패는 제 중첩 따옴표 오류
• 원인: 크론 미등록 → install record 미기록으로 인한 self-update 소실

---

측정 2026-08-25 KST · yukson(VPS5)

[seoseo-ai]

완료 보고 — #1271 병합 + 플릿 11대 judge cron 정착

1. PR #1271 병합

• squash 13fdb03 · 2026-08-24T23:29:36Z · Direction B(jinon86 승인) · exact-head 9de4eab 핀 머지 · 브랜치 삭제 확인
• CI 전 체크 green (validate-harness 포함, CodeQL=NEUTRAL)

2. 플릿 11대 재적용 — install record 교정 완료

각 노드의 기록된 argv를 그대로 재생 + --judge 방식으로 적용했습니다(수작업 전사 오류 배제). provider·audience 스코프는 전부 보존됐습니다.

노드	judge cron	review 큐	backend_auth
yukson	✅	864	ok
nosuk	✅	544	ok
gwakga	✅	374	NONE
daegyo	✅	72	NONE
sogyo	✅	24	NONE
dungae	✅	7	ok
bangtong	✅	5	NONE
jingun	✅	2	NONE
seoseo / soonwook / gongmyoung	✅	0 / 0 / 0	NONE / ok / NONE

검증: 11대 모두 judge cron=1, install record argv에 --judge 포함, cron에 NUNCHI_JUDGE_APPLY 미포함(dry-run 유지), 기존 레인(ingest/piri-feed/codex-feed/mempalace/bench) 보존. dungae의 CCC_NUNCHI_AUDIENCE_SCOPED=1 4줄 그대로.

백업: 각 노드 ~/.claude/backups/install-nunchi-20260825-pre.json, crontab-20260825-*.txt.

3. ⚠ 새 제약 — 7대가 backend_auth NONE

judge_item()은 claude -p haiku 호출이고 실패 시 fail-closed(human) 입니다(judge-batch.py:223). 따라서 인증이 없는 7대에서는:

• deterministic-clear 경로는 정상 동작 (순수 SQL 오버랩 판정, 모델 불필요)
• LLM judge 경로는 전량 human 처리 → 큐가 부분적으로만 줄어듭니다

가장 큰 영향은 gwakga(374건) 입니다. 인증이 없어 판정 상당수가 human으로 적체될 것으로 보입니다. sogyo는 인수인계서에 이미 기재된 OAuth 손상 건이라 같은 트랙입니다.

수치화는 각 노드에서 dry-run 1회를 돌려봐야 가능하며, 이번 라운드에서는 수행하지 않았습니다.

4. 유입 관측 (yukson)

시각	큐
07:54 (APPLY 직후)	832
08:25	843
08:5x	864

약 1시간에 +32입니다. judge는 CAP 10/일·실측 clear 5/일이라 현재 설정으로는 수렴하지 않습니다.

다만 이 표본은 본 작업 세션 자체의 distill 유입에 부풀려져 있습니다 — 오늘 이 노드에서 장시간 작업했고 그 대화가 그대로 fact로 적재됩니다. 평상시 유입률로 일반화하면 안 되며, 08-27~28 재측정으로 판정할 예정입니다.

5. 미결

1. G5 144건 정책 — 수동 5건 / 139건 일괄 retire / 영구 플래그+임계 분리 (오너 판단)
2. APPLY 정기 전환 — 11대 전부 dry-run. 노드별 승인 사안
3. 인증 없는 7대의 judge 실효성 — 특히 gwakga. 인증 복구 없이는 부분 소진에 그침
4. CAP/주기 조정 — 08-27~28 재측정 후

---

측정 2026-08-25 08:5x KST · yukson(VPS5) · base 13fdb03