Walking Story가 먼저 로컬에 저장하는 이유

남기고 싶은 순간은 신호가 올 때까지 기다려 주지 않습니다

Walking Story는 산책용으로 설계됩니다. 공원, 골목, 산책로, 등하교 길, 저녁 동네 한 바퀴. 그 순간에는 바람과 울퉁불퉁한 지면, 다리 아래나 건물 사이에서 끊기는 수신이 따라옵니다. 사진이나 음성 메모 저장이 완벽한 네트워크 핸드셰이크를 기다려야 한다면, 제품은 지키려는 경험을 스스로 방해하게 됩니다.

그래서 우리는 로컬 우선 캡처를 선택 사항이 아니라 하드 룰로 둡니다. 사진, 음성, 텍스트 메모는 먼저 기기에 남아야 합니다. 클라우드 동기화, 전사(STT), Drive 업로드, 지명 조회 같은 원격 작업은 그 뒤에 백그라운드로 이어집니다. 로컬 저장이 성공하는 즉시 산책하는 사람에게 제어권을 돌려줍니다.

Walking Story는 아직 개발 중입니다. 아래 원칙은 캡처 경로를 어떻게 만들고 있는지, 로컬 우선 저널 앱에서 무엇을 기대하면 좋은지를 설명합니다. 완성된 제품처럼 포장하기보다 상태를 솔직히 적는 쪽을 택합니다.

실무에서 “로컬 우선”이 의미하는 것

로컬 우선은 “영원히 오프라인”이나 “동기화 없음”이 아닙니다. 방금 남긴 기록의 기준 원본이 손안의 기기라는 뜻입니다. 동기화는 지연되거나 실패하거나 재시도되어도, 이미 저장된 것을 지우지 않는 보강층입니다.

전형적인 캡처 순서

1. 산책 중 사진을 찍거나, 짧은 음성을 녹음하거나, 메모를 적습니다.
2. 앱이 로컬 저장소(예: Drift / 기기 파일)에 기록을 쓰고, 흔히 sync: false 같은 플래그와 함께 “이 기기에 저장됨” 상태를 둡니다.
3. UI는 곧바로 다음 입력을 받을 준비가 됩니다. Firebase·Drive·지오코딩·STT를 기다리는 긴 “저장 중…” 스피너가 없어야 합니다.
4. 백그라운드 작업이 타임아웃과 함께 업로드·전사·지명 부착을 시도합니다. 실패는 기록되고 나중에 재시도되며, 캡처 화면을 멈춰서는 안 됩니다.

장소 메타데이터를 붙이기 위한 GPS는 약 2초 정도의 짧은 타임아웃이나 마지막 알려진 위치를 쓰는 편이 맞습니다. 저장을 끝내기 전에 긴 위치 고정에 사람을 붙잡아 두는 것은 기능이 아니라 버그에 가깝습니다.

네트워크에 저장을 묶어두면 왜 깨져 보이는가

많은 클라우드 우선 앱은 모든 쓰기를 원격 쓰기로 가정합니다. 책상 앞에서는 통합니다. 산책에서는 익숙한 실패 모드가 생깁니다.

• 가짜 긴급성. 스피너는 네트워크가 답할 때까지 아무것도 안 저장된 것처럼 보이게 만듭니다 — 이미 디스크에 바이트가 있어도요.
• 놓친 순간. 터널이나 지하철에서 업로드가 끊기면 사람들은 캡처를 취소하거나 포기합니다.
• 불안 루프. “저장됐나?”가 장소보다 더 오래 기억됩니다.
• 배터리와 발열. 걸으면서 오래 라디오를 열어 두면, 방해하지 않아야 할 기기가 먼저 지칩니다.

로컬 우선은 감정적 계약을 바꿉니다. 기기가 로컬 기록을 확인하면 주머니에 넣어도 됩니다. 동기화는 Wi‑Fi 앞에서 따라오면 됩니다.

