페이스북에 썼던 글 두 개 취합해서 현재 시점으로 다시 정리했다. 요약하면

• 웹 프론트엔드단에서 에러 모니터링, 이벤트 추적, 분석 모두 Datadog으로 하려고 했던 시도는 실패였다.
• 지금은 에러 모니터링은 Sentry로, 주요 이벤트 추적 및 분석은 Amplitude로 하고 있다.
• 디버깅할때는 Datadog의 세션 리플레이와 자동 클릭 이벤트 추적을 유용하게 써먹고 있다.

Datadog 도입 배경

다른 서비스들과 마찬가지로 XL8에서도 모니터링 서비스가 필요해졌다. 여러가지 고민하다가 “올인원 툴”이라고 홍보되던 Datadog을 MediaCAT에서 써보기로 했다. 이전 회사였던 한국신용데이터에서는 다양한 도구를 조합해서 썼었는데 도구 갯수를 줄여보고 싶었다.

• 한국신용데이터는 프론트엔드 기준, Segment에 Google Analytics, Facebook Pixel, Amplitude 등을 붙여서 썼다.
• 분석은 Amplitude + 자체 개발 서비스(Mixpanel을 포크 뜬)로 하고, 에러 모니터링은 Sentry로 했다.

Datadog이 백엔드 로그 모니터링만 위주인 줄 알았는데 프론트엔드단 모니터링(RUM, Real User Monitoring)도 있고 이벤트 분석도 되길래 괜찮아 보였다. 당시 Sentry는 패키지 크기가 너무 컸던 것도 한가지 이유였다.

운영 환경에서 한 달

9월에 MediaCAT을 릴리즈했다. Datadog을 한 달 정도 운영 환경에서 사용해보니 여러가지 아쉬움이 들었다. 올인원 툴이라는 명성에 걸맞게 대부분의 기능이 적당히 잘 동작하지만, 그 모든 것들이 10점 만점에 7점 수준인 느낌이었다. 사용법을 파악하기 위해 문의를 상당히 많이 해야 했는데, 문의를 해야만 했다는 거 자체는 마이너스고 답변이 비교적 빨리빨리 왔다는 건 플러스였다.

Sessions & Replays

• 세션 리플레이는 만족스러웠다. 동적으로 변하는 경로(e.g., /tasks/1, /tasks/2)들을 알아서 잘 묶어서 하나의 이벤트로 만들어주는 것도 좋고, Hotjar처럼 아예 녹화하듯 영상을 볼 수도 있었다(유저 인풋은 가려짐). 새로 배포한 피처에 대한 반응을 볼 때도 괜찮았고 온보딩 퍼널 분석, 디버깅할 때 등등 계속 유용하게 썼다. 화면 녹화에 별도의 비용이 들어가지 않고 플랜에 포함되어있다는 것도 좋았다.
• MediaCAT은 데스크탑 웹 전용으로 만든 앱이고, 아직 유저도 적어서 화면 녹화에 따르는 네트워크 트래픽은 당분간 신경쓰지 않기로 했다.
• 대부분의 클릭 이벤트를 자동으로 잡아주는데 이건 좋기도 하고 나쁘기도 했다. 클릭 이벤트의 title을 자동 생성해주는 게 제법 그럴듯해서 작업 공수가 줄어들지만, 원치 않는 클릭 이벤트 전송을 막는 건 어렵고(Datadog 인스턴스를 초기화할 때 beforeSend로 처리해야 함) property를 함께 보낼 수도 없다.

Analytics

• 유저 이벤트 찍어서 퍼널 만들고 분석하는 건 꽤 편하고 잘 되어있는 편이었다. 개발자 친화적인 (즉 못생긴) UI인데, 이렇게 하면 되려나? 싶은 건 대부분 되더라. 교차 도메인에서 이벤트 이어지게 하는 것도 가능하고.
• 대시보드로 만들어서 Datadog 계정 없는 사람들에게 MediaCAT의 메트릭을 공유하고 싶었는데, 버그가 있는지 그래프 제목만 나오고 내용이 나오질 않았다.
• Amplitude와 달리(과금 여부와 상관없이 2000개) 이벤트 타입 갯수 제한은 없는 것 같아서 마음에 들었다. 물론 대부분의 스타트업에서는 이벤트 타입을 동적으로 계속 만들지만 않는다면 이벤트 타입 갯수가 모자를 일은 없겠지만.

Error Monitoring

