GA4 분석을 전체 페이지에 추가해 사용자 행동 추적
목차
GA4 분석 도구를 프로덕션 애플리케이션에 연동했다. 기본 레이아웃 파일에 환경 변수 기반 설정을 통해 배포 환경마다 유연하게 구성할 수 있도록 구현했는데, 여기서 배운 몇 가지 설계 관점을 정리해본다.
왜 GA4인가
사실 이 작업이 필요했던 배경은 단순했다. 팀에서 사용자가 서비스를 어떻게 사용하는지를 더 이상 추측으로만 판단할 수 없게 됐기 때문이다. 초기 단계에는 로그와 피드백으로도 충분했지만, 사용자가 늘어나고 기능이 복잡해지면서 정확한 행동 데이터가 필수가 됐다.
GA4를 선택한 이유는 한국에서 가장 광범위하게 지원되고, 기존 분석 도구들과의 통합도 좋으며, 학습 곡선도 그리 가파르지 않다는 점 때문이었다. 팀원들이 대시보드를 직접 만지고 이해할 수 있어야 하는데, GA4는 그런 접근성에서 강점이 있다.
Base.astro에 주입한 이유
GA4 스크립트를 어디에 넣을지는 예상보다 중요한 결정이었다. 한 두 페이지에만 넣는 것이 아니라 모든 페이지에서 사용자 행동을 추적해야 하기 때문이다.
| 위치 선택 | 장점 | 단점 |
|---|---|---|
| 각 페이지 .astro 파일 | 페이지별 커스터마이징 가능 | 중복, 유지보수 어려움 |
| Base 레이아웃 (선택) | 한 곳만 관리, 모든 페이지 자동 적용 | 레이아웃 의존성 증가 |
| 별도 레이아웃 컴포넌트 | 유연함 | 또 다른 관리 포인트 |
Base.astro는 Astro 프레임워크에서 말하는 "루트 레이아웃" 같은 역할을 한다. 거기에 GA4 스크립트를 한 번 주입하면 이 레이아웃을 사용하는 모든 자식 페이지에 자동으로 적용된다. 즉, 새로운 페이지를 추가할 때마다 GA4 설정을 신경 쓸 필요가 없다. 한 번의 설정이 조직적으로 확산되는 구조다.
이런 접근은 코드 리뷰할 때도 깔끔했다. "이 페이지에 GA4가 빠졌네?"라는 질문이 자동으로 사라진다.
환경 변수 기반 설정의 중요성
OPSVORO_GA_ID라는 환경 변수를 사용한 것이 이 구현에서 가장 중요한 부분이다. 왜냐하면 로컬 개발, 스테이징, 프로덕션이 서로 다른 GA4 ID를 써야 하기 때문이다.
<!-- Base.astro 예시 -->
<head>
<!-- ... 다른 헤더 -->
{import.meta.env.OPSVORO_GA_ID && (
<script async
src={`https://www.googletagmanager.com/gtag/js?id=${import.meta.env.OPSVORO_GA_ID}`}
/>
)}
</head>
이렇게 하면:
- 로컬에서는 비활성화 → 개발 중 불필요한 분석 데이터 오염 방지
- 스테이징에는 테스트용 ID → 실 서비스 데이터와 분리
- 프로덕션에는 메인 ID → 실제 사용자 데이터 수집
코드 한두 줄로 이 모든 것을 관리할 수 있다는 게 좋다. 보안 측면에서도 GA4 ID 자체는 공개되어도 문제없지만, 환경 변수로 관리하는 습관은 나중에 정말 민감한 정보를 다룰 때 자연스럽게 적용된다.
회고: 라이브러리 라이센싱 vs 직접 구현
사실 Google에서 공식 Astro 통합 라이브러리를 제공하기도 한다. 팀에서 고민했던 부분은 "그 라이브러리를 쓸까, 아니면 직접 스크립트 태그를 주입할까"였다. 결국 후자를 택했는데, 이유는:
- 의존성 하나를 덜고 싶었음
- 우리 조직의 GA4 설정은 단순하고 변화도 적을 것 같았음
- 나중에 Segment나 다른 분석 도구를 추가해야 해도, 같은 Base.astro 원칙으로 쉽게 확장 가능
물론 팀에서 GA4 이벤트 커스터마이징이 필요하다면 그때 라이브러리 도입을 다시 생각해볼 것이다. 지금은 "필요한 것만, 관리하기 쉽게"라는 원칙이 우리 상황에 맞는다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.