구글이 2026년 10월 8일 구글 태그 관리자(GTM) 컨테이너 스니펫이 gtag('config') 명령을 다루는 방식을 바꿨다. PPC Land가 10월 9일 보도한 내용에 따르면, 이제 모든 gtm.js 컨테이너 스니펫은 gtag('config') 명령과 관계없이 컨테이너가 로드될 때 초기화된다. 동시에 이 명령은 dataLayer에서 눈에 보이는 gtag.config 이벤트로 나타나고, 와일드카드 커스텀 이벤트 트리거로 만든 태그가 이 이벤트에 반응해 실행될 수 있다. 지원되지 않는 구성을 쓰는 사이트나 .* 트리거를 둔 컨테이너 운영자는 설치 방식과 트리거 설정에 해당하는지 확인해 보자.

이 변화는 구글이 GTM 릴리스 노트에 올린 "Google 태그 관리자의 gtag('config') 명령 동작 표준화"라는 항목에서 나왔다. PPC Land는 이 항목이 세 문단짜리 짧은 공지라고 전했다. 구글은 태깅 스니펫의 동작을 표준화해 구글 태그를 쓰는 모든 웹사이트에서 일관성과 안정성, 높은 성능을 확보하겠다고 밝혔다. 이 글은 PPC Land 보도가 인용한 구글 릴리스 노트와 도움말 내용을 바탕으로 정리했다.

두 가지 코드가 섞여 생긴 문제

구글의 태그 코드는 두 종류다. 하나는 GTM 컨테이너 스니펫이다. gtm.js 파일을 불러오고, 식별자가 GTM-으로 시작한다. 다른 하나는 구글 태그(gtag.js)다. 구글 애즈나 애널리틱스 설정 화면에서 광고주에게 건네는 사이트 태그가 대부분 이쪽이며, G-(구글 애널리틱스), AW-(구글 애즈), DC-(플러드라이트) 같은 제품별 ID를 쓴다. gtag.js는 자체 명령 큐를 가지고 있어서 gtag('js', ...)로 시작하고 gtag('config', ...)로 각 목적지를 설정한다.

PPC Land에 따르면 10월 8일 이전에는 gtm.js 컨테이너가 페이지 다른 곳에 놓인 gtag('config') 호출을 알아보고 기다릴 수 있었다. 일부 사이트는 이 동작에 기대어 gtag.js 로더를 설치하는 대신 GTM 스니펫 옆에 config 한 줄만 따로 두는 방식을 써 왔다. 구글은 이 의존을 없앴다. 컨테이너는 이제 로드되는 순간 초기화된다.

구글 도움말은 이런 구성을 지원하지 않는 구현으로 규정한다. GTM 스니펫 경로(gtm.js)에 G-, AW-, DC-로 시작하는 구글 태그 ID를 얹는 방식이며, 이런 사이트는 태그 동작이 예상과 다르게 바뀔 수 있다고 경고한다. 구글은 지원하지 않는 구현의 컨테이너 사용자에게 이메일로 알렸다고 밝혔지만 대상 수는 공개하지 않았다.

와일드카드 트리거가 한 번 더 실행될 수 있다

실무에서 더 넓게 영향을 줄 수 있는 쪽은 두 번째 변화다. 구글은 릴리스 노트에서 config 명령이 이제 dataLayer에 gtag.config 이벤트로 보이게 된다고 설명했다. 그리고 컨테이너에 와일드카드 커스텀 이벤트 트리거가 있으면 이 변경 때문에 해당 태그가 실행될 수 있다고 덧붙였다.

dataLayer는 페이지가 이름 붙은 이벤트를 밀어 넣는 자바스크립트 배열이고, 커스텀 이벤트 트리거는 그 배열에서 이름이 맞는 이벤트가 나오면 태그를 실행한다. 정규식 일치 옵션을 켜면 이벤트 이름 자리에 정규식을 쓸 수 있는데, 패턴 .*는 어떤 문자열과도 맞는다. 구글 도움말에는 10월 8일 이전부터 이미 경고가 있었다. .* 정규식은 GTM과 구글 태그가 자동으로 내보내는 이벤트를 포함해 감지되는 모든 이벤트에서 트리거가 실행된다는 뜻이므로 더 제한적인 정규식을 쓰라는 권고다.

새 gtag.config 이벤트는 바로 그 자동 발생 이벤트에 해당한다. PPC Land는 .*로 실행되는 태그가 gtag('config') 명령이 도는 모든 페이지에서 한 번씩 더 실행될 것이라고 짚었다. 영향의 크기는 태그 성격에 달렸다. 모든 dataLayer 푸시를 기록하는 로깅이나 디버깅 태그는 행이 하나 늘어나는 정도로 끝난다. 반면 전환 태그, 리마케팅 픽셀, 이벤트를 외부로 전달하는 맞춤 HTML 태그는 추가 전송을 일으킬 수 있다.

업계 전문가의 시각

웹 분석 전문가 사이먼 아하바(Simmer 공동 창업자)는 10월 8일 항목을 링크한 링크드인 글에서 컨테이너 초기화 수정은 좁은 범위의 수정이라고 설명했다. 구글이 먼저 구글 태그 CDN으로 불러도 GTM이 동작하게 만들었고, 이제는 GTM 스니펫만 있고 gtag 로더가 없는 상태에 떠도는 gtag('config', ...) 호출이 만드는 컨테이너 로딩 문제를 고치는 중이라는 해석이다. 그가 더 주의해야 한다고 본 부분은 이벤트였다. 타임라인에 gtag.config라는 새 데이터 레이어 이벤트가 생겼으니, .* 이벤트 이름 트리거를 쓴다면 추가 실행이 생긴다는 것이다. 그는 트리거 단계에서 이 이벤트를 걸러내거나 주석과 로그에서 이를 감안하라고 조언했다.

