Capacitor 및 Capgo를 위한 TypeScript API 예제

모든 견고한 TypeScript API 예시를 보려면 Capacitor용은 같은 방식으로 시작됩니다. 바로 타입이 지정된 플러그인 인터페이스로 말이죠. 메서드, 옵션, Promise 결과를 명시적으로 정의하면 웹 code 및 네이티브 레이어가 TypeScript가 실제로 강제하는 하나의 계약을 공유하게 됩니다.

강력한 타입의 Capacitor 플러그인 인터페이스 구축하기

인터페이스는 웹 code가 보는 API를 설명합니다. 그 뒤의 네이티브 구현은 해당 계약을 준수해야 하며, TypeScript는 앱이 실행되기 전에 메서드 이름, 매개변수, 반환 값을 검사합니다.

import { registerPlugin } from ‘@capacitor/core’;

export interface DeviceStatus { online: boolean; batteryLevel?: number; }

export interface DevicePlugin { getStatus(): Promise;\nsetLabel(options: { label: string }): Promise<{ saved: boolean }>;\n}

export const Device = registerPlugin(‘Device’);

이 몇 줄 안에 많은 내용이 담겨 있습니다:

명시적 반환 타입 모든 결과를 예측 가능하게 유지합니다.
타입이 지정된 옵션 객체 컴파일 시점에 누락되거나 철자가 틀린 속성을 잡아냅니다.
Promise 기반 메서드 비동기로 완료되는 네이티브 작업을 모델링합니다.
제네릭 registerPlugin 호출 웹 API를 네이티브 브릿지에 연결하는 역할을 합니다.
인터페이스 런타임 code를 1바이트도 추가하지 않고 계약(contract)을 문서화합니다.

모든 호출부에 동일하게 적용됩니다:

const status = await Device.getStatus(); console.log(status.online);

await Device.setLabel({ label: 'Production' });

교체 { label: 'Production' } 위해 { name: 'Production' } 컴파일러가 즉시 잡아냅니다. 모바일 릴리스 후에 불일치를 발견하는 것보다 훨씬 낫습니다.

인터페이스는 옵셔널 값과 실패 케이스를 모델링하는 곳이기도 합니다. 네이티브 메서드가 항상 배터리 잔량을 반환할 수 없다면, batteryLevel?: number 모든 호출자에게 처리를 요구합니다 undefined.

아래 다이어그램은 타입이 지정된 메서드, 옵션, 반환값, 브리지 정의, 컴파일 타임 체크가 Capacitor API 내부에서 어떻게 연결되는지 보여줍니다.

모바일 개발 프레임워크를 위한 강력한 타입의 TypeScript 플러그인 인터페이스가 제공하는 주요 이점을 보여주는 다이어그램입니다.

핵심 아이디어: 타입 정의는 웹 인터페이스에서 네이티브 플랫폼 로직 쪽으로 흐르며, 컴파일 타임 체크가 모든 호출 지점을 지켜줍니다.

API 설계를 위한 빠른 참조

요소	목적	예시
메서드 시그니처	호출 가능한 동작 정의	`getStatus()`
옵션 타입	입력 형식 제어	`{ label: string }`
Promise 결과	비동기 작업 표현	`Promise<DeviceStatus>`
Result 인터페이스	반환 데이터 정의	`online: boolean`

더 자세한 참고를 위해 가이드를 읽어보세요 TypeScript로 API 구축하기. 두 가지 습관을 유지하세요: 클라이언트 code에서 시크릿과 서명 자격 증명을 제외하고, 게시 전에 각 플랫폼 구현과 인터페이스를 테스트하세요.

모바일 팀은 JavaScript, 네이티브 code, 디바이스 권한, 비동기 플랫폼 서비스를 동시에 다룹니다. 강력한 TypeScript 컨트랙트는 각 경계에서 공유 체크리스트처럼 작동해, code가 iOS나 Android 기기에 배포되기 전에 기대치를 명확히 합니다.

커피 머그잔 옆 책상에서 code가 표시된 노트북으로 코딩하는 사람.

구체적인 TypeScript API 예시를 보려면, 타입이 있는 값을 반환하는 메서드와 Promise<DeviceStatus> 타입이 없는 데이터를 반환하는 메서드를 비교해 보세요. 타입이 지정된 버전은 에디터와 모든 리뷰어에게 어떤 필드가 존재하는지 정확히 알려줍니다. 타입이 없는 버전은 그 발견 작업을 런타임 로그, 수동 테스트, 최악의 경우 프로덕션 장애로 떠넘깁니다.

