정적 사이트와 동적 페이지 — 같은 서비스에서 분리하는 기준

서비스를 설계하다 보면 “이 페이지는 정적으로 가도 될까, 아니면 서버가 필요할까”라는 질문을 자주 받는다. 우리 팀도 같은 고민을 오래 했다. 정답은 없지만, 반복된 실수와 수정을 거치면서 나름의 기준이 생겼다.

정적과 동적의 경계를 어디서 그을까

가장 먼저 물어야 할 것은 “이 페이지의 내용이 요청마다 달라지는가”다. 로그인 여부, 사용자 식별, 실시간 데이터 조회가 필요하다면 동적이다. 반대로 콘텐츠가 빌드 시점에 확정되고 이후 배포 전까지 변하지 않는다면 정적으로 처리할 수 있다.

그런데 현실에서는 이 경계가 흐릿하다. 예를 들어 마케팅 랜딩 페이지처럼 내용은 고정되어 있지만 A/B 테스트나 쿠키 기반 분기가 붙는 순간 정적이라고 하기 어렵다. 반대로 상품 목록처럼 동적으로 보이지만 5분 캐시를 적용하면 사실상 정적처럼 동작하는 페이지도 있다.

우리가 내린 결론은 간단하다. 요청 단위로 개인화가 필요하면 동적, 그렇지 않으면 정적으로 시작한다. 나중에 캐시 레이어를 얼마나 쌓느냐는 별개의 문제다.

같은 도메인에서 분리하는 방법

정적 페이지와 동적 페이지를 같은 서비스 아래에 두는 방법은 여러 가지다. 우리가 써본 패턴은 크게 세 가지다.

첫 번째는 라우트 기반 분리다. /docs, /blog, /about 같은 경로는 Nginx 레벨에서 정적 파일을 직접 서빙하고, /api, /dashboard, /my 같은 경로는 애플리케이션 서버로 프록시한다. 설정이 단순하고 운영이 쉽다.

두 번째는 서브도메인 분리다. www.example.com은 CDN에서 정적 파일을 내려주고, app.example.com은 서버가 처리한다. 팀이 둘로 나뉘어 개발할 때 유리하지만 인증 쿠키 공유가 까다로워진다.

세 번째는 빌드 파이프라인 분리다. 같은 코드베이스 안에서 빌드 시점에 어떤 페이지를 정적으로 렌더링할지 결정한다. Next.js의 SSG/SSR 혼용이 대표적인 예다. 유연하지만 빌드 복잡도가 올라간다.

우리가 선택한 기준

우리 팀은 서비스 초기에는 라우트 기반 분리를 기본으로 쓴다. 트래픽이 커지거나 특정 영역의 독립 배포가 필요해지면 그때 서브도메인을 검토한다.

이 선택에는 이유가 있다. 작은 팀에서 운영 복잡도를 낮추는 것이 더 중요하다고 판단했기 때문이다. 정적 영역을 분리해서 얻는 성능 이득보다, 배포 파이프라인을 단순하게 유지해서 생기는 속도 이득이 더 크다.

물론 이 판단이 영원히 옳지는 않다. 서비스 규모가 달라지면 기준도 다시 세워야 한다. 중요한 것은 분리 기준을 팀 안에서 명확하게 공유해두는 것이다. “그냥 그렇게 됐다”는 상태로 운영되다 보면, 나중에 리팩터링할 때 어디서 어떤 결정을 했는지 추적하기 어려워진다.

— by mings