MZ 그로스 매니저의 택소노미 설계 꿀팁 대방출(1) (ft. 버거킹)

Intro. 택소노미는 어렵고 복잡하다.

‍

“택소노미요? 쭉 훑어봤는데 막 어렵지는 않더라고요. 빨리 끝내고 앰플리튜드 배우고 싶어요.”

‍

입사 1주일 차, 입사 동기에게 실제로 했던 말이다. 택소노미의 개념적 이해는 어렵지 않았다. 평소 Python 코딩을 해왔기에 익숙한 개념들이 많았기 때문이다. 이벤트는 Class, 프로퍼티는 매개변수와 유사했다. 예를 들어, 아래는 brand, model, year를 매개변수로 받아오는 Car 클래스를 정의한 코드다.

class Car:	# Car라는 클래스를 정의
	def __init__(self, brand: str, model: str, year: int):
    	self.brand = brand
        self.model = model
        self.year = year
        # Car 클래스에는 brand, model, year의 3가지 매개변수가 필요하다

‍

택소노미 스키마 역시 이와 매우 유사한 형태를 띤다. 하나의 이벤트를 정의할 때 여러 프로퍼티를 필요로 하고, 이는 데이터 분석의 기본 단위가 된다. "택소노미, 쉽네?"라고 생각했다.

그러나 그건 내가 택소노미의 표면만을 보았기 때문이었다. 실제로 설계를 시작하자 복잡한 이벤트 간의 관계, 속성 간의 상호 의존성, 퍼널의 다양성, 그리고 각기 다른 상황에서 어떤 이벤트를 발생시켜야 하는지에 대한 고민들이 쏟아져 나왔다. 택소노미는 단순한 데이터 구조 설계가 아니라 비즈니스 로직과 사용자 행동을 체계적으로 모델링하는 과정이었다.

사실, 버거킹은 마티니에서 이미 2023년에 한 차례 앰플리튜드 택소노미를 구축한 경험이 있었다. 하지만 이후 앱이 계속해서 리뉴얼되면서 기존 택소노미와 실제 어플 사용경험이 점점 맞지 않게 되었다. 그 결과, 2025년을 맞아 새롭게 택소노미를 리뉴얼할 필요가 생겼다. 버거킹 측에서는 원하는 이벤트 목록을 추가하여 약식의 택소노미를 제공해 주었고, 이를 바탕으로 2025년 버전의 이벤트 패스와 택소노미를 새롭게 설계해야 했다. 그러나 이 과정에서 가장 큰 난관이 있었다. 버거킹과의 직접적인 인터뷰가 불가능했다. 즉, 내가 가진 정보는 제한적이었고, 단순히 제공된 문서만으로는 버거킹의 데이터 분석 및 비즈니스 로직 니즈를 100% 이해하는 것이 어려운 상황이었다. 그 결과, 작은 결정 하나를 내릴 때마다 "이게 정말 맞는 방식일까?"라는 고민을 끊임없이 해야 했다.

그렇게 머리가 터질 것 같은 열흘간의 '버거킹 택소노미' 설계를 거치고, 팀장님을 붙들고 질문 폭격을 쏟아낸 끝에, 나는 택소노미 설계를 위한 몇 가지 실무적인 팁을 정리할 수 있었다. 나처럼 처음 택소노미를 구축하려는 사람들에게 작은 도움이 되길 바라며, 내가 직접 부딪히며 배운 교훈들을 재미있게 공유하려 한다.

‍

1. 이벤트 패스 및 택소노미 전반

우선적으로 해야 할 일은 이벤트 + 이벤트 프로퍼티를 고려한 이벤트 패스 및 이벤트 택소노미를 작성하는 것이다.

이벤트 패스는 고객사의 웹사이트나 앱을 직접 사용해보면서 분석에 유용한 정보를 담고 있을 이벤트를 찾아 마인드맵 형태로 작성하는 과정이다. 이는 고객이 경험하는 유저 여정을 체험하며 퍼널의 연결성을 파악하는 행위이며, 각 페이지에서 어떤 이벤트가 발생하고, 어떤 정보를 수집해야 할지를 개괄적으로 이해하는 데 도움을 준다.

‍

이벤트 택소노미는 이벤트 스키마 설계서와 동일한 의미를 갖는다. 즉, 이벤트를 어떤 기준으로 쌓아서 볼 것인지 정의하는 문서이다.

