일론 머스크의 위성 인터넷, 케냐 나이로비의 버튼 하나

저자원 환경과 고급 인프라 사이, 오프라인-퍼스트 UX의 설계 전략

"인터넷은 존재하지만, 사용자는 없다.”

한 우간다 개발자의 회고. 2025년 현재, 수십억 명은 여전히 안정적인 인터넷 없이 산다. 그들의 일상은 "로딩 중"이 아니라, "접속 불가"를 전제로 한다.

스타링크는 왜 저소득 국가를 노리는가

이 시장에 스타링크가 진입한다. 수천 개의 저궤도 위성을 쏘아 올려, 인터넷 맹지에 고속 연결을 제공한다는 모델이다. 그리고 그들의 전략은 명확하다: 전체 수익의 60%를 저소득 국가에서 확보하겠다.

스타링크 앱

인터넷은 상품이고, 연결은 시장이다. 스타링크가 공급한다면, 우리는 그 위에서 작동할 수 있는 제품을 설계할 수 있다. 스타링크로 인해 인터넷이 연결되자 많은 것이 가능해졌다. 케냐와 르완다 농촌에서 100Mbps 이상의 속도가 기록됐고, 부룬디에선 원격 수업 참여율이 35% 상승했다. 남아공 농촌의 이커머스 판매량은 2년 사이 2배가 됐다. 스타링크 외의 원웹(OneWeb), 아마존 쿠이퍼(Project Kuiper), 중국의 GW 등 LEO 위성망의 등장으로 가능성은 더욱 커지고 있다.

연결은 가능해졌지만, 여전히 신뢰할 수 없다

하지만 이 연결은 여전히 예측 불가능하다. 위성 간 핸드오버로 5~15초간 끊기고, 혼잡 시간대엔 속도가 절반 이하로 떨어지며, 일부 국가는 위성 주파수를 법적으로 막고 있다.

스타링크 LEO 위성의 커버리지 시각화.

초록 원은 각 위성이 커버하는 지상 셀, 붉은 점은 실시간 위성 위치를 나타낸다. 슬라이더는 연결 허용 각도(지평선 기준)를 조절하며, 지도 배경은 연결 가능성과 국가별 차이를 보여준다. 사용자는 이 셀 간 전환(handover) 시 5~15초간 연결 단절을 겪게 된다.

인터넷이 끊기면 사용자는 버튼을 누르지만 아무 일도 일어나지 않는다. 신호는 전송되지 않고, 에러는 뜨지 않으며, 앱은 정지한다. 스타링크와 Mesh 네트워크는 종종 속도는 있지만, 신뢰는 없다. 40~100Mbps 속도도 8%의 패킷 손실, 200ms 이상의 레이턴시 앞에선 무력하다.

offline-first는 예외가 아니라 진입 전략이다

우리가 가정해온 ‘연결됨’이라는 개념은 과도하게 낙관적이다. 우리가 아는 대부분의 앱은 인터넷이 항상 켜져 있을 거라는 전제 하에 설계되기 때문이다.

여기서 중요한 건 인터넷 연결이 잘 되지 않는 시장이 우리가 아는 시장보다 크다는 거다. 스타링크는 고객 확보를 위해 이중 전략을 추진한다. 저소득 국가에선 정부-기업 협력 모델을 통해 월 $10 이하 요금제를 밀고, 선진국에선 항공·해상·극지방을 타겟으로 프리미엄 패키지를 판매한다. 이 모델은 2026년까지 전체 수익의 60%를 개발도상국에서, 40%를 선진국에서 확보할 계획을 의미한다. 동시에 1,000만 아프리카 가구에 인터넷을 공급하겠다는 구체적인 수치도 제시됐다.

이 신흥시장을 노리는 디자이너, 개발자, 파운더, PM이라면. 당신이 구글같은 빅테크의 저자원 인프라 국가에 프로덕트를 만든다 생각하고 이 글을 읽어도 좋다.

