LLM WikiAccess-protected knowledge portal

WIKI

2026-W28 Worklog

AI Summary Purpose Tracks development work across repositories for this week. Key points 2026 07 06 PHP/Composer 크롤러 zero row 자가 백필 sweep + changes 커서 하드닝 + ladder 30~39 확장 crawler lib php d968c5c + f210373 , master 푸시 완료 . 계기 hakanispirli/

경로ai/worklog/2026/2026-W28.md
카테고리Worklog
태그#ai-review #airflow #composer #crawler #human-output #php #portfolio #report #security #w28 #worklog

# 2026-W28 Worklog

AI Summary

Purpose:

Key points:

ladder 30~39 확장 (crawler-lib-php d968c5c+f210373, master 푸시 완료). 계기: hakanispirli/parasut-laravel 영구 누락 실측. 피해 2,419건은 배포 첫 실행에서 자동 백필.

지연 import, 4807696 비-누락 예외 ERROR→WARNING; origin/main push 완료, 미배포) + npm @zylem/behaviors 누락 검증(실누락 아님). 재사용 지식: npm _changes 는 CouchDB coalesced feed(패키지=문서 최신 seq 1회, 버전당 X)이나 npm_crawling 이 전체 doc 을 받아 api−db 로 백필 → 피드 gap ≠ 버전 누락. 진짜 누락 = 부분-200(feed-ahead-of-meta)+재publish 없음.

(proof-metric 중심 재구성, spotlight 4장, CSS-only 카탈로그 reveal) + 선택형 PDF 빌더 + 카드 기본 정렬(랩스→개인→대학원) + System Associates 항목 정정(나라장터 조달공고 크롤러 +LLM 선별) + homepage evidence 문구 정정 + public 이력서 recruiter-scan 개선 + FIRM-COV 저자관계 정정 + hero 타이틀 다듬기. (llm-wiki, hw-me/hyunwook.tech)

Relevant when:

Do not read full document unless:

Linked documents:

Work Items

SPM 누락 리포트 21건 검증 (2026-07-06, 조사만 — 수정 없음)

1.0.0 존재하는데 TB_COMP_LIB_SPM_LIST/PRODUCT_SPI/VERSION_SPI 어디에도 없음 (인테이크 미진입). 추가로 universe(11,254) ↔ SPM_LIST(11,589) 전수 diff 결과 같은 부류 총 6건: darktau/reentryguard, firechip/cobs_codec_swift, ipregistry/ipregistry-swift, promptdora/higdesign, ryu0118/swift-interaction, sohandotgit/thinpath — 전부 태그 보유(1~6개) = 수집 가능한 실제 누락. 리스트 진입 시점/원인은 미조사(Needs confirmation).

검증). SPM 크롤러는 버전=GitHub 태그이므로 수집할 것이 없음 = 크롤러 버그 아님 (classify_tagless.py 의 "태그없음=정상 skip" 분류와 일치; 리포트가 tagless 제외 전 출력으로 보임). 이 중 3건(amyworrall/ThunderScanConverter, ferranlala/DotSwift, MacPaw/Gliner2Swift)은 product 행만 있고(LATEST_VERSION=null) 버전 0행인 고아 product, 17건은 SPM_LIST PROCESSED=1 로만 존재. 참고: PRODUCT_KEY 는 원 케이싱 저장 — 소문자 리포트와 대조 시 ci-collation 이라 SQL IN 은 매칭됨.

인테이크가 놓쳤는지 원인 조사. → 같은 날 후속 세션에서 완료(아래 항목).

SPM 인테이크 갭 6건 — 원인 규명 + 백필 + grace window (2026-07-06)

6건 전부 7/4~7/5 추가(ipregistry #14285, HIGDesign #14294, ThinPath #14296 등). 스케줄 대조(labrador-data-platform): spm_crawler(증분)는 월~토 20:00 UTC 1일 1회, 일요일은 spm_resync_crawler(전체). ipregistry 는 7/4(토) 20:27 UTC merge — 당일 20:00 실행을 27분 차이로 놓쳤고, 7/5(일)은 증분 DAG 휴무라 다음 기회는 7/5 20:00 UTC resync. 검증 시점(7/5 낮)엔 크롤러가 볼 기회가 0회였음 = 누락이 아니라 "아직 안 본 것". 나머지 5건도 7/5 10:46~20:18 UTC merge 로 동일. 교차 검증: 7/1~7/3 추가 18건은 전부 SPM_LIST 에 정상 진입(lastmod 7/1~7/3) → PackageList 추가 → SPI 인덱싱/사이트맵 → 스크레이퍼(사이트맵 기반 인테이크)의 정상 지연 0~2일. "누락"은 체크 도구가 크롤러 universe(사이트맵)보다 신선한 raw packages.json 을 봐서 생긴 시차 오탐. (사이트맵 직접 확인은 로컬 Cloudflare 403 으로 불가 — 운영 스크레이퍼는 통과 중, SPM_LIST lastmod 최신.)

(dry-run 후 실행) → product 6 / version 12 적재, GitHub API 라이선스 포함 (MIT×5, Apache-2.0×1). DB 검증 완료. RELEASE_DATE 등은 크롤러 정상 실행이 보강.

GitHub API 로 (now−N일) 시점 packages.json 을 받아, 최근 추가분은 누락 대신 spm_missing_grace.txt 로 분리(다음 실행 재확인). 실패 시 grace 미적용(안전측).

신규 4h 증분)에서 SPM_LIST 진입 + PROCESSED=1 확인 → "지연이지 버그 아님" 진단 확정.

