gRPC 스트리밍 vs REST 폴링: 언제 진짜로 중요한가

문제: 업데이트 요청 vs 업데이트 수신

폴링은 클라이언트가 타이머에 맞춰(예: 1초, 5초, 30초마다) 서버에게 계속해서 "업데이트 있나요?"라고 묻는 방식입니다.

스트리밍은 클라이언트가 한 번 연결을 열면 서버가 발생하는 업데이트를 그때그때 보내고, 다음 요청을 기다리지 않는 방식입니다.

이 한 가지 차이 때문에 작은 데모에서는 스트리밍과 폴링이 비슷해 보이지만 실제 제품에서는 전혀 다르게 동작합니다. 폴링에서는 미리 트레이드오프를 선택해야 합니다: 더 빠른 업데이트는 더 많은 요청을 의미합니다. 스트리밍에서는 연결을 열어두고 실제로 변경이 있을 때만 보냅니다.

실무에서는 몇 가지 요인이 결과를 바꿉니다:

폴링은 선택한 간격만큼만 최신 상태를 유지하는 반면, 스트리밍은 거의 즉시 느껴질 수 있습니다. 폴링은 또한 많은 "변경 없음" 응답을 만들어 양쪽 모두에 비용을 발생시킵니다(요청, 헤더, 인증 확인, 파싱). 모바일에서는 빈번한 폴링이 네트워크 라디오를 자주 깨워 배터리와 데이터 소모를 높입니다. 또한 폴링은 상태를 샘플링하기 때문에 간격 사이에 일어난 빠른 변화를 놓칠 수 있지만, 잘 설계된 스트림은 이벤트를 순서대로 전달할 수 있습니다.

간단한 예로 새 주문과 상태를 보여주는 실시간 운영 대시보드를 들 수 있습니다. 평온한 날에는 10초마다 폴링해도 괜찮을 수 있습니다. 하지만 팀이 1초 내 업데이트를 기대한다면 폴링은 느리게 느껴지거나 서버를 과도하게 요청하게 됩니다.

모든 앱이 실시간을 필요로 하는 건 아닙니다. 사용자가 가끔 한 번 페이지를 확인하는 경우(예: 월별 보고서)에는 1분 간격 폴링이나 수동 새로고침이 가장 간단하고 좋은 선택일 때가 많습니다.

폴링이 문제를 일으키기 시작하는 상황들

폴링은 간단해 보입니다: 클라이언트가 N초마다 "새로운 게 있나?"라고 묻습니다. 업데이트가 드물거나 사용자 수가 적거나 몇 초의 지연이 문제되지 않을 때는 잘 작동합니다.

문제는 자주 최신성이 필요하거나 사용자 수가 많아지거나 둘 다일 때 시작됩니다.

실시간 대시보드가 전형적인 사례입니다. 열린 티켓, 결제 실패, 레드 알림을 보여주는 운영 화면을 생각해 보세요. 숫자가 몇 초마다 변한다면 폴링은 사용자가 스파이크를 놓치게 하거나 API를 두드려대는 결과를 낳습니다(서버가 반복적으로 "변경 없음"에 응답하는 데 자원을 소비함).

진행 상황 업데이트도 흔한 함정입니다. 파일 업로드, 보고서 생성, 비디오 처리 같은 작업은 종종 몇 분이 걸립니다. 초당 폴링하면 UI는 "실시간"처럼 보이지만 많은 추가 요청을 만들고 여전히 점프하는 듯한 사용자 경험을 줍니다(클라이언트는 스냅샷만 보기 때문).

예측 불가능한 도착도 폴링을 비효율적으로 만듭니다. 채팅, 지원 대기열, 신규 주문은 10분 동안 조용하다가 30초 동안 폭주할 수 있습니다. 폴링은 조용한 시간 동안 비용을 지불시키고 폭주 시에는 지연 위험을 남깁니다.

IoT 스타일 신호는 문제를 더 악화시킵니다. 장치의 온라인/오프라인 상태, last seen, 작은 메트릭을 추적할 때 수천 건의 작은 변경이 누적될 수 있습니다. 폴링은 이를 지속적인 요청의 흐름으로 증폭시킵니다.

일반적으로 다음과 같은 패턴이 보일 때 폴링은 이미 문제를 일으키고 있습니다: 팀이 응답성을 위해 간격을 1~2초로 낮추고; 대부분의 응답이 업데이트를 포함하지 않지만 헤더와 인증을 소모하고; 서버 부하가 실제 변경이 아니라 열린 탭 수에 비례해 증가하고; 모바일 사용자가 배터리와 데이터 문제를 호소하고; 사람들이 대시보드를 열 때 트래픽 급증이 발생한다.

