GA4 멀티 속성: 개발 및 운영 환경 분리 가이드

더 이상 테스트 데이터에 속지 마세요

데이터 분석 프로젝트를 진행하다 보면, 가장 흔하게 마주하는 문제가 바로 ‘데이터 오염’입니다. 개발자가 테스트 목적으로 발생시킨 트래픽, QA의 검수 데이터, 그리고 실제 고객의 데이터가 하나의 통에 뒤섞여 있다면 어떨까요? 전환율(Conversion Rate)은 왜곡되고, 마케팅 성과 측정은 신뢰를 잃게 됩니다.

유니버설 애널리틱스(UA) 시절에는 ‘보기(View)’ 기능을 통해 필터를 걸어 이 문제를 해결하곤 했습니다. 하지만 ‘보기’가 사라진 GA4에서는 아키텍처 설계 단계부터 다른 접근이 필요합니다.

오늘은 GA4 계정 구조 설계의 핵심인 ‘멀티 속성(Multi-Property) 전략’을 통해 개발(Dev), 스테이징(Staging), 프로덕션(Production) 환경을 명확히 분리하고, 데이터의 무결성을 확보하는 방법을 실무적인 관점에서 상세히 알아보겠습니다.

Part 1 – GA4 멀티 속성 전략의 핵심 개념

실무에서 “그냥 필터로 거르면 되지 않나요?”라는 질문을 자주 받습니다. 하지만 GA4의 데이터 필터 기능은 UA에 비해 제한적이며, 원본 데이터 자체를 관리하는 것이 장기적인 데이터 거버넌스 관점에서 훨씬 효율적입니다.

1. 환경별 속성(Property) 분리의 필요성

Google 공식 가이드 및 엔터프라이즈급 구축 사례에서는 환경별로 별도의 GA4 속성을 생성하는 것을 강력히 권장합니다.

• 데이터 무결성 보장: 개발 서버에서 발생하는 수많은 이벤트와 오류 로그가 실제 비즈니스 의사결정용 데이터(운영 서버)에 섞이는 것을 원천적으로 차단합니다.
• 안전한 실험 환경: 새로운 이벤트나 맞춤 측정기준을 운영 서버에 반영하기 전, 개발 속성에서 자유롭게 테스트하고 검증할 수 있습니다.
• 권한 관리: 개발팀에게는 개발 속성의 편집 권한을, 마케팅 팀에게는 운영 속성의 조회 권한을 부여하는 등 보안 관리가 용이합니다.

2. 잘못된 구조 vs 올바른 구조

• [비권장] 단일 속성 + 단일 스트림: 모든 환경(localhost, dev, prod)의 데이터를 하나의 G-ID(측정 ID)로 수집. (데이터 정제가 불가능에 가까움)
• [비권장] 단일 속성 + 멀티 스트림: 하나의 속성 안에 ‘웹 스트림’을 환경별로 여러 개 만드는 방식. (보고서에서 스트림별로 데이터를 발라내기 번거로우며, 사용자 식별자가 꼬일 위험이 있음)
• [권장] 멀티 속성 구조: 환경별(Dev/Prod)로 완전히 다른 속성 ID를 부여하고, GTM(구글 태그매니저)을 통해 도메인에 따라 데이터를 라우팅하는 방식.

Part 2 – 실무 적용 가이드

이제 실제로 환경을 분리하여 구축해보겠습니다. 이 과정은 GA4와 GTM(Google Tag Manager)을 함께 활용할 때 가장 효과적입니다.

Step 1: GA4 속성 및 데이터 스트림 생성

가장 먼저, 환경별로 데이터를 담을 그릇(속성)을 각각 만듭니다.

1. GA4 관리(Admin) 접속: 좌측 하단 톱니바퀴 아이콘 클릭.
2. 운영(Production) 속성 생성:
   • 속성 이름: BrandName_Web_Prod (명확한 식별을 위해 접미사 권장)
   • 데이터 스트림 생성 후 측정 ID(G-XXXXXX) 복사.
3. 개발(Dev/Staging) 속성 생성:
   • 속성 만들기 > 속성 이름: BrandName_Web_Dev
   • 데이터 스트림 생성 후 측정 ID(G-YYYYYY) 복사.

Step 2: GTM을 활용한 동적 측정 ID 배정 (핵심)

개발자가 소스코드 내의 ID를 매번 수정하게 하는 것은 비효율적입니다. GTM의 ‘조회표(Lookup Table)’ 변수 등을 활용하면 도메인에 따라 자동으로 측정 ID를 갈아끼울 수 있습니다.