도입 현황

TypeScript는 이제 프론트엔드라는 니치 마켓을 넘어섰습니다. 도입률은 2024년 기준 개발자의 35%까지 상승했으며, 이는 불과 2017년에는 12%, 그리고 100만 명이 넘는 GitHub 기여자 2025년까지 이를 주력 언어로 꼽았습니다. 전체 TypeScript 도입 결과 원본 수치가 궁금하다면 확인해 보세요.

이러한 흐름은 모바일 조직에 실질적인 영향을 미칩니다. 채용, onboarding, code 리뷰가 점점 공유 타입을 중심으로 돌아갑니다. Capacitor 프로젝트에 합류한 개발자는 모든 구현을 일일이 추적하지 않고도 interface만 보고 예상되는 native 동작을 이해할 수 있습니다.

Typed API를 사용하면 릴리스 작업을 더 쉽게 예측할 수 있습니다. 메서드가 특정 options object를 요구할 때, 속성 이름이 바뀌거나 필드가 누락되면 불완전한 native request를 조용히 생성하는 대신 컴파일 타임에 실패합니다.

강력한 타입 시스템은 핵심 피드백 시점을 앞당겨, 긴급 hotfix 릴리스 대신 단 몇 분 만에 수정할 수 있게 해줍니다.

Capacitor 팀을 위한 이점

크로스 플랫폼 앱은 보통 여러 native 구현체 위에 놓인, 웹에 노출되는 하나의 API를 제공합니다. TypeScript가 모든 native 세부 사항이 동일하게 동작함을 보장할 수는 없지만, 앱 전체에서 호출 방식을 일관되게 유지할 수는 있습니다.

명시적 타입을 적용할 대상:

메서드 입력값, 필수 및 선택 옵션 포함
Promise 결과, 성공 데이터가 항상 예측 가능한 형태를 갖도록
이벤트 및 리스너, 콜백이 알려진 페이로드를 처리하도록
오류 및 상태 값, 폴백 경로가 명확히 보이도록 합니다

이 구조는 디바이스 플러그인이나 운영 서비스 통합 시 그 가치를 발휘합니다. 업데이트 자동화를 검토하는 팀에도 도움이 되며, 잘못된 채널, 번들 식별자, 호환성 필드가 대규모 사용자 기반에 파급되는 문제를 방지할 수 있습니다.

관련 패턴에 대해 더 자세히 알고 싶다면 OpenAPI로 타입 지정된 API 생성 가이드를 읽어보세요. 공유 정의가 API 문서와 애플리케이션 code 사이에서 흔히 생기는 수동 불일치를 어떻게 줄이는지 다룹니다.

비즈니스 가치 증명하기

엄격한 타입 지정에는 어느 정도 초기 투자가 필요합니다. 특히 오래된 JavaScript code의 데이터 형태가 일관되지 않을 때 더욱 그렇습니다. 보상은 시간이 지나면서 나타납니다. 더 작아지는 리팩터링, 더 명확해지는 소유권, 통합 과정의 예상치 못한 문제가 크게 줄어드는 것입니다.

가장 리스크가 큰 경계부터 시작하세요:

네이티브 및 원격 호출에 대한 응답 인터페이스를 정의합니다.
옵션 객체와 이벤트 페이로드에 타입을 지정합니다.
엄격한 컴파일러 체크를 점진적으로 켭니다.
업데이트를 배포하기 전에 타입 체크를 필수로 겁니다.

엔터프라이즈 모바일 팀에게 이 기반은 플랫폼, 릴리스, 기여자가 달라져도 유지보수를 예측 가능하게 유지해 줍니다.

Capacitor의 ScreenOrientationPlugin은 아주 좋은 TypeScript API 예시를 보려면 예시입니다. 몇 가지 간단한 웹 메서드를 플랫폼별 디바이스 동작에 매핑하기 때문이죠. 공개 계약은 모든 플랫폼에서 동일하게 유지되고, 내부적으로는 iOS와 Android가 각자의 네이티브 세부 사항을 처리합니다.

import { registerPlugin } from '@capacitor/core';

