Sentry 완벽 가이드, 에러 추적부터 성능 모니터링까지

 

SENTRY OBSERVABILITY GUIDE

Sentry 완벽 가이드:
에러 추적부터 성능 모니터링까지

React, ASP.NET Core, API 서버 환경에서 Sentry를 활용해 운영 장애, 성능 병목, 사용자 오류 흐름, Source Map, Session Replay, 샘플링 전략까지 정리한 실무 중심 가이드입니다.

대상 Frontend · Backend

핵심 Error · Tracing · Replay

운영 Release · Sampling · Security

Official Docs Style Sentry

Observability Error Monitoring · Performance · Source Map · Replay

Introduction

1. Sentry는 무엇인가

Sentry는 애플리케이션에서 발생하는 오류와 성능 문제를 개발자가 빠르게 분석할 수 있도록 도와주는 관측성 플랫폼입니다. 단순히 로그를 저장하는 수준이 아니라, 어떤 사용자에게, 어떤 화면에서, 어떤 릴리스 이후, 어떤 코드 라인에서 문제가 발생했는지 추적할 수 있습니다.

전통적인 서버 모니터링이 CPU, 메모리, 디스크, 네트워크 같은 인프라 상태를 보는 데 집중했다면, Sentry는 실제 애플리케이션 코드와 사용자 경험에 더 가깝습니다. 프론트엔드 런타임 오류, API 실패, 느린 요청, 소스맵 기반 원본 코드 추적, 세션 리플레이 등을 통해 운영 장애 대응 속도를 높일 수 있습니다.

01

에러 추적

Unhandled Exception, API 실패, 런타임 오류를 자동 수집합니다.

02

성능 분석

트랜잭션, 스팬, 느린 API, DB 병목을 추적합니다.

03

릴리스 관리

특정 배포 이후 오류가 증가했는지 확인할 수 있습니다.

04

사용자 경험

세션 리플레이로 실제 사용자가 겪은 흐름을 재현합니다.

Architecture

2. Sentry 내부 아키텍처 흐름

Sentry는 SDK에서 전송된 이벤트를 바로 저장하지 않고 여러 처리 단계를 거칩니다. 대표적으로 SDK, Relay, Kafka, Ingest Consumer, Symbolicator, Snuba, ClickHouse가 이벤트 수집과 분석 과정에 관여합니다.

SDK

브라우저, 모바일, 서버 런타임에서 에러와 성능 이벤트를 수집합니다.

Relay

DSN 검증, 할당량 체크, 샘플링, 이벤트 필터링을 수행합니다.

Kafka

대량 이벤트를 비동기 스트리밍 방식으로 안정적으로 전달합니다.

Symbolicator

난독화된 스택 트레이스를 원본 소스 코드 라인으로 복원합니다.

Snuba / ClickHouse

이벤트 검색, 집계, 대시보드 분석을 위한 데이터를 저장합니다.

실무 핵심

Sentry는 인프라 전체를 보는 도구라기보다 애플리케이션 코드와 사용자 경험 중심의 모니터링 도구입니다. 서버 자원 모니터링은 Prometheus, Grafana, Datadog 등과 함께 구성하는 방식이 안정적입니다.

Frontend

3. React 프론트엔드 적용 방법

React에서는 애플리케이션 진입점에서 Sentry를 초기화하고, Error Boundary, Browser Tracing, Session Replay를 함께 구성하는 방식이 일반적입니다. 운영 환경에서는 성능 트레이스 수집 비율을 낮게 설정하여 비용과 노이즈를 줄여야 합니다.

React / Vite 기본 적용 예시

import * as Sentry from "@sentry/react";

