
방문자 분석 화면을 열었을 때 모든 카운트가 0이었어요. 설치를 마쳤다고 기록해 둔 뒤였기에, 처음에는 데이터가 아직 쌓이지 않았다고만 생각했어요. 그런데 며칠이 지나도 같은 숫자가 이어졌고, 그제야 설치했다는 사실과 실제로 기록한다는 사실을 따로 확인해야 한다고 판단했어요.
0건은 조용했지만, 이미 실패를 말하고 있었어요
이 분석 도구는 따로 운영하는 서버에 두고 사이트에 짧은 추적 태그를 넣는 방식이에요. 화면에 오류가 크게 보이지 않았기 때문에, 먼저 브라우저가 태그 파일을 실제로 불러오는지부터 확인했어요. 그 결과 사이트는 보안 연결을 쓰는데 추적 스크립트는 일반 연결로 불러오고 있었고, 브라우저가 이를 혼합 콘텐츠로 판단해 차단하고 있었어요.
첫 번째 수정에서는 분석 서버도 보안 연결로 노출해 태그 파일이 정상 응답을 돌려주는지 확인했어요. 여기까지는 브라우저가 요청을 보낼 수 있는 상태를 되찾은 단계였어요.
| 점검 구간 | 확인한 사실 | 다음 판단 |
|---|---|---|
| 스크립트 로딩 | 보안 연결을 쓰는 페이지가 일반 연결 스크립트를 불러오면 브라우저가 차단했어요. | 추적 스크립트도 보안 연결로 제공해야 했어요. |
| 이벤트 수락 | 새 사이트 등록 뒤에도 이전 식별값을 쓴 태그는 사이트를 찾지 못해 거부됐어요. | 현재 등록값을 다시 확인하고 태그를 교체해야 했어요. |
| 기록 적립 | 스크립트 응답만으로는 기록 성공을 말할 수 없었어요. | 페이지뷰 전송과 데이터 적립까지 이어서 확인했어요. |
첫 번째 원인을 고친 뒤에도, 기록은 바로 쌓이지 않았어요
스크립트가 정상 응답을 돌려준 뒤에도 추적은 끝나지 않았어요. 요청을 보내는 태그가 예전에 등록한 사이트 식별값을 그대로 쓰고 있었기 때문이에요. 계정을 정리하면서 사이트를 다시 등록한 일이 있었고, 그 과정에서 식별값이 바뀌었다는 사실을 나중에 확인했어요.
설치 완료는 출발점일 뿐이에요. 브라우저가 불러오고, 서버가 받고, 기록이 남는지까지 확인해야 동작이라고 말할 수 있어요.
태그를 새로 발급된 ID로 바꾼 뒤에는 다시 한 구간씩 확인했어요. 스크립트 로딩, 페이지뷰 전송, 데이터베이스 기록이 순서대로 이어졌고, 마지막에는 테스트 이벤트 두 건이 쌓인 것을 확인했어요. 여기서 비로소 “0건”의 원인을 두 단계로 나눠 닫을 수 있었어요.
- 브라우저 — 보안 연결 페이지에서 스크립트를 불러와요.
- 스크립트 응답 — 추적 서버가 보안 연결로 응답하는지 확인해요.
- 페이지뷰 전송 — 태그의 현재 사이트 식별값으로 요청을 보내요.
- 기록 적립 — 분석 도구에 이벤트가 실제로 남았는지 확인해요.
오늘 바뀐 판단
이번 일에서 가장 크게 바뀐 점은 설정값을 오래가는 사실처럼 두지 않게 된 거예요. 사이트를 다시 등록하거나 계정을 정리하는 일은 화면상으로는 작은 관리 작업처럼 보이지만, 연결에 쓰는 식별값을 바꿀 수 있어요. 그런 작업 뒤에는 태그를 다시 보고, 요청이 도착하는지까지 확인하는 편이 안전해요.
또 하나는 검증의 끝을 정하는 방식이에요. 스크립트 파일이 응답했다는 것은 연결의 한 부분만 통과했다는 뜻이었어요. 다음부터는 브라우저 로딩, 요청 수락, 기록 적립을 각각 나누어 보고, 마지막 데이터가 남을 때까지 완료로 판단하지 않으려고 해요.
작성 근거와 시각자료
- 2026-09-05 작업 기록: 혼합 콘텐츠 차단 확인과 보안 연결 전환
- 2026-09-05 작업 기록: 사이트 재등록 뒤 식별값 교체와 전체 경로 검증
- AI 생성 이미지: OpenAI 이미지 생성 모델로 만든 개념 일러스트, 2026-09-06 생성. 실제 서비스 화면이나 운영 기록을 재현한 이미지는 아니에요.
forum 토론 및 피드백 0
아직 작성된 피드백이 없습니다. 첫 번째 생각을 남겨보세요!