앱 개발을 위한 인증 관리: 장애 방지

생산 중단으로 인한 만료된 인증서로 인한 문제는 불공평하다. 기능 code 에는 문제가 없고 데이터베이스도 문제가 없는데도 불구하고 사용자는 로그인할 수 없고 업데이트를 다운로드할 수 없거나 API 클라이언트는 모든 요청을 거부한다. 신뢰 체인에 있는 하나의 잊어버린 자격증이 앱 전체를 막을 수 있다.

모바일 팀은 이 문제에 더 자주 부닥친다. Capacitor 앱은 API 엔드포인트, CDN 에지, 빌드 서명 자산, CI 비밀, 앱 스토어 자격증, 그리고 때때로 live update 전달에 의존한다. 모든 움직이는 부분은 인증서, 키, 또는 서명된 식별성을 포함한다. 어려운 부분은 인증서가 중요하다는 것을 이해하는 것이 아니다. 어려운 부분은 앱 아키텍처가 클라우드 서비스, 장치, pipe line에 걸쳐 퍼질 때 모든 인증서를 관리하는 것이다.

인증서 관리는 실제 엔지니어링 분야가 되었다. 인증서 관리 시장은 2025 년에 58 억 달러로 평가되었으며 2034 년까지는 142 억 달러에 이를 것으로 예상된다. 클라우드 배포는 2025 년에 시장의 수익의 1/4를 차지한다고 Market Intelo의 인증서 관리 시장 보고서에 따르면. 5.8 억 달러 2025 년 14.2 억 달러 2034 년 62.4% 2025 년 시장의 수익의 1/4 Market Intelo의 인증서 관리 시장 보고서에 따르면.클라우드 배포

모바일 팀이 빠르게 배포하는 경우, 실용적인 목표는 간단합니다. 신뢰를 유지하면서 배포 속도를 늦추지 않도록 하려면, 재고 관리, 자동화, 모니터링, 서명된 업데이트 워크플로의 명확한 처리가 필요합니다. 오버 더 에어(Over-the-air) 업데이트 배포 시, 이 문제는 더욱 심각합니다. 서명 경로가 릴리스 안전 모델의 일부가 되기 때문입니다. 좋은 시작점은 __CAPGO_KEEP_0__ 앱에 대한 OTA 보안 체크리스트입니다. Capacitor 앱의 OTA 보안 체크리스트하지만 보다 광범위한 인증서 관리는 그 체크리스트 아래에 위치합니다.

소개
- 인증서 관리가 왜 중요해졌는가
- 인증서 관리를 신경 쓰지 않는 비용
모바일 팀이 인증서 관리에서 필요로 하는 것
모바일 플랫폼의 인증서와 프로비저닝
- 실무에서 중요하는 다섯 단계
- 단기 라이프 사이클이 팀 행동을 어떻게 바꾸는지
최신 도구로 라이프 사이클을 자동화하는 방법
인증 모니터링 및 대응 계획을 구축하는 방법
- 관찰이 제어보다 먼저 오는 이유
- 작동하는 대응 계획의 모습
라이브 업데이트와 서명된 패키지를 사용한 보안
결론: 인증서 관리의 문화를 구축하는 것

소개: 인증서 관리의 중요성

애플리케이션 팀은 보통 인증서 관리를 볼 때가 문제가 생기면이다. 프로덕션에서 HTTPS 호출이 실패한다. Apple signing이 릴리스를 중단한다. 빌드 에이전트가 프라이빗 엔드포인트에 접근할 수 없다. live update 패키지가 클라이언트가 더 이상 인증할 수 없다고 판단되면 거부된다. 각 경우의 근본적인 문제는 동일하다. 신뢰가 만료되거나 신뢰가 잘못 구성되거나 신뢰가 문서화되지 않았다.

그런 이유로 스프레드시트가 실패한다. 스프레드시트는 환경이 느리게 변하고 소유권이 명확하다고 가정한다. 그러나 이러한 가정은 더 이상 사실이 아니다. 모바일 앱은 백엔드 서비스, 식별 제공자, 패키지 레지스트리, CI 러너, 앱 스토어 서명 자료, 업데이트 전달 경로에 의존한다. 새로운 통합이 추가될 때마다 만료되거나 위치가 잘못된 인증서가 전달을 중단하는 또 다른 장소가 생긴다.

인증서를 서류처럼 다루는 비용

