앱이 인터넷을 잃었을 때 벌어지는 일 (그리고 계속 작업하는 방법)

와이파이가 끊깁니다. 앱에서 양식을 작성하던 중이었죠—절반쯤 입력했고, 벌써 5분을 썼습니다. 그다음엔 무슨 일이 벌어질까요?

앱이 온라인 전용이라면 이야기는 이렇습니다: 페이지가 새로고침되거나 다시 로드됩니다. 입력한 데이터는 사라집니다. 처음부터 다시 시작해야 합니다. 앱을 닫고, 다시는 돌아오지 않습니다.

앱이 오프라인 우선이라면 이야기는 달라집니다: 계속 타이핑합니다. 데이터는 안전합니다. 와이파이가 다시 들어오면(3분 뒤든, 3일 뒤든) 모든 것이 동기화됩니다. 이것이 오프라인 우선 설계를 한 문장으로 정리한 것입니다: 앱은 인터넷 연결 없이도 계속 작동하고, 변경 사항을 로컬에 저장하며, 다시 온라인이 되는 즉시 그것을 동기화합니다.

대부분의 앱 빌더는 만들기가 더 간단하다는 이유로 오프라인을 건너뜁니다. 하지만 오프라인 우선은 복잡한 게 아니라—의도적인 것입니다. 사람들이 다시 찾는 앱과 삭제해버리는 앱의 차이가 바로 여기서 갈립니다.

앱이 인터넷을 잃으면 실제로 무슨 일이 일어날까요?

앱이 인터넷을 잃으면 계속 작동하거나, 그렇지 않거나 둘 중 하나입니다—중간은 없습니다. 그리고 연결 끊김은 드문 일이 아닙니다: 비행기에 탄 사용자는 인터넷이 없고, 터널을 지나는 사용자는 신호가 없고, 시골 행사장에 있는 사용자는 접속이 불안정하고, 새벽 3시에 집 공유기가 재부팅되는 사용자는 죽은 와이파이에 발이 묶이고, 휴대폰 테더링을 쓰는 사용자는 핫스팟 용량 한도에 걸립니다.

이 모든 경우에, 앱은 작동하거나 작동하지 않거나 둘 중 하나입니다.

저희는 프리랜서용 시간 추적 앱을 만든 적이 있습니다. 오프라인 상태에서 앱이 멈췄죠. 건설 현장에서(신호가 전혀 없는 곳) 앱을 쓰던 프리랜서 한 명은 결국 사용을 그만두고—적어도 연필은 어디서나 작동하니까—연필과 종이로 돌아갔습니다. 3개월 뒤, 오프라인 모드가 추가되고 나서야 그는 다시 돌아왔고, 그 뒤로는 떠나지 않았습니다.

작동 원리는 간단합니다: 인터넷이 끊겼을 때 작업을 로컬에 저장하고, 연결이 돌아오면 동기화합니다. 그게 전부입니다.

오프라인에는 어떤 종류가 있을까요?

대비해야 할 오프라인 상황은 세 가지입니다: 의도된 오프라인, 예기치 못한 오프라인, 느린 오프라인—그리고 각각에는 서로 다른 해법이 필요합니다.

의도된 오프라인 — 사용자가 스스로 오프라인 작업을 선택한 경우입니다. 비행기 안이거나, 와이파이가 안 좋다는 걸 이미 알고 있는 상황이죠. 나중에 동기화될 거라고 예상하고 있습니다. 만들기 가장 간단한 유형입니다: 초안을 로컬에 저장하고, 연결이 돌아오면 서버로 밀어 넣기만 하면 됩니다.

예기치 못한 오프라인 — 인터넷이 갑자기 끊긴 경우입니다. 사용자는 뭔가를 한창 하던 중이었고요. 문장을 쓰다 말고 끊겨버리면 화가 나기 마련입니다. 해법 자체는 같지만(초안을 로컬에 저장), 사용자 경험은 더 배려 있게 만들어야 합니다: 앱이 계속 작동하고 있다는 것을 보여주고, 다시 온라인 상태가 되면 알려주세요.

느린 오프라인 — 연결은 되어 있지만, 너무 느려서 없는 것이나 마찬가지인 경우입니다. 고객이 양식을 작성하고 제출 버튼을 누른 뒤, 제출이 끝날 때까지 20초를 기다립니다. 그쯤 되면 뭔가 고장 났다고 생각하고 제출 버튼을 다시 누릅니다(이제 중복 제출이 생깁니다). 테스트하기 가장 어려운 유형이지만, 해법은 정직합니다: 작업이 진행 중임을 보여주거나(스피너), 초안을 잃지 않고 다른 화면으로 이동할 수 있게 해주세요.

