grep

MATCH Console & MAI

무신사

2026년 8월 21일

원문에서 보기 ↗

데이터 탐색부터 실행까지 연결하는 방법

1편: MATCH란 무엇인가 2편: MATCH Console & MAI

안녕하세요. 무신사에서 MATCH의 개인화 기능과 운영 콘솔의 프론트엔드 및 백엔드 개발을 담당하고 있는 Core-E Personalization 팀의 김의중, 김건희입니다.

1편에서 우리는 MATCH를 '유저 단위의 더 나은 결정을 시스템으로 옮기는 일'이라고 정의했습니다. 이번 글에서는 여기서 한 단계 더 들어가, 그 결정이 운영자의 실제 업무 안에서 어떤 모습으로 다뤄지는지를 이야기하려 합니다.

모델은 적합한 오디언스를 찾아내고, 서빙 인프라는 그 결정을 빠르게 전달합니다. 그런데 이 결정의 앞뒤에는 여전히 사람의 일이 남아 있습니다. 무엇을 기준으로 대상을 나눌지 정하고, 만들어진 대상을 검증하고, 어느 채널에서 활용할지 판단하는 것은 운영자의 몫입니다.

이 과정을 도구로 옮기는 일은 화면을 하나 더 만드는 것 이상의 고민이 필요합니다. 데이터를 다루는 도구는 정보를 정확하게 전달하면서도, 데이터를 전문으로 다루지 않는 사람이 쉽게 사용할 수 있어야 합니다. 정확하게 만들수록 복잡해지고, 쉽게 만들수록 판단에 필요한 맥락이 빠질 수 있습니다.

실제 운영 현장에서는 마케터가 속성 하나를 확인하기 위해 데이터 분석가에게 질문하고, 캠페인 한 건을 발송하기 위해 스프레드시트와 Braze, Databricks에 같은 값을 반복해서 입력하고 있었습니다. 데이터는 충분했지만, 이를 이해하고 실행 가능한 형태로 다루기까지는 여전히 많은 시간이 필요했습니다.

이번 글에서는 운영자가 MATCH와 만나는 접점인 MATCH Console과 AI Assistant MAI를 소개합니다. 데이터를 찾고, 오디언스를 정의하고, 실행 채널로 연결하는 흐름을 어떻게 하나의 시스템으로 만들었는지 이야기해 보겠습니다.

하나의 흐름으로 연결된 운영자의 업무

운영자가 MATCH의 결정을 실제 업무에 사용하려면 세 가지를 직접 다룰 수 있어야 했습니다. 사용할 데이터를 확인하고, 이를 조건으로 조합해 대상을 정의하고 검증한 뒤, CRM 캠페인이나 다른 서비스로 전달하는 일입니다.

MATCH Console의 정보 구조도 이 흐름을 따라 세 개의 공간으로 나뉩니다.

여기에 AI Assistant MAI가 세 공간을 오가는 과정에서 생기는 질문을 받아, 데이터 탐색부터 실행까지의 흐름을 이어줍니다.

MATCH Console을 설계하면서 일관되게 바라본 문제는 인지적 부하였습니다. 데이터는 그것을 전문적으로 다루지 않는 사람에게 낯설고 추상적입니다. MATCH Console은 데이터 탐색부터 대상 정의와 채널 활성화까지 하나의 흐름으로 연결해, 운영자가 본업인 '결정'에 집중하도록 돕는 도구입니다.

MATCH Console (1): 데이터 구조를 비즈니스 언어로 제공하는 Data Explorer

첫 번째 단계는 Data Explorer입니다. 운영자는 여기에서 사용할 수 있는 유저 속성과 행동 이벤트를 찾습니다. 데이터베이스에 저장된 이벤트명과 컬럼명만으로는 그 데이터가 실제로 무엇을 의미하는지 판단하기 어렵습니다. 예를 들어 click_button이라는 이름만으로는 어떤 버튼을 눌렀을 때 발생하는지, 어떤 조건으로 수집되는지, 캠페인 조건으로 사용해도 되는지 알 수 없습니다.

