광고비부터 매출까지, 퍼널을 잇는 다섯 개의 레이어 RevDrill 아키텍처 살펴보기
광고비 1원이 매출로 이어지기까지, RevDrill 같은 풀퍼널 마케팅 인텔리전스 툴이 거치는 다섯 개 레이어(데이터 수집·파이프라인·AI 에이전트·실행 승인·인프라 보안)를 살펴봅니다.
"광고비 1원이 매출 몇 원이 됐는가"에 답하려면, 데이터가 흩어져 있던 곳에서부터 사람이 결정을 내리는 순간까지 여러 단계를 거쳐야 해요. RevDrill 같은 풀퍼널 마케팅 인텔리전스 + AI 에이전트 툴은 보통 다섯 개의 레이어로 이 과정을 구성합니다. 개발 용어를 잘 몰라도 괜찮아요.
각 단계를 일상적인 비유로 먼저 풀고, 궁금하신 분들을 위해 기술적인 설명도 함께 담았어요.
데이터 수집 (Data Ingestion)
광고 플랫폼과 자사 사이트에서 이벤트를 끌어오는 부분이에요.
여러 군데 흩어진 영수증을 한곳에 모으는 단계예요. 메타·네이버·구글 광고에 얼마를 썼는지, 우리 사이트에서 사람들이 어디를 클릭하고 어디서 나갔는지, 상담 전화는 몇 통이 왔는지. 이 모든 정보가 원래는 서로 다른 곳에 따로따로 저장돼 있어요. RevDrill은 이걸 사람이 일일이 복사·붙여넣기 하지 않아도 자동으로 끌어와요.
- 광고 플랫폼 API 연동메타 Marketing API, 네이버 검색광고 API, 구글 Ads API를 통해 광고비·노출·클릭 데이터를 배치(주기적) 또는 웹훅 방식으로 수집합니다.
- 웹 트래킹 SDK자체 픽셀·스크립트를 사이트에 심어서 스크롤, 클릭, 히트맵, 세션 흐름 등 행동 데이터를 수집해요.
GA4, Amplitude, Mixpanel류와 비슷한 원리를 자체 구현하는 경우가 많습니다. - CRM·전화 시스템 연동상담 신청, 통화 녹음 데이터를 CRM이나 콜 시스템 API에서 가져옵니다.
데이터 파이프라인 & 저장 (ETL/CDP)
여러 소스에서 온 데이터를 하나의 사용자 여정으로 잇는 부분이 기술적으로 가장 까다로워요.
모아온 정보들이 사실은 '같은 한 사람' 이야기라는 걸 알아채는 단계예요. 광고를 클릭한 사람과, 나중에 전화 상담을 한 사람과, 최종적으로 결제한 사람이 서로 다른 이름과 번호로 기록돼 있어도, 실제로는 한 명의 고객이 남긴 발자국이잖아요. 이 조각들을 퍼즐처럼 맞춰서 "이 사람이 어떤 광고를 보고, 어떻게 움직여서, 결국 구매까지 했는가"라는 하나의 이야기로 만들어요. 그리고 매출이 났을 때 "어떤 광고 덕분이었는지"를 계산하는 것도 이 단계의 일이에요.
- ID 매칭 · 디바이스 그래프광고 클릭 시 붙는 UTM·클릭ID를 세션ID, 이후 전화번호·이메일까지 연결해서 '한 사람의 여정'으로 통합합니다. 흔히 CDP(Customer Data Platform)로 부르는 개념이에요.
- 이벤트 스트리밍Kafka, Kinesis 같은 스트리밍 인프라로 실시간에 가깝게 이벤트를 처리합니다.
- 데이터 웨어하우스BigQuery, Snowflake, ClickHouse 등에 적재해서 대용량 쿼리를 처리해요.
- 어트리뷰션 모델링클릭 → 방문 → 상담 → 구매까지, 어떤 광고·소재가 기여했는지 계산하는 로직이에요. 라스트클릭, 멀티터치, 마르코프체인 기반 어트리뷰션 등 다양한 방식이 있습니다.
여기까지가 데이터를 모으고 정리하는 '기초 공사' 단계예요.
이제부터는 그 위에서 실제로 판단을 도와주는 AI 이야기입니다.
AI / LLM 에이전트
여기가 요즘 이런 툴들의 차별점이에요.
정리된 데이터를 보고 실제로 "다음에 뭘 해야 할지" 사람 대신 생각해주는 단계예요. 마치 전략 담당, 광고 담당, 콘텐츠 담당처럼 역할을 나눠 가진 여러 명의 AI 비서가 같은 자료를 보면서 각자 자기 일을 하는 것과 비슷해요. 필요하면 지나간 상담 기록이나 리뷰까지 찾아서 참고하고("이런 자료가 있었지"), 판단이 서면 광고 시스템에 직접 요청도 보낼 수 있어요("이 소재는 꺼야겠다"). 전화 상담 녹음을 글로 옮기는 것도 이 단계에서 하는 일입니다.
- RAG (검색증강생성)정형 데이터(퍼널 지표)와 비정형 데이터(상담 녹취, 리뷰)를 LLM이 참조할 수 있게 벡터DB나 지식 그래프로 구조화합니다.
- 에이전트 오케스트레이션전략, 광고 운영, 콘텐츠 등 여러 역할을 나눠 각각 다른 프롬프트·툴 접근권한을 가진 서브에이전트로 구성하고, 오케스트레이터가 작업을 분배해요. LangGraph, AutoGen류 프레임워크를 쓰거나 자체 구현하는 방식이 있습니다.
- 함수 호출 · 툴 사용LLM이 직접 광고 API를 호출해서 '이 소재 OFF' 같은 액션을 제안하거나 실행하는 구조예요 (Function calling).
- STT · 화자분리상담 녹음을 텍스트로 바꾸는 부분은 Whisper류 오픈소스 모델을 쓰거나, 자체 엔진을 쓰는 경우도 있습니다.
실행 · 승인
AI가 뭔가를 제안했다고 해서 곧바로 실행되는 건 아니에요. 회사에서 결재 문서를 올리면 상사가 검토 후 승인 도장을 찍는 것처럼, AI의 제안도 사람이 확인하고 승인 버튼을 눌러야만 실제 광고 계정에 반영돼요. 게다가 아무리 승인을 받았더라도 한 번에 바꿀 수 있는 범위 자체를 미리 정해둬서, 실수로 예산을 크게 흔들 위험도 함께 막아둬요. 누가 언제 어떤 결정을 내렸는지도 전부 기록에 남아서, 나중에 "왜 이런 변경이 있었는지" 언제든 되짚어볼 수 있어요.
- Human-in-the-loop 워크플로우AI가 제안한 변경사항(예산 조정, 소재 ON/OFF 등)을 사람이 승인하기 전까지 실행되지 않도록 막는 게이트 로직이에요. 제안이 올라오면 대기 상태(pending)로 큐에 쌓이고, 지정된 승인권자가 확인해야만 다음 단계로 넘어갑니다.
- 승인 권한 분리 (Segregation of Duties)제안하는 주체(AI)와 승인하는 주체(사람)를 시스템적으로 분리해요. 같은 계정이 제안과 승인을 동시에 할 수 없도록 막아, AI의 판단이 검증 없이 그대로 반영되는 걸 원천 차단합니다.
- 변경 한도 · 예산 변경폭 제한승인권자가 있더라도 한 번에 바꿀 수 있는 범위 자체에 상한을 둬요. 하루에 조정 가능한 소재 개수, 예산을 늘리거나 줄일 수 있는 최대 비율 같은 걸 미리 정해둬서, 실수나 이상 동작으로 인한 피해 범위를 제한합니다.
- 전체 이력 기록 (Audit Trail)누가, 언제, 어떤 근거로, 무엇을 승인했는지 모든 변경 이력이 로그로 남아요. 나중에 "왜 이 소재가 꺼졌는지" 되짚어볼 수 있고, 감사·검증이 필요할 때도 그대로 근거 자료가 됩니다.
- 광고 API 라이트백 (write-back)승인되면 실제로 메타·구글 Ads API를 호출해서 캠페인을 조정해요. 이때 API 호출이 실패하거나 매체 쪽에서 거절되는 경우를 대비한 재시도·오류 처리 로직도 함께 갖춰야 안정적으로 동작합니다.
- 롤백 · 되돌리기반영된 변경이 예상과 다르게 작동할 경우, 이전 상태로 되돌릴 수 있는 경로를 마련해둬요. 특히 예산처럼 되돌리기 어려운 변경일수록 이 장치가 중요합니다.
인프라 · 보안
여러 회사가 같은 서비스를 함께 쓰더라도, 서로의 데이터는 절대 섞이거나 보이지 않아요. 각자 자기 창고에 자물쇠를 걸어두는 것과 같은 원리예요. 보안이 특히 중요한 금융·공공기관 고객의 경우, 아예 데이터가 외부로 나가지 않고 회사 내부 서버 안에서만 처리되는 방식(온프레미스)을 선택할 수도 있어요. 그리고 담당자마다 볼 수 있는 범위와 할 수 있는 일이 다르게 설정돼요. 예를 들어 광고 예산을 실제로 바꿀 수 있는 사람은 별도로 지정해두는 식이에요. 여기에 국제 보안 인증까지 갖추고 있는지가, 기업 고객이 도입을 결정할 때 살펴보는 기본 체크리스트가 됩니다.
- 멀티테넌시고객사별 데이터 격리. 스키마 분리(고객사마다 별도의 DB 스키마) 또는 row-level 보안(같은 테이블 안에서도 조직 ID로 행 단위 접근을 제한) 방식을 씁니다. 어느 쪽이든 한 고객사의 쿼리가 다른 고객사의 데이터에 물리적으로 닿을 수 없게 설계하는 게 핵심이에요.
- 온프레미스 · 클라우드 옵션금융·공공기관 고객을 상대하는 국내 업체들은 온프레미스 구축을 많이 지원해요. 데이터가 아예 외부 네트워크로 나가지 않고 고객사 내부 서버에서만 처리되는 방식이라, 규제가 엄격한 산업군에서 특히 요구됩니다.
- 권한 관리 (RBAC)역할 기반 접근 제어를 적용해서, 담당자별로 볼 수 있는 화면과 할 수 있는 행동을 다르게 부여해요. 특히 광고 계정을 실제로 바꿀 수 있는 승인권자는 조회만 가능한 일반 사용자와 별도로 지정합니다.
- 암호화전화번호·이메일 같은 개인정보는 저장할 때(at rest)와 전송할 때(in transit) 모두 암호화돼요. 상담 녹취처럼 민감한 데이터일수록 접근 자체를 별도 권한으로 한 번 더 제한하는 경우가 많습니다.
- 보안 인증 · 표준 준수ISO/IEC 27001(정보보안), 27017(클라우드 보안), 27018(클라우드 개인정보보호) 같은 국제 인증을 갖추고 있는지가 기업 고객 도입 심사의 기본 체크포인트가 돼요.
- 백업 · 장애 대응일일 자동 백업과 복구 절차를 갖춰서, 장애가 나더라도 데이터 유실 없이 복원할 수 있게 해요. 온보딩 시 계정·시스템 연동을 짧은 시간 안에 마칠 수 있도록 표준화된 절차를 두는 것도 이 레이어의 역할입니다.
다섯 개 레이어, 한 줄로 다시 정리하면
데이터 수집
광고·웹사이트·상담 채널에 흩어진 정보를 자동으로 끌어옵니다.
데이터 파이프라인 & 저장
흩어진 조각을 한 사람의 여정으로 잇고, 어떤 광고 덕분인지 계산합니다.
AI / LLM 에이전트
정리된 데이터를 보고 다음에 무엇을 해야 할지 근거와 함께 제안합니다.
실행 · 승인
AI의 제안은 사람이 검토하고 승인해야만 실제로 반영됩니다.
인프라 · 보안
고객사별 데이터는 완전히 격리되고, 권한과 이력이 촘촘하게 관리됩니다.
앞의 두 단계(데이터 수집·정리)는 흩어진 정보를 하나로 모으는 '기초 공사'고, 뒤의 세 단계(AI 판단·승인·보안)는 그 위에서 실제로 사람과 함께 일하는 '살림'이에요.
데이터를 잘 모으는 것만큼, 그 데이터로 안전하게 판단을 내리고 실행하는 구조가 갖춰져야 진짜로 쓸모 있는 툴이 됩니다. 결국 좋은 마케팅 인텔리전스 툴은 데이터를 정확히 보여주는 것에서 그치지 않고, 그 데이터를 근거로 안전하게 판단하고 실행까지 이어지는 다섯 단계 전체가 하나로 맞물려 돌아갈 때 완성됩니다.