---

연결은 꺼졌다 켜지는 게 아니다

우리는 보통 인터넷을 전구처럼 생각한다. 켜져 있으면 연결되고, 꺼져 있으면 안 되는 것. 앱도 마찬가지다. 연결되어 있을 때만 서버와 대화하고, 그렇지 않으면 ‘에러’가 뜬다.

하지만 세상은 그렇게 단순하지 않다. 특히 위성 인터넷, Mesh 네트워크, 극지방, 재난 지역, 저개발국가 같은 환경에선 인터넷이 ‘잠깐 잠깐 있다가 사라지는’ 식으로 존재한다. 연결은 단절되었다기보단, 지연되고, 재구성되는 중이다.

이럴 때 필요한 게 바로 DTN (Delay-Tolerant Network, 지연 허용 네트워크) 라는 생각 방식이다.

출처: 이은빈

1. 실시간 연결: 우리가 익숙한 환경

서울, 뉴욕, 런던 같은 도시에서 사는 우리는 주로 LTE, Wi-Fi, 광섬유 네트워크 같은 항상 연결된 환경에 있다. 우리가 어떤 버튼을 누르면 서버가 즉시 응답하고, 데이터가 자동으로 동기화된다. 대부분의 앱은 이런 환경에서 테스트되고, 그런 환경만을 고려해서 설계된다. 하지만 이건 지구상 극히 일부 사용자들의 이야기다.

2. 간헐적 연결: 예측은 안 되지만 가능은 함

위성 인터넷, 불안정한 3G/4G처럼 접속은 되지만 불안정한 환경이 있다. 이런 곳에서는 연결이 자주 끊기거나 지연이 크기 때문에, 단순히 요청을 보내는 것만으론 충분하지 않다. 시스템은 재시도하거나, 데이터를 일시적으로 저장했다가 연결이 복구되면 자동 전송해야 한다. 이걸 하지 않으면? 버튼을 눌러도 아무 반응이 없고, 사용자는 앱이 고장난 줄 알게 된다.

3. 지연 허용 네트워크(DTN): 연결이 "간헐적"인 곳

극지방, 재난 현장, 산간 지역, 또는 메쉬 네트워크 기반 커뮤니티처럼 인터넷이 간헐적으로만 존재하는 환경도 있다. 이런 곳에선 데이터가 곧바로 전송되지 않는다. 대신, 장치에 임시로 저장되고, 연결이 생기면 그때 전달된다. 마치 누군가의 편지를 들고 있다가 나중에 전달하는 식이다. 이 방식은 "store–carry–forward"라 불린다. 이런 환경에선 앱의 기본 동작 방식 자체가 달라져야 한다. 지금 반응하지 않더라도, "나중에 반영될 것이다" 라는 믿음을 줄 수 있어야 한다.

4. 완전 차단된 환경: 연결이 아예 없는 곳

심지어 어떤 환경에서는 인터넷 자체가 불가능하다. 군사 작전, 외딴 기지, 격리된 시스템 등에서는 네트워크를 사용할 수 없다. 이런 곳에서는 데이터 전송이 아니라 물리적 복사, 예: USB, QR 코드 스캔, 프린트된 바코드 등으로만 정보가 이동할 수 있다. 이런 상황에서 작동하는 앱은 완전히 오프라인 우선으로 만들어져야 하며, 네트워크 의존도를 최소화해야 한다.

재난 현장, 군사 작전에서도 쓰이는 메쉬(Mesh) 네트워크

이 챕터는 개발자를 위한 내용이다. 우리는 위에서 본 케이스 중 3번, DTN 연결을 가능하게 하는 네트워크를 살펴볼거다. 우리가 흔히 쓰는 네트워크는 중심이 있다. 집에서는 와이파이 공유기, 밖에서는 셀 타워. 기기는 항상 중앙에 연결된 상태에서 서버와 데이터를 주고받는다.