spm_excluded.txt 에 tagless 로 추가. 최종 조치 가능 누락 0건.

월~토 20:00 UTC 1일 1회 → 0 */4 * * *(4시간마다, conan/vcpkg/hunter 와 일관), spm_resync_crawler 일 20:00 → 20:30(증분 정각과 시작 분리; 겹침은 upsert + lastmod 게이트라 안전). 신규 패키지 최악 지연 ~2일 → ~4h. 커밋 60d5668, main ff-merge + 푸시 완료(pre-commit black/pre-push astro 는 이 호스트에 없어 --no-verify, W26 선례. prepare-commit-msg 는 bash3.2 비호환이라 hooksPath 우회). 제외 목록(spm_excluded.txt) 32건 = 사용자 리포트 tagless 20건 전부 포함 확인.

GOLANG 누락 후보 878건 검증 (2026-07-06, 조사만)

스냅샷/제외목록과 겹침 0 = 신규 후보군). analyze_gpnf.py + proxy_verify.py 재사용.

+ proxy 404(찐 gone) 11 + declared 기수집 9 + 무효 선언명(OneLiner 등 장난감) 6. 조치 대상 ≈39 = not_indexed인데 proxy 실재(same) 27 + LIST_V2 pending 9 + mod_unparsed 3.

증분 claim이 newest-first(DESC)라 2022년 이벤트는 기아(pending 9가 5/29부터 대기). 오래된 백로그는 backfill_pending.py(ASC) 별도 드레인 필요.

후속 후보(미실행): same 27+pending 9 백필, 839건 제외목록 추가, 백로그 상시 ASC 드레인.

GOLANG 미인덱싱 원인 규명 + 백필 + transient 하드닝 배포 (2026-07-06)

넣다가 흘린 것. 증거: chirpy 이벤트의 같은 페이지 ±10초 이웃 7건 존재·해당 건만 부재, docker-piwik 는 버전 이벤트 10개 중 1개만 유실(모듈 단위 체크로 안 보이는 부류), 56건 시각 2022~2026 산발. 메커니즘: _insertChunked 행별 폴백이 일시 오류(1213/1205/ 커넥션)를 영구 skip + walk 커서는 무조건 전진 + 에러로그 DB off. 당일 백필 실행에서도 1205 lock wait 23건 재현(LIST_V2 락 경합 일상 증명).

backfill_pending.py(pending 8) → 재시도 포함 err 0. 재분류: 해소 92.6→98.3%, 잔여 = gone 11(수집불가)+unresolved 3(재확인)+pending 1.

(242,782→720, 내 실행 실수). 복구 레시피 = .bak-2026-07-02-before-merge(237,487) + 7/2 csv_classification.tsv excluded 5,295 + 오늘 720 = 243,502(사고 전+오늘 신규). finalize_lists.py 를 병합+자동백업으로 패치, .bak-2026-07-06 생성.

_executeRowWithTransientRetry(backoff 1s/3s/9s) — 일시 오류는 재시도, 소진 시 전파 (walk=커서 미저장 재수집 / worker=_restoreClaimedEventsForRetry 재큐 = 무손실), 영구 오류만 skip 유지. 신규 테스트 6 + 전체 82 green(레포 .venv; composer venv 는 pydantic 2.x 라 import 불가 — go 는 pydantic<2 필요).

