Data Layer와 GTM — 이벤트 태깅의 큰 그림

① 왜 이 작업이 필요한가

개발팀 입장에서 ‘이 push 작업은 왜 우리가 해야 하는가’를 먼저 정리합니다. 모든 GA4 구축은 마케팅·UX팀의 분석 요구에서 출발하지만, 그 요구를 실제 데이터로 만들 수 있는 사람은 개발팀뿐입니다 — 이 단절을 메우는 것이 데이터레이어 작업의 본질입니다.

마케팅·UX팀이 데이터를 통해 답하고 싶어 하는 질문

• 사용자는 어떤 경로로 유입되는가
• 어떤 페이지에서 가장 많이 이탈하는가
• 상담·구매·가입은 어디에서 막히는가
• 어떤 버튼이나 기능이 실제로 사용되는가
• 어떤 UX 요소가 전환에 영향을 주는가

이 질문들은 모두 ‘사용자의 행동 흐름’을 정확히 알아야만 답할 수 있습니다. 단순 방문자 수가 아니라 ‘사용자가 서비스 안에서 어떻게 움직이고, 어디에서 멈추는지’를 알아야 합니다.

그런데 마케팅·UX팀은 이 데이터를 스스로 만들 수 없습니다

분석을 위한 데이터가 자동으로 만들어지지 않는다는 점이 핵심입니다. 마케팅·UX 담당자는 다음 세 가지 한계를 가지고 있습니다.

1. 소스코드에 직접 접근하기 어렵다. 프론트엔드·백엔드 코드에 직접 접근하거나 수정할 권한이 없습니다. 버튼 클릭 시점 · 폼 제출 완료 시점 · 결제 성공 시점 · 비동기 처리 완료 시점 같은 기술적인 이벤트 발생 지점을 직접 구현할 수 없습니다.
2. ‘어디에 심어야 하는지’ 알기 어렵다. 어떤 데이터를 수집해야 하는지는 알아도, 어느 파일에서 / 어떤 함수에서 / 어떤 타이밍에 / 어떤 방식으로 이벤트를 넣어야 하는지는 판단하기 어렵습니다. 잘못된 위치에 넣으면 실제 완료 전인데 완료로 기록되거나, 여러 번 중복 수집되거나, 아예 수집되지 않는 문제가 발생합니다.
3. 코딩 방식과 데이터 구조를 동시에 이해하기 어렵다. 이벤트 수집은 단순한 로그 출력이 아니라 데이터 구조 설계 · 변수 매핑 · 비동기 처리 이해 · 예외 상황 대응이 모두 함께 고려되어야 하는 작업입니다. 일반적인 마케팅·UX 업무 범위를 넘어서는 영역입니다.

그래서 택소노미 문서가 ‘중간 설계서’가 된다

이 문제를 해결하기 위해 허들러스는 마케팅·UX 요구사항을 기술 문서 형태로 변환한 이벤트 택소노미 문서를 제공합니다. 마케팅팀이 원하는 분석 구조를 정리하고, UX팀이 중요하다고 판단한 흐름을 반영하며, 개발팀이 그대로 구현할 수 있도록 기술적으로 번역한 문서입니다. 즉 ‘비기술 조직과 개발 조직을 연결하는 중간 설계서’ 역할입니다.

한 줄로 정리하면 — 개발팀의 역할은 ‘택소노미 문서를 기준으로 정확한 위치에, 정확한 구조로, 정확한 값을 데이터레이어에 전달하는 것’입니다. 이 한 가지가 마케팅·UX팀의 모든 분석 질문이 답을 얻을 수 있는 출발점이 됩니다.

② 큰 그림 — 하나의 dataLayer가 여러 매체로

개발자가 사이트 코드에 단 한 가지 — ‘이벤트가 발생할 때 dataLayer에 push 하는 코드’ — 만 심어 두면, 그 한 줄의 push가 GTM을 통해 동시에 여러 분석·광고 도구로 흘러 들어갑니다.

핵심은 — 사이트에 심는 코드는 한 번이지만, 그 코드가 보내는 데이터는 N개 매체로 동시에 흐른다는 구조입니다. 매체 하나가 늘어날 때마다 개발팀이 사이트 코드를 다시 손볼 필요가 없습니다.

③ 역할 분담

한 줄로 정리하면 — 개발팀은 ‘택소노미 문서를 기준으로 정확한 위치에, 정확한 구조로, 정확한 값을 데이터레이어에 전달하는 것’이 임무입니다. 그 외 단계는 허들러스가 처리합니다.

④ DataLayer란 무엇인가

