LabHub

블로그

에러 트래킹 & 모니터링 2026 — Sentry / Bugsnag / Honeybadger / GlitchTip / Highlight / LogRocket / Hyperdx 심층 비교

한국어English日本語

1. 2026년 에러 트래킹 지도 — 상용 / 오픈소스 / 세션 리플레이 3 진영

2026년의 에러 트래킹은 "Sentry 쓰면 끝" 이라는 시대를 지났습니다. 정확히 말하면 Sentry 가 여전히 사실상의 리더지만, 그 주변에 세 가지 분명한 카테고리가 자라났습니다 — 클래식 상용 도구, 셀프호스팅 가능한 오픈소스, 그리고 "에러만이 아니라 그 직전 60초의 사용자 행동" 을 함께 보여주는 세션 리플레이 진영.

큰 그림을 정리하면 다음과 같습니다.

2026년의 핵심 변화는 세 가지입니다. 첫째, Sentry 가 2024년 Codecov 를 인수하면서 "에러 → 영향받은 코드 → 영향받은 PR → 누구의 변경" 흐름을 한 회사 안에서 풀게 됐습니다. 둘째, OpenTelemetry 의 Logs 시그널이 GA 가 된 지 2년차에 접어들면서, 벤더 락인 없이 에러를 보낼 수 있는 길이 실용적이 됐습니다. 셋째, AI 그룹화 / AI 트리아지 가 Sentry, Datadog, Bugsnag 모두에서 기본 기능이 됐습니다.

이 글은 위 도구들을 2026년 5월 기준 기능 / 가격 / 셀프호스팅 가능성 / 데이터 잔존 정책 관점에서 빠르게 훑어가는 가이드입니다.


2. Sentry — 리더, Codecov 인수 (2024), AI 기능

Sentry 는 2008년 David Cramer 가 만든 오픈소스 에러 트래커에서 출발해 지금은 에러 트래킹의 사실상의 표준이 됐습니다. 2024년의 가장 큰 사건은 Codecov 인수였습니다 — Sentry 가 코드 커버리지 도구 Codecov 를 인수하면서, "에러가 발생한 라인의 테스트 커버리지" 와 "에러를 일으킨 변경의 PR 번호" 를 한 화면에서 보는 그림이 완성됐습니다.

2026년 5월 기준 Sentry 의 주요 영역은 다음과 같습니다.

JavaScript 클라이언트의 기본 셋업은 다음과 같습니다.

import * as Sentry from '@sentry/nextjs'

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
  release: process.env.SENTRY_RELEASE,
  environment: process.env.NODE_ENV,
  tracesSampleRate: 0.1,
  replaysSessionSampleRate: 0.0,
  replaysOnErrorSampleRate: 1.0,
  integrations: [
    Sentry.replayIntegration({
      maskAllText: true,
      blockAllMedia: true,
    }),
  ],
})

핵심 패턴 몇 가지를 정리하면 다음과 같습니다.

가격은 2026년 5월 기준 Team 플랜 월 $26 부터, Business 월 $80 부터입니다. 셀프호스팅도 가능하지만 2024년부터 Sentry 본체는 Business Source License (BSL) 로 전환했습니다 — 호스팅 서비스로 재판매할 수는 없지만 회사 내부에서 쓰는 데는 무료입니다.


3. Bugsnag (SmartBear) — 엔터프라이즈

Bugsnag 은 2013년에 만들어진 에러 트래커로, 2021년 SmartBear 가 인수했습니다. SmartBear 는 BitBar / Cucumber / SoapUI / TestComplete 같은 QA 툴체인을 가진 회사로, 인수 이후 Bugsnag 은 엔터프라이즈 / 컴플라이언스 / SDLC 통합 방향으로 더 기울었습니다.

Bugsnag 의 차별점은 다음과 같습니다.

Bugsnag 의 한국 / 일본 시장 점유율은 Sentry 보다 작지만, 글로벌 엔터프라이즈 (특히 모바일 게임 / 핀테크) 에서는 여전히 1군입니다.

가격은 공개되지 않습니다 — 영업 문의 기반입니다. 일반적으로 시트당 / 이벤트당 과금이 섞입니다.

JavaScript 클라이언트 셋업은 Sentry 와 거의 같은 모양입니다.

import Bugsnag from '@bugsnag/js'
import BugsnagPluginReact from '@bugsnag/plugin-react'

Bugsnag.start({
  apiKey: process.env.NEXT_PUBLIC_BUGSNAG_KEY,
  appVersion: process.env.APP_VERSION,
  releaseStage: process.env.NODE_ENV,
  enabledReleaseStages: ['production', 'staging'],
  plugins: [new BugsnagPluginReact()],
})

4. Honeybadger — 인디 친화

Honeybadger 는 2012년 Ben Curtis / Joshua Wood / Starr Horne 3 인이 만든 부트스트랩 회사입니다. VC 자본 없이 운영되며, "indie hacker / Rails 커뮤니티의 친구" 라는 포지션을 유지하고 있습니다.

특징을 정리하면 다음과 같습니다.

Honeybadger 의 매력은 "팀이 작아도, 결제가 단순해도, 컴플라이언스가 가볍더라도 부담 없이 쓸 수 있다" 는 점입니다. Sentry 의 자유 기능 폭이 부담스럽거나, Bugsnag 의 영업 사이클이 부담스러운 1인 / 소규모 팀의 선택입니다.

Ruby 의 셋업은 거의 1 줄입니다.

# Gemfile
gem "honeybadger"

# config/honeybadger.yml
api_key: 'xxx'
env: <%= Rails.env %>

5. Rollbar — 롱테일

Rollbar 는 2012년에 만들어진, Sentry 와 비슷한 시기에 시작한 에러 트래커입니다. 한때는 Sentry 와 양강이었지만, 2020년대 들어 Sentry 의 기능 폭 / 커뮤니티 / 가격 경쟁에서 밀리면서 점유율이 줄었습니다. 2026년에도 살아 있지만 "롱테일" 위치입니다.

Rollbar 의 강점은 여전히 다음과 같습니다.

기존 Rollbar 사용자라면 유지해도 좋지만, 신규 도입에서 Rollbar 를 첫 선택지로 검토하는 케이스는 줄었습니다.


6. GlitchTip — 오픈소스 Sentry 호환

GlitchTip 은 2020년 Burke Software 에서 시작한 오픈소스 에러 트래커입니다. 가장 큰 특징은 Sentry 의 SDK 와 와이어 프로토콜이 호환된다는 점입니다 — 즉, 클라이언트 코드에서 DSN 만 바꾸면 그대로 GlitchTip 으로 보낼 수 있습니다.

GlitchTip 이 의도한 자리는 분명합니다.

Docker Compose 한 줄로 셀프호스팅이 가능합니다.

git clone https://gitlab.com/glitchtip/glitchtip-backend.git
cd glitchtip-backend
docker compose up -d

기존 Sentry 클라이언트의 DSN 만 바꿔서 동작시킬 수 있습니다.

import * as Sentry from '@sentry/browser'

Sentry.init({
  // Sentry 본체 대신 GlitchTip 호스트
  dsn: 'https://yourkey@glitchtip.example.com/1',
})

GlitchTip 은 Sentry 의 모든 기능을 따라가지 않습니다 (특히 Performance / Replay / Profiling 은 없음). 하지만 "에러만 잘 잡으면 된다, 그리고 우리 데이터센터에서 돌리고 싶다" 는 요구엔 가장 가벼운 답입니다.


7. Highlight.io — 오픈소스 + 세션 리플레이

Highlight.io 는 2022년 시작된 오픈소스 옵저버빌리티 플랫폼입니다. 에러 트래킹 + 세션 리플레이 + 로그 + 분산 트레이싱 을 한 화면에 묶은 게 특징입니다. Apache 2.0 라이선스로, GitHub 와 셀프호스팅 호환성을 우선합니다.

특징을 정리하면 다음과 같습니다.

Highlight 가 흥미로운 자리는 "오픈소스인데 LogRocket 같은 세션 리플레이를 준다" 는 점입니다. LogRocket 의 라이선스 / 가격이 부담스러운 인디 / 소규모 팀 / 비영리에서 좋은 후보입니다.

import { H } from 'highlight.run'

H.init('YOUR_PROJECT_ID', {
  environment: 'production',
  version: 'commit:abcdefg12345',
  tracingOrigins: true,
  networkRecording: {
    enabled: true,
    recordHeadersAndBody: true,
    urlBlocklist: ['/api/auth/login'],
  },
})

8. AppSignal — Elixir/Ruby 특화

AppSignal 은 네덜란드 회사로, 2012년 Ruby on Rails APM 으로 시작해 지금은 Elixir / Node.js / Python / Ruby 를 1군으로 지원하는 풀스택 옵저버빌리티 도구입니다. 특히 Elixir 커뮤니티에서는 사실상의 표준입니다.

특징을 정리하면 다음과 같습니다.

AppSignal 은 "Elixir / Rails 다단계 다이나믹 언어를 쓰고, 단일 도구로 APM + 에러를 다 풀고 싶다" 는 사용자에게 1순위입니다. JS / Java / Go 가 메인인 팀에는 잘 안 맞습니다.

Elixir 의 셋업은 다음과 같습니다.

# mix.exs
defp deps do
  [
    {:appsignal_phoenix, "~> 2.4"}
  ]
end

9. BetterStack — 로그 + 에러 + 상태 페이지

BetterStack 은 슬로바키아 회사로, 2021년 Better Uptime / 2022년 Logtail 을 통합해 만든 옵저버빌리티 플랫폼입니다. 2026년 현재는 Uptime / Logs / Telemetry (메트릭+트레이싱) / Incidents / Status Pages 를 한 SaaS 로 묶고 있습니다.

특징을 정리하면 다음과 같습니다.

BetterStack 의 차별점은 "한 회사로 Uptime + Logs + Status Page 까지 다 묶기" 입니다. 작은 SaaS / 인디 / 스타트업이 PagerDuty + Datadog + statuspage.io 같은 3 곳을 묶지 않고 한 곳으로 시작할 때 좋은 후보입니다.

에러 트래킹의 "전용 도구" 는 아니지만, 로그 기반으로 에러를 탐지 / 알림하는 워크플로가 충분히 됩니다. Sentry 의 영역과 부분적으로 겹칩니다.


10. LogRocket / FullStory / OpenReplay — 세션 리플레이

세션 리플레이는 "에러가 났을 때 그 직전 N 분의 사용자 화면 / 클릭 / 네트워크 / 콘솔" 을 비디오처럼 재생해 주는 기능입니다. "버그가 안 재현돼요" 라는 클래식 문제를 해결합니다. 2026년의 3 강은 LogRocket, FullStory, OpenReplay 입니다.

LogRocket — 2016년 시작, 가장 유명한 세션 리플레이 도구

FullStory — UX 분석 1군

OpenReplay — 오픈소스 세션 리플레이 (Elastic License)

세션 리플레이는 PII / GDPR 문제가 항상 따라옵니다. 입력값 / 신용카드 번호 / 토큰을 클라이언트에서 마스킹한 다음 전송하는 게 표준입니다.

// LogRocket 예시
import LogRocket from 'logrocket'

LogRocket.init('your/app-id', {
  network: {
    requestSanitizer: (request) => {
      if (request.url.includes('/api/auth')) return null
      delete request.headers['Authorization']
      return request
    },
  },
  dom: {
    inputSanitizer: true,
    textSanitizer: false,
  },
})

11. Hyperdx — OpenTelemetry 네이티브 오픈소스

Hyperdx 는 2023년 시작된 오픈소스 옵저버빌리티 플랫폼입니다. 가장 큰 특징은 OpenTelemetry 네이티브 — 즉 OTLP 가 1급 입력이고, ClickHouse 가 백엔드입니다. 2024년 ClickHouse 가 Hyperdx 를 인수하면서, 지금은 ClickHouse Observability 의 한 컴포넌트로 자리 잡고 있습니다.

특징을 정리하면 다음과 같습니다.

Hyperdx 의 자리는 분명합니다. "벤더 락인 없이 OpenTelemetry 표준 위에서 셀프호스팅하고 싶다, 그러면서 Sentry 비슷한 UX 도 원한다" 는 팀입니다. ClickHouse 가 인수한 이후로 "ClickHouse + Hyperdx + OTel" 스택은 Datadog / New Relic 의 강력한 대안이 됐습니다.

// OpenTelemetry SDK 만 설정하면 Hyperdx 로 자동 전송
import { NodeSDK } from '@opentelemetry/sdk-node'
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http'

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: 'https://in-otel.hyperdx.io/v1/traces',
    headers: {
      authorization: process.env.HYPERDX_API_KEY,
    },
  }),
})

sdk.start()

12. Datadog / New Relic — APM과의 통합

Datadog Error Tracking 과 New Relic Errors Inbox 는 "APM 안에 내장된 에러 트래킹" 입니다. 즉, 별도 도구가 아니라 APM 의 한 탭입니다.

Datadog Error Tracking 의 특징은 다음과 같습니다.

New Relic Errors Inbox 의 특징은 다음과 같습니다.

"이미 Datadog / New Relic 을 APM 으로 쓰고 있다" 는 팀은 Sentry 를 별도로 도입하기 전에 이 기능부터 켜 보는 게 합리적입니다. 추가 도구 없이 APM + 에러를 한 화면에서 풀 수 있습니다.


13. OpenTelemetry Logs/Errors signal 성숙

OpenTelemetry 는 2019년 OpenTracing + OpenCensus 가 합쳐져 만들어진 옵저버빌리티 표준입니다. 처음엔 Traces 만 GA 였지만 — Metrics 가 2023년, Logs 가 2024년에 차례로 GA 가 됐습니다. 2026년 시점엔 "OpenTelemetry 로 로그 + 트레이스 + 메트릭 + 에러를 한 SDK 로 보내고, 백엔드만 갈아끼우는" 시나리오가 현실적이 됐습니다.

OpenTelemetry 로 에러를 보내는 표준 모양은 다음과 같습니다.

import { trace, SpanStatusCode } from '@opentelemetry/api'

const tracer = trace.getTracer('my-app')

async function fetchUser(id: string) {
  return tracer.startActiveSpan('fetchUser', async (span) => {
    try {
      const user = await db.user.findUnique({ where: { id } })
      span.end()
      return user
    } catch (err) {
      span.recordException(err)
      span.setStatus({ code: SpanStatusCode.ERROR, message: err.message })
      span.end()
      throw err
    }
  })
}

이렇게 만들어진 에러는 OTLP 로 어디든 보낼 수 있습니다 — Sentry (OTLP 입력 베타), Datadog, New Relic, Hyperdx, Grafana, 또는 자체 백엔드. 이게 2026년의 "에러는 표준, 벤더는 교체 가능" 시나리오의 기반입니다.

다만 현실적으로는 모든 벤더가 OTLP 를 1급으로 받는 건 아닙니다. Sentry / Datadog / New Relic 모두 자기 SDK 의 기능이 더 많고 (예: 자동 컨텍스트 / 자동 그룹화 / 자동 PII 마스킹), OTLP 경로는 그보다 미니멈입니다. "벤더 락인" 과 "최대 기능" 사이의 트레이드오프가 있습니다.


14. 한국 / 일본 — 토스, 카카오, 메르카리, LINE, freee

한국 / 일본의 큰 회사들이 실제로 어떤 에러 트래커를 쓰고 있는지를 보면, 글로벌 트렌드와 비슷하면서도 약간의 지역 색이 있습니다.

한국 사례

일본 사례

공통 패턴이 보입니다. 사용자 데이터 양이 일정 규모 이상이 되면 (월 수억 이벤트 이상) 자체 도구 / 셀프호스팅을 검토합니다. 비용도 비용이지만, 개인정보 보호법 (한국) / 個人情報保護法 (일본) 의 데이터 거주 요건이 중요합니다. 그래서 작은 회사는 Sentry SaaS, 큰 회사는 Sentry 셀프호스팅 또는 자체 도구로 갈리는 모양이 자주 보입니다.


15. 누가 무엇을 골라야 하나 — 1인 / 스타트업 / 엔터프라이즈 / 셀프호스팅

마지막으로 시나리오별 추천을 정리합니다.

1인 / 인디 / 사이드 프로젝트

소규모 스타트업 (10명 이하)

성장 단계 스타트업 (10~100명)

엔터프라이즈 (100명 이상, 컴플라이언스 중요)

셀프호스팅 / 데이터 주권

언어 / 런타임 1순위

2026년의 베스트 셋업은 "Sentry 또는 OpenTelemetry + 백엔드" 의 둘 중 하나입니다. Sentry 는 즉시 가치를 주고, OpenTelemetry 는 장기적 자유를 줍니다. 작은 팀은 Sentry, 큰 팀은 OTel 위에 Sentry / Datadog / Hyperdx 를 얹는 양면 전략이 흔해졌습니다.


16. 참고 / References

Sentry

Bugsnag

Honeybadger

Rollbar

GlitchTip

Highlight.io

AppSignal

Raygun

BetterStack

LogRocket / FullStory / OpenReplay

Hyperdx

Datadog / New Relic

OpenTelemetry

한국 / 일본 사례

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다