export type OrientationType =\n| ‘portrait-primary’\n| ‘portrait-secondary’\n| ‘landscape-primary’\n| ‘landscape-secondary’;

export interface OrientationData {\ntype: OrientationType;\nangle: number;\n}

export interface LockOptions {\norientation: OrientationType;\n}

export interface ScreenOrientationPlugin { orientation(): Promise};\nlock(options: LockOptions): Promise;\nunlock(): Promise;\naddListener(\neventName: ‘screenOrientationChange’,\nlistenerFunc: (data: OrientationData) => void,\n): Promise<{ remove: () => Promise }>; }

export const ScreenOrientation =\nregisterPlugin(‘ScreenOrientation’);

각 시그니처에 대한 빠른 참조입니다:

orientation() — 현재 방향을 비동기로 읽어옵니다
lock() — 알려진 방향 값만 허용합니다
unlock() — 제어권을 기기의 정상 동작으로 되돌립니다
addListener() — 방향이 바뀔 때마다 타입이 지정된 페이로드를 발생시킵니다

모든 메서드가 Promise를 반환하므로, 네이티브 브리지와 브라우저 구현체 모두 동일한 호출 패턴을 사용할 수 있습니다. 분기 처리도, 예외 케이스도 필요 없습니다.

const current = await ScreenOrientation.orientation();