Sentry.init({
  dsn: import.meta.env.VITE_SENTRY_DSN,
  environment: import.meta.env.MODE,
  release: `frontend@${import.meta.env.VITE_APP_VERSION}`,

  integrations: [
    Sentry.browserTracingIntegration(),
    Sentry.replayIntegration()
  ],

  sampleRate: 1.0,
  tracesSampleRate: import.meta.env.MODE === "production" ? 0.05 : 1.0,

  replaysSessionSampleRate: 0.0,
  replaysOnErrorSampleRate: 1.0,

  beforeSend(SENTRY_event) {
    if (SENTRY_event.user) {
      delete SENTRY_event.user.email;
      delete SENTRY_event.user.ip_address;
    }

    if (SENTRY_event.request && SENTRY_event.request.headers) {
      delete SENTRY_event.request.headers.authorization;
      delete SENTRY_event.request.headers.cookie;
    }

    return SENTRY_event;
  }
});

API 오류 수집 전략

프론트엔드에서 API 오류를 단순히 콘솔에만 출력하면 운영 환경에서 원인 파악이 어렵습니다. Axios 인터셉터를 사용하면 API 실패 정보를 일관된 방식으로 Sentry에 전송할 수 있습니다.

Axios Interceptor 예시

import axios from "axios";
import * as Sentry from "@sentry/react";

const SENTRY_apiClient = axios.create({
  baseURL: "/api",
  timeout: 10000
});

SENTRY_apiClient.interceptors.response.use(
  function SENTRY_onSuccess(SENTRY_response) {
    return SENTRY_response;
  },
  function SENTRY_onError(SENTRY_error) {
    const SENTRY_status = SENTRY_error.response?.status || "NETWORK";
    const SENTRY_method = SENTRY_error.config?.method || "UNKNOWN";
    const SENTRY_url = SENTRY_error.config?.url || "UNKNOWN";

    Sentry.withScope(function SENTRY_scopeHandler(SENTRY_scope) {
      SENTRY_scope.setTag("api.status", String(SENTRY_status));
      SENTRY_scope.setTag("api.method", SENTRY_method.toUpperCase());
      SENTRY_scope.setTag("api.url", SENTRY_url);

      SENTRY_scope.setFingerprint([
        "api-error",
        SENTRY_method,
        String(SENTRY_status),
        SENTRY_url
      ]);

      Sentry.captureException(SENTRY_error);
    });

    return Promise.reject(SENTRY_error);
  }
);

export default SENTRY_apiClient;

Backend

4. ASP.NET Core 백엔드 적용 방법

백엔드에서는 Unhandled Exception, 요청 처리 시간, 외부 API 호출 실패, DB 쿼리 병목을 함께 추적하는 것이 중요합니다. 특히 운영 서버에서는 개인정보 전송 여부와 샘플링 비율을 명확하게 통제해야 합니다.

ASP.NET Core Program.cs 예시

var SENTRY_builder = WebApplication.CreateBuilder(args);

SENTRY_builder.WebHost.UseSentry(SENTRY_options =>
{
    SENTRY_options.Dsn = SENTRY_builder.Configuration["Sentry:Dsn"];
    SENTRY_options.Environment = SENTRY_builder.Environment.EnvironmentName;
    SENTRY_options.Release = "backend@1.0.0";

    SENTRY_options.TracesSampleRate =
        SENTRY_builder.Environment.IsProduction() ? 0.05 : 1.0;

    SENTRY_options.SendDefaultPii = false;

    SENTRY_options.BeforeSend = SENTRY_event =>
    {
        if (SENTRY_event.User != null)
        {
            SENTRY_event.User.Email = null;
            SENTRY_event.User.IpAddress = null;
        }

        return SENTRY_event;
    };
});

var SENTRY_app = SENTRY_builder.Build();

SENTRY_app.MapGet("/", () => "Sentry backend monitoring ready.");

SENTRY_app.Run();

SDK Options

5. Sentry 주요 옵션과 편리 기능 정리

Sentry를 단순히 설치만 하면 운영 환경에서 원하는 수준의 관측성을 얻기 어렵습니다. 실제 서비스에서는 어떤 데이터를 수집할지, 얼마나 수집할지, 어떤 정보는 제거할지, 어떤 오류는 무시할지를 명확하게 설정해야 합니다.