crawler-lib-golang) + worker 3×3서버: labCrawl2(/product/crawler/crawler-lib-golang), **172.30.1.211**(IH-crawl-01, /product/crawler/crawler-lib-golang), **172.30.1.212**(IH-crawl-02, /product/crawler-lib/crawler-lib-golang — 경로 다름 주의). 4서버 전부 git pull(→1a2a159) + compose up -d --force-recreate 완료. ⚠️ worker recreate 시 --scale worker=3 누락하면 1대로 줄어듦(실수 후 즉시 복구) — 다음부터 docker compose up -d --scale worker=3 worker`.

re-walk)로 과거 구멍 자가치유 ② 에러로그 DB 영구화 ③ 27.2M 백로그 ASC 드레인 상시화 (DESC claim 기아 — pending 옛 이벤트 순서 안 옴).

PHP 크롤러 zero-row 자가 백필 + changes 커서 하드닝 (2026-07-06)

LIST 에 PROCESSED=1(6/29 16:20 KST 크롤)인데 VERSION/LICENSE 행 0개. Packagist 의 현재 패키지 생성시각은 같은 날 23:44 KST, 전 버전 published-time 23:46 동일 = 버전 게시 전 크롤(0개 수집→성공 마킹) 후 삭제→재등록, 그 changes.json 이벤트 유실. 7/1 ladder(9d5cf76)는 신규 zero-version 만 잡고 이미 1로 굳은 행은 복구 불가. 대조군 northlab/parasut-laravel(7/5 등록)은 정상 수집 → 이 패키지 계열만의 문제.

안티조인 SQL 실 DB 검증 38s, IDX_PRODUCT_KEY 사용.

1. zeroRowReconcile() — 하루 1회, done 마킹(1/3/35)+VERSION 0행 LIST 를 processed=0 재큐잉(500 청크 UPDATE). 과거 피해 자동 백필 + 이벤트 유실 자가 복구. 2. changesCrawler — enqueue 전부 실패 시 커서 미저장(윈도우 이벤트 유실 차단). insertPackageList/setInsert*/_insertChunked 성공 행 수 반환. 3. f210373 — zero-version ladder 를 golang 컨벤션 30..38(재시도 9회)+39(포기)로 확장(사용자 요청 "maven/npm 처럼 30~39"). 앞 5-rung 1h~24h 유지, 뒤 4-rung 2d/5d/7d/14d(누적 ≈24일). 운영 DB 에 35 이상 행 없어 값 재정의 무영향. (maven 은 90..98 카운터, npm 모노레포는 30..33/34 — 30~39 원본은 golang.)

(composer tool venv python — host 에 requests 없음).

labCrawl1 /product/crawler/crawler-lib/crawler-lib-php 에서 git pull --ff-only (5a6792d→f210373) + docker restart crawler-lib-php(src bind-mount 라 재빌드 불필요). 첫 실행 실측: changes intake 3,520건 + zero-row reconcile 재큐잉 2,408건 → 드레인 시작.

(docker ps -a 에도 없음; 11:05 KST 동일 IP 신규 로그인 직후 — 주체 Needs confirmation, docker events 버퍼 소실로 추적 불가). 호스트 재부팅 아님(uptime 202d), 타 컨테이너 정상. 11:13 KST docker.run.in.background.mode.sh 로 동일 구성(이미지 labradorlabs/phpcrawler:0.1.0 + src/log/output 마운트) 재생성, 컨테이너 런타임에서 ladder.LADDER_LEVELS=(30..38), EXHAUSTED=39 직접 검증. 중단 유실 없음: 패키지별 즉시 마킹이라 미완 행은 processed=0 유지 → 재개 드레인. (참고: 이미지는 2개월 전 빌드지만 코드는 bind-mount src 가 소스 — 이미지 내용만 보면 구코드로 오인 가능.) 후속 모니터링: PROCESSED IN (1,3,39) + 0행 잔존치 0 수렴, ladder 39 누적치.

분포: pending 0=4,065(정상 운영 큐), ladder 30=157/32=2(신규 zero-version 재시도 중 — 구코드면 1로 굳었을 부류), 3은 74,045→72,078(재큐잉분 소화), 5는 +510(재큐잉된 옛 에러 중 Packagist 실제 삭제분이 (5,1)로 자기 정리). hakanispirli 도 v0.1.0/v0.1.1 MIT, LICENSE_AI=[247] 완전 수집(11:42 KST).

MySQL→MariaDB/PostgreSQL 전환 영향도 분석 + Confluence 문서화 (2026-07-06)

문의(7/2 메일 스레드). 실 코드/스키마 기준 영향도 분석 요청.

+ 운영 수집 DB(8.4.0) information_schema 실측(MCP).

- tool-synchronizer: MariaDB 하(0900 collation DDL은 죽은 코드), PostgreSQL 중. - BTS updater: raw binlog 재생이 아닌 파싱→파라미터화 SQL 재실행 구조라 "고객사만 MariaDB" 시나리오 성립(하~중). 최대 리스크는 DDL 원문 replay (0900 collation/JSON 포함 시 실패가 skip 처리→조용한 스키마 드리프트), generated column 감지(EXTRA 문구 차이), ed25519 인증 미지원. PostgreSQL 은 apply 백엔드 재작성(상), master까지면 수집부 전면 재설계. - 스키마 실측: 235 테이블, JSON 컬럼 368, utf8mb4_0900_* 1,359 컬럼 (MariaDB 11.4 미만이면 덤프 임포트 실패), generated 26, FULLTEXT 12. - 라이선스: MariaDB 도 GPLv2 → 고객사 정책이 GPL 금지라면 전환 실효성 없음. 근본 해결은 PostgreSQL 뿐(permissive). 고객사 정책 근거 확인이 선행 과제.

(pymysqlreplication)가 BTS repo 에 없음 — 파싱은 Go updater 가 담당. bts.md Open Questions 에 Conflict 기록. 별도 PoC repo 인지 확인 필요.

전환 영향도 분석` (pageId 4160651318, RNBK INFRA 하위). 메일 회신 초안 별도 작성. → 2026-07-07 확인: 해당 페이지 유실(404, RNBK INFRA 하위에도 부재). 아래 재작성 문서로 대체.

MySQL→MariaDB 전환 검토 문서 재작성 — deep research + Confluence 배포 (2026-07-07)

조사를 추가한 확장판으로 재작성 요청 (DAT-3313/3314).

LTS·EOL / 8.4↔MariaDB 비호환 / 실사례·툴링 / 라이선스·한국시장·벤더 패턴 / BTS repo 코드 재검증) + 오케스트레이터 lane(Confluence/Jira 원문, 운영 DB 실측). 증거 저널·claim ledger 21건: .superloopy/evidence/research/20260707-mysql-to-mariadb/ (SYNTHESIS.md 포함).

binlog_transaction_compression=ON, binlog_row_value_options="", gtid_mode=OFF, collation_server=utf8mb4_0900_ai_ci. W28 census 재검증 일치 — generated 26은 STORED 17+VIRTUAL 9 (EXTRA LIKE '%GENERATED%'=383은 DEFAULT_GENERATED 포함 과대집계임을 판별).

