Sentry React Native: 2026 통합 가이드

당신의 React Native 앱이 로컬에서 작동하고 QA가 승인했으며 프로덕션에 가까워졌을 때, 사용자의 장치에서 깨지면 어떻게 될까?

Sentry가 없다면 일반적으로 나쁜 대답이 나옵니다. 지원 티켓, 모호한 스크린샷, 개발 빌드의 콘솔 로그가 프로덕션과 일치하지 않는 경우가 있습니다. Sentry React Native가 올바르게 설정되면 오류, 스택, 배포한 릴리스, 그리고 오류를 고치기 위한 충분한 컨텍스트를 얻을 수 있습니다. 문제는 기본 설치는 쉬운 부분입니다. 실제로 어려운 부분은 나중에 시작됩니다: 네이티브 통합, symbolication, 소스 맵, 릴리스 이름, 그리고 라이브 업데이트를 포함하는 배포 모델의 경우 모든 것을 일치시키는 것입니다.

Table of Contents

Sentry __CAPGO_KEEP_0__와 함께 시작하기

Getting Started with the Sentry SDK
- 위치 마법사 실행 및 결과 검토
- 네이티브 iOS 및 Android 프로젝트 구성
iOS에서 변경된 점
CI, App Store 빌드, Android 릴리스, 그리고 원본 바이너리에서 항상 오리지널 바이너리가 아닌 JavaScript 번들을 포함하는 경우
성능 데이터 및 사용자 지정 이벤트를 캡처하는 방법
- 화면이 느려질 때 추적하는 대신 추측하지 않기
- 오류에 유용한 정보를 추가하는 방법
통합을 확인하고 문제를 해결하는 방법
라이브 업데이트 워크플로와의 통합 방법 ( Capgo )
- 릴리즈 식별자와 라이브 배ंडल을 매칭하는 방법

SDK에 Sentry를 시작하는 방법

production 환경에서 작동하는 baseline을 빠르게 얻는 가장 빠른 방법은 여전히 설치 마법사입니다. 마법사는 반복적인 설정을 대부분 처리하고, 작동하는 baseline을 빠르게 얻습니다. 이것은 중요합니다. 첫 번째 설치를 수동으로 처리하면, 첫 번째 프로덕션 오류가 발생할 때까지 작은 불일치가 발생할 수 있습니다.

설치하기 전에 필요한 것

React Native 개발 환경이 먼저 필요합니다. Node, 패키지 관리자, iOS 및 Android의 플랫폼 도구, macOS에서 Watchman이 이미 워크플로우의 일부일 경우. 또한 Sentry 계정과 React Native 프로젝트가 필요합니다.

React Native가 팀의 운영 선택이 맞는지 여부를 평가 중이라면 기업용 React Native 가이드 플랫폼의 트레이드 오프, 인력, 유지 보수 예상치에 대한 유용한 비판적 콘텍스트를 제공합니다. monitoring 및 릴리스 프로세스를 공유 코드베이스에 적용하기 전에 읽어보세요.

SDK를 프로젝트 루트에서 마법사로 설치하세요:

npx @sentry/wizard@latest -i reactNative

마법사는 몇 가지 질문을 합니다. 개발자들은 종종 너무 빠르게 클릭합니다:

프로젝트 선택실제로 프로덕션에서 사용할 Sentry 프로젝트를 선택하세요. 나중에 업데이트를忘지지 않도록 임시 샌드박스를 선택하지 마세요.
자연스러운 변경. JavaScript-only 오류 캡처만으로는 모바일 앱을 위한 충분한 수단이 아닙니다.
선택적 기능. 사용할 수 있는 기능을 모두 활성화하지 말고, 팀이 결과 데이터를 검토하지 못할 경우 첫 번째 날에 모든 것을 무작위로 활성화하지 마십시오.

위치 마법사 실행 및 결과 검토

위치 마법사가 완료되면, 결과를 신뢰하지 않고 검토하십시오. Sentry 패키지가 package.json자연스러운 변경 사항이 ios 및 android에 나타나야 합니다. 또한 앱 진입 파일의 초기화 블록이

