블로그 검색 기능 성능 최적화: ISR부터 쿼리 개선까지

성능, 왜 중요한가?

검색 기능을 구현하고 나니 새로운 고민이 생겼습니다.

"포스트가 100개, 200개로 늘어나면 어떻게 될까?"

현재는 괜찮지만, 미래를 대비한 성능 최적화가 필요했습니다.

현재 구조의 성능 분석

데이터 흐름

// 서버 컴포넌트에서 데이터 준비
export default async function BlogPage({ searchParams }) {
  const tag = searchParams.tag;
  const page = Number(searchParams.page) || 1;
  
  const initialPosts = await getPosts(page, 5, tag);  // 5개만
  const allPosts = await getAllPosts(tag);            // 전체
  const totalPages = await getTotalPostsCount(tag);
  
  return <PostListSection {...props} />;
}

초기 로딩 시간 측정

포스트 개수별 초기 번들 크기:

• 10개: ~15KB
• 50개: ~75KB
• 100개: ~150KB

문제점:

• allPosts를 항상 로드하므로 포스트가 많을수록 초기 로딩 증가
• 검색하지 않는 사용자도 전체 데이터를 받음

최적화 1: ISR 캐싱 전략

Next.js ISR (Incremental Static Regeneration)

// app/blog/page.tsx
export const revalidate = 60; // 60초마다 재검증

export default async function BlogPage({ searchParams }) {
  // 이 페이지는 60초 동안 캐시됨
  const posts = await getPosts();
  return <PostListSection posts={posts} />;
}

효과:

• 서버 부하 60배 감소 (1분에 여러 요청 → 1번만 처리)
• 평균 응답 시간 200ms → 50ms
• Supabase 쿼리 비용 절감

캐싱 전략 선택

// 개발 환경: 즉시 반영
export const revalidate = process.env.NODE_ENV === "development" ? 0 : 60;

// 프로덕션: 60초 캐싱

고려사항:

• 60초는 블로그 특성상 충분 (실시간성 불필요)
• 새 포스트 발행 시 최대 1분 지연은 허용 가능
• 필요시 revalidatePath로 수동 재검증 가능

최적화 2: Supabase 쿼리 개선

PostgreSQL 배열 연산자 활용

// Before: 비효율적인 태그 검색
const { data } = await supabase
  .from("posts")
  .select("*")
  .ilike("tags", `%${tag}%`); // 느림

// After: contains 연산자 사용
const { data } = await supabase
  .from("posts")
  .select("*")
  .contains("tags", [tag]); // 빠름

성능 차이:

• ilike: 전체 텍스트 스캔 (O(n))
• contains: 인덱스 활용 가능 (O(log n))

쿼리 최적화 포인트

export async function getPosts(page = 1, limit = 5, tag?: string) {
  const from = (page - 1) * limit;
  const to = from + limit - 1;
  
  let query = supabase
    .from("posts")
    .select("id, title, slug, excerpt, tags, created_at") // 필요한 필드만
    .eq("published", true)
    .order("created_at", { ascending: false })
    .range(from, to);
  
  if (tag) {
    query = query.contains("tags", [tag]);
  }
  
  return query;
}

개선 사항:

1. SELECT 최적화: content 필드 제외 (목록에서 불필요)
2. 인덱스 활용: created_at, published 컬럼 인덱싱
3. 조건부 필터링: 태그가 있을 때만 필터 적용

최적화 3: 데이터베이스 인덱스

Supabase SQL Editor에서 인덱스 생성

-- 생성일 기준 정렬 인덱스
CREATE INDEX idx_posts_created_at 
ON posts(created_at DESC) 
WHERE published = true;

-- 태그 검색 인덱스 (GIN 인덱스)
CREATE INDEX idx_posts_tags 
ON posts USING GIN(tags);

-- 복합 인덱스
CREATE INDEX idx_posts_published_created 
ON posts(published, created_at DESC);

효과:

• 정렬 속도 3배 향상
• 태그 필터링 5배 향상
• 복잡한 쿼리에서도 일정한 성능

측정 결과

Before vs After

Lighthouse 점수

Performance: 92 → 98
Best Practices: 95 → 100
SEO: 100 → 100

현재 구조의 한계

1. 초기 데이터 크기