PPC Land는 두 변화의 영향 범위가 다르다고 구분했다. 컨테이너 초기화 수정은 구글이 지원하지 않는 구현으로 분류하는 사이트에만 해당한다. 반면 새 이벤트는 와일드카드 트리거가 있는 컨테이너가 gtag('config')도 실행하는 페이지에 놓인 모든 경우에 영향을 준다. 구글이 올바르다고 보는 설치도 포함되는데, 지원되는 gtag.js 스니펫 자체에 config 호출이 들어 있기 때문이다.

내 사이트가 해당하는지 확인하는 방법

구글 도움말이 제시한 올바른 구성은 gtag.js 전체 스니펫이다. googletagmanager.com/gtag/js?id=TAG_ID를 비동기로 불러오고, dataLayer를 준비한 뒤 gtag() 함수를 정의하고 gtag('js', ...)와 gtag('config', ...)를 호출하는 형태다. 반대로 지원되지 않는 예시는 GTM 컨테이너 표준 스니펫 뒤에 gtag('config', 'TAG_ID'); 한 줄만 따로 둔 구성이다. 이 예시에는 gtag.js 로더도, gtag() 함수 정의도 없다.

구글이 안내한 이전 절차는 네 단계다. 구글 애즈나 애널리틱스에서 구글 태그 ID를 확인하고, 그 ID를 gtag.js 템플릿에 넣고, gtm.js 스니펫과 거기 딸린 독립 gtag('config') 명령을 제거하고, 모든 페이지의 head 태그 바로 뒤에 gtag.js 스니펫을 붙인다. GTM으로 다른 서드파티 태그나 맞춤 설정을 관리한다면 주 GTM 스니펫은 그대로 두고 gtm.js 스니펫의 G-, AW-, DC- ID를 GTM-XXXXXX ID로 바꾸라는 대안도 있다. 이 경우 구글 태그는 GTM 컨테이너 안에 배포하고 GTM 관리 화면에서 설정한다. 즉 GTM으로 다른 태그까지 함께 관리하는 사이트에 맞는 선택지다.

검증 경로도 문서화돼 있다. 태그 어시스턴트의 "Google tags found" 헤더에서 올바른 ID가 녹색이나 파란색 상태로 보이는지 확인하거나, 크롬 개발자 도구 네트워크 탭에서 요청이 /gtm.js가 아니라 googletagmanager.com/gtag/js로 가는지 볼 수 있다.

문서 사이의 시점 차이와 앞으로의 방향

PPC Land는 두 문서의 시점이 어긋난다고 지적했다. 도움말 문서는 gtm.js 스니펫이 곧 업데이트될 것이라고 미래형으로 쓰는 반면, 10월 8일 릴리스 노트는 이미 적용된 동작으로 적는다. 전체 컨테이너에 10월 8일 일괄 적용됐는지 단계적으로 적용 중인지는 두 문서 모두 밝히지 않았고, 지원되지 않는 패턴을 쓰는 컨테이너가 얼마나 되는지도 공개되지 않았다.

이번 변경은 구글이 태그 설치 방식을 좁혀 온 흐름의 연장선이다. PPC Land에 따르면 구글은 2026년 7월 9일 /gtag/js 같은 지원되지 않는 경로로 불러온 컨테이너의 처리 방식을 바꿔, 경로가 아니라 컨테이너를 불러오는 ID가 서드파티와 맞춤 태그의 실행 여부를 정하게 했다. 5월 20일에는 GTM과 구글 태그를 합쳐 모든 구글 태그를 완전한 GTM 컨테이너로 올리는 계획을 도움말에 게시했다. 이 계획에서 구글은 모든 새 배포 스니펫이 같아지고 gtag config 명령이 없어질 것이라고 밝혔다. PPC Land는 이를 근거로 10월 표준화가 그 방향의 기반 작업처럼 보인다고 해석했다. 이는 매체의 해석이며 구글이 이번 변경의 의도를 그렇게 설명한 것은 아니다.

국내 마케터가 먼저 볼 것

대부분의 사이트는 이번 변경이 눈에 띄는 영향 없이 지나갈 가능성이 높다. 표준 gtag.js 스니펫만 쓰거나 GTM 컨테이너 안에 구글 태그를 설정한 사이트는 이미 구글이 권장하는 구성이기 때문이다. 다만 페이지 소스에서 GTM- 로더와 G-, AW- ID가 든 config 한 줄이 함께 보인다면 구글이 지원하지 않는 구성이므로 도움말의 이전 절차를 검토할 만하다. 이어서 GTM 관리 화면에서 .* 정규식을 쓰는 커스텀 이벤트 트리거가 있는지 찾아보자. 그런 트리거에 걸린 태그가 로깅용인지, 전환이나 외부 전송용인지를 구분해 gtag.config 이벤트를 트리거 단계에서 걸러낼지 정하면 된다. 정확한 시행 범위와 시점은 구글 태그 관리자 릴리스 노트와 도움말 문서의 내용으로 확인해야 한다.