[GTM 무료강의] GTM 모범 사례 12가지 (1편) : 계획부터 데이터 레이어까지 기초를 다지는 법
핵심 요약 (한 줄 답변)
GTM(구글태그관리자)을 안전하고 효율적으로 운영하려면, 태그를 만들기 전에 측정 계획을 먼저 세우고, 계정은 회사당 1개·컨테이너는 웹사이트당 1개로 유지하며, 명확한 이름 규칙으로 태그·트리거·변수를 관리해야 합니다. 여기에 권한을 최소한의 인원에게만 부여하고, 워크스페이스로 팀 작업을 분리하며, 상수 변수·조회 테이블(Lookup/Regex Table)로 반복 입력을 줄이고, 가능하면 커스텀 템플릿을 활용해 위험한 Custom HTML을 최소화하는 것이 핵심입니다. 데이터가 많고 서드파티 공유를 엄격히 통제해야 한다면 서버사이드 태깅을, 낯선 자바스크립트 코드를 쓸 때는 반드시 개발자와 상의해야 합니다. 마지막으로 데이터 레이어를 활용하면 자동 이벤트 리스너로 잡히지 않는 상호작용도 안정적으로 추적할 수 있고, IT 부서가 GTM에 반대하더라도 허용목록(allowlist)·정책 설정으로 통제권을 나눠 가질 수 있습니다.
이 글에서 알 수 있는 것
- 태그를 만들기 전 반드시 세워야 할 측정 계획의 순서
- 계정/컨테이너를 회사당 1개·웹사이트당 1개로 유지해야 하는 이유
- 대행사가 클라이언트의 GTM 컨테이너를 절대 직접 소유하면 안 되는 이유
- 태그·트리거·변수 이름 규칙 팁
- 4단계 권한(읽기·수정·승인·게시) 체계와 부여 기준
- 워크스페이스로 여러 작업을 안전하게 병행하는 방법
- 상수 변수와 조회/정규식 테이블로 반복 작업을 줄이는 법
- 커스텀 템플릿, 서버사이드 태깅, 데이터 레이어를 언제 써야 하는지
✳️ 난이도 : 중급 | 소요 시간 : 약 9분 | 대상 : GTM을 체계적으로 운영하고 싶은 마케터·데이터 분석가·에이전시 실무자
GTM, 왜 이렇게 자주 "엉망"이 될까요?
구글태그관리자(GTM)는 IT 부서의 개입 없이도 추적 코드(태그)를 추가·수정할 수 있게 해주는 강력한 도구입니다. 웹사이트 소스코드 곳곳에 흩어진 태그를 하나의 대시보드에서 관리할 수 있다는 것도 큰 장점입니다.
하지만 태그·트리거·변수를 만들고 관리하는 데는 여전히 특정한 기술과 규칙이 필요합니다. 제대로 활용하지 못하면 계정이 정말 엉망이 되거나, 최악의 경우 웹사이트 기능을 망가뜨려 회사에 상당한 금전적 손실을 끼칠 수도 있습니다. 이 글에서는 즉시 따라 할 수 있는 GTM 모범 사례를 정리합니다. 이것이 "정답"이라거나 "완전한 목록"은 아니지만, 다음 프로젝트에 아이디어와 영감을 줄 수 있기를 바랍니다.
1. 구현 전에 먼저 계획하라
새 프로젝트를 시작할 때, 여러 추적 기법을 무작정 구현하려고 서두르지 마세요. 대신 측정 계획과 태그 구현 계획부터 준비해야 합니다.
| 단계 | 내용 |
| ① | 비즈니스 목표부터 파악한다 (예: 매출 증대) |
| ② | 그 목표를 달성하는 데 웹사이트의 어떤 부분이 기여하는지 파악한다 (예: 이커머스라면 구매) |
| ③ | 그 목표로 이어지는 이벤트/상호작용을 정의한다 (예: 장바구니 담기, 결제 시작, 뉴스레터 구독) |
| ④ | 이벤트 목록을 바탕으로 GTM에 구현할 태그 목록을 준비한다 |
| ⑤ | 모든 태그와 설정을 담은 스프레드시트를 만든다 |
✅ 핵심 : 이런 스프레드시트를 관리하다 보면 개발자에게 무엇을 요청해야 하는지, 이벤트 이름을 어떻게 지을지가 자연스럽게 드러나고, 이는 곧 탄탄한 이름 규칙(naming convention) 을 세우는 밑거름이 됩니다.
2. 계정/컨테이너 구조와 소유권
GTM은 계정과 컨테이너로 구성됩니다. GA와 비슷하게, 하나의 계정 안에 여러 컨테이너(GA4의 속성에 해당)를 둘 수 있습니다. 구글은 회사당 계정 1개, 웹사이트당 컨테이너 1개를 사용하라고 권장합니다.
⚠️ 주의 : 그런데도 한 회사에 여러 GTM 계정이 만들어져 있거나, 하나의 웹사이트에 여러 컨테이너 태그가 심어진 경우를 종종 봅니다. 여러 계정/컨테이너는 조만간 추적·진단 문제를 일으킬 수 있습니다. 또한 계정이 커질수록 여러 계정/컨테이너에 흩어진 태그·트리거·변수를 관리하는 일이 악몽이 될 수 있습니다.
물론 예외도 있습니다. 성격이 매우 유사한 두 웹사이트가 동일한 GTM 컨테이너 코드를 함께 쓸 수도 있습니다. 다만 이 경우 트리거를 한쪽 사이트에서만 실행되도록 설정할 때 매우 주의해야 합니다.(몇 개의 컨테이너가 필요한지는 상황마다 다르므로, 별도로 판단 기준을 정리해두는 것이 좋습니다.)
절대 하지 말아야 할 것 : 대행사의 컨테이너 독점
디지털 에이전시는 모든 클라이언트의 GTM 컨테이너를 하나의 에이전시 GTM 계정 아래 절대 만들어서는 안 됩니다. 컨테이너는 항상 클라이언트가 소유해야 합니다.
에이전시가 할 수 있는 방법은 두 가지뿐입니다.
- 클라이언트에게 계정과 컨테이너를 직접 만들어달라고 요청한다.
- 에이전시가 별도의 계정+컨테이너를 만들고, 클라이언트에게 관리자 권한을 부여한다.
⚠️ 주의 : 클라이언트가 관계를 종료하려 할 때, 에이전시가 클라이언트를 GTM 컨테이너에서 차단해버리는 좋지 않은 사례를 실제로 본 적이 있습니다.
3. 올바른 이름 규칙을 사용하라
GTM을 써본 적이 있다면, 태그·트리거·변수의 개수가 순식간에 관리하기 어려운 수준으로 불어날 수 있다는 것을 아실 겁니다. 명확한 이름 규칙을 쓰면 나와 팀원 모두가 훨씬 쉽게 관리할 수 있습니다. 쉬워질수록 태깅에 낭비되는 위험·시간·비용도 줄어듭니다.
이름 규칙 없이 방치하면 위와 같은 상황이 벌어집니다.
태그·트리거·변수 이름 짓는 팁
| 팁 | 설명 |
| 추적 유형 포함 | GA 태그라면 이름에 "Event" 또는 "Config"를, 구글애즈 태그라면 "Conversion" 또는 "Remarketing" 같은 태그 유형을 포함 |
| 특정 페이지 명시 | 특정 페이지(또는 하위 디렉터리)에서만 실행되는 태그라면 이름에 해당 페이지/디렉터리를 포함 (예: GA4 event – generate_lead – contact form, Google Ads Remarketing – Thank You page) |
4. 올바른 사람에게만 GTM 권한을 부여하라
GTM은 매우 강력한 도구이며, 충분한 고민·계획·테스트 없이 무책임하게 사용하면 웹사이트 기능을 망가뜨릴 수 있습니다. 태그 배포에 관여하는 사용자에게만 접근 권한을 제한하세요.
GTM은 계정 수준과 컨테이너 수준에서 접근 권한을 위임할 수 있습니다. 예를 들어 계정 수준에서는 다른 사용자를 보거나 관리할 권한을, 컨테이너 수준에서는 읽기·수정·승인·게시 권한을 부여할 수 있습니다.
사용자를 추가·수정하려면 GTM 메뉴 바에서 [관리자] 를 클릭하고, 원하는 계정 또는 컨테이너를 선택한 뒤 "사용자 관리" 를 클릭합니다.
4단계 권한 체계
| 권한 | 컨테이너 조회 | 워크스페이스 생성/수정 | 버전 생성 | 게시 |
| 읽기(Read) | ✅ | ❌ | ❌ | ❌ |
| 수정(Edit) | ✅ | ✅ | ❌ | ❌ |
| 승인(Approve) | ✅ | ✅ | ✅ | ❌ |
| 게시(Publish) | ✅ | ✅ | ✅ | ✅ |
✅ 팁 : "게시" 권한은 팀 내에서 GTM을 가장 잘 아는 사람에게만 부여하세요.
5. 워크스페이스를 적극 활용하라
대규모 팀에 특히 유용한 모범 사례입니다. GTM 워크스페이스는 컨테이너에 대해 여러 개의 서로 다른 변경사항 집합을 만들 수 있게 해줍니다. 여러 사용자·팀이 각자의 워크스페이스에서 동시에 독립적으로 태그를 개발·테스트할 수 있습니다.
워크스페이스를 사용하면 여러 개의 컨테이너 초안(Container Draft) 을 동시에 다루게 됩니다. 새 워크스페이스를 만들면 최신 GTM 컨테이너 버전에서 분리된 새 초안이 생성되고, 이것이 새 워크스페이스가 됩니다.
- 새 버전이 만들어지면, 각 워크스페이스에는 "워크스페이스가 오래되었다" 는 알림이 표시됩니다.
- 다른 워크스페이스가 버전으로 전환되면, 나머지 모든 워크스페이스에도 최신 컨테이너 버전이 바뀌었다는 알림이 표시됩니다.
⚠️ 주의 : 새 버전을 만들고 게시하기 전에, 반드시 워크스페이스를 업데이트해야 합니다. 워크스페이스를 업데이트하는 동안 동기화된 변경사항과 이미 워크스페이스에 있던 변경사항 사이에 충돌이 있으면 "충돌 발견(Conflict found)" 표시가 나타나며, 이를 해결하는 도구로 이동하게 됩니다.
6. 상수 변수 사용을 고려하라
GTM의 대부분 태그는 고유한 추적 코드 등 개별적인 설정값이 필요합니다. 예를 들어 페이스북 픽셀 태그를 30개 만들었는데, 어느 날 픽셀 ID를 X에서 Y로 바꿔야 한다면 어떻게 될까요?
30개의 태그를 일일이 찾아 수동으로 바꿔야 합니다. 최적의 방법도 아니고, 사람 실수가 생기기 쉬운 구조입니다.
해결책은 "상수 변수(Constant Variables)"입니다. [변수] → [새로 만들기] → [상수] 로 이동합니다.
여기에는 필드가 하나뿐입니다. 픽셀 ID를 붙여넣고 변수를 저장하면, 이제 모든 페이스북 픽셀 태그에서 이 변수를 사용할 수 있습니다.
향후 ID를 변경해야 할 때는 상수 변수 하나만 수정하면, 이 변수를 사용하는 모든 페이스북 픽셀 태그가 자동으로 변경사항을 상속받습니다.
7. 조회/정규식 테이블(Lookup/Regex Table)을 사용하라
GTM의 조회 테이블은 추적 설정에서 여러 값을 관리하는 작업을 단순화합니다. 필요한 태그 수를 극적으로 줄여, 지저분한 GTM을 깔끔한 환경으로 바꿀 수 있습니다.
GTM의 조회 테이블은 다른 변수의 값을 입력값으로 받는 변수입니다. 동작 방식은 다음과 같습니다. [입력 변수]가 ___와 같으면, [이 출력 변수]를 ___로 설정한다.
가장 흔한 활용 사례: 운영(실제) 웹사이트와 개발 버전용으로 서로 다른 GA 측정 ID를 쓰는 경우입니다. 이 방법을 쓰면 개발 사이트에서 발생한 모든 페이지뷰가 테스트용 GA 계정으로만 전송되고, 실제 추적 데이터에는 전혀 섞이지 않습니다.
- 페이지 호스트 이름이 https://www.example.com과 같으면 → 조회 테이블 값을 G-1234567890으로 설정
- 페이지 호스트 이름이 https://dev.example.com과 같으면 → 조회 테이블 값을 G-9876543210으로 설정
✅ 핵심 : GTM은 정규식 테이블(Regex Table) 도 제공합니다. 조회 테이블과 동일하게 작동하되, 모든 필드에서 정규 표현식을 지원해 더 복잡한 조건(더 강력한 기능)을 설정할 수 있습니다.
8. 가능하면 커스텀 템플릿을 사용하라
커스텀 템플릿과 커뮤니티 갤러리가 성장하면서, 점점 더 많은 사람이 즉시 사용 가능한 템플릿을 만들고 공유하고 있습니다. 순수 자바스크립트 코드를 직접 편집하는 것보다 사용하기 쉽고, Custom HTML 태그나 Custom JS 변수만큼 위험하지도 않기 때문에 인기가 높습니다.
자바스크립트에 익숙하지 않은 GTM 사용자가 많다는 점에서, 템플릿 사용은 거의 당연한 선택입니다. 또한 이런 템플릿은 웹사이트의 콘텐츠 보안 정책(CSP) 과 더 잘 어울리도록 설계되었습니다.
✅ 참고 : CSP는 웹 개발자가 자바스크립트가 웹사이트에서 할 수 있는 유해한 행동을 제한하는 방법입니다. 커스텀 템플릿을 사용하면, 개발자가 일부 제한을 유지하면서도 GTM 사용자는 여전히 커스텀 템플릿을 쓸 수 있습니다.
9. 서버사이드 태깅을 고려하라
디지털 분석 환경이 계속 변화하면서, 점점 더 많은 기업이 서드파티 벤더와 공유되는 데이터를 더 세밀하게 통제하고, 수집 데이터의 정확도를 높이기 위해 서버사이드 방식으로 옮겨가고 있습니다.
2020년, GTM도 이 흐름에 합류해 서버사이드 태깅을 도입했습니다.
| 구분 | 클라이언트 사이드(표준) | 서버사이드(고급) |
| 실행 위치 | 사용자의 브라우저 | 서버 |
| 데이터 통제력 | 낮음(벤더가 사용자 IP·헤더를 볼 수 있음) | 높음(무엇을 보낼지 직접 선택) |
| 성능 | 웹사이트 속도를 늦출 수 있음 | 대부분의 처리를 기기 밖으로 옮길 수 있음 |
| 비용 | 무료 | 월 서버 비용 발생 |
✅ 핵심 : 서버사이드 태깅은 모든 비즈니스에 맞는 것은 아닙니다.(소규모 사업체에는 월 서버 비용이 부담될 수 있음) 하지만 이점이 단점을 상당히 능가하는 경우가 많습니다.
10. 낯선 자바스크립트 코드는 개발자와 먼저 상의하라
어떤 웹사이트에 가치를 더할 수 있는 유용한 커스텀 코드를 발견했다면, 사용하기 전에 개발자와 상의하는 것을 권장합니다. 잘 알려지고 신뢰받는 출처에서 나온 코드라도 마찬가지입니다.
왜일까요? Custom HTML 태그(또는 비슷한 방식)로 구현하는 커스텀 코드는 웹사이트를 망가뜨릴 수 있기 때문입니다. 마케팅팀이 충분히 테스트하지 않은 코드를 추가해 사이트를 일시적으로 망가뜨리고, 그 결과 수천 달러의 매출 손실로 이어진 사례를 실제로 본 적이 있습니다.
⚠️ 주의 : 그 결과 해당 마케팅팀은 GTM 컨테이너 변경사항을 게시할 권한을 잃었습니다. 큰 힘(유연성)에는 큰 책임이 따르고, 생각보다 많은 사람이 이 점을 인지하지 못합니다.
11. 데이터 레이어를 적극 활용하라
GTM 데이터 레이어는 커스텀 데이터와 트리거를 전달하는 데 매우 유용합니다. 초보자에게는 다소 까다로운 개념이지만, 태그 관리의 핵심 요소 중 하나이므로 좋든 싫든 반드시 이해해야 합니다.
데이터 레이어란 무엇일까요? 데이터 레이어는 웹사이트의 가상 레이어로, 개발자가 (거래 총액, 양식 ID, 사용자 속성 같은) 정보를 저장해두면 GTM이 이를 쉽게 읽을 수 있습니다. 웹사이트 코드와 추적 태그를 잇는 다리 역할을 합니다.
웹사이트의 특정 부분/기능을 추적하고 싶은데, GTM의 기본 자동 이벤트 리스너가 해당 상호작용을 잡아내지 못한다면 데이터 레이어 활용을 권장합니다.
데이터 레이어 사용이 특히 권장되는 대표 사례
| 사례 | 설명 |
| 양식(Form) 추적 | GTM의 폼 트리거가 양식 제출을 잡아내지 못한다면, 개발자에게 원하는 데이터를 담아 dataLayer.push 이벤트를 실행해달라고 요청 |
| 온라인 스토어의 전자상거래 데이터 전송 | GA로 전자상거래 거래를 추적하려면, 개발자가 거래 데이터를 dataLayer.push 방식으로 전달해야 함 |
✅ 핵심 : 가능하다면 DOM 스크래핑보다 데이터 레이어를 우선하세요. 데이터 레이어가 훨씬 더 안정적입니다. DOM 스크래핑도 개발자를 구하기 어려운 경우 등에는 여전히 실용적인 선택지가 될 수 있지만, 웹사이트 코드 구조가 바뀌면 깨질 수 있다는 문제가 있습니다.
12. 개발자·CTO가 태그 매니저에 반대한다면
일부 회사에서는 IT 부서가 태그 매니저 사용에 강하게 반대하는 경우가 드물지 않습니다. 외부 당사자가 스크립트를 주입해 웹사이트 성능과 보안에 영향을 줄 수 있다는 우려 때문입니다.
이 경우 IT 부서는 GTM 구현과 관련된 모든 요청을 거절하곤 합니다.
✅ 핵심 : 하지만 IT 부서는 보통 GTM이 IT 부서에 상당한 통제권을 부여하면서도, 마케팅/분석팀이 필요한 업무 대부분을 여전히 수행할 수 있게 해주는 기능을 제공한다는 사실을 잘 모릅니다.
예를 들어 IT 부서는 마케터가 Custom HTML 태그를 사용하지 못하도록 자동으로 막고, 구글애널리틱스·구글애즈 등 일부 태그만 허용하도록 설정할 수 있습니다. 허용목록/차단목록(allowlist/blocklist) 기능이 이를 가능하게 합니다. 서버사이드 태깅 환경을 구축하고 싶다면, 개발자가 특정 작업만 허용하는 정책을 구성할 수도 있습니다.
✅ 핵심 : 이는 마케팅/분석팀에 더 많은 제약이 생긴다는 뜻이지만, 그래도 GTM을 아예 못 쓰는 것보다는 훨씬 낫습니다.
결론 : 구조와 규칙이 있어야 GTM이 무기가 됩니다 (2편 예고)
1편에서 다룬 12가지의 핵심은 하나로 요약됩니다.
"태그 하나를 만들기 전에, 구조·이름 규칙·권한·데이터 통로를 먼저 설계하라."
계획 없이 태그부터 만들면 반드시 엉망이 되고, 구조·이름 규칙이 없으면 몇 달 뒤의 나 자신도 이해하지 못하는 컨테이너가 만들어집니다. 데이터 레이어는 초반에 익히기 까다롭지만, 결국 가장 안정적인 추적 방식입니다. 다음 2편에서는 실행 단계 - 요소 식별자 추가, 페이지 속도 관리, 테스트와 디버깅, 버전 관리, 데이터 검증까지 나머지 12가지를 이어서 다루겠습니다.
자주 묻는 질문 (FAQ)
Q. GTM 계정과 컨테이너는 몇 개씩 만들어야 하나요?
A. 구글은 회사당 계정 1개, 웹사이트당 컨테이너 1개를 권장합니다. 여러 계정/컨테이너를 쓰면 조만간 추적·진단 문제가 생기기 쉽고, 관리도 훨씬 어려워집니다. 단, 성격이 매우 유사한 두 웹사이트는 예외적으로 같은 컨테이너를 공유할 수 있습니다.
Q. 에이전시가 클라이언트의 GTM 컨테이너를 직접 만들어 관리해도 되나요?
A. 절대 안 됩니다. 컨테이너는 항상 클라이언트가 소유해야 합니다. 클라이언트가 직접 계정/컨테이너를 만들게 하거나, 에이전시가 별도 계정을 만들고 클라이언트에게 관리자 권한을 부여하는 두 방식 중 하나를 선택해야 합니다.
Q. GTM의 4단계 권한(읽기·수정·승인·게시)은 어떻게 나누어야 하나요?
A. "게시" 권한은 팀에서 GTM을 가장 잘 아는 사람에게만 부여하는 것이 안전합니다. 나머지 인원에게는 업무 범위에 맞게 읽기·수정·승인 권한을 단계적으로 부여하세요.
Q. 상수 변수는 왜 사용해야 하나요?
A. 픽셀 ID처럼 여러 태그에서 반복 사용되는 값을 상수 변수로 만들어두면, 나중에 값이 바뀌었을 때 변수 하나만 수정하면 이를 사용하는 모든 태그에 자동으로 반영됩니다. 태그가 많을수록 시간 절약과 실수 방지 효과가 커집니다.
Q. 데이터 레이어와 DOM 스크래핑 중 무엇을 우선해야 하나요?
A. 가능하다면 데이터 레이어를 우선해야 합니다. DOM 스크래핑은 개발자 지원 없이도 쓸 수 있는 실용적인 대안이지만, 웹사이트 코드 구조가 바뀌면 추적이 깨질 위험이 있습니다.
Q. IT 부서가 GTM 도입에 반대하면 어떻게 해야 하나요?
A. GTM의 허용목록/차단목록(allowlist/blocklist) 과 정책 설정 기능을 활용하면, IT 부서가 Custom HTML 사용을 막고 특정 태그만 허용하는 등 통제권을 유지하면서도 마케팅팀이 필요한 작업을 계속할 수 있습니다.
요약 (한 장 정리)
- 계획 : 비즈니스 목표 → 핵심 이벤트 정의 → 태그 스프레드시트 작성
- 구조 : 회사당 계정 1개, 웹사이트당 컨테이너 1개 / 에이전시는 컨테이너를 절대 독점 소유 금지
- 이름 규칙 : 추적 유형 + 특정 페이지를 태그명에 포함
- 권한 : 읽기·수정·승인·게시 4단계, 게시는 최고 숙련자에게만
- 워크스페이스 : 여러 팀이 독립적으로 작업 후 충돌 해결
- 상수 변수 : 반복되는 값(픽셀 ID 등) 한 곳에서 관리
- 조회/정규식 테이블 : 조건별 값 매핑으로 태그 수 축소
- 커스텀 템플릿 : Custom HTML보다 안전, CSP와도 호환
- 서버사이드 태깅 : 데이터 통제력 ↑, 비용 발생 — 상황에 맞게 선택
- 낯선 JS 코드 : 반드시 개발자와 사전 상의
- 데이터 레이어 : 자동 이벤트로 안 잡히는 상호작용의 표준 해법
- IT 반대 시 : 허용목록/정책으로 통제권 분담
- 다음 편(2편) : 요소 식별자·속도·테스트·디버깅·버전 관리·데이터 검증
작성 : 디애널리틱스(The Analytics) · 구글애널리틱스를 활용하여 기업의 마케팅 성과를 향상시키는 방법을 연구합니다.