클라우드에서 여전히 일어나는 일(필요할 때)

로컬 우선은 공유·백업과 충돌하지 않습니다. Walking Story의 장기 표면에는 개인 이야기와, 공개된 산책을 한데 모은 블로그형 홈 — 예를 들어 …/walkingstory/{userHandle} 같은 핸들 기반 인덱스 — 이 포함됩니다. 일회성 공유 링크만이 전부가 아닙니다. 그런 표면에는 원격 저장이 필요합니다. 차이는 타이밍과 의존성입니다.

• 캡처 UX는 원격 성공을 await 하면 안 됩니다.
• 발행/공유 UX는 네트워크가 필요할 수 있습니다. 발행은 본질적으로 원격 행위이기 때문입니다.
• 백그라운드 동기화는 캡처 화면에서 기다리지 않게 두고, 업로드가 안 된 경우 나중에 상태가 보이면 됩니다.

발행 흐름이 완성되기 전까지 클라우드 기능은 진화 중으로 보시면 됩니다. 개발 중에도 타협하지 않으려는 불변 조건은 하나입니다. 네트워크가 흔들려도 캡처는 쓸 수 있어야 합니다.

산책하는 사람을 위한 설계 함의

솔직한 상태

로컬 우선 앱은 동기화 상태를 숨기지 않는 편이 좋습니다. “이 기기에 저장됨”과 “동기화 대기”는 유용한 사실입니다. 끝없는 스피너 뒤에 밀린 업로드를 감추면 신뢰를 깎습니다.

완벽한 글보다 작은 캡처

산책은 작은 조각들의 합입니다 — 사진 세 장, 음성 하나, 짧은 텍스트 둘. 각 조각은 싸게 커밋되어야 합니다. 다음 셔터 전에 매번 긴 클라우드 파이프라인이 필요하면, 저널은 산책 옷을 입은 책상 제품이 됩니다.

프라이버시 경계

초안을 기본으로 로컬에 두면 프라이버시 이야기도 선명해집니다. 발행을 고를 때까지 기기에 남는 것과, 이미 서버로 떠난 것은 다르게 이해됩니다. 기능이 성숙하면 제품 페이지와 법적 문서에서 보관 모델을 더 구체적으로 적을 예정입니다.

Zetty Factory 제품 스타일과의 연결

WaveLog와 PodWave는 듣기 도구입니다. iRing은 가족 플래너입니다. Walking Story는 밖에 있을 때를 위한 캡처·스토리 도구입니다. 일은 다르지만 스튜디오의 편향은 같습니다. 좁은 표면을 내고, 사용 맥락을 존중하며, 실제 마찰에서 개선합니다.

로컬 우선 캡처는 “라디오를 듣기 위해 계정을 만들지 않는다”, “학교 한 주가 여섯 개의 채팅에 살지 않게 한다”와 같은 계열입니다. 제약은 같습니다. 사람의 순간과 인프라 사이의 가짜 의존을 걷어내는 것.

개발 중인 앱에서 기대할 것

기능·플랫폼·동기화 백엔드는 아직 바뀔 수 있습니다. 플레이스홀더, 제한된 공유, 불완전한 클라우드 미러를 볼 수 있습니다. 바뀌지 않아야 하는 것은 산책 중 저장을 눌렀을 때의 우선순위입니다.

1. 로컬에 빠르게 남기고 확인한다.
2. 제어권을 산책하는 사람에게 돌려준다.
3. 타임아웃과 함께 백그라운드에서 동기화·보강한다.
4. 원격 실패로 캡처 UI를 멈추지 않는다.

제품 페이지에서 Walking Story를 따라가고 있다면, 이 저널 노트는 “개발 중” 배지 뒤의 설계 계약으로 읽어 주세요. 신호가 나빠도 빛이 좋을 때 방해하지 않는 도구가 신뢰를 얻는다는, 단순한 약속입니다.