Data Explorer는 기술 명칭과 함께 운영자가 사용하는 표기 명칭, 설명, 발생 조건을 제공합니다. 또한 매일 실제 데이터 저장소의 컬럼 목록과 등록된 속성 스키마를 비교해 현재 수집 상태를 Active와 Inactive로 표시합니다. 운영자는 데이터의 의미뿐 아니라 "지금 믿고 사용해도 되는가"까지 같은 화면에서 확인할 수 있습니다.

중요한 점은 이 설명이 화면을 위한 도움말에 그치지 않는다는 것입니다. 이 비즈니스 메타데이터는 뒤에서 소개할 MAI가 질문과 데이터를 연결할 때도 동일하게 사용합니다. 사람과 AI가 서로 다른 사전을 읽지 않도록 한 것입니다.

MATCH Console (2): 문장을 완성하듯 정의하는 Audience

사용할 데이터를 찾았다면 Audience에서 대상을 정의합니다. 1편에서 오디언스를 '결정의 가장 핵심적인 단위'라고 소개했습니다. 기존에 이런 오디언스는 추출 자체가 분석가의 일이었습니다. 마케터가 "최근 한 달 동안 특정 브랜드 상품을 세 번 이상 본 유저"를 요청하면, 분석가가 조건을 쿼리로 옮겨 결과를 추출했습니다.

조건 빌더는 "The users who"라는 문장으로 시작합니다. 운영자는 문장을 완성하듯 어떤 행동을 했는지, 몇 번 했는지, 어느 기간에 발생했는지, 특정 파라미터가 어떤 값이었는지를 선택합니다. 여러 조건은 AND와 OR로 조합할 수 있습니다. 예를 들어 "최근 30일 동안 특정 브랜드 상품을 세 번 이상 조회했지만 아직 구매하지 않은 고객"이라는 조건을 SQL 없이 화면에서 정의할 수 있습니다. Data Explorer에서 확인한 명칭과 설명이 Audience에서도 그대로 이어지므로, 데이터를 찾을 때와 대상을 만들 때 서로 다른 표현을 다시 해석할 필요가 없습니다.

문법적으로 올바른 조건이 의도한 고객을 만든다는 보장은 없습니다. 그래서 현재 모수와 마지막 계산 시점뿐 아니라 실제 포함된 고객의 프로필도 확인할 수 있게 했습니다. 운영자는 조건을 저장하기 전에 예상하지 못한 고객이 포함되지는 않았는지 검증할 수 있습니다.

MATCH Console (3): 원하는 형태로 필요한 곳에 연결하는 Activation

정의한 오디언스는 Activation을 통해 CRM 캠페인이나 다른 서비스로 전달합니다. 정의한 오디언스는 Activation에서 두 가지 방식으로 활용됩니다. 차이는 MATCH가 최종 의사결정을 어디까지 담당하는가에 있습니다.

**CRM 캠페인에서는 MATCH가 오디언스를 바탕으로 최종 타겟을 결정하고 실행 채널로 전달하는 과정까지 담당합니다.**MATCH Console은 캠페인 설정과 전달 과정을 하나의 워크플로우로 연결해, 스프레드시트와 Braze, Databricks를 오가며 같은 정보를 반복해서 입력하던 일을 줄였습니다. 이 과정의 중심에는 Campaign Meta Engine이 있으며, 자세한 내용은 다음 글에서 다룹니다.

반면 Audience API는 최종 액션을 결정하지 않습니다. 서비스가 자체 정책과 실험에 따라 판단할 수 있도록, 해당 유저가 어떤 오디언스에 속하는지만 제공합니다. 예를 들어 출석 체크 서비스는 진입한 유저의 오디언스 정보를 MATCH에 요청하고, 응답받은 정보를 바탕으로 어떤 보상을 제공할지 직접 결정합니다. MATCH는 "이 유저가 누구인가"를 알려주고, 서비스는 "이 유저에게 무엇을 할 것인가"를 판단합니다.

즉, 오디언스는 MATCH에서 한 번 정의하지만 활용 방식은 다를 수 있습니다. MATCH가 타겟팅부터 실행까지 직접 결정할 수도 있고, 다른 서비스의 의사결정에 필요한 정보만 제공할 수도 있습니다.

