느린 인터넷을 위한 엔지니어링: 남극에서 사용자 불편을 줄이는 방법

 (brr.fyi)
2P by GN⁺ | ★ favorite | 댓글 1개
  • South Pole의 인터넷은 제한된 위성 링크에 의존해 하루 몇 시간만 연결됐고, 2023년 10월 기준 커뮤니티 사용자는 높은 지연·낮은 대역폭·간헐적 단절을 감수해야 했음
  • 실제 환경은 왕복 지연 약 750ms에 수 초 지터, 수 kbps~2Mbps 속도, 혼잡·큐잉·패킷 손실·서비스 선점이 겹쳐 일반 앱의 네트워크 가정을 쉽게 깨뜨렸음
  • 큰 JavaScript 번들, 하드코딩된 타임아웃, 진행률 폐기, 캐시 무효화, 재개 불가능한 내장 다운로더는 느린 링크에서 앱이 스스로 실패하게 만드는 요인이었음
  • 바이트가 느리게라도 흐르면 기다리고, 청크 전송·재개·상태 표시·동적 타임아웃·수동 다운로드 링크를 제공하면 텍스트 메시지나 업데이트처럼 작은 목표는 달성 가능했음
  • 남극은 극단적 사례지만 해상 선박, 산악 연구지, 불안정한 Wi‑Fi, 품질 낮은 WISP, 전화선 기반 접속자도 비슷한 제약을 겪을 수 있어 사용자 진행을 방해하지 않는 설계가 필요함

South Pole 인터넷 환경의 제약

  • South Pole에서 인터넷을 제공하는 일 자체가 비사소한 엔지니어링 과제이며, 극지에서 쓸 수 있는 위성 선택지가 제한적임
  • NSF가 McMurdo와 Palmer의 Starlink 관련 발표를 했지만, 2023년 10월 기준 South Pole Station에는 비슷한 발표가 없었음
  • McMurdo는 최근까지 거의 1,000명과 여러 과학·운영 워크로드가 기지 전체의 수십 Mbps 수준 집계 대역폭을 공유했음
    • 미국 교외의 일반적인 4G 셀룰러 네트워크에서 개인이 얻을 수 있는 대역폭보다 적은 양을 기지 전체가 나눠 쓰는 상황임
  • South Pole은 위성이 지평선 위로 올라오고 기지가 사용 허가를 받은 시간에만 연결됐으며, 위성 일정은 항성시와 태양시 차이 때문에 대체로 하루 약 4분씩 앞당겨짐
  • 사용자가 체감한 지연은 일반적인 인터넷 경험과 크게 달랐음
    • 미국 본토 목적지까지 왕복 지연은 약 750ms
    • 미국 동부·서부 해안 간 왕복 지연 최대 75ms의 약 10배
    • 일반 가정의 케이블·광섬유 연결에서 주요 CDN까지 기대되는 최대 25ms의 약 30배
    • 사용자의 집 GPON 광섬유에서 Fastly, Cloudflare, CloudFront, Akamai, Google까지 약 3ms였던 것과 비교하면 South Pole은 250배 이상 큼

커뮤니티 사용자가 실제로 마주한 조건

  • 2023년 10월 기준 South Pole에서 커뮤니티 용도로 인터넷을 쓰는 개인은 다음 조건을 겪을 수 있었음
    • 평균 왕복 지연 약 750ms, 수 초를 넘는 패킷 간 지터
    • 최종 사용자 단말 기준 수 kbps에서 아주 좋은 날 2Mbps까지의 속도
    • 심한 혼잡, 큐잉, 패킷 드롭
    • 제한된 가용성, 잦은 드롭아웃, 가끔 발생하는 서비스 선점
  • 특정 상황에서는 40kbps, 1,000ms 지연, 최대 2,000ms 지터, 10% 패킷 손실, 몇 분마다 15초 완전 단절 같은 조건도 나타났음
  • 운영 트래픽이 강하게 우선순위를 받기 때문에, 커뮤니티 사용자는 남는 용량에 의존했음
  • 실시간 화상회의 같은 기능은 기대하기 어렵지만, 일부 앱에서는 몇 바이트짜리 텍스트 송수신이 가능했음
  • 느리거나 간헐적인 링크를 고려하지 않은 웹·앱 엔지니어링이 사용성을 더 악화시켰음

20MB JavaScript를 요구한 협업 웹앱 사례

  • 한 엔터프라이즈 협업 플랫폼은 메인 화면을 렌더링하기 위해 JavaScript만 거의 20MB를 내려받아야 했음
    • 이전 접속 이후 앱이 업데이트돼 브라우저 캐시 자산이 모두 오래되었고, 다시 다운로드해야 했음
  • 브라우저와 프로토콜은 느린 인터넷에서 혼잡 제어를 어느 정도 처리하지만, 이 앱은 자체 실패 조건으로 로딩을 끊어버렸음
    • 개발자가 정한 시간이나 재시도 횟수 안에 완전히 로드되지 않으면 앱이 중단됨
    • 에러 페이지로 리다이렉트됨
    • 이미 진행한 로딩 상태가 사라짐
    • 다음 재시도 때 강한 캐시 무효화 조치가 적용됨
  • 이 앱은 본질적으로 메시징 앱이었고, 실행 후 친구와 채팅할 때 실제 콘텐츠 페이로드는 바이트 단위였음
  • South Pole의 인터넷 성능은 개발자가 “허용 가능”하다고 본 경계에 걸쳐 있었고, 사용자는 여러 번 새로고침하며 같은 JavaScript를 다시 내려받아야 했음
    • 필요한 전송을 그대로 두면 15분 안에 끝낼 수 있었지만, 실제로는 몇 시간이 걸릴 때가 있었음
    • 성공 사례에서는 809개 HTTP 요청, 51.4MB 전송, 26.5분 로딩 뒤 1.8KB HTTPS POST로 6바이트 메시지를 보냈음
  • 앱이 데이터가 느리게라도 흐르는 동안 계속 기다리도록 설계됐다면 불필요한 재전송과 대역폭 낭비를 줄일 수 있었음