에 나타나야 합니다.

import * as Sentry from '@sentry/react-native';

Sentry.init({
  dsn: 'YOUR_DSN',
});

일반적인 초기화는 다음과 같습니다. DSN은 __CAPGO_KEEP_0__에서 이벤트를 전송할 위치를 알려줍니다. 이에 대한 설정으로 다루어야 하며, 비밀 보관소 항목으로 다루어서는 안 됩니다. 이는 인증 토큰과 다릅니다. 여전히 환경 설정이 깨끗하고 일관적일 경우 앱이 각 환경에서 올바른 Sentry 프로젝트를 참조하도록 하십시오. tells the SDK where to send events. Treat it as configuration, not as a secret vault item that must never be visible. It isn’t the same as an auth token. Still, keep your environment setup clean and consistent so your app points to the right Sentry project in each environment.

환경 변수에서 DSN을 로드하고 앱 tree가 마운트되기 전에 Sentry를 초기화하는 실용적인 패턴입니다. 시작업 폴리시를 통해 작업하는 경우, 이 React Native 스플래시 스크린 설정 가이드가 유용합니다. 시작업 __CAPGO_KEEP_0__ 순서가 Sentry 초기화 위치와 교차하는 경우가 많기 때문입니다. 실용적인 규칙: is useful because startup code order often intersects with where teams place Sentry initialization.

이 단계에서는 완벽함을 추구하지 마세요. 즉시 목표는 간단합니다: 앱을 출시하고 나중에 이 문서에서 설명하는 JavaScript 예외를 트리거하고, 이벤트가 Sentry로 도달하는지 확인하세요. 그게 작동되면, 네이티브 및 릴리스层가 더 쉬운 논리를 제공합니다. 네이티브 iOS 및 Android 프로젝트 구성

이 단계에서 많은 React Native 팀이 완전성을 착각합니다. JavaScript __CAPGO_KEEP_0__가 설치되어 이벤트가 표시되고, 모든人が 충돌 보고가 완료된 것으로 생각합니다. 그러나 그렇지 않습니다. 네이티브 통합이 꺼져 있으면, 가장 중요하게 생각하는 충돌이 Sentry에서 사용할 수 있는 형태로 도달하지 못할 것입니다.

iOS에서 변경된 점

At this stage, many React Native teams get a false sense of completion. The JavaScript SDK is installed, events show up, and everyone assumes crash reporting is done. It isn’t. If native integration is off, some of the crashes you care about most will never reach Sentry in a usable form.

Xcode에서 다음 위치를 확인하세요:

앱 데리케이션 시작업 __CAPGO_KEEP_0__']}

targetLanguage

App delegate startup code. 앱이 초기 런칭 시에 네이티브 센트리 초기화를 필요로 합니다.
빌드 단계. 디버그 SYMBOL 또는 소스 맵 처리 관련된 센트리 업로드 스크립트를 찾으세요.
빌드 설정 및 아카이브 동작. Symbol 파일이 생성되고 아카이브 빌드 시에 사용 가능해야 합니다.

앱이 AppDelegate.mm를 사용한다면, 초기화는 종종 React Native 브리지 부트스트래핑과 근접합니다. 정확한 파일 내용은 React Native 버전, 템플릿 및 새로운 아키텍처 사용 여부에 따라 달라질 수 있으므로, 프로젝트 형태와 일치하는 랜덤 리포지토리에서 Snippet을 복사하지 마세요.

iOS 네이티브 크래시에서 Symbol 데이터가 필요하고 앱은 크래시가 신뢰할 수 있게 관찰되기 전에 센트리를 시작해야 합니다.

iOS 크래시가 센트리에 표시되며 읽을 수 없는 네이티브 프레임이 있다면, 일반적으로 문제는 “센트리가 깨진다.”가 아닙니다. Symbol 업로드 또는 릴리즈 매칭이 문제입니다.

Android에서 변경된 사항은?

