Conversation
chore(repo): data를 main으로 승격
도장 화면과 미방문 목록은 맛집 하나를 볼 때마다 사용자 리뷰가 있는 후보 맛집 전체를 다시 훑었습니다 (승인 맛집 1,500개 x 후보 40개 = 60,000회, 후보마다 주소 게이트와 이름 게이트). 후보를 주소별로 한 번만 색인하고 직접 ID를 먼저 확인하면, 주소가 겹치지 않는 후보는 주소 게이트에서 이미 탈락한 것과 같아 검사 수가 목록 길이 수준으로 줄어듭니다. - apps/web/lib/restaurant-review-lookup.ts: createVisitedRestaurantMatcher 추가(순수 추가). 선형 판정(hasRelatedVerifiedUserReview)은 참조 구현으로 그대로 남깁니다. - apps/web/hooks/useUnvisitedRestaurants.tsx, apps/web/app/stamp/page.tsx, apps/web/components/overlay-pages/StampOverlay.tsx: 같은 판정을 색인 경로로 호출합니다. - 판정 결과(방문/미방문)는 바뀌지 않습니다. 검증 - tests-unit/restaurant-visit-matching-matcher.test.ts: 선형 판정과 동일성 15 케이스. - tests-unit/unvisited-restaurants-derivation.test.ts: 색인 경로 기준으로 갱신. - 전체 단위 테스트 2379 pass / 1 skip / 0 fail, 격리 150 pass / 8 skip / 0 fail, typecheck:parity diagnostics 0, lint exit 0. - 실제 로컬 DB: 병합 맛집 723개 전수 비교 불일치 0. - 성능 근거: apps/web/performance/visited-restaurant-matcher-20260922/benchmark.json 후보 검사 60,000 -> 30(2,000배), 중앙값 3.40ms -> 0.38ms(8.9배), p95 3.99ms -> 0.48ms. 퇴화 모양(모든 맛집이 한 주소를 공유)에서도 1.78배로 느려지지 않습니다.
buildRelatedVerifiedReviewCountMap은 맛집마다 selectRelatedRestaurantReviewIds로 후보 전체를 다시 훑어 비용이 맛집 수 x 후보 수였다. 후보를 주소로 한 번만 색인하는 createRelatedVerifiedReviewCountLookup을 추가하고 호출을 바꿨다. 합산 값은 선형 경로와 같다. - 색인 경로는 맛집 주소 버킷에 걸린 후보만 본다. 주소 없는 맛집은 주소 없는 후보만 통과시키는 선형 규칙을 그대로 유지한다. - 맛집마다 집합을 새로 만들지 않도록 countedIds를 재사용하고, seenStamps로 주소가 여러 개인 후보를 한 번만 본다. - selectRelatedRestaurantReviewIds는 참조 구현으로 그대로 남긴다. 근거(동결 원자료): apps/web/performance/verified-review-count-index-20260922/benchmark.json sha256 86e710b01c5c33b50ce675c54298c3618f7af11ddd939d150f7be911a7e2a9b5 작업량: 맛집 1000 x 중복 후보 1000 + 무관 후보 200, 반복 21, 표본 루프 20 - unique-address: 후보 검사 1,200,000 -> 1,000, 중앙값 64.333ms -> 0.657ms (97.9배), MAD 0.0501 / 0.0529 - shared-address(퇴화, 한 주소에 후보 1000개): 후보 검사 1,200,000 -> 1,000,000, 중앙값 173.667ms -> 155.844ms (1.11배), MAD 0.0241 / 0.0695 - 두 시나리오 모두 합산 지문 identical이고 absolute/relative/noise 예산을 모두 통과한다. 검증: npm run test:unit 2389 pass / 1 skip / 0 fail + 격리 150 pass / 8 skip / 0 fail, npm run typecheck:parity diagnostics 0, npm run lint exit 0
…0922 perf(web): 승인 리뷰 조회를 주소 색인으로 바꿔 후보 재스캔을 없앤다
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
…into-develop-20260922k
…p-20260922k chore(repo): main/data를 develop으로 동기화
This was referenced Sep 22, 2026
twoimo
added a commit
that referenced
this pull request
Sep 22, 2026
develop -> data 승격이 strict 보호 규칙에서 behind가 되지 않게 양쪽 커밋을 한 브랜치에 모은다.
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
무엇을 하나
develop을data로 승격합니다. 승격 경로(develop -> data -> main)에 따라data가develop의 내용을 그대로 받습니다.내용
git diff origin/data origin/develop: 12개 파일 +1511/-31 (구현 4개, 단위 테스트 3개, 성능 근거 4개, 그 외 1개)확인
develop에서 통과한 검사 결과를 그대로 승격합니다. 이 병합은 배포를 실행하지 않습니다.