하드코딩된 타임아웃과 큰 단일 전송의 문제

  • 페이로드가 얼마나 빨리 전송될지, 한 요청에서 얼마나 많이 보낼 수 있을지에 대한 고정 가정은 느린 링크에서 앱을 망가뜨릴 수 있음
  • 바이트가 흐르고 있음을 측정할 수 있다면 아무리 느려도 전송을 중단하지 말고, 현재 상황을 UI로 보여주는 편이 나음
  • HTTPS 호출이 실패하면 더 긴 타임아웃으로 재시도하고, 큰 데이터는 작은 청크로 나눠 전송해야 함
    • 청크별 진행 상황을 추적해야 함
    • 실패한 작은 부분만 재시도하거나 재개할 수 있어야 함
    • 큰 데이터를 한 번에 보내려는 시도보다 느리고 꾸준한 증분 진행이 더 안전함
  • HTTPS 호출이 계속 실패하면 같은 호출을 맹목적으로 반복하기보다 DNS, ICMP, TLS 없는 HTTP, 알려진 정상 상태 엔드포인트로의 HTTPS 등을 점검해 사용자에게 상태를 알려야 함

  • 시작 시 메타데이터 다운로드 실패

    • 한 인기 데스크톱 앱은 시작할 때 벤더 웹사이트에서 설정 정보를 내려받으며, HTTPS 호출에 하드코딩된 타임아웃을 사용했음
    • 이 호출이 실패하면 앱은 로드되지 않고 같은 파라미터로 영원히 재시도했으며, 로딩 화면은 원인을 알려주지 않았음
    • South Pole에서는 계속 시도하면 결국 통과할 수 있었지만, 단일 타임아웃 값 하나가 엔터프라이즈급 앱을 거의 사용할 수 없게 만들었음
    • 더 나은 동작은 긴 타임아웃으로 단계적 후퇴, 연결 상태 점검, 원인 표시, 캐시·기본 설정 사용, 수동 다운로드와 설치 경로 제공이었음

  • 채팅 앱 두 개의 대비

    • 한 인기 채팅 앱은 WebSocket 초기화에 10초 하드코딩 타임아웃을 사용했음
    • TCP 핸드셰이크, TLS 세션, WebSocket 설정, 초기 시그널링이 모두 필요해 South Pole처럼 각 왕복이 여러 초 걸리는 조건에서는 10초를 넘길 수 있었음
    • 타임아웃이 지나면 앱이 동작하지 않고 긴 백오프 상태에 들어갔으며, UX는 상황을 명확히 보여주지 않았음
    • 경쟁 채팅 앱은 극도로 나쁜 네트워크 조건에서도 더 잘 동작했음
      • 여러 네트워크 요청 전략을 사용함
      • 열린 연결을 적극 재사용함
      • 타임아웃을 동적으로 조정함
      • 실패 시 재시도 간격을 지능적으로 선택함
      • 현재 네트워크 상태를 명확하게 보여줌
    • 두 앱 모두 실제로는 일반 텍스트 몇 바이트를 전송했지만, 네트워크 가정의 차이 때문에 사용할 수 있는 조건이 달라졌음

증분 전송과 재개 가능한 업로드

  • brr.fyi는 정적 Jekyll 블로그이며, 자산은 S3에 저장되고 CloudFront로 제공됨
    • 정적 파일은 로컬 노트북에서 빌드됨
    • S3로 직접 업로드됨
    • 서버, QA 환경, 빌드 시스템, 자동 훅, 동적 요소는 없음
  • South Pole의 제약을 고려해 만든 Python 게시 스크립트는 S3 API로 자산을 작은 청크 단위로 업로드했음
    • 실패한 업로드를 감지하고 진행 상황을 잃지 않고 재개함
    • 모든 파일이 안전하게 업로드될 때까지 새 버전을 게시하지 않음
    • 약 200줄의 Python으로 구현됨
  • 상용 블로그 플랫폼이나 소셜 미디어에 큰 파일을 올리는 사용자는 위성 창 안에서 한 번에 성공할 가능성에 맞춰 시간을 조절해야 했음
    • 실패하면 여러 번 재시도해야 했음
    • 콘텐츠가 올라갔는지, 업로드가 끝났는지, 다시 “Post”를 눌러도 되는지 명확하지 않은 경우가 있었음
  • 청크 POST가 실패해도 나중에 최소한의 손실로 재시도·재개할 수 있으면, 몇 KB씩이라도 편한 시간에 모아 업로드할 수 있음