GA4를 비롯한 마케팅·분석 도구로 데이터를 전송하기 전, 허들러스 구축 방식에서는 반드시 ‘데이터레이어(Data Layer)’를 거쳐 데이터를 전달합니다. 데이터레이어는 단순한 변수나 로그가 아니라 — 웹·앱에서 발생한 사용자 행동 데이터를 외부 도구에 전달하기 위한 표준 중간 저장소입니다. 한 문장으로 정리하면 ‘서비스 내부에서 발생한 이벤트를 외부로 전달하기 전에 잠시 모아 두는 공식 통로’입니다.

기술적으로 데이터레이어는 전역 배열(Array) 형태로 존재하는 JavaScript 변수입니다. 일반적인 초기화 코드는 다음과 같습니다.

window.dataLayer=window.dataLayer|| [];

이 객체에 이벤트 데이터를 push 하면, GTM이 이를 감지해 후속 처리를 수행합니다.

window.dataLayer.push({event:"submit_main_consult",car_model:"sedan",user_type:"new"});

위 코드를 트리거 시점(예: 상담 신청 버튼 클릭 후 서버 응답 success 분기)에 실행시키면, 같은 시점에 GTM이 ‘submit_main_consult 이벤트가 발생했다’는 신호를 받고 — 미리 설정해 둔 GA4·광고 픽셀 태그를 동시에 발화합니다.

⑤ 왜 GTM을 거치는가 — 세 가지 이유

허들러스 GA4 구축 방식에서는 모든 이벤트 데이터를 GTM을 통해 전송합니다. 개발팀이 직접 GA4·광고 스크립트·분석 도구를 호출하지 않고, 반드시 dataLayer → GTM 구조를 거쳐 데이터를 전달합니다. 단순한 기술 선택이 아니라 ‘장기 운영과 안정성’을 고려한 표준 구조입니다.

요약하면 — ‘한 번 잘 심은 dataLayer’ + ‘GTM에서 마케터가 자유롭게 다루는 매체 전송 구성’의 분업 구조가 가장 안정적이고 변화에 강합니다.

⑥ 개발팀의 5단계 워크플로

택소노미 문서가 전달된 시점부터 ‘세팅 완료’까지의 작업 순서. 개별 이벤트 시트 안의 코드 가이드를 기준으로 진행합니다(시트 구조 자체는 ‘이벤트 택소노미 문서 — 개발자용’ 글에서 자세히).

1. 문서 이해

   택소노미 문서를 열어 작업할 이벤트의 시트를 확인합니다. 트리거 지점·파라미터·데이터 타입·화면 구조를 파악하는 단계로, 이후 모든 작업은 이 시트를 기준으로 합니다.

2. 데이터 전달 — dataLayer push 구현

   시트의 ‘코드 가이드’ 영역에 있는 dataLayer.push 견본을 사이트 코드의 정확한 트리거 시점에 옮겨 심습니다. 키 이름·구조는 그대로 두고, 값은 그 시점의 사용자 행동에서 동적으로 추출해 채웁니다.

3. 테스트 및 자체 검증

   브라우저 콘솔에서 dataLayer를 입력해 발생한 이벤트와 파라미터가 정상적으로 들어왔는지 확인합니다(아래 ⑥에서 자세히).

4. 완료 보고

   해당 이벤트의 시트 상태값을 ‘대기중’ → ‘세팅 완료’로 갱신합니다. 이 시점부터 허들러스 측 검수가 시작됩니다.

5. 이슈 공유

   구현 도중 발생한 오류·설계와의 차이·추가 질의는 시트의 ‘추가 논의 히스토리’ 영역에 날짜와 함께 기록합니다. 메신저 전달만으로는 공식 이슈로 관리되지 않으므로 반드시 시트에 남깁니다.

⑦ 자체 검증 — 콘솔에서 dataLayer 확인

구현이 끝나면 사이트로 이동해 브라우저 콘솔에서 데이터가 정상적으로 들어가는지 확인합니다. 절차는 세 단계입니다.

콘솔에서 확인할 수 있는 것

• 이벤트 이름이 정확한가 — 시트의 이벤트 이름과 콘솔에 찍힌 event 값이 일치하는지
• 파라미터 키와 값이 모두 들어왔는가 — 트리거번호별 조건부 전송이 의도대로 동작하는지 포함
• 중복 발생은 없는가 — 한 번의 사용자 행동에 같은 이벤트가 두 번 push되지 않는지
• 비동기 시점이 정확한가 — 결제 콜백 등 비동기 처리의 success 분기에서 정확히 호출되는지

자주 묻는 질문