rinda-landing 백엔드 · DB · 어드민 성능 전수분석

0. 요약 (TL;DR)

어드민 지연은 단일 버그가 아니라 “DB에서 전체 row를 끌어와 JS로 집계”하는 데이터 접근 패턴이 깔린 구조적 문제다. 이 JS 집계는 주로 백엔드(서버 Node.js) API 핸들러에서, 일부는 프론트엔드(브라우저)에서 일어난다. 데이터가 커질수록 선형으로 악화된다.

1. 어드민 페이지가 느린 이유 — 종합

근본 원인 순위(WSJF: 영향 ÷ 수정비용). 각 항목은 아래 상세 절의 코드 근거로 이어진다.

1. 전량 fetch + JS 집계 (DB층) — analytics 핸들러가 OFFSET로 최대 5만 row를 끌어와 앱에서 집계. 대시보드 3–5s 주범 상
   _shared.ts:254-289, heatmap.ts, page-metrics.ts, day-detail.ts
2. 마운트 시 API 5개 동시 발사 + 캐시 불일치 (FE층) — 대시보드 진입 즉시 5요청 burst, 그중 4개는 raw fetch+useState라 TanStack 캐시 밖 → 뷰 왕복마다 재요청. 상
   AdminDashboard.tsx:288-544
3. SSR 게이트의 직렬 인증 왕복 (TTFB) — 매 진입 시 getServerSideProps에서 Supabase getUser() → cms_users 조회를 직렬 await. TTFB가 인증 2회 왕복에 묶임. 상
   admin/index.tsx:132-138
4. 전체 게시글 select("*") 무제한 + JS 페이징 (DB·FE 공통) — getPosts()가 content 포함 전 row 로드, VisitorList도 전 방문자 받아 클라에서 slice. 상
   storage.ts:393-398, VisitorList.tsx:124-155
5. 요청 경로의 외부 LLM/API 동기 블로킹 — AI 개선·트렌드 리포트·Buffer 발행을 요청 핸들러에서 동기 await(최대 16K 토큰 비스트리밍). 상
   ai-improve.ts:68-95, posts/[id]/index.ts:109-162
6. mutation마다 카테고리 전체 재집계 + 루프 UPDATE — 글 저장/상태토글 등 모든 변경이 전 테이블 재집계 트리거. 상
   storage.ts:586-605
7. recharts eager import → 초기 번들 비대 — 기본 뷰 대시보드가 recharts 전체(d3 의존) 동기 로드. 중
   AdminDashboard.tsx:3-15
8. 비가상화 + memo 부재 → 렌더 랙 — VisitorList 매 렌더 Set/sort 재계산, AdminDashboard map 45곳 vs memo 4개, 15초 heartbeat가 거대 컴포넌트 전체 리렌더. 중
   VisitorList.tsx:134-155, AdminDashboard.tsx
9. 집계 캐싱 누락 + 무한 폴링 — funnel/analytics/queue-status 등은 매 요청 재계산, heartbeat 15s·auth 5m 폴링이 탭 비활성에도 지속. 중
   funnel.ts:77-85, AdminDashboard.tsx:523-544

2. 프론트엔드 성능

어드민은 단일 URL /admin(SSR) + 인증 후 클라 상태로 뷰 전환되는 SPA. 컴포넌트 29파일 12,398 LOC, 최대 HeatmapView.tsx 2,042 LOC.

번들 / 코드 크기

데이터 패칭 워터폴 / 폴링

렌더링 · SSR

3. 백엔드 · DB 쿼리분석

핸들러 본문 + supabase/migrations 인덱스 정의를 직접 대조. DB는 자체호스팅 Supabase/Postgres(단일 supabaseAdmin 클라이언트).

3.1 최우선 쿼리 병목 (영향도 상)

3.2 요청 경로의 외부 LLM/API 동기 블로킹

→ 모두 BullMQ/waitUntil 큐화 + 202 즉시 반환 + SSE/폴링 진행률. (schedule-generate·ai-generate는 이미 큐 모범패턴.)

3.3 OFFSET + count:exact 페이지네이션 (CLAUDE.md 위반)

대상: media/list.ts, utm/visits.ts, audit-log.ts, trends/index.ts, admin/analytics/events.ts, support-chat-conversations, post-counts.ts(7× count head). → (created_at, id) keyset cursor, count→estimated, post-counts는 단일 GROUP BY status.

3.4 인덱스 갭 (핸들러 쿼리 vs 마이그레이션 정의 대조)

RLS는 병목 아님 — service_role(supabaseAdmin)은 RLS 우회. page_analytics(053)·trend_items(042)·click_heatmap 등은 인덱스 양호.

4. 환경변수 · 설정 감사

.env.local 27개 변수. 시크릿의 NEXT_PUBLIC 유출 없음, .env.local git 추적 안전(check-ignore 확인).

설정 관찰

• 중 NODE_ENV=production이 로컬 .env.local에 박힘 → dev 빌드 동작 오염 위험. 검토 권장.
• 중 next.config.images.remotePatterns hostname ** 전면 개방(http+https 전체) → 외부 이미지 임의 프록시(SSRF성 리스크·비용). 도메인 화이트리스트로 축소.
• 중 CSP가 Report-Only(미차단) + unsafe-inline/unsafe-eval 허용 → enforce 전환 시 XSS 방어 약함. HSTS 헤더 부재.
• 하 성능 옵션 누락: compiler.removeConsole, experimental.optimizePackageImports 미설정. target:ES2017(→ES2022 권장).
• 하 vercel.json crons 15개 중 다수 * * * * *(매분) → 함수 호출비·콜드스타트 고려.
• 정보 코드 사용하나 .env.local 누락(배포 환경에만 존재): SLACK_*, LANDING_API_KEY, ADMIN_ALLOWED_IPS, REDDIT_* 등 → 로컬에서 해당 기능 호출 시 실패 가능.

