분석가가 직접 만든 마케팅 자동화 시스템 — 오디언스 빌더 제작기

글. 조서연(Freya) / User Behavior팀

안녕하세요. User Behavior(UB)팀의 프레야입니다.

UB팀은 유저 행동 데이터를 수집하고 관리하는 데이터 분석 팀입니다. 최근 구매일, 선호 구매 카테고리, 회원 등급처럼 개인정보를 제외한 행동 특징을 정리한 ‘유저 피처 스토어’를 운영하는 등의 활동을 합니다. 행동 데이터를 쌓아 두는 데 그치지 않고 회사의 의사결정과 실무에서 실제로 쓰이게 만드는 것이 저희 팀의 역할입니다.

이 글에서는 개발 경험이 없던 데이터 분석가가 AI 에이전트와 바이브 코딩을 활용해 마케팅 자동화 시스템 ‘오디언스 빌더(Audience Builder)’를 만든 과정을 소개합니다. 마케터가 화면에서 간편하게 타겟 유저 조건을 설정하여 각 캠페인의 대상자 명단이 마케팅 채널에 전달되기까지의 과정을 차례로 이야기해 보겠습니다.

캠페인 대상자를 설정할 때의 병목

유저 데이터가 활발하게 쓰이는 분야 중 하나가 마케팅입니다. 모든 유저에게 동일한 메시지를 보내기보다 각자의 특징에 맞춘 캠페인을 운영하면, 유저의 반응을 이끌어내는 동시에 한정된 마케팅 예산으로 더 높은 성과를 낼 수 있습니다.

하지만 이를 실행하는 과정은 생각보다 번거로웠습니다. 예를 들어 앱 내 광고 배너 운영을 위해 어떤 단계를 거쳐야 했는지를 보여드리겠습니다.

1. 마케터가 배너 관리 도구에서 신규 오디언스를 생성합니다.
2. 어떤 유저가 그 광고를 봐야 할지 조건을 정리해 데이터 추출 담당자에게 전달합니다.
3. 담당자가 이 조건을 SQL 쿼리로 작성해 대상자 명단을 추출합니다.
4. 추출 결과를 CSV 파일로 저장합니다.
5. 이 파일을 배너 관리 툴 DB에 적재해 달라고 개발팀에 요청합니다.
6. 개발팀이 적재를 완료하면, 마케터가 배너 관리 도구에서 결과를 확인합니다.

간단한 캠페인 하나에도 여러 직무 간 소통이 필요했고, 그 과정에서 적지 않은 시간과 공수가 들었습니다.

문제는 이게 끝이 아니라는 점입니다. 추출된 타겟 유저 리스트는 그 시점에 고정되어 있지만, 유저들의 활동은 계속 변합니다. 시간이 지나면서 일부 유저는 금세 타겟 조건에서 이탈하고, 어떤 유저는 새로 타겟에 해당하게 됩니다. 그러면 타겟 유저 리스트를 주기적으로 업데이트해야 하는데, 그때마다 위의 과정을 전부 다시 거치거나, 아니면 이미 낡아버린 타겟 유저군을 그대로 사용하는 리스크를 안아야 했습니다.

최신 명단을 유지하려면 위 과정을 주기적으로 되풀이해야 했고, 그렇지 않으면 오래된 명단으로 캠페인을 운영해야 했습니다.

마케터가 직접 대상자를 설정하는 오디언스 빌더

이런 문제를 해소하고 개인화 마케팅을 훨씬 효율적으로 진행하기 위해, 마케팅실에서 새로운 툴을 고안했습니다. 그것이 오디언스 빌더입니다. 여기서 오디언스는 캠페인의 대상이 되는 유저 집합을 가리킵니다. 핵심 기능은 다음과 같이 정리할 수 있습니다.

1. SQL을 모르는 마케터도 자연어 필터와 조건 설정 화면에서 대상 조건을 만듭니다.
2. 이 조건을 SQL로 변환해 Data Warehouse(BigQuery)에서 실행합니다.
3. 추출한 결과를 마케팅 툴로 보내 같은 오디언스를 생성합니다.
4. 사용자가 정한 주기에 맞춰 추출과 전송을 반복합니다.

이렇게 되면 한 사람이 조건 설정부터 실제 운영까지 거의 10분 안에 마칠 수 있습니다. 조직 사이의 요청과 대기 시간이 줄고, 데이터 추출 담당자와 개발팀도 반복적인 추출·적재 작업에서 벗어날 수 있습니다. 캠페인을 기획한 시점과 실제 적용하는 시점 사이의 간격도 그만큼 짧아져서, 더 시의성 있는 캠페인 진행이 가능해집니다.

