이 사고에서 무슨 일이 벌어졌나

한 마케팅 담당자가 신규 애드네트워크의 리타게팅 스크립트를 GTM 커스텀 HTML 태그로 추가하면서, 결제 페이지의 특정 버튼 클릭 이벤트를 가로채는 코드를 함께 포함시켰습니다. 이 코드는 개발팀의 검토 없이 마케팅 담당자가 직접 GTM에서 게시(Publish) 버튼을 눌러 프로덕션 환경에 즉시 반영됐습니다. 문제는 이 스크립트가 결제 페이지의 기존 결제 버튼 이벤트 리스너와 충돌을 일으켜, 결제 버튼을 눌러도 아무 반응이 없는 상태가 반나절 동안 지속된 것입니다.

이 문제는 고객 문의가 폭증하면서야 발견됐고, 원인을 찾는 데도 상당한 시간이 걸렸습니다. GTM 변경 이력을 확인하고 나서야 그 시점에 게시된 태그가 원인이라는 것이 밝혀졌습니다.

왜 미리보기 모드로도 이 문제를 걸러내지 못했나

담당자는 GTM의 미리보기(Preview) 모드로 태그가 정상 작동하는지 확인한 뒤 게시했지만, 미리보기 모드에서 확인한 시나리오는 일반적인 페이지 탐색 흐름이었고 실제 결제 버튼을 여러 번 반복 클릭하거나 특정 브라우저 환경에서 발생하는 이벤트 리스너 충돌까지는 재현하지 못했습니다. 이는 미리보기 모드가 모든 실사용 시나리오를 완벽히 재현하지는 못한다는 한계를 보여주는 사례입니다.

특히 자사몰의 결제 버튼처럼 사업에 핵심적인 요소와 상호작용하는 코드를 GTM에 추가할 때는, 일반적인 미리보기 확인만으로는 충분하지 않다는 교훈을 남겼습니다.

왜 개발팀 검토 없이 게시가 가능했나

이 조직은 GTM 게시 권한을 마케팅팀 담당자에게 제한 없이 부여하고 있었고, 커스텀 HTML 태그처럼 임의의 자바스크립트를 실행하는 태그를 게시하기 전에 개발팀이 검토하는 절차가 없었습니다. GTM이 "개발자 없이도 태그를 관리할 수 있다"는 편의성을 내세우는 도구이다 보니, 이 조직은 그 편의성을 별다른 통제 없이 그대로 받아들이고 있었습니다.

사고 이후 어떤 개선이 이뤄졌나

사고 이후 이 조직은 GTM 태그 게시 권한을 승인 절차와 연동해, 커스텀 HTML 태그처럼 리스크가 큰 태그 유형은 개발팀의 코드 리뷰를 거친 뒤에만 게시할 수 있도록 프로세스를 바꿨습니다. 또한 결제 페이지처럼 핵심 플로우에 영향을 줄 수 있는 태그는 별도의 스테이징 환경에서 실제 결제 흐름을 끝까지 테스트한 뒤에만 게시하는 규칙을 추가했습니다.

이 사고와 데이터 레이어 거버넌스는 어떤 관계가 있나

이 사고는 표면적으로는 결제 버튼 충돌 문제이지만, 근본적으로는 GTM 변경 사항을 관리하는 거버넌스 자체가 없었다는 더 큰 문제의 한 사례입니다. 앞서 다룬 데이터 레이어 표준 스키마나 태그 관리 문서화도 결국 같은 원리로, "누가 무엇을 언제 어떤 절차로 변경할 수 있는가"를 명확히 정해두지 않으면 아무리 좋은 도구를 쓰더라도 이런 사고가 반복될 수 있습니다. 이 사고를 계기로 GTM 게시 절차만 손보고 데이터 레이어나 태그 문서화 같은 다른 거버넌스 영역은 그대로 방치한다면, 형태만 다른 유사 사고가 다른 영역에서 재발할 가능성이 남아 있습니다.

이런 사고를 예방하려면 지금 무엇을 점검해야 하나

현재 조직에서 GTM 게시 권한을 누가 갖고 있는지, 커스텀 HTML 태그 게시 전에 개발팀 검토 절차가 있는지 확인하는 것이 이런 사고를 예방하는 첫걸음입니다. 특히 결제·회원가입처럼 핵심 플로우가 있는 페이지에 새 태그를 추가할 때는 일반 페이지보다 더 엄격한 검증 절차를 적용해야 합니다.

이 사고가 매출에 미친 영향은 어떻게 산정해야 하나

결제가 반나절 동안 먹통이 되면, 그 시간 동안 발생했을 매출을 정확히 계산하기는 어렵지만 평소 같은 요일·시간대의 평균 결제 건수와 금액을 기준으로 대략적인 손실 규모를 추정할 수 있습니다. 이런 추정치는 사고 재발 방지 대책에 투자할 리소스를 정당화하는 근거 자료로 활용할 수 있으며, 경영진에게 이 문제의 심각성을 구체적인 숫자로 전달하는 데도 도움이 됩니다.

이 추정 작업을 사고 직후에 곧바로 진행해두면, 시간이 지나 기억이 흐려진 뒤에 손실 규모를 재구성하려 할 때보다 훨씬 정확한 숫자를 확보할 수 있습니다. 사고 대응 프로세스에 "손실 규모 추정"을 정식 단계로 포함시켜두는 것도 좋은 방법입니다.

이런 사고는 GTM에서만 발생하는가

이 사례는 GTM이라는 특정 도구의 문제라기보다, "비개발 인력이 프로덕션에 직접 코드를 반영할 수 있는 도구"가 갖는 보편적인 위험을 보여주는 사례에 가깝습니다. 노코드·로우코드 도구가 늘어나는 만큼, 마케팅팀이나 다른 비개발 부서가 직접 다루는 도구가 늘어날수록 이와 유사한 유형의 사고가 다른 도구에서도 재현될 수 있습니다. GTM 하나만 통제한다고 안심하기보다, 비개발 인력이 프로덕션에 영향을 줄 수 있는 다른 도구가 또 있는지도 함께 점검해볼 필요가 있습니다.