4S. 슬랙(Slack) 연동 구성

두 개의 독립 서브시스템이 공존한다 — (A) Hermes/Threads 봇(bot token + 서명검증 + 모달·홈·버튼, 풀 인터랙티브) / (B) Incoming Webhook 알림(리드·문의·CMS 단방향 통보, 서명검증·봇토큰 없음).

구성 요약

Inbound 버튼 액션: threads_recheck/stop(모니터 재확인·종료), threads_publish(mock 발행, waitUntil), threads_home_new/refresh, claim_inquiry(문의 담당자 지정 — 버튼 블록을 “제가 담당할게요” 텍스트로 교체).

시크릿

성능 · 보안 관찰

• 양호 3초 ack 룰 준수(Hermes) — LLM 생성·발행·홈 publish 등 무거운 작업은 waitUntil()로 ack 이후 비동기 실행. (BullMQ는 없고 Vercel waitUntil 사용)
• 중 Webhook 알림이 사용자 요청 경로에서 동기 블로킹 — contact.ts:452·chatbot-inquiry.ts:46이 Slack 전송을 응답 전 await. chatbot은 최대 3회 지수백오프까지 동기 대기 → 워스트 ~900ms+ 사용자 지연 누적. → waitUntil/큐로 분리 권장.
• 중 서명 검증 fail-open — SLACK_SIGNING_SECRET 미설정 시 검증이 {ok:true} 반환(slack-verify.ts:34). 미설정이면 위조 요청으로 모달·봇·홈 publish 트리거 가능. 이 정적 게이트가 유일 방어선이므로 env 설정 필수.
• 하 잔여물 — cms/test-slack.ts에 “확인 후 삭제할 것” 주석이 남은 채 프로덕션에 실제 알림 발송 가능(CMS_AUTH 보호). 채널 ID 하드코딩 4곳은 SSOT 위반 → env 단일화.

5. 의존성 최신버전 조사

pnpm@9.12.2 / Node ≥22. transitive 취약점은 overrides로 이미 핀 고정됨. major 갭 + 어드민 성능 ROI 중심.

Next 15.5 + React 19 — 적용 가능한 2026 패턴

• ROI 상 Turbopack dev(next dev --turbo) 즉시 도입(저위험 HMR 가속) · recharts v3 · next/image remotePatterns 축소 + LCP priority · GTM을 @next/third-parties/google로 이전(메인스레드 부하↓).
• 제약 RSC / PPR / Server Actions는 불가 — Pages Router + 내장 i18n이라 App Router 전환(next-intl 등 대공사) 없이는 미지원.
• 기보유 dynamic import(어드민 9개)·ISR(홈)·TanStack Query·next/image(61파일, avif/webp)는 이미 적용 중.

6. 실행 플랜 (WSJF 우선순위)

Phase 1 — 즉시 (저비용·고효과, 어드민 체감 직결)

1. 잔여 analytics 핸들러(heatmap·page-metrics·day-detail·funnel)를 기존 RPC + getCacheShared 패턴으로 이관 — fetchAllPages 제거. 대시보드 3–5s → 수백 ms
2. 대시보드 마운트 raw fetch 4종 → useQuery + 전역 QueryClient.defaultOptions(staleTime 60s, focus off). F5·F6
3. admin/ai/analyze.ts 1000행 절단 버그 수정(집계 RPC화) — 정확성+성능. N1.2
4. recharts/AnalyticsOverview dynamic import + recharts v3, heartbeat visibility 가드. F1·F2·F7
5. sanitize-html·dompurify 보안 patch. 즉시

Phase 2 — 구조 개선

1. getPosts() select("*") 제거 + keyset cursor, VisitorList 서버 페이지네이션 + useInfiniteQuery + 가상화. N1.1·F10
2. 요청 경로 외부 LLM/Buffer 동기호출 → BullMQ 큐화 + 202 + SSE 진행률. §3.2
3. updateCategoryCounts 증분 갱신/트리거화. N1.6
4. 어드민 SSR 게이트 제거 → 정적 셸 + 미들웨어 인증. F13·F14
5. 누락 인덱스 추가(utm_visits.created_at·trgm, blog_posts trgm, audit_log text_pattern_ops). §3.4

Phase 3 — 인프라/장기

• OLTP / analytics DB 분리(readonly role, work_mem 256MB) — 무거운 집계 격리.
• CSP enforce 전환·HSTS·remotePatterns 화이트리스트.
• tailwind v4 / next 16 (i18n 마이그레이션 동반, 별도 트랙).

부록 — 분석 방법

• 대상 커밋 rinda-landing alpha (HEAD c3eb0d3f), 2026-06-19 pull 최신.
• 방법 4개 서브에이전트 병렬 정적분석(FE 성능 / 백엔드·DB / env·config / 의존성) + supabase/migrations 인덱스 정의 직접 대조 + 의존성 최신버전 npm view 조회.
• 라이브 쿼리분석 시도했으나 DB IP 화이트리스트로 외부 접속 차단(ETIMEDOUT) → 정적 대조로 대체. EXPLAIN 실측은 화이트리스트/SSH 터널 필요.
• 근거 표기 모든 발견은 file:line 원본 코드 위치 동반.