1. GTM 접속 > 변수(Variables) > 새로 만들기
2. 변수 유형 선택: ‘조회표(Lookup Table)’ 또는 ‘RegEx 표(RegEx Table)’ 선택.
   • 입력 변수: {{Page Hostname}} (사용자가 접속한 도메인)
3. 조회표 구성:
   • 입력(Input): www.brandname.com (운영 도메인) -> 출력(Output): G-XXXXXX (운영 속성 ID)
   • 입력(Input): dev.brandname.com (개발 도메인) -> 출력(Output): G-YYYYYY (개발 속성 ID)
   • 기본값 설정: G-YYYYYY (예상치 못한 도메인이나 로컬호스트 등은 모두 개발 속성으로 보내 안전장치 마련)
4. 변수 저장: 이름을 GTM – GA4 Measurement ID로 저장합니다.

Step 3: GA4 태그 설정 및 배포

1. 태그(Tags) > Google 태그 클릭.
2. 측정 ID 입력란: 직접 ID를 입력하지 않고, 방금 만든 변수 {{GTM – GA4 Measurement ID}}를 선택합니다.
3. 미리보기(Preview):
   • dev.brandname.com으로 접속하여 DebugView 확인 -> Dev 속성에 데이터가 들어오는지 확인.
   • www.brandname.com으로 접속(가능하다면) -> Prod 속성에 데이터가 들어오는지 확인.
4. 제출(Publish): 설정을 배포합니다.

FAQ – GA4 속성 구조 관련 자주 묻는 질문

Q1. 개발 속성의 데이터를 나중에 운영 속성으로 합칠 수 있나요?

불가능합니다. Google 공식 문서에 따르면, 서로 다른 속성에 수집된 데이터는 병합할 수 없습니다. 이것이 바로 초기 설계 시 운영(Prod) 속성을 신성하게(깨끗하게) 유지해야 하는 이유입니다.

Q2. 소규모 사이트인데 굳이 속성을 나눠야 하나요?

트래픽이 적더라도 나누는 것을 권장합니다. 데이터 분석의 핵심은 ‘정확성’입니다. 오히려 데이터 모수가 적을수록 테스트 트래픽 1~2건이 전체 통계를 크게 왜곡할 수 있습니다.

Q3. ‘내부 트래픽 필터’ 기능으로는 부족한가요?

내부 트래픽 필터는 특정 IP(사무실 등)를 제외하는 데 유용하지만, 개발 환경 전체를 통제하기엔 역부족입니다. 개발자가 재택근무를 하거나, 동적 IP를 사용하는 경우, 혹은 QA 서버 자체가 외부망을 타는 경우 필터링이 누락될 수 있습니다.

Q4. GTM의 ‘환경(Environments)’ 기능과는 무엇이 다른가요?

GTM의 ‘환경’은 태그(코드)의 버전을 관리하는 기능이고, 본문에서 설명한 멀티 속성은 데이터가 쌓이는 저장소를 나누는 것입니다. 두 기능은 상호 보완적이며, 함께 사용하는 것이 가장 좋은 방법입니다.

Q5. 속성을 2개 만들면 비용이 더 드나요?

무료 버전(Standard) GA4를 사용하신다면 비용은 발생하지 않습니다. GA4 360(유료)을 사용하는 경우에도, 일반적으로 과금은 ‘이벤트 히트 수’ 기반이므로, 테스트 속성의 히트 수가 운영 속성만큼 많지 않다면 비용 영향은 미미합니다.

결론

GA4 아키텍처 설계에서 ‘환경 분리’는 선택이 아닌 필수입니다. 많은 기업이 데이터 분석을 시작하면서 단순히 스크립트만 심어두고 방치하지만, 정작 데이터를 뜯어보면 테스트 데이터로 인해 지표가 오염되어 신뢰할 수 없는 경우가 태반입니다.

오늘 소개한 [도메인 기반 GTM 설정 + 멀티 속성] 전략을 적용하면, 개발팀은 자유롭게 테스트하고, 마케팅팀은 정제된 데이터만 볼 수 있는 쾌적한 분석 환경을 구축할 수 있습니다.

지금 바로 GA4 속성에 들어가 debug_mode나 localhost와 같은 데이터가 운영 보고서에 찍히고 있지는 않은지 확인해보세요. 만약 그렇다면, 속성 분리가 시급한 시점입니다.