빌더에게 오프라인 모드를 어떻게 요청해야 할까요?

한 번에 큰 기능 하나로 요청하기보다 조각조각 나눠서 요청하세요—오프라인 우선은 하나의 체크박스가 아니라 설계 철학입니다. 빌더에게 요청할 수 있는 구체적인 다섯 가지를 소개합니다.

초안을 로컬에 저장하기: “누군가 양식이나 메모를 작성할 때, 그것을 휴대폰/브라우저에 저장해주세요. 페이지를 새로고침해도 양식 내용이 그대로 남아 있어야 합니다.” 테스트 방법: 뭔가를 입력하고, 브라우저 탭을 닫았다가 다시 열어보세요. 양식 내용이 그대로 남아 있어야 합니다.
오프라인에서 작동하기: “인터넷이 없으면, 앱은 우리가 가진 데이터를 보여주고, 사용자가 그것을 읽고 수정할 수 있게 하고, 변경 사항은 인터넷이 돌아왔을 때 동기화되도록 대기열에 넣어주세요.” 테스트 방법: 와이파이를 끄고, 뭔가 쓸모 있는 작업을 해본 다음, 와이파이를 다시 켜서 데이터가 동기화되는지 지켜보세요.
조용히 동기화하기: “변경 사항을 동기화할 때 큰 대화상자를 띄우지 마세요. ‘저장 중…’ 같은 작은 표시를 상단에 보여주고, 끝나면 사라지게 해주세요. 저장이 실패하면 변경 사항을 로컬에 남겨두고 나중에 다시 시도해주세요.”
진실을 보여주기: “어떤 데이터가 최신인지(서버에서 방금 동기화된 것) 그리고 어떤 데이터가 로컬에만 있는지(아직 동기화되지 않은 것) 사용자에게 알려주세요. 작은 표시나 라벨을 사용하되—무섭게 만들지 말고, 그저 정직하게만 해주세요.”
하나의 핵심 작업을, 로컬 우선으로: “사용자가 앱을 찾는 진짜 이유(예약 확인, 메모 작성, 시간 기록)는 오프라인에서도 작동해야 합니다. 있으면 좋은 기능들(과거 기록 전체 검색, 실시간 가격 불러오기)은 인터넷을 요구해도 괜찮습니다.”

실제 사례들

웨딩 플래너는 RSVP를 관리하는 앱을 만들었습니다. 그는 명단을 출력해서 행사장을 돌아다니며 참석 여부를 체크하곤 했죠. 하지만 행사장의 와이파이는 형편없었습니다. 그는 오프라인 우선 방식을 요청했습니다: 체크리스트를 로컬에 저장하고, 집에 돌아오면 동기화하는 방식으로요. 이제 이 앱은 그의 주력 도구입니다—휴대폰 신호가 있을 때조차, 앱은 데이터를 기다릴 필요 없이 작동합니다. 그는 이 앱을 정말 좋아합니다.

교실의 선생님은 학생들의 학습 진도를 추적하는 앱을 사용했습니다. 접속이 불안정한 교실들 사이를 오갈 때마다 입력한 내용이 자꾸 사라졌죠. 오프라인 모드가 생기면서 그는 자유롭게 작업하고 나중에 동기화할 수 있게 되었고, 휴대폰과 업무 사이에서 선택할 필요가 없어졌습니다. 단 한 번의 변경이 신뢰를 크게 끌어올렸습니다.

보험 손해사정사는 현장에서(일부 시골 지역은 신호가 없는) 손해 보고서를 작성했습니다. 원래 앱은 제출하려면 인터넷이 필요했죠. 저희는 오프라인 초안 기능을 추가했습니다. 이제 그는 양식을 작성하고 오프라인 상태로 제출하면, 운전해서 돌아오는 동안 동기화가 이루어집니다. “집에 갈 때까지는 아무것도 제출할 수 없어요” 같은 말은 더 이상 없습니다.

이 세 가지 사례 모두 “그냥 더 좋은 와이파이를 쓰면 되잖아요”라고 말할 수도 있겠지만, 현실 세계는 그렇게 돌아가지 않습니다. 오프라인 우선은 더 나은 동기화보다 훨씬 큰 신뢰의 전환이었습니다.

오프라인 우선이 앱을 더 빠르게 만들어줄까요?

