Sentry 완벽 가이드 | 에러 추적·모니터링·성능·알림·실전 활용
이 글의 핵심
Sentry로 프로덕션 에러를 추적하는 완벽 가이드. 에러 모니터링, 성능 추적, Source Maps, 알림 설정까지 실전 예제로 정리. Sentry·Error Tracking·Monitoring 중심으로 설명합니다.
이 글의 핵심
Sentry로 프로덕션 에러를 추적하는 완벽 가이드입니다. 에러 모니터링, 성능 추적, Source Maps, 알림 설정까지 실전 예제로 정리했습니다.
실무 경험 공유: Sentry를 도입하면서, 프로덕션 에러 대응 시간이 24시간에서 1시간으로 단축되고 사용자 만족도가 크게 향상된 경험을 공유합니다.
들어가며: “프로덕션 에러를 모르겠어요”
실무 문제 시나리오
시나리오 1: 에러가 발생해도 몰라요
로그를 확인해야 합니다. Sentry는 실시간 알림을 제공합니다. 시나리오 2: 에러 재현이 어려워요
정보가 부족합니다. Sentry는 상세한 컨텍스트를 제공합니다. 시나리오 3: 성능 문제를 찾기 어려워요
수동 분석이 필요합니다. Sentry는 자동 성능 추적을 제공합니다.
1. Sentry란?
에러 추적 플랫폼의 역사 (2008~)
Sentry는 2008년 David Cramer가 Django 프로젝트에서 에러를 모니터링하기 위해 만든 오픈소스로 시작했습니다. 당시 프로덕션 에러는 서버 로그 파일을 SSH로 접속해서 grep으로 찾는 방식이었고, 사용자가 겪은 에러를 개발자가 모르는 경우가 많았습니다.
Sentry는 이 문제를 “에러가 발생하면 즉시 알림, 재현 가능한 모든 정보 자동 수집”으로 해결했습니다. 2015년 회사로 전환하면서 다중 언어(Python→JS→Go 등) 지원, Source Maps로 minified 코드 추적, 성능 모니터링(APM)까지 확장했습니다.
Sentry의 철학: “에러는 문맥 없이는 해결할 수 없다”
로그 파일에 TypeError: Cannot read property 'name' of undefined만 있으면 재현이 어렵습니다. Sentry는 에러와 함께 문맥을 수집합니다:
- 사용자: 어떤 유저가 겪었나 (ID, 이메일, 세션)
- 환경: 브라우저·OS·디바이스·네트워크
- 경로: 에러 직전 사용자 행동(Breadcrumbs)
- 상태: 변수 값, Redux state, API 응답
- 스택: Source Maps로 원본 코드 위치
Sentry vs Datadog vs CloudWatch
| 측면 | Sentry | Datadog | AWS CloudWatch |
|---|---|---|---|
| 강점 | 에러 추적·Replay | APM·인프라 통합 | AWS 네이티브 |
| 무료 | 5K 이벤트/월 | 14일 trial | 기본 지표 무료 |
| Source Maps | ✅ 자동 업로드 | ✅ 수동 설정 | ❌ |
| Session Replay | ✅ | ❌ | ❌ |
| 가격 | $26/월~ | $15/호스트/월~ | 종량제 |
| 사용 시나리오 | 프론트엔드·백엔드 에러 | 인프라 전체 관측 | AWS 중심 모놀리스 |
선택 기준:
- 프론트엔드 에러 중심 → Sentry (Session Replay·Source Maps 필수)
- 인프라·메트릭 통합 → Datadog (서버·DB·네트워크 한눈에)
- AWS 올인 → CloudWatch (Lambda·EC2·RDS 통합)
핵심 특징
Sentry는 에러 추적 및 모니터링 플랫폼입니다. 주요 기능:
- 에러 추적: 실시간 에러 감지·알림 (Slack, PagerDuty)
- 성능 모니터링: APM·트랜잭션 추적 (느린 API 발견)
- Source Maps: 원본 코드 위치·변수 값 복원
- Session Replay: 에러 직전 사용자 행동 비디오 재생
- Release Tracking: 배포별 에러율·회귀 추적
에러 감지 범위:
- 프론트엔드: React, Vue, Angular 등
- 백엔드: Node.js, Python, Go, Java 등
- 모바일: iOS, Android
- 게임: Unity, Unreal Engine
2. 설치 및 설정
Next.js
npx @sentry/wizard@latest -i nextjs수동 설정
// sentry.client.config.ts
import * as Sentry from '@sentry/nextjs';
Sentry.init({
dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
tracesSampleRate: 1.0,
debug: false,
replaysOnErrorSampleRate: 1.0,
replaysSessionSampleRate: 0.1,
integrations: [
new Sentry.Replay({
maskAllText: true,
blockAllMedia: true,
}),
],
});3. 에러 추적
자동 에러 캡처
// 자동으로 캡처됨
throw new Error('Something went wrong');
// Promise rejection
Promise.reject('Failed');수동 에러 캡처
import * as Sentry from '@sentry/nextjs';
try {
riskyOperation();
} catch (error) {
Sentry.captureException(error);
}
// 메시지만 전송
Sentry.captureMessage('Something important happened', 'info');Context 추가
Sentry.setUser({
id: user.id,
email: user.email,
username: user.name,
});
Sentry.setTag('page', 'checkout');
Sentry.setContext('order', {
orderId: '12345',
amount: 99.99,
});
Sentry.captureException(error);4. 성능 모니터링
Transaction
import * as Sentry from '@sentry/nextjs';
const transaction = Sentry.startTransaction({
name: 'Checkout Process',
op: 'checkout',
});
try {
const span1 = transaction.startChild({ op: 'validate' });
await validateOrder();
span1.finish();
const span2 = transaction.startChild({ op: 'payment' });
await processPayment();
span2.finish();
transaction.setStatus('ok');
} catch (error) {
transaction.setStatus('error');
Sentry.captureException(error);
} finally {
transaction.finish();
}자동 성능 추적
// Next.js는 자동으로 추적됨
// - 페이지 로드
// - API 요청
// - 데이터베이스 쿼리5. Source Maps
Next.js
// next.config.js
const { withSentryConfig } = require('@sentry/nextjs');
module.exports = withSentryConfig(
{
// Next.js config
},
{
silent: true,
org: 'your-org',
project: 'your-project',
}
);빌드 시 업로드
npm run build6. 알림 설정
Slack 통합
- Sentry → Settings → Integrations → Slack
- 채널 선택
- Alert Rules 설정
Alert Rules
# 조건
- 에러 발생 시
- 특정 에러 타입
- 특정 환경 (production)
- 특정 사용자
# 액션
- Slack 알림
- Email 발송
- Webhook 호출7. Release Tracking
배포 추적
// sentry.client.config.ts
Sentry.init({
dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
release: process.env.NEXT_PUBLIC_SENTRY_RELEASE,
environment: process.env.NODE_ENV,
});CI/CD
# .github/workflows/deploy.yml
- name: Create Sentry release
uses: getsentry/action-release@v1
env:
SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }}
SENTRY_ORG: your-org
SENTRY_PROJECT: your-project
with:
environment: production정리 및 체크리스트
핵심 요약
- Sentry: 에러 추적 플랫폼
- 실시간 알림: 즉각적인 대응
- 성능 모니터링: APM
- Source Maps: 원본 코드 추적
- Release Tracking: 배포 추적
- 통합: Slack, Email
구현 체크리스트
- Sentry 설치
- DSN 설정
- 에러 추적 구현
- Context 추가
- 성능 모니터링 설정
- Source Maps 업로드
- 알림 설정
같이 보면 좋은 글
- Prometheus & Grafana 가이드
- AWS Lambda 완벽 가이드
- Kubernetes 실전 가이드
이 글에서 다루는 키워드
Sentry, Error Tracking, Monitoring, Performance, DevOps, Logging, APM
내부 동작과 핵심 메커니즘
이 글의 주제는 「Sentry 완벽 가이드 | 에러 추적·모니터링·성능·알림·실전 활용」입니다. 여기서는 앞선 설명을 구현·런타임 관점에서 한 번 더 압축합니다. 구성 요소 간 책임 분리와 관측 가능한 지점을 기준으로 생각하면, “입력이 어디서 검증되고, 핵심 연산이 어디서 일어나며, 부작용(I/O·네트워크·디스크)이 어디서 터지는가”가 한눈에 드러납니다.
처리 파이프라인(개념도)
flowchart TD A[입력·요청·이벤트] --> B[파싱·검증·디코딩] B --> C[핵심 연산·상태 전이] C --> D[부작용: I/O·네트워크·동시성] D --> E[결과·관측·저장]
알고리즘·프로토콜 관점에서의 체크포인트
- 불변 조건(Invariant): 각 단계가 만족해야 하는 조건(예: 버퍼 경계, 프로토콜 상태, 트랜잭션 격리)을 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
- 결정성: 동일 입력에 동일 출력이 보장되는 순수한 층과, 시간·네트워크에 의해 달라질 수 있는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
- 경계 비용: 직렬화/역직렬화, 문자 인코딩, syscall 횟수, 락 경합처럼 “한 번의 호출이 아니라 누적되는 비용”을 의심 목록에 넣습니다.
프로덕션 운영 패턴
실서비스에서는 기능 구현과 함께 관측·배포·보안·비용이 동시에 요구됩니다. 아래는 팀에서 자주 쓰는 최소 체크리스트입니다.
| 영역 | 운영 관점에서의 질문 |
|---|---|
| 관측성 | 요청 단위 상관 ID, 에러율/지연 분위수, 주요 의존성 타임아웃이 보이는가 |
| 안전성 | 입력 검증·권한·비밀 관리가 코드 경로마다 일관적인가 |
| 신뢰성 | 재시도는 멱등한 연산에만 적용되는가, 서킷 브레이커·백오프가 있는가 |
| 성능 | 캐시 계층·배치 크기·풀링·백프레셔가 데이터 규모에 맞는가 |
| 배포 | 롤백 룬북, 카나리, 마이그레이션 호환성이 문서화되어 있는가 |
운영 환경에서는 “개발자 PC에서는 재현되지 않던 문제”가 시간·부하·데이터 크기 때문에 드러납니다. 따라서 스테이징의 데이터 양·네트워크 지연을 가능한 한 현실에 가깝게 맞추는 것이 중요합니다.
문제 해결(Troubleshooting)
| 증상 | 가능 원인 | 조치 |
|---|---|---|
| 간헐적 실패 | 레이스 컨디션, 타임아웃, 외부 의존성 불안정 | 최소 재현 스크립트 작성, 분산 트레이스·로그 상관관계 확인 |
| 성능 저하 | N+1 쿼리, 동기 I/O, 잠금 경합, 과도한 직렬화 | 프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거 |
| 메모리 증가 | 캐시 무제한, 클로저/이벤트 구독 누수, 대용량 객체의 불필요한 복사 | 상한·TTL·스냅샷 비교(힙 덤프/트레이스) |
| 빌드·배포만 실패 | 환경 변수·권한·플랫폼 차이 | CI 로그와 로컬 diff, 컨테이너/런타임 버전 핀(pin) |
권장 디버깅 순서: (1) 최소 재현 만들기 (2) 최근 변경 범위 좁히기 (3) 의존성·환경 변수 차이 확인 (4) 관측 데이터로 가설 검증 (5) 수정 후 회귀·부하 테스트.
자주 묻는 질문 (FAQ)
Q. 무료로 사용할 수 있나요?
A. 네, 무료 플랜이 있습니다. 5K 에러/월까지 무료입니다.
Q. 모든 프레임워크를 지원하나요?
A. 네, JavaScript, Python, Go, Java 등 대부분의 언어와 프레임워크를 지원합니다.
Q. 개인정보가 걱정돼요
A. 민감한 데이터는 자동으로 마스킹됩니다. 추가 설정도 가능합니다.
Q. 프로덕션에서 사용해도 되나요?
A. 네, 수많은 기업에서 필수로 사용하고 있습니다.