유저 행동 이벤트 추적하기

• 데이터를 기반으로 하는 의사결정의 중요성
  ・ 유저 행동 이벤트란 무엇인가요?
  ┗ 유저 행동 이벤트가 아닌 것들

• 유저 행동 이벤트를 찍을 때 개발자들이 느끼는 고통
  1. 이벤트 로깅 코드는 기능 완성 여부와 관련이 없다
  2. B2B SaaS의 의사결정은 정성적 데이터가 차지하는 비중이 높다
  3. 이벤트 로깅을 위해 설계를 바꿔야하는 경우가 생긴다

• 이벤트 로깅에 대한 개발자의 심리적 허들 제거해주기

  
  

데이터를 기반으로 하는 의사결정의 중요성

어플리케이션을 개발한다는 것은 수 많은 의사결정의 연속이라고 볼 수 있습니다. 이러한 의사결정을 내릴 때 우리가 손에 쥐고 있는 정량적/정성적 데이터의 유무는 조직의 의사결정의 퀄리티에 막대한 영향을 주게 됩니다.

쿼타랩은 단순한 뇌피셜로 제품을 개발하는 것이 아닌 실제로 우리의 유저가 어떤 식으로 행동했는지, 어디서 이탈했는지, 그 이유는 무엇인지 데이터를 기반으로 추론하고 의사결정하는 것을 추구하기 때문에 어플리케이션 내에서 유저의 행동을 추적하는 이벤트 로그의 역할이 굉장히 중요합니다.

물론 정량적 데이터는 현재의 상황만을 투영하여 보여주는 숫자일 뿐이라 현상이 발생한 원인 자체를 설명해주지는 않기 때문에 정량적 데이터를 너무 맹신하는 것이 위험하기는 하지만, 우리의 의사결정에 대한 근거와 결과를 명확한 숫자로 확인할 수 있다는 것은 팀의 성장에 대한 강력한 무기가 될 수 있습니다.

특히 직접 제품을 개발하거나 고객을 공략해야하는 직군들은 이러한 데이터를 토대로 자신들의 의사결정으로 인한 결과를 가시적으로 확인할 수 있게 되고, 혹여 의사결정에 실패했더라도 이 과정에서 얻은 Lesson & Learn을 토대로 더 날카롭고 명료한 의사결정을 만들어 나가며 성장할 수 있습니다.

그래서 보통 정량적 데이터는 목표 달성치 산정 같은 정량적 수치를 측정하기 위해 활용되거나, "우리 고객들이 이러한 행동을 하고 있다"와 같은 현재 상황을 관측하고, 유저 인터뷰에서 이런 행동에 대한 Why를 알아내어 조직에 인사이트를 쌓기 위한 재료로 쓰이는 경우가 많습니다.

유저 행동 이벤트란 무엇인가요?

쿼타랩의 제품은 크게 클라이언트/서버 어플리케이션 모두에서 이벤트 로그를 수집하고 있어요. 이 중 유저 행동 이벤트는 아래와 같이 유저가 직접 사용하는 클라이언트 어플리케이션에서 행동하는 모든 것들을 수집한 이벤트를 의미합니다.

즉, 유저 행동 이벤트는 클릭/조회/스크롤 등 인간이 행위자가 되어 물리적으로 수행할 수 있는 일련의 행동을 수집한 것이죠.

유저 행동 이벤트가 아닌 것들

그럼 유저 행동 이벤트가 아닌 이벤트는 어떤 것들이 있을까요?

바로 "특정 데이터가 생성되었다"와 같은 이벤트가 유저 행동 이벤트가 아닌 이벤트에 이에 해당됩니다.

물론 데이터가 생성되기 위해서는 정보를 입력하고 마우스로 제출 버튼을 클릭하는 등 유저의 행동이 앞서 수행되어야 하지만, 데이터가 생성되었다는 사건 그 자체는 유저가 직접적으로 수행한 것이 아닌 우리가 만든 프로그램이 수행하는 것이기 때문입니다.