인증서를 일회성 작업으로 다루는 팀은 동일한 실패 모드를 계속 발견하게 될 것이다. alguien이 인증서를 런칭 스프린트 중에 생성하고 수동으로 설치한 다음 nobody이 소유권을 기억하지 못한다. 몇 달 후 경고가 잘못된 이메일 box로 전송되거나 존재하지 않으면서도.

실용적인 규칙: 인증서가 소유주, 갱신 경로, 배포 경로를 가지고 있지 않으면 관리되고 있지 않다. 단지 사고가 될 때까지 기다리는 것일 뿐이다.

속도와 보안에 모두 중요합니다. 인증서 관리가 약한 팀은 릴리스 일정을 서명 오류와 신뢰 체인에 문제가 생기는 대신에 배포를 진행합니다.

프로세스에서 모바일 팀이 필요로 하는 것

모바일 팀은 거대한 PKI 이론 강의가 필요하지 않습니다. 신뢰할 수 있는 운영 모델이 필요합니다:

존재하는 것을 알 수 있어야 합니다: API, code 서명 자산, 장치 인증서, 업데이트 서명 키 등 모든 자산에 대한 인벤토리를 관리해야 합니다.
반복적인 작업을 자동화해야 합니다: 인간이 일상적인 갱신을 기억해야 한다면 결국 하나를 놓치게 됩니다.
환경을 분리해야 합니다: 제품 환경의 신뢰할 수 있는 자원과 로컬 또는 스테이징 자산을 동일하게 관리하는 것은 피해야 합니다.
재난 대비를 위한 설계가 필요합니다: 갱신 실패, 취소된 키, 유효하지 않은 체인 검증 등에 대한 적절한 대응 경로가 필요합니다.

그런 운영 모델이 인증서 관리를 스트레스에서 근육 기억으로 바꿉니다.

모바일 앱 팀이 관리하는 3 가지 인증서 종류

대부분의 앱 팀은 “인증서”라는 단어를 하나의 개념으로만 생각합니다. 그러나 그것은 아닙니다. 여러 가지 디지털 식별자가 있고, 각 하나는 다른 문제를 해결합니다. 가장 쉬운 정신 모델은 동일한 건물 내에서 다른 배지를 생각하는 것입니다. 하나의 배지는 앞문이 열리는 것을 허용하고, 하나는 상점에서 온 패키지를 증명하고, 하나는 보안에게 허용된 층을 알려줍니다.

SSL/TLS, code 서명, 및 클라이언트 인증서를 포함하는 일반적인 디지털 인증서 유형을 나타내는 다이어그램

앱 트래픽을 위한 TLS 인증서

API, 인증 엔드포인트, 파일 저장소, 또는 웹 뷰와 대화할 때 앱이 매일 만나는 인증서입니다. 이들은 트래픽을 전송하는 동안 보안을 제공하고 클라이언트가 올바른 서버와 대화하고 있는지 확인합니다.

모바일 팀에서 TLS 오류는 일반적인 앱 실패가 보이는 네트워크 오류로 나타납니다. 사용자는 “인증서 문제”를 보지 못합니다. 그들은 로그인 오류, 비어있는 결제 화면, 또는 동기화 오류를 보게 됩니다.

여기서 몇 가지 실용적인 점이 중요합니다:

공개된 엔드포인트는 철저한 갱신이 필요합니다: API 인증서가 만료되면 앱은 건강할 수 있지만 사용할 수 없게 됩니다.
세 번째-party 의존성도 중요합니다: 분석 프록시, 기능 플래그 서비스, 또는 결제 게이트웨이 통합이 신뢰를 깨트리면 앱 흐름이 복제하기 어려운 방식으로 실패할 수 있습니다.
VPN 및 터널 선택은 신뢰 가정에 영향을 미칩니다: 만약 팀이 개인 접근 또는 기업 트래픽 경로를 다루고 있다면, 2026년 중국 VPN 이해를 위한 이 분석은 SSL 기반 및 IPsec 기반 모델의 기능적 차이점을 명확히 설명하기 때문에 유용합니다. 2026년 중국 VPN 이해 SSL 기반 및 IPsec 기반 모델의 기능적 차이점을 명확히 설명하기 때문에 유용합니다.

Code 소프트웨어 신뢰를 위한 서명 인증서

