방금 배포를 마쳤습니다. 그런데 누군가 폰으로 앱을 열어 결제 버튼을 탭했는데, 깨진 CSS 규칙 하나 때문에 버튼이 화면 밖으로 반쯤 밀려나 있습니다. 수정은 2분이면 됩니다. 하지만 그 수정 사항을 사용자에게 전달하는 것이 어려운 부분입니다. 일반적인 경로는 새로운 빌드, 새로운 제출, 그리고 또 다른 심사 대기 시간을 의미하니까요. 준비된 수정과 실제 수정된 앱 사이의 그 간극이 바로 OTA 업데이트를 그 가치를 인정받는 곳입니다.
목차
- OTA 업데이트가 중요한 이유
- OTA 업데이트의 작동 원리 이해하기
- 검증된 이점과 실제 리스크
- 플랫폼 규칙 및 App Store 고려 사항
- JavaScript 및 Capacitor 앱을 위한 기술적 접근 방식
- Observability와 보안 베스트 프랙티스
- Capgo가 OTA 배포를 간소화하는 방법
- OTA 릴리스 전략 세우기
OTA 업데이트가 중요한 이유
결제 버그가 익숙하게 느껴지는 이유는 code 자체가 느린 경우가 드물기 때문입니다. 오버플로우를 발견하고 코드 한 줄을 수정한 뒤, 몇 분 만에 로컬에서 테스트를 마칩니다. 하지만 수정 사항은 스토어 심사 대기열에 머물러 있고, 그동안 사용자는 계속해서 깨진 화면을 마주하며, 고객 지원팀은 똑같은 티켓에 계속 답변해야 합니다. 팀원들은 신속 제출을 서두를지, 아니면 다른 변경 사항과 함께 묶어 제출할지를 두고 논쟁하게 됩니다.
OTA 업데이트, 보통 줄여서 OTA가, 특정 종류의 변경 사항에 대해 그 대기열을 없애줍니다. Capacitor, Ionic 또는 기타 웹 기반 앱에서는 업데이트된 JavaScript, CSS, HTML 및 에셋 설치된 기기에 직접 배포할 수 있습니다. 앱이 새 web bundle을 다운로드하고 검증한 뒤, 이미 스토어를 통해 배포한 native shell 안에서 실행합니다.
그에 맞는 프로세스를 만들기 전에 장단점을 명확히 따져보세요.
- OTA로 빨라지는 작업: 카피 수정, 레이아웃 수정, 이미지 교체, 스타일 변경, 그리고 기존 native container 내에서 실행되는 JavaScript 로직.
- OTA가 대체할 수 없는 것: 새 native plugin, 권한 변경, native SDK 업그레이드, 아이콘 또는 entitlement 변경, 그리고 binary에 컴파일되는 모든 것.
- 팀에 달라지는 점: 배포 리스크가 스토어 일정에서 팀 자체의 테스트, 타겟팅, 롤백 관리로 옮겨갑니다.
마지막 포인트는 대부분의 설명에서 인정하는 것보다 더 중요합니다. 심사가 필요 없는 변경의 제출 지연을 건너뛰면, 때로는 부실한 배포를 걸러주던 강제 대기 시간도 함께 건너뛰게 됩니다. 대신 채널, 단계적 노출, 모니터링으로 안전성을 확보해야 합니다.
실무 원칙: OTA는 웹 레이어 버그를 발견하고 사용자에게 수정을 적용하기까지의 거리를 줄여줍니다. 하지만 그 수정이 안전한지 판단하는 일까지 줄여주지는 않습니다.
그래서 팀들은 OTA를 편의 기능이 아니라 배포 전략으로 다룹니다. 만약 모든 수정을 스토어 배포로 만들지 않으면서 배포 속도를 높이려 한다면성과는 속도만이 아닙니다. 어떤 변경이 전체 native release를 거쳐야 하고, 어떤 변경이 더 빠르고 좁은 웹 경로로 갈 수 있는지에 대한 제어권입니다.
OTA 업데이트의 작동 원리 이해하기
우편 비유로 설명하면 이 아키텍처를 더 쉽게 이해할 수 있습니다. 네이티브 앱은 집. 앱 스토어는 건축 허가증 그 집을 짓거나 개조할 수 있게 해주는 것입니다. 그리고 OTA 번들은 편지 집이 이미 승인받고 입주한 후에 우편함으로 들어가는 것과 같습니다.
우편으로 방을 추가할 수는 없습니다. 집의 구조가 그대로 유지되는 한, 새로운 지침, 수정된 서류, 벽을 위한 대체 사진 등을 보낼 수는 있습니다.
디바이스와 서버의 구성 요소
첫째, 빌드된 앱에는 네이티브 바이너리 그리고 내장된 웹 번들이 포함됩니다. 바이너리에는 런타임, 네이티브 플러그인, 권한, 스토어 메타데이터가 포함됩니다. 웹 번디에는 인터페이스가 렌더링하는 파일들이 저장됩니다.
둘째, 작은 클라이언트 SDK 또는 플러그인이 앱 내부에서 업데이트 서비스에 해당 기기에 대해 더 새로운 호환 번들이 있는지 확인합니다. 다운로드 전에 앱 버전, 채널, 번들 버전 등을 확인합니다.
셋째, 업데이트 서비스가 대상 bundle을 식별하는 manifest를 반환합니다. 디바이스는 파일을 다운로드하고 무결성을 검증한 후, 내장 bundle과 별도로 저장하며 재시작 시나 설정한 안전한 시점에 적용합니다. 새 bundle이 초기에 실패하면 앱은 크래시 루프에 갇히지 않도록 마지막에 정상 작동했던 bundle로 폴백해야 합니다.
Capacitor 방식의 앱이 이 모델에 적합한 이유
Capacitor 및 Electron 앱은 네이티브 컨테이너 내부의 웹 에셋으로 인터페이스의 상당 부분을 렌더링합니다. 이 분리 구조가 바로 OTA가 의존하는 핵심입니다. 컨테이너 자체를 교체하는 것이 아니라, 컨테이너가 이미 로드할 수 있는 웹 콘텐츠를 교체하는 것입니다.
혼란은 보통 JavaScript가 네이티브 기능을 호출할 때 시작됩니다. 사진 요청을 하는 JavaScript를 변경하는 것은 웹 변경 사항입니다. 반면 카메라 접근 권한을 추가하거나 카메라 플러그인을 교체하는 것은 네이티브 변경 사항이며, 이는 스토어 릴리스에 포함되어야 합니다. 인접 스택을 탐색하는 팀은 이 사고 모델을 다음과 비교해 볼 수 있습니다. React Native 앱의 빠른 수정 방법, 여기서 JavaScript와 네이티브 code 사이의 동일한 경계가 적용 대상이 무엇인지 결정합니다.
검증된 이점과 실제 리스크
OTA는 새로운 배포 개념이 아닙니다. Apple은 2011년 10월 iOS 5를 통해 컴퓨터나 iTunes 없이 디바이스에서 직접 업그레이드할 수 있는 에어(iOS) 업데이트를 도입했습니다. 2012년 3월 7일 iOS 5.1이 출시된 후, 개발자 David Smith가 추적한 OTA 대상 사용자의 50%가 5일 이내에, 77%가 15일 이내에 업그레이드를 완료했습니다.이는 David Smith의 iOS 5.1 도입 추적을 보도한 MacRumors.
이 부분을 주의 깊게 읽어보세요. 분모는 OTA 대상 사용자였지, 전 세계 모든 iPhone이 아니었습니다. 구형 및 호환되지 않는 기기를 포함했을 때, 15일 후 도입률은 더 낮았습니다. 이것이 첫 번째 운영 교훈입니다. 어떤 기기가 업데이트를 받을 수 있는지 알아야 도입률 차트가 의미를 가집니다.
Android의 초기 역사는 정반대의 실패 양상을 보여줍니다. 2011년 2월, Android 사용자의 0.8%만이 Android 2.3 Gingerbread를 실행 중이었고, 57.6%는 여전히 Android 2.2 Froyo를 사용 중이었습니다, 이는 Ben Dodson의 Android와 iOS 업데이트 배포 비교에서 확인할 수 있습니다. 사용자들은 무선으로 업데이트를 받을 수 있었지만, 제조사와 통신사는 릴리스를 서로 다른 속도로 걸러냈습니다. 무선 전송이 케이블은 없앴을지 몰라도, 게이트키퍼까지 없애지는 못했습니다.
혜택이 끝나고 책임이 시작되는 지점
요즘 앱 팀에게 이점은 구체적입니다. 깨진 화면을 더 빨리 고칠 수 있고, 바이너리를 다시 빌드하지 않고 문구 변경을 테스트할 수 있으며, 기기를 이전 bundle로 되돌려 잘못된 웹 릴리스를 중단할 수 있습니다. 팀과 기기 사이에 거치는 주체가 줄어들기 때문에 해당 변경 사항의 릴리스 사이클이 짧아집니다.
위험도 함께 압축됩니다. 결함이 있는 bundle은 누군가 크래시 리포트를 읽기도 전에 전체 사용자에게 도달할 수 있습니다. JavaScript 변경은 레이아웃을 넘어 가격, 동의, 인증, 자격 요건 동작까지 크게 바꿀 수 있습니다. 기술적으로는 여전히 웹 code이지만, 운영 및 법적 관점에서는 규제상 결과가 따르는 제품 변경일 수 있습니다.
의존성 위험도 있습니다. 업데이트 소스, channel 설정 또는 서명 경로에 문제가 생기면 기기가 다음 bundle을 안전하게 가져올 수 없습니다. 복구 가능한 배포 경로가 없는 속도는 사용자를 구버전에 더 빨리 묶어둘 뿐입니다.
플랫폼 규칙 및 App Store 고려 사항
대부분의 짧은 설명글은 슬로건에서 멈춥니다. 웹 변경은 괜찮고 네이티브 변경은 안 된다는 식이죠. 그 슬로건은 유용한 시작점이지만, 릴리스 시점에 마주치는 까다로운 사례를 판단하는 데는 도움이 되지 않습니다.
Apple은 다운로드된 인터프리터 방식의 code에 대해 더 복잡한 입장을 취합니다. 이는 앱의 주요 목적을 바꾸거나앱 마켓플레이스를 만들거나 운영체제 보안 제어를 우회하지 않을 때만 사용할 수 있습니다. 이 경계는 Otakit의 App Store 및 Google Play OTA 정책 분석에 요약되어 있습니다. 따라서 변경 사항이 어떤 언어로 작성됐는지만 문제가 아닙니다. 그 변경이 무엇을 하는지도 중요합니다.
버튼 색상은 쉽습니다. 새 결제 흐름, 다른 동의 화면, 변경된 가격 로직, 수정된 계정 자격 규칙은 모든 줄이 JavaScript여도 더 어렵습니다. 이런 변경은 사용자 고지, 스토어 심사 기대치, 특정 지역의 의무에 영향을 줄 수 있습니다.
유용한 비교: Android 업데이트 긴급도
Google Play 인앱 업데이트는 Capacitor web bundle 업데이트와 메커니즘이 다르지만, 긴급도 모델은 시사하는 바가 큽니다. Google Play의 유연한 업데이트 흐름은 사용자가 앱을 계속 사용하는 동안 백그라운드에서 다운로드 및 설치를 진행하는 반면, 즉시 업데이트 흐름은 업데이트가 설치되고 앱이 재시작될 때까지 사용자의 상호작용을 차단합니다. Google은 또한 업데이트 우선순위 값을 0~5 범위로 Play Developer API를 통해 제공합니다.
그 사고방식을 참고하세요. 일상적인 인터페이스 변경은 세션을 중단시켜서는 안 됩니다. 계속 사용하기에 안전하지 않은 보안 문제를 해결하는 수정은 더 강력한 경로가 필요하며, 대부분의 경우 네이티브 스토어 릴리스로, 명확한 앱 스토어 심사 관리 조용한 웹 패치보다는
OTA vs 스토어 릴리스 결정 매트릭스
| 변경 유형 | 배포 경로 | 필수 테스트 | 롤백 결과 |
|---|---|---|---|
| 문구 또는 CSS 수정 | OTA가 | 대상 기기에서 육안 확인 | 이전 bundle이 이전 인터페이스를 복원 |
| JavaScript 버그 수정 | OTA가 | 영향받는 플로우 회귀 테스트 | 결함이 있는 code가 기록한 로컬 데이터 확인 |
| 결제 또는 동의 작동 방식 | 스토어 심사 먼저 | 법무, 제품, E2E 테스트 | code를 롤백해도 사용자 영향은 남을 수 있음 |
| Native plugin 또는 권한 | 스토어 출시 | 전체 Native Build 및 디바이스 테스트 | 사용자가 스토어 업데이트를 다시 받아야 함 |
| 주요 목적 변경 | 스토어 출시 | 전체 리뷰 준비 | OTA 롤백으로 정책 리스크 해결 불가 |
변경 사항이 중간 행에 해당한다면, 해당 경로를 선택한 이유를 기록하세요. 이 메모는 지원, 컴플라이언스, 그리고 나중의 나를 위한 증거가 됩니다.
JavaScript 및 Capacitor 앱을 위한 기술적 접근 방식
OTA 파이프라인은 배포 버튼만 보면 단순해 보입니다. 하지만 그 아래에서는 기기가 새 bundle을 신뢰하고 실행하기 전에 여러 제어 요소가 서로 맞아떨어져야 합니다.
시작하기 패키징. 빌드하면 보통 HTML, JavaScript, CSS, 이미지, 폰트 같은 웹 에셋이 생성됩니다. 업데이트 시스템은 이 파일들을 manifest와 불변(immutable) 버전 식별자로 패키징합니다. 같은 버전 이름이 시점에 따라 다른 파일을 가리킬 수 있으면 디버깅이 추측이 되어버리므로, 불변성은 중요합니다.
다음 단계 델타 전송 시스템이 지원하는 경우, 모든 에셋을 다시 전송하는 대신 변경된 파일이나 기기에 이미 있는 버전에 대한 패치만 전송합니다. 이렇게 하면 다운로드 크기와 실패 위험이 줄어들며, 특히 연결 상태가 나쁜 환경에서 유리합니다. 다만 이전 bundle에서 올라온 기기가 새로 설치한 것과 동일한 최종 상태로 조립되는지 확인해야 하므로 테스트 부담도 생깁니다.
타겟팅, 스테이징, 롤백
서명 패키징과 전송 사이에 위치합니다. 기기는 익숙해 보이는 네트워크 경로로 전달되더라도 예상 서명이나 해시와 일치하지 않는 bundle은 거부해야 합니다. 서명은 해당 아티팩트가 릴리스 프로세스를 거쳤고 전송 중 변조되지 않았음을 증명합니다.
버전 타겟팅 그다음 어떤 native shell이 bundle을 받을지 결정합니다. 이것이 바로 호환성 방화벽 역할을 합니다. 새로운 JavaScript가 이전 바이너리에 없는 플러그인 메서드를 요구한다면, 요행을 바라지 말고 최소 native 버전 규칙으로 해당 바이너리를 제외해야 합니다. 더 넓은 크로스 플랫폼 개발 가이드 여기서 유용한 맥락입니다. 공유 web code는 서로 다른 native 기능과 운영체제 버전에서 여전히 실행되기 때문입니다.
채널 내부 테스터, 베타 사용자, 프로덕션 같은 별도 대상 단계적 배포 설치 결과와 앱 동작을 지켜보면서 번들을 점진적으로 노출하세요. 이전 번들은 안정적인 폴백으로 남겨두고, 팀이 압박을 받는 상황에서 새 수정본을 배포하지 않고도 노출을 일시 중지하는 방법을 숙지하게 하세요.
롤백은 파이프라인의 마지막 단계처럼 느껴지지만, 첫 출시 전에 설계해야 합니다. 어떤 번들이 정상 동작이 확인된 것인지, 이전 code가 최신 로컬 데이터를 읽을 수 있는지, 이미 스토리지 마이그레이션을 마친 기기를 어떻게 처리할지 알아두세요. 이러한 교체에 숨은 실질적인 파일 수준 질문들, 라이브 앱에서 파일을 안전하게 업데이트하는 방법 은 릴리스 체크리스트에 반영해야 할 메커니즘을 다룹니다.
롤백을 데이터의 실행 취소 버튼으로 생각하지 마세요. 롤백은 code을 복원할 뿐, 잘못된 code이 만든 상태까지 복원하지는 못할 수 있습니다.
Observability와 보안 베스트 프랙티스
보안과 Observability는 같은 런북에 있어야 합니다. 인시던트가 발생하면 두 질문이 한꺼번에 나오기 때문입니다. 무엇이 기기에 도달했는지, 누가 승인했는지, 어떻게 알 수 있는지?
아티팩트 신뢰부터 시작하세요. 업데이트 번들은 설치 전에 서명되고, 필요한 경우 암호화되며, 해시나 서명으로 검증되어야 합니다. 배포는 로그로 남기고, 변경 사항이 데이터, 권한, 사용자 경험에 영향을 주면 사용자에게 알려야 합니다.. 이는 단순한 서류 작업이 아닙니다. 기기가 여러분의 릴리스를 손상되었거나 악의적인 대체물과 구분하는 방법이고, 팀이 나중에 사건의 경위를 재구성하는 방법입니다.
위협 모델 기반 런북
- 권한 분리: 번들을 빌드하는 사람이나 파이프라인이 자동으로 프로덕션으로 승격할 수 없어야 합니다.
- 서명 자격 증명 보호: 키 접근을 프로덕션 데이터베이스 접근처럼 제한된 소지자와 감사 가능한 사용으로 관리하세요.
- 출처 기록: 모든 배포에 대해 커밋, 번들 식별자, 채널, 승인자, 롤아웃 변경 사항을 기록하세요.
- 디바이스에서 자격 요건을 확인하세요: 크래시 이후가 아니라 설치 전에 네이티브 호환성을 검증하세요.
- 킬 스위치를 유지하세요: 사전 합의한 임계값을 초과하는 실패가 발생하면 채널을 일시 중지하거나 강제 폴백을 실행하세요.
- 롤백 한계를 정의하세요: 로컬 데이터나 서버 컨트랙트가 이미 변경되어 롤링 포워드가 더 안전한 상황을 명시하세요.
플랫폼 거버넌스는 의존성을 하나 더 추가합니다. Apple은 대체 마켓플레이스나 웹 배포자를 통해 설치된 앱이 향후 업데이트를 해당 배포자에 의존하며, 그 마켓플레이스가 삭제되거나 운영을 중단하면 해당 앱은 더 이상 업데이트를 받지 못한다고 설명합니다. 자세한 내용은 다음에서 확인할 수 있습니다: Apple Support의 대체 앱 배포 가이드. 따라서 모니터링에서는 단순히 다운로드 성공 여부만이 아니라, 업데이트 소스 가용성과 구버전에 머물러 있는 기기까지 추적해야 합니다.
Observability는 이러한 제어를 의사결정으로 바꿉니다. 채널 및 네이티브 버전별 채택률, 사유별 설치 실패, 서명 실패, 활성화 후 크래시 신호, 그리고 여전히 fallback bundle을 사용하는 기기 비중을 모니터링하세요. 강력한 업데이트 bundle 서명 검증 방식은 검증 실패가 눈에 보이고 알림까지 가능해야만 도움이 됩니다.
많은 클라이언트 앱을 관리하는 핀테크, 헬스케어, 에이전시 팀에게는 업데이트가 롤백되었다는 사실만으로 사고 대응의 완전한 답이 되지 않습니다. 노출 범위, 영향받은 기기, 그리고 업데이트 철회 전 민감한 로컬 상태가 변경되었는지에 대한 증거도 필요합니다.
Capgo가 OTA 배포를 간소화하는 방법
플랫폼이 위에서 다룬 의사결정을 없애주지는 않습니다. 대신 각 팀이 스토리지, 서명, 디바이스 타겟팅, 대시보드로 인프라를 직접 구성하지 않아도 되도록, 그 의사결정에 일관된 제어 수단을 제공합니다.
Capgo의 Live Update 웹 번들을 배포하세요 릴리스 채널 사용, 단계적 롤아웃, 버전 타겟팅, 롤백 제어를 제공합니다. 팀은 내부, 베타, 프로덕션 대상을 분리한 뒤, 장애 상황에서 사용하는 동일한 채널 모델로 번들을 승격할 수 있습니다. 프로그레시브 딜리버리는 안정적인 폴백을 유지하면서 기기의 일정 비율에 번들을 지속적으로 할당하며, 설정된 실패 임계값을 초과하면 롤아웃을 자동으로 일시 중지할 수 있습니다.
중요한 설계 포인트는 라이브 업데이트가 네이티브 배포를 대체하는 척하지 않고 나란히 존재한다는 점입니다. Capgo는 클라우드 네이티브 빌드와 스토어 제출 지원도 제공하므로, 플러그인 변경은 바이너리 경로를 따르고 웹 수정은 번들 경로를 따릅니다. 이 분리는 팀이 이미 사용하고 있어야 하는 의사결정 매트릭스와 일치합니다.
운영 측면에서 Observe는 다음을 추적합니다 릴리스 채택률, 설치 실패, 성공률, 기기 로그. 실패 보고는 네트워크나 기기 문제를 번들 문제 및 롤백과 구분하므로, 릴리스가 red로 보이는지보다 더 유용한 질문에 답할 수 있습니다. 번들에 결함이 있었던 걸까요, 아니면 일부 기기 그룹이 번들을 제대로 수신하지 못한 걸까요?
짧은 간격의 릴리스 모니터링은 노출 범위가 아직 제한적인 상태에서 롤아웃 결정을 관찰된 디바이스 동작과 연결합니다. 솔로 개발자에게는 유지보수할 인프라가 줄어든다는 뜻이고, 에이전시나 엔터프라이즈 팀에게는 각 클라이언트마다 새로운 프로세스를 발명하지 않고도 동일한 채널 규율과 근거를 여러 애플리케이션에 적용할 수 있다는 뜻입니다.
OTA 릴리스 전략 세우기
전략은 한 페이지에 담을 수 있지만, 긴급한 수정이 이를 시험하기 전에 작성해야 합니다. 게시 화면을 여는 것부터 시작하지 말고, 변경 사항을 분류하는 것부터 시작하세요.
순서대로 다섯 가지 질문을 하세요. 이것이 순수한 웹 레이어 code 또는 에셋인가요? 앱의 주요 목적, 결제 동작, 동의, 인증, 가격 또는 자격 요건 로직을 변경하나요? 안전하게 실행할 수 있는 최소 네이티브 버전은 무엇인가요? 어떤 채널과 대상이 먼저 확인해야 하나요? 문제가 발생하면 롤백, 롤포워드, 또는 스토어 릴리스를 요구해야 하나요?
그다음 긴급도에 따른 공정성을 부여하세요.
- 낮은 우선순위: 백그라운드에서 도착할 수 있는 일상적인 카피, 스타일링 및 콘텐츠 변경 사항.
- 중간 우선순위: 단계적으로 롤아웃하고 채택률을 면밀히 모니터링해야 하는 성능 또는 워크플로우 수정 사항.
- 높은 우선순위: 계속 사용 시 실질적인 위험을 초래하여 배포 차단 또는 네이티브 릴리스가 정당화될 수 있는 보안 또는 핵심 기능 문제.
해당 분류에 맞춰 운영 주기를 정하세요. 프로덕션과 유사한 데이터 경계를 사용해 내부 채널에서 테스트하세요. 설치 결과와 앱 신호가 허용 가능한 수준을 유지할 때만 범위를 넓히세요. 정상 동작이 확인된 번들, 노출을 중단하는 실패 임계값, 그리고 그 판단을 내릴 권한이 있는 담당자를 기록해 두세요.
문제없이 진행되는 OTA 릴리스는 게시 전에 대부분 결정됩니다. 채널, 임계값, 담당자, 중단 경로는 이미 정해져 있어야 합니다.
같은 주기 안에서 업데이트가 끊긴 기기들도 검토하세요. 마이그레이션 계획 없이 구버전 네이티브 사용자를 남겨두는 롤아웃은 아무리 매끄러워도 지원해야 할 제품을 두 개로 만듭니다. 최소 버전 정책, 스토어 릴리스, 번들 채널을 함께 연결하세요 앱 릴리스 자동화 를 통해 일상적인 점검이 누군가의 기억이 아니라 파이프라인에서 이루어집니다.
이렇게 하면 다음번 까다로운 케이스에 쓸 반복 가능한 테스트가 생깁니다. 이번 변경을 스토어 정책, 호환성, 컴플라이언스 이슈 없이 라이브로 배포할 수 있나요? 근거를 대고 답할 수 없다면 서두르지 말고 스토어 경로를 택하세요.
Capgo는 Capacitor 및 Ionic 팀이 네이티브 변경은 적절한 스토어 경로에 두면서, 단계적 롤아웃, 롤백, 릴리스 모니터링이 갖춰진 통제된 채널을 통해 적용 가능한 JavaScript, CSS, 에셋 수정을 배포할 수 있게 돕습니다. 이 의사결정 프레임워크를 실제 릴리스 프로세스로 만들 준비가 되었다면, 다음을 방문해 Capgo 첫 live update 채널을 설정하세요.