기획에서 제작까지, UB팀이 주도한 이유

마케팅 자동화 프로젝트는 개발팀도, 마케팅팀도 아닌 데이터 분석팀인 UB팀이 주도하여 진행했습니다. 개발 조직 입장에서는 유저 피처 스토어에 어떤 데이터가 어떤 형태로 쌓여 있는지 알기 어려웠고, 마케팅 조직 입장에서는 그 데이터가 시스템에서 어떻게 처리되는지 알기 어려웠습니다. 기획 조직도 마찬가지였습니다. 유저 피처 스토어가 실제로 어떻게 소비되어야 하는지, 행동 데이터가 어떤 방식으로 구성되어 있는지를 알아야 기획이 가능했습니다.

개발, 마케팅, 데이터 세 관점을 모두 아우를 수 있는 팀이 UB팀뿐이었습니다. 이 프로젝트는 저희 팀 입장에서도 반가운 일이었습니다. 초기 기획안을 검토했을 때 오디언스 빌더는 UB팀이 개발한 유저 피처 스토어를 마케팅에 활용하도록 돕는 도구였고, 유저 데이터를 더 많이 더 잘 활용하게 한다는 팀의 목표와도 맞았습니다. 그렇게 UB팀이 제작을 주도하기로 했고 제가 담당을 맡게 되었습니다.

기획의 큰 틀은 이미 잡혀 있는 상태로 프로젝트가 넘어왔지만, 개발이 시작된 뒤에는 PM/PO에 가까운 일도 함께 맡았습니다. 배포와 데이터 웨어하우스 연동은 Ops 조직과, 마케팅 툴 연동은 각 도메인을 담당하는 개발팀과 협의했습니다. 실제 사용자인 마케팅실에는 개발 현황을 공유하며 의견을 들었습니다. 배포 권한이나 외부 툴 계정처럼 UB팀이 직접 다룰 수 없는 영역만 다른 팀의 도움을 받았고, 나머지 작업은 전반적으로 제가 맡았습니다.

그러다 보니 UB팀은 개발팀이 아니고 저 역시 개발 경험이 없었지만, 프론트엔드 전체와 백엔드 일부를 직접 만들게 됐습니다. 배포와 외부 인프라 연동을 제외하고 웹 애플리케이션 안에서 동작하는 로직까지가 제 범위였습니다. 이는 AI 에이전트의 급성장으로 인해 바이브 코딩으로 개발이 가능해진 덕분이었습니다. 작업 방식은 다음과 같았습니다.

• 새 기능이나 레이아웃의 방향이 분명하지 않을 때는 AI 에이전트에 미리 등록해 둔 브레인스토밍 스킬을 사용했습니다. AI가 결정할 항목과 선택지를 정리하면 제가 하나씩 검토해 방향을 정했고, 이렇게 제작한 spec 문서를 검토하고 나서 실제 구현에 들어갔습니다.
• 운영 QA와 파이프라인 점검처럼 반복되는 절차는 직접 스킬로 만들어 배포 전마다 같은 기준으로 확인했습니다.
• 기능을 추가하고 수정하는 과정에서 내린 결정과 그 근거를 문서로 꾸준히 정리하여 에이전트가 지속적으로 맥락을 참고할 수 있도록 했습니다.

오디언스 빌더의 아키텍처

구조를 정할 때 가장 먼저 결정한 것은 각 데이터를 어디에 둘지였습니다. 오디언스에는 성격과 규모가 다른 정보가 함께 들어 있습니다. 이름, 필터, 갱신 주기처럼 ‘어떤 유저 집합인가’를 설명하는 메타데이터는 수백 행 규모지만, ‘그 집합에 실제로 누가 들어 있는가’를 나타내는 대상자 명단은 오디언스 버전 한 개당 수십만에서 수천만 행에 이릅니다. 그래서 메타데이터는 PostgreSQL에 두고, 실제 대상자 명단은 BigQuery에 두어 집합 연산과 대량 적재를 맡겼습니다.