정리해보자면 다음과 같습니다.

유저 행동 이벤트를 찍을 때 개발자들이 느끼는 고통

사실 일반적인 조직, 특히 인적 자원이 턱없이 부족한 초기 스타트업에서 이벤트 로깅 작업이 어려운 이유 중 하나는 개발자들이 이 작업을 선호하는 경우가 적다는 것이죠.

물론 개발자들도 이러한 정량적 데이터를 수집하는 것이 조직에 도움이 된다는 사실은 알고 있지만, 여러가지 이유로 인해 이벤트 로깅 작업에 대한 심리적인 허들이 발생하게 되고 이 허들로 인해 이벤트 로깅 작업이 제대로 진행되지 않는 경우가 많습니다.

이 포스팅에서는 쿼타랩 프론트엔드 챕터가 분석한 개발자들이 이벤트 로깅 작업의 우선순위를 낮게 책정하거나 이 작업 자체에 심리적 허들을 느끼게 되는 요인 3가지 정도를 이야기해보려고 합니다.

1. 이벤트 로깅 코드는 기능 완성 여부와 관련이 없다

많은 개발자들은 모든 기능 개발이 완료된 이후 이벤트 로깅 작업을 진행하거나 심지어는 릴리즈 이후에 진행하기도 합니다. 즉, 개발자들은 직접적으로 기능을 개발하는 작업에 비해 이벤트 로깅 작업이 우선순위가 낮다고 판단하고 있는 것이죠.

이벤트 로그를 심고 유저의 행동을 추적한 데이터를 기반으로 의사결정하는 것이 중요하다면서 왜 개발자들은 이 작업의 우선순위가 낮다고 말하는 걸까요?

그 이유는 근본적으로 이벤트 로그를 발송하는 코드가 어플리케이션에 녹아들어있는 비즈니스 로직의 맥락과는 크게 관련이 없는 코드이기 때문입니다. 그러니 아무래도 이벤트 로깅 동작을 위한 코드는 목표 기능을 개발하기 위해 필수적으로 작성해야하는 코드들에 비해 우선순위가 낮을 수 밖에 없습니다.

한번 아래 예시를 볼까요?

위 예시의 handleCreateFundButtonClick 함수가 표현하고 있는 맥락은 "펀드의 생성"입니다. 유저가 펀드 생성 버튼을 클릭하면 미리 입력해둔 정보를 서버로 전송하고, 이후 전송 결과에 따라 유저에게 피드백을 보여주는 간단한 과정이죠.

위 코드에 포함되어있는 handleCreateFundButtonClick, createFundApi, openNotification, try/catch 등의 코드들은 이 함수의 관심사에 직접적으로 기여하고 있기 때문에, 만약 이 중 단 하나라도 사라진다면 펀드 생성이라는 행위를 표현하기 위해 의도했던 동작이 제대로 작동하지 않습니다.

하지만 이벤트 로깅을 담당하는 logger.click 메소드는 어떨까요?

만약 개발자가 logger.click이라는 코드 라인을 제거하거나 변경한다고 해도 펀드 생성이라는 행위 자체에는 아무런 이펙트도 발생하지 않습니다. 그렇기 때문에 이 코드는 펀드 생성이라는 맥락과는 별개로 "이벤트 로그 발송"이라는 자신의 관심사에만 집중하고 있다고 볼 수 있어요. 쉽게 말해 어플리케이션의 입장만 본다면 있어도 그만, 없어도 그만인 코드인 것이죠.

이는 비단 유저 행동 이벤트와 관련된 로깅 뿐 아니라 대부분의 로깅 작업이 가지고 있는 모순입니다.

물론 릴리즈 날짜까지 기능 개발과 이벤트 로깅 작업 모두를 완벽하게 마무리할 수 있으면 더할나위없이 좋겠지만, 프로젝트에 참여하는 메이커들은 전문가로써 프로젝트의 리스크 관리를 위해서 최악의 상황까지 고려한 의사결정을 해야할 책임과 의무가 있습니다.