Android는 일반적으로 Gradle 파일의 변경과 때로는 매니페스트 수준의 구성 변경을 포함합니다. android/build.gradle, android/app/build.gradle를 검토하고 센트리 관련 플러그인 또는 태스크와 관련된 wiring을 확인하세요.

Things to verify:

Sentry Gradle 플러그인은 적용되어 빌드 시간에 릴리즈 아티팩트가 처리될 수 있습니다.
품목 플래버 또는 여러 빌드 타입을 사용하는 경우 변형 처리가 정상입니다. ProGuard 또는 R8의 출력이 __CAPGO_KEEP_0__을 축소하거나 암호화하는 릴리즈 빌드에 고려됩니다.
로컬 디버그 실행이 성공적이라고 가정하는 안드로이드의 일반적인 실수는 릴리즈 설정이 올바른지 증명한다는 것입니다. 그것은 그렇지 않습니다. 릴리즈 경로는 minification 및 CI 서명이 포함된 경우 특히 다릅니다. 팀이 별도의 디버그, 스테이징, QA, 및 스토어 빌드를 유지한다면 if your release builds shrink or obfuscate code.

이 각 빌드 변형에 맞춰 모니터링 동작을 일치시키기 위한 유용한 참고 자료입니다. 나중에 시간을 절약하는 데 도움이 되는 네이티브 설정 확인 '마법사 파일을 수정했다'고 말하지 말고 직접 동작을 확인하세요.

Mobile 빌드 타입에 대한 이 분해는

디버그, 스테이징, QA, 및 스토어 빌드를 유지하는 팀에게 유용한 참고 자료입니다.

이 체크리스트를 사용하세요:

iOS 빌드를 로컬로 저장하고 symbol 처리 중에 빌드가 실패하지 않는지 확인하세요. Android 릴리즈 빌드를 생성하세요.
CI 로그를 확인하여 Sentry 관련 작업이 정상적으로 진행되는지 확인하세요. 관리하는 앱이 여러 개일 경우 Sentry에서 패키지 이름과 번들 식별자 매핑을 확인하세요.
릴리즈 이름 규칙을 확인하세요. CI가 불일치하는 이름으로 아티팩트를 업로드하기 전에 릴리즈 이름 규칙을 확인하세요.
일반적으로 잘 작동하지 않는 방법은:방법

문제가 발생하는 부분

__CAPGO_KEEP_0__	__CAPGO_KEEP_0__
__CAPGO_KEEP_0__	React Native 환경이나 빌드 도구가 변경될 때 Native 설정이 변동됩니다.
오로지 디버그 모드에서만 테스트합니다.	디버그 성공은 릴리즈 시 심볼화 문제를 숨깁니다.
수동 및 자동 업로드 단계를 혼용합니다.	아티팩트는 다른 릴리즈 하위에 위치하고 이벤트와 일치하지 않습니다.

최고의 설정은 단조롭습니다. Native 시작 hook이 설정되어 빌드 스크립트가 매번 실행되고, iOS, Android, JavaScript 번들에 대한 릴리즈 이름이 결정적입니다.

릴리즈와 소스맵 자동화

Sentinel React Native 설정이 무너지는 곳은 여기입니다. 팀은 SDK를 설치하고 이벤트를 확인하고 릴리즈 자동화를 미루고, 첫 번째 심각한 프로덕션 문제가 발생하면 스택 트레이스에 미니파이팅이 적용되어 릴리즈가 누락되거나 소스맵 업로드가 다른 번들에 속해있는 경우가 많습니다.

수동 소스맵 업로드는 드물게 배포하는 경우에는 합리적으로 보일 수 있지만, 실제로는 인간이 반복적인 릴리즈 관리를 잘 수행하지 못하기 때문에 실패합니다.

실제로 수동 업로드가 실패하는 이유는

예측 가능한 실패 모드

