SSOT Web

서비스별 단일 GA 테이블에 모든 TAG를 저장하는 기존 구조의 컬럼 과다 문제를 해소하기 위해 TAG별 별도 테이블 분리를 검토했으나, 관리 요소 감소와 Kafka 프로듀서·컨슈머 구성 간소화를 이유로 기존과 동일한 단일 테이블 구조를 유지하기로 결정했다.

배경

기존(2025-10-21 기준) 비즈하우스·디자인 허브·프린트 허브·미리캔버스 4개 서비스는 각각 서비스별 단일 GA 테이블 구조를 쓰고 있었고, 모든 TAG가 하나의 테이블에 저장되어 컬럼 수가 매우 많아지는 문제가 있었다(원문 첨부 스크린샷 캡션 "매우 많은 컬럼" — 이미지 자체는 이 문서에 옮기지 않았다).

서비스별 기존 GA 테이블 조회 쿼리(Databricks 노트북)는 아래와 같다.

결정

TAG별 별도 테이블로 분리하는 대신, 기존과 동일한 단일 테이블 구조를 유지하기로 결정했다.

근거 / 검토한 선택지

검토안 — TAG별 별도 테이블 (기각)

2025-10-16 진행한 GA & GTM 온보딩에서 서유진님과 논의했다.

하나로 합쳐진 GA 테이블이 아닌 TAG 종류별 테이블
장점: 조회 속도 이점, 로직 복잡도 감소
기존 단일 테이블 쿼리의 수정은 가능한 작업이라고 함
~~단일 TAG 방향으로 진행 시 event_name으로 테이블 분리~~ — 원문에서 취소선 처리되어 검토 후 제외된 세부안

채택안 — 기존과 동일한 단일 테이블 구조 (채택)

Tag, 이벤트 변수 변경에 따른 관리 요소 감소
Kafka 프로듀서, 컨슈머 구성 간소화
GA 데이터에 로직 처리가 필요하면 실버 테이블에서 처리

후속 작업

후속 작업 없음 — 원문에 명시된 실행 항목이 없다.

아직 해결되지 않은 것

이 결정이 내려진 정확한 일자가 원문에 없어 record_date 를 채우지 못했다. 2025-10-16은 TAG별 테이블 분리안을 논의한 날짜이고, 2025-10-21은 기존 구조를 기술한 기준일이다 — 둘 다 최종 방향을 확정한 날짜라고 원문이 명시하지 않는다.
TAG별 테이블 분리안의 "조회 속도 이점"·"로직 복잡도 감소" 를 뒷받침하는 정량적 근거(예: 실측 쿼리 성능 비교)는 원문에 없다.

GA 테이블 구조 결정 — TAG별 분리 검토 후 기존 단일 테이블 유지

배경

결정

근거 / 검토한 선택지

후속 작업

아직 해결되지 않은 것

관련 문서

GA 테이블 구조 결정 — TAG별 분리 검토 후 기존 단일 테이블 유지

배경

결정

근거 / 검토한 선택지

후속 작업

아직 해결되지 않은 것

관련 문서

플랫폼엔지니어링의 다른 문서

플랫폼엔지니어링의 다른 문서