Code 소프트웨어 서명은 소프트웨어가 당신이 만든 것임을 증명하고 서명 후에 소프트웨어가 수정되지 않았음을 증명합니다. 모바일 작업에서 이 점은 여러 층에서 중요합니다. 네이티브 앱 바이너리는 서명됩니다. 데스크톱 동료는 서명될 수 있습니다. 내부 도구는 서명될 수 있습니다. 오버-더-에어 배ंडल도 서명 모델이 필요합니다. 앱 스토어를 통해 배포되지 않는 경우에도.

팀은 종종 전송 보안과 콘텐츠 무결성을 혼동합니다. TLS는 전송 채널을 보호합니다. Code 서명은 아티팩트 자체를 보호합니다. 두 가지 모두 필요합니다.

TLS는 “이것을 신뢰할 수 있는 연결에서 다운로드했습니다.”라고 말합니다.
Code 서명은 “이 정확한 패키지는 당신이 신뢰하는 출판자가 생성한 것입니다.”라고 말합니다.

라이브 업데이트 사용 중이라면 이 차이점은 매우 중요합니다. 안전한 CDN만으로도 자바스크립트 배ंडल 자체가 합법적임을 증명하지는 못합니다.

모바일 프로비전 및 플랫폼 자격증명

모바일은 백엔드 팀이 생각하지 않는 카테고리 하나를 추가합니다: 플랫폼 특정 서명 및 프로비전 자산. 애플 워크플로우는 명백한 예입니다. 이 자격증명은 앱이 허용된 작업을 결정하고 개발 중에 실행할 수 있는 장치 또는 프로필을 결정하며, 릴리스를 빌드하고 배포할 수 있는지 여부를 결정합니다.

카테고리를 구분하기 쉬운 방법은 이 표입니다.

인증서 또는 자격 증명	무엇을 증명하는가	일반적인 실패 증상
TLS 인증서	네트워크 트래픽을 위한 서버 식별	API 호출 또는 웹 콘텐츠가 실패합니다.
Code 서명 인증서	소프트웨어의完整성 및 퍼블리셔의 진위성	빌드, 설치 또는 업데이트 확인이 실패합니다.
배포 또는 플랫폼 서명 자산	앱 권한 및 플랫폼 인증	iOS 빌드 또는 배포 PIPELINE이 중단됩니다.

모든 세 가지 경우에 일치하는 정책은 거의 없습니다. TLS 인증서는 짧은 서비스 지향 타이밍에 자주 회전합니다. Code 서명 자료는 엄격한 키 보관을 필요로 합니다. 플랫폼 자격증은 벤더별 갱신 및 접근 문제를 가져옵니다. 좋은 인증 관리는 이러한 것들을 별도의 운영 트랙으로 다루는 것으로 시작해야 합니다. 동일한 팀이 모든 것을 다루더라도.

인증서의 생애주기: 출생부터 먼지까지

인증서가 파일을 설치하고 잊는 것이 아닙니다. 그들은 유독한 자격증과 더 가깝습니다. 그들은 발급, 배포, 감시, 교체, 그리고 때로는 압박으로 인해 취소됩니다. 팀이 설치 단계만 본다면, 생애주기의 대부분을 놓치고 있습니다.

인증서 생애주기 관리의 다섯 단계를 나타내는 다이어그램.

실무에서 중요하게 여겨지는 다섯 단계

생애주기를 다섯 개의 운영 단계로 생각하는 것이 유익합니다.

요청 및 발급
누군가 또는 시스템이 인증서를 요청합니다. 이는 ACME를 사용하는 인그레스 컨트롤러, 서명 자산을 준비하는 CI 작업, 또는 단기적인 클라이언트 인증서를 요청하는 내부 서비스일 수 있습니다.
배포
인증서와 개인 키는 올바른 런타임에 도착해야 합니다. 이 단계에서 형식 불일치, 잘못된 비밀 범위, 부분 롤아웃은 피할 수 있는 다운타임을 발생시킵니다.
감시
만료, 사용, 및 소유권을 추적해야 합니다. 감시만 날짜를 확인하는 것이 아닙니다. 인증서가 원하는 곳에 있는지, 교체 경로가 여전히 작동하는지 알려줘야 합니다.

팀이 중간 단계를 건너뛰는 경우에 도움이 되는 짧은 시각적 리프레셔가 있습니다:

