GTM 권한 관리: 누구에게 어디까지 열어줄 것인가

📖 약 2분 읽기

GTM 컨테이너에 접근하는 인원이 늘어날수록 누가 무엇을 바꿨는지 추적하기 어려워집니다. 내부 담당자와 여러 대행사가 같은 컨테이너를 동시에 들여다보는 구조에서는 작은 수정 하나가 어디서 비롯됐는지 특정하기 힘듭니다. 태깅 사고가 발생했을 때 원인을 찾는 데 시간이 걸리는 경우 대부분은 권한이 필요 이상으로 넓게 열려 있는 상태에서 시작됩니다.

권한은 신뢰가 아니라 구조의 문제

GTM은 계정 수준과 컨테이너 수준으로 권한을 나눕니다. 계정 수준은 사용자와 관리자로 구분되고, 컨테이너 수준은 읽기, 수정, 승인, 게시 네 단계로 나뉩니다. 각 단계마다 할 수 있는 작업의 범위가 다르기 때문에, 누구에게 어떤 권한을 주는지에 따라 사고가 발생할 가능성 자체가 달라집니다. 권한을 넓게 열어두는 선택은 담당자를 믿지 못해서가 아니라 책임 범위를 흐리게 만드는 결정에 가깝습니다. 사고가 났을 때 원인을 특정할 수 있는 구조인지가 핵심입니다.

역할별로 필요한 권한은 다르다

모든 역할에 같은 권한을 줄 필요는 없습니다. 내부 담당자는 최종 게시까지 책임지는 위치이므로 승인과 게시 권한을 가지는 것이 자연스럽습니다. 대행사와 개발자는 태그를 구성하고 수정하는 역할이므로 컨테이너 수정 권한이면 충분하고, 게시 권한까지 줄 필요는 없습니다. 분석 담당자는 설정을 확인하고 검증하는 역할이므로 읽기 권한만으로도 업무가 가능합니다.

역할	계정 권한	컨테이너 권한	비고
내부 담당자	관리자	승인, 게시	최종 게시와 변경 승인을 담당
대행사	사용자	수정	작업공간에서 수정 후 승인 요청
개발자	사용자	수정	서버사이드 태그 영역을 분리해 작업
분석 담당자	사용자	읽기	설정 확인과 검증 목적

게시 권한을 제한해야 하는 이유

게시는 변경 사항을 사이트에 즉시 반영하는 단계입니다. 수정과 게시 사이에 승인 과정을 두면 검토를 거친 변경만 실제 사이트에 올라가게 됩니다. 게시 권한을 최소 인원에게만 남겨두는 것은 업무를 번거롭게 만드는 조치가 아니라, 오류가 바로 실환경에 반영되는 상황을 막는 구조입니다.

작업공간을 나누어 쓰는 방법

GTM은 하나의 컨테이너 안에서 여러 개의 작업공간을 만들어 쓸 수 있습니다. 담당자나 프로젝트 단위로 작업공간을 분리하면 한 사람의 수정이 다른 사람의 작업을 덮어쓰는 상황을 피할 수 있습니다. 작업이 끝나면 병합 과정에서 충돌 여부를 확인하게 되므로, 변경 내용을 한 번 더 점검하는 효과도 있습니다.

대행사 권한의 부여와 회수

계약 시작 시점에 필요한 최소 권한만 부여합니다. 대부분의 경우 컨테이너 수정 권한으로 업무가 가능합니다.
게시 권한은 부여하지 않고, 내부 담당자가 검토한 뒤 게시하는 절차를 둡니다.
작업공간을 대행사 전용으로 분리해 변경 범위를 한정합니다.
계약 종료 시점에 계정 접근 권한을 즉시 회수하고, 작업공간 소유권을 내부로 이전합니다.
회수 이후에는 활동 기록을 확인해 마지막 변경 내역을 점검합니다.

정기 점검 항목

계정 목록과 각 사용자의 권한 등급을 확인합니다.
게시 권한을 가진 인원이 필요 이상으로 늘어나지 않았는지 확인합니다.
활동 기록에서 최근 변경 내역과 담당자가 일치하는지 확인합니다.
계약이 끝났거나 사용하지 않는 계정이 남아 있는지 확인합니다.

권한 구조를 정리하는 작업은 한 번으로 끝나지 않고, 역할이 바뀔 때마다 다시 점검해야 하는 작업입니다. 버전 이력과 활동 기록을 함께 확인하는 습관을 들이면 사고가 나기 전에 이상 변경을 발견할 가능성이 높아집니다. 태그맨은 이런 권한 등급 설계와 승인 절차 구성을 운영 지원 범위에 포함하고 있습니다.