20 Posts
2026년 4월 12일4분 읽기

프론트엔드 개발자가 Datadog을 써야 하는 이유

에러는 Watap, 지표는 Elasticsearch, 마케팅은 GA4로 보던 시절이 있었다. Datadog을 만나고 나서 데이터가 연결되는 경험을 처음 했다.

프론트엔드 개발자가 GA4와 Datadog을 써야 하는 이유

우리 팀은 각자 다른 도구를 사용하고 있었다.

에러는 Watap으로 확인했고,

서비스 지표는 Elasticsearch 대시보드를 통해 확인했고,

마케팅 데이터는 GA4에서 확인했다.

각 도구는 나름의 역할을 잘 수행했다.

문제는 데이터가 서로 연결되지 않는다는 점이었다.

에러가 발생했다.

그런데 실제 사용자에게 어떤 영향을 줬는지는 알 수 없었다.

특정 페이지의 이탈률이 증가했다.

그런데 성능 문제 때문인지, 기능 문제 때문인지는 알 수 없었다.

데이터는 많았지만 하나의 이야기로 이어지지 않았다.

프론트엔드 개발자가 데이터를 보기 시작하면

예전에는 기능을 만들고 배포하면 끝이라고 생각했다.

하지만 서비스를 운영할수록 궁금한 것들이 많아졌다.

이 버튼은 실제로 얼마나 눌릴까?

사용자들은 어디에서 가장 많이 이탈할까?

느린 페이지 때문에 사용자가 떠나고 있는 건 아닐까?

개발자가 데이터를 보기 시작하면 단순히 구현만 하는 사람이 아니라 제품을 함께 만드는 사람이 된다.

그래서 자연스럽게 GA4를 보기 시작했다.

페이지뷰를 보고,

이벤트를 만들고,

전환율을 확인했다.

그 자체로도 충분히 재미있었다.

내가 만든 기능이 실제 사용자에게 어떤 영향을 주는지 처음으로 볼 수 있었으니까.

Datadog을 처음 봤을 때의 충격

Datadog을 처음 접한 건 POC를 진행하면서였다.

솔직히 처음에는 또 다른 모니터링 툴 정도로 생각했다.

이미 Watap도 있었고,

Elastic도 있었고,

GA4도 있었으니까.

그런데 RUM(Real User Monitoring)을 처음 보고 생각이 완전히 바뀌었다.

사용자가 실제로 어떤 환경에서 서비스를 사용하고 있는지 볼 수 있었다.

어떤 브라우저를 사용하는지,

어떤 페이지에서 느려지는지,

어느 구간에서 JavaScript 에러가 발생했는지,

실제 사용자의 경험을 그대로 확인할 수 있었다.

그동안 보던 데이터는 시스템 중심이었다.

Datadog RUM은 사용자 중심이었다.

그 차이가 꽤 크게 다가왔다.

데이터가 연결되기 시작했다

특히 신기했던 건 데이터가 서로 연결된다는 점이었다.

예전에는

에러 발생

이라는 사실만 알 수 있었다.

Datadog에서는

어떤 사용자가

어떤 페이지에서

어떤 동작을 하다가

어떤 에러를 만났는지

까지 이어서 볼 수 있었다.

성능 데이터도 마찬가지였다.

LCP가 느려졌다.

그러면 어떤 리소스가 원인인지,

어떤 사용자가 영향을 받았는지,

특정 브라우저에서만 발생하는 문제인지 추적할 수 있었다.

그 순간부터 모니터링 툴이 아니라 디버깅 도구처럼 느껴졌다.

Bits AI도 꽤 인상적이었다

최근에는 Bits AI도 함께 사용해봤다.

물론 아직 모든 것을 완벽하게 해결해주는 수준은 아니다.

하지만 로그와 메트릭을 분석해서

"이 문제가 왜 발생했는지"

를 먼저 제안해주는 경험은 꽤 신선했다.

예전에는

  1. 로그 확인
  2. 대시보드 확인
  3. 원인 추측
  4. 추가 조사

를 반복했다.

지금은

이 시간대에 응답 시간이 증가했고,

특정 API 에러가 함께 증가했습니다.

같은 힌트를 먼저 받을 수 있다.

AI가 문제를 해결해주는 것은 아니지만 문제를 찾는 시간을 줄여주는 느낌에 가까웠다.

결국 가장 중요한 것은 관찰 가능성(Observability)

Datadog을 사용하면서 가장 크게 느낀 것은 기능이 아니라 관점의 변화였다.

예전에는

서비스가 정상인가?

를 확인했다면

지금은

사용자는 지금 어떤 경험을 하고 있는가?

를 보게 됐다.

그리고 그 질문은 프론트엔드 개발자에게 생각보다 중요하다.

좋은 UI를 만드는 것도 중요하지만,

실제 사용자가 어떻게 느끼는지 확인할 수 없다면 절반만 만든 것과 비슷하다고 생각한다.

마무리

Datadog을 도입하면서 가장 좋았던 점은 새로운 툴을 사용했다는 사실이 아니었다.

데이터를 바라보는 방식이 달라졌다는 점이었다.

에러와 성능,

사용자 행동과 비즈니스 지표가 하나로 연결되기 시작했다.

돌아보면 내가 POC를 제안하고 도입을 추진했던 이유도 비슷했던 것 같다.

서비스를 더 잘 이해하고 싶었다.

그리고 개발자가 제품을 이해하는 가장 좋은 방법 중 하나는 결국 데이터를 직접 보는 것이라고 생각한다.

최근 접해본 기술 중 가장 재미있었던 것을 하나 꼽으라면,

아마 Datadog과 Observability 문화가 아닐까 싶다.

More posts

전체 보기