메쉬 네트워크는 이 구조를 깨버린다. 모든 기기가 서로 직접 연결될 수 있고, 서로 데이터를 전달할 수 있다. 즉, 어떤 하나가 서버가 아니더라도, 누군가의 메시지를 들고 있다가, 다른 기기와 연결되면 전달해주는 구조다.

예를 들어 A가 B에게 메시지를 보내고 싶다. 그런데 지금 둘은 직접 연결되어 있지 않다. 하지만 A는 근처에 있는 C에게 메시지를 저장시킬 수 있다. C는 나중에 B를 만나면 그 메시지를 전달한다. 즉, 데이터는 서버를 통해 가는 게 아니라, 기기를 타고 ‘걸어서’ 도착하는 셈이다. 이게 바로 메쉬 네트워크의 작동 방식이다. store–carry–forward. 말 그대로, 저장하고(store), 들고 있다가(carry), 나중에 전송(forward)한다는 뜻이다.

데이터를 한 번에 전달하지 못할 때, 각 기기가 ‘잠시 보관’했다가, 다음 기기와 연결되면 다시 전달한다

예를 들어보자. 당신이 농촌에서 주문 앱을 쓰고 있다고 하자. 버튼을 누르면 주문이 바로 서버로 가지 않는다. 일단 휴대폰 안에 저장된다. 연결이 생기면 앱은 알아서 그 정보를 보내버린다. 사용자 입장에선 “지금 바로 처리되진 않지만, 나중에 처리될 것”이라는 피드백만 있으면 된다. 이게 바로 DTN의 기본 원리다.

실제로 NASA는 화성 탐사 로버와의 통신에 이 방식을 쓴다. 지구에서 로버에게 명령을 보내면, 그건 실시간이 아니다. “언젠가 닿을 것”을 가정한 구조다. 이 방식은 재난 대응 장비(goTenna 같은), 저가 휴대폰 네트워크, 물류 트래킹, 날씨 센서, 가축 GPS 추적기 같은 IoT에서도 쓰인다. 연결이 안 되면 데이터를 잠시 쌓아두고, 나중에 싱크한다.

물론 여기서 질문이 생긴다. “아니, 그럼 서버 없이 앱이 어떻게 작동해?”, “이게 진짜 가능한 이야기야?” 가능한 얘기다. 다만 우리가 평소에 보던 구조랑 완전히 다르다.

예를 들어 메신저 앱을 생각해보자. 평소엔 서버에 메시지를 보내고, 상대가 접속하면 받아간다. 메쉬 구조에서는, 메시지를 휴대폰 안에 저장해둔다. 그리고 내 기기가 누군가와 연결될 때, 그 사람에게 직접 보내는 거다. 혹은 그 사람이 아니더라도, 누군가에게 넘겨서 대신 전달해달라고 할 수 있다. 즉, 모든 기기가 작은 우체국이 된다. 자기 안에 저장된 메시지를 들고 다니다가, 목적지에 가까운 누군가를 만나면 넘겨주는 방식이다.

그렇다고 모든 걸 다 직접 짜야 하는 건 아니다. 이미 이 구조를 지원하는 기술 스택과 프레임워크들이 있다.

예를 들면,

기기 간 직접 통신을 가능하게 하는 Bluetooth Mesh, Wi-Fi Direct, LoRa

데이터를 임시로 저장하고 전송 상태를 관리하는 store-and-forward queue

동기화 실패를 자동으로 복구하는 conflict resolution 알고리즘

따라서, UX는 연결 상태를 이해해야 설계할 수 있다.

문제는 우리가 아직 이런 생각을 UX 설계에 반영하지 않는다는 것이다. 대부분의 앱은 “연결됨 = 바로 반응”을 전제로 한다. 그래서 연결이 느리거나 불안정하면 그냥 멈춘다. 버튼을 눌러도 아무 일도 일어나지 않는다. 앱이 멈춘 건지, 전송 중인 건지, 다시 눌러야 하는 건지 알 수가 없다.