스트리밍이 실무에서 폴링을 이길 수 있는 이유

스트리밍의 핵심 이점은 단순합니다: 일반적으로 답이 "변경 없음"일 때 서버에게 같은 질문을 반복하지 않아도 됩니다. 폴링에서는 앱이 타이머에 맞춰 계속 요청을 보내서 변경이 없는 것을 확인합니다. 이로 인해 불필요한 트래픽, 추가 파싱, 타임아웃 가능성이 늘어납니다.

스트리밍에서는 서버가 하나의 연결을 열어두고 변경이 있을 때만 새 데이터를 푸시합니다. 주문 상태가 바뀌거나 메트릭이 임계값을 넘기거나 백그라운드 작업이 40%에서 41%로 이동하면, 다음 폴링 창을 기다리지 않고 업데이트를 즉시 받을 수 있습니다.

지연 감소는 단순히 속도만의 문제가 아닙니다. UI의 느낌을 바꿉니다. 폴링은 종종 눈에 띄는 "도약"을 만듭니다: 스피너가 나타나고 데이터가 한꺼번에 새로고침되며 숫자가 확 튀어 오릅니다. 스트리밍은 더 작고 잦은 업데이트를 만들어 더 부드럽고 신뢰감 있는 느낌을 줍니다.

스트리밍은 서버 작업을 더 이해하기 쉽게 만들기도 합니다. 폴링은 대개 매번 전체 응답을 반환하는데, 99%가 이전 응답과 동일할 수 있습니다. 스트림에서는 변경된 부분만 보낼 수 있어 바이트 수, 반복적인 DB 읽기, 직렬화 비용을 줄일 수 있습니다.

실무에서 차이는 다음과 같습니다: 폴링은 종종 "아무 것도 새로 없음"을 반환하는 짧은 요청을 많이 만든다. 스트리밍은 하나의 장기 연결을 사용하고 필요할 때만 메시지를 보낸다. 폴링 지연은 선택한 간격(2초, 10초 등)에 묶여 있지만 스트리밍 지연은 이벤트 자체에 묶입니다(업데이트가 발생하면 사용자가 즉시 본다). 폴링 응답은 전체 스냅샷인 경우가 많고 스트림은 작은 델타를 보낼 수 있습니다.

대시보드 예로 돌아가 보면: 5초마다 폴링하면 조용한 기간에는 호출을 낭비하거나 대시보드가 항상 몇 초 뒤처지는 것을 감수해야 합니다. 스트리밍이면 조용한 기간은 조용하고 티켓이 도착하면 UI가 즉시 업데이트됩니다.

사람들이 실제로 사용하는 스트리밍 패턴들

사람들은 스트리밍이라 하면 종종 모든 문제를 해결하는 "하나의 큰 라이브 연결"을 상상합니다. 실제로 팀들은 몇 가지 간단한 패턴을 사용합니다. 각 패턴은 다른 유형의 업데이트에 적합합니다.

1) 서버→클라이언트 스트리밍 (다운링크)

가장 흔한 패턴입니다: 클라이언트가 하나의 호출을 열고 서버는 발생하는 새로운 메시지를 계속 보냅니다. 사용자가 변화를 지켜보는 화면에 적합합니다.

라이브 운영 대시보드가 명확한 예입니다. 브라우저가 2초마다 "새 주문 있어?"라고 묻는 대신 서버가 새 주문이 도착하면 즉시 푸시합니다. 많은 팀이 연결 상태를 보여주고 끊김을 빠르게 감지하기 위해 가벼운 하트비트 메시지를 함께 보냅니다.

진행 상황 업데이트에도 동일한 아이디어를 적용할 수 있습니다. 보고서 생성에 3분이 걸린다면 서버는 마일스톤(대기 중, 10%, 40%, PDF 생성 중, 완료)을 스트리밍해 UI가 스팸 없이 움직임을 보여주게 할 수 있습니다.

2) 클라이언트→서버 스트리밍 (업링크)

이 패턴에서는 클라이언트가 하나의 호출로 많은 작은 이벤트를 효율적으로 보내고 서버는 끝에 한 번 응답하거나 최종 요약만 응답합니다. 데이터가 폭주할 때 유용합니다.

