제로렌트 아키텍처: 스와트랜드 농부를 위한 설계
Source: Dev.to
번역할 텍스트를 제공해 주시면 한국어로 번역해 드리겠습니다.
상황
필드는 스와트랜드 깊숙한 곳, 케이프 타운에서 두 시간 거리이다. 온도는 34 °C, 공기는 밀짚과 먼지로 가득하고 가장 가까운 기지국은 거대한 화강암 언덕에 가려져 있다.
여기에는 방금 40톤의 밀을 수확한 농부가 서 있다. 그는 다음 구역으로 이동하기 전에 수확량, 위치, 그리고 수분 수준을 지금 기록해야 한다.
만약 그에게 전통적인 “실리콘밸리” 앱—무거운 프런트‑엔드와 버지니아 북부에 호스팅된 REST API에서 데이터를 가져오고 Auth0로 인증되는—을 제공한다면 그 앱은 쓸모가 없을 것이다. 앱은 계속 로딩하고, 기다리다가 타임아웃이 발생하고 데이터는 사라진다. 더 나아가 농부는 신뢰할 수 없기 때문에 도구 사용을 완전히 중단할 것이다.
샌프란시스코의 개발자에게 “오프라인 지원”은 엣지 케이스—지하철 터널에 들어갈 때만 필요할 수도 있는 부가 기능이다. 이 농부에게 오프라인은 유일한 상태가 중요하다.
접근 방식 재고
이 깨달음은 내가 “현실 세계”—광섬유 도시 밖의 세계—에 대한 소프트웨어를 구축하는 방식을 재고하도록 만들었다. 나는 더 이상 다음과 같은 질문을 하지 않았다:
“이걸 백만 명의 사용자에게 확장하려면 어떻게 해야 할까?”
그리고 다음과 같이 질문하기 시작했다:
“한 명의 사용자를 위해 이걸 절대 깨지지 않게 만들려면 어떻게 해야 할까?”
답은 클라우드에 있지 않았다. 답은 클라우드를 완전히 삭제하는 것이었다.
첫 번째 장애물: 관료주의
전통적인 경로를 통해 도구를 농부에게 전달하려면 다음과 같은 절차가 필요합니다:
- 앱을 네이티브 셸에 감싼다.
- Apple과 Google에 제출한다.
- 승인을 기다린다(또는 사소한 정책 위반으로 거부될 수 있다).
- 농부는 스토어를 열고, 앱을 검색하고, 3년 전 잊어버린 Apple ID 비밀번호를 기억한 뒤, 제한된 3G 연결을 통해 150 MB 바이너리를 다운로드해야 한다.
그것이 비대함이다. 그것이 마찰이다.
“제로‑렌트” 솔루션
QR 코드 배포
농부가 사무실로 돌아와서 느리지만 안정적인 Wi‑Fi에 연결되어 있을 때:
- QR 코드를 스캔한다.
- 카메라가 브라우저를 열고, “홈 화면에 추가?” 라는 프롬프트가 표시된다.
- 예를 탭한다.
3초 만에 앱이 설치되고 WhatsApp 및 Gallery 옆에 나타나며 네이티브처럼 보이고 네이티브처럼 느껴지지만, 수백만 달러 규모의 게이트키핑 산업을 우회한다.
오프라인‑퍼스트 아키텍처
- 아이콘이 화면에 표시되면 인터넷 연결이 선택 사항이 됩니다.
- 기기 자체가 앱의 전체 우주가 됩니다.
Source: …
Persistent Local Storage: SQLite via OPFS
웹 앱에서 데이터를 저장하는 표준 방법은 localStorage 또는 IndexedDB입니다. 다크 모드 선호도 정도라면 괜찮지만, 핵심 비즈니스 데이터에는 끔찍합니다:
- 구조화되지 않음.
- 크기 제한이 있음.
- 브라우저가 언제든지 데이터를 삭제할 수 있음.
왜 SQLite (via OPFS)인가?
| Feature | Benefit |
|---|---|
| Full‑featured, ACID‑compliant | Android, iOS 및 수많은 데스크톱 앱을 구동하는 동일한 엔진. |
| Fast | 쿼리가 밀리초 단위로 실행—네트워크 왕복이 필요 없음. |
| Relational | 복잡한 SQL(예: “Yield per Hectare”)을 디바이스에서 바로 실행, JSON을 가져와 JavaScript로 필터링할 필요 없음. |
| Persistent | 데이터가 폰 저장소의 보호된 샌드박스에 존재; 페이지 새로고침, 재시작, 비행 모드에서도 살아남음. |
이 아키텍처에서 폰은 “클라이언트”가 아닙니다. 폰이 서버입니다.
인보이스 생성 → SQLite에 저장.
재고 업데이트 → SQLite에 저장.
로딩 스피너도, 네트워크 지연도 없이 즉시 상호작용이 가능합니다.
인터넷의 역할: 백업, 계산이 아니라
휴대폰은 부서지기 쉽습니다; 분실되거나 도난당하거나 진흙에 빠질 수 있습니다. 기기가 관개 도랑에 빠지면 데이터도 함께 사라집니다. 우리가 인터넷이 필요한 유일한 이유는 보험을 위해서이며, 계산을 위해서가 아닙니다.
Google Drive를 이용한 클라우드 백업
- 대부분의 사용자는 이미 Google 계정을 가지고 있습니다.
- 앱은 사용자의 Drive 내 특정 폴더에 접근 권한을 요청합니다.
- 농부가 농가 Wi‑Fi에 다시 연결될 때:
- 앱이 연결을 감지합니다.
- SQLite 데이터베이스의 스냅샷을 찍습니다.
- 그 단일 파일을 그의 Google Drive에 업로드합니다.
결과:
- 프라이버시 – 개발자는 데이터를 전혀 보지 못합니다; 데이터는 휴대폰에서 바로 Drive로 전송됩니다.
- 비용 – 호스팅 비용 $0; 농부에게도 비용 $0 (무료 티어 저장소 사용).
- 복원력 – 새 휴대폰 → 로그인 → 파일을 가져오기 → 중단했던 지점부터 계속 진행.
우리는 **“클라우드 의존성 없이 ‘클라우드 백업’**을 구현했습니다.
예상되는 우려 사항 및 답변
| Concern | Response |
|---|---|
| Conflicts – 두 장치가 같은 레코드를 편집하면 어떻게 되나요? | 모델은 단일 장치 소유를 가정합니다. 충돌‑없는 편집은 이 사용 사례에 필요하지 않습니다. |
| Real‑time collaboration – 여러 사용자는 어떻게 되나요? | 아키텍처는 오프라인‑first이며, 실시간 동기화는 범위에 포함되지 않습니다. |
| Device loss – 동기화 전에 전화기가 꺼지면 어떻게 되나요? | 인터넷은 여전히 전달자 역할을 합니다: 주기적인 동기화(예: Wi‑Fi 사용 가능 시)가 데이터 손실을 완화합니다. |
| Scalability – 많은 사용자에게 확장할 수 있나요? | 예—각 사용자는 자신의 Drive에 격리된 SQLite 파일을 받습니다. 서버‑측 확장은 필요하지 않습니다. |
요약
- 오프라인은 저연결 환경 사용자에게 유일하게 중요한 상태입니다.
- QR 코드 배포는 앱 스토어의 마찰을 없앱니다.
- OPFS를 통한 SQLite는 장치에서 신뢰할 수 있고 관계형이며 영구적인 데이터 저장소를 제공합니다.
- Google Drive는 저렴하고 프라이버시를 보호하는 백업 “운송자” 역할을 합니다.
- 결과는 Zero‑Rent 아키텍처입니다: 백엔드 서버가 없고, 외부 전송 비용이 없으며, 복잡한 인증 흐름도 없습니다—필요한 곳에서 빠르고 신뢰할 수 있는 도구만 제공됩니다.
앱은 수동적이면서도 능동적입니다. Background Sync API 또는 간단한 연결 리스너를 사용해 네트워크 상태를 감시합니다. 전화기가 Wi‑Fi에 연결되는 순간, 동기화가 백그라운드에서 자동으로 트리거됩니다.
그가 Wi‑Fi에 다시 연결되기 전에 전화기를 진흙에 빠뜨리면? 그날의 데이터는 사라집니다. 하지만 신호가 없어 데이터를 전혀 저장하지 못한 클라우드‑우선 앱과 비교해 보세요. 클라우드 상황에서는 데이터가 애초에 존재하지 않았습니다. 이 경우에는 최소한 저장될 가능성이 있었습니다.
엔지니어가 삼키기 가장 어려운 알약
모든 앱이 멀티플레이어일 필요는 없습니다.
보세요, 이게 완벽하지는 않다는 걸 압니다. 농부와 그의 아내가 정확히 같은 순간에 같은 레코드를 편집하려고 하면, 둘 중 한 명은 데이터를 잃게 됩니다. 이를 해결하려면 서버, WebSockets, CRDTs(충돌‑없는 복제 데이터 타입) — 가장 중요한 것은 — 그 복잡성을 지원하기 위한 월별 비용이 필요합니다.
하지만 사용 사례를 보세요. 농부는 들판에 있고, 아내는 사무실에 있습니다. 그들은 소설을 공동 집필하고 있는 것이 아닙니다. 그들은 별개의 이벤트를 기록하고 있습니다. 소규모 비즈니스의 90 %에 대해 “Single User” 모드가 충분합니다.
- 실시간 협업에 **“No”**라고 말함으로써, 나는 일주일 안에 이 앱을 만들고, 무료로 호스팅하며, 영원히 실행될 수 있습니다.
- **“Yes,”**라고 말하면, 나는 몇 달 간의 개발 시간과 평생 유지보수를 약속하게 됩니다.
밀 농부에게 가장 필요한 기능은 **“Real‑Time Collaboration.”**이 아니라 **“It Works When I Press the Button.”**입니다.
왜 우리는 실리콘밸리 지평을 계속 바라보는가
우리는 마이크로서비스, 엣지 컴퓨팅, 서버리스 함수에 집착합니다. 그것은 넷플릭스와 우버가 하는 일이기 때문이죠. 그렇게 하다 보면 우리가 실제로 누구를 위해 만들고 있는지를 종종 잊게 됩니다.
- 우리는 넷플릭스를 위해 만들고 있는 것이 아닙니다.
- 우리는 스와트랜드의 농부를 위해 만들고 있습니다.
- 우리는 소웨토의 정비사를 위해 만들고 있습니다.
- 우리는 케이프타운의 커피숍 주인을 위해 만들고 있습니다. 그 주인은 이익 마진이 월간 SaaS 비용과 데이터 번들에 사라지는 모습을 지켜보고 있습니다.
“Zero‑Rent” 아키텍처
“Zero‑Rent” 아키텍처는 단순히 열악한 인프라에 대한 우회책이 아닙니다. 소프트웨어는 반드시 임대되어야 하고, 데이터는 데이터 센터에 있어야 하며, 라우터의 불빛이 빨간색으로 바뀌면 앱이 작동을 멈춰야 한다는 가정에 도전하는 것입니다.
Local‑First, SQLite, 그리고 User‑Owned Storage에 베팅함으로써 우리는 네트워크 가장자리로 권한을 되돌려줍니다:
- Speed – 물리학이 광섬유를 이깁니다.
- Ownership – 그들의 데이터, 그들의 드라이브.
- Resilience – 언제나 작동합니다.
웹을 위한 새로운 비전
아프리카는 종종 서구에 “뒤처져”야 하는 시장으로 취급됩니다. 하지만 프라이버시, 클라우드 비용, 에너지 효율에 대한 인식이 점점 높아지는 세상에서 저는 그 반대가 진실이라고 믿습니다.
농부를 위한 해결책을 찾음으로써 우리는 웹의 하위 버전을 만드는 것이 아니라, 더 가볍고, 더 빠르며, 이를 사용하는 사람들을 더욱 존중하는 차세대 웹을 구축하고 있습니다.
Originally published at nanosoft.co.za