서비스 계정을 만드는 데는 4분. 첫 동기화에서 소급 반영되는 Search Console 기록은 16개월. 이미 인증되고 권한이 부여된 도메인이라면 2초. 그리고 2개월 — 다른 세 숫자를 합친 것보다 더 많은 지원 티켓을 유발하는 숫자로, 이는 GA4의 기본 데이터 보관 기간이며 연결하기 전에 확인해야 한다는 사실을 아는 사람은 거의 없습니다.
설정 자체는 간단합니다. 설정 → Google 계정에서 자격 증명 하나, 도메인 관리에서 연결 버튼 두 개면 끝이고, 그 이후로는 이 페이지의 존재를 대부분 잊게 됩니다. 하지만 앞서 언급한 2개월이라는 숫자는 자세히 설명할 가치가 있습니다. 왜 어떤 도메인은 첫날부터 풍부하고 유용한 Analytics 기록을 보여주고, 다른 도메인은 몇 주 동안 거의 아무것도 보여주지 않는지 설명해 주기 때문이며, 이런 경우가 플랫폼 버그는 아닙니다.
한 번만 부여하는 자격 증명 하나
여러분은 Google 서비스 계정 키 — 개인 로그인이 아닌 JSON 파일 — 를 업로드합니다. 만료되거나 누군가 비밀번호를 바꿀 때 깨지는 사람 OAuth 토큰이 아니라 로봇 계정 방식입니다. Google Cloud는 이를 한 번 발급하며, 삭제하지 않는 한 계속 작동합니다. 바로 이 방식 덕분에 플랫폼은 아무도 로그인하지 않은 새벽 3시에도 동기화를 수행할 수 있습니다.
처음 만들어 본다면 대략 앞서 말한 4분이 걸립니다. 새 프로젝트 또는 기존 프로젝트, IAM 및 관리자 → 서비스 계정 → 만들기, 키 다운로드. 드롭다운에서 보이는 것보다 권한 선택이 훨씬 중요합니다 — Search Console 속성과 Analytics 속성에 뷰어 권한만 부여하고, 그 이상은 주지 마세요. 팀들이 단순히 상단에 있다는 이유로 편집자 권한을 부여하는 경우를 봤는데, 6개월 뒤에는 왜 로봇 계정이 GA4 설정에 쓰기 권한을 갖고 있는지 아무도 설명하지 못합니다. 읽기 전용이 올바른 선택이며, 플랫폼은 설정을 절대 건드리지 않습니다.
키 하나로 해당 Google Cloud 프로젝트 아래의 모든 도메인을 처리할 수 있습니다. 만약 여러 클라이언트 사이트를 운영하는 에이전시라면, 전체를 하나의 서비스 계정으로 묶기보다는 클라이언트별로 서비스 계정을 하나씩 두는 편이 낫습니다 — 클라이언트 오프보딩이 단순히 키 하나를 삭제하는 일이 되며, 이미 퇴사한 사람과 조용히 자격 증명을 공유하던 도메인이 어디인지 감사할 필요가 없어집니다.
Search Console: 빠를 때는 빠르고, 아닐 때는 답답한
- 도메인에서 연결을 엽니다. Search Console과 Analytics 각각 카드가 있으며, Analytics에는 "Search Console과 동일" 단축 옵션이 있습니다. 보통 키 하나로 둘 다 처리되기 때문입니다.
- 이미 인증되어 서비스 계정에 접근 권한이 부여되어 있다면? 즉시 처리됩니다 — 권한 확인만 하면 되며 약 2초가 걸립니다.
- 아직 인증되지 않은 경우: 등록기관의 API 키(Cloudflare, Route 53 등)를 제공하면 자동 DNS 인증이 가능하고, 직접 추가하는 수동 TXT 레코드 방식도 있습니다.
사람들이 조바심을 내는 지점이 바로 수동 방식입니다. 전파 시간은 실제로 편차가 큽니다 — 어떤 경우는 90초, 어떤 경우는 4시간, TTL과 리졸버 캐싱에 따라 달라집니다. 플랫폼이 계속 폴링하므로, 레코드를 추가하고 기다리면 됩니다. 하루가 지나도 인증이 안 된다면 전파 문제인 경우는 드뭅니다 — 값에 오타가 있거나 레코드가 잘못된 존에 등록된 경우(루트 대신 서브도메인, 혹은 그 반대)입니다. Google 탓을 하기 전에 실제로 반영된 값을 대상으로 `dig TXT`를 실행해 보세요.
API 키 방식은 레코드를 대신 작성해주므로 이런 과정을 건너뛸 수 있지만, 대신 서드파티 도구에 DNS 쓰기 권한을 넘겨야 합니다 — 그리고 그 DNS가 프로덕션 트래픽을 처리한다면, 망설이는 것도 무리는 아니라고 생각합니다. 수동 방식은 처음에 몇 분이 더 들지만, 이후로는 다시 신경 쓸 필요가 없다는 대가를 얻습니다.
Analytics, 그리고 아무도 알려주지 않는 보관 기간 격차
Analytics는 인증이 아니라 탐지 방식으로 연결됩니다 — 플랫폼이 해당 도메인에 기존 GA4 속성이 있는지 찾고, 서비스 계정에 접근 권한이 있으면 연결합니다. GA4 권한은 이미 Google 측에서 통제되고 있기 때문입니다. 아무것도 없으면 새 속성을 만들 수도 있지만, 진짜로 새로운 사이트일 때만 그렇게 하게 두세요. Universal Analytics에서 마이그레이션했거나 몇 년치 기록이 있는 속성이 있다면 그 속성에 명시적으로 연결하세요. 사흘치 데이터만 있는 새 속성은 계절적 패턴이 이미 쌓인 9년 된 속성보다 훨씬 나쁜 출발점이며, 최적화 루프는 연결 흐름이 암시하는 것보다 그 기록에 훨씬 더 의존합니다.
여기서 사람들이 걸리는 격차가 있습니다. Search Console은 첫 동기화 시 최대 16개월치 쿼리 데이터를 소급 반영합니다. Google이 연결 시점과 무관하게 서버 측에 그만큼의 기록을 보관하고 있기 때문입니다. GA4에는 그런 보장이 없습니다 — 소급 반영 범위는 속성 자체의 데이터 보관 설정에 따라 제한되며, 조직 내 누군가 변경하지 않았다면 그 설정은 기본값인 2개월입니다. 그래서 같은 도메인이, 같은 날, 같은 설정 흐름을 거쳤는데도 연결 즉시 16개월치 노출수와 클릭수를 보여주면서 세션 데이터는 2개월치만 보여주는 일이 생깁니다. 이는 동기화 오류가 아닙니다. Google의 보관 기본값이 설정된 대로 정확히 작동하고 있는 것이며, 앞으로 더 긴 기간을 원한다면 이 플랫폼이 아니라 GA4 속성 설정에서 직접 보관 기간을 변경해야 합니다. 혼란을 겪은 뒤가 아니라 연결하기 전에 확인할 가치가 있습니다.
공유 속성과 그 이후 동작 방식
Analytics에 관한 한 가지 더 미묘한 점: 조직이 다섯 개 사이트의 데이터를 수집하는 GA4 속성 하나만 운영하는 경우 — 몇 년 전에 누군가 추적을 설정한 뒤 아무도 분리하지 않은 흔한 상황 — 연결 자체는 문제없이 작동하지만, 모든 쿼리는 백그라운드에서 호스트명으로 필터링됩니다. 체크박스도 아니고, 실수로 끌 수 있는 설정도 아닙니다. 대시보드가 항상 이 도메인의 수치만 보여주고, 속성 전체의 합계는 절대 보여주지 않는 이유가 바로 이것입니다.
두 연결이 모두 완료되면, 동기화는 사용자가 제어하는 일정에 따라 매일 실행되며(일정 챕터 참고), 플랫폼에서 구축된 모든 항목에 대해 스토어 애널리틱스가 자동으로 결합됩니다. 도메인 행에는 대기 중, 부분, 또는 활성 상태가 표시됩니다 — "부분"은 두 연결 중 하나는 정상이고 다른 하나는 그렇지 않다는 뜻이며, 이는 전체 상태만 믿지 말고 어느 카드가 빨간색인지 직접 확인해야 한다는 신호입니다.
실제로 문제가 생기는 지점
제가 본 거의 모든 티켓은 특별할 것 없는 세 가지 유형으로 나뉩니다. 첫째, 서비스 계정 키는 유효하지만 잘못된 Google Cloud 프로젝트에 스코프가 지정되어 있어서, 키 업로드 자체는 성공해도 권한 확인 결과가 비어 있는 경우입니다. 둘째, 서비스 계정의 이메일 주소 — 예를 들어 [email protected] — 를 아무도 Search Console이나 GA4 자체의 액세스 설정에서 뷰어로 추가하지 않은 경우입니다. 플랫폼에 키를 업로드하는 것만으로는 Google 측에서 아무 권한도 부여되지 않습니다. 셋째, 좀 더 교묘한 경우: 도메인이 새 서비스 계정으로 다시 연결되었는데 기존 계정이 삭제된 뒤에도 일정이 조용히 실패를 반복하며, 수치가 업데이트를 멈춘 지 일주일이 지나도록 아무도 눈치채지 못하는 경우입니다.
이 중 어느 것도 플랫폼 버그가 아닙니다 — 로봇이 서로 다른 두 Google 제품에서 각각 권한을 받아야 하는 데서 오는 통상적인 비용이며, Google의 방식 자체가 이를 직관적으로 보여주지 않을 뿐입니다. 첫 도메인에는 흐름이 암시하는 2분이 아니라 15분을 잡아두세요. 그 이후 도메인들은 자격 증명과 익숙해진 손놀림 덕분에 모두 빠르게 진행됩니다.