if (current.type.startsWith(‘landscape’)) {\nconsole.log("}Angle: ${current.angle}); }

await ScreenOrientation.lock({ orientation: 'landscape-primary', });

오타가 섞인 값을 입력하면 landscape-main 빌드가 즉시 실패합니다. 기기 로그를 뒤지며 쫓아다닐 플랫폼별 런타임 버그가 아니라, 몇 초 만에 고칠 수 있는 컴파일 에러입니다.

리스너 인자 타입을 정확히 지정하세요

리스너도 일반 메서드만큼 엄격하게 다뤄야 합니다. 다음은 피하세요 any 여기서는 이벤트 페이로드와 orientation() 반환합니다.

const handleChange = (data: OrientationData) => {\ndocument.body.dataset.orientation = data.type;\n};

const subscription = await ScreenOrientation.addListener( ‘screenOrientationChange’, handleChange, );

await subscription.remove();

단일 타입은 OrientationData 두 네이티브 구현체가 동일한 필드를 보장할 때만 공유하세요. 한 플랫폼에서 angle필드가 누락되면 optional로 표시하고 호출자가 처리하도록 강제하세요. undefined.

설계 선택	더 안전한 패턴
입력값	이름이 지정된 옵션 인터페이스
결과	명시적 Promise 타입
이벤트	리터럴 이벤트 이름
정리	제거 가능한 구독 반환

인터페이스는 네이티브 구현이 아닌 브리지 계약입니다. 작고, 예측 가능하며, 테스트하기 쉽게 유지하세요.

플랫폼 동작, 권한, 설치 단계에 대해서는 다음을 읽어보세요. Capacitor Screen Orientation 플러그인 가이드. 마지막으로 권장하는 습관 하나: 엄격한 TypeScript 설정에서 유효한 호출과 거부된 호출을 모두 테스트하세요. 이 조합은 모바일 애플리케이션 패키징 전에 잘못된 메서드 이름, 누락된 필드, 호환되지 않는 리스너 페이로드를 조기에 잡아줍니다.

Capgo은 Capacitor 팀이 앱 스토어 리뷰를 기다리지 않고 JavaScript, CSS, 설정, 에셋 수정 사항을 배포할 수 있는 방법을 제공합니다. 핵심은 업데이트 파이프라인을 다른 타입화된 API 경계처럼 취급하는 것입니다. 이렇게 하면 채널, 롤아웃 규칙, 호환성 검사, 롤백 결정이 번들이 사용자 기기에 도달하기 전에 명확하게 유지됩니다.

스마트폰을 든 사람이 세로 및 가로 화면 방향 모드의 차이를 보여줍니다.

업데이트 계약 정의하기

먼저 자동화가 허용하는 값을 정확히 정하세요. Literal union을 쓰면 실수로 잘못된 채널에 배포하는 일을 막을 수 있고, interface를 쓰면 bundle과 필요한 native version의 관계가 코드 자체로 드러납니다.

type Channel = ‘beta’ | ‘staging’ | ‘production’;

interface UpdateRequest {\nchannel: Channel;\nbundleVersion: string;\nminNativeVersion: string;\nrolloutPercent: number;\nsigned: boolean;\n}

interface UpdateResult {\naccepted: boolean;\nappliedOnNextLaunch: boolean;\nrollbackEnabled: boolean;\n}

간단한 TypeScript API 예시를 보려면 요청을 Capgo 클라이언트에 넘기기 전에 검증합니다:

async function publishUpdate(\nrequest: UpdateRequest,\n): Promise { if (!request.signed || request.rolloutPercent < 0 || request.rolloutPercent > 100) { throw new Error(‘Unsafe update request’); }

return capgo.publish(request);\n}

Capgo SDK 버전 간에 정확한 클라이언트 메서드 이름이 달라지므로, 자체 인터페이스로 감싸세요. 이렇게 격리하면 업그레이드할 때마다 효과를 발휘하고, 벤더별 세부 사항이 코드베이스 전반으로 새어 나가지 않게 해 줍니다.

Channel과 호환성 보호하기

Channel 선택은 가볍게 해서는 안 됩니다. 프로덕션 릴리스는 베타 실험보다 더 엄격한 검증이 필요하며, 특히 웹 번들이 이전 앱 버전에는 없던 native 기능을 호출할 때는 더욱 그렇습니다.

function canDeploy(\nrequest: UpdateRequest,\ninstalledNativeVersion: string,\n): boolean {\nreturn request.signed &&\ninstalledNativeVersion >= request.minNativeVersion;\n}

버전을 단순 문자열로 비교하지 마세요. 적절한 semantic-version 라이브러리를 도입해 1.10.0 뒤에 정렬되도록 1.9.0. Channel에 배포되기 전에 체크리스트를 하나씩 점검하세요:

번들이 서명되었는지 확인합니다.
대상 Channel이 의도와 일치하는지 검증합니다.
native와 번들의 호환성 범위를 비교합니다.
먼저 제한된 대상에게 배포합니다.
실패 신호를 모니터링하고 롤백 준비를 유지합니다.

타입이 지정된 업데이트 파이프라인은 릴리스 정책을 리뷰어와 CI가 실제로 검사할 수 있는 code로 바꿔 줍니다.

Capgo의 차등 배포와 채널 제어는 이 패턴에 잘 맞고, 디바이스 수준 관측성 덕분에 팀은 사후에 채택 또는 실패 신호를 추적할 수 있습니다. 이벤트 계측 쪽은 다음을 참고하세요: Capgo를 활용한 커스텀 이벤트 트래킹 가이드.

서명 키와 관리자 자격 증명은 배포되는 앱이 아니라 서버나 CI 시스템에 있어야 합니다. 다음 실행 시 업데이트를 적용하고, 의도적으로 거부된 번들로 롤백을 테스트하며, 모든 결정을 타입이 지정된 결과로 로그에 남기세요. 이 조합이면 빠른 배포와 엄격한 모바일 릴리스 제어를 함께 유지할 수 있습니다.

타입이 지정된 리스너 덕분에 비동기 API를 쉽게 신뢰할 수 있습니다. 콜백이 화면 방향을 추적하든 Capgo 업데이트 이벤트를 추적하든, 모든 플랫폼에서 동일한 페이로드 형태를 받아야 하며, 이를 강제하는 주체는 컴파일러여야 합니다.

interface UpdateEvent {\nversion: string;\nchannel: ‘beta’ | ‘production’;\navailable: boolean;\n}

type Listener = (payload: T) => void;

interface UpdateService {\naddListener(\nevent: ‘updateAvailable’,\ncallback: Listener,\n): Promise<{ remove: () => Promise{} }>;\nremoveAllListeners(): Promise; }

이 TypeScript API 예시를 보려면 이벤트 이름을 리터럴로 고정하고 콜백을 타입이 지정된 페이로드에 연결합니다. 에디터에서 version 무료로 자동 완성해 주며, 컴파일러는 관련 없는 데이터를 기대하는 콜백을 거부합니다. 설정은 조금만 하면 되고, API가 바뀔 때마다 제값을 합니다.

실제 동작을 보고 싶다면? 워크스루 영상을 보세요:

리스너를 안전하게 등록하기

컴포넌트 안에서는 구독 핸들을 계속 보관해 정리(cleanup)가 명시적으로 유지되게 하세요. 같은 패턴을 Angular 라이프사이클 훅, React effect, Vue mount 훅에 그대로 적용할 수 있습니다.

let orientationHandle: { remove: () => Promise } | undefined;

async function start() { orientationHandle = await ScreenOrientation.addListener( ‘screenOrientationChange’, ({ type, angle }) => { console.log(type, angle); }, ); }

async function stop() {\nawait orientationHandle?.remove();\norientationHandle = undefined;\n}

앱 전체가 종료될 때뿐만 아니라 화면이 사라질 때도 정리를 수행하세요. 이를 생략하면 화면을 이동해도 콜백이 네이티브 이벤트 소스에 연결된 채로 남습니다. 결국 중복 작업과 추적하기 어려운 오래된 상태 업데이트가 생깁니다.

각 프레임워크는 이를 위한 훅을 제공합니다:

Angular — 여기서 cleanup 트리거 ngOnDestroy
React — 여기서 async-safe cleanup 함수 반환 useEffect
Vue — 여기서 구독 해제 onBeforeUnmount

모든 addListener 호출에는 그에 맞는 제거 경로가 있어야 합니다.

적절한 Cleanup 방식 선택하기

하나의 컴포넌트가 하나의 구독을 관리할 때는 핸들을 반환하는 방식이 적합합니다. removeAllListeners() 서비스가 여러 리스너를 보유하고 전체를 초기화해야 할 때는 이 방식이 효과적입니다.

async function resetUpdates(service: UpdateService) {\nawait service.removeAllListeners();\n}

다른 화면이 해당 서비스에 여전히 의존하고 있을 때, 공유 컴포넌트에서 광범위한 메서드를 호출하지 마세요. 소유권이 로컬에 있을 때는 개별 remove() 핸들을 사용하세요.

상황	권장 조치
단일 컴포넌트 구독	호출하세요 `handle.remove()`
서비스 종료	호출하세요 `removeAllListeners()`
반복 등록	초기화 가드
알 수 없는 페이로드	사용 전 검증

Capgo 알림의 경우, 업데이트 페이로드를 디바이스 이벤트와 분리하세요. 그런 다음 등록, 전달, 정리 과정을 각각 따로 테스트하세요 — Capgo 커스텀 이벤트 트래킹 가이드 에서 통합 측면을 더 다룹니다.

출시 전 세 가지를 확인하세요: 언마운트가 실제로 핸들러를 제거하는지, 거부된 Promise가 잡히는지, 콜백이 파괴된 컴포넌트를 업데이트할 수 없는지입니다. 이 원칙을 지켜야 Angular, React, Vue 전반에서 반응형 Capacitor 앱이 원활하게 동작합니다.

헤드폰을 쓰고 듀얼 모니터 환경에서 code 작업을 하고 있는 전문 소프트웨어 개발자.

잘 설계된 TypeScript API 예시를 보려면 것은 의도를 나타내는 이름에서 시작됩니다. 메서드에는 동사를, 인터페이스에는 명사를 사용하고, 다음과 같이 일관된 접미사를 유지하세요. Options, Result, 그리고 Event. 명확한 이름은 온보딩 시간을 단축합니다. 개발자가 구현부를 열어보지 않고도 계약을 파악할 수 있기 때문입니다.

공개 인터페이스는 작게 유지하세요. 연관성이 약한 작업을 하나의 객체에 몰아넣기보다, 역할에 집중한 메서드로 기능을 노출하세요.

getStatus() 상태를 읽습니다.
updateConfig(options) 설정을 변경합니다.
addListener(event, callback) 변경 사항을 구독합니다.

입출력 타입을 정확하게 지정하기

파라미터가 늘어날 수 있다면 명명된 옵션 인터페이스를 사용하세요:

interface PublishOptions { channel: ‘beta’ | ‘production’; rolloutPercent: number; }

interface PublishResult { version: string; accepted: boolean; }

async function publish( options: PublishOptions, ): Promise { return client.publish(options); }

제네릭은 API가 서로 다른 payload를 감싸면서도 각자의 구체적인 타입을 유지해야 할 때 그 가치를 인정받습니다:

interface ApiResponse { data: T; requestId: string; }

async function request(path: string): Promise<ApiResponse> {\nreturn fetchJson<ApiResponse>(path); }

유연해 보이기 위해 제네릭을 남용하지 마세요. 제네릭은 입력과 출력 사이의 실제 관계를 표현해야 합니다. 그렇지 않다면 구체적인 interface가 읽고 유지보수하기 훨씬 쉽습니다.

잘못된 상태를 표현하기 어렵게 만드세요, 특히 네이티브, 네트워크, 업데이트 경계에서.

계약 바로 옆에 동작을 문서화하세요. 권한, 단위, 거부된 promise, 선택 필드, 그리고 메서드가 즉시 적용되는지 다음 실행 시 적용되는지까지 다루세요. 인라인 주석은 메서드 이름을 반복하는 것이 아니라 의사결정을 설명해야 합니다.

변경에 대비해 Code 정리하기

타입, 클라이언트 로직, 플랫폼 어댑터, 테스트를 예측 가능한 파일로 분리하세요. 공개 타입은 하나의 엔트리 포인트에서 내보내고 구현 세부 사항은 비공개로 유지하세요.

고려 사항	권장 위치
공개 인터페이스	`types.ts`
API 메서드	`client.ts`
네이티브 어댑터	`platform/`
호환성 테스트	`tests/`

플러그인에 Breaking Change가 있으면 새 메이저 인터페이스나 호환성 레이어를 도입하고, deprecated 메서드는 당분간 유지하면서 마이그레이션 단계를 문서화하세요. API 버전 관리 전략 알아보기 사용하는 쪽을 변경하기 전에

배포 전에 CI에서 엄격한 타입 검사와 컨트랙트 테스트를 실행하세요. Capgo 워크플로우에서는 채널 값, 네이티브 호환성, 서명된 번들, 롤백 동작을 타입이 지정된 릴리스 규칙으로 검증하세요. 이렇게 하면 팀, 플랫폼, 통합이 늘어나도 빠른 업데이트를 안정적으로 관리할 수 있습니다.

동적 Native 결과는 어떻게 타입 지정해야 할까?

…하게 두지 마세요 any 네이티브 메서드가 예측 불가능한 데이터를 반환할 때 그 데이터가 code로 흘러 들어가지 않도록 하세요. 대신, 신뢰할 수 있는 필드를 명시하고, 정말로 선택적인 값은 ?로 표시하고, 불확실한 입력은 다운스트림에서 건드리기 전에 경계에서 sanitize하세요.

interface NativeResult {\nsuccess: boolean;\nvalue?: string;\n}

async function readValue(): Promise { const result = await NativePlugin.read(); return { success: Boolean(result.success), value: typeof result.value === ‘string’ ? result.value : undefined, }; }

이 방식은 호출하는 쪽을 안전하게 지키면서 타입 자체에 불확실성을 분명히 드러냅니다. 이 인터페이스 패턴을 전반적으로 살펴보려면, TypeScript로 API 구축하기.

리스너가 Unhandled Rejection을 피하려면 어떻게 해야 할까요?

비동기 콜백은 설계 단계부터 방어적이어야 합니다. 이벤트 시스템이 거부된 promise를 조용히 삼켜줄 것이라 믿지 말고, 리스너 내부에서 직접 에러를 catch하세요.

const handleUpdate = (event: UpdateEvent): void => { void applyUpdate(event).catch((error: unknown) => { console.error(‘Update failed’, error); }); };

구독 참조를 유지하고 컴포넌트가 unmount될 때 제거하세요. 그러면 중복 콜백과 stale state 업데이트를 막을 수 있습니다. 리스너 라이프사이클 섹션에서 자세히 설명합니다.

모든 비동기 리스너에는 에러 처리 경로와 정리(cleanup) 경로가 모두 필요합니다.

Capgo 업데이트는 어떻게 보호하나요?

서명 키와 관리자 자격 증명은 서버나 CI 시스템에만 보관하세요. 끝입니다. 클라이언트는 서명된 bundle만 수신해야 하며, 타입이 지정된 결과는 상태 표시에만 사용해야 합니다. 서명 생성에는 절대 사용해서는 안 됩니다.

배포 전, 별도의 channel union을 설정하고, 호환성 검사를 실행하며, rollout 제한을 구성하고, 롤백 경로를 계획하세요. Capgo Capacitor 및 Electron 앱에 대한 서명된 배포, 채널 제어, 다음 실행 시 적용, 롤백 보호를 처리합니다. 문서에서는 타입이 지정된 릴리스 워크플로우가 업데이트 파이프라인을 어떻게 강화하는지 보여줍니다.