누군가가 늦은 밤 핫픽스를 업로드하지 않았습니다. 업로드한 파일은 다른 커밋에 속합니다.
바이너리 또는 OTA 배포 사용자가 실행하는 바이너리와의 차이점입니다. iOS, Android, CI 단계에서 릴리스 이름이 약간 다릅니다.
맵 업로드 후 재빌드가 발생하고 Sentry가 매칭해야 하는 대상이 무효화됩니다. 긴급 릴리스가 압박하에 출시될 때까지 'Notion'에서 단계를 문서화하는 방법은 작동합니다.
React Native용 Sentry 릴리스 및 소스맵 관리를 자동화하는 7단계 플로우차트입니다. 실제로 유지되는 릴리스 프로세스입니다.

신뢰할 수 있는 설정에는 몇 가지 특성이 있습니다:

__CAPGO_KEEP_0__

Release ID는 한 번 생성되고 어디서든 재사용됩니다. 빌드, 번들, 업로드 단계는 동일한 pipeline에서 발생합니다.
소스맵은 CI에서 업로드되며 개발자 노트북에서 업로드되지 않습니다..
앱은 CI가 업로드 시 사용한 동일한 릴리스 문자열로 Sentry를 초기화합니다.그 마지막 점은 일반적으로 예상되는 것보다 더 중요합니다. Sentry에 소스맵만 필요하지 않습니다. 앱이 런타임에 내보내는 정확한 릴리스 식별자와 연결된 올바른 소스맵이 필요합니다.
팀이 이미 모바일 자동화에 표준화했다면, 이 __CAPGO_KEEP_0__ Actions를 사용하는 자동 빌드 및 릴리스 워크플로 가이드는 동일한 운영 모델에 잘 맞습니다. 이 가이드는 __CAPGO_KEEP_0__ Actions를 사용하여 자동 빌드 및 릴리스 워크플로를 구축하는 방법에 대한 안내서입니다.

이 가이드는 __CAPGO_KEEP_0__ Actions를 사용하여 자동 빌드 및 릴리스 워크플로를 구축하는 방법에 대한 안내서입니다. 이 가이드는 __CAPGO_KEEP_0__ Actions를 사용하여 자동 빌드 및 릴리스 워크플로를 구축하는 방법에 대한 안내서입니다..

이 가이드는 __CAPGO_KEEP_0__ Actions를 사용하여 자동 빌드 및 릴리스 워크플로를 구축하는 방법에 대한 안내서입니다. 이 가이드는 GitHub Actions를 사용하여 자동 빌드 및 릴리스 워크플로를 구축하는 방법에 대한 안내서입니다. 이 가이드는 __CAPGO_KEEP_0__ Actions를 사용하여 자동 빌드 및 릴리스 워크플로를 구축하는 방법에 대한 안내서입니다.

실용적인 CI 스크립트 패턴

CI에서 스크립트를 사용하여 pipeline 환경에서 값들을 제공하세요.

#!/usr/bin/env bash
set -euo pipefail

export SENTRY_AUTH_TOKEN="$SENTRY_AUTH_TOKEN"
export SENTRY_ORG="your-org"
export SENTRY_PROJECT="your-project"

RELEASE_NAME="${APP_VERSION}+${GIT_SHA}"

npx sentry-cli releases new "$RELEASE_NAME"

npx react-native bundle \
  --platform ios \
  --dev false \
  --entry-file index.js \
  --bundle-output ./dist/main.jsbundle \
  --sourcemap-output ./dist/main.jsbundle.map

npx sentry-cli releases files "$RELEASE_NAME" upload-sourcemaps ./dist \
  --rewrite \
  --strip-prefix "$(pwd)"

npx sentry-cli releases finalize "$RELEASE_NAME"

Android용 배포 명령어를 적절히 조정하고, 플랫폼별 작업을 분리하는 팀도 많습니다. 그게 괜찮습니다. 중요한 것은 일관성입니다.

Release discipline이 뛰어난 스크립팅보다 중요합니다. CI에서 일관된 이름 규칙을 선택하고 빌드 시에 앱에 삽입하고, 로컬의 임시 업로드와 CI를 경쟁시키지 마세요.

React Native의 경우, 빌드 시에 생성된 __CAPGO_KEEP_0__ 위치에 릴리스 문자열을 저장하고, __CAPGO_KEEP_1__를 읽어들이는 것을 선호합니다. Sentry.init():

