RACI를 왜 데이터 인프라 작업에 써야 하나

RACI는 작업마다 실행(Responsible), 최종책임(Accountable), 자문(Consulted), 통보(Informed)를 배정하는 방식입니다. 마케팅 데이터 인프라가 특히 이 표를 필요로 하는 이유는, 작업의 절반이 마케팅 도구 안에서 일어나고 나머지 절반이 자사 서비스 코드 안에서 일어나기 때문입니다. 도구 안 작업은 마케터가 직접 할 수 있고, 코드 안 작업은 전산팀 없이는 불가능한데, 이 경계가 도구마다 다릅니다.

특히 GTM 같은 태그 관리 도구는 경계를 흐립니다. GTM 컨테이너는 특정 웹사이트나 앱에 설치된 태그·트리거·변수 구성 전체를 담는 패키지이고, 마케터가 코드 배포 없이 태그를 바꿀 수 있게 해줍니다. 편리하지만 그 태그가 실제 페이지에서 실행된다는 사실은 변하지 않습니다. 권한상 마케터가 할 수 있다는 것과 책임상 마케터가 져야 한다는 것은 다른 문제이고, RACI는 이 둘을 분리해 적는 도구입니다.

태그 배포에서 책임을 어떻게 나눠야 하나

현실적인 배분은 이렇습니다. 태그 기획과 값 정의는 마케팅팀이 실행하고, 자사 서비스 페이지에 영향을 줄 수 있는 태그의 배포 승인은 전산팀이 최종책임을 갖는 구조입니다. 데이터레이어는 사용자 행동 발생 시 값을 넣는 임시 저장소이므로, 어떤 키에 어떤 값을 담을지는 마케팅팀이 정의하되 실제 코드에 심는 것은 개발 영역입니다.

배포 전 확인 절차도 RACI에 포함해야 합니다. GTM의 미리보기·디버그 모드는 태그 구성이 정상 작동하는지 배포 전 실시간으로 테스트하는 기능으로, 실행된 태그와 처리 중인 데이터, 트리거 조건 충족 여부를 확인할 수 있습니다. 이 확인을 누가 하고 누가 승인 기록을 남기는지까지 적어두면, 문제가 생겼을 때 원인을 되짚을 지점이 생깁니다. 참고할 사고 유형은 분명합니다. 마케팅 쪽에서 임의로 태그를 바꿨다가 결제 스크립트와 간섭해 서비스가 멈추는 사고는 업계에서 반복적으로 보고되는 패턴입니다.

스키마 변경은 누구의 결정 사항인가

스키마 변경은 RACI에서 가장 자주 비어 있는 칸입니다. 이벤트 이름을 바꾸거나 매개변수를 추가하는 작업은 마케팅 요구에서 시작하지만, 결과는 전산팀이 관리하는 코드와 데이터 파이프라인 전체에 영향을 미칩니다.

여기서 권장되는 배분은 정의는 마케팅팀 실행, 영향 범위 판단은 전산팀 자문, 승인은 데이터 인프라 담당자 최종책임입니다. GA4 쪽 제약이 판단 근거가 됩니다. 이벤트 이름 40자, 이벤트당 매개변수 최대 25개, 매개변수 값 일반적으로 100자 같은 한도가 있고, 주요 이벤트로 설정할 수 있는 개수도 표준 속성 30개, 360 속성 50개로 제한됩니다. 한도가 있는 자원이므로 선착순으로 채우는 것이 아니라 누군가 배분을 결정해야 하며, 그 사람이 최종책임자입니다.

클라우드 비용은 누가 책임지나

데이터 인프라에서 금액 사고가 나는 지점은 대체로 자동 확장 설정입니다. GTM 서버 컨테이너의 자동 확장은 유입 트래픽에 비례해 인스턴스를 늘리는 구조라, 최대 인스턴스 수나 예산 알림을 미리 설정하지 않으면 봇 트래픽이나 이벤트 폭주 상황에서 요금이 통제 없이 증가하는 구조적 리스크가 있습니다. 구글 공식 가이드도 App Engine 프로덕션 구성 기준값과 함께, Cloud Run의 최대 인스턴스 설정이 이론상 최악의 지출 상한으로 작동한다고 설명합니다.

BigQuery 쪽도 같습니다. 구글은 맞춤 쿼리 할당량을 만들어 프로젝트나 사용자 단위로 처리 데이터 한도를 두고, 쿼리당 청구 바이트를 제한하며, 실행 전 예상 비용을 확인하라고 권장합니다. RACI 표에는 이 설정들의 값을 누가 정하고 누가 정기적으로 점검하는지를 적어야 합니다. 구체적 단가는 리전과 시점에 따라 달라지므로 예산 산정 자체는 구글 클라우드 공식 가격표와 가격 계산기로 리전을 지정해 수행하고, 그 산정 결과의 승인 주체를 표에 명시해두는 방식이 실효적입니다.

표를 실제로 작동하게 만들려면 무엇이 더 필요한가

RACI 표의 흔한 실패는 항목이 너무 추상적이라는 것입니다. "데이터 관리"처럼 큰 단위로 적으면 실제 상황에서 아무 판단도 내려주지 않습니다. 항목은 실제로 벌어지는 사건 단위로 쪼개야 합니다. 새 태그 추가, 기존 태그 수정, 이벤트 이름 변경, 신규 매체 적재 추가, 권한 부여, 권한 회수, 비용 상한 변경, 장애 신고 접수 정도가 최소 단위입니다.

그리고 표에 한 칸을 더 붙이는 것이 좋습니다. 예외 상황의 판단 주체입니다. 긴급 캠페인으로 승인 절차를 건너뛰어야 할 때 누가 결정하는지, 승인 없이 배포된 변경을 발견하면 누구에게 알리는지를 적어두는 칸입니다. 정상 절차는 표가 없어도 대개 굴러가고, 표가 실제로 필요해지는 순간은 예외 상황입니다. 그 칸이 비어 있으면 표 전체가 장식이 됩니다.