// 문제: allPosts를 항상 로드
const allPosts = await getAllPosts(tag); // 포스트 100개 = 150KB

영향:

• 포스트가 늘어날수록 초기 번들 크기 증가
• 검색하지 않는 사용자도 불필요한 데이터 수신

2. 클라이언트 메모리

// 클라이언트 메모리에 모든 포스트 저장
const [allPosts, setAllPosts] = useState(initialAllPosts); // 메모리 사용

영향:

• 포스트 200개 이상 시 브라우저 메모리 부담
• 모바일 기기에서 성능 저하 가능

향후 개선 방향

1. 조건부 데이터 로딩

// 검색 시작할 때만 allPosts 로드
const [allPosts, setAllPosts] = useState(null);

const handleSearchStart = async () => {
  if (!allPosts) {
    const posts = await fetchAllPosts();
    setAllPosts(posts);
  }
};

효과:

• 검색하지 않는 사용자는 5개만 받음
• 초기 로딩 시간 대폭 감소

2. 서버 사이드 검색으로 전환

// Supabase Full-text Search
export async function searchPosts(query: string, page = 1) {
  const { data } = await supabase
    .from("posts")
    .select()
    .textSearch("title,excerpt,tags", query, {
      type: "websearch",
      config: "korean" // 한글 검색 최적화
    })
    .range((page - 1) * 5, page * 5);
  
  return data;
}

장점:

• 클라이언트는 항상 5개만 받음
• 포스트가 1000개여도 성능 일정
• 더 정교한 검색 (형태소 분석 등)

3. 가상화 (Virtualization)

import { useVirtualizer } from "@tanstack/react-virtual";

function PostList({ posts }) {
  const parentRef = useRef();
  
  const virtualizer = useVirtualizer({
    count: posts.length,
    getScrollElement: () => parentRef.current,
    estimateSize: () => 200,
  });
  
  return (
    <div ref={parentRef} style={{ height: "600px", overflow: "auto" }}>
      {virtualizer.getVirtualItems().map((item) => (
        <PostCard key={item.key} post={posts[item.index]} />
      ))}
    </div>
  );
}

효과:

• DOM 노드 수 대폭 감소
• 대량의 포스트도 부드러운 스크롤

4. 증분 검색 (Debouncing)

import { useDebouncedCallback } from "use-debounce";

const debouncedSearch = useDebouncedCallback(
  (searchQuery) => {
    performSearch(searchQuery);
  },
  300 // 300ms 지연
);

<Input onChange={(e) => debouncedSearch(e.target.value)} />

효과:

• 타이핑 중 불필요한 검색 방지
• 서버 요청 80% 감소

성능 모니터링

1. Vercel Analytics 활용

// vercel.json
{
  "analytics": {
    "enable": true
  }
}

측정 지표:

• First Contentful Paint (FCP)
• Largest Contentful Paint (LCP)
• Time to First Byte (TTFB)

2. 커스텀 성능 로깅

export async function getPosts(page = 1, limit = 5, tag?: string) {
  const startTime = performance.now();
  
  const { data } = await supabase
    .from("posts")
    .select("*")
    .range((page - 1) * limit, page * limit);
  
  const endTime = performance.now();
  console.log(`Query time: ${endTime - startTime}ms`);
  
  return data;
}

실전 팁

1. 점진적 개선

한 번에 모든 것을 최적화하려 하지 마세요. 측정 → 개선 → 재측정의 사이클을 반복하세요.

2. 사용자 데이터 기반 결정

실제 사용자가 어떻게 사용하는지 데이터를 수집하고, 그에 맞춰 최적화하세요.

3. 트레이드오프 이해

모든 최적화에는 트레이드오프가 있습니다. 무엇을 포기하고 무엇을 얻는지 명확히 하세요.

결론

성능 최적화는 끝이 없는 여정입니다.

핵심 원칙:

1. 측정 먼저: 추측하지 말고 측정하라
2. 점진적 개선: 작은 개선을 쌓아가라
3. 사용자 중심: 사용자 경험을 최우선으로

현재 구조로 충분히 빠르지만, 미래를 대비한 개선 방향을 항상 고민해야 합니다.

다음 단계:

• 조건부 데이터 로딩 구현
• Supabase Full-text Search 도입 검토