문제는 날이 갈수록 구매 퍼널이 다양해지고 유저 여정이 복잡해지는 등 앱의 절차가 점점 더 복잡하고 무거워지고 있다는 점이다. 그러나 이 모든 퍼널에 대하여 이벤트를 계속해서 추가할 수는 없다. 새로운 이벤트가 지나치게 많아지면 데이터 분석이 어려워지고, 이벤트 프로퍼티가 불필요하게 늘어나면서 데이터의 일관성이 깨질 수 있기 때문이다. 또한 이벤트 패스와 택소노미를 작성할 때 고려해야 할 부분이 너무 많다. 예를 들어

🤯ㅤ

어떤 화면의 어떤 이벤트를 기록할지
이벤트가 발생하는 트리거 조건은 무엇인지
함께 기록해야 하는 프로퍼티는 무엇인지
속성 간에 중복되거나 누락된 값이 있는지
데이터 타입은 무엇인지, Null 값을 허용하는지, 배열 값을 받을 것인지 등

이 모든 요소를 고려하면서 설계를 진행하다 보면, 무엇이 우선순위인지, 어디까지 초기에 디테일하게 구상해야 하는지 갈피를 잡기가 어려워진다. 그렇다면, 효율적인 택소노미 설계를 위해서는 어떻게 해야 할까?

‍

1.1. 전체 그림을 먼저 보기 (사실 힘들다)

처음 이벤트 패스를 작성할 때 나는 처음부터 완벽하게 정리하고 싶었다. 오류나 빈 곳을 발견하고 나중에 고치는 것이 더 피곤한 일이라고 생각했기 때문이다. 그래서 처음부터 모든 화면을 다 들어가 보고, 설정, 멤버십, 쿠폰, 프로모션 등 버거킹 앱 내의 모든 이벤트를 고려하려 했다.

하지만 이렇게 모든 요소를 한 번에 설계하려고 하면 일이 지나치게 복잡해지고 진행 속도가 늦어진다. 중요한 것은 우선 고객의 유저 경험에서 굵직한 이벤트만 먼저 파악하는 것이다.

🍔ㅤ 어플을 통해 버거를 사려고 한다고 가정해보자. 그럼 무엇을 해야 할까?
: 메인 홈 화면 접속 → 매장 선택 → 버거 선택 → 장바구니 담기 → 결제

‍

이 당연한 흐름을 먼저 기억했다면, 해당 전환이 일어나는 주요 화면을 중심으로 캡처하고 뼈대를 만들었을 것이다. 이후에 디테일을 보완하면 충분했다.

주요 이벤트 패스를 작성하는 것은 글을 쓸 때 개요를 먼저 정하는 것과 같다. 개요 없이 글을 쓰면 무조건 중구난방으로 튀게 되어있다. 이벤트 패스와 택소노미 역시 마찬가지다. 전체 그림을 볼 수 있어야 다른 곳으로 빠지지 않고 효율적인 설계를 할 수 있다. 만약 처음부터 세부 이벤트와 각 이벤트에서 수집하는 모든 프로퍼티를 고려한다면, 눈 앞에 거대한 나무에 가로막혀 전체 숲을 보지 못하고 길을 헤매게 될 것이다. 세부적인 이벤트에 매몰되지 말고 전체 흐름을 봐야 한다!

💡ㅤ 완벽한 설계를 처음부터 하려고 하면 오히려 비효율적이다. 초반에는 전체 그림을 우선적으로 그리는 것이 중요하다. 이후 디테일을 보완하면서 정리해나가는 것이 가장 효율적인 방식이었다.

‍

1.2. 퍼널 분리를 통한 이벤트 패스 간소화

사실 이 장은 1.1과 연결된 내용이다. 앞서 이야기했듯이, 이벤트 패스를 작성할 때 가장 먼저 해야 할 일은 메인 퍼널을 정의하고 그리는 것이다.

버거킹의 경우, 주문으로 이어지는 퍼널이 정말 많았다.

메인홈 하단 주문하기 버튼을 통한 주문
배너를 통한 전환
쿠폰을 통한 전환
과거 주문 히스토리 기반으로 한 전환
추천 시스템을 통한 전환

‍

각 퍼널별로 유입할 수 있는 경로도 다양했다. 예를 들어, 배너 클릭만 해도 5군데 이상에서 유입 가능했고, 무한 반복의 사이드 제품 추천시스템도 있었다. 이 모든 퍼널을 하나의 이벤트 패스 안에 그려 넣는다면? 패스가 지나치게 복잡해지고 직관성이 떨어질 것이다. 처음에 내가 작성한 1차 버전의 이벤트 패스는 정말 끔찍했다. 선들이 얽히고설켜 있고, 순환구조까지 포함되어 혼돈 그 자체였다. 그래서 내린 결론은 퍼널을 분리하고, 연결 지점만 정의하는 것이었다.