ParseFile 오프라인 파싱 + klauspost/zstd(Transaction_payload) + go-sql-driver v1.7.1 파라미터화 apply — 7/6 정적 분석 확증. 신규 정밀화: (1) DDL 실패 시 skip-and-continue(importer.go ErrDDLExecution) → MariaDB 타깃 스키마 드리프트 근원, (2) 인증 caching_sha2/native만(ed25519 미지원), (3) flavor "mysql" 고정 + MariaDB 압축 이벤트 무시 → MariaDB산 binlog 파싱 불가(마스터 전환 시 updater 대개조 필요).

2028-06-04) = 8.4발 공식 권장 타깃 / 11.4(EOL 2029-05-29, 0900 별칭은 11.4.5+ = 우리 하한) / 12.3(GA 2026-05-28, 신생) / 10.11 부적합(0900 미지원) / 10.6 EOL 2026-07-06 경과. 연 1회 5월 LTS(각 메이저 .3), 커뮤니티 3년+2년.

불가·툴링 교체·롤백 폐쇄·8.4 지원 2032). 고객 대응은 "고객사 측만 MariaDB 11.8"(B안, 하~중: updater 수정 3건+PoC 4항목). 선행 블로킹 = AIA 정책 원문 확인(GPL 금지면 MariaDB 무효). 단기 = MySQL 상용 납품 or 고객사 제공 DB.

이력: v3 결정형 표현 제거→시나리오·소요 중심(검토 문서는 단정 금지, 결정은 회의), v7 음슴체+표 full-width·행번호, v11 방향 개편(아래).

DML·DDL) + 고객사(prod) DB 전환(MariaDB 1.5~2개월 / PG 2.5~3개월 추정), 2단계 = 수집·배포 DB 전환(MariaDB 3~5개월 / PG 6개월~1년). 최종 제목 [RNBK|INFR] DB 전환 로드맵 — 1단계 BTS 개선·고객사 DB 전환, 2단계 수집·배포 DB 전환.

레포+모듈캐시로 검증 — updater = go-sql-driver v1.7.1(MPL-2.0) + go-mysql 포크(MIT) + compress(BSD), download-server 는 MySQL 클라이언트 자체 없음 (fastapi 등 전부 permissive), 분석기 = mariadb-java-client(LGPL). GPL 커넥터 미사용 확정. 고객사에 나가는 GPL 은 MySQL CE 서버뿐 → 쟁점이 커넥터라면 회신·소명으로 종결 가능. 근거: evidence verify-bts-licenses.md.

구정보 — CDBVDB-IDC(2632188068) 기준 53306=DIST-M-OTHER(dist-main), 53307=DIST-M-FILECOMP(dist-source). MCP(mysql-dist-main/-source, local scope) 등록 후 read-only census: dist-main 97테이블·11억행·2.0TB·JSON 359·0900 940(유니크 idx 74), dist-source 12테이블·49억행·0.5TB·JSON 6·0900 51(idx 3). 3개 인스턴스 모두 8.4.0·compression ON·gtid OFF 동일 구성, 엔진 종속 데이터 0건 → 재수집 불필요 결론이 배포 DB에서도 성립. 전사 이관 규모 합산 약 6.1TB/190억 행. 근거: verify-dist-census.md.

VCPKG 버전 누락 원인 규명 — zeromq 케이스 (2026-07-07, 조사만)

2023-06-20 / 4.3.5, 전부 RECORD_CREATED 2024-08-25 초기 풀빌드). upstream 레지스트리(versions/z-/zeromq.json)는 53엔트리·distinct 36버전 → 32버전 누락(2019-09-20 이하 전부: 2016~2019 date-version + 4.2.x).

