[직군별 믹스패널 AI 에이전트 활용 전략] 기획자와 개발자- 기획자 개발자를 위한 믹스패널AI 3가지 (Context Engine·Verified Mode·Audit)

분석툴을 도입한 뒤, 기획자와 개발자의 슬랙에는 비슷한 질문들이 쏟아지게 됩니다.

하나씩 답하다 보면 하루가 가고, 이 일은 잘해도 티가 나지 않아요. 문제가 터졌을 때만 드러나니까요.

그런데 이 질문들은 정말 중요한 일이예요. 사실 기획자와 개발자가 하는 일은 내부 팀원들이 데이터를 믿고 쓸 수 있게 만드는 일이기 때문에.. 데이터가 깨끗하지 않으면 애초에 데이터 분석하는 의의가 흔들리게 되니까요.

이 글은 그 중요한 '개발자와 기획자의 리소스 투입을 최소화하여 데이터의 신뢰도와 일관성을 확보하는 믹스패널 AI 기능 3개'를 다룹니다. 다 읽으시면 우리 프로젝트의 데이터 관리가 조금 더 편해질거예요.

✅ 이 글을 다 읽고 나면 세 가지를 하실 수 있어요.

모두가 에이전트를 쓰기 시작하면, 대혼돈이 펼쳐질 수도 있다는 사실!

컨설팅 현장에서 가장 자주 보는 상황을 하나 말씀드려볼까요?

최근 30일 액티베이션 지표를 기획팀은 41%, 마케팅팀은 27%, 데이터팀은 63%로 보고해서 숫자가 다르다는 문의가 옵니다. 개발이 잘못된 것 같다고도 문의하시는 편이예요. 이유는 뭘까요? 세 팀에서 각기 정의하는 액티베이션의 정의가 달랐고 또는 각자 다른 이벤트를 썼기 때문에 숫자가 떨어진 거예요.

지금까지 이 불일치가 크게 터지지 않았습니다. 왜냐? 분석가가 중간에서 걸러줬기 때문입니다. 쿼리를 돌리고 내부 분석 기준(예: Activation)에 맞추어 데이터를 잡아주고 분석 시 꼭 들어가야 하는 필터나 조건을 확인해주었거든요.

문제1 - 모두가 AI분석을 하는 시대, 각기 AI가 생성한 다른 답을 가져와요

모두가 AI분석을 하는 시대가 펼쳐지면 혼란이 일어납니다. PM도 마케터도 임원도 에이전트에게 직접 질문해 분석하기 시작하면, 이 사람들은 암묵지로 있던 내부 분석 기준-세팅을 모르기 때문에 각기 다른 결과를 보고하게 됩니다. 결국 최악은 분석을 하는 사람 수만큼 다른 답변을 가져올 수도 있게 됩니다. 분석에 대한 멘탈 모델이 없는 사람도 분석을 하게 되니까 데이터가 안 맞는데요라는 질문도 같이 늘어나고요.

그래서 오늘은 모두가 AI를 활용해 분석가가 되는 시대에 기획자와 개발자가 어떻게 에이전트를 이용해 폭발하는 문의를 줄이고 데이터 신뢰도를 유지할 수 있는지를 주제로 잡았습니다. 툴 도입때마다 쏟아지는 문의가 곤란하셨던 분이라면 오늘 이 포스팅을 주목해주세요.

문제2 - AI가 틀린 답을 가져와요. 분석할때마다 값이 달라…

홈페이지 개편한 담당자가 몇 차례 바뀌면서, 일단 두고 나중에 정리.. 하고 했던 이벤트들이 결국 섞여 엉망이 되는 것을 흔히 보셨을거에요. view_product, PDP_viewed, pdp_view, 상품상세조회처럼 여러 벌 쌓여 있는 프로젝트요. 그리고 또 새로들어온 사람은 이벤트가 없다고 심어달라고 하는 상황까지….

하지만 이 때 사람은 어느 것이 정본인지 물어봐서 알아내곤 하죠. 문제는 AI는 물어볼 곳이 없기 때문에, 알려주지 않으면 분석 상황마다 매번 다른 것을 고릅니다.그래서 답이 각기 달라지고는 하죠.

문제3- 지금 데이터가 AI를 쓰기에 지저분한 건 알겠어요… 근데 정리할 엄두가 안나요..

데이터 정리를 한번 해야 AI 분석이 용이해진다는건 알겠는데 엄두가 안나실거예요. 무슨 기준으로 어디서부터 어떻게 정리해야할지… 각 부서의 입장도 다르고 부서별 쓰는 이벤트도 다르고 정말 두 이벤트가 같은건지 이름만 다른건지도 모르겠고, 이름도 좀 바꿔야 하는데..… 이런 상황 많이 경험하셨을거예요.