네—오프라인 우선 앱은 서버를 기다릴 필요가 없기 때문에 더 빠르게 느껴집니다. 입력하면 앱이 로컬에 즉시 저장하고, 백그라운드에서 동기화합니다. 스피너도, 기다림도 없습니다. 인터넷이 있을 때조차도, 서버가 방해가 되지 않기 때문에 경험은 더 경쾌합니다.

온라인 전용 앱은 모든 변경 사항에 대해 서버의 확인을 반드시 기다려야 합니다. 키 입력 → 네트워크 요청 → 서버 검증 → 응답 → 사용자에게 표시. 보통은 문제없지만, 느린 네트워크(또는 서버 응답이 느린 모바일 환경)에서는 상호작용 하나하나가 지연됩니다.

오프라인 우선을 구현하는 데 비용이 얼마나 들까요?

오프라인 우선은 초기에 엔지니어링 시간을 필요로 합니다. 빌더는 다음을 고민해야 합니다:

로컬 저장소: 앱이 튕겨도 사라지지 않도록 데이터를 휴대폰/브라우저에 저장하는 방법. 어렵지는 않지만, 반드시 의도적으로 설계해야 합니다.
충돌 해결: 사용자가 오프라인 상태에서 어떤 필드를 변경했는데, 동기화되기 전에 다른 누군가(또는 다른 기기)가 같은 필드를 변경했다면, 어느 쪽이 이길까요? 보통은 온라인 쪽이 이깁니다(더 최신이니까요), 하지만 사용자는 놀라는 대신 미리 경고를 받아야 합니다. 실제 예시: 휴대폰 두 대가 오프라인 상태에서 같은 메모를 편집하다가, 둘 다 온라인이 됩니다—나중에 동기화된 쪽이 이기고, 먼저 편집한 사용자는 “당신의 버전은 오래되었습니다. 여기 최신 버전이 있습니다”라는 메시지를 보게 됩니다.
오래된 데이터: 사용자가 3일 동안 오프라인 상태였다면, 다시 연결되었을 때 앱이 조용히 모든 것을 새로고침해야 할까요, 아니면 먼저 물어봐야 할까요? 물어보는 편이 더 안전합니다—오래된 데이터에 아직 저장되지 않은 변경 사항이 딸려 있을 수도 있으니까요.

이런 고민들이 공짜는 아니지만, 생각보다는 훨씬 간단합니다.

그 대가로 얻는 것: 사람들이 신뢰하는 앱입니다. 오프라인 우선 앱은 변명하지 않고(“이걸 쓰려면 인터넷이 필요해요”) 작업 내용을 잃어버리지도 않습니다. 이건 정말 큰 차이입니다.

앱이 오프라인에서 작동하는지 어떻게 테스트할까요?

테스트를 위해 비행기를 탈 필요는 없습니다—휴대폰의 비행기 모드가 여러분의 테스트 무대입니다. 방법은 다음과 같습니다:

열고 뭔가를 입력하세요: 평소처럼 뭔가를 해보세요(양식 작성, 메모 추가).
오프라인으로 전환하세요: 비행기 모드를 켜거나 와이파이를 끄세요.
계속 작업해보세요: 같은 작업을 다시 시도해보세요. 앱이 거부한다면 오프라인 우선이 아직 갖춰지지 않은 것입니다. 앱이 작동한다면 좋습니다. 헷갈린다면, “오프라인 상태입니다”라는 명확한 표시를 빌더에게 요청하세요.
다시 온라인으로 전환하세요: 비행기 모드를 끄세요.
동기화를 확인하세요: 변경 사항이 자동으로 동기화되었나요? ‘동기화’ 버튼을 클릭하거나 새로고침해야 했다면, 아직 완전히 갖춰진 게 아닙니다.

가장 잘 만들어진 오프라인 앱은 너무나 자연스러워서 오프라인 상태라는 걸 눈치채지 못합니다—그저 앱이 여전히 작동한다는 것만 알아챌 뿐이죠.

여러분이 만든 앱이 정말로 오프라인에서 작동해야 할까요? “우리 사용자들의 인터넷 상태가 불안정하다, 혹은 신호가 없는 곳에서 일한다”는 답이라면, 답은 ‘그렇다’입니다. “항상 안정적인 와이파이에 연결되어 있다”는 답이라면, 지금은 건너뛰어도 괜찮습니다. 하지만 누군가 “제 작업 내용을 잃어버렸어요”라고 말하는 순간, 더 일찍 요청해둘 걸 하고 후회하게 될 것입니다.