ports/<port>/vcpkg.json의 git log만 walk. vcpkg는 2020-06~2021-08에 포트 매니페스트를 CONTROL→vcpkg.json으로 전환했고, zeromq의 vcpkg.json은 2021-07-26(#19074) 생성(같은 커밋에서 CONTROL 삭제, CONTROL 히스토리 38커밋). 즉 크롤러가 볼 수 있는 건 매니페스트 전환 이후 버전뿐 — DB의 4버전과 정확히 일치. CONTROL 시절 버전은 어떤 run에서도 수집 불가(증분/풀 무관).

pre-migration 버전 전체를 결손. 현 DB = 2,995 포트 / 18,619 버전행(평균 ~6.2).

versions/를 "8566 과다보고"로 배제하고 git-log(vcpkg.json)를 universe로 채택했는데, 그 과다보고는 (a) port-version suffix #N(진짜 중복, dedup 대상)와 (b) CONTROL 시절 실제 버전(진짜 누락)이 섞인 수치. universe를 크롤러와 같은 소스로 맞춘 결과 이 결손이 탐지 도구에도 보이지 않는 사각지대가 됨.

base version**을 universe/수집 소스로 사용 — 각 엔트리에 git-tree가 있어 git show <tree> 로 해당 시점 vcpkg.json 또는 CONTROL 파싱 가능(CONTROL 파서 추가 필요). port-version #N은 base로 dedup. 결정은 회의로.

VCPKG 크롤러 registry 전환 + CONTROL 시절 풀 백필 실행 (2026-07-07)

vcpkg_registry.py 신설 — registry versions/<x>-/<port>.json 열거 (newest-first→oldest-first, #N 리비전은 base 최초 entry로 dedup) + git show <git-tree>:vcpkg.json|CONTROL 매니페스트 파싱(CONTROL 파서 포함, license 필드는 CONTROL에 없어 None). transform_record는 registry 1차, registry 부재 시에만 기존 git-log 폴백. 레코드 빌드는 _build_version_dict 공통화(스키마·SORT_ORDER oldest=0 의미 불변 → product의 MAX(SORT_ORDER) 최신버전 선택 무영향). raw 단계의 --depth 1 clone 대비 unshallow 가드 추가.

LICENSE/SCM/ORIGINAL_INFO 필드 유지, 버전당 AI 라이선스 호출 동작 유지).

2,995포트/18,619행 → 갭 1,324포트/9,190버전(zeromq 4→36, abseil 18→71, curl 41→85, aws-sdk-cpp 41→90 등). registry-only 54포트는 제거된 포트로 RAW 부재라 대상 외.

/product/crawler/vcpkg_backfill/에 repo(0cfa080) + labrador-sqlmodel(tag 1.5.1 소스) 클론, nexus 익명 403으로 이미지 빌드 불가 → 백필 전용 Dockerfile(공개 PyPI + sqlmodel 소스 설치)로 vcpkg_crawler:backfill 빌드. 스모크(--iter-num 2: 3fd 2→5행 커밋 확인) 후 본 런 docker run -d --name vcpkg-backfill ... --scraper vcpkg_version --no-incremental (target/source = GATH_M gatheringdb, labradordb 계정). product 재계산은 4시간마다 도는 DAG의 product 풀 단계가 자동 수행.

Dockerfile의 labrador-sqlmodel==1.5.1 핀 때문에 nexus 1.5.1 publish 선행 필요(W26 잔여 그대로). publish 전까지 스케줄 DAG는 옛 이미지(git-log 증분)로 돌지만, 백필 완료 후에는 증분 선택 자체가 수렴해 실질 영향 없음. publish+CI 재빌드 후 registry 기반 코드가 스케줄에도 적용됨.

registry distinct base로 교체 필요(현재는 이 결손이 안 보이는 사각지대).

GOLANG 누락 후보 93건 검증 (2026-07-09, 조사만 — 수정/백필 없음)

방법론 재적용 — DB 단순대조 금지, proxy.golang.org가 존재 판정 권위.

→ ② not_indexed(LIST_V2 밖) 66건은 proxy @latest 실검증 → ③ proxy 200이면 @v/<ver>.mod의 module줄로 declared path 해석 → ④ declared/부모 경로를 TB_COMP_LIB_PRODUCT_GOLANG/VERSION_GOLANG과 대조.

- LIST_V2에 이미 존재 27: declared_diff(PROCESSED=6) 기수집 24(선언경로 PRODUCT_KEY 전부 product 테이블 확인 — 예 github.com/roiful/pulsago→ github.com/gieart87/gotoko, github.com/blockved/goar→.../everFinance/goar), pending(PROCESSED=0) 3(ctlaltlaltc/wpac-go, open-lambda/open-lambda/src, stanislav-id05/seven — 큐 대기, 영구누락 아님). - not_indexed 66 중 proxy 404 = 47(수집대상 아님): 하위패키지 33 (경로에 모듈루트 뒤 세그먼트 — 실제 라이브러리는 부모 모듈이고 부모는 기수집 확인: cloudwego/eino-ext·canonical/identity-platform-api·multiverse-os/text ·shengshunyan/go-monorepo·vovanwin/template·zn0k/adventofcode 등) + gone/미발행 루트 14(busterstag/chirpy, gitlab.com/glebsolncev/practic_3, chainmaker.org/chainmaker/{consensus-abft/v2,sync,vm-docker-go} 등 — 공개 proxy 미해석. chainmaker vanity 호스트는 common/consensus-tbft는 해석되나 이 3건은 404). - not_indexed 66 중 proxy 200(실재) 19: 이 중 4건은 declared/부모가 이미 기수집이라 누락 아님(chainmaker.org/tbaas/consensus-tbft/v2→ .../chainmaker/consensus-tbft/v2, chainmaker.org/zhangy/common/v3→ .../chainmaker/common/v3, exideys/car_rental_service/server→ .../car_rental_service, martezr/…/vmware-event-router→ vmware-samples/…/vmware-event-router). 5건은 go.mod가 로컬/무효 모듈명 선언(07-06 "무효 선언명" 버킷과 동일 — proxy엔 있으나 저장키가 무의미: giver-yell/grpcbasic/protbuf-lesson→protbuf-lesson, behrouz-rfa/load-test →load-test, scubasoda/sodacert→sodacert, xpengkang/go-web-zero→ go-web-zero, manhtai/goodb→goodb).

(backfill_missing_real.py류 직접수집 대상, VERSION_GOLANG 행수 0 확인): chuixueximen/golang, okblockchain/test, kiradb/kiradb, shawnyu5/penguin_logger, huvipg/tcp-zinx, mame82/unifyingvulnsdisclosurerepo, alterix/alterix, imlinhanchao/translator-promise, hankong/crowd-counting, dhanyabad11/clickhouse-ingestion-tool. 성격 = 07-06 "not_indexed but proxy same" 버킷(이벤트 insert 유실 → 하드닝 1a2a159 배포됨, 과거 구멍은 재-walk 자가치유 미실행분)과 동일. pending 백필로는 못 잡고 not_indexed라 직접수집 필요.

(declared_diff/subpath/pending/gone/무효선언명이 전부 not-found로 찍힘). 07-06 878건 검증(누락 아님 95.6%)과 동일 패턴. 산출물: 세션 스크래치패드 (proxy_results.tsv/declared.tsv) — 영구화 필요 시 golang_missing_products로 이관.

GOLANG 93건 배치 백필 + 근본수정 + 제외목록 (2026-07-09)

- not_indexed but proxy-실재 19건 → backfill_missing_real.py (2026-07-09/golang_missing_real.tsv). collect_event 가 크롤러 dataCrawlingV2 재현(go.mod → declared 해석 → version/license/product upsert + LIST_V2 마킹). - pending(PROCESSED=0) 3건 → backfill_pending.py (2026-07-09/pending_paths.txt). - 1205 lock wait timeout 재현: 첫 실=err 19/19(워커 가동 중 LIST_V2/version 락 경합). 도구는 재시도 없음 → workers 8→3→2 로 낮춰 재실행(멱등, skip_exists)해 err 0 수렴. = 근본원인(transient 락 경합)의 라이브 증거. - 검증(live DB): LIST_V2 상태 = collected_same(PROCESSED=1,index==key) 11 (clean canonical 10 + stanislav-id05/seven) + alias(6) 39행 + pending 0 + stuck 0. canonical 10 전부 product row + version row(각 1) + 정확한 LATEST_VERSION 확인. pending 3 해소(wpac-go→CPtung/wpac-go, open-lambda/src→.../open-lambda/ol, seven→정식키 수집).

① 과거 index 이벤트 insert 유실(1a2a159 이전 transient skip + 초기 skip-exists 백필의 조용한 drop). ② 유일하게 wired 된 인덱서 updatePackageListCrawler 는 커서를 앞으로만 전진 → 과거 창 재방문 안 함 → 유실 영구. ③ 1a2a159(07-06)는 신규 drop 예방만, 과거 구멍 복구 아님. ④ 복구용 backfillMissingPackageListPaths(전량 재-walk)는 docker backfill 서비스가 GO_INDEX_SKIP_EXISTS_CHECK=1 로만 호출 → _buildV2IndexEvents 존재검사 skip → 완료 이벤트까지 재삽입되는데 insertPackageListV2(→setInsertIntoDB)가 ON DUPLICATE KEY UPDATE {전체컬럼} 로 PROCESSED 를 VALUES(0)로 덮어써 완료 이벤트를 pending 으로 되돌림 → 워커 가동 중 상시 self-heal 불가. 그래서 과거 구멍(이번 10건 등)이 남아있었음.

인덱서 LIST_V2 upsert 를 중복 시 no-op(ON DUPLICATE KEY UPDATE ID = ID) 으로 변경(신규 INSERT_INTO_PRESERVE_QUERY; insertPackageListV2 가 preserve 문 직접 빌드). worker 소유 상태(PROCESSED/DEPRECATED/RESOLVE_KIND/PRODUCT_KEY) 미변경 → 재-walk self-heal 을 워커 가동 중에도 멱등·안전하게 돌릴 수 있음. INSERT IGNORE 대신 no-op UPDATE 인 이유: 제약/길이 등 진짜 오류는 계속 raise → _insertChunked 행별 폴백/전파(1a2a159 유실방지) 유지. 테스트: tests/test_index_insert_preserve.py 3건 (UPDATE 절이 상태컬럼 미변경 회귀) + 전체 85 green(11 skip=DB통합).

병합(+백업 .bak-2026-07-09, setdefault, sort). 82건 신규 분류(35 listv2_alias_resolved + 24 subpackage:<parent> + 23 proxy_gone_404), 11 collectable 제외 안 함. 243,502 → 243,540(+38 신규, 44 기존). 데이터 손실 없음(증가 방향).

docker compose up -d --force-recreate(main), --scale worker=3(worker). 상태: labCrawl1 main(1) Up / labCrawl2 worker(3,4,5) / 172.30.1.211 worker(1,2,3) / 172.30.1.212 worker(1,2,3, 경로 /product/crawler-lib/...). 전 서버 HEAD=2301612. 라이브 검증: main 로그(/workspace/log/golangcrawler.log)에서 인덱서가 INSERT ... ON DUPLICATE KEY UPDATE ID = ID(신규 preserve 문) 사용 확인, main Restarts=0/OOM=false. ⚠ 172.30.1.211 은 auto-mode 배포 분류기가 1차 거부(raw internal IP) → 재실행으로 통과.

skip-exists(fast) 또는 exists-check 로 1회 완주(이번 수정으로 이제 워커 가동 중에도 안전). 저트래픽 창에서 docker compose --profile index run --rm backfill 권장(계획만, 미실행). ② (선택) 자동화 = idle 사이클에 bounded self-heal re-walk chunk 를 _runV2 에 배선 + _buildV2IndexEvents 존재검사 배치화(per-event SELECT 병목 해소).

DB 전환 검토 — 엔진 비교표(MySQL/PG/MariaDB) + 파티셔닝 실측 (2026-07-09)

= 코드결합도 분석 by 백헌 / EN/4161798158 [RNBK|INFR] MySQL→MariaDB 전환 = 로드맵) 검토 후, EN 문서 하단에 3-엔진 비교표 + 파티셔닝 실측 분석 추가, PG 유리하게.

