이벤트 트래킹은 데이터 기반 의사결정을 위해 필수적인 장치입니다. 우리의 설계 내에서 유저가 어떤 액션을 하거나 노출되었을 때 특정 이벤트가 발생했다고 생각하고 서버에 기록합니다.
그럼 이벤트의 트리거일 때 전송하면 되는거 아닌가?
이게 일반적인 생각이고, 제가 처음 합류했을 시기에도 그렇게 작성되어 있었으며 별 문제가 없었습니다. 허나 시간이 지나니까 문제가 되더라구요. 수집하고 싶은 데이터가 많아지고 하고싶은 실험의 수가 많아지고 컴포넌트끼리 겹치다보니 클릭 한 번, 페이지 진입 한번에 수십개의 API가 호출되고 있었고, 이벤트 처리 서버가 툭하면 죽었습니다.
제가 이벤트 대량 전송 문제를 해결하기 위해 고민했던 내용에 대해 함께 알아봅시다.
기술적 정복자에 대한 아티클을 본 적 있습니다. 당신이 아무리 뛰어난 기술을 가진 엔지니어라고 한들, 이를 다른 조직에 적용하는 과정에서 그 집단 구성원에 대한 존중이 없다면 한낱 정복자에 지나지 않다고.
이 글이 충격적이었던 사실은, 제가 현재 조직에 처음 와서 여러 기술과 방법론을 도입했을 때의 상황과 비슷했다는 점 때문이었습니다. 당시 옛날 기술로 도배가 되어 있어 고통받던 동료 개발자들을 위해 개발자 경험을 올릴 수 있도록 기여해야겠다는 생각에 야근까지 자처하면서 다양한 신문물을 들여와서 적용시켰습니다.
그 결과 우리 팀 기술 스택은 꽤 많이 바뀌었고, 개발이나 관리에 있어 효율을 얻을 수 있었죠. 하지만 그 과정이 순탄치는 않았습니다. 기술 자체를 이해하지 못하는 사람도 있었고, 딱히 니즈가 없으신 분들도 있었어요. 오히려 과거의 기술들이 장점을 가진 경우도 있었죠. 어쩌면 저는 앞뒤사정을 확인하지 않고 무자비하게 회사 기술을 갈아엎었던 정복자라고 볼 수 있는 거에요.
비교적 최근에, 지금 다니는 회사의 CTO님이 꽤나 근본적인 질문을 주셨었습니다.
물론 다른 회사에서도 물어보는 단골 질문이기 때문에 실제 면접관으로 참여하며 들었을 땐 내가 대답하는 게 아니니 그러려니 하고 깊게 생각하진 않았었는데 이 질문을 답하려고 하니 말문이 막혔어요. 답변을 작성하기 위해 무려 퇴근하고 컴퓨터에 앉아서 고민할 만큼.
이 질문이 우리에게 어떤 울림을 주는 목적이거나 잘못에 대한 우회 징계와 같은 성격을 띠진 않았고, 개발자 채용을 위한 우리들의 인재상을 종합한다는 명확한 이유가 있었기 때문에 같이 일하기 좋고 말이 잘 통하는 동료 정도로 적어서 제출했던 기억이 납니다.