내장 다운로더가 충족해야 하는 기준

  • 앱이 자체 다운로더를 만들려면 높은 수준의 품질이 필요하며, 그렇지 않으면 느린 인터넷에서 심하게 불편하거나 치명적으로 실패함
  • 가능한 경우 사용자가 내장 다운로더를 벗어나 직접 파일을 받을 수 있어야 함
    • 수동 다운로드 링크 제공이 유용함
    • 가능하면 전체 설치 파일보다 앱이 받으려던 차등 패치 파일 링크가 더 좋음
  • 수동 다운로드 링크의 장점은 명확함
    • 사용자가 브라우저처럼 더 견고한 다운로더를 선택할 수 있음
    • 파일을 한 번 받아 여러 장치에 공유할 수 있음
    • 앱이 실행되는 컴퓨터가 아닌 다른 컴퓨터에서 받을 수 있음
    • 사용자가 자신의 제약에 맞춰 다운로드를 예약하거나 관리할 수 있음
  • South Pole에는 24시간 인터넷이 없으므로, 매일 4시간 다운로드 창이 있더라도 그 시간 동안 받을 수 있는 데이터가 페이로드 크기보다 작으면 한 번에 완료할 방법이 없음
  • 많은 내장 다운로더는 일시정지·재개, 상태 알림, 재시도 로직, 진행률 추적이 부족하고, 다운로드 시간 제한 같은 제약도 있어 느린 인터넷에서 앱 전체의 사용 가능성을 좌우함

브라우저 다운로드 관리자가 기준점인 이유

  • 현대 웹 브라우저의 다운로드 관리자는 내장 다운로더가 비교될 수밖에 없는 높은 기준을 제공함
    • 중단, 일시정지, 재개 기능
    • 실패한 다운로드 재시도
    • 현재 상태, 속도, 남은 시간 표시
    • 저장 위치 선택과 파일 복사 가능성
    • 임의의 성능 컷오프 없음
  • 사용자가 60kbps로 수 GB 파일을 받겠다고 해도 브라우저는 이를 허용함
  • 앱이 브라우저 수준의 기능을 구현하지 못한다면, 최소한 사용자가 브라우저로 받을 수 있는 원본 URL을 제공하는 편이 나음

macOS 업데이트 사례

  • macOS 업데이트는 South Pole에서 특히 부담이 컸음
    • 마이너 OS 업데이트 패치 크기는 보통 0.5~1.5GB
    • 메이저 OS 업그레이드 패치는 때때로 6GB 이상
    • Xcode 같은 추가 도구도 여러 GB인 경우가 많음
  • 모든 macOS 장치가 Apple에서 직접 업데이트를 받으면 대역폭이 크게 낭비됨
  • macOS 내장 업데이터는 제어가 적고, 기저 패치 파일을 쉽게 얻을 방법이 없었음
    • 취소하거나 실패하면 항상 지능적으로 재개하지 않았고, 진행 상황을 잃는 경우가 있었음
  • Apple의 macOS 캐싱 서버 기능은 이론상 각 패치를 한 번만 South Pole로 내려받게 해 부담을 줄일 수 있었음
    • 실제로는 각 클라이언트 MacBook이 캐시 파라미터 협상을 위해 Apple에 HTTPS 호출을 성공시켜야 했음
    • 이 호출이 실패하면 클라이언트 Mac은 알림이나 재시도 없이 공용 Apple 서버에서 직접 패치를 받았음
    • South Pole에서는 이 초기 협상 호출이 자주 실패해 캐싱 기능이 유용하지 않았음
  • 전체 설치 파일은 Mr. Macintosh에 모인 링크를 통해 Apple에서 받을 수 있었고, 이를 느리지만 신중하게 받아 기지 내 배포할 수 있었음
    • 전체 설치 파일은 12GB였고, 다운로드에는 며칠이 걸릴 수 있었지만 신뢰성은 있었음
  • Apple Silicon Mac은 전체 설치 파일로 업데이트해도 펌웨어나 Rosetta 업데이트 등 추가 콘텐츠 1~2GB를 Apple에서 직접 내려받으려 했음
    • 이를 우회하거나 캐시할 방법이 없었음
    • 다운로드가 macOS의 별도 구성요소로 넘어가 설치 UI에 진행률이 반영되지 않는 경우도 있었음
    • “32분 남음” 화면이 몇 시간 동안 유지되며 백그라운드에서 1GB를 내려받는 상황이 발생했음
  • 필요한 패치 링크 제공, 일시정지·재개와 상태 관리 강화, 전체 설치 파일에 Apple Silicon용 추가 항목 포함, 캐싱 서버의 신뢰성과 제어권 개선이 필요했음

Samsung Android OS 업데이트 사례

  • Samsung Android 폰의 OS 업데이트 도구는 느리거나 간헐적인 인터넷을 고려하지 않은 사례였음
  • 업데이트 UI에는 속도 표시, 숫자 진행률, 일시정지, 취소, 파일 크기 표시, 별도 다운로드용 파일 접근 방식이 없었음
  • 다운로드가 실패하면 재개할 수 없고 처음부터 다시 시작했음
  • South Pole에서는 한 번의 위성 패스 안에 전체 OS 업데이트를 받을 수 없어, 연결이 끊기면 반드시 실패하고 처음부터 다시 해야 했음
  • 실제로는 인터넷이 끊기기 직전 폰을 완전히 끄고, 다음 위성 패스 때 다시 켜는 방식으로 다운로드 실패 판정을 피했음
    • 이 방식으로 여러 위성 패스에 걸쳐 다운로드를 나눠 완료할 수 있었음
    • 이런 우회는 필요하지 않아야 하는 비정상적인 해결책이었음
  • Verizon의 macOS·Windows용 업데이트 앱은 이론상 컴퓨터에서 OS 업데이트를 플래시할 수 있게 하지만, 실제로는 버그가 많고 신뢰성이 낮으며 자체 내장 다운로더를 사용했음
  • 문제의 핵심은 벤더가 제공하는 일반 사용자용 도구가 느린 인터넷 사용자에게 부족한 기능을 제공한다는 점임