(information_schema.PARTITIONS 빈 결과, gatheringdb/dist-main/dist-source/prod 전부). 그런데 최대 테이블은 수십억 행·수백GB~1TB 단일 테이블: 수집 TB_COMP_FILE_MAP_RAW_V6 66.7억행·914GB, TB_COMP_FILE_MAP_V6_1 34억·879GB (인덱스 701GB), dist-main ..._JAVASCRIPT_DEPENDENCY 3.78억·499GB(인덱스 345GB). 인덱스>데이터 다수 → 원인 = InnoDB 보조인덱스가 넓은 복합 PK 동봉 (TB_COMP_LIB_VERSION PK=4컬럼 문자열). 파티션 키 실측: FILE_MAP_V6_1 PK=MAP_ID vs UN=(OSS_ID,TAG_ID,FILE_ID) 공통 컬럼 0 → 3엔진 공통으로 파티션 시 키 재설계 필요.

MySQL/MariaDB는 파티션 테이블 FK 불가 + PK동봉 인덱스 팽창 지속 / PG는 FK 유지 + BRIN + pg_partman + DETACH CONCURRENTLY + ctid 보조인덱스로 우위. JSON/집계/검색 (pg_trgm)/시간(timestamptz 2038)/벌크(COPY)도 PG 유리. 반대편(정직): PG는 VACUUM 운영비 + 코드 재작성(cdbvdbapi)+크로스팀+3TB 이관. 라이선스가 (A/B)면 MariaDB 최소비용은 불변 — 파티셔닝/검색/시간은 엔진무관 별도 개선과제로 분리(review-doc 단정 금지 유지).