갱신
갱신은 공황이 시작되기 전에 발생해야 합니다. 만약 당신의 유일한 갱신 테스트가 프로덕션 만료 주일이라면, 당신은 프로세스를 가지고 있지 않습니다. 당신은 도박을 하고 있습니다.
취소
키가 노출되거나 인증서가 잘못 발급된 경우, 빠르게 무효화하고 대체할 수 있는 방법이 필요합니다. 이 경우, 재고가 필수적입니다. 인증서가 배포된 모든 장소에 대해 알지 못하면, 자신감 있게 취소할 수 없습니다.

중간 기간의 짧은 수명이 팀 행동을 어떻게 바꾸는지

대규모 운영 전환은 2026년 3월 15일에 발생했습니다. 주요 산업 표준은 200일으로 제한된 새로 발급된 TLS 인증서에 대한 변경이었습니다. 이 변경은 갱신 빈도가 5배 증가했습니다 earlier norm과 비교하여, 최대 유효 기간은 2029년까지 47일로 떨어질 것으로 예상됩니다. 2029년까지 47일로 떨어질 것으로 예상됩니다. Accutive Security의 TLS 라이프 사이클 요약에 따르면. TLS 생명주기 요약해당 출처는 또한만

조직이 전체적으로 인증서 인벤토리에 대한 가시성을 가지고 있지 않은 경우가 34% 입니다. 이는 많은 팀이 만료에 놀라는 이유입니다. 갱신이 빈번해지면 숨겨진 인증서가 edge case가 아닌 장애 발생 원인이 됩니다.

인증서 라이프 사이클은 발견, 갱신, 배포가 하나의 루프에 포함되어야만 작동합니다. 다른 소유자 간에 분리하고 공유된 시각이 없다면, 실패는 생산으로 강제되기 전까지 숨겨집니다.

모바일 개발의 실제 implication은 TLS보다 더 광범위합니다. 동일한 마음가짐이 빌드 서명 비밀, 업데이트 검증 키, CI에 임베디드된 모든 것에 적용됩니다. 만약 그 자산이 저장되는 곳과 갱신되는 방법을 매핑하지 않았다면, pipeline hardening 작업을 시작하여 CI/CD pipeline에서 비밀을 관리하는 것을 시작하세요. 인증서 관리와 비밀 처리는 동일한 장소에서 만납니다.

인증서 모니터링 및 대응 계획 구축

네트워크 트래픽, 위협 감지, 서버 활동을 모니터링하는 사이버 보안 전문가가 어두운 방에서.

visibility가 control보다 중요합니다.

이 카테고리는 "shadow certificate"입니다.

암시적 인증 인증 모니터링 및 대응 계획을 구축하는 방법환경 내에서 활성화 된 모든 인증서가 포함되며, 팀이 의도적으로 추적하지 않았거나 현재 소유하지 못하거나 쉽게 갱신할 수 없는 인증서입니다. 하이브리드 모바일 스택은 이 문제를 악화시킵니다. 신뢰할 수 있는 자료는 에지 서비스, 내부 API, 오래된 스테이징 환경, 앱 업데이트 인프라 및 제 3 자 시스템에 위치할 수 있습니다.

그것은 특정 문제가 아닙니다. 68% 조직의 %s가 인증서를 완전히 목록화할 수 없다고 보고하고 있으며, 이 격차는 특히 모바일 및 하이브리드 앱 팀에서 특히 심각하다고 묘사됩니다. 어둠의 인증서 발견에 대한 Help Net Security의 보도.

실용적인 목록은 모든 인증서에 대해 네 가지 질문에 답해야 합니다.

질문	왜 중요합니까
배포 위치	갱신 및 취소에 필요한 것은 무엇입니까
누구가 소유합니까	경고가 실제 팀이 아닌 죽은 이메일箱에 의존하지 않도록 해야 합니다.
무엇을 위해 사용합니까	TLS, 서명, 장치 인증, 또는 플랫폼 사용 모두 다르게 처리합니다.
대체 방법은 무엇입니까?	만약 그 대답이 “수동으로”라면, 그것은 위험 항목입니다.

작업 가능한 대응 계획은 무엇입니까?

인증 만료 압박이 심해질 때 경보가 발생해야 합니다. 경보는 최소한의 압박이 발생하기 전에 발생해야 합니다. 대응 규칙: 첫 번째 경보가 작업을 생성해야 합니다. 마지막 경보가 루틴북을 트리거해야 합니다.

