보유하고 있는 앱 스토어 리뷰 4,000개, 읽지 않은 Zendesk 티켓 200개, 그리고 같은 엔지니어 3명이 전체 사용자 기반을 대표하는 것처럼 의견을 계속 올리는 Slack 채널. 팀은 피드백 수집에 바쁘지만, 가장 중요한 질문에 답할 수 있는 사람은 아무도 없습니다: 다음 릴리스에서 어떤 사용자 문제를 해결해야 할까요?
대부분의 피드백 수집 조언이 가진 핵심 문제입니다. 모든 채널을 동일하게 취급하고 모든 응답이 동등하게 유용하다고 가정합니다. CapacitorJS, Ionic, 또는 Electron 앱에서는 릴리스 채널이 피드백 시스템의 일부입니다. 카나리 빌드를 테스트하는 사용자는 안정적 릴리스 사용자에게서보다 더 많은 마찰을 감수하고 있으므로, 프롬프트, 질문, 후속 조치는 그 맥락을 반영해야 합니다.
실질적인 목표는 최대 응답량이 아닙니다. 바로 릴리스당 높은 신호 밀도이며,특정 코호트, 이벤트, 빌드, 제품 의사결정과 연결됩니다.
목차
- 대부분의 피드백 루프가 시작되기도 전에 실패하는 이유
- 앱에 적합한 피드백 채널 선택하기
- 솔직한 답변을 끌어내는 질문 설계법
- 샘플링, 세그먼테이션, 지표 읽기
- 툴링, 통합, 그리고 이를 하나로 묶는 스택
- 사용자와 릴리스로 피드백 루프 완성하기
- 30일 피드백 프로그램 롤아웃
대부분의 피드백 루프가 시작되기도 전에 실패하는 이유
팀은 우선 모든 것을 내보내는 것부터 시작합니다. App Store 리뷰는 스프레드시트로, Zendesk 티켓은 프로젝트 채널로 복사됩니다. 누군가는 엔지니어링 팀에 사용자에게서 무엇을 들었는지 묻습니다. 한 주가 끝날 무렵 조직은 이전보다 더 많은 피드백을 갖게 되지만, 백로그만으로는 내보내기 실패가 신규 사용자, 베타 테스터, 특정 OS, 단일 릴리스 중 어디에 영향을 주는지 여전히 알 수 없습니다.
실패는 수집 설계에서 시작됩니다. 모든 사람에게 같은 질문을 하는 팀은 서로 다른 여정 단계, 버전, 기대치를 가진 사용자들로부터 뒤섞인 답변을 받습니다. 깨진 워크플로우를 보고하는 stable 릴리스 사용자와 거친 부분을 설명하는 내부 테스터가 구분되지 않는 같은 큐에 들어가서는 안 됩니다.
세 가지 구조적 문제가 반복해서 나타납니다:
- 타겟 코호트 없음: prompt는 릴리스 채널, 기능 노출, 여정 단계, 최근 이벤트와 연결되어 있지 않습니다.
- 질문에 따른 결정 없음: 팀은 긍정적 또는 부정적 답변이 어떤 액션으로 이어질지 알지 못한 채, 사용자가 무언가를 “좋아하는지”만 묻습니다.
- 책임 소재가 불분명한 수신처: 응답이 설문 대시보드나 Slack 스레드에 머물러 다음 결정을 내야 할 제품 오너, 지원 리드, 또는 엔지니어에게 전달되지 않습니다.
실무 원칙: 모든 피드백 항목에는 코호트, 트리거 이벤트, 제안된 오너, 결정 날짜가 필요합니다.
채널 자체도 신호의 품질을 변화시킵니다. 외부 고객 설문 응답률은 보통 5%에서 15% 사이, 이메일 전용 설문은 종종 10%. 인컨텍스트 수집이 더 효과적입니다. 사용자가 방금 수행한 작업과 질문을 바로 연결할 수 있기 때문입니다. 현재 고객 피드백 벤치마크 앱 내 마이크로서베이, 상호작용 후 프롬프트, SMS, 웹사이트 인터셉트를 서로 다른 수집 환경으로 설명하며, 상호 교환 가능한 전달 방식이 아님을 강조합니다.
앱 스토리 리뷰는 여전히 중요합니다. 특히 사용자 획득과 대중적 신뢰 측면에서 그렇습니다. 하지만 타겟팅된 제품 루프의 대안은 아닙니다. 팀은 리뷰를 모니터링하고, 주제를 분류하며, 관련 보고서를 해당 릴리스와 연결해야 합니다. 리뷰의 더 넓은 중요성은 앱 리뷰와 평점이 중요한 이유, 하지만 운영 측면의 교훈은 간단합니다: 공개 피드백은 하나의 입력값일 뿐, 완벽한 리서치 패널이 아닙니다.
앱에 적합한 피드백 채널 선택하기
질문부터 시작한 뒤 채널을 선택하세요. 이미 설치되어 있다는 이유로 도구부터 고르면, 제품 의사결정에 필요한 데이터가 아니라 그 도구가 수집하기 쉬운 데이터만 모으게 됩니다.
채널을 상황에 맞추기
인앱 설문조사 의미 있는 상호작용 직후에 진행할 때 가장 효과적입니다. 특정 작업 완료 후 onboarding_completed 완료가 얼마나 쉬웠는지 물어볼 수 있습니다. 또한 특정 작업 후 export_failed 사용자가 어떤 결과를 기대했는지 물을 수도 있습니다. 반복적인 방해는 prompt 피로를 유발하므로 질문은 짧게 유지하세요.
베타 및 스테이징 채널 더 깊이 있는 정성 조사가 이루어져야 하는 곳입니다. TestFlight, Google Play Internal Testing, Electron canary build는 다소 번거로운 경험을 감수한 사용자에게 도달합니다. 이들은 미흡한 부분을 더 잘 견디고 무엇이 잘못됐는지 설명해 줄 가능성이 높습니다. 응답률은 2~4배 더 높음 브리프의 운영 전제에 따르면 광범위한 홍보보다 이러한 코호트에서 더 높게 나타나지만, 이를 보편적인 벤치마크로 삼기보다는 자체 프로그램에서 검증해야 할 기획 가설로 취급하십시오.
서포트 티켓 및 채팅 로그 사용 마찰에 대한 풍부한 설명을 제공합니다. 특히 막힌 워크플로우, 혼란스러운 에러, 누락된 문서를 발견하는 데 유용합니다. 다만 문제를 전혀 겪지 않는 사용자는 티켓을 거의 열지 않으므로 성공한 사용자를 잘 대표하지는 못합니다.
애널리틱스 및 이벤트 스트림 무슨 일이 있었는지 보여줍니다. 특정 이벤트 이후 사용자가 흐름을 이탈했다는 사실은 알 수 있지만, 원인이 혼란스러운 문구인지, 느린 요청인지, 기능 부재인지는 확실히 설명하지 못합니다. 행동 데이터에 짧은 맥락 질문을 함께 사용하세요.
App Store 리뷰 대중의 여론과 유입 단계의 우려 사항을 드러냅니다. 반복되는 불만을 감지하고 기존 피드백 프로그램 외부에서 제품이 어떻게 인식되는지 파악하는 데 유용합니다. 또한 극단적인 긍정 또는 부정 경험에 치우치는 경향이 있으므로, 평균적인 톤을 제품 상태의 유일한 척도로 사용해서는 안 됩니다.
| 채널 | 추천 대상 | 응답률 범위 | 왜곡/편향 | 운영 비용 |
|---|---|---|---|---|
| 앱 내 설문조사 | 마찰 또는 성공 순간 캡처 | 10%~30% | 활성 사용자 및 노출된 워크플로 | 보통 |
| 베타 또는 스테이징 채널 | 심층 릴리스 피드백 | 계획 가설로 2~4배 넓은 범위 아웃리치 | 자발적 참여, 관대한 테스터 | 보통 |
| 지원 티켓 및 채팅 | 블로커 및 실패 상세 | 표준화되지 않음 | 도움이 필요한 사용자 | 분석 공수 높음 |
| 애널리틱스 및 이벤트 스트림 | 사용자의 실제 행동 | 해당 없음 | 의도가 명시되지 않은 행동 | 엔지니어링 및 스토리지 공수 |
| App Store 리뷰 | 대중 인식과 발견의 마찰 | 표준화되지 않음 | 강력한 경험과 눈에 띄는 불만 | 낮은 수집률, 보통 수준의 분석 |
2025년 벤치마크는 460개 기업의 4,332개 설문 조사를 분석한 결과 중앙값 응답률 9.98%를기록했으며, 중간 50% 범위는 3.75%에서 21.69% 사이였습니다.또한 중앙값 응답률은 모바일 설문 18.69%,, 위젯 7.64%로 나타났습니다., 그리고 Intercom 설문 조사 5.41%. 이 수치들은 유용한 기준점을 제공합니다. 모든 형식이 의도가 높은 모바일 프롬프트처럼 작동하리라 기대하기보다 각 채널을 자체 과거 성과와 비교하세요. 이 시스템의 릴리스 채널 측면은 TestFlight 및 Android 테스트 워크플로 에서 확인하세요.
솔직한 답변을 끌어내는 질문 설계법
설문 질문은 위장된 제품 요구사항입니다. 질문을 작성하기 전에, 이 답변이 어떤 결정에 쓰일지 먼저 정하세요. 온보딩 재설계가 필요한지 결정하는 것이라면 완료 난이도를 물어보세요. 내보내기 실패를 사용자가 이해할 수 있는지 결정하는 것이라면, 실패 후 사용자가 무엇을 기대했는지 물어보세요.
질문 유형은 결정에 맞춰야 합니다:
- 리커트 또는 평가 척도: 감정, 노력, 또는 인지된 용이성을 측정합니다.
- 다중 선택: 가장 흔한 장애물을 식별하거나 사전 정의된 옵션을 우선순위에 둡니다.
- 자유 응답: 사용자가 해당 평가를 선택한 이유나 팀이 예측하지 못한 부분을 파악합니다.
약한 질문은 사용자를 동의 쪽으로 유도합니다:
“새로운 온보딩을 좋아하셨나요?”
기능과 사용자의 감정적 반응에 대한 가정도 함께 포함됩니다. 더 강한 버전은 다음과 같습니다:
“오늘 온보딩을 완료하는 것이 얼마나 쉬웠거나 어려웠나요? 가장 어려웠던 단계를 알려주세요.”
두 번째 버전은 구체적인 경험에 대해 묻고 비판의 여지를 남깁니다. 또한 측정 가능한 평가와 그 평가를 유용하게 만드는 설명을 분리합니다.
이벤트 발생 시 질문 트리거하기
CapacitorJS 앱에서는 다음 시점에 프롬프트를 표시하세요 onboarding_completed, 타이머가 만료되는 시점이 아닙니다. Electron에서는 다음 시점에 내보내기 질문을 표시하세요 export_failed, 사용자가 무엇을 하려 했는지 기억이 생생할 때입니다. 응답을 나중에 해석할 수 있도록 트리거에는 기능 이름, 빌드 식별자, 릴리스 채널, 로케일을 포함해야 합니다.
“온보딩과 계정 설정이 얼마나 쉬웠나요?”처럼 두 가지 질문을 한 문장에 담지 마세요. 이는 별개의 경험입니다. 척도는 구체적인 언어로 고정하고, 항목당 하나의 아이디어만 담으며, 사용자가 빠르게 답변하되 ‘왜’를 잃지 않도록 자유 텍스트 설명을 선택 사항으로 만드세요.
인터뷰, 사용성 세션, 설문조사, 행동 분석 중에서 선택해야 하는 팀을 위해, 사용자 리서치 방법론 에 대한 실무 개요는 리서치 방법을 질문에 맞추는 데 도움이 됩니다. 팀이 심층 탐색이 필요할 때 설문조사로 인터뷰를 대체하려 해서는 안 됩니다. 마찬가지로, 단일 이벤트 기반 평점으로 좁은 범위의 릴리스 결정을 검증할 수 있다면 인터뷰는 과합니다.
응답을 유발한 이벤트와 함께 저장하세요. 그러면 낮은 평점을 제품에 대한 막연한 기억이 아니라 실제 워크플로우와 연결할 수 있습니다. 또한 일반적인 만족도 점수보다 이탈 분석에 더 유용한 입력값을 제공하며, 특히 다음 지표와 함께 사용할 때 더욱 그렇습니다. 앱 성능 지표.
샘플링, 세그먼테이션, 지표 읽기
샘플링 오류는 좀처럼 티가 나지 않습니다. 대시보드는 정밀해 보여도, 함께 분석해서는 안 될 사용자들이 섞여 있을 수 있습니다. 베타 테스터, 정식 릴리스 사용자, 내부 직원이 같은 질문에 답하더라도 기대치와 결함 노출 정도는 다릅니다.
응답률 공식은 일관되게 사용하세요:
응답률 = 완료된 설문 수 ÷ 초대된 적격 사용자 수 × 100
이 계산은 대상 조건(eligibility)이 명확히 정의될 때만 의미가 있습니다. 기능을 본 적 없는 사용자는 제외하고, 닫은 prompt와 열지 않은 이메일 초대를 구분하세요. 또한 의도가 낮은 intercept 설문과 의도가 높은 이벤트 후 설문을 하나의 대시보드에 섞지 마세요.
릴리스 컨텍스트별로 세그먼트하기
앱 팀에게는 업데이트 채널이 운영체제보다 더 많은 정보를 제공합니다. Stable, beta, internal 코호트는 서로 다른 빌드 정책을 적용받으며 결함에 대한 허용도도 다릅니다. 기술적 차원을 추가하기 전에 기능 노출, 릴리스 채널, 여정 단계, 로케일 기준으로 세분화하세요.
2025년 벤치마크에 따르면 모바일 설문 응답률 중앙값은 18.69%였습니다이에 비해 iOS는 위젯 7.64%로 나타났습니다. 및 Intercom 설문 조사 5.41%. 이러한 차이 때문에 채널별 비교가 필수적입니다. 플랜과 채널별로 사용자를 세그먼트하는 가이드 비즈니스 맥락을 잃지 않으면서 이러한 코호트를 구조화하는 유용한 방법을 제공합니다.
| 피드백 채널 | 치우침 / 편향 | 일반적인 응답률 | 세그먼트별 최소 표본 수 |
|---|---|---|---|
| 인앱 인터셉트 | 해당 기능을 활발히 쓰는 사용자가 과대표집됨 | 보통 10%~30% | 의사결정 정밀도에 따라 설정 |
| 베타 또는 스테이징 | 부족한 부분을 감수할 의향이 있는 사용자만 참여 | 광범위한 배포보다 응답률이 높은 편 | 의사결정 정밀도에 따라 설정 |
| 지원 티켓 | 문제로 막힌 사용자가 과대 대표됨 | 표준화되지 않음 | 티켓 발생량에 따라 설정 |
| App Store 리뷰 | 강한 긍정·부정 경험 | 표준화되지 않음 | 평균만 보지 말고 테마 분석 |
| 이메일 설문조사 | 활동이 적은 사용자층까지 더 폭넓게 도달 | 이메일만으로는 10% 미만인 경우가 많음 | 응답과 의사결정 요구에 따라 설정 |
수치화하려면 응답률 계산과 채널별 벤치마크를 함께 활용하세요. 한 대형 플랫폼 데이터셋에 따르면 팝업 설문조사의 응답률은 3.65%였습니다, SMS: 18.54%, 웹 링크 설문: 29.95%, 모바일 SDK 인앱 설문: 34.37%, 그리고 이메일 설문: 49.17%성장한 수치로, 전체 고객 피드백 설문 평균: 31.81%. 이 수치는 별도의 수집 환경에서 나온 것이므로, 앱에 대한 약속으로 보기보다 채널 간 방향성 비교에 사용하세요.
단일 평가는 집계 과정에서 왜곡될 수 있습니다. 안정적 사용자가 내보내기 플로우에 낮은 점수를, 베타 사용자가 중간 점수를, 내부 사용자가 높은 점수를 준다면, 합산된 숫자는 중요한 릴리스 경계를 가립니다. 코호트를 가시화하고, 분모를 기록하며, 리뷰를 앱 사용을 중단한 사용자를 대표한다고 보기 전에 생존자 편향을 조사하세요.
툴링, 통합, 그리고 이를 하나로 묶는 스택
Notion 문서에 있는 설문은 Notion 문서에서 죽습니다. 실용적인 스택은 응답을 이벤트로 전환하고, 빌드와 연결하며, 담당자에게 라우팅하고, 릴리스 경계가 변경될 때 추세를 보여줍니다.
타이머가 아닌 이벤트 중심으로 빌드하세요
최소 스택에는 네 가지 구성 요소가 필요합니다:
- 이벤트 트리거 기반 설문 SDK: SDK은 다음과 같은 앱 이벤트에 반응해야 합니다
onboarding_completed,export_failed, 또는subscription_cancelled, 단순히 일정대로 프롬프트를 표시하는 것만으로는 부족합니다. - 행동 데이터 레이어: PostHog, Amplitude, 또는 자체 호스팅된 Mixpanel 배포를 사용하면 이전 이벤트와 기능 사용 데이터를 연결할 수 있습니다.
- 티켓 수집함: Linear, Zendesk, 또는 GitHub Issues로 에스컬레이션된 피드백을 안정적으로
feedback_id. - 릴리스 인식 대시보드: 빌드 및 롤아웃 경계를 기준으로 뷰를 새로고침하고, stable, beta, internal, locale, 앱 버전 필터를 제공합니다.
CapacitorJS 구현은 플러그인에서 기능 이벤트를 수신하고, 사용자가 워크플로우에 충분히 머물러 의미 있는 경험을 했는지 확인한 후 1~3개 질문의 프롬프트를 열 수 있습니다. 정확한 대기 시간은 보편적 상수가 아니라 워크플로우에 대해 테스트된 구성 값이어야 합니다. 중요한 것은 임의의 시계가 아니라 이벤트가 관련성을 결정한다는 점입니다.
응답을 다음과 같은 1급 속성과 함께 분석 도구로 전송하세요. app_version, channel, build_sha, locale, feature, 그리고 feedback_id. 빌드 SHA와 티켓 링크를 포함하여 간결한 알림을 Slack에 미러링하세요. 이를 통해 엔지니어는 모호한 불만을 지원팀에 번역해 달라고 요청하는 대신 동일한 릴리스에서 문제를 재현할 수 있습니다.
릴리스 메타데이터가 없는 응답은 메모일 뿐입니다. 릴리스 메타데이터가 있는 응답은 디버깅 입력값입니다.
피드백 플로우가 후속 조치나 베타 초대용 이메일을 수집하는 경우에도 검증이 중요합니다. 이메일 검증 API 알림 워크플로에 유효하지 않은 주소가 들어가기 전에 제거하는 데 도움이 되지만, 이메일 검증만으로는 깔끔한 이벤트 모델을 대체할 수 없습니다.
CapacitorJS에서 커스텀 이벤트 계측을 사용할 때는 의도적인 네이밍 컨벤션을 사용하고 페이로드 계약을 문서화하세요. 커스텀 이벤트 추적을 위한 Capgo 플러그인 앱 이벤트를 릴리스 기반 피드백 워크플로우와 연결하는 한 가지 방법입니다. Capgo 자체는 CapacitorJS 및 Electron 웹 번들에 타겟팅된 라이브 전달을 제공하며, 채널로 beta, staging, production 또는 고객별 스트림을 분리할 수 있습니다. 따라서 릴리스 코호트를 사후 고려 사항이 아니라 실질적인 피드백 속성으로 활용할 수 있습니다.
사용자와 릴리스로 피드백 루프 완성하기
실행이 따르지 않는 분석은 사용자의 노력을 운영상의 낭비로 만듭니다. 팀이 모든 요청을 반영하겠다고 약속할 필요는 없지만, 누군가 입력을 검토하고 결정을 내렸다는 사실은 보여주어야 합니다.
4단계 마무리 워크플로우를 사용하세요:
- 48시간 이내 트리아지: 항목을 버그, 사용성 문제, 요청, 질문 또는 노이즈로 분류합니다.
- 예상 릴리스 연결: 팀이 조사하거나 해결할 것으로 예상하는 build 또는 릴리스 경계를 기록합니다.
- 입력이 결정에 영향을 준 경우 회신: 결과가 “지금은 안 됨”일지라도 사용자는 설명을 들을 권리가 있습니다.
- 결과 게시: 변경 사항이 다루는 피드백 테마를 설명하는 changelog 항목을 추가합니다.
“피드백을 확인했습니다”라는 말은 아무것도 전달하지 못합니다. “4.2.0 버전의 iPad 회전 관련 제보는 4.2.3 버전에서 수정되었습니다”라고 해야 사용자가 직접 확인할 수 있는 구체적인 결과를 줍니다.
답변은 짧고 구체적으로 작성하세요:
버그 확인 시: “제보해 주셔서 감사합니다. 해당 워크플로우에서 회전 이슈를 재현했으며, 다음 유지보수 릴리스에 반영될 예정입니다. 빌드가 준비되면 다시 안내해 드리겠습니다.”
수정하지 않을 시: “요청하신 내용을 검토했으나, 기존 워크플로우와 충돌할 수 있어 현재 제품 방향성에는 포함하지 않기로 했습니다. 해당 유스케이스는 향후 계획을 위해 기록해 두었습니다.”
이미 수정된 경우: “다음 빌드에서 수정되었습니다. 현재 베타 버전으로 업데이트해 보시고, 동일한 현상이 발생하면 다시 말씀해 주세요.”
먼저 베타 사용자와의 피드백 루프를 완성하세요. 이들은 이미 릴리스 과정에 참여하고 있으므로, 유용한 답변 하나가 험난한 테스트 경험을 지속적인 참여로 바꿀 수 있습니다. 안정 버전 사용자가 명확한 changelog 개선 사항과 맞춤형 후속 조치를 보면, 다음 베타 그룹에 참여할 이유가 생깁니다. 이렇게 하면 테스터는 더 정확한 증거를 제공하고, 엔지니어는 더 많은 맥락을 갖고 출시하며, 사용자는 결과를 확인하는 릴리스 중심의 플라이휠이 만들어집니다.
30일 피드백 프로그램 롤아웃
유익한 첫 달은 방대한 조사 목록이 아니라, 하나의 신뢰할 수 있는 루프를 만드는 것이어야 합니다. 다음 릴리스에 중요한 단일 워크플로우부터 시작하세요. 팀이 피드백 수집부터 의사 결정, 그리고 실제 반영된 변경 사항까지의 과정을 추적할 수 있을 때 비로소 범위를 확장해야 합니다.
주차별 계획
1주 차, 점검 및 출시: App Store 리뷰, 서포트 티켓, 분석 이벤트, 기존 설문, 릴리스 채널을 목록화하세요. NPS 스타일 질문 같은 홈 화면 인앱 prompt 하나를 골라 정의된 코호트와 버전에 연결합니다.
2주 차, 베타 코호트 생성: TestFlight, Google Play 내부 테스트 또는 Electron canary 스트림을 설정하세요. 모든 사용자에게 안정 버전용 prompt를 보여주는 대신, 해당 코호트에는 테스트 중인 기능에 특화된 설문을 제공합니다.
3주 차, 분류 자동화: 서포트 티켓, App Store 리뷰 테마, 설문 응답을 하나의 dashboard로 연결하세요. 유의미한 수치 급증 시 Slack 알림을 추가하고, feedback_id모든 알림에 앱 버전, 채널, locale, build SHA를 포함하세요.
4주 차, 담당자 지정: 세 가지 답변 템플릿을 작성하고, 각 피드백 카테고리에 담당자를 지정하세요. 출시됨, 계획됨, 거절됨, 미해결 테마를 담은 첫 digest를 발행합니다.
첫 분기 동안 이 체크리스트를 활용하세요:
- 코호트 편향 점검: 파워 유저, 베타 테스터, 지원 연락처, 침묵하는 사용자를 하나의 집단으로 취급하지 마세요.
- 부정적인 리뷰를 가시적으로 유지하세요: 정교한 5성 테마는 특정 릴리스의 미해결 실패를 보상할 수 없습니다.
- Slack 메시지에 목적지를 지정하세요: 대화로 사라지지 않도록, 담당자가 있는 티켓이나 대시보드로 메시지를 라우팅하세요.
- 보고자에게 알림을 보내세요: 수정이 배포되면, 해당 문제를 정의하는 데 도움을 준 사용자에게 알려주세요.
- 신호 밀도를 측정하세요: 원시 응답량이 아닌, 릴리스별 실행 가능한 발견 사항을 추적하세요.
가장 강력한 피드백 프로그램은 릴리스마다 운영할 수 있을 만큼 작고, 의사결정이 왜 바뀌었는지 설명할 수 있을 만큼 구조화되어 있어야 합니다. 하나의 이벤트, 하나의 코호트, 하나의 오너, 그리고 프로덕션에 도달하는 하나의 응답부터 시작하세요.
Capgo는 CapacitorJS 및 Electron 팀을 위해 릴리스 채널, 대상 업데이트, 릴리스 관측 가능성을 연결하여 피드백을 생성한 빌드와 코호트와 연관 지을 수 있는 인프라를 제공합니다. 방문 Capgo 하여 모든 릴리스를 더 집중된 피드백 루프로 만들 수 있는 방법을 확인해 보세요.
