1. 출발점: 왜 문서화를 선택했는가?#

이 프로젝트의 초기 동기는 과거 전사 대상으로 기술 발표를 함에 있어 피드백을 받았던 문장에서 부터 시작된다.

“시퀀스? SDK? 패키지? 그게 무슨 뜻이에요? 좀 쉽게 설명해주세요”

기술 문서는 종종 개발자를 위한 문장으로만 작성되기 쉬운데, 나는 그것을 양측을 잇는 다리로 만들고 싶었다. 하지만 일단 읽는 독자 타게팅을 해야 하다보니… 처음엔 ‘개발자용 문서’와 ‘비개발자용 문서’를 각각 따로 써야겠다고 생각했다.

하지만 학습이 깊어질수록, 그리고 이벤트 설계라는 주제가 생각보다 낯선 영역임을 인지하게 되며 방향을 바꾸게 된다.

2. 행동 분석 툴로 확장된 문제의식#

최근 커피챗을 통해 다음과 같은 이야기를 들었다

“C1~C4를 진행하며 유저의 피드백을 토대로 개선할 수 없었던 것이 가장 큰 아쉬움”

이 말은 테크로서 지원해줄 수 있는 방법은 무엇일까 고민하게 되었고, 디자이너가 직감적으로 “이 버튼은 안 눌릴 것 같다”고 판단할 지언정, 그것이 실제 유저의 행동 데이터로 입증되지 않으면 디자이너 스스로도 확신을 갖기 어렵다. 이 문제를 해결하기 위해선 반드시 계측 가능한 행동 로그가 필요하다. 라는 뇌피셜을 거쳐 GA4와 자체 서버 로그 API 시스템에 대해서 생각하게 되기 시작했고, 자체 서버 API는 너무나 방대한 영역이니 자체 기각 후 GA4와 유사한 Amplitude에 대해서 공부하게 된다.

3. 전환점: 단순 가이드를 넘어…?#

문서의 독자를 명확히 하고자 했다. 처음의 생각은 비개발자가 굳이 프로젝트에 패키지 설치하는 방법을 알아야만 할까? 정도에만 그치며 아래와 같이 문서화 산출물을 두 갈래로 나누고자 했다.

• ✅ 개발자를 위한 문서는 패키지 설치, 이벤트 트래킹 API 사용법 등을 포함한다.
• ✅ 비개발자를 위한 문서는 각 툴간의 장단점, 제약사항, 가격 등을 비교하고 툴 선택에 있어 의사결정을 돕는다.

초기에는 단순한 툴 세팅 가이드를 문서화했다. Swift 학습에 게을러 아직도 Flutter가 익숙한 나는 Flutter 환경에서 GA4, Amplitude를 세팅하는 방법 안내서를 작성했고, 멘토에게 다음과 같은 피드백을 받았다.

“문서의 난이도가 너무 낮다. 학습이 되지 않을 것”

이 피드백은 명백히 옳았고, 빠르게 납득했다. 허나, 아 그럼 뭐하지? 하는 생각이 덮쳤고 어떻게 이벤트를 설계할지, 툴이 여러개 있을 때의 처리, 어떤 파일에서 어떻게 관리할지, 트랙킹할 이벤트가 늘어나면서 관리 포인트들 등의 아이디어를 주었다

피드백에서 새롭게 얻은 학습 키워드는 이벤트 텍소노미 였는데, 이 단어를 처음 들었을 때의 나의 인상은

‘이벤트 텍소노미..? 그게 뭐임?’

였다. 이 의문은 내 머리채를 잡고 나를 책상에 데려다 앉혔다. 아래 부터는, 내가 새로운 배움과 그로 인한 잘못된 믿음이 깨지는 과정, 내가 알던 지식과의 병합된 산물들… 이라고 볼 수 있을 것이다.

4. 그래서 최종 Deliverable#

이러한 문제의식과 학습, 그리고 개인적인 경험을 바탕으로 문서를 작성했다.

개발자라면 놓치지 말아야 할 이벤트 설계의 포인트들

5. 나는 지금 어디쯤 와 있는가#

6. 결론: 해석 가능한 로그를 설계한다는 것#

이벤트 설계는 한 번의 학습으로 끝나는 주제가 아니라는 것을 공부할수록 느낀다. 도메인별, 기능별, 서비스 특성별로 완전히 다른 기준이 되어버리기 때문이다.

하지만 수확이 있다면,

• 이벤트는 수집이 아니라 해석을 위한 구조 설계다
• 데이터의 노이즈를 줄이기 위해, 심는 것보다 버리는 것이 더 중요할 수 있다

그리고 이 글을 끝맺으며, 아직 내가 인지 하지도 못한 다음 미신을 찾아내보기로 한다.