예를 들어 모바일 앱이 센서 판독값을 수집하거나 POS 앱이 오프라인 작업을 버퍼링할 때 네트워크가 가능해지면 수백 개의 개별 REST 요청보다 적은 오버헤드로 이벤트 배치를 스트리밍할 수 있습니다.

3) 양방향 스트리밍 (양쪽 통신)

양쪽이 언제든지 말할 수 있는 지속 대화에 적합합니다. 디스패처 툴은 현장 앱에 명령을 보내고 앱은 상태를 스트리밍으로 되돌려줄 수 있습니다. 여러 사용자가 같은 레코드를 동시에 편집하는 라이브 협업도 여기에 맞습니다.

결과가 단일 응답이거나 업데이트가 드물거나 캐시, 게이트웨이, 모니터링을 거치는 가장 단순한 경로가 필요하면 요청-응답 방식이 여전히 최선입니다.

단계별로 어떻게 결정하고 설계할지

화면에서 즉시 변경되어야 하는 것과 몇 초 정도 늦어져도 되는 것을 적어보는 것부터 시작하세요. 대부분 제품에는 작은 "핫" 부분만 있습니다: 실시간 카운터, 진행 바, 상태 배지 등.

업데이트를 두 개의 버킷으로 나누세요: 실시간으로 필요한 것과 "나중에 괜찮은" 것. 예를 들어 지원 대시보드는 새 티켓은 즉시 나타나야 하지만, 주간 합계는 1분마다 새로고침해도 아무도 눈치채지 못할 수 있습니다.

그다음 이벤트 유형의 이름을 정하고 각 업데이트를 작게 유지하세요. 매번 전체 객체를 보내지 마십시오. 실용적인 접근법은 TicketCreated, TicketStatusChanged, JobProgressUpdated 같은 이벤트를 정의하고 UI가 반응하는 데 필요한 최소 필드만 포함시키는 것입니다.

유용한 설계 흐름:

• 각 UI 요소에 최대 허용 지연을 표시하세요(100 ms, 1 s, 10 s).
• 이벤트 유형과 각 이벤트의 최소 페이로드를 정의하세요.
• 클라이언트가 연결 끊김 후 어떻게 복구할지 결정하세요(전체 스냅샷 또는 커서로 이어가기).
• 느린 클라이언트에 대한 규칙을 정하세요(배치, 업데이트 합치기, 오래된 것 드롭 또는 전송 빈도 줄이기).
• 스트리밍이 불가능할 때의 폴백 계획을 선택하세요.

재연결 동작은 많은 팀이 막히는 지점입니다. 기본 전략으로는: 연결 시 현재 상태의 스냅샷을 보내고 그다음에 증분 이벤트를 보내는 것입니다. 리줌(resume)을 지원하면 "last event id" 같은 커서를 포함해 클라이언트가 "18452 이후 것 보내줘"라고 요청할 수 있게 하세요. 이렇게 하면 재연결이 예측 가능해집니다.

백프레셔(클라이언트가 따라오지 못할 경우)는 "클라이언트가 따라오지 못하면 어떻게 할 것인가?"의 문제입니다. 라이브 대시보드에서는 업데이트를 합치는 게 자주 괜찮습니다. 진행률이 41%, 42%, 43%로 빠르게 변할 때 폰이 바쁠 경우 43%만 보내면 됩니다.

또한 스트리밍이 사용 불가할 때 제품이 여전히 유용하도록 폴백을 계획하세요. 일반적인 선택지는 임시로 5~15초 간격의 폴링으로 전환하거나 덜 중요한 화면에 수동 새로고침 버튼을 두는 것입니다.

AppMaster로 개발하면 종종 두 경로로 깔끔하게 매핑됩니다: "핫" 업데이트를 위한 이벤트 기반 흐름과 폴백용 표준 API 읽기입니다.

실제 예: 라이브 대시보드와 작업 진행 업데이트

재고 200개 SKU를 보여주는 창고 대시보드를 상상해보세요. REST 폴링이면 브라우저가 /inventory를 5초마다 호출해 전체 JSON 목록을 받고 테이블을 다시 그립니다. 대부분의 시간 아무것도 바뀌지 않지만 반복 요청, 전체 응답, 반복 파싱 비용을 지불합니다.

스트리밍이면 흐름이 바뀝니다. 클라이언트는 하나의 장기 스트림을 열고 초기 스냅샷을 받은 뒤(UI가 즉시 렌더링하도록) 변경이 있을 때만 작은 업데이트를 받습니다.