Sentry.init({
  dsn: Config.SENTRY_DSN,
  release: Config.SENTRY_RELEASE,
  dist: Config.SENTRY_DIST,
});

결과는 간단합니다. 이벤트가 도착하면 Sentry는 미니파이드 프레임을 code로 매핑하고, code로 매핑하지 않습니다.

성능 데이터 및 사용자 정의 이벤트 캡처

크래시가 발생하면 무엇이 깨졌는지 알 수 있습니다. 성능 추적은 사용자가 포기하기 전에 느꼈던 것을 알려줍니다.

일반적인 보고서의 예는 다음과 같습니다. “대시보드가 느립니다.” 하지만 이는 디버깅을 위한 충분한 정보가 아닙니다. 느리게 느껴지는 곳은 어디인가요? 네비게이션 중인가요? 데이터를 가져오는 중인가요? 무거운 차트를 렌더링하는 중인가요? Sentry는 이때 디버깅을 위해 에러 인박스 대신 앱 동작을 인스트루먼트할 때 유용합니다.

소프트웨어 개발자가 데이터 시각화 그래프가 배경 모니터에 표시된 상태로 노트북에 코딩하는 모습입니다.

느린 화면을 추적하는 대신 추측하지 마세요.

__CAPGO_KEEP_0__를 활성화하여 초기화 단계에서 성능 추적을 시작하세요. 정확한 샘플링 전략은 환경과 볼륨 용량에 따라 달라지지만 구조는 다음과 같습니다.

Sentry.init({
  dsn: Config.SENTRY_DSN,
  tracesSampleRate: 1.0,
});

React Navigation을 사용하는 경우, 화면 전환을 통해 추적 데이터를 생성하도록 통합하세요. 그런 다음 물리 장치에서만 불량을 재현하세요. 시뮬레이터에서는 사용자가 주목하는 느린 성능을 숨깁니다.

실용적인 대시보드 예시:

사용자는 로그인 후 메인 대시보드를 열어보세요.
네비게이션 완료는 하지만 콘텐츠가 늦게 나타납니다.
트레이스에서는 화면 거래가 길다는 것을 보여줍니다.
자식 스팬은 하나의 API 요청과 하나의 비싼 렌더 경로를 드러냅니다.
렌더 경로를 최적화하고 다시 배포한 후, 새로운 트레이스 모양을 비교하세요.

감정에 의한 추측보다 낫습니다.

웹뷰 또는 하이브리드 앱 모니터링 패턴에 대해 넓게 생각하는 팀에게는 Capacitor 프로젝트의 성능 모니터링에 대한 이 글을 읽어보는 것이 가치가 있습니다. 운영 방식의 마음가짐은 비슷하지만 스택은 다르기 때문에.

에러에 유용한 정보를 추가합니다.

성능 데이터가 더 유용해질 때는 이벤트가 비즈니스 컨텍스트를 포함합니다. 그게 자랑하기 위한 metadata가 아니라, 영향을 받은 사용자, 현재 화면, 그리고 실패 직전의 상황을 알 수 있게 해주는 정도입니다.

이 도구들을 의도적으로 사용하세요.

사용자 컨텍스트 with Sentry.setUser() 이러한 도구들을 사용하여 지원팀이 보고서를 사용자 계정과 관련지을 수 있도록 도와줍니다.
액션의 경로를 추적하세요. 예를 들어, 제출 버튼을 탭했을 때, 모달을 열었을 때, 또는 동기화를 시작했을 때. 사용자 플랜 타입, 기능 플래그 상태, 또는 __CAPGO_KEEP_0__ 지역과 같은 차원에 대한 커스텀 태그를 사용하세요.
예외가 발생했을 때 추가적인 정보를 캡처하세요. 예를 들어, 예외를 다시 던지거나 제어된 실패를 노출할 때. API
__CAPGO_KEEP_0__ __CAPGO_KEEP_0__

예시:

Sentry.setUser({
  id: user.id,
  email: user.email,
});