AI분석의 신뢰도와 일관성을 유지하는 믹스패널AI 기능 3가지

기획자와 개발자가 믹스패널 AI를 알아야 하는 이유는 기능 학습이 아니에요. 늘어날 질문에서 내 시간을 지키고, 정말 해야 하는 일을 하기 위한 수단입니다. 믹스패널은 이 문제를 3개의 기능으로 만들어 기획자와 개발자를 돕습니다. 하나씩 살펴볼게요.

Context Engine - AI에게 우리 회사 맥락을 가르치기

Context Engine부터 볼게요. 조직과 제품의 맥락을 미리 정의해서 AI가 우리 비즈니스 기준으로 답하게 만드는 기능입니다.

배달 앱에 다니는 사람과 반도체 회사에 다니는 사람은 수익을 내는 방법이 다르니까 매일 보는 지표도 KPI도 다를 텐데요. 배달앱 분석에 반도체 기준 분석을 제공하면 잘못된 결과가 나오겠죠? Context Engine은 이와 같이 우리 회사의 상황과 비즈니스 모델, 사업 부문, 지표 등을 적어두는 곳이에요.

한 번 적어두면 믹스패널 채팅 AI도, MCP도, KPI Agent도 RCA Agent도 Dashboard Agent도, MCP로 연결한 외부 도구까지 이 맥락을 먼저 읽고 분석을 시작합니다.

Context Engine은 조직 수준과 프로젝트 수준으로 나눠 적습니다

조직 수준에는 사업 레벨 정보를 적습니다.

프로젝트 수준에는 성과 지표 추적에 관한 정보를 적습니다.

웨비나에서 든 가상의 예시를 그대로 옮겨보면 이렇습니다.

MDU 같은 내부 약어의 기입이 왜 Context 기입이 필요한지 여기서 드러납니다. 풀어 써도 외부인은 뜻을 알 수 없거든요. 라이더 활동 시간을 적어두지 않으면 새벽 5시에 찍힌 데이터를 이상치로 잘못 잡을 수도 있고요.

Context Engine을 넣으면, 한 줄 차이로 답이 이렇게 달라집니다

지표의 정의를 명확히 하는 사례 1

어떤 이벤트를 액티베이션으로 봤는지 알 수 없고, 11월 1일의 하락이 정상인지도 판단할 수 없습니다.

지표의 정의를 명확히 하는 사례 2

저희 회사에서 지난 30일간 리드가 얼마나 발생했는지 물었더니 157건이라 답했습니다. 문제는 3가지 이벤트를 합산한 숫자였습니다. 저는 데모 신청만 리드로 보고 있었거든요.

이럴 때마다 다시 질문하고 기다리지 마세요. 대신 Context Engine에 submit_demo_request만 리드로 지정한다고 적어주세요. 그러면 앞으로는 처음부터 원하는 기준으로 답이 옵니다.

Context Engine 작성법 - 토글을 켜고 마크다운으로 적으면 끝!

Settings에서 Organization 또는 Project로 들어가 토글을 켜고 마크다운 포맷으로 기입합니다. 프로젝트 Owner와 Admin이 편집할 수 있고, 프로젝트 접근 권한이 있는 사람은 누구나 읽을 수 있어요.

빈 화면 앞에서 막막하시다면 Generative AI 기능으로 초안을 생성한 뒤 고쳐도 됩니다. MCP로 연결한 AI에게 프로젝트를 검토하게 하고 지표 정의가 불분명한 단어를 확인해 달라고 요청하는 방법도 유용해요.

길게 쓸수록 좋아지는 게 아닙니다

최대 5만 자, 한국어 기준 A4 30~40페이지까지 넣을 수 있지만 실제로는 A4 2페이지 안팎을 권합니다. 분석 요청마다 이 맥락을 읽고 시작하기 때문에 길수록 응답이 느려지고 토큰 비용도 올라가거든요. 짧게 시작해서 계속 늘려가는 편이 낫습니다.

무엇부터 적을지는 기준이 하나 있어요. AI가 유추할 수 없는 것부터 적으시면 됩니다. 회사 이름이나 업계는 AI가 웹에서 찾아내지만 우리가 액티베이션을 뭐라고 부르는지는 알아낼 방법이 없기 때문에, 핵심 이벤트의 정의와 사내 용어부터 채우고 표준 대시보드와 프로퍼티 사용례(단위·형식·허용값)를 그다음에 붙이시면 됩니다.

이 3가지는 미리 확인하고 작성을 시작하세요

여기까지 하면 AI가 우리 회사의 맥락 맞춤 답변을 하기 시작합니다.

Verified Mode - AI가 볼 데이터를 직접 골라주면 답이 흔들리지 않아요

