[Troubleshooting] 리액트(React) & 뷰(Vue) SPA 웹사이트 GA4 페이지뷰 누락 완벽 해결 아키텍처

"웹사이트 트래픽은 엄청난데, 구글 애널리틱스(GA4)를 보면 사용자들이 페이지를 하나만 보고 100% 이탈한 것으로 나옵니다."

리액트(React), 뷰(Vue), 넥스트(Next.js) 등으로 개발된 현대적인 SPA(Single Page Application) 웹사이트를 운영하는 퍼포먼스 마케터들이 가장 먼저 겪는 치명적인 데이터 누수 현상이다. 눈으로 볼 때는 분명히 사용자가 '메인 페이지 → 상품 페이지 → 결제 페이지'로 이동하고 있는데, GA4 대시보드에는 오직 '메인 페이지' 조회수 1건만 찍혀 있다.

이 에러를 방치하면 마케팅 부서는 어떤 페이지가 전환을 일으키는지 전혀 추적할 수 없게 되어 광고비를 허공에 날리게 된다. 본 가이드에서는 SPA 라우팅의 본질적 한계를 해체하고, 구글 태그 매니저(GTM)를 활용해 자바스크립트의 가상 이동을 완벽하게 추적하는 '가상 페이지뷰(Virtual Pageview)' 아키텍처를 단호하게 제시한다.

1단계: 핵심 원인 분석 (물리적 새로고침의 부재)

기존의 전통적인 웹사이트는 링크를 클릭할 때마다 브라우저가 '물리적으로(Physically)' 새로고침되며 구글 애널리틱스 스크립트가 매번 다시 실행되었다. 하지만 SPA는 최초 1회만 사이트를 로드한 뒤, 화면의 껍데기만 자바스크립트로 바꿔치기한다. 브라우저 입장에서는 URL 주소창의 글자만 바뀌었을 뿐 새로고침이 일어나지 않았기 때문에, GA4 스크립트는 "사용자가 계속 첫 페이지에 머물고 있다"고 착각하는 것이다.

2단계: 1차 방어선 - 향상된 측정(Enhanced Measurement)의 한계 인지

GA4 설정에 들어가면 '향상된 측정' 기능 내에 '브라우저 기록 이벤트를 기반으로 한 페이지 변경'을 추적하는 옵션이 기본적으로 켜져 있다. 초보자들은 이것만 믿고 안심하지만, 복잡한 매개변수가 붙거나 비동기(Async) 렌더링이 일어나는 기업용 SPA에서는 이 기본 기능이 30~40%의 데이터를 놓치는 결함을 보인다. 진정한 데이터 무결성을 원한다면 이 옵션을 끄고 GTM을 통한 수동 제어로 넘어가야 한다.

3단계: 완벽한 해결책 - GTM History Change 트리거 구축

구글 태그 매니저(GTM)를 열고 브라우저의 '기록(History)' 상태 변화를 감지하여 강제로 페이지뷰를 쏘아 올리는 트리거를 구축해야 한다.

[1] 트리거 생성: GTM에서 새 트리거를 만들고, 유형을 기록 변경(History Change)으로 선택한다.
[2] 태그 생성: 새 태그를 만들고 Google Analytics: GA4 이벤트를 선택한다. 이벤트 이름에 page_view를 입력한다.
[3] 이벤트 매개변수 강제 주입: SPA는 URL이 바뀌는 속도보다 화면이 렌더링되는 속도가 미세하게 다를 수 있다. 매개변수(Event Parameters)에 page_location(값: {{Page URL}}), page_title(값: {{Page Title}})을 수동으로 매핑해 주어 엉뚱한 페이지명이 기록되는 것을 차단한다.
[4] 태그와 트리거 결합: 생성한 page_view 태그에 1번에서 만든 '기록 변경' 트리거를 연결하고 배포한다.

// 개발자가 직접 DataLayer를 쏘는 가장 확실한 코드 레벨 방어망 (React 예시)
import { useEffect } from 'react';
import { useLocation } from 'react-router-dom';

function usePageTracking() {
  const location = useLocation();

  useEffect(() => {
    // 페이지 이동이 감지될 때마다 GTM 데이터레이어로 가상 페이지뷰 푸시
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({
      event: 'virtual_page_view',
      page_url: window.location.href,
      page_title: document.title
    });
  }, [location]);
}

아키텍트의 시선 (Insight)

SPA 프레임워크가 제공하는 '눈 깜짝할 새의 로딩 속도'와 '부드러운 UX'는 사용자에게 축복이지만, 데이터 엔지니어에게는 통제력을 잃게 만드는 저주가 될 수 있다. 프론트엔드의 화려한 아키텍처 전환 뒤에는 반드시 그에 걸맞은 백엔드 추적 아키텍처의 진화가 수반되어야 한다. History Change 트리거와 DataLayer 푸시를 결합하는 순간, 당신의 데이터 파이프라인은 속도와 무결성이라는 두 마리 토끼를 모두 잡게 될 것이다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