마케터가 대상자 조건을 설정할 때 화면에 노출되는 필터들은 UB팀에서 구축해 둔 ‘유저 피처 스토어’를 기반으로 관리자가 미리 선언해 둔 카탈로그 항목들입니다. 각 유저 조건 필터가 테이블 칼럼 또는 그 칼럼들을 조합한 계산식과 일대일로 대응되도록 구현했습니다. 예를 들어 ‘회원 등급’ 필터는 단일 칼럼에, ‘최근 90일 구매 빈도’는 여러 칼럼을 연산한 식에 매핑됩니다. 동시에 필터의 데이터 타입(범주형, 날짜, 정수형 등)에 따라 UI의 입력 방식을 제어하도록 속성을 정의했습니다. 시스템은 추출 실행 직전에 이 카탈로그 메타데이터를 참조하여 런타임에 동적으로 SQL을 빌드합니다. 유저 피처 스토어에 새로운 특징이 추가되더라도, 카탈로그에 속성만 등록하면 즉시 마케팅 조건으로 활용할 수 있는 것입니다.

수천만 행을 스캔하는 추출 작업은 비동기로 처리됩니다. 요청이 인입되면 즉시 작업 번호만 리턴하고, 백그라운드의 백엔드 워커가 2초 주기로 완료 여부를 체크합니다. 연산이 끝난 대상자 명단은 즉각적인 활용을 위한 라이브 테이블과 버전별 이력 테이블에 동시 반영됩니다. 이러한 구조는 10분 주기의 예약 실행 스케줄러에도 동일하게 적용됩니다. 스케줄러는 갱신 대상만 백엔드에 전달할 뿐 실제 추출 워크플로우는 수동 실행과 완전히 동일한 비동기 로직을 탑니다. 결과적으로 대상자를 정의하는 핵심 비즈니스 로직을 단일 코드로 깔끔하게 유지할 수 있었습니다.

전송할 때는 마지막으로 내보낸 버전과 현재 버전을 비교해 전체 명단, 새로 들어온 유저, 빠진 유저를 각각 CSV 파일로 만듭니다. 이때, 마케팅 툴마다 명단을 갱신받는 방식이 달라서, 전달하는 파일이 달라집니다.

• 전체 명단을 교체하는 A에는 full 파일만 전달합니다.
• 추가·제거분을 반영하는 B에는 세 파일을 모두 전달합니다.
• A와 B는 CSV를 S3에 올리고 Kafka 메시지를 한 건 발행하면 담당 개발팀의 컨슈머가 실제 API를 호출합니다.
• 한편, C는 Kafka를 거치지 않고, C에 기록된 오디언스 상태를 확인해 최초 적재라면 MySQL에 전체 명단을 넣고 확정 API를 호출합니다. 최초가 아니라면 추가·제거 대상자 명단만 REST API로 보냅니다.

이후, 선택한 모든 마케팅 툴로의 전송 작업이 성공적으로 완료되었을 때만 증분 비교를 위한 기준 버전(Baseline)을 갱신하도록 설계했습니다. 만약 일부 툴로의 전송이 실패한 상태에서 베이스라인을 변경돼버리면, 아직 전달받지 못한 타겟 변경분이 다음 추출 대상에서도 제외되어 영구적으로 누락되기 때문입니다.

유저 프로파일링: 자동화 도구를 넘어 분석 도구로

처음 계획했었던 기본 기능을 모두 구현한 뒤에는, 오디언스 빌더를 단순한 자동화 도구에서 마케팅 분석 도구로 확장하는 것이 새로운 목표가 되었습니다. 가장 먼저 오디언스 관리 페이지, 필터 관리 페이지에 노출할 유저 프로파일을 만드는 작업을 시작했습니다.

빌더에는 휴면 고객, 가끔 접속하는 고객, 자주 접속하는 고객처럼 UB팀이나 마케팅실이 만든 유저군 필터가 있습니다. 마케터가 오디언스 빌더에서 생성하는 오디언스 자체도 하나의 유저군이라고 볼 수 있습니다. 이러한 유저군의 특징을 프로파일 형태로 제시주면 마케터가 ‘이 유저군은 이런 특징이 있으니 이 캠페인에 타겟해야겠다’는 판단을 내리는 데에 활용할 수 있을 것이라 생각했습니다. 그리고 프로파일이 쌓이면 저희 팀에서도 더 유용한 유저군을 찾고 유저 피처 스토어에 추가할 피처를 정하는 데 활용할 수 있을 것입니다.

문제는 어떤 지표를 넣을 것인가였습니다. 화면에 모든 지표를 담을 수는 없으니 후보를 좁힐 기준이 필요했습니다. 마케팅의 대표적인 성과 지표 중 하나인 전환율과 관련성이 큰 행동 지표가 유용할 것이라고 보고, 향후 전환 확률을 예측하는 모델을 만들어 모델이 예측에 많이 활용한 변수를 살펴보기로 했습니다. 고도로 정교한 예측 시스템을 만드는 것이 목적은 아니었기 때문에 복잡한 계절성 요인은 제외하고, 탐색용으로 정한 일주일 간의 데이터로 빠르게 모델을 학습시켰습니다.