5-1. 기본 식별 옵션

옵션	역할	실무 권장값
dsn	Sentry 프로젝트로 이벤트를 전송하기 위한 고유 주소입니다.	환경변수로 관리하고 코드에 직접 하드코딩하지 않는 것이 좋습니다.
environment	production, staging, development 같은 실행 환경을 구분합니다.	운영, 테스트, 개발 환경을 반드시 분리합니다.
release	어떤 버전에서 오류가 발생했는지 추적합니다.	frontend@1.0.0, backend@2026.04.26처럼 명확히 지정합니다.
dist	같은 release 안에서 빌드 산출물을 더 세분화합니다.	모바일 빌드 번호, 웹 빌드 번호, CDN 배포 번호 구분에 사용합니다.

실무 팁

release 값을 지정하지 않으면 이번 배포 이후 오류가 늘었는지 추적하기 어렵습니다. 운영 배포 자동화에서는 Git Commit SHA, Git Tag, 빌드 번호 중 하나를 release 값으로 넣는 것이 좋습니다.

5-2. 에러 수집과 필터링 옵션

옵션	역할	주의사항
sampleRate	에러 이벤트를 몇 % 수집할지 결정합니다.	운영 초기에는 1.0을 권장합니다. 너무 낮추면 중요한 장애를 놓칠 수 있습니다.
ignoreErrors	특정 에러 메시지를 무시합니다.	브라우저 확장 프로그램 오류, 외부 스크립트 오류 제외에 유용합니다.
denyUrls	특정 URL에서 발생한 오류를 무시합니다.	광고 스크립트, 브라우저 플러그인, 외부 위젯 오류 제외에 사용합니다.
allowUrls	허용한 URL에서 발생한 오류만 수집합니다.	자사 도메인 오류만 보고 싶을 때 사용합니다.
beforeSend	이벤트 전송 직전에 데이터를 수정하거나 폐기합니다.	개인정보 제거, 특정 오류 무시, 토큰 삭제에 가장 많이 사용됩니다.

에러 필터링 옵션 예시

Sentry.init({
  dsn: import.meta.env.VITE_SENTRY_DSN,
  environment: import.meta.env.MODE,
  release: `frontend@${import.meta.env.VITE_APP_VERSION}`,

  sampleRate: 1.0,

  ignoreErrors: [
    "ResizeObserver loop limit exceeded",
    "Non-Error promise rejection captured",
    "Network Error"
  ],

  denyUrls: [
    /extensions\//i,
    /^chrome:\/\//i,
    /^moz-extension:\/\//i,
    /googleads/i,
    /doubleclick/i
  ],

  beforeSend(SENTRY_event, SENTRY_hint) {
    if (SENTRY_event.user) {
      delete SENTRY_event.user.email;
      delete SENTRY_event.user.ip_address;
    }

    if (SENTRY_event.request && SENTRY_event.request.headers) {
      delete SENTRY_event.request.headers.authorization;
      delete SENTRY_event.request.headers.cookie;
      delete SENTRY_event.request.headers["x-api-key"];
    }

    const SENTRY_errorMessage = SENTRY_hint.originalException?.message || "";

    if (SENTRY_errorMessage.includes("사용자가 직접 취소한 요청")) {
      return null;
    }

    return SENTRY_event;
  }
});

5-3. 성능 모니터링 옵션

Sentry의 성능 모니터링은 트랜잭션과 스팬을 통해 화면 로딩, API 요청, DB 처리, 외부 서비스 호출 시간을 추적합니다. 단, 모든 트랜잭션을 100% 수집하면 비용과 노이즈가 빠르게 증가할 수 있으므로 운영 환경에서는 샘플링 전략이 중요합니다.