만약 여러분이 릴리즈 날까지 모든 작업을 완료하지 못 했을 때 아래 두 가지 상황 중 한 가지를 선택해야 한다면 어떤 것을 선택하게 될까요?

1. 목표했던 기능이 모두 구현되지 않고 이벤트 로그만 찍히는 상황

2. 목표했던 기능은 모두 작동하는데 이벤트 로그가 안 찍히는 상황

   
   

아마 대부분의 경우에는 목표했던 기능이 모두 구현된 2번 상황을 선택할 것입니다. 왜냐하면 목표했던 기능을 모두 구현하기만 하면 릴리즈를 할 수라도 있지만, 목표했던 기능 자체가 구현되지 않는다면 릴리즈를 하겠다는 선택 자체가 불가능해지는 것이니까요.

따라서 2번 옵션을 선택하고 목표했던 기능 구현을 먼저 완료한 이후 이벤트 로그 작업을 진행하는 것이 전반적인 프로젝트의 리스크를 관리하는 측면에서 이익을 볼 수 있습니다.

또한 많은 개발자들이 릴리즈 시점에 이벤트 로깅 작업을 완료하지 못 할 것 같은 경우 "릴리즈 이후에 작업해야지"라고 생각하지만, 대부분의 경우 이미 다음 작업이 To Do로 잡혀있는 경우가 많기 때문에 이벤트 로깅 작업을 진행할 새도 없이 바로 다음 작업을 이어가야 하는 경우가 흔합니다.

2. B2B SaaS의 의사결정은 정성적 데이터가 차지하는 비중이 높다

사실 쿼타랩과 같은 B2B SaaS 비즈니스를 하는 조직은 조직의 특성 상 의사결정에서 B2C에 비해 정량적 데이터가 차지하는 비중이 상대적으로 낮습니다.

그렇다고 정량적 데이터를 보지 않는 것은 아니지만 아무래도 불특정 다수의 고객을 대상으로 시장에서 니즈를 직접 발굴해야하는 B2C 비즈니스에 비해, 직접 고객의 목소리와 요구사항을 들어보는 정성적 데이터가 더 정확한 경우가 많다는 것이죠.

B2B SaaS는 이미 시장에 존재하고 있는 특정한 유저 세그먼트가 가진 페인 포인트를 제거하고 니즈를 만족시켜야 하는 비즈니스이기 때문에 고객이 원하는 것이 곧 시장의 니즈인 경우가 많습니다.

애초에 타겟 고객군이 B2C처럼 다양한 페르소나를 가진 고객이 아닌 특수한 특성과 행동 패턴을 가진 소수의 고객들이기 때문에 성립할 수 있는 전제이지요.

그런 이유로 B2B SaaS 비즈니스를 이해하고 조직의 비즈니스 임팩트를 중심으로 사고하는 개발자는 고객에게 직접적인 Happy Moment를 전달할 수 있는 기능 개발의 우선순위를 더 높게 평가하고, 이벤트 로깅 작업의 우선순위를 상대적으로 낮게 책정하기 쉽습니다.

3. 이벤트 로깅을 위해 설계를 바꿔야 하는 경우가 생긴다

이벤트 로그를 중요하게 생각하는 조직을 경험해본 프론트엔드 개발자들이 공통적으로 공감하는 부분 중 하나는 바로 현재 설계로는 이벤트 로깅이 애매해서 설계를 변경해야하는 경우가 생각보다 잦게 발생한다는 점이에요.

보통 이벤트 로깅을 위해서는 크게 2가지 설계 방향을 따르게 되는데요.

그 중 첫 번째 방법은 이벤트를 직접 트리거하는 컴포넌트와 최대한 가까운 곳에 이벤트 로깅 코드를 위치시켜 응집도를 높임과 동시에 컴포넌트를 사용하는 다른 개발자들이 이벤트 로깅에 대한 맥락을 인지하지 않아도 되도록 추상화해주는 방법입니다.