예를 들어 앱이 응답을 기다리는 중이라면, 사용자에게 “잠시 후 전송됩니다”라고 알려줘야 한다. 실제로 메시지가 실패했을 땐 “연결이 되면 자동 재전송됩니다” 같은 피드백이 필요하다. 반응이 늦는다고 해서 실패로 처리하면 안 된다. 지연, 실패, 순서 어긋남 — 이 셋을 다르게 처리해야 한다.

출처: 이은빈

이 위에 올라가는 앱은 기존처럼 “실시간 요청–응답” 구조가 아니라, “내가 가진 데이터를 언제쯤 전송할 수 있을지 모른다”는 전제를 가진 UX 설계가 필요하다. 그래서 UI도 다르게 구성된다. “전송 완료됨”이 아니라 “전송 대기 중”, “연결 시 전송 예정” 같은 상태가 기본이 된다.

개발과 디자인의 우선순위가 달라진다

신호가 없는 세계에서, 사용자의 '의도'를 다루는 법

오프라인 퍼스트 UX에서 중요한 건 '연결됨'이라는 상태를 어떻게 재정의하느냐다. 사용자가 어떤 행동을 했을 때, 지금 처리되지 않아도 언젠가 반영될 거라는 구조. 이건 단지 캐싱 문제가 아니다. 사용자 의도를 기억하고 보존하는 시스템이 필요하다.

예를 들어 사용자가 메시지를 보냈을 때, 연결이 없어 즉시 전송이 안 되는 상황. 대부분의 앱은 실패 메시지를 띄우거나 아무 일도 하지 않는다. 하지만 좋은 시스템은 다르다. "전송 대기 중 – 연결 시 자동 발송됩니다."라는 피드백을 주고, 로컬에 해당 행동을 안전하게 저장하고, 이후 연결이 복구되면 서버로 확정된 요청을 보낸다.

Offline-first flow: local intent capture, deferred relay, and post-connect sync enable interaction

디자이너는 실시간 ≠ 즉시 피드백이라는 전제를 버리고, '지연된 신뢰'를 설계해야 한다. 사용자에게는 지금 당장 결과를 보장하지 못해도, "기억되고 있다"는 감각을 주는 게 핵심이다. 예: “요청이 접수되었습니다. 연결 시 처리됩니다.”

개발자는 이러한 상태 전이를 로직으로 보장해야 한다. 사용자의 action을 어떻게 로컬에 저장하고, 어떤 조건에서 전송하고, 서버에서 어떻게 병합하며, 중복 처리를 어떻게 피할 것인가?를 기본 흐름의 일부로 설계하는 것이다.

오프라인을 고려한 UX 패턴 정리

1. 단순한 디자인이 가장 강력하다. 피처폰이나 저사양 기기를 쓰는 사용자에겐, 화려한 UI보다 텍스트 기반 메뉴가 더 빠르고 이해하기 쉽다.

2. 트랜잭션은 '언제 처리되냐'보다 '확실히 기억되고 있느냐'가 중요하다. 블록체인 시스템에서처럼, TX ID나 확인 코드만으로도 사용자는 안심할 수 있다.

3. 연결이 없어도 '작동 중'이라는 신호는 줄 수 있다. 진동 패턴, 뱃지, 저장됨 알림 등으로 사용자의 행동이 유효하다는 걸 알려줄 수 있다.

4. 중앙 서버 없이도 데이터는 전달될 수 있다. SMS 릴레이, Mesh 네트워크, QR 코드 기반 키 교환 등으로 P2P 기반 데이터 전달이 가능하다.

5. 사용자 행동 자체가 데이터가 된다. 예: 여러 사용자 위치 데이터를 자동으로 모아, 커버리지 맵을 만들 수 있다.