옵션	역할	권장 사용 방식
tracesSampleRate	성능 트랜잭션 수집 비율을 설정합니다.	운영 환경에서는 0.05 ~ 0.1부터 시작합니다.
tracesSampler	요청 조건에 따라 동적으로 수집 비율을 결정합니다.	결제, 로그인, 주문 같은 핵심 기능은 높게 수집하고 일반 페이지는 낮게 수집합니다.
beforeSendTransaction	트랜잭션 전송 직전에 데이터를 수정하거나 폐기합니다.	health check, static resource 요청을 제외할 때 유용합니다.

동적 트레이싱 샘플링 예시

Sentry.init({
  dsn: import.meta.env.VITE_SENTRY_DSN,

  integrations: [
    Sentry.browserTracingIntegration()
  ],

  tracesSampler(SENTRY_samplingContext) {
    const SENTRY_transactionName = SENTRY_samplingContext.name || "";

    if (
      SENTRY_transactionName.includes("/payment") ||
      SENTRY_transactionName.includes("/login") ||
      SENTRY_transactionName.includes("/order")
    ) {
      return 0.5;
    }

    if (SENTRY_transactionName.includes("/admin")) {
      return 0.2;
    }

    return 0.05;
  },

  beforeSendTransaction(SENTRY_transaction) {
    if (
      SENTRY_transaction.transaction === "/health" ||
      SENTRY_transaction.transaction === "/ping"
    ) {
      return null;
    }

    return SENTRY_transaction;
  }
});

주의

tracesSampleRate: 1.0은 모든 성능 이벤트를 수집한다는 의미입니다. 트래픽이 많은 서비스에서 무심코 1.0으로 배포하면 사용량과 비용이 빠르게 증가할 수 있습니다.

5-4. Session Replay 옵션

Session Replay는 사용자가 오류를 만나기 전후에 어떤 화면을 보고, 어떤 버튼을 누르고, 어떤 네트워크 요청이 실패했는지 재현하는 기능입니다. 텍스트 로그만으로 재현하기 어려운 UI 오류를 분석할 때 매우 유용합니다.

옵션	역할	권장값
replaysSessionSampleRate	일반 사용자 세션을 몇 % 녹화할지 결정합니다.	운영에서는 0.01 ~ 0.05 또는 0.0부터 시작합니다.
replaysOnErrorSampleRate	오류가 발생한 세션을 몇 % 보관할지 결정합니다.	오류 분석 목적이라면 1.0 권장
maskAllText	화면의 모든 텍스트를 마스킹합니다.	개인정보가 많은 서비스라면 활성화 권장
blockAllMedia	이미지, 영상 같은 미디어 노출을 차단합니다.	사용자 이미지나 민감 자료가 있다면 활성화 권장

Session Replay 개인정보 보호 예시

Sentry.init({
  dsn: import.meta.env.VITE_SENTRY_DSN,

  integrations: [
    Sentry.replayIntegration({
      maskAllText: true,
      blockAllMedia: true,

      mask: [
        ".password",
        ".token",
        ".phone",
        ".email",
        "[data-private='true']"
      ],

      block: [
        ".payment-card-area",
        ".resident-number-area",
        ".secret-document-area"
      ]
    })
  ],

  replaysSessionSampleRate: 0.0,
  replaysOnErrorSampleRate: 1.0
});

5-5. Breadcrumb 활용

Breadcrumb는 오류가 발생하기 전 사용자가 어떤 행동을 했는지 남기는 작은 로그입니다. 페이지 이동, 버튼 클릭, 콘솔 로그, 네트워크 요청, 사용자 지정 이벤트를 순서대로 확인할 수 있습니다.

Breadcrumb 활용 예시

Sentry.init({
  dsn: import.meta.env.VITE_SENTRY_DSN,

  maxBreadcrumbs: 80,

  beforeBreadcrumb(SENTRY_breadcrumb) {
    if (
      SENTRY_breadcrumb.category === "fetch" ||
      SENTRY_breadcrumb.category === "xhr"
    ) {
      const SENTRY_url = SENTRY_breadcrumb.data?.url || "";

      if (SENTRY_url.includes("/auth/token")) {
        return null;
      }
    }

    return SENTRY_breadcrumb;
  }
});