이런 식의 설계를 하게 되면 FooButton 컴포넌트를 사용하는 다른 개발자들은 해당 버튼이 클릭되었을 때 Click Foo Button이라는 이름의 이벤트가 발송된다는 사실을 신경쓰지 않고 비즈니스 구현에만 집중할 수 있다는 장점이 있습니다.

하지만 이러한 설계로는 아예 이벤트 로깅이 필요없거나 상황에 따라 다른 이벤트를 로깅해야 하는 경우에는 대처할 수 없기 때문에 컴포넌트의 재사용성이 다소 떨어질 수 있다는 단점 또한 가지고 있어요.

그래서 많은 개발자들은 컴포넌트를 사용하는 쪽에서 이벤트 로깅에 대한 맥락을 자유롭게 주입할 수 있도록 이런 설계를 선택하기도 합니다.

이렇게 이벤트 로깅 관심사를 컴포넌트 자체가 아닌 컴포넌트를 호출해서 사용하는 쪽에 위임하게 되면 FooButton 컴포넌트는 이벤트 로깅 관심사와 관계없이 재사용성을 확보할 수 있습니다.

다만 아무래도 이 경우 이벤트 로깅의 책임을 컴포넌트 트리의 Root에 가까운 쪽이 가져갈수록 이런 설계의 장점을 살릴 수 있기 때문에, 첫 번째 설계와는 반대로 이벤트를 트리거링하는 컴포넌트부터 Root까지 이어지는 과도한 Props Drilling이 생길 수 있다는 단점이 있어요.

결국 오직 이벤트 로깅만을 위해 자신이 처음 구상했던 설계를 변경해야 하는 경우가 발생할 수 있다는 것이며, 이런 이유들로 인해 개발자는 이벤트 로깅 작업에 대한 심리적 허들을 느끼게 되기 쉬운 것이죠.

이벤트 로깅에 대한 개발자의 심리적 허들 제거해주기

위와 같은 이유들로 인해 쿼타랩의 유저 행동 이벤트 로깅 작업은 굉장히 누락되기 쉬운 작업이라고 판단할 수 있고, 실제로 쿼타랩의 어플리케이션에는 불과 6개월 전까지만 해도 상당히 많은 유저 행동 이벤트가 누락되어 있었습니다.

쿼타랩 프론트엔드 챕터는 정량적 데이터가 조직의 의사결정 퀄리티에 미치는 영향력에 대해 깊이 공감하고 있고 팀의 성장을 위해서도 반드시 필요한 작업이라고 생각하기 때문에 우리에게 요구되는 이벤트 로깅 작업을 최대한 누락없이 처리해야할 책임이 있다고 생각했습니다.

개발자들이 이벤트 로그를 찍을 때 사용하는 대부분의 시간은 사실 코딩하는 행위가 아니라 설계 자체에 대한 고민을 하는 과정에서 소비됩니다. 앞서 이야기한 대로 오직 이벤트 로그만을 위해 내가 애써 만든 설계를 변경해야 하는 경우가 발생할 가능성이 높으니, 이 문제를 최대한 우아하게 해결하기 위한 고민 과정인 것이죠.

결국 쿼타랩 프론트엔드 챕터는 쿼타랩 팀에 데이터를 기반으로 의사결정하는 문화를 확실하게 정착시키고 발전시키기 위해서라도 프론트엔드 개발자들이 이벤트 로그를 찍을 때 이러한 설계 변경에 대해 고민하는 과정을 거치지 않도록 만들어줘야 했습니다.

해결 방법은 생각보다 간단합니다. 바로 이벤트 로그를 발송하는 코드와 컴포넌트 트리 구조의 맥락을 완전히 분리해버리면 되는 것이죠.

다음 포스팅에서는 @quotalab/logger 패키지를 통해 쿼타랩 프론트엔드 챕터가 이러한 문제를 어떻게 해결했는지에 대해 소개하도록 하겠습니다.

벤처금융 인프라를 함께 만들어 나갈 동료를 찾습니다.
쿼타랩 채용 바로가기