그 루틴북은 크지 않아도 됩니다. 실행할 수 있어야 합니다. 각 인증서 클래스에 대해 문서화하십시오: 주요 책임자:

갱신에 대한 책임이 있는 팀입니다.

90일, 60일, 30일 전 경보가 발생해야 합니다. 대체 방법은 무엇입니까?
대체 주인: 주인이 unavailable 할 때 대체하는 팀입니다.
갱신 방법: ACME 작업, CI 작업, 벤더 콘솔, 또는 수동 긴급 경로.
유효성 검사 단계: 새 인증서가 사용 중인지 확인하는 방법.
통신 경로: 사용자 영향이 가능할 때 알림을 받는 사람.

만약 이미 사고 템플릿이 없다면 기존의 템플릿을 조정하세요 Live Update를 위한 서명된 패키지 보안 rather than inventing a separate one for certificates. Expired trust is still an incident. Treat it with the same clarity you use for API failures or broken releases.

인증서 관리

라이브 업데이트은 인증서 대화가 변경됩니다. 앱이 스토어 리뷰 사이클 외부에서 code 또는 자산 변경을 수용할 수 있게 되면, Transport Security만으로는 충분하지 않습니다. 클라이언트에서 아티팩트完整성을 필요로합니다. 즉, 서명된 번들을 기기에서 검증할 수 있는 키 라이프 사이클을 운영할 수 있어야합니다.

서명된 번들을 사용하여 안전한 모바일 앱 업데이트를 전달하는 프로세스를 설명하는 6단계의 정보그래픽.

기기에서 신뢰 흐름이 어떻게 작동하는지

깨끗한 모델은 간단합니다.

서명 키 pair가 존재합니다. 개인 키 CI에서 각 업데이트 번들을 서명합니다. 공개 키 기본 앱 빌드에 포함된 공개 키

업데이트를 다운로드할 때, 앱은 로컬에서 서명 검증을 수행한 후 번들을 적용합니다. 검증이 실패하면 업데이트는 거부됩니다.

Implementation의 안정적인 구현은 일반적으로 이 순서를 따릅니다.

강력한 implementation은 일반적으로 이 순서를 따릅니다: OTA 배포용 번들에 서명하기 위해.
보안상으로 안전한 곳에 개인 키를 저장하세요. CI 환경에서 개인 키를 저장하고 소스 코드 관리에서 제거하세요.
앱에 공개 키를 임베드하세요. 클라이언트가 오프라인에서 서명 확인을 할 수 있도록 하세요.
릴리즈 작업 중에 모든 번들을 서명하세요. 업로드하기 전에 서명하세요.
다운로드한 업데이트를 적용하기 전에 기기에서 확인하세요. 유효하지 않은 서명이 있는 경우 거부하고 로그하세요.
지원팀이 실패를 추적할 수 있도록 하세요. 이 기능을 __CAPGO_KEEP_0__ 스택에서 구현하는 경우, 제품 수준의 메커니즘은 이해하기 더 쉬울 것입니다.

If you’re implementing this in a Capacitor stack, the product-level mechanics are easier to understand through Capacitor 업데이터에 대한 code 서명, 그러나 underlying 보안 모델은 일반적이다.

업데이트 전달을 중단하지 않고 키 회전

서명 키는 영원히 살 수 없다. 회전은 많은 팀이 두려워하는 곳이다. 실수하면 오래된 클라이언트 또는 유효한 업데이트를 차단할 수 있다.

일반적인 규칙은 오버랩을 설계하는 것이다. 현재 검증 키를 신뢰하는 클라이언트를 배달하고, 마이그레이션 중에는 다음 키도 신뢰하도록 한다. 그런 다음 새로운 버전의 개인 키로 새로운 패키지를 서명한다. 오래된 앱 버전이 나이를 먹으면, 신고된 키에 대한 신뢰를 제거한다.

저장품질은 회전 주기를影响한다. Keytos의 PKI 및 SSL 인증서 관리 최적화 가이드에 따르면비하드웨어 보호 인증서는 매 30일으로 회전해야 한다. 컴퓨터 리프 인증서가 HSM에 의해 지원되는 경우에는 매 90일까지 회전할 수 있다. live update 서명에 대한 실용적인 교훈은 서명 개인 키가 하드웨어로 지원되지 않는 경우, 회전 창구를 단축하고 CI 제어를 강화하는 것이다.