• 가장 크게 실망했던 부분. Sentry보다 훨씬 못하다. RUM에는 뜨는데 에러로는 안 잡히는 게 너무 많았다. 이걸 팀원 중 한 분이 오랫동안 파고들었는데 결국 해결이 안 됐다. 그래서 슬랙 알림으로도 안 오니까, 에러가 생겨도 알기가 어려워서 너무 치명적이었다.
• 슬랙 integration이 너무 안 좋아서 무슨 에러가 났는지 바로 알기 어려웠다.
• 사소하다면 사소할 수 있으나, 이슈를 resolve 하는 기능도 없고 ignore만 가능하다.
• Source map upload도 잘 안 되던데, 이건 Datadog 문제는 아니고 github action + vercel의 문제긴 하지만 아무튼...
• 그래서, 전통의 강자 Sentry로 갈아타기로 결정했다. 과금 정책이 모두 쪼개져있으니 일부만 다른 툴 쓰는데 비용적 손해가 없는 건 좋다. (Sentry의 용량 문제는 2022년 7월에 일부 해결되었다)

그리고 또 한 달

Datadog의 에러 모니터링에 실망하여 Sentry를 도입한지 한 달이 또 지났다. 위에 Datadog이 “분석하는 건 꽤 편하고 잘 되어있는 편이다”는 말은 취소한다. 제대로 분석을 하려고 하니 아주 불편해서, 결국 Amplitude로 넘어왔다.

Datadog은 분석이 세션 위주라서 “유저 기반”으로 분석이 안 된다. Amplitude나 Mixpanel 등 이벤트 분석 도구들에서 제공하는 기능들이 대부분 안 되거나, 부족했다. 예를 들어:

• 퍼널 만들 때 property를 조건에 넣을 수 없다. 당연히 같은 property를 유지한 채 퍼널을 구성하는(i.e., Holding Constant ) 것도 안 된다.
• 퍼널 만들 때 여러 이벤트를 한 이벤트처럼 묶을 수 없다. 그래서 한 페이지에서 유사한 가치를 제공하는 액션들을 하나의 단계로 가정하고 넘어갈 수가 없었다.
• 퍼널이 세션 기준이고, 세션 길이를 분석하면서 조정할 수 없다 보니 "그래서 이 유저가/얼마나 많은 유저가 이 이벤트를 경험한거냐 아닌거냐" 같은 걸 보기가 어렵다. 한 세션에서 퍼널의 중간까지 하고, 다음날 돌아와서 퍼널의 나머지를 수행했을 때 Datadog 퍼널에서는 유저 여정이 끊긴 것으로 보는 것 같았다.
• 코호트 분석을 할 수 없다.

그리고, 위에도 썼지만 우리는 Datadog의 자동 클릭 이벤트 추적을 많이 썼었다. 예를 들어 <button>Download</button> 같은 걸 유저가 클릭했을 때 따로 액션 지정을 안 해도 "click on Download" 같은 이벤트로 찍히는 식이어서 편했다.

그런데 우리 웹사이트는 영어로만 되어 있고, 유저 중 브라우저의 번역 기능을 이용하는 사람들이 있었다. 그러면 이벤트가 "click on 다운로드" 가 되어버려서 퍼널에 안 잡히더라. 즉 분석을 제대로 할 거면 이벤트 자동 추적에 의존하지 않고 직접 이벤트를 넣어야 한다는 뜻이었다.

결론

각 분야에서 유명한 툴들은 역시 이유가 있다는 걸 몸으로 깨달았다. 그래서 지금은 에러 모니터링은 Sentry로, 이벤트 트래킹과 분석은 Amplitude로 각각 하고 있다. Datadog은 디버깅 전용이 되었다. 분석할 거 아니고 디버깅만 할 거면 이벤트 자동 트래킹은 충분히 유용하고, 세션 리플레이도 좋다. 아직은 트래픽이 적어서 비용도 많이 안 낸다.

백엔드에서는 로그 찍고 모니터링하는 건 Datadog에서 잘 하고 계시고, 우리처럼 디버깅에 잘 써먹을 순 있으니 Datadog의 효용을 부정할 순 없다. 하지만 다른 툴 대신 Datadog 하나만으로, 이벤트 추적하고 분석한다는 회사가 있다면… (열심히 문의 답변해주신 엔지니어 분들께는 죄송하지만) 적극 말리며 다른 거 쓰시라고 얘기하련다.