일반적인 대시보드 뷰:

• 초기 상태: SKU 전체 목록, 수량, 각 행의 "마지막 업데이트" 타임스탬프
• 증분 업데이트: 변경된 행만(예: SKU-184가 12에서 11로 변경)
• 신선도 신호: 전역 "데이터 최신 시점" 표시로 사용자가 신뢰할 수 있게 함

두 번째 화면으로 장시간 작업(예: CSV 가져오기, 월별 송장 생성)을 추가해 보세요. 폴링은 종종 어색한 도약을 만듭니다: 0%, 0%, 0%, 80%, 완료. 스트리밍은 더 정직하고 차분한 느낌을 줍니다.

진행 스트림은 보통 작고 빈번한 스냅샷을 보냅니다:

• 완료 비율(0~100)
• 현재 단계("Validating", "Matching", "Writing")
• ETA(추정치, 변경 가능)
• 최종 결과(성공, 경고, 오류 메시지)

델타 vs 스냅샷 선택은 중요합니다. 재고 같은 경우 델타가 좋습니다(매우 작음). 작업 진행은 각 메시지가 이미 작기 때문에 스냅샷이 안전한 경우가 많습니다. 재연결 시 누락된 메시지로 인한 혼란을 줄여줍니다.

AppMaster 같은 플랫폼에서 빌드하면 보통 읽기 모델(초기 상태) + 이벤트성 업데이트(델타)로 매핑되어 UI가 API를 과다 사용하지 않고도 반응성을 유지합니다.

모바일 클라이언트에서 달라지는 점

휴대폰에서는 "연속 연결"이 데스크톱과 다르게 동작합니다. 네트워크는 Wi‑Fi와 셀룰러 사이를 전환하고 터널이 리셋되며 사용자는 엘리베이터에 들어갑니다. 핵심은 세션이 언제든 사라질 수 있다는 관점으로 설계해야 한다는 점입니다.

끊김을 예상하고 안전한 재재생(replay)을 설계하세요. 좋은 스트림은 "last event id" 같은 커서를 포함해 앱이 재연결 시 "여기서부터 이어줘"라고 말할 수 있게 합니다. 그렇지 않으면 중복 업데이트(같은 진행 단계가 두 번 보임)나 누락(40%에서 90%로 건너뜀)이 발생합니다.

메시지가 작고 의미 있을 때 스트리밍은 배터리 수명을 개선하는 경향이 있습니다. 하지만 메시지마다 전체 객체를 초당 전송하면 데이터와 배터리를 빨리 소모합니다. "order 183 status changed to Shipped" 같은 간결한 이벤트를 선호하세요.

앱이 백그라운드에 있을 때 스트리밍은 보통 정지되거나 OS에 의해 종료됩니다. 명확한 폴백을 계획하세요: 마지막 알려진 상태를 보여주고 포그라운드로 돌아올 때 새로고침합니다. 긴급 이벤트는 플랫폼 푸시 알림을 사용해 사용자가 탭하면 앱이 열리고 동기화하도록 하세요.

모바일 대시보드 및 진행 업데이트에 대한 실용적 접근법:

• 재연결 시 백오프(backoff)를 적용해 나쁜 연결 상태에서 배터리를 낭비하지 않게 합니다.
• 이벤트 id나 타임스탬프를 포함하고 업데이트를 멱등하게 만들어 중복이 UI를 망치지 않게 합니다.
• 의미가 있으면 델타를 보내고, 우선순위가 낮은 업데이트는 배치합니다.
• 연결 시 스냅샷을 보내 UI가 올바르게 시작하도록 한 뒤 라이브 이벤트를 적용합니다.
• 간단한 버전 관리(메시지 타입 + 선택적 필드)를 추가해 오래된 앱 버전도 동작하도록 합니다.

AppMaster로 모바일 앱을 빌드하면 스트림을 "있으면 좋은" 경로로 취급하고 "유일한 진실 원천"으로 만들지 마세요. 짧은 끊김 동안에도 UI가 사용 가능해야 합니다.

방화벽, 프록시, HTTP/2 주의사항

스트리밍은 이론상 명확한 이점으로 보이지만 실제 네트워크가 개입하면 상황이 달라집니다. 핵심 차이는 연결입니다: 스트리밍은 보통 장기 HTTP/2 연결을 의미하며 이는 기업 프록시, 미들박스, 엄격한 보안 설정을 흔들리게 할 수 있습니다.