Capgo live update 인증 키는 배포 권한으로 다루어야 합니다. 편리한 비밀번호처럼 다루지 마세요.

일반적으로 잘못하는 팀은?

세 가지 실수를 반복적으로 발견했습니다.

모든 것을 하나의 키로 사용하는 경우: OTA 서명과 다른 인증서 및 플랫폼 자격 증명과 분리하십시오. 공유된 키는 폭파 반경을 증가시킵니다.
CI 외부에서 서명하는 경우: 노트북 기반 서명 워크플로우는 감사하기 어려우며 더 어려운 키 전환을 깨끗하게 수행하기 어렵습니다.
롤백 신뢰 무시하는 경우: 자동 롤백을 지원하는 경우, 롤백된 패키지가 여전히 검증을 통과하고 키 전환에 의해 차단되지 않도록 보장하십시오.

모바일 팀에게 인증 관리는 매우 구체적이 됩니다. 단순히 엔드포인트를 보호하는 것이 아니라, 배포 후에 실행 중인 앱 code을 변경할 수 있는 권한을 보호하고 있습니다. 이는 프로덕션 배포 자격 증명과 같은 엄격성을 요구합니다.

결론: 인증 관리 문화를 구축하는 것

좋은 인증 관리는 보안 도구를 더 많이 모으는 것이 아닙니다. 배포 경로에서 취약한 신뢰 가정들을 제거하는 것입니다. 앱이 API, 모바일 서명, CI 작업 및 라이브 업데이트에 인증을 사용하는 경우, 신뢰 관리는 이미 엔지니어링 시스템의 일부입니다. 그것을 공식화했는지 여부와 상관없이.

어디서도 문제가 안 되는 팀은 몇 가지 간단한 일들을 잘 해내는 경향이 있습니다. 그들은 현실에 맞는 재고를 유지합니다. 자동화된 갱신 및 배포 단계를 신뢰하기보다는 기억력에 의존하지 않습니다. 만료 및 실패를 감시하기 위해 충분한 시간을 가지고 정상적으로 행동할 수 있도록 합니다. 그리고 특히 라이브 업데이트와 관련된 서명 키를 프로덕션급 릴리스 자산으로 다루는 것입니다.

더 깊은 변화는 문화적입니다. 인증서에 대한 주의가 백엔드, 모바일, DevOps, 릴리스 엔지니어링과 같은 모든 팀에서 공유될 때 가장 잘 작동합니다. 백엔드는 서비스 신뢰를 소유합니다. 모바일은 클라이언트 인증 동작을 소유합니다. DevOps는 자동화 및 관찰성을 소유합니다. 릴리스 엔지니어링은 반복 가능한 서명 워크플로를 소유합니다. 그 책임이 명확할 때 오류가 드물고 복구 속도가 빠릅니다.

유용한 표준은 다음과 같습니다:

시각성 우선순위
반복 가능한 경로를 자동화
비공개 키를 강력하게 제어
사고 경로를 작성하기 전에
신뢰 도메인을 분리하여 한 실수가 어디서도 퍼지지 않도록

인증서 관리는 이전에는 더 오래 지속되었고 아키텍처가 더 단순했기 때문에 쉽게 미루어졌습니다. 그러나 그 시간은 사라졌습니다. 현대 앱은 너무 분산되어 있고 릴리스 주기는 너무 빠르고 서명된 업데이트 경로는 비정형 처리에 너무敏감하기 때문에.

팀이 이 문제를 잘 해결하면 사용자는 아무것도 느끼지 않습니다. 그게 목표입니다. 앱은 계속 연결되며 빌드는 서명되며 업데이트도 검증되며 엔지니어는 만료된 신뢰 체인 복구에 시간을 보내지 않고 대신 배포를 진행합니다.

만약 Capacitor 또는 Electron 앱에서 실시간 업데이트 shipping을 하고 있다면, Capgo 실시간 업데이트 shipping을 제공하는 __CAPGO_KEEP_0__은 signed bundles를 전달하는 실용적인 방법을 제공하고, rollout channels를 제어하고, release가 잘못되면 빠르게 복구할 수 있는 강력한 기능입니다. 이 기능은 웹-layer fix를 매번 스토어 리뷰를 기다리지 않고도 업데이트의完整성을 높이고 싶은 팀에게 적합합니다.

앱 개발을 위한 인증서 관리: 장애 방지

목차