정적 사이트를 공개 링크로 만드는 것은 첫 단계일 뿐입니다. 그다음에 더 중요한 질문이 생깁니다. 누가 실제로 이 링크를 열었을까요?
방문이 어디서 왔는지, 어떤 페이지가 먼저 열렸는지, 휴대폰에서 보는 사람이 많은지, 어느 국가가 보이는지, 이미지나 PDF, 영상, 폰트가 대역폭을 많이 쓰고 있는지도 확인해야 합니다.
처음부터 무거운 분석 도구를 붙일 필요는 없습니다. 공개 직후에는 프로젝트와 연결된 기본 통계만으로도 다음 결정을 내릴 수 있는 경우가 많습니다.
사이트가 답해야 하는 질문부터 정합니다
모든 숫자가 중요해 보이면 통계는 금방 흐려집니다.
정적 사이트는 보통 목적이 분명합니다. 온라인 포트폴리오, 온라인 이력서, 랜딩 페이지, 클라이언트 미리보기, 문서 사이트, 학생 프로젝트, AI 생성 웹사이트, PDF 공개 페이지처럼 처음 봐야 할 데이터가 서로 다릅니다.
| 사이트 유형 | 먼저 물어볼 질문 | 우선 볼 데이터 |
|---|---|---|
| 온라인 포트폴리오 | 클라이언트나 채용 담당자가 열었나? | 방문자, 유입 경로, 상위 페이지, 기기 |
| 랜딩 페이지 | 어떤 채널이 방문을 만들었나? | 유입 경로, UTM 링크, 상위 페이지, 국가 |
| 온라인 이력서 | 휴대폰에서도 읽기 좋은가? | 기기, 브라우저, 페이지 조회 |
| 클라이언트 미리보기 | 최신 버전 링크가 열렸나? | 최근 방문, 국가, 기기, 페이지 |
| 문서 사이트 | 방문자가 올바른 문서에 도착했나? | 상위 페이지, 유입 경로, 이상한 경로 |
| 이미지나 PDF가 많은 페이지 | 파일 무게가 이미 보이는가? | 대역폭, 상위 페이지, 리소스 크기 |
사이트가 무엇을 검증해야 하는지 모르면 대시보드가 대신 결정해 주지 않습니다. 선이 올라가거나 내려가는 것은 보이지만, 경로를 고칠지, 문구를 바꿀지, 링크 공유 방식을 바꿀지, 도메인을 연결할지 판단하기 어렵습니다.
방문과 방문자는 다른 신호입니다
방문이나 페이지 조회는 페이지가 몇 번 로드되었는지를 보여줍니다. 방문자는 얼마나 많은 사람, 브라우저 또는 세션이 사이트에 도달했는지에 가까운 추정치입니다.
둘 다 필요하지만 같은 의미는 아닙니다.
공개 직후에는 본인, 팀, 고객, 교수자가 같은 링크를 여러 번 새로고침할 수 있습니다. 페이지 조회는 늘지만 실제 외부 관심이 그만큼 늘어난 것은 아닐 수 있습니다. 반대로 조회 수는 많지 않아도 여러 유입 경로와 기기에서 들어왔다면 포트폴리오나 이력서, 프로토타입에는 의미 있는 반응일 수 있습니다.
| 지표 | 보기 좋은 것 | 흔한 오해 |
|---|---|---|
| 페이지 조회 | URL별 활동 | 내부 테스트를 실제 관심으로 읽기 |
| 방문자 | 대략적인 도달 범위 | 정확한 사람 수로 받아들이기 |
| 상위 페이지 | 실제로 열린 URL | 홈페이지 통계만 보기 |
| 대역폭 | 파일 무게와 요금제 압박 | 방문이 늘고 나서야 무거운 페이지를 알아차리기 |
도구마다 이름은 다릅니다. Google Analytics 4에서는 page_view가 페이지 로드 시 전송되는 이벤트입니다. Plausible이나 Cloudflare Web Analytics 같은 가벼운 도구는 페이지 조회, 방문자, referrer, 국가, 기기, 브라우저를 더 직접적으로 보여주는 편입니다.
중요한 것은 이름보다 함께 읽는 방식입니다. 페이지 조회, 방문자, 유입 경로, 상위 페이지를 같이 봐야 공개 후 반응을 더 정확하게 이해할 수 있습니다.
DeployPages의 프로젝트 통계는 페이지 조회, 추정 방문자, 대역폭, 상위 페이지, referrer, 국가, 기기, 브라우저, 운영체제, 최근 방문을 보여줍니다. 막 공개한 정적 사이트라면 이 첫 번째 층만으로도 충분한 경우가 많습니다.
유입 경로는 링크 배포가 맞았는지 보여줍니다
작은 사이트 공개가 실패하는 이유는 페이지 자체가 아닐 때가 많습니다. 링크를 본 사람이 너무 적거나, 잘못된 곳에 공유되었을 수 있습니다.
유입 경로는 이 둘을 구분하는 데 도움이 됩니다.
| 보이는 상황 | 의미할 수 있는 것 | 다음 단계 |
|---|---|---|
| direct가 많음 | 이메일, 메신저, QR 코드, 복사된 링크, referrer 누락 | 다음 공유에는 UTM 사용 |
| 특정 소셜 채널이 큼 | 게시물이나 재공유가 작동함 | 해당 트래픽의 페이지와 기기 확인 |
| 검색 유입이 보이기 시작함 | 최초 공유 범위를 넘어 발견되기 시작함 | title, description, 도메인 확인 |
| 내부 도메인이나 고객 도메인 | 검토 트래픽이 있음 | 공개 반응과 섞어 읽지 않기 |
| 이상한 referrer | 잡음, bot, 의미 낮은 방문 | 그 신호만 보고 페이지를 바꾸지 않기 |
같은 페이지를 이메일, 카카오톡, LinkedIn, QR 코드, 프로필 링크에 공유한다면 URL에 이름을 붙여 두는 것이 좋습니다. UTM 링크 빌더는 source, medium, campaign을 맞춰 링크를 만들 때 유용합니다.
완벽한 attribution이 목표는 아닙니다. 나중에 “이 방문이 어디서 왔지?”를 줄이는 것이 목표입니다.
기기와 브라우저는 어디서 테스트할지 알려줍니다
정적 사이트는 노트북에서 만들고 휴대폰에서 열리는 경우가 많습니다.
데스크톱에서 깔끔한 포트폴리오 그리드가 모바일에서는 긴 목록처럼 보일 수 있습니다. 랜딩 페이지의 주요 버튼이 큰 화면에서는 보이지만 휴대폰에서는 너무 아래로 내려갈 수 있습니다. HTML 이력서는 데스크톱 Chrome에서 괜찮아도 iPhone Safari에서는 답답하게 보일 수 있습니다.
기기, 브라우저, 운영체제 통계가 디자인 정답을 대신 내리지는 않습니다. 대신 어디서 먼저 테스트해야 하는지 알려줍니다.
방문 대부분이 모바일이라면 전체 문구를 다시 쓰기 전에 실제 공개 링크를 휴대폰에서 열어 보세요. iOS Safari가 자주 보이면 이미지, 영상, 폰트 크기, 터치 영역을 그 환경에서 확인하세요. 클라이언트 검토가 오래된 데스크톱 브라우저에서 온다면 검토가 호환성 대화로 바뀌지 않도록 복잡한 상호작용을 줄이는 편이 나을 수 있습니다.
일반적인 mobile-first 구호보다 이 데이터가 더 실용적입니다. 방금 공개한 그 사이트의 사용 환경을 말해 주기 때문입니다.
상위 페이지는 가정을 깨뜨립니다
공개한 사람은 보통 하나의 진입점을 생각합니다. 방문자는 다른 문으로 들어올 수 있습니다.
누군가 하위 페이지 링크를 직접 공유합니다. QR 코드가 캠페인 경로를 가리킵니다. 오래된 문서에 이전 URL이 남아 있습니다. 검색이 특정 글을 먼저 찾습니다. AI 생성 웹사이트에 테스트 경로가 남아 있을 수도 있습니다.
상위 페이지는 특히 다음 상황에서 봐야 합니다.
- 새 버전을 업로드한 뒤.
- 미리보기 링크에서 커스텀 도메인으로 옮긴 뒤.
- GitHub Pages, 오래된 포트폴리오, 문서 사이트에서 이전한 뒤.
- 이메일, 소셜, QR, 광고에 서로 다른 링크를 쓴 뒤.
index.html, 내비게이션, 파일 경로를 바꾼 뒤.- PDF, 이미지, 다운로드 파일을 공개한 뒤.
하위 페이지가 가장 많이 열린다고 해서 항상 나쁜 것은 아닙니다. 그 페이지가 더 좋은 진입점일 수 있습니다. 문제는 오래된 경로, 깨진 다운로드, 아직 공개할 준비가 안 된 페이지가 위에 있을 때입니다.
대역폭은 늦게 보면 문제가 됩니다
대역폭은 방문자 수보다 덜 눈에 띄지만, 정적 사이트에서는 비용과 성능을 보여주는 실용적인 신호입니다.
큰 이미지, PDF, 배경 영상, 무거운 폰트, 압축하지 않은 스크린샷은 세 사람이 미리보기를 열 때는 별문제가 없어 보입니다. 하지만 링크가 캠페인, 포트폴리오, 인쇄된 QR 코드, 많이 공유되는 게시물에 들어가면 상황이 달라집니다.
다음 경우에는 대역폭을 확인하세요.
- 사진, 스크린샷, 제품 이미지가 많습니다.
- PDF, 메뉴, 발표 자료, 미디어 파일을 같은 프로젝트에서 제공합니다.
- 캠페인으로 짧은 트래픽 피크가 생길 수 있습니다.
- 프로젝트가 요금제 한도에 가까워집니다.
- 방문자가 주로 모바일에서 들어옵니다.
대역폭은 어떤 파일이 너무 큰지 자동으로 알려 주지는 않습니다. 경고 신호로 봐야 합니다. 이후 이미지 크기, 압축, lazy loading, 영상, 폰트, 큰 파일의 위치를 점검해야 합니다.
먼저 내장 통계, 나중에 더 깊은 분석
Google Analytics, Plausible, Matomo, Fathom, Simple Analytics, PostHog 모두 필요한 상황이 있습니다. 핵심은 언제 붙이느냐입니다.
공개 직후 질문은 보통 단순합니다.
- 링크가 열리는가?
- 방문은 어디서 왔는가?
- 어떤 URL이 열렸는가?
- 모바일과 데스크톱 중 어디가 많은가?
- 예상한 국가에서 방문이 오는가?
- 대역폭은 정상인가?
내장 통계는 이 첫 번째 층에 잘 맞습니다. 업로드한 프로젝트와 연결되어 있기 때문입니다. 폴더를 업로드하고 HTTPS 링크를 받은 뒤 공유하면, 정적 파일에 별도 스크립트를 추가하지 않아도 초기 반응을 볼 수 있습니다.
버튼 클릭, 퍼널, 전환, A/B 테스트, 유료 캠페인, 로그인 사용자, 제품 이벤트, 이커머스 데이터를 봐야 한다면 더 전문적인 분석 도구를 계획해서 붙이는 편이 맞습니다.
두 층을 분리하면 판단이 쉬워집니다. 게시 통계는 사이트가 보이고 있는지를 답합니다. 제품 분석은 도착한 사람이 무엇을 하는지를 답합니다.
개인정보, 쿠키, 외부 스크립트
한국에서도 웹사이트 통계는 쿠키, 외부 스크립트, 개인정보 처리방침과 떨어져 있지 않습니다.
출시 반응을 보는 기본 통계와 완전한 추적 설정은 같은 것이 아닙니다.
| 층 | 주된 질문 | 예시 |
|---|---|---|
| 게시 통계 | 공개 링크가 열렸는가? | 페이지 조회, referrer, 기기, 국가, 대역폭 |
| 마케팅 또는 제품 분석 | 사용자가 사이트 안에서 무엇을 했는가? | 이벤트, 전환, 세그먼트, A/B 테스트, 광고 |
DeployPages는 프로젝트에 연결된 첫 번째 통계를 제공합니다. 이것이 개인정보 처리방침 검토를 대체하지는 않습니다. Google Analytics, 광고 픽셀, 히트맵, 채팅, 외부 폼, 기타 스크립트를 추가한다면 어떤 데이터가 수집되는지, 브라우저에 무엇이 저장되는지, 방문자에게 무엇을 알려야 하는지 확인해야 합니다.
작은 페이지를 법무 프로젝트로 만들자는 뜻은 아닙니다. 설명되지 않은 측정 도구가 조용히 들어가지 않도록 하자는 뜻입니다.
첫 주에는 이렇게 봅니다
통계를 하루 종일 볼 필요는 없습니다. 정적 사이트라면 몇 번의 확인만으로도 충분합니다.
| 시점 | 볼 것 | 이유 |
|---|---|---|
| 첫 1시간 | 페이지가 열리는지, 404, 이미지와 스크립트 | 더 많이 공유되기 전에 수정 |
| 첫날 | 유입 경로, 기기, 상위 페이지 | 배포와 레이아웃이 방문자와 맞는지 확인 |
| 첫 주 | 추이, 국가, 대역폭, 계속 열리는 페이지 | 개선, 유지, 교체 여부 결정 |
| 새 버전 후 | 상위 페이지와 최근 방문 | 유효한 URL이 깨지지 않았는지 확인 |
| 도메인 연결 후 | direct, 검색, 이전 URL | 도메인이 미리보기 링크를 대체했는지 확인 |
목표는 보고서를 만드는 것이 아닙니다. 다음 행동을 정하는 것입니다. 경로를 고치고, 이미지를 압축하고, 공유한 링크를 바꾸고, 도메인을 연결하거나 더 깊은 분석 도구를 붙일지 판단하면 됩니다.
DeployPages에서는 이렇게 이어집니다
DeployPages는 통계를 게시 흐름의 일부로 다룹니다.
정적 폴더, ZIP, 프런트엔드 빌드, AI 생성 웹사이트, PDF가 포함된 페이지, 포트폴리오를 공개한 뒤 프로젝트에서 페이지 조회, 추정 방문자, 유입 경로, 상위 페이지, 국가, 기기, 브라우저, 시스템, 대역폭, 최근 방문을 확인할 수 있습니다.
같은 프로젝트는 이후 커스텀 도메인, 비밀번호 보호, 이전 버전으로 복원, CLI 배포, 통계로 확장할 수 있습니다.
많은 정적 사이트에는 이 순서가 더 자연스럽습니다. 먼저 공개하고, 실제 신호를 읽고, 그다음 도메인, 최적화, 팀 작업, 더 깊은 분석 도구가 필요한지 결정합니다.