MAI --- 흐름 전체를 연결하는 AI Assistant

Data Explorer에서 데이터를 찾고, Audience에서 대상을 정의하고, Activation으로 실행까지 연결해도 화면의 조건과 설정만으로 답하기 어려운 질문은 남습니다. 만들어진 오디언스가 어떤 고객으로 구성되어 있는지, 모델이 예측한 성향이 실제 행동과도 연결되는지 확인하려면 여러 데이터를 함께 살펴봐야 합니다.

MAI는 이 과정에서 발생하는 분석의 병목을 줄이기 위해 만든 AI Assistant입니다. 운영자는 SQL을 작성하지 않고 자연어로 질문할 수 있습니다. MAI는 질문과 관련된 테이블과 속성을 찾고, 쿼리를 생성해 실행한 뒤 결과를 요약합니다. 분석가에게 요청하고 기다리던 질문이 콘솔 안에서 1분 이내에 답으로 돌아오는 구조입니다.

무엇을 물어봐야 할지부터 안내하기

AI Assistant를 화면에 배치하는 것만으로 운영자가 바로 질문을 시작하는 것은 아닙니다. 빈 채팅창을 마주하면 무엇을 물어봐야 하는지, 어떤 방식으로 질문해야 하는지부터 고민하게 됩니다. 우리는 이 순간도 하나의 인지적 부하라고 봤습니다.

**MAI 화면에는 현재 업무에서 활용할 수 있는 추천 질문을 전면에 배치했습니다. 운영자는 추천 질문을 선택해 바로 분석을 시작하거나, 질문의 구조를 참고해 자신의 질문을 작성할 수 있습니다.**추천 질문은 코드에 하드코딩하지 않고 프롬프트 관리 시스템에서 버전별로 관리합니다. 애플리케이션을 새로 배포하지 않고도 운영 과정에서 질문을 수정하거나 추가할 수 있습니다.

질문 하나가 답이 되기까지

MAI는 ReAct(Reasoning + Acting) 방식의 에이전트 구조를 기반으로 동작합니다. 질문이 들어오면 에이전트는 필요한 정보를 추론하고(Reason), 도구를 선택해 실행합니다(Act). 실행 결과를 확인한 뒤(Observe), 추가 작업이 필요한지 판단합니다. 답변에 필요한 정보를 얻을 때까지 이 과정을 반복합니다.

여기서 Act는 곧바로 쿼리를 실행한다는 의미가 아닙니다. 에이전트가 사용할 수 있는 도구는 다음 네 가지입니다.

  1. 데이터베이스와 테이블 목록 조회
  2. 테이블 스키마 확인
  3. 샘플 데이터 확인
  4. SELECT 쿼리 실행

사람이 처음 보는 데이터를 분석할 때도 바로 쿼리부터 작성하지 않습니다. 어떤 테이블이 있는지 확인하고, 컬럼 구조와 샘플 값을 살펴본 뒤 질문에 맞는 데이터인지 판단합니다.

MAI도 같은 절차를 따릅니다. 질문과 관련된 테이블을 탐색하고 컬럼과 샘플 데이터를 확인한 뒤, 질문을 해결할 수 있다고 판단한 경우에만 SQL을 생성해 실행합니다. 이 과정은 콘솔 화면에 실시간으로 스트리밍됩니다. 운영자는 어떤 데이터를 확인하고 있는지 볼 수 있으며, 최종 답변과 함께 실제 실행된 쿼리도 확인할 수 있습니다.

질문 분류에서 데이터 자동 탐색 체계로의 전환

MAI의 첫 번째 버전은 지금과 같은 형태가 아니었습니다. 초기에는 질문의 의도를 분류한 뒤, 의도에 맞는 테이블과 SQL 템플릿을 선택하는 고정 파이프라인을 사용했습니다. 동작이 예측 가능하다는 장점은 있었지만, 시스템이 미리 정의한 질문에만 안정적으로 답할 수 있었습니다.