작은 앱 업데이트와 Microsoft Office for Mac의 대비

  • 한 작은 데스크톱 앱의 내장 업데이터는 느린 링크에서 필요한 기본 기능이 부족했음
    • 일시정지 버튼
    • 취소 버튼
    • 진행률 표시
    • 속도나 남은 시간 표시
    • 원본 URL 접근
    • 진행률 추적과 중단된 다운로드의 자연스러운 재개
  • 이 앱은 수동 다운로드 링크만 제공해도 South Pole 사용자에게 크게 나아질 수 있었음
  • 다른 앱의 자동 업데이터는 취소 버튼과 시각적 진행률 표시는 있었지만, 일시정지, 숫자 진행률·속도, 원본 URL 접근, 재개 기능이 부족했음
  • Microsoft Office for Mac의 자동 업데이터는 South Pole에서도 좋은 사례였음
    • 일시정지 버튼
    • 취소 버튼
    • 진행률 표시
    • 속도와 남은 시간 표시
    • 중단된 다운로드의 자연스러운 재개
  • 원본 URL을 제공했다면 더 좋았겠지만, 인터페이스가 충분히 좋아 South Pole에서도 사용하기 괜찮았음

느린 인터넷 사용자를 위한 실무적 설계 원칙

  • 빠른 인터넷 환경에서는 작은 누락처럼 보이는 기능도 느린 인터넷에서는 주요 장애가 될 수 있음
  • 앱은 고정 타임아웃 하나 때문에 사용자가 몇 바이트의 텍스트도 보내지 못하는 루프에 빠지지 않도록 설계돼야 함
  • 가능한 설계 원칙은 단순함
    • 바이트가 움직이면 중단하지 않음
    • 큰 페이로드는 청크로 나눔
    • 실패해도 진행 상황을 보존함
    • 네트워크 상태를 사용자에게 명확히 보여줌
    • 내장 다운로더가 부족하면 수동 다운로드 링크를 제공함
  • South Pole은 엣지 케이스지만, 해상 선박의 Inmarsat 환경, 산악 연구지의 Thales MissionLink와 Iridium Certus, 불안정한 Wi‑Fi, 잘못 구성된 라우터, 품질 낮은 WISP, 낡은 전화선 기반 다이얼업 사용자도 비슷한 제약을 겪을 수 있음
  • 개발자가 모든 극단 상황을 최적화할 필요는 없지만, 제품이 느린 연결 사용자의 진행을 적극적으로 방해하지 않도록 만드는 노력은 필요함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 글이 많이 와닿음. 남극은 아니고 베이징에 있지만 인터넷 때문에 여전히 고생함
    만리방화벽 뒤에 있으면 창의적인 방법을 써야 하고, VPN도 가끔만 동작함. VPN마다 흔적이 남아서 방화벽의 휴리스틱과 기계학습이 결국 잡아내며, 국가가 허용한 VPN조차 정치적으로 민감한 시기에는 “부드럽게” 제한됨
    결국 연결이 돼도 안정적이지 않고, 귀한 패킷을 쓸모없는 웹앱/React 왕복 요청에 낭비하는 게 너무 고통스러움
    일부 개발자는 2005년쯤으로 시간여행해서 그 시대 기준으로 개발해봐야 가볍게 만드는 법을 배울 듯함. 시간여행이 안 된다면 개발자 도구의 속도 제한을 켜고 3G로 맞춘 뒤 자기 웹앱이 버티는지 제발 확인했으면 함

    • 시간여행을 발명할 필요 없이, 며칠 동안 나쁜 모바일 연결만 있는 곳에서 워킹 리트릿을 시키면 됨
    • Shoreditch에서 7년 살았는데, 살던 집 대부분의 인터넷 속도가 거의 3G 수준이었음. 마지막 집은 창문이 우연히 패러데이 케이지처럼 동작했음
      항상 프로젝트를 제한된 대역폭에서 테스트함. 접근성과 마찬가지로 좋은 관행을 따르면 연결이 나쁜 사용자뿐 아니라 모든 사용자에게 더 나은 사용자 경험이 되기 때문임
      자주 놓치는 또 다른 기회는 단일 페이지 앱을 오프라인 우선으로 만드는 것임
    • 느린 인터넷을 고려해 설계하고 있고, React는 서버 사이드 렌더링, 코드 분할, HTTP/2 push, Tauri 같은 더 오프라인 친화적인 클라이언트와 섞으면 그쪽에서 꽤 좋은 선택지 중 하나임. “엣지”에서 동작한다면 사용자 가까이에 배포할 수도 있음
      전체 요지에 꼭 반대하는 건 아니지만, 현대 JavaScript는 서버-클라이언트 “애플리케이션”에서 느린 인터넷을 다루는 데 실제로 꽤 좋음. 다만 쉽게 하기는 어렵고, Google/GPT로 코딩하는 사람이 프로젝트의 기반으로 삼을 만한 온라인 자료가 거의 없음
      이는 온라인에 형편없는 JavaScript 자료가 너무 많은 탓도 있지만, 이런 방식으로 일하는 조직들이 공유하지 않는 영향도 큼. 우리도 경쟁사에 정보를 넘길 이유가 없어서 작업 방식에 대한 공개 자료가 0개임
    • 연결이 잘 된 도시에 살지만, 회사가 다른 대륙에 있는 가상 머신만 비용 처리해줘서 대부분의 프로젝트가 “빠르지만” 지연 시간에 묶임
      모든 것에 왕복 요청을 쓰길 기대하는 기술에서 쓸모없는 왕복을 줄이는 흥미로운 훈련이 됨
    • 중국에서 여러 VPN을 시도하다가 결국 Wireshark용 난독화 계층을 직접 만들었음. 검색해보니 GitHub에 비슷한 프로젝트가 여럿 있었지만, 이런 건 눈에 띄기 시작하면 예전만큼 잘 안 되는 듯함
      아직도 1~10Mbit/s 정도는 나오고, 대체로 시간대에 따라 달라지며 연결 문제는 거의 없음

  • 지하 대중교통 통근 경험이 많고(간헐적·혼잡), 호주에서 살고 일해본 입장에서, “이상적인” 네트워크 조건이 아닌 사람들에게 대부분의 서비스는 형편없다고 자신 있게 말할 수 있음
    London Underground에서는 대부분의 앱이 약 2분마다 끊겼다 붙는 네트워크를 정말 못 다루는 게 특히 두드러짐. 역 사이에서 끊기고, 승객 500명이 탄 열차가 동시에 접속하려 하니 각 접근점에 연결하는 데도 15초쯤 걸림
    호주에서는 대체로 모든 곳에서 200ms 떨어져 있음. 별것 아닌 것처럼 보일 수 있지만, 어떤 앱이 N+1 요청 문제에 걸려 넘어지는지 아주 잘 드러남
    항상 인상적인 유일한 앱은 WhatsApp임. 재연결 뒤 가장 먼저 동작하고, 끊기기 직전까지도 마지막으로 트래픽을 통과시키며, 지연 시간이 있어도 통화가 꽤 빠르게 느껴짐

    • 200ms가 많은 걸 말해줌
      WhatsApp은 실제로 호주에 서버를 배포한 드문 서비스 중 하나일 가능성이 큼. 200ms는 대륙 간 트래픽이라는 강한 신호로 보임
      대부분의 글로벌 회사는 많아야 세 지역, 즉 미국(us-east, us-central, us-east+us-east), 유럽(west-europe), 그리고 비교적 드물게 극동(us-west 또는 일본)에만 배포함
      그래서 남아프리카, 남미, 호주 같은 곳은 보통 이 지역 중 하나에서 데이터를 가져와야 하고, 물리 한계 때문에 최소 200ms 지연 시간이 생김
      호주는 특히 타격이 큼. 이론상 관할권에 전용 배포가 있더라도 실제 서버가 완전히 다른 대륙(미국 서부나 일본)에 있는 경우가 많아, 사용자는 패킷이 지구 반 바퀴를 도는 성능 영향을 그대로 겪음
    • WhatsApp은 느린 인터넷과 훨씬 느린 기기가 흔한 개발도상국 사용자층이 엄청나게 큼
      그런 관점이 개발 목표에 깊이 박혀 있었기 때문에, WhatsApp이 세계 여러 나라에서 대표 메신저가 될 충분한 이유가 생겼다고 봄
    • 서비스 자체만의 문제도 아님. 아주 느린 모바일 연결을 쓰는데, 브라우저에서 이미지를 내려받는 일이 정말 짜증났음
      브라우저에서 .jpg URL을 열어 이미지를 보려 하면, termux로 넘어가 wget을 실행할 때보다 훨씬 오래 걸리고 때로는 시간 초과가 남. Firefox와 Chrome 계열 브라우저 모두에서 겪었음
      참고로 wget 다운로드도 모바일 연결에서는 보통 10~30초가 걸림
    • London에서는 역에서만 Wi-Fi가 되는 것 같은데 Berlin도 같음. Helsinki에서는 열차 안과 역 모두에서 Wi-Fi가 돼서 이동 중 연결이 끊기지 않음
      Berlin이 왜 이렇게 했는지 이해가 안 됨. 그냥 열차 안에 인터넷을 제공하면 될 텐데
      네트워크가 계속 끊기면 인터넷 대부분이 정말 형편없이 동작함
    • London Underground가 다른 지하철 시스템보다 수십 년 늦게까지 연결성을 제공하지 않았다는 사실은, 통근 중 높은 연결성이 필수는 아니라는 것만 보여줌

  • 여행을 많이 하는데 느린 인터넷은 꽤 흔함. 지금도 모바일 데이터가 다 떨어져서 8kbps로 제한되어 있음
    그냥 페이지에 텍스트만 있는 웹사이트는 빨라야 하는데, 그렇지 않은 곳이 많음. Hacker News는 엄청 빠르지만 Google API 문서는 아예 안 열림
    가장 나쁜 문제는 대부분의 UI가 느린 요청을 고려하지 않는다는 것임. 버튼이 고장 난 것처럼 느껴지고, 메가바이트 단위 데이터가 필요 없어야 할 것들도 로드에 몇 분이 걸리거나 실패함. Google Maps UI 전체가 망가짐
    개발자들이 느린 인터넷을 더 많이 설계하고 테스트했으면 좋겠음. 대신 빠른 회사 노트북과 빠른 인터넷에서만 잘 동작하는 데이터 탐식 웹사이트가 나옴
    관련해서, 웹사이트를 운영하며 먹고사는데 정적 사이트 생성기로 옮긴 건 생산성 면에서 최고의 선택 중 하나였음. CMS 지연 시간이 모든 작업에 스며드는 대신, 완전 오프라인에서도 텍스트 파일을 엄청 빠르게 편집하고 온라인이 되면 변경사항만 push하면 됨. 판이 바뀜

    • 예전 Google은 느린 앱을 잘 챙겼음. 학교 컴퓨터에서 Gmail을 쓰던 시절, 사이트가 너무 느리게 로드되면 이를 감지해서 기본 HTML 버전을 대신 띄웠음
      요즘은 휴대폰에 Google Maps 캐시 500MB를 받아도 의미가 없는 것 같음. 여전히 모든 걸 가져오고 뒤늦게 튀어나옴
    • 정적 사이트의 추가 장점 하나를 힘들게 배웠는데, 공격에 대체로 면역이라는 것임
      최신 WordPress를 쓰지 않았다는 이유로 현재 내 도메인 하나가 “위험”으로 표시되어 있음
    • 예전에 그 문서를 서비스하는 팀에서 일했음. 문서를 동적·인터랙티브하게 만들겠다는 명목의 불운한 기술 결정 때문에 거의 전부 캐시되지 않음
      기본적으로 보내는 모든 요청이 AppEngine 앱에 닿고, 그 앱이 Python 코드를 실행해 HTML을 돌려줌. 그래서 빨라 보여야 할 것 같은데 실제로는 그렇지 않음
    • 상황이 항상 그렇게 단순하지는 않음
      영국에 있는데 news.ycombinator.com까지 ping이 147ms임. CDN을 쓰지 않고 미국에서 호스팅되기 때문으로 보임
      반면 cloud.google.com은 ping이 8ms임
      Hacker News는 단순하고 JavaScript가 적은 페이지지만, 어떤 지역 사용자에게는 느리게 느껴지게 만드는 다른 요인도 있을 수 있음. 대칭 8Gbps를 제공하는 XGS-PON 광회선을 쓰는 특권적 환경에서도 그렇다

  • 빙상에서 막 내려온 사람을 히치하이킹 중에 태워준 적이 있는데, 그가 말하길 그 블로그 작성자는 글이 훌륭하긴 하지만 이미지 업로드 중 이미 제한된 대역폭을 잡아먹는 경우가 많아 주변 사람들에게 어느 정도 미움을 샀다고 함
    다만 행정 쪽에서 홍보 가치를 알아봤기 때문에 우선권을 받았다고 함. 느린 인터넷 논의와 잘 맞물린다고 생각했음

    • 실제 운용이 궁금했음. 모든 사람이 자기 운영체제나 앱이 언제 업데이트를 시작하는지 아는 건 아님
      주머니 속 휴대폰이 불필요하게 가능한 모든 대역폭을 쓰고 있을 수도 있고, 720p 동영상을 보면서 겨우 재생되는 수준이라 하더라도 그 뒤에 로드하려는 사람은 480p조차 못 보게 될 수 있음. 본인은 버퍼가 있어서 눈치 못 채고, 상대는 버퍼가 충분히 차기 전에 포기할 수 있음
      최소한 지난 1시간 트래픽 중 몇 %가 본인에게 갔는지, 그리고 사용 가능 대역폭을 연결 사용자 수로 나눈 기준값과 비교해 모두가 동등하게 필요했다면 자신의 몫이 몇 %였는지 알려주는 사용량 회계가 있어야 할 듯함
      더 나아가 “네, 앞으로 [X≤24]시간 동안 쓸 대역폭을 알고 있으며 실제로 필요합니다” 버튼을 누르기 전까지는 모두를 낮은 우선순위로 두고, 누르면 MAC/IP 주소의 QoS 우선순위를 정상으로 올리는 시스템도 가능해 보임

  • 이런 상황은 로컬 우선 애플리케이션과 해법이 필요하다고 외치고 있고, 애초에 인터넷이 만들어진 이유도 그쪽임 [1][2]
    사람들은 Salesforce의 “No Software” 광고 문구에 속았는데, 이는 인터넷의 기반과 정신에 정면으로 어긋남. 1969년부터 인터넷 역사의 대부분에서 Mbps는 예외였지 표준이 아니었고, 첫 킬러 앱인 이메일 메시징은(아마 지금도 최고의 인터넷 앱) 로컬 우선임 [3]
    아이러니하게도 글쓴이가 한탄한 문제의 애플리케이션도 메신저 앱임
    [1] Local-first software: You own your data, in spite of the cloud:
    https://www.inkandswitch.com/local-first/
    [2] Local-first Software:
    https://localfirstweb.dev/
    [3] Leonard Kleinrock: Mr. Internet:
    https://www.latimes.com/opinion/la-oe-morrison-use24-2009oct...

  • 몇 년 동안 네트워킹 관련 작업을 많이 해왔고, 나만의 “느린 인터넷” 환경을 동작시키는 데 시간을 썼음. McMurdo만큼 흥미롭지는 않지만, 국제선 비행기, 외딴 곳을 지나는 열차, 형편없는 시골 호텔, 터널 안에서도 채팅하고 YouTube 영상을 봤음
    범용 컴퓨팅 장치에 접근할 수 있고 전력도 감당할 수 있으며(이런 장비는 전력을 많이 먹는 편), 직접 만들 의향이 있다면 NNCP를 추천함 [1]. NNCP는 데이터를 받아 조각낸 뒤 보낼 수 있음. TCP 위에서 noise를 쓰는 동기화 프로토콜도 포함되어 있고, 실패한 조각을 재시도하면서 보냄. TLS가 필요 없어서 연결 수립에 1.5 RTT만 듦
    NNCP는 데이터를 표준 입력으로 원격 프로그램에 먹일 수 있음. YouTube 다운로더, Slack 봇, Telegram 봇, Discord 봇을 만들어 들어오는 데이터를 읽고 해당 서비스와 상호작용하게 했음. 로컬 머신에는 Matrix(Dendrite) 서버와 봇을 띄워두고, NNCP를 통해 적절한 원격 서비스로 데이터를 보냄
    경로상의 MTU/MSS가 가능한 한 낮아 TCP 수준 재시도가 자주 가능하길 바라거나 실험해봐야 하지만, 이 구성은 어디를 가든 거의 실패한 적이 없고 미디어 소비와 채팅을 가능하게 해줌
    국제선에서 가장 짜증나는 점은 NNCP 엔드포인트가 지리적으로 분산되어 있지 않다는 것임. 비행 경로와 엔드포인트까지 패킷이 실제로 가는 경로에 따라 지연 시간과 지터가 크게 늘 수 있음. 보통 목적지 근처에 NNCP 엔드포인트를 두려 하지만, 기내 Wi-Fi 기준 실제 경로가 형편없을 수 있음. NNCP는 이제 Yggdrasil 지원이 있어 이를 완화하고 MTU 문제 제어에도 도움 될 수 있지만, 이런 조건에서 Ygg를 써본 적은 없음
    [1]: http://www.nncpgo.org/

    • 흥미롭다. 구성 방식을 설명한 글이 있나?

  • 남태평양의 배에서 글쓴이와 비슷한 경험을 했음. Starlink는 있었지만 전력 사용량이 높아(60W 이상) 자주 쓰지 않았음. 대신 현지 SIM 카드를 사서 어떤 곳에서는 4G, 어떤 곳에서는 EDGE(2G)를 썼음
    EDGE 자체는 문서상으로 아주 나쁘진 않음. 초당 수십 킬로비트는 나옴. 실제로는 훨씬 나빴음. 로딩이 밀리초가 아니라 몇 분 걸릴 수 있다는 점만 고려했다면 잘 동작했을 앱들이, 짧은 시간 초과 때문에 실패하는 걸 겪었음
    낮은 대역폭·높은 지연 시간 연결은 소프트웨어의 정기 테스트에 포함되어야 함. Linux에는 이를 가능하게 해주는 netem(https://wiki.linuxfoundation.org/networking/netem)이 있음
    익명 블로그 작성자에게는 없었던 문제로 종량제 연결이 있었음. 비용 때문에 운영체제나 앱 업그레이드는 거의 불가능했음. 다행히 몇 주에 한 번씩은 무제한 연결이 있는 곳에 도착해 그런 작업을 할 수 있었음. 그 대신 여러 운영체제에서 연결을 종량제/비종량제로 표시하고 자동 업데이트를 모두 끄며 귀한 대역폭을 아끼는 방법에 매우 익숙해짐

    • 남태평양이면 햇빛이 아주 강할 텐데, 60W 이상을 공급할 태양광 패널이 충분하지 않았다는 건 의외임
      그리고 “현지 SIM 카드”라면 그 SIM을 사러 섬에 내렸다는 뜻일 텐데, 2020년대에 어디서 2G만 됐는지 궁금함. 남태평양에 아직 그런 곳이 남아 있다는 걸 믿기 어려움
    • “모두에게 하나의 크기”는 맞지 않음. 태평양 한가운데 배에 있을 수도 있는 잠재 사용자 일부 때문에 앱을 설계하거나 재설계하는 건 시간과 노력 낭비일 수 있음
      관점을 유지해야 함. 어떤 프로젝트는 여러 브라우저에서 웹앱을 테스트하는 것조차 낭비이고 정당화되지 않는 비용이라며 건너뜀. 테스트 매트릭스에 넣는 게 사소하고 UI만의 문제인데도 그렇다

  • 느린 인터넷을 고려한 엔지니어링은 여전히 정말 중요하고, 대부분의 소프트웨어 개발자에게 크게 과소평가되어 있다고 봄. 하지만 저궤도 위성 시스템(Starlink, 특히 StarLink)은 이제 핵심 문제를 사실상 해결함
    2023년 9~10월에 북극 항로(Alaska에서 Norway)를 지났는데, 북극권 훨씬 위의 선박에서도 구름, 육지와의 거리, 얼음에도 불구하고 FaceTime 영상통화를 할 수 있었음. 글쓴이가 Antarctica에 있던 시기와 같음
    그 제약이 무엇이었든 결국 서비스 계약과 터미널을 현장에 가져다 놓는 문제임. 극지 커버리지는 상대적으로 드물지만, 인구가 극도로 적어서 여전히 충분함
    https://satellitemap.space/

    • 저궤도 위성 시스템이 핵심 문제를 해결했다는 평가는 근본 문제를 제대로 본 것 같지 않음
      느린 인터넷에는 여러 의미가 있고, 그중 하나는 연결 문제임. TCP 같은 연결 지향 프로토콜에서는 패킷 손실로 인한 느려짐이고, UDP 같은 던져놓고 끝나는 프로토콜에서는 메시지가 도착하지 않는다는 뜻임. 따라서 느림은 낮은 전송률일 수도 있고, 순간적인 높은 처리량 뒤 잠깐씩 끊기는 형태일 수도 있음
      느린 네트워크를 다루는 견고한 접근법 하나는 오프라인 모드 지원임. 모든 데이터 push/pull을 비동기 트랜잭션으로 설계하고, 데이터 push는 로컬에 캐시해 가능할 때 재시도하는 방식임. 이러면 버전 관리와 충돌 해결 같은 추가 요구사항이 생김
      자연스럽게 UI 요구사항도 늘어남. 수동 동기화/새로고침, 네트워크 상태 표시, 네트워크가 끊겼을 때 의미 없는 동작 비활성화, 오프라인에서도 사용 가능하도록 선제 로딩 등이 필요해짐
    • SF에서 자주 가는 식당이 있음. 붐비는 상가 거리에서 문에서 15피트 떨어진 자리에 보통 앉고, Verizon 프리미엄 네트워크 접근권도 있으며, iPhone XS는 LTE 두 칸을 표시하지만 DNS가 풀릴 만큼의 처리량조차 절대 안 나옴. 치과에서도 같음
      언젠가 느린 인터넷 이후의 세상에서 살고 싶지만 아직 여러 해 남았음. 참고로 XS는 그 시대 Qualcomm 플래그십보다 열등하다고 알려진 Intel 모뎀을 탑재했음
    • 통근 열차 가득 찬 사람들이 내가 있는 역의 같은 접근점에 붙을 때 저궤도 위성이 어떻게 도움이 됨?
      세계에서 가장 인구 밀도가 높은 곳 중 하나에 살고, 5G 안테나와 Wi-Fi 스테이션이 가득하지만, 엉성하게 만든 웹사이트가 느리거나 간헐적인 연결에서 넘어지는 건 여전히 체감됨
    • Pole에는 Starlink가 없고 McMurdo에는 있음. 이유가 있음
      정지궤도 위성은 Pole에서 지평선에 너무 가까워 극지 커버리지가 제한됨. Pole은 연료가 적고 궤도 경사각이 비교적 큰 낡은 정지궤도 위성을 쓰며, 그래서 24시간 중 약 6시간만 통신할 수 있음
      일정: https://www.usap.gov/technology/1935/
    • 너무 이상적임. 앞으로 많은 국가가 Starlink 신호를 방해해 차단할 것 같음. 일부 국가가 GPS를 강하게 교란해 성공하고 있는 것과 비슷함
      정부들은 검열되지 않은 웹이나 미국 회사가 인터넷 관문이 되는 걸 원치 않을 것임. 지금 보유한 영토 내 네트워크를 유지할 테고, 속도 문제는 계속 유효함
      전 세계에서 인터넷 접근 수단이 낡은 소프트웨어와 제한된 CPU를 가진 100달러짜리 Android 폰뿐인 사람들의 수도 고려해야 함

  • 느린 네트워크에서 사용자 경험을 개선할 수 있는, 효율적 상태 동기화를 위해 HTTP를 확장하는 IETF 초안 제안이 있음: https://news.ycombinator.com/item?id=40480016
    Braid Protocol은 여러 동기화 알고리즘이 공통 네트워크 프로토콜 위에서 상호운용되도록 하며, 어떤 동기화기의 네트워크 메시지도 그 위로 변환될 수 있음. 현재 Braid 명세는 HTTP에 두 동기화 차원을 추가함
    Level 0: 오늘날의 HTTP
    Level 1: push 업데이트가 있는 구독
    Level 2: P2P 일관성(패치, 버전, 병합)
    오늘날 동기화기들은 서로 다른 프로토콜을 쓰지만, 네트워크 메시지는 같은 종류의 정보를 전달함. 시간상의 버전, 공간상의 위치, 시간 범위에 걸친 공간 영역 패치임. 임의의 패치 집합의 합성은 braid라는 수학적 구조를 이룸. 시간에 따른 공간의 분기, 병합, 재정렬임
    희망은 영원히 샘솟음

    • 좋다, 제발! 쓸데없이 복잡한 쓰레기 계층을 더 얹으면 분명 좋아질 것임
    • Matrix와 수상하게 비슷하게 들림. 사용자 에이전트의 동의가 필요한가, 아니면 구현되면 기존 브라우저도 이득을 보나?
    • 심술 난 관점으로는, 더 복잡한 기술이 비즈니스·사회적 문제를 고치지는 못함. 사실 이렇게 엉망으로 만들려면 일부러 애써야 함
      왕복 요청을 줄이고 덜 부풀린 것을 만드는 건 어렵지 않고 오히려 훨씬 쉬움. 비대함은 전혀 다른 이유로 존재함
      때로는 데이터센터 가까이 있는 빠른 인터넷과 넉넉한 기계에서는 비대함이 티가 안 남. 쉽게 시뮬레이션할 수 있지만 회사가 신경 써야 함. 대체로 광고 기술과 그 주변은 작은 사용자 집단에 거의 관심이 없음. 사실 최종 사용자에게 관심을 갖는 유일한 이유도 그들이 실제 고객, 즉 광고주에게 매출을 만들어주기 때문임

  • 앱과 웹사이트 등을 만드는 우리는, 우리가 쓰는 빠른 Wi-Fi나 광회선에 연결되어 있지 않은 사람이 많다는 걸 기억해야 함
    영국에서는 일부 통신사가 3G 종료를 시작했음. 어떤 곳은 저전력 대체 수단으로 2G를 두지만 이제는 4G/5G를 쓰라는 식임. 문제는 4G가 아직 모든 곳에서 되지 않고, 얼마 전까지는 일부 지역에서 3G 신호만 괜찮았다는 것임
    그래서 원치 않게 2G/EDGE로 떨어지는 일이 더 잦아졌고, 많은 것들이 그냥 멈춤. 많은 앱이 느리고 지연 시간이 높으며 패킷 손실이 큰 시나리오에서 테스트되지 않음

    • 3G를 종료한 건 실수였음. 수많은 기기를 전자폐기물로 만든 것뿐 아니라, 4G가 혼잡할 때 좋은 백업이었음
    • 미국에서는 데이터 요금제가 다 떨어지면 많은 네트워크가 2G로 떨어짐. 가난한 사람들은 대부분 데이터 한도가 아주 낮아서 한 달 대부분을 2G로 지냄
      2G에서 Google Maps로 길 찾아보면 답이 나옴 :(
답변달기