[직군별 믹스패널 AI 에이전트 활용 전략] 기획자, 개발자 편 - 코딩 에이전트에 이벤트 트래킹을 맡기면 어디까지 하나요(Agent+Implementation Skill)

분석가에게 분석의 어려움과 고통이 있다면, 개발자와 기획자는 툴 도입 후 또 다른 종류의 고통을 받습니다.

그런데 이 일은 고통스러운 만큼 중요합니다. 팀이 데이터를 믿고 쓸 수 있느냐가 여기서 정해지니까요. 어차피 꼭 해야 하는 일이라면 부담을 덜 방법을 찾는 편이 낫겠죠. 그래서 개발자와 기획자의 고통을 덜어줄 기능을 소개하려고 이 글을 준비했습니다

이 글은 믹스패널이 배포한 Implementation Skill로 계측 코드 작성과 결함 진단을 코딩 에이전트에게 시키는 법을 다룹니다. 콘솔에서 프롬프트를 복사해 붙여넣는 것으로 시작해서, 첫 이벤트를 심고 검증하는 데까지 한 세션이면 끝난답니다.(Quick Start 기준)

이 글을 다 읽고 나면 네 가지 모드가 언제 쓰이는지 알고, 에이전트가 추천한 모드가 내 상황에 맞는지 판단하실 수 있어요.

그리고 코드베이스에 접근할 수 없어도 멈추지 않습니다. Quick Start와 Full Implementation은 개발자에게 넘길 구현 스펙 문서를 대신 만들어 줘요.

계측 앞에서 개발자와 기획자가 겪는 세 가지

문제1 - 제품 정의는 남이 하는데, 구현은 개발자가 합니다

기능 로직은 30줄인데 애널리틱스를 붙이고 나면 PR의 절반이 트래킹 코드가 됩니다. 분량은 제일 많은데 리뷰에서는 아무도 안 보고요. 더 곤란한 건 코드로 풀리지 않는 질문들이에요. Order Completed의 completed가 프론트 콜백인지 결제 승인인지는 제품 정의의 문제인데 물어봐도 확답이 안 오니까, 결국 개발자가 임의로 정하고 넘어가게 됩니다. 나중에 숫자가 이상하면 그 결정이 문제가 되고요.

문제2 - 맞게 심겼는지는 배포 후에야 안다

개발자는 한 번 눌렀는데 이벤트가 세 번 찍히는 것도, identify() 뒤에 로그아웃과 계정 전환, 웹뷰를 거치며 사용자 프로필이 쪼개지는 것도 데이터가 쌓여야 압니다. 기획자는 내가 설계한 이벤트가 코드에 의도대로 들어갔는지를 사전에 알 방법이 아예 없고요. 그래서 문제가 며칠 뒤에 드러나는데, 그때는 이미 다른 스프린트라 컨텍스트를 다시 불러오는 비용이 처음 심을 때보다 훨씬 큽니다.

문제3 - 코드는 고쳤는데 데이터가 맞는지는 또 모른다

수정 목록을 받아 코드를 고쳤다고 끝이 아니에요. 정의한 프로퍼티에 값이 제대로 들어오는지, 일부만 들어오는지, 데이터 타입이 맞는지는 코드를 봐서는 알 수 없고 실제로 쌓인 값을 봐야 압니다. 그런데 이 검산(QA)을 누가 언제 하는지가 정해져 있는 팀은 드물어요.

코드 작성부터 진단까지, 계측을 맡기는 3가지 방법

세 문제의 뿌리는 같습니다. 정의와 구현 사이가 비어 있고, 그 틈이 배포 후에야 드러난다는 것이죠. 앞의 둘은 Implementation Skill이 구현 모드와 Audit 모드로 해결할 수 있습니다. Implementation Skill도 구현한 뒤에 Live View에서 이벤트가 실제로 들어오는지 확인해요. 다만 기준값 대비 수집률이나 프로퍼티 충족률, 경로별 누락처럼 모집단 수준에서 정량 비교하고 수정 후 다시 재보는 루프는 별도 영역이라, 마켓핏랩이 자체 스킬로 운영하고 있습니다.

하나씩 살펴볼게요.

Implementation Skill은 믹스패널 콘솔이 아닌 여러분의 코딩 에이전트에서 실행됩니다

먼저 헷갈리는 지점 하나를 짚고 시작할게요. Implementation Skill은 믹스패널 콘솔에서 실행되는 제품 내장 기능이 아닙니다.

믹스패널이 배포하는 것은 계측 절차서이고 실행은 여러분이 쓰는 Claude Code, Codex, Cursor, Copilot 같은 코딩 에이전트가 합니다. 믹스패널은 스킬이 코딩 에이전트 안에서만 돌고 코드가 사용자 환경을 벗어나지 않는다고 안내합니다. 프로젝트 토큰도 프로젝트에 설치되는 믹스패널 SDK만 사용해요.

설치는 프롬프트를 붙여넣기로 끝!

Implementation에는 4가지 모드가 있고, 에이전트가 제안하되 결정은 사용자가 합니다

앞의 세 개가 구현 모드, 마지막이 진단 모드입니다.

스킬은 코드베이스에 접근할 수 있으면 먼저 조용히 스캔한 뒤, 네 가지 중 어느 모드로 갈지를 묻습니다. 진행하다가 identity 복잡도나 consent 이슈, CDP 사용처럼 판단이 바뀔 만한 게 나오면 다른 모드로 옮기자고 제안하고요. 결정은 사용자가 합니다.