6. 네트워크가 부족한 곳일수록 신뢰 표현이 중요하다. “저장됨 – 연결 시 전송됩니다.” 같은 문장은 단순한 안내가 아니라 신뢰 메커니즘이다.

7. 온보딩도 연결 없는 상황을 전제로 해야 한다. QR 코드로 시작하고, 오프라인에서도 채널 가입, 메시 저장 정책 설정 등이 가능해야 한다.

이런 디테일이 설계되지 않으면, 연결이 없는 순간 사용자 경험은 끊기고 시스템 전체가 무력화된다.

케이스 스터디: 현지 사례 세 가지

이제 이론을 현실로 가져올 시간이다. 다음 세 가지 사례는 오프라인-퍼스트 UX의 핵심 원칙이 실제로 어떤 방식으로 구현되고 있는지를 보여준다. 단지 참고가 아니라, 여러분이 설계하는 시스템에서 직접 활용 가능한 구조적 인사이트다.

이 사례들을 통해 우리는 세 가지 서로 다른 문맥 — 금융 인프라가 부족한 지역, 재난 대응 상황, 오프그리드 커뮤니티 — 속에서 부분 동기화(partial sync), 로컬 인터페이스, 비시각적 피드백, 그리고 사용자 주도 확장성이 어떻게 작동하는지를 본다.

개발자에게는 구현 전략으로, 디자이너에게는 설계 힌트로, PM에게는 시장 진입 모델로 읽히길 바란다.

1. Kotani Pay – 오프라인에서 송금이 가능한 금융 기술

우리는 이 책 1화에서 아프리카의 많은 사용자는 스마트폰이 아닌 피처폰을 쓴다는 것을 배웠다. 복습하면, Kotani는 이들을 위해 인터넷 없이 블록체인 기반 송금을 할 수 있게 한다. 방법은 단순하다. 384*6# 같은 코드를 입력하면 텍스트 기반 메뉴가 뜬다. 사용자는 거기서 ‘송금’을 선택하고 금액을 입력하면, 요청이 시스템에 저장된다.

보통 앱에서는 송금을 누르면 즉시 서버가 처리하지만, 여기서는 연결이 없기 때문에 시스템이 먼저 “거래가 대기 중”이라는 메시지를 주고, 나중에 연결될 때 블록체인 상에서 실제 송금이 일어난다. 이때 사용자는 TXID(거래 확인 코드)를 통해 내 송금이 처리됐는지를 확인할 수 있다. 그리고 만약 USSD 세션(일종의 대화창)이 중간에 끊겨도, 사용자는 같은 코드를 다시 입력하면 이전 상태로 복구된다. 이 모든 과정은 단 하나의 앱 없이, 기본 휴대전화로 가능하다.

� 인사이트:

오프라인 UX는 단순한 인터페이스가 아니라 시스템 설계 방식이다.

‘지금 반응 없음’이 아니라 ‘나중에 처리된다’는 확신이 신뢰를 만든다.

네트워크 없이도 동작 가능한 금융 UX는 UI보다 프로토콜에 달려 있다.

2. goTenna Mesh – 재난 상황에서의 연결 유지법

goTenna는 ‘인터넷이나 휴대폰 신호 없이도 메시지를 주고받을 수 있는 장치’다. 작은 라디오 장비처럼 생겼고, 너의 스마트폰과 블루투스로 연결된다. 이 장치끼리는 서로 직접 통신할 수 있어. 마치 통신탑이 필요 없는 무전기 같은 거지. 근처에 있는 다른 goTenna 장비를 거쳐서 메시지를 전달한다.

예를 들어 산속에서 구조 요청을 보내야 한다 하자. 하지만 전화는 안 터진다. 그럼 goTenna로 “도와주세요” 메시지를 보내면, 그 메시지는 당신과 가까운 다른 사람의 goTenna를 통해 hop-hop-hop 하면서 전달 가능한 사람에게 도착하는 것이다.