function SENTRY_onClickOrderButton(SENTRY_orderId) {
  Sentry.addBreadcrumb({
    category: "order",
    message: "사용자가 주문 버튼을 클릭했습니다.",
    level: "info",
    data: {
      orderId: SENTRY_orderId
    }
  });
}

5-6. Tags, Context, User 활용

Sentry에서 장애를 빠르게 찾으려면 이벤트에 부가 정보를 잘 넣어야 합니다. tag는 검색과 필터링에 좋고, context는 상세 분석에 좋으며, user는 영향받은 사용자 범위를 파악할 때 유용합니다.

기능	용도	추천 데이터
setTag	검색과 필터링에 사용할 짧은 값	화면명, API명, 고객사코드, 기능구분, 배포채널
setContext	상세 분석용 객체 데이터	주문 상태, 장바구니 상태, 서버 응답 요약
setUser	영향받은 사용자 식별	내부 사용자 ID. 이메일, 전화번호는 신중히 처리
setExtra	추가 디버깅 데이터	임시 상태값, 계산 결과, 조건 분기 정보

Tags / Context / User 예시

function SENTRY_setMonitoringContext(SENTRY_loginUser) {
  Sentry.setUser({
    id: SENTRY_loginUser.userId,
    username: SENTRY_loginUser.userName
  });

  Sentry.setTag("company.code", SENTRY_loginUser.companyCode);
  Sentry.setTag("system.name", "IAMZ-BIZ");
  Sentry.setTag("screen.name", "OrderCreatePage");

  Sentry.setContext("business", {
    module: "order",
    feature: "create-order",
    permission: SENTRY_loginUser.permissionName
  });
}

function SENTRY_captureOrderError(SENTRY_error, SENTRY_order) {
  Sentry.withScope(function (SENTRY_scope) {
    SENTRY_scope.setTag("order.status", SENTRY_order.status);
    SENTRY_scope.setContext("order", {
      orderId: SENTRY_order.orderId,
      itemCount: SENTRY_order.items.length,
      totalAmount: SENTRY_order.totalAmount
    });

    Sentry.captureException(SENTRY_error);
  });
}

5-7. 수동 캡처 편리 함수

Sentry는 자동 오류 수집뿐 아니라 개발자가 원하는 시점에 직접 메시지, 예외, 트랜잭션 정보를 보낼 수 있습니다. 운영 중 특정 비즈니스 조건이 비정상일 때 수동 캡처를 넣어두면 장애를 더 빨리 찾을 수 있습니다.

수동 캡처 함수 예시

function SENTRY_validateBusinessRule(SENTRY_payload) {
  if (!SENTRY_payload.customerCode) {
    Sentry.withScope(function (SENTRY_scope) {
      SENTRY_scope.setLevel("warning");
      SENTRY_scope.setTag("validation.type", "missing-customer-code");
      SENTRY_scope.setContext("payload", {
        screen: "OrderCreatePage",
        hasItems: SENTRY_payload.items?.length > 0
      });

      Sentry.captureMessage("주문 생성 요청에 고객사 코드가 없습니다.");
    });

    return false;
  }

  return true;
}

async function SENTRY_saveOrder(SENTRY_order) {
  try {
    const SENTRY_response = await fetch("/api/orders", {
      method: "POST",
      body: JSON.stringify(SENTRY_order)
    });

    if (!SENTRY_response.ok) {
      throw new Error("주문 저장 API 실패");
    }
  } catch (SENTRY_error) {
    Sentry.withScope(function (SENTRY_scope) {
      SENTRY_scope.setTag("api.name", "save-order");
      SENTRY_scope.setTag("order.status", SENTRY_order.status);
      SENTRY_scope.setLevel("error");

      Sentry.captureException(SENTRY_error);
    });

    throw SENTRY_error;
  }
}