Sentry.addBreadcrumb({
  category: 'navigation',
  message: 'Opened dashboard screen',
  level: 'info',
});

try {
  await loadDashboard();
} catch (error) {
  Sentry.captureException(error, {
    tags: { screen: 'dashboard' },
    extra: { widget: 'balance-summary' },
  });
}

사용자가 앱이 멈췄다고 말하는 것과 앱이 데스크톱을 열고 동기화를 시작하고 다시 실패한 요청을 시도한 후에 실패한 것 사이의 차이점은 종종 트레일이다.

사용자 지정 인스트루먼테이션의 오류는 일반적으로 너무 많은 노이즈로 인해 발생한다. 앱의 모든 버튼 클릭을 영원히 캡처하지 마십시오. 디버깅을 위해 중요할 때만 캡처하십시오. 이벤트를 설명할 수 있는 충분한 컨텍스트. 디버깅을 위해 너무 많은 정보를 제공하지 마십시오.

통합을 확인하고 문제를 해결하는 방법

배송 전에, 빌드 PIPELINE 변경 후, 그리고 SDK 업그레이드 후에 Sentry를 확인해야 합니다. “몇 달 전에는 작동했다”는 것은 의미가 없습니다.

제일 깨끗한 방법은 자바스크립트와 네이티브 경로 모두에 제어된 실패를 트리거하고 Sentry에 도착하는 방법을 검사하는 것입니다.

컴퓨터 모니터에 code를 작성하는 남성 소프트웨어 개발자와 그의 데스크에 있는 테스트 통합 체크리스트.

테스트 이벤트를 안전하게 트리거하는 방법

자바스크립트 오류의 경우, 비프로덕션 화면에 임시 버튼을 추가하십시오.

<Button
  title="Trigger JS Error"
  onPress={() => {
    throw new Error('Test JavaScript Sentry error');
  }}
/>

포착된 예외가 앱을 멈추지 않는 경우:

<Button
  title="Capture Exception"
  onPress={() => {
    Sentry.captureException(new Error('Handled Sentry test error'));
  }}
/>

네이티브 크래시 테스트는 개발 또는 제어된 QA 빌드에서만 수행해야 합니다. SDK 버전과 플랫폼 연결에 따라 사용할 수 있는 정확한 헬퍼 메서드가 달라질 수 있으므로, SDK의 문서화된 네이티브 크래시 테스트 유틸리티를 사용하는 것이 좋습니다.

Sentry UI에서 확인해야 할 항목

이벤트가 나타날 때, 제목만으로는 충분하지 않습니다.

이 필드를 확인하세요:

플랫폼 및 메커니즘. JS 예외와 네이티브 충돌을 구분하기 위해 도움이 됩니다.
릴리즈 및 dist. 올바른 소스맵이 업로드되지 않았거나 잘못된 경우 소스맵과 symbolication이 비정상적으로 작동합니다.
스택 프레임. 올바르게 업로드된 자바스크립트 맵에 대한 읽을 수 있는 소스 위치가 나타나야 합니다.
브레드크럼과 태그. 사용자 정의 컨텍스트가 올바르게 도착했는지 확인하세요.
환경. 개발 및 운영 이벤트가 혼합되지 않도록 개발 환경과 운영 환경을 분리하세요.

If a native event arrives but has poor symbolication, don’t keep tweaking app code. That’s usually a build artifact problem.

React Native Sentry 일반 문제 해결

