[경기문화재단] 아트경기 기술스택 마이그레이션

프로젝트 개요

• 아트경기 사이트에서 사이트 로딩이 현저히 느려지는 성능 문제 발생

• 성능 개선 작업을 요구하여 아키텍처 단의 최적화와 전체 페이지 코드 재작성

문제 상황: 렌더링 전략이 DB 쿼리까지 침범

+_+

+_+

+_+

1. 기존의 구현이 “모든 작가(상세 포함) 데이터를 한 번에 가져온 후 클라이언트 라우트”하는 식으로 되어 있었습니다.

   1. 최초 접근이 상세 페이지인 경우에도 모든 작가 데이터를 로드하게 됩니다.

2. 2025년에 기존 아카이브된 작가들이 모두 업로드되었고, 업로드된 모든 작가 데이터의 용량은 3.07MB (gzip 454KB) 였습니다.

strapi.find('authors', {
  pageSize: 1000, // 모든 작가
  populate: {
    featured_works: { populate: 'media' }, // 작가마다 작품·이미지 전체
    projects: ...
  }
})

SELECT * FROM authors WHERE published_at IS NOT NULL ORDER BY name LIMIT 1000;
SELECT * FROM authors_components WHERE author_id IN (...전체...) AND field='featured_works';
SELECT * FROM components_author_artworks WHERE id IN (...작가×작품...);
SELECT * FROM files_related_morphs WHERE related_type='components_author_artworks' AND ...;  -- 가장 비싼 단계
SELECT * FROM files WHERE id IN (...모든 작품 이미지...);

해결 과정

1. 쿼리 최적화: 리스트용 쿼리와 상세 페이지용 쿼리 분리

+_+

+_+

2. 2개의 SvelteKit 및 Strapi CMS를 1개의 Next.js에 통합

+_+

1. Payload CMS의 우수한 성능: 현저히 빠른 CRUD 속도

2. Payload CMS의 구조상 이점: 프론트엔드 - CMS - DB 라는 불필요한 HTTP 통신 Hop이 사라지고, 타입 및 스키마도 자동 관리됩니다.

3. 두 앱이 비즈니스 로직과 데이터 모델을 공유하고 표현 계층만 상이: 반응형 단일 앱으로 통합하는 편이 중복 코드와 배포, 검증 비용을 줄이는 데 유리했습니다.

2-2. Why Payload CMS?

2-3. 부가적인 개선

• tailwind CSS와 Pure CSS가 혼재되어 있던 기존 코드를 Vanilla Extract로 모두 통합했습니다.

  • tailwind CSS는 강력한 도구이지만 학습곡선이 필요합니다. Vanilla Extract는 강제로 CSS를 파일 단위로 분리시켜 컨벤션을 유지하고, 강력한 타입 지원이 가능해 채택했습니다.

• Payload CMS까지 Next.js 앱에 통합되면서 3개 앱 + shared module의 모노레포 구조였던 것이 단일 앱으로 통합되면서 프로젝트 전체의 구조가 간결해졌습니다.

성과

1. 성능 지표의 비약적 향상

+_+

2. 운영 비용 절감

• 인스턴스 4GB x2 + 8GB x1 → 4GB x1

• 월 270,000원 → 월 78,000원으로 71.1%의 인스턴스 운영비 절감

회고

• 이 구조 문제는 2025년 인수 때부터 염두에 두던 것으로, 첫 해에는 인프라 안정화를 우선했고 올해 클라이언트의 성능 개선 요청과 함께 공수를 확보해 진행했습니다.

• 성능 문제의 최초 원인은 데이터 조회량처럼 보였지만, 실제로는 렌더링 전략, 배포 구조, CMS 통신 방식이 모두 연결된 문제였습니다. 쿼리 최적화보다 아키텍처를 현재 요구사항에 맞게 재설계한 작업입니다.

• 풀스택 프로젝트에서는 프론트엔드 렌더링 설계가 DB 쿼리까지 전이되지 않도록, 계층별 설계를 의식적으로 분리해야 한다는 원칙을 얻었습니다.