분류 체계에 없는 질문이 들어오면 적절한 템플릿을 찾기 어려웠고, 새로운 지표와 테이블이 추가될 때마다 의도 분류와 SQL 템플릿을 사람이 수정해야 했습니다. 결국 질문의 종류를 시스템이 미리 알고 있어야만 동작하는 구조였습니다.

우리가 원한 것은 질문 유형을 계속 추가하는 시스템이 아니었습니다. 에이전트가 현재의 데이터 구조를 직접 읽고, 질문에 필요한 정보를 스스로 찾는 시스템이었습니다. 그래서 질문을 미리 분류하는 방식에서 스키마와 샘플 데이터를 직접 탐색하는 ReAct 구조로 전환했습니다. 새로운 테이블이나 지표가 추가되더라도 에이전트가 데이터 구조를 읽을 수 있다면 기존 SQL 템플릿을 수정하지 않고 질문을 처리할 수 있습니다.

자유롭게 추론하되 좁은 범위에서 실행하기

에이전트가 직접 스키마를 탐색하고 SQL을 생성하면 자율성이 높아집니다. 그만큼 실행 범위를 통제하는 장치도 중요해집니다.

에이전트는 질문을 해결하는 방법을 자유롭게 판단할 수 있지만, 실제로 움직일 수 있는 범위는 시스템이 좁게 제한합니다. 자율성은 추론에 주고, 안전은 실행 계층에서 보장하는 구조입니다.

모델의 판단을 비즈니스 데이터로 선순환하기

MAI가 빠르고 안정적으로 답하기 위해서는 에이전트 구조만큼 데이터 구조가 중요합니다. MAI가 바라보는 ClickHouse는 원천 이벤트가 그대로 쌓인 공간이 아닙니다. 전사 데이터 마트 위에 분석을 위한 Semantic Layer가 구성되어 있으며, 테이블과 컬럼은 전사 규약에 따라 정의되고 각 데이터의 의미와 관계는 주석과 메타데이터로 관리됩니다.

이 공간에는 유저의 행동 데이터뿐 아니라 MATCH의 개인화 모델이 생성한 시그널도 함께 들어 있습니다.

모델이 생성하는 값은 대부분 점수(Score)이기 때문에 점수 자체만으로는 운영자가 의미를 이해하기 어렵습니다. 선호도 점수가 높다는 사실만으로 해당 유저들이 실제로 무엇을 구매하고 어떤 특성을 보이는지는 알 수 없습니다. **이를 해결하기 위해 점수 구간별 유저 특성을 미리 집계했습니다.**각 구간에 속한 유저 수와 성별·연령대 분포, 거래액, 주문 수 등을 함께 제공하여 모델의 점수를 운영자가 해석할 수 있는 정보로 바꿨습니다. 행동 데이터도 전체·카테고리·브랜드 단위로 일간, 주간, 월간 집계를 구성했습니다.

MAI는 매번 원천 이벤트 전체를 탐색하는 대신 이미 정리된 집계 데이터를 조회합니다. 이를 통해 '유저가 무엇을 했는가'와 '앞으로 무엇을 좋아할 가능성이 있는가'를 하나의 공간에서 함께 확인할 수 있습니다. 1편에서 소개한 모델의 판단이 운영 현장에서 즉시 활용 가능한 데이터로 선순환하는 구조입니다.

비즈니스 메타데이터도 에이전트의 지식이 된다

Semantic Layer가 기술적으로 잘 구성되어 있어도 테이블명과 컬럼명만으로 모든 의미를 전달하기는 어렵습니다. Data Explorer가 관리하는 비즈니스 메타데이터는 이 간극을 채웁니다. 이벤트가 어떤 행동을 의미하는지, 속성이 어떤 값을 가지는지, 운영자가 해당 데이터를 어떤 이름으로 부르는지를 함께 제공합니다. 에이전트는 기술 스키마뿐 아니라 업무에서 사용하는 언어를 바탕으로 질문과 데이터를 연결할 수 있습니다.