[Troubleshooting] 504 Gateway Timeout 에러 완벽 방어: 파이썬(Python) Celery와 Redis 기반 비동기 백그라운드 아키텍처

"어드민(Admin) 페이지에서 10만 건짜리 매출 데이터 엑셀 다운로드 버튼을 누르면, 화면이 30초 동안 멈춰있다가 결국 하얀 바탕에 '504 Gateway Timeout' 에러만 뜹니다." 엔터프라이즈 B2B 솔루션이나 사내 인트라넷을 개발하는 백엔드 팀이 가장 뼈아프게 마주하는 시스템의 붕괴점이다. 초보 개발자들은 이 에러를 보면 Nginx 프록시 설정 파일( nginx.conf )을 열어서 proxy_read_timeout 값을 30초에서 300초로 무식하게 늘려버린다. 하지만 이는 시한폭탄의 타이머를 늦췄을 뿐, 여러 명의 직원이 동시에 다운로드를 누르면 결국 웹 서버 워커(Worker)가 모두 고갈되어 사이트 전체가 마비되는 대참사로 이어진다. 본 가이드에서는 클라이언트를 기다리게 만드는 무능한 동기식(Synchronous) 설계의 한계를 해체하고, 메시지 브로커(Message Broker)를 활용하여 작업을 백그라운드로 우아하게 던져버리는 비동기(Asynchronous) 아키텍처를 단호하게 제시한다. 1단계: 핵심 원인 분석 (동기식 HTTP 통신의 족쇄) 웹 브라우저와 Nginx(또는 AWS ALB) 간의 HTTP 통신은 철저히 동기식이다. 사용자가 요청을 보내면, 응답이 올 때까지 브라우저와 프록시 서버는 연결 통로(Connection)를 잡고 하염없이 기다린다. 만약 DB에서 10만 건의 데이터를 조회하고 엑셀로 변환하는 데 60초가 걸린다면? 30초를 한계치로 설정해 둔 Nginx는 "이 서버는 죽었다"고 판단하고 연결을 강제로 끊어버린 뒤 클라이언트에게 504 에러를 던지는 것이다. 2단계: 완벽한 해결책 - Celery + Redis 비동기 아키텍처 해결책은 무거운 작업을 웹 서버(Django, FastAPI 등)가 직접 처리하지 않게 분리(Decoupling)하는 것이다. 웹 서버는 "작업 접수 완료!"라는 짧은 대답만 0.1초 만에 유저에게 ...
자세한 내용 보기

[Troubleshooting] AWS RDS 'Too Many Connections' 에러 완벽 방어: RDS Proxy 및 Connection Pool 아키텍처

"마케팅팀에서 전 회원에게 할인 푸시 알림을 보낸 지 정확히 1분 만에, DB가 'Too many connections' 에러를 뿜으며 서버가 전면 마비되었습니다." 트래픽이 폭주하는 이벤트 날, 데브옵스(DevOps) 엔지니어와 백엔드 개발자들이 가장 두려워하는 치명적인 에러다. 웹 서버(EC2)나 서버리스(Lambda)는 오토 스케일링(Auto-scaling)을 통해 10대에서 100대로 순식간에 복제되어 트래픽을 견뎌내지만, 가장 안쪽에 있는 데이터베이스(AWS RDS)는 그 늘어난 100대의 서버가 동시에 찌르는 수만 개의 연결(Connection) 요청을 견디지 못하고 질식사해 버린다. 초보자들은 파라미터 그룹에 들어가 max_connections 값을 무식하게 늘리거나 DB 인스턴스 사양을 올려버리는 임시방편을 택한다. 하지만 이는 메모리 고갈을 앞당겨 결국 DB 전체를 다운시키는 자살 행위다. 본 가이드에서는 애플리케이션과 DB 사이에 강력한 방파제를 세워 커넥션 풀(Connection Pool)을 통제하는 엔터프라이즈급 아키텍처를 단호하게 제시한다. 1단계: 핵심 원인 분석 (무한 확장 서버와 유한한 DB의 충돌) 관계형 데이터베이스(MySQL, PostgreSQL)는 클라이언트와 연결을 맺고 끊는 과정 자체에 엄청난 CPU와 메모리 자원을 소모한다. 특히 AWS Lambda와 같은 서버리스 환경은 치명적이다. 수천 명의 유저가 접속할 때마다 수천 개의 Lambda 컨테이너가 1초 만에 떴다가 사라지는데, 이때마다 DB에 연결을 요청하고 제대로 닫지도 않은 채 죽어버린다. 결국 버려진 '좀비 커넥션'들이 DB의 허용치를 꽉 채우고, 진짜 필요한 결제 요청은 연결 거부(Connection Refused)를 당하게 된다. 2단계: 1차 방어선 - HikariCP 최적화 및 타임아웃 튜닝 가장 먼저 백엔드 코드 레벨에서 커넥션 풀을 관리하는 프레임워크(Spring의 HikariCP,...
자세한 내용 보기