지표들의 후보 풀은 사내 마케팅 성과 분석과 유저 특성 분석 기록에서 먼저 모았습니다. 외부 문헌을 조사해 업계에서 유저 행동을 분석할 때 일반적으로 사용하는 지표도 추가했더니, 약 200여 개의 후보 지표가 만들어졌습니다.

모델은 로지스틱 회귀와 LightGBM, 두 개를 만들었습니다.

공선성은 변수끼리 강하게 상관돼 사실상 같은 정보를 담는 관계를 뜻합니다. 로지스틱 회귀는 공선성이 있으면 계수가 불안정해지므로 관련 피처를 제거한 데이터로 학습했고, 트리 기반이라 공선성에 비교적 강한 LightGBM은 원본 피처를 그대로 사용했습니다. 서로 다른 방식으로 영향력을 평가하는 두 모델을 함께 보면 한쪽이 놓치는 신호를 다른 쪽이 보완해 줄 것이라고 기대했습니다.

두 모델에서 모두 중요도가 높게 나온 피처를 먼저 골랐고, 트리 모델의 순위는 낮지만 회귀 모델에서 방향이 뚜렷한 피처도 후보에 남겼습니다. 중요도가 연속적인 값이라 어디서 끊을지 기준선을 만들기가 애매했기 때문에, 높은 순으로 나열한 뒤 지표 수가 적당하고 지표의 종류가 충분히 다양해지는 지점에서 잘라냈습니다. 어디까지나 목표가 정확한 예측이 아니라 중요한 피처의 선정이었기 때문에, 이 정도의 러프한 기준으로 빠르게 진행한 것입니다.

그렇게 40개 정도의 지표를 선정해 종류별로 구분하고, 이를 직관적으로 보여줄 UI를 만들어 마케팅실에 공유했습니다.

• 지표를 방문, 탐색, 의도, 검토, 구매 같은 행동 단계별 그룹으로 묶어 배치했습니다.
• 세그먼트의 원값과 함께, 전체 유저 평균을 100으로 둔 지수 보기를 제공해 이 유저군이 평균 대비 어디가 얼마나 다른지를 바로 읽을 수 있게 했습니다.
• 관측 기간을 지표 성격에 따라 분리했습니다. 방문·탐색 같은 행동 지표는 최근 단기간의 평균으로, 구매 이력은 더 긴 기간 기준으로 집계해 성격이 다른 지표가 같은 잣대로 비교되지 않게 했습니다.
• 상단 요약에는 전체 대비 편차가 큰 지표를 추려 카드로 올려, 스크롤 없이 이 유저군의 특징을 파악할 수 있게 했습니다.

마치며

UB팀은 이 프로젝트에서 데이터와 개발뿐 아니라 여러 팀 사이의 소통을 조율하고 일정을 관리하는 PO 역할까지 맡았습니다. 그렇게 만든 오디언스 빌더는 지금 실제 캠페인 운영에 쓰이고 있습니다. 준비하는 데 2~3일이 걸리던 캠페인을 10분 안에 마칠 수 있게 됐고, 여러 담당자가 요청과 답을 주고받으며 진행하던 일을 마케터 한 사람이 처음부터 끝까지 준비할 수 있게 됐습니다.

앞으로는 프로파일을 제공하는 데서 나아가 캠페인 성과를 시스템 안에서 확인하고 분석할 수 있도록 기능을 확장하려고 합니다. A/B 테스트에 사용할 오디언스를 만들고 각 집단을 비교·관리하는 기능도 계획하고 있습니다. 유저 행동 데이터과 오디언스별 성과 데이터가 한곳에 모이면 마케팅 데이터를 더 체계적으로 관리할 수 있고, 유저 행동을 더 심도 있게 분석하는 데에도 다시 활용할 수 있을 것입니다.

AI 에이전트가 코드를 대신 써주는 시대에 비개발자가 개발을 맡는 일은 앞으로 더 흔해질 겁니다. 다만 그럴수록 무엇을 만들지에 대한 확신, 시스템이 실제로 어떻게 동작하는지에 대한 이해, 그리고 사용자가 어떻게 쓰는지에 대한 관찰은 인간이 쥐고 있어야 한다는 것이 이 프로젝트를 통해 얻은 가장 큰 깨달음이었습니다.

긴 글 읽어주셔서 감사합니다.