느려졌다는 말을 무엇으로 재나

결제 지연은 체감이 아니라 지표로 잡아야 논의가 됩니다. 상호작용 응답성을 재는 지표는 INP이고, 구글이 정의한 기준값은 페이지 조회의 75퍼센타일에서 200밀리초 이하가 양호, 200밀리초 초과 500밀리초 이하가 개선 필요, 500밀리초 초과가 나쁨입니다.

INP가 재는 시간은 세 구간으로 나뉩니다. 입력 지연, 처리 시간, 프레젠테이션 지연입니다. 태그를 많이 붙였을 때 문제가 되는 곳은 주로 첫 구간입니다. 입력 지연은 메인 스레드를 붙잡고 있는 긴 작업 때문에 생기는 경우가 많고, 구글은 상호작용성을 좌우하는 주된 요인으로 자바스크립트를 지목합니다. 사용자가 결제 버튼을 눌렀는데 반응이 없는 순간은, 브라우저가 그 클릭을 처리할 여유가 없어 대기하고 있는 시간입니다.

그래서 개선 목표도 세 구간 중 어디를 줄일 것인지로 세워야 합니다. 태그 정리는 입력 지연을 겨냥한 작업이고, 결제 API 응답 속도는 다른 문제입니다.

태그 몇 개부터 위험한지 숫자를 묻는다면

공식 기준으로 공개된 바 없습니다. 구글 web.dev도 서드파티 스크립트가 렌더링을 막을 수 있다는 메커니즘은 설명하지만, 태그 개수당 지연 시간을 수치로 제시하지 않습니다. 태그당 지연은 스크립트 크기, 실행 시간, 네트워크 상태에 따라 달라져 일반화되지 않기 때문입니다.

확인된 인접 사실은 있습니다. web.dev는 서드파티 자바스크립트가 추가 네트워크 요청을 일으키고, 최적화되지 않은 이미지와 영상을 끌어오며, 여러 벤더가 같은 프레임워크를 중복으로 불러오는 문제를 지적합니다. 그리고 서드파티 코드가 임계 렌더링 경로 안에서 동기적으로 로드되면 문서의 나머지 파싱이 지연되고, 벤더 서버가 장애를 일으키면 요청 타임아웃이 날 때까지 10초에서 80초 동안 렌더링이 완전히 막힐 수 있다고 설명합니다. 개수가 아니라 로드 방식과 벤더 안정성이 변수라는 뜻입니다.

기준선은 자사 데이터로 세웁니다. 최소 4주치 INP 기준선을 확보하고, 한 번에 한 항목만 바꾸고, 같은 요일끼리 비교하고, 가능하면 변경하지 않은 구간을 남겨 대조합니다. 결제 페이지는 요일과 프로모션에 따라 트래픽 구성이 크게 달라지므로 이 절차 없이 전후 하루를 비교하면 판단이 뒤집힙니다.

GTM 안에서 지금 돌릴 수 있는 손잡이는 무엇인가

세 가지가 태그 고급 설정에 있습니다.

첫째, 태그 실행 옵션입니다. 값은 Unlimited, Once per event, Once per page 세 가지입니다. Unlimited는 트리거가 지시할 때마다 매번 실행하는 값으로 태그 시퀀싱과 함께 쓰는 옵션이고, Once per event는 지정한 이벤트가 발생할 때 한 번만, Once per page는 페이지가 로드될 때 한 번만 실행합니다. 결제 완료 페이지처럼 한 번만 발동하면 되는 태그가 Unlimited로 남아 있는 구성이 흔하고, 이건 성능과 중복 집계 양쪽에 걸립니다.

둘째, 태그 실행 우선순위입니다. 태그가 실행되는 순서를 결정하며 양의 정수와 음의 정수를 모두 넣을 수 있습니다. 매출 집계에 직접 쓰이는 태그를 앞으로 당기고, 보조 태그를 뒤로 미는 데 씁니다.

셋째, 태그 시퀀싱입니다. 이 태그가 실행되기 전에 설정 태그를 실행하도록 지정하면 설정 태그가 먼저 실행되고, 이 태그가 완료되면 정리 태그를 실행하도록 지정하면 정리 태그가 직후에 실행됩니다. 여러 매체 태그가 같은 값을 필요로 할 때 값을 만드는 태그를 설정 태그로 묶으면 같은 계산을 여러 번 반복하지 않게 됩니다.

태그 목록은 어떤 기준으로 줄이나

web.dev가 제시하는 관리 방법은 네 가지입니다. 필요한 기능을 최소 코드로 제공하는 벤더를 고르는 것, 서드파티 리소스에 성능 예산을 설정하고 모니터링하는 것, 중복 서비스를 제거하는 것, 불필요해진 스크립트를 주기적으로 감사하는 것입니다. 중복 서비스 제거에는 분석 도구나 태그 관리자를 두 개 쓰지 않는다는 항목이 명시돼 있습니다.

실무에서 가장 큰 덩어리가 마지막 항목입니다. 종료된 캠페인의 매체 태그, 쓰지 않는 히트맵 도구, 담당자가 바뀌며 남은 검증용 태그가 컨테이너에 그대로 있는 경우가 많습니다. 태그를 지우기 전에 무엇이 무엇을 위해 붙어 있는지 목록으로 정리하는 작업이 먼저이고, 소유자를 특정할 수 없는 태그부터 후보로 올립니다.

브라우저 밖으로 옮기면 무엇이 달라지나

서버사이드 GTM은 이벤트 데이터를 브라우저가 아니라 클라우드 서버를 통해 보내는 방식으로, 자사 도메인에 호스팅된 서버 컨테이너가 웹사이트와 분석·광고 플랫폼 사이의 중간 레이어 역할을 합니다. 정리된 장점에는 데이터 정확성 향상, 개인정보 제어 강화, 웹사이트 성능 개선(브라우저 부하 감소), 광고 차단 대응, 데이터 라우팅 유연성이 들어갑니다. 브라우저에서 매체마다 스크립트를 로드하던 구조가 바뀌므로, 메인 스레드 관점에서는 방향이 맞습니다.

다만 비용 구조가 따라옵니다. 구글 공식 가이드는 App Engine 배포 시 프로덕션 기준 서버 36대 구성을 권장하고 서버 1대당 월 약 40달러, 초당 요청 50200건을 기준값으로 제시합니다. Cloud Run으로 배포하면 트래픽에 따라 동적으로 확장되며 최대 인스턴스 수 설정값이 이론상 지불할 수 있는 최악의 비용 상한으로 작동합니다. 자동 확장은 유입에 비례해 인스턴스를 늘리는 구조라, 최대 인스턴스 수나 예산 알림을 미리 걸어두지 않으면 봇 트래픽이나 이벤트 폭주 때 요금이 통제 없이 늘어납니다. 옮기는 결정과 상한을 거는 설정은 같은 날 함께 해야 합니다.