🍔 버거킹 프로젝트 - 메인퍼널과 서브퍼널의 분리

1. 우선 메인 퍼널을 정의한다: 홈화면 → 매장 선택 → 버거 선택 → 장바구니 → 결제

‍

2. 다른 구매 퍼널을 별도의 페이지에 따로 정의하고, 메인 퍼널로 합류하는 지점을 설정한다.

- 예시: banner_clicked → event_detail_viewed → 주문하기 버튼 클릭 시 메인퍼널로 합류

[배너 유입] 퍼널을 새로운 페이지에 작성 및 주문하기 버튼 클릭 시 메인퍼널과의 연결성을 시각화

‍

3. 반복해서 퍼널별로 개별 페이지를 제작하고, 메인 퍼널과의 연결성을 시각적으로 정리한다.

이렇게 구매 전환 퍼널들을 분리하니 복잡했던 경로도 훨씬 단순화되었다.

또한, 지나치게 세세하게 이벤트 패스를 만들 필요는 없다. 사이트 내 모든 페이지를 캡처할 필요는 없으며, 유의미한 이벤트가 발생하는 화면만 정리하는 것이 훨씬 효과적이다. 예를 들어, 버거킹의 제품 추천 시스템은 무한 루프(?)를 형성한다. 고객이 장바구니에 제품을 담으면, 사이드 제품을 팝업으로 추천하고 이를 장바구니에 담으면 또다시 사이드를 추천하는 형식이다.

‍

이러한 사이드 추천 페이지를 다 표현할 것인가? 언제까지, 몇 번째 추천까지 표현할 것인가. 반복되거나 무의미한 화면은 무시하는 것이 효율적인 이벤트 패스이다!

💡ㅤ 이벤트 패스의 본질은 퍼널을 직관적으로 시각화하는 것이다. 지나치게 복잡하면 아무도 보지 않는다. 중요한 이벤트를 누락하지 않되, 고객사가 이해할 수 있도록 간소화 및 정리하는 것이 이벤트 패스 작성의 필수덕목이다.

‍

1.3. 이벤트 패스와 택소노미 시트는 유기적 관계

앞서 내가 이벤트 패스가 글의 개요 역할을 한다고 했으니, “이벤트 패스를 먼저 완성하고 나서 택소노미 시트를 작성하면 되겠다”고 생각했을 것이다. 나 역시도 그렇게 생각하였고, 서둘러서 이벤트 패스를 완성하고자 했다. 그러나 얼마 가지않아 또다시 문제에 직면하게 되었다.

🤯ㅤ

"주요 이벤트"를 기준으로 이벤트 패스를 작성하는 것은 우선시 되어야 한다. 하지만...
이벤트 프로퍼티를 작성하는 과정부터는 누락 및 중복 방지, 프로퍼티의 상속 등 세부적으로 고려해야 할 요소가 많다.
또한, 후기 퍼널로 갈수록 프로퍼티의 양이 기하급수적으로 늘어나기 때문에 방대해지는 데이터가 정리가 되지 않아 혼란이 가중된다.

예를 들어, 버거킹의 Main 퍼널에서는 후기 이벤트가 앞선 이벤트의 거의 모든 프로퍼티를 상속한다. 즉, order_completed 이벤트 하나만 해도 40개가 넘는 프로퍼티를 포함해야 했다.

‍

“대체 어떤 프로퍼티들이 상속되고, 새로 추가되는거지?”

이 질문은 계속해서 반복되었고, 이벤트 패스만 보고는 도무지 답을 내릴 수 없었다. 특정 이벤트에서 어떤 프로퍼티를 유지하고, 어디서 새로운 프로퍼티를 추가해야 하는지 등이 정리되지 않으니 택소노미가 구체화되는 느낌을 받을 수가 없었다. 그래서 내린 결론은 이벤트 패스와 택소노미 시트를 병행하며 작업하는 것이었다.

‍

이벤트 패스를 작성하면 전체적인 사용자 플로우를 한눈에 볼 수 있지만, 개별 이벤트가 수집해야 하는 데이터까지 파악하기는 어렵다. 반면, 택소노미 시트를 작업하면 각 이벤트별 데이터 정의를 체계적으로 정리할 수 있지만, 전체적인 흐름 속에서 프로퍼티의 연결성을 파악하기 어렵다. 결국, 두 작업은 병행되어야만 했다.