증상	가능한 원인	해결 방안
JavaScript 오류가 도착하지만 스택 추적은 압축되어 있습니다	업로드 된 소스 맵이 해당 릴리스와 일치하지 않습니다	CI가 빌드 후 맵을 업로드하는지 확인하고 `release` 그것이 `Sentry.init()` 업로드 된 릴리스와 정확히 일치하는지 확인하십시오
네이티브 크래시가 나타나지 않습니다	네이티브 SDK 훅이 누락되거나 초기화되지 않았습니다	iOS 및 Android 네이티브 설정을 다시 확인하고 QA 빌드에서 제어된 네이티브 충돌 경로로 테스트하십시오.
iOS 네이티브 프레임이 읽을 수 없습니다.	디버그 символ이 업로드되지 않았거나 올바른 빌드에 연결되지 않았습니다.	CI 또는 Xcode 아카이브 플로우 중에 업로드 단계가 실행되는지 확인하고 아카이브 빌드가 символ을 생성하는지 확인하십시오.
디버그 모드와 릴리즈 모드의 동작이 다릅니다.	릴리즈 아티팩트 경로가 변경되었습니다.	릴리즈 Gradle 작업을 검토하고 릴리즈 버전에서 Sentry 처리가 실행되는지 확인하십시오.
이벤트가 올바른 환경 아래에 표시되지 않습니다.	빌드 타겟 간 환경 설정이 누출되고 있습니다.	빌드 타겟별로 DSN, 환경, 릴리즈, 및 dist 값을 분리하십시오.
크럼블 또는 사용자 데이터가 누락되어 있습니다.	앱 상태 변경 중에 컨텍스트가 너무 늦게 설정되거나 삭제되었습니다.	사용자 및 태그를 인증 상태가 해결되면 즉시 설정하고 critical flows 주변에 breadcrumbs 추가

릴리스 프로세스에서 작고

Integrating with Live Update Workflows like Capgo

checklist

를 유지하는 것이 유익한 습관입니다. 스테이징에서 하나의 JS 이벤트를 트리거하고 릴리스 값을 확인하고 소스 위치를 확인하기 전에 빌드를 승격합니다. __CAPGO_KEEP_0__Live Update Workflows와 통합

Live updates는 릴리스 모델을 변경합니다. 스토어에 있는 바이너리는 동일한 채로 유지될 수 있지만 JavaScript bundle은 그 아래에서 변경될 수 있습니다. Sentry가 여전히 원래 앱 버전만을 생각한다면, 스택 트레이스들은 속도감 있게 오류가 발생합니다.

해결책은 release Sentry 릴리스 식별자가 Live Bundle에 따라야 합니다. dist Live update workflows에서 릴리스 식별자를 Live Bundle에 매칭시킵니다.

배포된 JavaScript 패키지와 연결된 런타임 식별자로

기본 릴리스 이름의 일부로 네이티브 앱 버전을 사용하세요.
실시간 업데이트 버전 또는 패키지 식별자와 연결하세요.
__CAPGO_KEEP_0__ dist 채널 또는 빌드에 따라 구분할 때 모델에 맞게 사용하세요.
각 실시간 번들을 위한 소스 맵을 정확한 릴리스 식별자 아래 업로드하세요.

예를 들어, 앱이 런타임에 업데이트된 메타데이터를 로드하는 경우, 현재 활성 번들을 기준으로 Sentry를 초기화하세요. 단순한 정적 빌드 구성만으로는 충분하지 않습니다.

Sentry.init({
  dsn: Config.SENTRY_DSN,
  release: activeBundle.releaseName,
  dist: activeBundle.channel,
});

이러한 방식으로, 사용자가 핫픽스된 번들에서 오류를 발생시키면 Sentry는 핫픽스 대신에 더 오래된 스토어 번들을 기준으로 프레임을 해결합니다.

이것은 OTA-style 워크플로우와 관련하여 중요합니다. OTA-style 워크플로우의 움직이는 조각에 대한 좋은 프라이머를 원한다면, __CAPGO_KEEP_0__ 앱에서 실시간 업데이트가 어떻게 작동하는지에 대한 설명을 참조하세요. how live updates work in Capacitor apps https://__CAPGO_KEEP_0__.app

스크린샷

capgo

The main mistake to avoid is reusing one static release string for every post-store update. If multiple bundles share the same Sentry release, debugging turns into guesswork again.

If your team ships fixes outside app store review cycles, Capgo is worth evaluating. It gives Capacitor teams a structured way to deliver live updates, target channels, control rollouts, and recover from bad releases quickly. Pair that with disciplined Sentry release naming and source map uploads, and you get a workflow where errors still point to the exact code users are running.

Sentry React Native: 2026년 통합 가이드