2025년 8월 06일·7분
현장 설문 수집을 위한 모바일 앱 만드는 방법
오프라인 폼, GPS, 미디어 캡처, 동기화, 보안, 테스트 및 롤아웃을 포함해 현장 설문 수집을 위한 모바일 앱을 기획·설계·구축하는 방법을 알아보세요.
오프라인 폼, GPS, 미디어 캡처, 동기화, 보안, 테스트 및 롤아웃을 포함해 현장 설문 수집을 위한 모바일 앱을 기획·설계·구축하는 방법을 알아보세요.
모바일 현장 조사 앱은 단순한 “휴대폰의 폼”이 아닙니다. 실제 사람들이 증거를 수집하고, 결정을 내리며, 사무실과 루프를 닫을 수 있게 돕는 엔드투엔드 워크플로우입니다. 와이어프레임이나 기능 목록에 앞서 성공이 무엇인지, 누가 앱을 사용할지를 명확히 하세요.
설계 대상인 현장 역할을 명확히 하세요: 검사관, 연구원, 기술자, 감사관, 조사원(열거조사원), 계약자 등. 각 그룹은 작업 방식이 다릅니다.
검사관은 엄격한 준수 체크와 사진 증거를 필요로 할 수 있고, 연구원은 유연한 노트와 표본 추출을, 기술자는 자산에 연결된 빠른 이슈 로그를 필요로 할 수 있습니다. 사용자를 구체적으로 정의하면 폼 길이, 미디어 캡처, 승인, 오프라인 필요성 같은 제품 결정이 훨씬 쉬워집니다.
데이터 수집 후 무슨 일이 일어나는지 문서화하세요. 준수 보고서, 유지보수 우선순위 결정, 청구, 리스크 스코어링, 규제 감사 등에 사용되나요? 데이터가 결정을 촉진하지 않으면 종종 ‘있으면 좋은’ 잡음이 됩니다.
유용한 연습: 3–5개의 예시 결정을 적어보세요(예: “이 사이트 승인”, “48시간 내 수리 일정”, “비준수 표시”) 그리고 각 결정에 필요한 필드를 적어두세요.
일회성 조사(예: 초기 평가), 정기 방문(월간 검사), 감사, 또는 체크리스트 스타일 작업이 필요한지 결정하세요. 정기적 워크플로우와 감사는 보통 타임스탬프, 서명, 추적성이 필요하고, 체크리스트는 속도와 일관성을 강조합니다.
초기에 검증할 수 있는 지표를 선택하세요: 평균 완료 시간, 오류율(누락/잘못된 필드), 동기화 신뢰도(성공적 업로드), 재작업률(수정 요청된 설문). 이 지표들은 MVP에 집중하게 하고 이후 기능 팽창을 막습니다.
화면을 스케치하거나 데이터베이스를 선택하기 전에 현장이 실제로 어떤 느낌인지 구체적으로 파악하세요. 사무실에서는 완벽하게 작동하던 설문 앱이 진흙 속, 도로변, 창고 내부에서 빠르게 실패할 수 있습니다.
몇몇 현장 작업자를 따라가거나 짧은 인터뷰를 진행하세요. UI와 워크플로우에 직접 영향을 주는 제약을 문서화하세요:
이러한 세부사항은 더 큰 탭 대상, 자동 저장, 레코드당 단계 축소, 명확한 진행 표시 같은 요구사항으로 전환되어야 합니다.
일반적인 폰/태블릿에서 앱이 반드시 사용해야 하는 기능을 나열하세요:
팀이 이미 어떤 디바이스를 들고 다니는지, 무엇을 표준화하는 것이 현실적인지 확인하세요.
사용량을 정량화하세요: 작업자당 하루 레코드 수, 피크일, 레코드당 평균 첨부파일 수(사진, 오디오, 문서). 이는 오프라인 저장 필요량, 업로드 시간, 압축 수준에 영향을 줍니다.
수집된 데이터의 소유자가 누구인지(클라이언트, 기관, 하도급업체), 보존 기간, 삭제가 감사 가능해야 하는지 여부를 결정하세요. 이 답변들이 권한, 내보내기 요구, 장기 저장 비용을 형성합니다.
좋은 현장 데이터는 좋은 폼 디자인과 시간이 지나도 망가지지 않는 데이터 모델에서 시작됩니다. 이를 하나의 문제로 취급하세요: 추가하는 모든 질문 유형은 이후 어떻게 저장, 검증, 보고할지에 깔끔하게 매핑되어야 합니다.
대부분의 설문을 커버하는 작고 일관된 입력 집합으로 시작하세요:
옵션에는 라벨이 바뀌더라도 유지되는 내부 ID를 할당해 안정성을 확보하세요.
현장 팀은 빠르게 이동합니다. 조건부 로직은 관련 항목만 보이게 해줍니다:
로직을 단순한 규칙(조건 + 액션)으로 모델링하고, 폼 버전과 함께 규칙 정의를 저장해 과거 제출이 해석 가능하게 하세요.
검증은 일반적 오류를 막아야 하지만 오프라인에서도 실용적이어야 합니다:
실제 고치는 방법을 알려주는 명확한 메시지(“0과 60 사이의 값을 입력하세요”)를 사용하고, 무엇이 차단이고 무엇이 경고인지 결정하세요.
신뢰할 만한 접근법은: Form → Sections → Questions → Responses 와 메타데이터(사용자, 타임스탬프, 위치, 버전)를 함께 저장하는 것입니다. 응답은 가능하면 타입화된 값(숫자/날짜/문자열)으로 저장하세요.
폼을 버전 관리하세요. 질문이 바뀌면 새 버전을 만들어 분석 시 비교 가능하게 하세요.
사이트 검사, 고객 방문, 재고 확인 같은 공통 설문 패턴용 템플릿을 만드세요. 지역별 옵션 같은 통제된 커스터마이즈를 허용하되 모든 것을 포크하지는 마세요. 템플릿은 구축 시간을 단축하고 팀 간 결과의 일관성을 유지합니다.
현장 팀은 강한 햇빛, 비, 장갑, 시끄러운 거리 등에서 한 손으로 작업하는 경우가 많습니다. UX는 노력을 줄이고 실수를 예방하며 진행을 명확히 보여줘야 합니다.
데이터 입력이 연결성에 의존하지 않도록 설계하세요. 사용자가 오프라인에서 설문을 완전히 마치고 사진을 첨부하고 다음 작업으로 넘어갈 수 있게 하세요.
동기화 상태는 놓치기 어렵게 표시하세요: 레코드 수준과 헤더에 작은 전역 상태로 Not synced / Syncing / Synced / Needs attention 같은 명확한 표시를 두세요. 현장 작업자는 자신의 작업이 안전하게 업로드됐는지 추측하지 않아야 합니다.
큰 터치 대상, 명확한 간격, 높은 대비의 레이블을 사용하세요. 타이핑을 줄이기 위해:
텍스트가 필요할 때는 짧은 제안과 입력 마스크(전화번호 등)를 제공해 형식 오류를 줄이세요.
언제든지 임시저장을 지원하세요, 질문 중간에도 가능하게. 현장 작업은 방해받기 쉬우니 “나중에 재개”가 신뢰할 수 있게 작동해야 합니다.
내비게이션은 예측 가능해야 합니다: 간단한 섹션 목록, “다음 미완료” 버튼, 누락되거나 유효하지 않은 답변으로 바로 점프하는 검토 화면.
오류는 인라인으로 보여주고 고치는 방법을 설명하세요: “이 사이트에는 사진이 필요합니다” 또는 “값은 0과 100 사이여야 합니다”. “잘못된 입력” 같은 모호한 메시지는 피하세요. 가능한 경우 초기에 문제를 막도록 선택지를 제한하고 필드 아래에 예시를 보여주세요.
위치는 단순히 “데이터를 수집했다”에서 “언제, 어디서 수집했는지 증명할 수 있다”로 가는 차이를 만듭니다. 잘 설계된 위치 레이어는 맵에서 과제와 커버리지를 보여줘서 현장 팀과의 불필요한 왕복을 줄입니다.
설문 시작 시 GPS 좌표와 정확도 값을 기록하세요(예: 미터 단위). 정확도는 핀만큼 중요합니다: ±5m로 캡처된 포인트와 ±80m는 전혀 다릅니다.
도시 협곡, 밀집 산림, 실내 작업 등 GPS가 혼란스러울 때는 수동 조정을 허용하세요. 수정이 허용된다면 원본 판독값과 조정값, 선택적 이유를 기록해 리뷰어가 무슨 일이 있었는지 알 수 있게 하세요.
맵은 “다음에 무엇을 해야 하나”에 답할 때 가장 가치가 큽니다. 다음과 같은 맵 뷰를 고려하세요:
쿼터나 존 기반 워크플로우가 있으면 복잡한 GIS 도구 대신 간단한 필터(미방문, 오늘 마감, 우선순위 등)를 추가하세요.
지오펜싱은 승인된 경계 밖에서 제출을 차단하거나 경고를 표시할 수 있습니다(“할당 구역에서 300m 밖에 있습니다”). 데이터 품질을 보호하는 곳에만 사용하고, 지역에서 GPS가 신뢰할 수 없다면 경고 후 감독자 검토 방식이 더 낫습니다.
열기/저장/제출/동기화 같은 주요 타임스탬프와 각 이벤트의 사용자 ID/디바이스 ID를 기록하세요. 이 감사 추적은 규정 준수, 분쟁 해결, QA 개선에 도움이 되며 현장 작업자에게 추가 작업을 요구하지 않습니다.
현장 설문은 종종 증거가 필요합니다: 파손된 전봇대 사진, 누수의 짧은 비디오, 주민 인터뷰의 오디오 노트 등. 미디어를 부가 기능으로 다루면 현장 작업자는 개인 카메라 앱을 사용해 파일을 채팅으로 보내게 되고, 갭과 프라이버시 위험이 생깁니다.
미디어 캡처를 일급 질문 타입으로 만들어 첨부가 자동으로 올바른 레코드와 질문에 연결되게 하세요.
검토를 돕는 주석(캡션, 이슈 태그, 간단한 마크업)을 허용하되 경량으로 유지하세요—한 번 탭으로 캡처, 한 번 탭으로 수락, 그리고 다음으로 이동할 수 있게 합니다.
자산 조사에서는 바코드/QR 스캔이 타이핑 오류를 줄이고 반복 작업을 빠르게 합니다. 자산 ID, 재고 코드, 미터 번호 같은 필드에 스캔 입력을 사용하고 즉시 검증 피드백(예: “ID를 찾을 수 없음” 또는 “오늘 이미 조사됨”)을 보여주세요.
스캔 실패 시(더럽거나 저조도) 빠른 대체 수단으로 수동 입력과 “라벨 사진” 옵션을 제공하세요.
미디어는 모바일 데이터 요금을 압도할 수 있고 동기화를 느리게 합니다. 합리적 기본값을 적용하세요:
업로드 전에 최종 파일 크기를 미리 보여줘 사용자가 동기화 비용을 이해하게 하세요.
질문당·제출당 개수와 총 MB 같은 명확한 한도를 정의하세요. 오프라인일 때는 로컬에 첨부를 저장하되 다음 같은 규칙을 두세요:
이로써 앱을 현장에서도 안정적으로 유지하면서 저장공간과 데이터 요금의 놀라움을 방지합니다.
현장 설문 앱은 연결성이 불안정할 때 어떻게 동작하느냐에 따라 성공이 좌우됩니다. 목표는 간단합니다: 현장 작업자가 작업을 잃을까 걱정하지 않도록 하고, 감독자는 시스템의 데이터를 신뢰할 수 있어야 합니다.
동기화를 수동(명확한 “지금 동기화” 버튼)으로 할지 자동(백그라운드에서 조용히 동기화)으로 할지 결정하세요. 많은 팀은 하이브리드 방식을 씁니다: 연결이 괜찮을 때 자동 동기화하고, 마음의 평안을 위해 수동 제어를 제공합니다.
또한 백그라운드 재시도를 계획하세요. 업로드 실패 시 앱은 큐에 넣고 사용자가 다시 입력하지 않도록 나중에 재시도해야 합니다. 인터럽트 대신 작은 상태 표시(“3개 항목 대기 중”)를 보여주세요.
디바이스를 작업 공간의 기본으로 가정하세요. 사용자가 온라인이든 오프라인이든 모든 폼과 편집을 즉시 로컬에 저장하세요. 이 오프라인 퍼스트 접근은 짧은 신호 중단으로 인한 데이터 손실을 방지하고 앱이 더 빠르게 느껴지게 합니다.
동일 레코드가 두 디바이스에서 편집되거나 감독자가 오프라인 상태의 현장 작업자를 대신해 케이스를 업데이트할 때 충돌이 발생합니다. 운영에 맞는 전략을 선택하세요:
규칙을 쉬운 언어로 문서화하고 변경 이력을 남겨 추적 가능하게 하세요.
사진·오디오·비디오는 동기화가 깨지는 주요 지점입니다. 작은 청크 단위의 증분 업로드와 재개 가능한 전송을 사용해 30MB 비디오가 95%에서 실패해 다시 처음부터 시작하지 않도록 하세요. 사용자가 작업하는 동안 백그라운드에서 미디어가 업로드되게 하세요.
동기화 실패, 디바이스별 마지막 동기화, 저장공간 압력, 앱 버전 같은 항목을 보여주는 대시보드나 보고 도구를 제공하세요. 간단한 “디바이스 헬스” 뷰는 지원 시간을 절약하고 데이터 품질을 보호합니다.
현장 설문 앱은 위치, 사진, 응답자 정보, 운영 메모 등 민감한 정보를 다루는 경우가 많습니다. 보안과 개인정보는 "있으면 좋은" 기능이 아니라 필수입니다 — 사람들이 앱을 신뢰하지 않으면 사용하지 않으며 규정 위험을 초래할 수 있습니다.
역할 기반 접근 제어(RBAC)로 간단하게 시작하세요:
제출 후 누가 편집 가능한지, 누가 레코드를 삭제할 수 있는지, 누가 PII를 볼 수 있는지를 실제 워크플로우에 맞춰 설계하세요. 유용한 패턴은 감독자는 운영 필드(상태, GPS, 타임스탬프)는 볼 수 있지만 응답자 세부정보는 필요할 때만 제한적으로 접근하게 하는 것입니다.
현장 작업은 오프라인에서 이뤄지므로 데이터가 로컬에 저장됩니다. 휴대폰은 분실될 수 있다고 가정하세요.
자동 로그아웃, 생체/핀 잠금, 세션 취소 또는 원격 데이터 삭제 기능도 고려하세요.
로그인 방식은 현장 팀의 실제 운영 방식에 맞아야 합니다:
어떤 방식을 선택하든 빠른 계정 복구와 명확한 세션 처리를 지원하세요 — 잠금으로 작업이 중단되면 현장 작업이 멈춥니다.
정말로 필요한 것만 수집하세요. PII가 필요하다면 왜 필요한지 문서화하고 보존 규칙을 정하며 동의를 명시적으로 받으세요.
경량 동의 흐름: 짧은 설명이 있는 체크박스, 필요 시 서명 필드, 언제·어떻게 동의가 확보되었는지 기록하는 메타데이터를 포함하세요. 이는 설문을 존중하게 만들고 나중에 감사하기 쉽게 합니다.
기술 스택은 현장 팀의 실제 작업 방식에 맞아야 합니다: 불안정한 연결성, 혼합된 디바이스, 업데이트를 중단 없이 배포해야 하는 필요성 등. “최고”의 스택은 팀이 빠르게 빌드·유지·반복할 수 있는 스택입니다.
iOS와 Android를 모두 지원해야 한다면 크로스플랫폼 프레임워크가 MVP를 빠르게 만드는 경로인 경우가 많습니다.
실용적 절충안은 대부분의 UI와 로직을 크로스플랫폼으로 개발하고 필요한 부분만 네이티브 모듈로 구현하는 방법입니다(예: 특수 블루투스 SDK).
백엔드는 사용자 계정, 폼 정의, 제출물, 미디어 파일, 동기화를 처리해야 합니다.
어떤 선택을 하든 오프라인 퍼스트 클라이언트, 로컬 저장소, 동기화 큐, 서버 측 검증을 중심으로 설계하세요.
만약 처음 버전을 빠르게 가속화하고 전통적인 전체 빌드를 당장 선택하기 어렵다면, 챗 기반 명세로 웹 관리자, 백엔드 API, 심지어 모바일 앱의 프로토타입을 생성해주는 vibe-coding 플랫폼(예: Koder.ai)을 고려해보세요. 현장 설문 제품은 폼 정의, 권한/역할, 동기화 동작을 빠르게 반복해야 하므로 프로토타입에서 소스 코드를 내보내 프로젝트를 인하우스로 이전할 준비를 할 수 있습니다. (Koder.ai는 보통 웹에 React, 백엔드 서비스에 Go + PostgreSQL, 모바일에 Flutter를 제공합니다.)
현장 데이터는 혼자 존재하지 않습니다. 일반적인 통합 대상은 CRM/ERP, GIS 시스템, 스프레드시트, BI 도구입니다. 다음을 갖춘 아키텍처를 선호하세요:
일반적인 규칙:
시간이 촉박하면 첫 릴리스를 신뢰할 수 있는 캡처와 동기화에 집중하세요 — 나머지는 그 위에 쌓으면 됩니다.
전체 빌드에 착수하기 전에 현장에서, 실제 디바이스에서, 실제 제약 조건 하에서 앱이 작동함을 증명하는 작은 프로토타입을 만드세요. 좋은 프로토타입은 다듬어진 데모가 아니라, 변경 비용이 적을 때 사용성 문제와 요구사항 누락을 빠르게 드러내는 도구입니다.
일상 작업을 대표하는 2–3개의 핵심 흐름으로 시작하세요:
프로토타입은 핵심 경험을 검증하는 데 집중하세요. 모든 폼 유형이나 기능을 다 구현하려 하지 마세요.
빠르게 진행하려면 기획 우선 접근(사용자 역할 → 워크플로우 → 데이터 모델 → 화면)을 사용하고 작업 골격을 빠르게 생성하세요. 예를 들어 Koder.ai의 planning mode는 요구사항을 빌드 계획과 기본 구현으로 전환하는 데 도움이 되고, 스냅샷 및 롤백 기능은 프로토타입 사이클 동안 공격적으로 반복하는 것을 더 안전하게 만듭니다.
실사용자(이해관계자가 아닌 실제 현장 사용자)와 실제 조건(강한 햇빛, 장갑, 불안정한 수신, 구형 폰, 시간 압박)에서 빠른 현장 테스트를 하세요. 참가자들에게 작업하면서 생각을 말하게 하면 혼란스러운 부분을 직접 들을 수 있습니다.
테스트 중 다음과 같은 구체적인 이슈를 추적하세요:
작은 지연도 하루에 수십 건의 설문을 완료할 때 누적됩니다.
사용자 테스트 결과를 바탕으로 질문 순서, 그룹화, 검증 메시지, 기본값(예: 자동 채움 날짜/시간, 마지막 사용된 사이트, 흔한 답변)을 다듬으세요. 초기에 폼 디자인을 다듬으면 비싼 재작업을 줄이고 MVP 빌드를 수월하게 합니다. 범위를 정의할 때는 /blog/mobile-app-mvp를 참조해 우선순위를 정하세요.
책상에서의 테스트만으론 부족합니다. 출시 전에 폼, GPS, 동기화가 지하실, 농촌 도로, 붐비는 작업 현장에서도 동일하게 동작한다는 증거가 필요합니다.
구조화된 오프라인 시나리오를 실행하세요: 비행기 모드에서 설문 생성, 신호가 한 칸인 지역, 네트워크 전환(Wi‑Fi → LTE) 중 작성 등. 사용자가 목록을 검색하고 초안 저장하고 큐를 제출하는 등 작업을 잃지 않는지 확인하세요.
특히 경계 타이밍 이슈에 주의하세요: 예를 들어 현지 시간으로 11:58에 저장한 폼이 자정 이후에 동기화될 때, 또는 여행 중 디바이스가 시간대를 변경할 때 타임스탬프가 백엔드와 보고서에 일관되게 남는지 검증하세요.
기기 종류와 환경(도시 협곡, 창가 근처 실내, 탁 트인 필드)별로 GPS 정확도를 테스트하세요. 무엇을 "충분"으로 볼지 정의하고(예: 30m 이하일 때 경고) 해당 프롬프트를 검증하세요.
또한 깔끔한 설치 상태에서 권한 흐름을 테스트하세요: 위치, 카메라, 저장소, 블루투스 통합, 백그라운드 동기화. 많은 실패가 사용자가 한 번 "허용 안 함"을 탭한 데서 시작됩니다.
스킵 로직, 계산, 필수 필드, 검증 규칙에 대한 회귀 테스트를 자동화하세요. 폼 업데이트마다 이전 가정이 깨질 수 있으니 자동화된 검사가 출시를 안전하게 합니다.
누락되는 항목이 없게 간단한 체크리스트를 사용하세요:
현장 설문 앱은 팀이 정확하고 일관되며 편안하게 사용해야 가치를 제공합니다. 출시를 단순히 앱 스토어에 올리는 버튼 이벤트가 아니라 운영 프로젝트로 다루세요.
"10분 안에 배우고 하루 만에 숙달"을 목표로 하세요. 앱 내에서 온보딩을 제공해 사용자가 설명서를 찾지 않게 하세요.
포함 항목:
현실적인 작업 조건을 대표하는 파일럿 팀으로 시작하세요(다양한 지역, 디바이스, 숙련도 포함). 피드백 루프를 빡빡하게 유지하세요:
단계적 롤아웃은 위험을 줄이고 내부 챔피언을 만들어 다른 팀 교육을 돕게 합니다.
현장 데이터 수집은 검토되고 활용돼야 가치가 있습니다. 단순한 보고 옵션을 제공하세요:
보고는 결정에 초점을 맞추세요: 무엇이 완료됐고, 무엇이 주의가 필요한지, 무엇이 의심스러운지.
분석으로 마찰 지점을 찾아 개선하세요:
이 인사이트를 바탕으로 폼을 단축하고, 문구를 명확히 하고, 검증 규칙을 조정하고, 워크플로를 개선하고, 할당을 조정해 팀 생산성을 유지하고 데이터 신뢰도를 높이세요.
먼저 주요 사용자(검사관, 기술자, 조사원 등)와 데이터가 결정 지원에 어떻게 쓰일지(예: 현장 승인, 수리 일정, 비준수 표시 등)를 정의하세요. 그런 다음 설문 빈도(일회성 vs 반복 vs 감사)를 정하고, 평균 완료 시간, 오류율, 동기화 신뢰도, 재작업률 같은 측정 가능한 지표를 설정해 MVP가 방향을 잃지 않도록 하세요.
오프라인을 정상 상태로 가정하세요. 다음과 같은 제약을 설계에 반영해야 합니다:
이 제약들은 자동 저장, 레코드당 단계 축소, 큰 터치 대상, 명확한 진행/동기화 표시 등으로 구체화됩니다.
빠르고 보고 가능해야 하는 입력을 우선하세요:
옵션에는 내부 ID를 부여해 라벨이 바뀌어도 분석과 검증이 유지되도록 하세요.
관련 항목만 보이게 하는 조건부 로직을 사용하세요(예: “파손 = 예”일 때 파손 유형 질문 표시). 로직은 조건 → 액션 같은 단순 규칙으로 모델링하고, 폼 버전과 함께 규칙을 저장해 폼이 진화해도 이전 제출을 해석할 수 있게 하세요.
오류가 자주 발생하는 곳에 검증을 집중하세요:
명확한 메시지(“0과 60 사이의 값을 입력하세요”)를 제공하고, 오프라인 상황을 고려해 무엇을 차단(hard block)하고 무엇을 경고(warning)로 둘지 결정하세요.
오프라인 퍼스트 접근을 사용하세요:
목표는 현장 작업자가 자신의 작업이 안전하게 저장됐는지 의심하지 않도록 하는 것입니다.
GPS 좌표를 기록할 때 **정확도 값(미터)**도 함께 저장하고, 열기/저장/제출/동기화 같은 주요 타임스탬프와 사용자/디바이스 ID를 남겨 추적 가능하게 하세요. GPS가 부정확할 경우 수동 조정을 허용하되 원본 값과 조정된 값을 모두(선택적으로 이유도) 기록해 검토자가 상황을 이해할 수 있게 하세요.
미디어를 폼의 핵심 타입으로 다루세요:
이렇게 하면 현장 팀이 개인 카메라 앱을 사용해 파일을 외부로 전송하는 일을 막을 수 있습니다.
동일 레코드가 여러 디바이스에서 수정될 때의 전략을 운영 방식에 맞게 고르세요:
항상 변경 이력을 남겨 누가 언제 무엇을 바꿨는지 확인할 수 있게 하세요.
팀 역량과 디바이스 요구에 맞춰 선택하세요:
백엔드는 관리형(Postgres + 관리형 인증), 서버리스, 또는 커스텀 중 선택할 수 있으며, 어떤 선택이든 오프라인 퍼스트 클라이언트, 동기화 큐, 안정적인 API(REST/GraphQL)로 통합을 계획하세요.