기업 네트워크는 TLS 검사(트래픽을 복호화하고 재암호화하는 프록시)를 사용할 수 있습니다. 이로 인해 HTTP/2 협상이 깨지거나 장기 스트림이 차단되거나 동작이 조용히 저하될 수 있습니다. 증상은 무작위 끊김, 스트림이 시작되지 않음, 업데이트가 부드럽게 오지 않고 버스트로 도착하는 등입니다.

클래식 gRPC는 HTTP/2 지원이 필수입니다. 프록시가 HTTP/1.1만 지원하면 정상적인 REST는 작동하지만 호출이 실패할 수 있습니다. 그래서 브라우저 환경에서는 gRPC-Web이 더 잘 통과하도록 설계되어 있는 경우가 많습니다.

로드 밸런서, 유휴 타임아웃, 킵얼라이브

네트워크가 HTTP/2를 허용하더라도 인프라스트럭처는 종종 유휴 타임아웃을 가집니다. 한동안 조용한 스트림은 로드 밸런서나 프록시에 의해 끊길 수 있습니다.

일반적인 해결책:

• 서버와 클라이언트에 적절한 킵얼라이브(ping) 설정을 둡니다(너무 잦지 않게).
• 로드 밸런서와 리버스 프록시의 유휴 타임아웃을 늘립니다.
• 긴 무응답 기간이 정상인 경우 작은 하트비트를 보냅니다.
• 재연결을 깔끔하게 처리합니다(상태를 이어가기, 중복 이벤트 회피).
• 클라이언트와 서버 양쪽에서 끊김 원인을 로그로 남깁니다.

gRPC-Web 또는 폴백을 선호할 때

사용자가 잠긴 기업 네트워크 뒤에 있다면 스트리밍을 최선의 노력(best-effort)으로 취급하고 폴백 채널을 제공하세요. 일반적인 분할은 네이티브 앱에는 gRPC 스트리밍을 유지하되, 브라우저 프록시 같은 네트워크에서는 gRPC-Web(또는 짧은 REST 폴링)을 허용하는 것입니다.

사용자들이 실제로 사용하는 장소에서 테스트하세요:

• 프록시 정책이 있는 기업 사내 네트워크
• 공공 와이파이
• VPN 연결
• 모바일 통신사 네트워크

AppMaster를 AppMaster Cloud나 주요 클라우드 제공자에 배포한다면 로컬 개발 환경뿐만 아니라 엔드투엔드로 이러한 동작을 검증하세요.

흔한 실수와 함정

가장 큰 함정은 스트리밍을 기본값으로 취급하는 것입니다. 실시간은 좋게 느껴지지만 서버 부하, 모바일 배터리 사용, 고객 지원 요청을 조용히 늘릴 수 있습니다. 어떤 화면이 정말 초 단위 업데이트가 필요한지 엄격히 판단하고 나머지는 30~60초 간격으로 새로고침하도록 시작하세요.

또 다른 실수는 이벤트마다 전체 객체를 보내는 것입니다. 분당 200KB짜리 JSON 덩어리를 매초 푸시하는 라이브 대시보드는 바쁜 시간이 되면 금방 문제가 됩니다. 작은 델타를 선호하세요: "order 4832 status changed to shipped"처럼 전체 주문을 다시 보내지 마세요.

보안도 종종 간과됩니다. 장기 스트림이라도 강력한 인증과 권한 검사가 필요하고, 중간에 토큰 만료에 대비해야 합니다. 사용자가 프로젝트 접근 권한을 잃으면 서버는 즉시 업데이트 전송을 중단해야 합니다.

재연결 동작은 특히 모바일에서 많은 앱이 실패하는 곳입니다. 폰은 Wi‑Fi와 LTE를 오가고 잠들고 백그라운드 처리됩니다. 몇 가지 습관이 최악의 실패를 막아줍니다: 끊김을 가정하기; 마지막으로 본 이벤트 id(또는 타임스탬프)에서 이어가기; 업데이트를 멱등으로 설계해 재시도가 중복을 만들지 않게 하기; 느린 네트워크에 대한 타임아웃과 킵얼라이브를 설정하기; 스트리밍이 실패하면 저빈도 폴링 같은 열악 모드 제공하기.