제가 현장에서 보니 맥락을 알아도 이벤트가 엉망이면 다시 답이 엉망-제각각이 됩니다.

이 때 사용하실 수 있는게 Verified Mode예요. Verified Mode는 AI가 분석 시, 담당자가 인증한 특정 이벤트만 사용하게 하는 기능입니다. Verified로 설정하면 해당 이벤트와 커스텀 이벤트, 코호트만 AI가 분석에 사용하고, Unverified 데이터는 프로젝트에 그대로 남지만 AI 분석에서는 제외돼요. MCP도 물론 적용됩니다.

앞에서 본 이런 동일 데이터가 쌓여있다면 view_product, PDP_viewed, pdp_view, 상품상세조회가 있다면 이중 하나 (예: view_product)를 인증처리하시면 되세요. 그러면 AI가 분석 시, 이런 이벤트와 코호트가 1,000개 있어도 중요한 Verified된 데이터 50개만 읽게 만들 수 있어요.

이런 조직에는 Verified Mode가 필요합니다

Verified Mode는 Lexicon에서 5개 항목에 적용할 수 있어요

해당 항목을 열고 우측에서 Verified 처리하면 됩니다.

이 3가지는 꼭 미리 확인하세요!

Verified Mode를 켜면 AI가 답할 수 있는 범위가 줄어듭니다. 검증 작업이 부족한 상태에서 켜면 관련 데이터가 더 있지만 검증되지 않아 제외했습니다라는 응답이 돌아와요. 그래서 아래 세 조건을 먼저 보셔야 합니다.

세 조건 중 하나라도 부족하다면, AI가 Verified 데이터와 사용량 높은 데이터를 우선 참조하되 거기에만 제한되지는 않는 기본 상태가 더 나을 수 있어요.

Audit - 승인하기 전에, 재료가 쓸 만한지부터 확인하세요

여기서 순서 문제가 하나 생깁니다. Verified 처리를 하려면 무엇을 승인할지 알아야 하는데, 이벤트가 400개 쌓여 있으면 어디서부터 봐야 할지 정하는 데만 몇 주가 가거든요.

더 곤란한 건 모르는 채로 승인했을 때예요. 중복된 이벤트 중에 틀린 쪽을 정본으로 고정하면 AI는 앞으로 계속 그것만 씁니다. 개인정보가 담긴 프로퍼티를 승인하면 MCP를 타고 외부 AI 도구로 그대로 나가고요. Verified Mode는 AI에게 이것만 보라고 알려주는 기능이기 때문에, 잘못 승인하면 틀린 답이 오히려 더 반복됩니다.

이 진단을 위해 Audit을 사용하실 수 있습니다. 코드와 설정, 스키마를 훑어서 수정 목록을 만들어줘요. Audit은 Implementation Skill의 4가지 모드 중 하나인데요. 실행 방법과 나머지 모드는 4편에서 다루겠습니다.

Audit은 AI가 데이터를 잘못 읽게 만드는 네 가지를 봅니다.

실제로 돌려보면 이 네 가지 말고도 수집 동의 처리까지 함께 잡아줍니다. 단, Audit이 보는 건 코드와 설정, 스키마까지예요. 실제로 쌓인 데이터 값이 맞는지 정량적으로 검수하는 것은 별도 작업입니다. 무엇이 어떤 형태로 나오는지는 4편에서 실측 결과와 함께 보여드릴게요.

기획자와 개발자를 위한 믹스패널 AI 적용 순서 Context, Audit, Verified

세 기능을 이제 다 확인하셨다면, 이 순서로 시작하세요.

순서가 이렇게 정해지는 이유가 있습니다. 맥락이 없으면 무엇이 중요한 이벤트인지 판단할 기준이 없고, 진단을 건너뛰면 지저분한 이벤트를 그대로 승인하게 되거든요.

이 상태가 되면 사용자는 질문만 하면 됩니다. 맥락이 마련되어 있고 참조할 데이터 범위도 정해져 있으니까요. 여러 번 질문해도 일관된 답이 나오고, 팀원들이 AI를 자유롭게 써도 기획자와 개발자가 뒷수습을 걱정하지 않아도 되고요. 기억하실 점은 Lexicon 정리를 프로젝트로 접근하면 전수 조사부터 하게 됩니다. 되는 것부터 주요 이벤트부터 천천히 시작하세요

4편에서 이어집니다

다음 편은 개발자 트랙입니다. 이벤트 설계가 코드가 되기까지 에이전트가 어디까지 하는지, Implementation Skill의 네 가지 모드와 Audit 실측 결과를 다룹니다.

우리 프로젝트 데이터, 지금 상태가 궁금하다면

문의: solutions@mfitlab.com, nicky@mfitlab.com