같은 콘텐츠, 다른 경험
Surface Layer는 고객이 브랜드를 경험하는 인터페이스다. 방문자가 보고, 클릭하고, 탐색하는 모든 것이 이 계층에 속한다.
핵심은 이것이다. 같은 콘텐츠라도 어떤 렌더링 방식을 택하느냐에 따라 속도가 달라지고, 어떤 디자인 시스템을 적용하느냐에 따라 일관성이 달라지고, 어떻게 성능을 최적화하느냐에 따라 검색 순위가 달라진다. Surface Layer의 선택이 Signal Layer의 효과에 직접 영향을 미친다.
이 글은 “AI-Ready 웹 아키텍처의 세 계층” 시리즈의 세 번째 글로, Surface Layer의 세 가지 설계 영역을 다룬다. 렌더링 아키텍처, 디자인 시스템, 성능 최적화.
1. 렌더링 아키텍처 — 콘텐츠를 어떻게 보여줄 것인가
렌더링 아키텍처는 “서버와 브라우저가 페이지를 어떻게 만드느냐”의 문제다. 세 가지 방식이 있고, 각각의 트레이드오프가 다르다.
정적 사이트 생성(SSG)
빌드 시점에 모든 페이지를 미리 만들어 CDN으로 서빙한다. 서버 연산이 없으므로 속도가 극단적으로 빠르다. Astro, Hugo, 11ty 같은 프레임워크가 대표적이다.
적합한 경우: 콘텐츠 업데이트 빈도가 낮은 기업 홈페이지, 포트폴리오 사이트, 랜딩 페이지. 페이지 수가 수백 개 이하이고, 실시간 데이터가 필요 없는 경우.
부적합한 경우: 수만 개의 제품이 실시간으로 변동하는 커머스, 사용자별 개인화가 필요한 서비스. 빌드 시간이 페이지 수에 비례하므로, 대규모 사이트에서는 빌드 시간이 문제가 될 수 있다.
Headless (CMS-프론트엔드 분리)
CMS와 프론트엔드를 API로 연결한다. CMS에서 콘텐츠를 관리하고, 프론트엔드가 API로 콘텐츠를 가져와 렌더링한다. CMS를 교체해도 프론트엔드가 유지된다. 프론트엔드를 교체해도 CMS의 콘텐츠가 보존된다.
적합한 경우: 콘텐츠를 여러 채널(웹, 앱, 키오스크)로 배포하는 경우. CMS 전환을 계획하고 있는 경우. 프론트엔드 기술 스택을 자유롭게 선택하고 싶은 경우.
부적합한 경우: 개발 리소스가 제한적인 경우. CMS의 기본 프론트엔드로 충분한 경우. 유지보수 복잡도를 최소화하고 싶은 경우.
통합형(Monolithic)
CMS와 프론트엔드가 하나의 시스템으로 작동한다. WordPress, Drupal이 대표적이다. 구축 속도가 가장 빠르고, 운영이 단순하다. 테마와 플러그인 생태계가 풍부하여 기능 확장이 용이하다.
적합한 경우: 빠른 구축이 필요한 경우. 비기술 인력이 콘텐츠를 관리하는 경우. 검증된 생태계를 활용하고 싶은 경우.
부적합한 경우: CMS와 프론트엔드를 독립적으로 진화시키고 싶은 경우. 극단적인 성능이 필요한 경우. 멀티 채널 배포가 핵심인 경우.
선택 기준
어떤 방식이 “정답”인지는 프로젝트의 맥락에 따라 다르다. 판단 기준은 세 가지다.
콘텐츠 업데이트 빈도. 월 1~2회 업데이트라면 SSG가 유리하다. 일 단위 업데이트라면 Headless나 통합형이 적합하다.
멀티 채널 배포 필요성. 웹만이 아니라 앱, 키오스크, 외부 플랫폼으로 콘텐츠를 배포해야 하면 Headless가 유리하다.
운영 리소스. 전담 개발자가 있으면 Headless의 유연성을 활용할 수 있다. 그렇지 않으면 통합형의 단순함이 유리하다.
Signal/Surface/Core 계층 분리의 장점이 여기서 드러난다. 렌더링 방식(Surface)을 바꿔도, 구조화 데이터와 검색 자산(Signal)은 보존된다. CMS(Core)를 바꿔도, 프론트엔드(Surface)는 유지된다.
2. 디자인 시스템 — 일관성의 인프라
디자인 시스템은 재사용 가능한 UI 컴포넌트를 체계화한 것이다. 버튼, 카드, 네비게이션, 폼 — 이런 요소들을 한 번 정의하고 사이트 전체에서 일관되게 사용한다.
왜 기업 웹사이트에 디자인 시스템이 필요한가
기업 웹사이트는 시간이 지나면서 페이지가 추가된다. 새로운 제품 라인이 생기고, 뉴스룸에 새 콘텐츠 유형이 추가되고, 캠페인 랜딩페이지가 만들어진다. 디자인 시스템 없이 이 확장이 진행되면, 각 페이지가 조금씩 다른 스타일로 만들어진다. 1년 후에는 브랜드 일관성이 무너진다.
디자인 시스템이 있으면 이 문제가 해결된다. 새 페이지를 추가할 때 기존 컴포넌트를 조합하면 된다. 전면 리디자인 없이도 새 콘텐츠 유형을 빠르게 수용할 수 있다. 운영 단계에서의 확장 비용이 극적으로 줄어든다.
기업 웹사이트의 핵심 컴포넌트
| 컴포넌트 | 역할 | 재사용 빈도 |
|---|---|---|
| Hero | 페이지 최상단, 핵심 메시지 전달 | 모든 주요 페이지 |
| Card | 콘텐츠 목록(솔루션, 프로젝트, 인사이트) | 매우 높음 |
| CTA Block | 전환 유도(문의, 상담 신청) | 모든 페이지 하단 |
| Navigation | 글로벌 내비게이션 + 브레드크럼 | 전체 |
| Feature Grid | 특장점, 서비스 구조 설명 | 솔루션, 전문성, 산업 페이지 |
| FAQ Accordion | 질문-답변 | 솔루션, 산업 페이지 |
이 6개 컴포넌트가 기업 웹사이트 페이지의 80% 이상을 구성한다. 나머지 20%는 페이지 특화 컴포넌트다.
3. 성능 최적화 — 속도는 Signal Layer에 영향을 미친다
Core Web Vitals는 Google이 정의한 사용자 경험 지표다. 이 지표가 Surface Layer에 속하는 이유는 “사용자가 페이지를 경험하는 속도”를 측정하기 때문이다. 그러나 그 영향은 Signal Layer까지 미친다.
LCP(Largest Contentful Paint) — 2.5초 이내. 페이지의 가장 큰 콘텐츠 요소가 렌더링되는 시간이다. 히어로 이미지, 메인 텍스트 블록이 대상이다. LCP가 느리면 사용자 이탈률이 올라가고, Google 검색 순위에서 불이익을 받는다.
CLS(Cumulative Layout Shift) — 0.1 이내. 페이지 로딩 중 레이아웃이 밀리는 정도다. 이미지에 width/height를 명시하지 않거나, 웹폰트 로딩이 지연되면 CLS가 올라간다.
INP(Interaction to Next Paint) — 200ms 이내. 사용자가 클릭, 탭, 키 입력을 했을 때 다음 프레임이 렌더링되기까지의 시간이다. JavaScript 실행이 메인 스레드를 점유하면 INP가 느려진다.
성능 최적화 실전 원칙
이미지 최적화. WebP/AVIF 포맷 사용, 적절한 해상도(뷰포트 대비), lazy loading 적용, width/height 명시.
JavaScript 최소화. 필요한 페이지에만 필요한 스크립트를 로드한다. 전역으로 무거운 라이브러리를 로드하면 모든 페이지의 성능이 저하된다.
폰트 최적화. font-display: swap으로 FOUT를 허용하되 CLS를 방지한다. 사용하는 글리프만 서브셋으로 추출한다. 한국어 폰트는 파일 크기가 크므로 서브셋이 특히 중요하다.
CDN 활용. 정적 자산(이미지, CSS, JS)을 CDN에서 서빙한다. SSG와 CDN의 조합이 가장 빠른 성능을 제공한다.
Surface Layer 설계 체크리스트
렌더링 아키텍처:
- 콘텐츠 업데이트 빈도, 멀티 채널 필요성, 운영 리소스를 기준으로 방식을 선택했는가
- 선택한 방식이 Signal Layer(구조화 데이터, 크롤링)와 호환되는가
디자인 시스템:
- 핵심 컴포넌트(Hero, Card, CTA, Navigation, Feature Grid, FAQ)가 정의되어 있는가
- 새 페이지 추가 시 기존 컴포넌트로 조합할 수 있는가
성능:
- LCP 2.5초 이내, CLS 0.1 이내, INP 200ms 이내를 충족하는가
- 이미지 포맷 최적화(WebP/AVIF)가 적용되어 있는가
- CDN이 적용되어 있는가
다음 글에서
이 글은 “AI-Ready 웹 아키텍처의 세 계층” 시리즈의 세 번째 글이다. 다음 글에서는 Core Layer — 콘텐츠가 작동하는 기반을 다룬다. CMS 설계, 콘텐츠 모델링, 클라우드 인프라의 설계 원칙을 정리할 예정이다.