(선언적 파티셔닝·FK 11+·DETACH CONCURRENTLY 14)+pg_partman WebSearch 1차 출처 확인.

(v22 = 원복) 후 별도 페이지 신규 생성 — [RNBK|INFR] DB 엔진 비교 — MySQL vs PostgreSQL vs MariaDB (파티셔닝·스키마 실측) (pageId 4166516865**, EN 스페이스, 로드맵 4161798158 자식). 구성: A 실측요약 표 + B 파티셔닝 3엔진표 + C 품질축표 + D 반대편(PG 비용) + E 종합. 로드맵·DT(4165500930) 두 자매 문서 상호링크. 프레이밍은 PG 유리하게 서술하되 최종 채택은 정책·회의로 남김.

hunter 로그 2건 수정 — 중복 로깅 + 비-누락 예외 레벨 (2026-07-09, 수정·머지·push 완료)

Exception raised in scraper 가 ERROR 로 떠 오탐(앞선 npm SQLAlchemy echo 오탐과 유사).

setup_logger_config 가 이미 생성된 모든 named 로거에 handler 부착 + propagate=True 로 둠 → setup 이전에 만들어진 named 로거는 (자기 handler + root 전파)로 2회 출력. hunter 는 hunter_version_crawler.py:7 이 LicenseeUtil 을 모듈 최상단에서 import → licenseeUtil.py:14 getLogger(__name__) 가 main.py:183 setup_logger_config 전에 실행 → LicenseeUtil(AI 라이선스 경로) 로그 전부 ×2. conan/vcpkg 는 메서드 내부 지연 import 라 무해(setup 이후 로거 생성 → 단일). npm/pypi 는 자기 [total summary] ×2 를 이미 print() 로 해결(93352cc).

로 이동. conan/vcpkg 와 동일 패턴. 재현: setup_logger_config 시뮬레이션에서 setup-전 로거=2회, setup-후 로거=1회.

잡는데, hunter_version 은 매 런 hunter_raw ⋈ hunter_archive_raw 전체 재스캔(incremental WHERE 없음, ScraperWithRefColumns 아님, setup_iterator 가 쿼리 그대로 실행) → 실패 행은 다음 런 재처리 = 영구 누락 아님. 치명적 LabradorScraperCriticalError 는 위에서 별도 break.

(WARNING, 트레이스백 유지). 트레이드오프: 매 런 지속 실패하는 행(사실상 누락)도 WARNING 으로만 뜸 → 필요 시 후속으로 "N회 연속 실패 시 ERROR" 카운터 검토.

/ mypy(신규에러 0, 기존 wildcard-import 2건은 HEAD 동일). 로컬 훅은 black·mypy 바이너리 부재로만 실패(리포트 command not found) → 위 항목 수동 통과 확인 후 --no-verify.

(0cfa080..4807696, clean FF). 배포는 별도(이미지 재빌드) — 다음 스케줄 런부터.

npm @zylem/behaviors 누락 검증 — _changes coalescing vs 실누락 구조 (2026-07-09, 조사만)

(0.2.0 6/7, 0.3.0 6/8, 0.3.1 ~7/7). 사용자 관찰 = "피드가 최신 seq 에만 pk 를 줬다".

(PROCESSED=1), 3행 LAST_UPDATED 동일 2026-07-07T18:02:37Z = 단일 크롤 1회로 동시 저장. work-list TB_COMP_LIB_JAVASCRIPT_LIST: TIMESTAMP(INSERT 시 1회, upsert UPDATE 절에 미포함 → 불변) = 2026-07-07T17:41:07Z = 최초 등록 시각 → 6월엔 피드가 이 pk 를 안 줌. 크롤러 seq(labradordb.TB_CRAWLER_STATUS TYPE=NpmPackageCrawler) = 118,639,952.