MAI가 빠르게 정확한 답을 제공할 수 있는 이유는 LLM의 성능만이 아닙니다. 모델이 읽는 데이터가 사람이 이해할 수 있는 구조와 언어로 정리되어 있기 때문입니다. 현재는 지표 정의와 업무 용어 사전까지 에이전트가 읽을 수 있는 지식으로 편입해, 같은 단어를 팀마다 다르게 이해하는 문제를 줄이는 방향으로 의미 계층을 확장하고 있습니다.

모든 대화는 운영을 위한 기록이 된다

MAI에서 발생한 모든 대화는 대화 기록 저장소에 남습니다. 질문과 최종 답변뿐 아니라 중간에 실행된 도구, 실제 SQL, 토큰 사용량, 운영자의 피드백까지 함께 저장합니다. 이 기록은 LLM Observability 레이어와 연결됩니다. 운영자가 남긴 좋아요·싫어요는 해당 대화의 품질 신호로 활용합니다. 문제가 발생하면 최종 답변만 보는 것이 아니라 에이전트가 어떤 테이블을 선택하고 어떤 쿼리를 실행했는지 전체 흐름을 확인합니다.

문제가 프롬프트에서 발생했다면 프롬프트 관리 시스템에서 수정할 수 있습니다. 시스템 프롬프트와 추천 질문을 버전별로 관리하기 때문에 애플리케이션을 새로 배포하지 않고도 개선 내용을 반영할 수 있습니다. 대화 기록, 품질 관측, 프롬프트 개선이 하나의 운영 루프 안에서 연결됩니다.

입구는 달라도 답을 만드는 엔진은 하나다

운영자는 모든 업무를 MATCH Console 안에서만 처리하지 않습니다. 슬랙에서 협업하고 정보를 확인하는 시간도 많습니다. 우리는 운영자가 익숙한 업무 공간에서도 MAI를 사용할 수 있도록 슬랙 봇을 만들었습니다.

슬랙 봇을 위해 별도의 에이전트를 만들지는 않았습니다. MATCH Console과 슬랙은 동일한 Agent API와 에이전트 스트림을 사용합니다. 콘솔에서는 답변과 진행 과정을 실시간으로 보여주고, 슬랙에서는 결과를 스레드 답글로 전달합니다. 표현 방식은 다르지만 데이터를 탐색하고 답을 만드는 엔진은 같습니다. 질문의 입구가 늘어나더라도 품질을 관리해야 할 지점은 하나로 유지됩니다.

AI Briefing: 반복되는 질문을 배치 파이프라인으로

그때그때 생기는 질문뿐 아니라 매일 같은 시각에 반복되는 질문도 있습니다. MAI를 운영하면서 발견한 사용 패턴입니다.

"어제 발송한 캠페인의 성과는 어땠을까?" "운영 중인 오디언스의 모수가 얼마나 변했을까?" "이번 주 주요 지표에 평소와 다른 변화가 있었을까?"

MAI는 답을 기다리는 시간을 없앴습니다. 하지만 매일 같은 질문을 한다면 남아 있는 비용은 대기가 아니라 질문을 떠올리고 입력하는 행위 자체입니다. AI Briefing은 그 행위까지 없앱니다.

운영자가 매일 MAI에 입력하던 질문을 배치 파이프라인으로 옮기고, 출근 전에 분석을 완료해 결과를 준비합니다. AI Briefing은 다음과 같은 핵심 변화를 미리 정리해 제공합니다.

같은 질문이라도 한 번 발생하면 대화지만, 매일 반복되면 배치로 다루는 편이 효율적입니다. 운영자가 정보를 찾기 위한 행동을 하기 전에 답이 먼저 준비되어 있는 구조를 만든 것입니다. 운영자는 데이터를 기다리는 대신, 이미 준비된 데이터를 바탕으로 무엇을 결정할지에 집중할 수 있습니다.

시스템이 스스로 좋아지는 루프