Quick Start와 Add Tracking, Full Implementation 동작 원리

구현 모드 3가지는 읽기, 스펙 확인, 구현, 검증, 기록이라는 흐름을 공유합니다. 구현 모드에 따라서 달라지는 부분은 읽는 범위와 승인 강도, 구현 범위입니다.

이 글에서는 Quick Start 모드로 이 동작을 보여드리도록 할게요.

‍

코드 작성 전에 에이전트가 정리하고 사람이 확인하는 4가지

이 부분이 실무적으로 가장 의미 있는 부분이라고 생각해요. 개발자와 기획자가 구현 직전에 맞춰보려다 확답이 안 와서 넘어가고, 결국 배포 후 데이터로 드러나던 것들이 있잖아요. 그 네 가지를 코드 작성 전에 확정하고 들어갑니다.

통제방식은 크게 둘로 나뉩니다. 1)에이전트는 코드에서 답을 찾고 스킬 규칙을 적용하며, 2) 제품 의미와 정책 판단은 사람이 확인합니다.

아래 네 가지가 통제 대상이예요.

결과적으로 개발자가 할 일은 스펙 문서를 검토해 코드에 적용하고 테스트 환경과 Live View에서 결과를 확인하는 것까지입니다.

참고로 Add Tracking은 기존 믹스패널 계측과 코드 접근을 전제로 만들어진 모드입니다. 코드 미접근 경로는 현행 skill.md 기준으로 정의돼 있지 않습니다.

결함을 검출하는 Audit 모드

Audit의 기능 소개는 3편에서 다뤘습니다. 여기서는 실제로 돌려본 결과를 봅니다.

Audit이 만드는 것은 우선순위가 붙은 수정 목록입니다. 개별 이벤트 수정은 Add Tracking, 구조를 손봐야 하면 Full Implementation 경로로 이어집니다. 저희 실측에서는 이 전환까지 한 세션 안에서 연속으로 진행됐고, 이슈와 위치, 항목별 수정 방안이 파일과 라인 단위로 나왔습니다.

그런데, 코드는 고쳐졌는데, 데이터도 고쳐졌을까요?

Audit 진단서를 받은 기획자가 던지는 질문이 하나 있습니다.

고칠 곳은 진단서로 알았어요. 그런데 고친 다음 실제로 쌓이는 데이터가 맞는 데이터인지는 누가 확인해 주나요?

Audit은 구현 상태를 진단합니다. 코드와 identity 배치, 트래킹 플랜과의 차이를 봐요. 다만 트래킹 플랜상 이 프로퍼티가 대상 이벤트의 100%에 있어야 하는데 실제로는 몇 퍼센트인지, 특정 경로에서만 빠지는지처럼 기대값과 관측값을 모집단 수준에서 비교하는 것은 다른 층입니다. 문서와 코드와 관측 데이터, 이 세 정본이 서로 맞는지는 별도 작업이에요.

마켓핏랩이 자체 개발한 QA Skill이 이 층을 담당합니다. 두 스킬은 대체 관계가 아니라 직렬 관계예요.

운영 루프로 보면 이렇습니다.

정의한 프로퍼티에 값이 제대로 들어오고 있는지, 일부만 들어오고 있는지, 데이터 타입이 맞는지는 코드를 봐서는 알 수 없습니다. 실제로 쌓인 값을 봐야 알 수 있어요. 국내 고객사에서 계측을 새로 깐 뒤 첫 QA를 돌리면, 특정 프로퍼티가 절반만 채워져 들어오는 경우를 자주 만납니다. 웹뷰 경로나 서버 사이드 전송 경로에서만 누락되는 식이에요.

에이전트가 스킬을 활용해 심고, 마켓핏랩은 검산하고 수렴까지 운영합니다.

기획자와 개발자가 자주 묻는 질문

이벤트 설치 속도가 빨라질수록, 검증 리소스 체계가 필요합니다

구현 속도가 병목이 아니게 되면 병목이 검증으로 옮겨갑니다.

지금까지 이벤트 추가가 느렸던 이유 중 큰 부분은 개발 리소스였어요. 구현 비용이 낮아지면 이벤트를 추가하는 속도와 빈도도 올라갑니다. 그런데 3편에서 다룬 Verified Mode 체크리스트를 떠올려 보세요. 이벤트 검증이 배포 속도를 따라갈 수 있는가라는 조건이 첫 번째였습니다.

구현이 빨라진 만큼 검증도 자동화되어야 하겠죠. 진단은 특정 시점의 상태를 보는 것이고, 데이터 품질을 유지하려면 검산은 반복 루프로 설계해야 하니까요. 수정하고, 재실행하고, 차이가 줄었는지 확인하고, 남은 항목을 리뷰 큐에 넣는 과정이 계속 돌아야 데이터가 신뢰할 만한 상태로 유지됩니다.

5편에서 이어집니다

마지막 편은 Headless입니다. 믹스패널 기능 전체를 파이썬 객체로 노출하는 오픈소스 SDK가 나왔어요. 분석을 코드로 재현하고 반복 실행으로 연결하는 방식이라, MCP와는 쓰임이 다릅니다. 저희가 실제로 자사 프로젝트에 적용해본 결과와 함께 정리했습니다.

지금 바로 해볼 수 있는 것

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