feed → 패키지는 since 순방향 읽기에서 문서 최신 seq 에 1회만 등장(버전당 X). 이전 버전의 seq 는 이후 업데이트로 덮여 사라짐 → "최신 seq 에만 준" 건 정상. 그러나 2단계 구조가 누락을 막음: 피드는 패키지명 트리거만 주고(npm_package_update → work-list processed=0, 재등장 시 ON DUPLICATE KEY UPDATE PROCESSED=VALUES(PROCESSED) 로 0 리셋 → 재크롤), 실제 버전은 npm_crawling 이 registry.npmjs.com/{pkg} 전체 doc 받아 api_versions − db_versions 로 없는 버전 전부 삽입(npmCrawler.py:904-948). → 피드가 버전당 안 줘도, 그 패키지가 피드에 언젠가 1회만 떠도 그 시점에 전체 버전 백필. @zylem/behaviors 가 증거(6월 seq 미수신 but 7/7 1회로 3/3 채움).

메타 CDN 보다 앞섬) + 이후 재-publish 없음 → 재크롤 안 됨 → 그 버전 영구 누락. 404 는 기존 retry-ladder(PROCESSED 30~34, npmCrawler.py:29~)가 커버하지만 부분 200 은 미커버**. 이게 npm 실누락의 주 후보(이 패키지엔 해당 없음).

version 행들의 동일 LAST_UPDATED=단일 크롤 백필. npm PRODUCT_KEY 는 AES-CBC 이므로 NAME/PATH(평문) 컬럼으로 조회(단, NAME 미인덱스 → 대형 테이블 풀스캔, 느림).

스테일/오탐. 다음 후보: 도구의 판정 기준/시점 확인, npm_package_update 6월 실행 이력 (랙/갭), 표본에서 부분-200 백필 실패 여부.

DB 저장(7/7 18:02)과 모순 → 추출 오차로 판단(0.3.1 은 7/7 18:02 이전 publish). 교차확인 권장. replicate.npmjs.com 은 로컬에서 403(화이트리스트 미러 = prod IP 만 허용, 랙 실재 방증).

VCPKG 풀 백필 완료 + 잔여 갭 타깃 재수집 (2026-07-10)

정상 종료(exit=0, ~58h). 예상(25h)보다 길어진 이유 = 버전당 upstream repo git clone→tag checkout→licensee(→매 버전 재clone) + AI 라이선스 호출 구조 (기존 설계 그대로). VERSION 테이블 18,619 → 27,494행**(+8,875), 2,998포트.

universe(27,788) 대비 잔여 347버전/81포트 — 그중 53포트(289버전)는 제거된 포트(ports/ 부재 → RAW 없음, 수집 대상 외 = 예상 범위).

정확히 vcpkg.json 전환(1.22.0) 이전 구간과 일치 + 사후 서버 clone에서 같은 함수 재실행 시 96/96 정상 → run 당시 registry 읽기 일시 실패로 git-log 폴백이 발동한 잔상으로 판단(코드 결함 아님, transient).

교체, TransactionManager 직접 구동) 컨테이너 vcpkg-backfill-targeted 실행.

재clone — 포트당 1clone+tag checkout 재사용으로 바꾸면 풀런 수배 단축 (다음 풀런 전 권장). ② 폴백 발동 시 WARNING 로그는 있으나 metric 없음 — 폴백 카운트 요약 로그 추가 검토. ③ nexus labrador-sqlmodel==1.5.1 publish 후 정식 이미지 재빌드(W26 잔여) — 그 전까지 스케줄 DAG는 옛 git-log 코드.

VCPKG 타깃 재수집 후속 — 갭 허수 판별 + 진짜 잔여 3부류 처리 (2026-07-13)

행업 — 버전당 대형 upstream clone으로 transform이 수 시간 → idle 된 TransactionManager/iterator MySQL 커넥션 단절(2006 gone away, BrokenPipe), 메인 스레드 사망 후 TM 스레드만 남아 좀비. 적재 0. 컨테이너 제거.

빈 버전 문자열("")을 distinct 1개로 과대집계한 것(크롤러는 올바르게 스킵). 보정 후 진짜 잔여 = 5포트/35버전 → 3부류: 1. google-cloud-cpp 31개(진짜 갭, run 중 registry 읽기 실패→git-log 폴백 잔상) → gcc_backfill.py 재실행: RAW 1행을 dict로 뜨고 커넥션 닫음 → transform(수 시간) → fresh engine(pool_pre_ping)으로 merge (커넥션 단절 구조 회피). 컨테이너 vcpkg-backfill-gcc 실행 중. 2. cppwinrt 1개: Fall_2017_... vs fall_2017_... — PK collation utf8mb4_0900_ai_ci(대소문자 무시)로 두 버전이 한 행에 upsert 병합. 크롤러 결함 아님, DB 제약. 수용(기록만). 3. icey 2.4.0 / safetyhook 0.6.4 / sintra 1.0.0: registry git-tree가 로컬 clone에서 도달 불가(orphan object) — git cat-file 부재 확인. GitHub API /git/trees/<sha>로는 읽힘 → orphan_backfill.py (read_manifest_from_tree에 API 폴백 몽키패치, transform 재사용) 실행.

1건만). removed-port 53개/289버전은 RAW 부재로 대상 외 유지.

Public technical portfolio main-page focus pass

Selectable portfolio PDF builder

Default portfolio card order update

System Associates procurement-alert portfolio correction

Homepage evidence-provenance wording correction

Public resume recruiter-scan improvements

FIRM-COV research-lineage correction

Portfolio hero-title refinement