재난 지역에선 셀룰러 네트워크가 종종 마비된다. 이때 goTenna의 각 장치가 서로 직접 메시지를 전달할 수 있는 ‘메시 네트워크’를 형성해 통신을 가능하게 한다.

예를 들어 구조요청을 보내려면, 미리 저장된 문구(예: “의료 지원 요청”, “식수 부족”)를 선택해 전송한다. 이 문구는 데이터량이 적어 전송 성공률을 높인다. 메시지는 근처 장치들을 hop-hop으로 거쳐, 최종 수신자에게 전달된다. 전송 성공 여부는 장치의 LED나 진동으로 피드백된다.

메시지는 TTL(수명 제한)을 갖고 네트워크를 떠돌다가, 도달하지 못하면 자동 삭제되어 과부하를 막는다. 또 연결 가능성은 실시간 지도 위에서 확인할 수 있다.

� 인사이트:

시각보다 촉각/진동 중심 피드백이 더 강력할 수 있다.

예측 가능한 경로와 제한된 데이터 구조는 불안정 네트워크에서 생존 가능성을 높인다.

메시 네트워크는 사용자가 늘수록 더 강해진다 — 즉, 사용자 = 인프라다.

3. Meshtastic LoRa – 커뮤니티가 직접 만든 통신망

Meshtastic은 인터넷이 아예 안 되는 지역에서 쓸 수 있는 메시지 전송 시스템이다. 이건 휴대폰 앱이나 와이파이를 쓰지 않고, LoRa라는 무선 기술을 써서 메시지를 주고받는다. LoRa는 장거리 통신이 가능한 아주 저전력 라디오 기술이다. 인터넷이나 셀룰러 신호가 없어도, 몇 킬로미터 떨어진 사람과 통신할 수 있다. 단, 그 사람도 Meshtastic 장비를 갖고 이있어야 한다.

인터넷이 닿지 않는 지역에서, Meshtastic은 저전력 장치를 이용해 지역 네트워크를 만든다. 누구든지 작은 LoRa 장치를 갖고 QR코드를 스캔하면 새로운 ‘채널’에 가입할 수 있고, 키 교환도 자동으로 이루어진다.

메시지를 보내면 일반/긴급에 따라 진동 패턴이 다르게 울리며, 화면을 보지 않아도 어떤 종류인지 알 수 있다. 또한 사용자의 위치 데이터를 수집해 ‘우리가 지금 어디까지 통신할 수 있는지’를 지도로 시각화한다.

� 인사이트:

사용자 참여 자체가 인프라를 확장한다.

감각 중심 인터랙션(진동, 청각 등)은 비시각적 환경에서도 명확한 피드백을 준다.

누구든지 참여할 수 있는 구조는, 중앙 서버 없는 네트워크의 핵심이다.

경계에 선 이들을 위한 디자인

오프라인-퍼스트는 단순한 백업이 아니다. 이건 ‘불안정한 연결’을 기본값으로 전제하고 시스템을 설계하는 새로운 틀이다. 우리가 다룬 사례들은 단순한 앱 최적화가 아니라, 완전히 다른 조건에서 작동하는 시스템을 어떻게 구성해야 하는지를 보여준다. 아래 세 가지로 대략 정리해볼 수 있다.

예측형 캐싱은 사용자 행동을 기반으로 오프라인에서도 데이터를 준비하게 만들고,

감각 기반 피드백은 시각 없이도 시스템을 신뢰할 수 있게 한다.

사용자 주도 확장은 인프라를 소수가 제공하는 게 아니라, 참여자 수에 따라 스스로 성장하는 구조를 설계하게 한다.

이제 필요한 건, 더 많은 제품 설계자들이 이 프레임을 실험해보는 일이다. 세계의 40억 사용자를 위한 프로덕트를 만드는 모든 이들에게 도움이 되었길 바란다.