지금까지 대화 기록과 품질 관측 데이터를 주로 소비한 것은 사람이었습니다. 다음 단계는 이 기록을 시스템이 직접 읽고 개선 항목을 찾도록 만드는 것입니다. 대화 기록을 배치로 분석하면 다음과 같은 패턴을 발견할 수 있습니다. 운영자가 자주 묻지만 MAI가 안정적으로 답하지 못하는 질문은 무엇인지, 어떤 표현에서 질문의 의도를 잘못 이해하는지, 최근 새롭게 등장한 질문 패턴은 무엇인지 확인할 수 있습니다.

이 결과는 다시 시스템의 개선으로 이어집니다.

운영자가 MAI를 사용할수록 대화가 쌓이고, 대화에서 발견한 패턴이 다시 MAI의 품질을 높이는 순환입니다. 여기에 질문의 난이도와 성격에 따라 적합한 모델을 선택하는 모델 라우팅(Model Routing)도 더해지고 있습니다. 모든 질문에 같은 모델을 사용하는 대신, 필요한 품질과 응답 비용을 함께 고려해 적합한 모델을 선택하는 구조입니다.

결정이 실제 실행으로 이어지는 시간

Data Explorer, Audience, Activation, MAI는 서로 다른 기능처럼 보이지만 같은 철학 위에서 만들어졌습니다. 시스템이 운영자를 대체하는 것이 아니라, 탐색과 반복 입력, 도구 전환, 응답 대기처럼 결정이 아닌 일을 시스템이 흡수하는 것입니다. 운영자는 그만큼 판단과 실행에 집중할 수 있습니다.

좋은 개인화는 좋은 모델만으로 완성되지 않습니다. 모델이 내린 결정이 운영자가 이해할 수 있는 데이터로 표현되고, 실행 가능한 오디언스로 정의되며, 실제 채널과 서비스에 자연스럽게 연결되어야 합니다.

MATCH Console과 MAI가 하는 일은 데이터와 결정, 결정과 실행 사이에 남아 있던 시간을 줄이는 것입니다. 1편에서 이야기한 '사람과 시스템이 조화롭게 협업하는 방식'은 운영자가 매일 마주하는 이 화면에서 가장 구체적인 모습으로 드러납니다.

다음 이야기는 시스템이 유저를 이해하는 방식에 관한 것입니다. 콘솔의 Audience도, MAI가 활용하는 선호도와 이탈 위험도도 모두 시스템이 유저를 이해하고 있다는 전제 위에서 동작합니다. 3편에서는 무신사의 여러 개인화 모델이 함께 사용하는 유저 표현층인 통합임베딩을 어떻게 구축했는지, 그리고 그 공통 기반을 개인화 푸시에 처음 적용한 과정을 소개합니다.

TEAM MUSINSA CAREER

Personalization팀은 무신사, 29CM, 글로벌 등 팀 무신사의 다양한 서비스에서 개인화 경험을 책임지고 있습니다. 단순히 추천 모델을 개발·서빙하는 것을 넘어, 고객의 행동과 취향을 깊이 이해하여 제품, 콘텐츠, 캠페인 전반에 걸친 맞춤형 경험을 구현합니다. Personalization팀은 데이터엔지니어, 데이터사이언티스트, 머신러닝엔지니어, 백엔드엔지니어, 프론트엔지니어가 한 팀에서 end-to-end로 협업하는 조직입니다. 고객 행동 데이터 정의·수집·집계부터 페르소나 및 세그먼트 개발, 대규모 임베딩 기반 모델링, 실시간 타겟팅 API와 자동화된 캠페인 생성까지 전 과정을 직접 설계하고 운영합니다. 대규모 분산 시스템과 최첨단 머신러닝 기법을 활용하여 방대한 고객·상품·콘텐츠 신호를 통합적으로 해석하고, 이를 개인화 메시징, 배너 최적화, 유저 페르소나 추출 등 다양한 서비스 경험에 연결합니다. Personalization팀은 기술과 데이터를 바탕으로 고객의 쇼핑 여정을 한층 더 즐겁고 의미 있게 만드는 데 집중하고 있습니다. 🚀 Backend Engineer (Core Ads Platform) 🚀 Machine Learning Engineer (AdTech/MarTech)

MATCH Console & MAI was originally published in MUSINSA techblog --- 무신사 테크 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.