5-8. 운영 환경 추천 설정 조합

서비스 규모	에러 수집	트레이싱	리플레이
사내 시스템 / 트래픽 낮음	sampleRate: 1.0	tracesSampleRate: 0.2 ~ 1.0	replaysOnErrorSampleRate: 1.0
일반 B2B 서비스	sampleRate: 1.0	tracesSampleRate: 0.05 ~ 0.2	일반 세션 낮게, 오류 세션 높게
대규모 B2C 서비스	sampleRate: 0.5 ~ 1.0	tracesSampler로 동적 제어	핵심 화면 위주로 제한
개인정보 민감 서비스	필수 오류만 수집	낮은 비율부터 시작	마스킹, 블록 처리 필수

실무 결론

Sentry 옵션 설정의 핵심은 많이 수집하는 것이 아니라 장애 대응에 필요한 데이터를 안전하게 수집하는 것입니다. 운영 환경에서는 에러는 놓치지 않되, 트레이싱과 리플레이는 비용·보안·노이즈를 고려해 점진적으로 확대하는 전략이 좋습니다.

Source Maps

6. 소스맵과 릴리스 관리

프론트엔드 코드는 운영 배포 시 압축되고 난독화됩니다. 이 상태에서 오류가 발생하면 스택 트레이스가 실제 원본 코드와 다르게 보일 수 있습니다. 이를 해결하려면 빌드 시점에 Source Map을 생성하고 Sentry에 업로드해야 합니다.

보안 주의

Source Map은 원본 코드 구조를 노출할 수 있으므로 운영 서버 public 경로에 그대로 남기지 않는 것이 좋습니다. Sentry에 업로드한 뒤 삭제하거나 .map 파일 접근을 차단해야 합니다.

Vite Source Map 업로드 예시

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import { sentryVitePlugin } from "@sentry/vite-plugin";

export default defineConfig({
  build: {
    sourcemap: "hidden"
  },
  plugins: [
    react(),

    sentryVitePlugin({
      org: "YOUR_ORG_SLUG",
      project: "YOUR_PROJECT_SLUG",
      authToken: process.env.SENTRY_AUTH_TOKEN,

      sourcemaps: {
        filesToDeleteAfterUpload: [
          "./dist/**/*.map"
        ]
      }
    })
  ]
});

릴리스 관리 체크리스트

• 프론트엔드와 백엔드 release 값을 명확히 지정합니다.
• production, staging, development environment 값을 분리합니다.
• CI/CD의 SENTRY_AUTH_TOKEN은 Secret으로 관리합니다.
• Source Map은 Sentry 업로드 후 public 배포 경로에서 제거합니다.
• 배포 직후 Release 화면에서 신규 오류 증가 여부를 확인합니다.

Tracing

7. 분산 트레이싱과 성능 모니터링

Sentry의 성능 모니터링은 요청 하나를 Transaction으로 보고, 그 안에서 발생하는 API 호출, DB 쿼리, 외부 서비스 호출, 렌더링 작업을 Span 단위로 분석합니다.

지표	의미	실무 활용
Apdex	사용자 만족도를 0~1 점수로 표현	서비스 전체 체감 품질 판단
p95 / p99	상위 5% 또는 1% 사용자가 겪는 느린 응답	일부 사용자만 겪는 병목 추적
Throughput	분당 또는 초당 요청 처리량	트래픽 급증과 장애 상관관계 분석
Error Rate	전체 요청 중 실패 비율	배포 후 장애 증가 여부 확인

Security & Cost

8. 도입 시 주의사항: 보안, 비용, 알림

개인정보와 민감정보 제거

