
동적 웹 앱(SaaS)과 정적 블로그의 완전 분리 아키텍처: 색인 누락과 보안 충돌을 해결한 경험
웹 서비스를 구축할 때 흔히 저지르는 구조적 실수 중 하나는, 복잡한 인증과 상태 관리가 필요한 **동적 웹 대시보드(SaaS Application)**와 검색 엔진 최적화가 필수적인 **기술 콘텐츠 블로그(Static Blog)**를 단일 저장소와 단일 빌드 파이프라인에 한데 섞어 넣는 것입니다.
초기 프로젝트 구조는 모든 기능이 Next.js 단일 프로젝트 안에 공존했습니다.
하지만 서비스가 성장하면서 이 단일 구조는 검색 엔진 색인 누락, 인증 쿠키 간섭, 빌드 시간 폭증이라는 세 가지 구조적 재앙을 불러왔습니다.
검색 엔진 크롤러가 본 동적 대시보드의 한계
우리의 웹 앱은 클라이언트 사이드 렌더링(CSR)과 SWR 데이터 페칭, 그리고 복잡한 모달 라우팅에 크게 의존했습니다.
사용자에게는 매우 부드러운 반응형 UX를 제공했지만 검색 엔진 크롤러에게는 재앙이었습니다.
Googlebot은 자바스크립트를 실행할 수 있지만, 복잡한 API 권한 검증이나 인증 가드가 걸려 있는 페이지는 즉시 크롤링을 포기합니다.
그 결과, 정성스럽게 작성한 분석 글들이 웹 앱 내부의 모달이나 인증 경로에 묶여 검색 엔진에 전혀 색인되지 못하는 현상이 발생했습니다.
| 비교 기준 | 단일 웹 앱 통합 구조 (과거) | 정적 미디어 완전 분리 구조 (현재) |
|---|---|---|
| 블로그 빌드 방식 | Next.js 동적 서버 사이드 렌더링 | Astro 기반 완전 정적 HTML 생성 (SSG) |
| 검색 엔진 색인 | 자바스크립트 렌더링 지연으로 누락 빈발 | 0.8초 정적 컴파일, Schema.org 100% 인식 |
| 배포 및 인프라 | Vercel 단일 풀스택 인스턴스 | Cloudflare Pages 독립 엣지 배포 |
| 보안 격리 | 앱 쿠키와 블로그 방문자 세션 간섭 | 도메인 및 환경변수 완전 격리 |
Astro를 통한 순수 정적 테크 미디어로의 전환
우리는 블로그 영역을 완전히 독립된 저장소(Lumen-blog)로 분리하고, 정적 사이트 생성기(SSG)인 Astro를 도입했습니다.
- 자바스크립트 제로 번들(Zero-JS by Default): 불필요한 클라이언트 사이드 런타임을 배제하고, 순수한 시맨틱 HTML과 최적화된 WebP 이미지만으로 페이지를 생성합니다.
- 독립된 사이트맵 자동화:
sitemap-index.xml과robots.txt가 빌드 시점에 자동으로 생성되어 검색 엔진에 실시간 반영됩니다. - 구조화된 메타데이터(Schema.org): 모든 테크 아티클에
Article및Person스키마를 JSON-LD로 주입하여 E-E-A-T 신뢰도를 극대화했습니다.
---
// Astro 기반 정적 아티클 컴포넌트의 깔끔한 메타데이터 주입 예시
const { title, description, pubDate, heroImage } = Astro.props;
---
<article class="prose prose-invert max-w-none">
<header>
<h1 class="text-3xl font-bold tracking-tight">{title}</h1>
<time datetime={pubDate.toISOString()}>{formatKSTDate(pubDate)}</time>
</header>
<slot />
</article>
시스템 분리가 가져다준 엔지니어링 이점
웹 앱과 블로그를 물리적으로 분리한 결과, 대시보드 백엔드가 대량의 배치 크롤링을 돌리거나 DB 유지보수를 진행하더라도 블로Cloudflare 엣지 네트워크에서 100% 가동률을 유지합니다.
블로그의 빌드 속도는 전체 47개 페이지 기준 0.8초 만에 완료되는 놀라운 성능을 보여줍니다.
서로 다른 성격의 워크로드는 아키텍처 수준에서 분리되어야 합니다.
동적 상호작용은 Next.js 웹 앱에 맡기고, 지식의 기록과 지식 전달은 가벼운 정적 미디어에 맡기는 것.
이것이 1인 빌더가 시스템 복잡도를 낮추고 유지보수 비용을 최소화하는 최선의 아키텍처입니다.
참고 자료:
