배포 후 발생하는 에러는 사용자가 신고하기 전까지는 존재 자체를 모르는 경우가 많습니다. 서버 로그를 뒤져서 찾아낸다 해도 스택트레이스만으로는 어떤 입력값·어떤 화면 흐름에서 터졌는지 알기 어렵고, 재현이 안 되면 원인 파악에 시간이 오래 걸립니다. Sentry는 이 에러 수집·집계·알림 과정을 대신 맡아주는 옵저버빌리티 서비스로, 예외가 발생한 순간의 스택트레이스와 직전 사용자 행동 로그(Breadcrumb)를 함께 모아서 대시보드에 정리해줍니다.

앱 코드에 내장된 Sentry SDK가 예외 발생 시 이벤트를 HTTPS로 Sentry 서버에 전송하고, 서버는 동일 스택트레이스를 Issue로 그룹핑해 대시보드에 집계하는 동시에 Alert Rule 조건을 만족하면 Slack·Email로 알림을 보내는 흐름도
SDK가 이벤트를 전송하면 Sentry 서버가 그룹핑과 알림을 대신 처리합니다.

왜 필요한가

에러 모니터링 없이 운영하면 보통 아래 순서로 문제를 알게 됩니다.

  • 사용자가 문의를 남기거나 앱스토어에 낮은 별점 리뷰를 남긴다
  • 그제서야 서버 로그나 클라이언트 크래시 리포트를 뒤져서 원인을 찾는다
  • 같은 에러가 몇 명에게, 얼마나 자주 발생했는지는 로그만으로 집계하기 어렵다

Sentry를 붙이면 이 흐름이 뒤바뀝니다. 예외가 발생하는 즉시 이벤트가 전송되고, 같은 스택트레이스를 가진 에러는 하나의 Issue로 자동 그룹핑되어 발생 빈도와 영향받은 사용자 수가 집계됩니다. 임계치를 넘으면 Slack이나 이메일로 알림이 오므로, 사용자 문의보다 먼저 문제를 인지할 수 있습니다.

핵심 개념

  • Event: 예외 하나가 발생했을 때 SDK가 전송하는 단위. 스택트레이스, 발생 시각, 실행 환경(브라우저/OS/앱 버전)을 담습니다.
  • Issue: 같은 원인으로 보이는 Event들을 스택트레이스 지문(fingerprint) 기준으로 자동 묶은 그룹. 발생 건수와 영향받은 사용자 수가 Issue 단위로 집계됩니다.
  • Breadcrumb: 에러가 나기 직전까지 있었던 행동 로그(클릭한 버튼, 호출한 API, 콘솔 로그 등). 재현 없이도 "무슨 상황에서" 터졌는지 유추하는 데 씁니다.
  • Release / 소스맵: 배포 버전을 SDK 초기화 시 태그로 넘기면, 압축·난독화된 코드의 스택트레이스도 소스맵을 업로드해 원본 파일·라인 번호로 복원해서 보여줍니다.
  • Alert Rule: "1시간 내 같은 Issue가 10건 이상 발생하면 Slack으로 알림" 같은 조건을 설정하는 규칙. 모든 에러를 알림으로 받으면 금방 무시하게 되므로 실제로는 임계치를 둔 규칙 몇 개만 운영하는 경우가 많습니다.

실전 예시

Node.js/Express 서버에 붙이는 경우입니다. 의존성을 설치합니다.

npm install @sentry/node

가장 먼저, 다른 모든 코드보다 먼저 초기화합니다.

// instrument.js
const Sentry = require('@sentry/node')

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  release: process.env.APP_VERSION,
  tracesSampleRate: 0.1,
})

module.exports = Sentry

// server.js
require('./instrument') // 반드시 다른 require보다 먼저 로드
const express = require('express')
const Sentry = require('@sentry/node')

const app = express()

app.get('/orders/:id', async (req, res) => {
  const order = await findOrder(req.params.id)
  if (!order) {
    throw new Error(`주문을 찾을 수 없음: ${req.params.id}`)
  }
  res.json(order)
})

// 라우트 정의 뒤, 다른 에러 핸들러보다 앞에 등록
Sentry.setupExpressErrorHandler(app)

app.use((err, req, res, next) => {
  res.status(500).json({ error: '서버 오류가 발생했습니다' })
})

app.listen(3000)

findOrder에서 예외가 나면 Sentry가 자동으로 캡처하지만, try/catch로 직접 잡은 에러는 명시적으로 넘겨야 합니다.

app.post('/payments', async (req, res) => {
  try {
    const result = await chargeCard(req.body)
    res.json(result)
  } catch (err) {
    Sentry.captureException(err, {
      tags: { feature: 'payment' },
      extra: { orderId: req.body.orderId, amount: req.body.amount },
    })
    res.status(402).json({ error: '결제에 실패했습니다' })
  }
})

tags는 Issue 목록에서 필터링에 쓰이고, extra는 해당 Event 상세 화면에서만 확인할 수 있는 부가 정보입니다. 결제처럼 자주 문제가 나는 기능은 이렇게 feature 태그를 붙여두면, 같은 결제 관련 에러들을 대시보드에서 한 번에 모아볼 수 있습니다.

배포 파이프라인에서는 릴리스와 소스맵을 함께 업로드합니다.

npx @sentry/cli releases new "$APP_VERSION"
npx @sentry/cli releases files "$APP_VERSION" upload-sourcemaps ./dist
npx @sentry/cli releases finalize "$APP_VERSION"

이 단계를 빠뜨리면 프로덕션 빌드의 압축된 코드 기준 스택트레이스만 보이는데, 파일명이 bundle.min.js:1:48213 같은 식으로 나와서 원인 파악이 사실상 불가능합니다.

비슷한 서비스와 비교

항목 Sentry Firebase Crashlytics Bugsnag
대상 웹 백엔드·프론트엔드·모바일 전반 Firebase 연동 모바일 앱 위주 웹·모바일 전반
Breadcrumb(행동 로그) 제공 제공(커스텀 키 방식) 제공
소스맵/심볼 복원 제공 제공(dSYM/ProGuard 매핑 업로드) 제공
성능·트레이스 모니터링 제공(APM 겸용) 별도 제품(Performance Monitoring) 미제공, 에러 추적에 집중
무료 티어 있음(아래 비용 항목 참고) 무료, 사용량 제한 없음 있음, 월 이벤트 건수로 제한

Firebase Crashlytics는 이미 Firebase를 쓰는 모바일 앱이라면 추가 설정 없이 무료로 붙일 수 있다는 점이 강점이지만, 백엔드나 웹 프론트엔드까지 하나의 대시보드에서 보고 싶다면 범위 밖입니다. Bugsnag은 기능 구성이 Sentry와 비슷하지만 성능 모니터링 없이 에러 추적에만 집중되어 있고, 정확한 요금 구간은 서비스별로 자주 바뀌는 편이라 도입 전 공식 요금 페이지 확인이 필요합니다.

비용

Sentry는 2026년 9월 기준 공식 요금 페이지에서 아래처럼 안내하고 있습니다.

  • Developer(무료): 월 5,000 에러, 사용자 1명. 개인 프로젝트나 소규모 테스트에 적합합니다.
  • Team: 월 26달러부터. 기본 제공량은 에러 5만 건, 스팬(트레이스) 500만 건, 리플레이 50건, 로그 5GB 포함이고, 초과분은 종량제(예: 5만~10만 건 구간 기준 에러 1건당 약 0.00036달러)로 청구됩니다.
  • Business: 월 80달러부터. 기본 제공량은 Team과 동일하고 고급 기능(SSO, 데이터 보관 기간 연장 등)이 추가됩니다.

Firebase Crashlytics는 Spark(무료)·Blaze 플랜 모두에서 완전히 무료이고 별도 사용량 제한이 없습니다. 다만 크래시 리포트 전용이라 백엔드 에러나 커스텀 이벤트 태깅 같은 Sentry의 기능은 없습니다. 정확한 최신 수치는 각 서비스의 공식 요금 페이지에서 재확인하는 것이 안전합니다.

장단점 정리

장점

  • 사용자 신고보다 먼저 에러 발생을 인지할 수 있음
  • 동일 원인 에러를 Issue로 자동 그룹핑해 중복 알림에 지치지 않음
  • Breadcrumb·소스맵 덕분에 재현 없이도 원인 범위를 상당히 좁힐 수 있음
  • 웹·모바일·백엔드를 하나의 대시보드에서 함께 볼 수 있음

단점

  • 트래픽이 늘면 이벤트 건수도 함께 늘어서 비용이 사용량에 비례해 커짐
  • Sentry.init을 다른 코드보다 먼저 호출해야 하는 등 초기화 순서에 민감해서, 잘못 배치하면 일부 초기 에러가 누락됨
  • 소스맵 업로드 단계를 배포 파이프라인에 추가해야 하고, 빠뜨리면 압축된 코드 기준 스택트레이스만 남아 사실상 무용지물이 됨

이미 로그 수집·알림 인프라를 자체로 구축해뒀다면 당장 필요하지 않을 수 있지만, 그런 인프라가 없는 상태로 프로덕션에 배포한다면 Sentry의 무료 티어만으로도 사용자 신고보다 먼저 문제를 아는 체감 차이가 큽니다.