마지막으로, 팀들이 관측(모니터링) 없이 스트리밍을 배포하는 경우가 많습니다. 끊김 비율, 재연결 루프, 메시지 지연, 누락된 업데이트를 추적하세요. 서버는 100% 완료를 보고하는데 클라이언트가 20초간 70%에 머물러 있다면 지연이 어디서 발생하는지(서버, 네트워크, 클라이언트)를 보여줄 메트릭이 필요합니다.

스트리밍을 선택하기 전의 빠른 체크리스트

사용자에게 "실시간"이 정확히 무엇을 의미하는지 결정하세요.

지연으로 시작하세요. 대시보드가 실시간으로 느껴져야 한다면 1초 이하 업데이트가 스트림을 정당화할 수 있습니다. 사용자가 10초 또는 1분 정도면 괜찮다면 단순 폴링이 비용과 단순성 측면에서 이깁니다.

그다음 팬아웃(fan-out)을 보세요. 같은 데이터 피드를 많은 사람이 동시에 보는 경우(벽면용 운영 대시보드 + 50명의 브라우저 등) 폴링은 백그라운드 부하로 이어집니다. 스트리밍은 반복 요청을 줄이지만 여전히 많은 열린 연결을 처리해야 합니다.

간단한 결정 체크리스트:

• 변경이 얼마나 빨리 보여야 하는가: 1초 이내, 약 10초, 또는 약 1분?
• 동시에 동일 데이터를 보는 클라이언트 수는 얼마이며 얼마나 오래 보는가?
• 클라이언트가 30초 오프라인이면 어떻게 할 것인가: 오래된 데이터 보여주기, 업데이트 버퍼링, 또는 상태 재로딩?
• 네트워크 경로가 프록시와 로드밸런서를 포함해 끝까지 HTTP/2를 지원하는가?
• 스트리밍이 프로덕션에서 깨질 때 안전한 폴백(예: 임시 폴링)이 있는가?

또한 실패와 복구를 고려하세요. 스트리밍은 작동할 때 훌륭하지만 재연결, 누락 이벤트, UI 일관성 유지가 어렵습니다. 실용적인 설계는 스트리밍을 빠른 경로로 사용하되 재연결 후 현재 상태를 재구성하는 단일 REST 호출(리시크(sync) 액션)을 정의하는 것입니다.

대시보드를 빠르게 프로토타이핑하는 경우(예: AppMaster의 노코드 UI로) 이 체크리스트를 빨리 적용해 백엔드를 과도하게 구축하지 마세요.

다음 단계: 작은 스트림으로 파일럿하고 안전하게 확장하세요

스트리밍을 스위치 하나로 켜는 것이 아니라 얻어야 할 가치로 취급하세요. 신선도가 분명히 가치 있는 한 곳을 선택하고 나머지는 그대로 두세요.

작은 범위로 시작하세요: 장시간 작업의 진행 업데이트(파일 가져오기, 보고서 생성)나 라이브 대시보드의 한 카드(오늘의 주문, 활성 티켓, 현재 대기열 길이)처럼 하나의 고가치 스트림을 선택하세요. 범위를 좁히면 폴링과 실제 수치를 비교하기도 쉽습니다.

간단한 파일럿 계획:

• 성공 정의: 목표 업데이트 지연, 허용 가능한 끊김 비율, 모바일에서의 "충분히 좋음" 기준
• 최소 스트림 배포: 메시지 타입 한 개, 화면 한 개, 백엔드 엔드포인트 한 개
• 기본 지표 측정: 서버 CPU/메모리, 열린 연결 수, 메시지 지연, 재연결 빈도, 클라이언트 배터리 영향
• 폴백 추가: 스트림이 실패하거나 네트워크가 차단되면 자동으로 느린 폴링 모드로 전환
• 신중히 확장: 메트릭을 설명할 수 있을 때만 필드나 화면 추가

폴백을 의도적으로 유지하세요. 일부 기업 네트워크, 오래된 프록시, 엄격한 방화벽은 HTTP/2와 충돌할 수 있고, 모바일 네트워크는 앱이 백그라운드에 있을 때 불안정합니다. 우아한 다운그레이드는 빈 화면과 고객 지원 티켓을 피하게 해줍니다.

무거운 커스텀 코드를 쓰지 않고 이걸 배포하고 싶다면 AppMaster (appmaster.io)가 백엔드 로직, API, UI를 빠르게 빌드하고 요구사항 변화에 따라 반복하는 데 도움을 줄 수 있습니다. 작게 시작해 가치를 증명하고 폴링을 대체할 곳에만 스트림을 추가하세요.