Sentry 이벤트에는 요청 정보, 사용자 정보, 브라우저 정보, 서버 컨텍스트가 포함될 수 있습니다. 이메일, IP, 인증 토큰, 쿠키, 비밀번호, 결제 정보는 전송 전 또는 저장 전 단계에서 반드시 제거해야 합니다.

Client

beforeSend

전송 전 user, request, headers, extra 데이터를 정리합니다.

Server

Data Scrubbing

Sentry 프로젝트 설정에서 저장 전 마스킹 규칙을 적용합니다.

Alert

Allowlist

Slack, Email, Webhook에는 필요한 최소 정보만 전달합니다.

샘플링 전략

모든 성능 데이터를 100% 수집하면 비용과 노이즈가 빠르게 증가할 수 있습니다. 일반적으로 에러 이벤트는 최대한 놓치지 않도록 유지하고, 성능 트랜잭션과 세션 리플레이는 낮은 비율부터 시작하는 것이 안전합니다.

에러 이벤트 sampleRate: 1.0

운영 초기에는 중요 장애를 놓치지 않도록 100% 수집 권장

성능 트레이스 tracesSampleRate: 0.05 ~ 0.1

트래픽이 많은 서비스는 낮은 비율부터 시작

세션 리플레이 replaysOnErrorSampleRate: 1.0

일반 세션은 낮게, 오류 발생 세션은 높게 설정

FAQ

9. 자주 묻는 질문

Sentry는 로그 수집 도구와 무엇이 다른가요?

일반 로그 수집 도구는 서버나 애플리케이션 로그를 저장하고 검색하는 데 강점이 있습니다. Sentry는 오류 이벤트를 코드 라인, 릴리스, 사용자 영향도, 성능 트랜잭션과 연결해 분석하는 데 강점이 있습니다.

운영 환경에서 tracesSampleRate를 1.0으로 설정해도 되나요?

트래픽이 적은 내부 시스템이라면 가능하지만, 대규모 서비스에서는 비용과 노이즈가 빠르게 증가할 수 있습니다. 운영 환경에서는 0.05~0.1부터 시작하고, 핵심 기능만 tracesSampler로 높이는 방식을 권장합니다.

Source Map 파일은 서버에 배포해도 되나요?

Source Map은 원본 코드 구조를 노출할 수 있으므로 public 경로에 그대로 두는 것은 권장하지 않습니다. Sentry에 업로드한 후 삭제하거나, 웹 서버에서 .map 파일 접근을 차단하는 방식이 안전합니다.

Session Replay는 개인정보 문제가 없나요?

설정에 따라 화면 텍스트, 입력값, 미디어가 포함될 수 있으므로 개인정보 보호 설정이 필수입니다. maskAllText, blockAllMedia, block, mask 옵션을 활용해 민감 영역을 반드시 보호해야 합니다.

Conclusion

10. 마무리

Sentry를 잘 도입하면 장애 대응 방식이 바뀝니다. 사용자가 오류를 제보한 뒤 로그를 뒤지는 방식에서, 어떤 사용자에게 어떤 화면에서 어떤 배포 이후 어떤 코드가 문제였는지 먼저 확인하고 대응하는 방식으로 전환할 수 있습니다.

다만 Sentry는 설치만으로 끝나는 도구가 아닙니다. 릴리스 관리, Source Map 자동화, 개인정보 제거, 샘플링 정책, 알림 라우팅, 담당자 지정까지 함께 설계해야 운영 환경에서 진짜 가치가 나옵니다.

최종 정리

Sentry는 장애가 발생한 뒤 보는 로그 도구가 아니라, 장애가 사용자 경험에 미치는 영향을 코드와 배포 단위로 연결해주는 관측성 플랫폼입니다.

Sentry 에러모니터링 성능모니터링 APM Observability 프론트엔드 백엔드 React ASP.NETCore SourceMap

References

공식 문서 참고 링크

• Sentry JavaScript SDK Options
• Sentry Session Replay Configuration
• Sentry Vite Source Map Upload
• Sentry ASP.NET Core Options