planning ·
기획자를 위한 웹/앱 구조 ② 정적 웹, 동적 웹, 그리고 클라이언트/서버 사이드
“이 페이지는 정적이라 금방 돼요” 같은 말의 배경이다. 웹 페이지는 만들어지는 방식이 두 갈래다.
| 정적(static) | 동적(dynamic) | |
|---|---|---|
| 내용 | 누가 언제 봐도 같음 | 보는 사람·시점마다 다름 |
| 만드는 주체 | 미리 만들어 둔 파일을 웹서버가 그대로 전달 | 요청이 올 때마다 WAS가 데이터를 조회해 생성 |
| 예시 | 회사 소개, 이용약관, 이벤트 안내(고정), 이미지·JS·CSS | 마이페이지, 주문 내역, 검색 결과, 피드 |
| 속도·비용 | 빠르고 싸다 — CDN에 복사해두면 더 빠름 | 상대적으로 느리고 서버 부담 있음 — DB까지 다녀와야 함 |
| 기획 감각 | ”내용 고정 + 전원 동일” 화면은 정적으로 가능한지 물어볼 것 | 개인화·실시간이 필요하면 동적 — 비용을 감수하는 결정 |
요즘 웹의 표준은 절충형이다. React·Vue 같은 프레임워크로 만든 화면(정적 파일 뭉치)을 먼저 빠르게 내려주고, 사용자별 데이터만 API로 받아 채운다(SPA 방식). 그래서 1편의 시퀀스 그림처럼 “화면은 이미 떠 있고, 데이터 요청만 서버에 다녀오는” 구조가 된다.
클라이언트 사이드 vs 서버 사이드
“그건 클라(클라이언트)에서 할게요 / 서버에서 해야 해요”를 가르는 기준 — 코드가 어디에서 실행되는가다.
| 클라이언트 사이드 | 서버 사이드 | |
|---|---|---|
| 실행 위치 | 사용자 기기(브라우저·앱) | 회사 서버(WAS) |
| 담당 | 프론트엔드 (React·Vue) | 백엔드 |
| 잘하는 일 | 즉각적인 화면 반응 — 입력 검사 안내, 정렬·필터, 애니메이션 | 믿을 수 있어야 하는 일 — 결제, 권한 확인, 재고 차감, 최종 검증 |
| 한계 | 사용자가 조작 가능 — 브라우저는 사용자 손안에 있음 | 요청이 와야 실행 — 왕복 시간만큼 느림 |
기획에서 가장 중요한 함의: 클라이언트의 검사는 “친절”이고 서버의 검사가 “보안”이다. 예를 들어 쿠폰 중복 사용 방지를 화면에서만 막으면 조작으로 뚫린다 — 돈·권한이 걸린 규칙은 반드시 서버 사이드 검증이 있어야 하고, 기획서에 그렇게 명시해야 개발자가 빠뜨리지 않는다. (참고: 서버가 화면을 미리 그려 내려주는 SSR이라는 방식도 있다 — 첫 화면 속도·검색엔진 노출이 중요할 때 쓰는 선택지 정도로 알아두면 된다.)
시리즈 전체 보기: ① 요청과 응답 · ② 정적/동적 웹 · ③ 다섯 명의 등장인물 · ④ 라이브러리와 프레임워크 · ⑤ 서버의 층위와 MSA · ⑥ 주소와 환경 · ⑦ 상태코드와 통역표 · ⑧ UML과 용어사전