2025년 9월 18일·8분
오프라인 현장 데이터 수집용 모바일 앱을 만드는 방법
오프라인 우선 모바일 앱을 기획·설계·구축하는 방법: 저장소, 동기화, 충돌 처리, 보안, 테스트 전략을 포함한 가이드
오프라인 우선 모바일 앱을 기획·설계·구축하는 방법: 저장소, 동기화, 충돌 처리, 보안, 테스트 전략을 포함한 가이드
도구를 고르거나 화면을 설계하기 전에, 현장에서 일이 어떻게 진행되는지—그리고 팀에게 ‘오프라인’이 무엇을 의미해야 하는지—명확히 하세요. 이 섹션은 실제 루틴을 테스트 가능하고 지원할 수 있는 요구사항으로 바꾸는 방법에 관한 내용입니다.
역할을 명확히 하세요: 검사관, 설문조사원, 기술자, 감사관, 커뮤니티 워커, 계약자 등. 각 역할은 제약 조건이 다를 수 있습니다(보호장비, 한 손 사용, 긴 이동일, 기기 공유 등).
작업 장소를 문서화하세요: 실내 시설, 지하실, 외딴 도로, 농장, 건설 현장 또는 국경을 넘는 지역 등. 간헐적 수신, 충전 기회, 사용자가 “동기화 대기”를 할 수 있는지 여부(대부분 불가능함) 같은 실무적 현실을 기록하세요.
앱이 작업, 자산, 위치 또는 고객에 귀속시켜 수집해야 할 레코드를 나열하세요. 각 필드와 파일 유형에 대해 구체적으로 적습니다. 예:
또한 무엇이 ‘완료’인지 정의하세요: 레코드를 초안으로 저장할 수 있는가, 제출 후 나중에 승인될 수 있는가 등.
최대 오프라인 일수, 기기당 예상 기록 수, 첨부파일 최대 크기 같은 운영 목표를 정의하세요. 이 수치는 로컬 저장 필요량, 성능 제한, 동기화 동작을 결정합니다.
공유 기기, 하루에 여러 작업 수행, 사용자가 오프라인 상태에서 과거 기록을 검색해야 하는지 같은 엣지 제약도 포함하세요.
개인식별정보(PII), 동의 요건, 보존 규칙, 감사 추적이 필요한지 확인하세요. 승인(감독자 검토, QA 체크 등)이 필요한 경우 어떤 동작을 오프라인에서 차단해야 하고 어떤 동작은 나중에 큐에 넣을 수 있는지 정의하세요.
오프라인 우선 설계는 가혹할 정도로 명확한 범위에서 시작합니다. 오프라인으로 허용하는 기능이 많아질수록 로컬 저장, 동기화 복잡도, 충돌 위험이 커집니다 — 따라서 신호가 끊겼을 때 ‘반드시’ 작동해야 하는 것을 정의하세요.
대부분의 현장 데이터 수집 팀에겐 네트워크에 의존하지 않고 지원해야 하는 핵심 작업 세트가 있습니다:
읽기 전용 vs 완전 편집 가능을 명확히 하세요. 오프라인에서의 편집 허용은 일반적으로 모바일 오프라인 동기화와 이후 충돌 해결을 필요로 합니다.
오프라인 복잡도를 줄이는 실용적 방법은 가장 작은 오프라인 루프를 먼저 제공하는 것입니다:
만약 ‘있으면 좋은’ 기능이 참조 데이터의 과도한 캐싱이나 복잡한 병합을 강제한다면 핵심 워크플로가 안정화될 때까지 연기하세요.
일부 동작은 오프라인(또는 참조 데이터가 오래된 경우)에 차단해야 합니다. 예:
“오프라인에서 초안 허용, 제출은 동기화 필요” 같은 명확한 규칙을 사용하세요.
연결 상태를 숨기지 마세요—명확히 표시하세요:
이 범위 정의는 이후의 모든 결정(데이터 모델, 백그라운드 동기화, 기기 보안 등)에 대한 계약이 됩니다.
오프라인 앱의 아키텍처는 “연결 없음”을 예외가 아니라 정상 상태로 만들어야 합니다. 목표는 데이터 입력을 기기 내에서 빠르고 안전하게 유지하면서 연결이 복구될 때 동기화를 예측 가능하게 만드는 것입니다.
iOS, Android, 또는 둘 다 대상으로 할지 결정하세요.
사용자가 주로 한 플랫폼을 쓴다면(엔터프라이즈 배포에서 흔함), 네이티브 빌드는 성능 튜닝, 백그라운드 동작, OS별 저장/보안 기능을 단순화할 수 있습니다. iOS와 Android를 동시에 초기 지원해야 한다면 React Native나 Flutter 같은 크로스플랫폼 프레임워크가 UI 중복 작업을 줄여주지만, 백그라운드 동기화, 권한(GPS/카메라), 파일 저장소에 대해 플랫폼별 처리가 여전히 필요합니다.
빠르게 진행하고 의견이 있는 경로를 원한다면 웹, 백엔드, 모바일 전반에서 작은 기술 스택을 표준화하는 것이 도움이 됩니다. 예를 들어 Koder.ai 같은 플랫폼은 웹(주로 React), 백엔드(Go + PostgreSQL), 모바일(Flutter) 등으로 구성된 채팅 기반 워크플로우를 제공합니다. 플랫폼을 전부 채택하지 않더라도 이러한 표준화 마인드는 오프라인 우선 개발을 확장하고 유지관리하기 쉽게 만듭니다.
오프라인 앱의 생명은 기기 내 DB에 달려 있습니다. 일반 옵션:
무엇을 선택하든 신뢰할 수 있는 마이그레이션, 구형 기기에서의 쿼리 성능, 암호화 지원을 우선시하세요.
REST와 GraphQL 모두 오프라인 동기화에 쓸 수 있지만 하나를 선택하고 시간이 지남에 따른 변경을 고려해 설계하세요.
명시적인 버전 전략(예: /v1 엔드포인트 또는 스키마 버전)을 추가해 구버전 앱도 롤아웃 중 안전하게 동기화하도록 하세요.
사진, 서명, 오디오, 문서 등은 별도 계획이 필요합니다:
UI → 로컬 DB → 동기화 워커 → API의 깔끔한 분리는 네트워크가 불안정해도 오프라인 캡처를 신뢰할 수 있게 합니다.
오프라인 앱은 로컬 데이터 모델에 의해 좌우됩니다. 목표는 간단합니다: 현장 직원이 레코드를 생성하고 초안으로 저장하며 나중에 편집하고 심지어 삭제할 수 있어야 합니다—네트워크를 기다릴 필요 없이. 따라서 로컬 DB는 ‘진행 중 작업(work in progress)’을 표현해야 합니다.
실용적 접근은 각 레코드를 sync state(예: draft, pending_upload, synced, pending_delete)로 저장하는 것입니다. 이렇게 하면 “로컬에서 삭제했지만 재시작 후 보이는” 같은 까다로운 엣지 케이스를 피할 수 있습니다.
편집에 대해서는 (a) 최신 로컬 버전 + 보류 중 변경 목록을 유지하거나, (b) 서버 필드를 덮어쓸 전체 로컬 레코드를 유지하는 방식을 고려하세요. (a)는 더 복잡하지만 이후 충돌 처리에 도움이 됩니다.
비기술 사용자라도 몇 가지 일관된 필드는 디버그와 조정에 크게 도움이 됩니다:
오프라인에서 ID를 생성한다면 충돌 방지를 위해 UUID를 사용하세요.
현장 앱은 자산 목록, 사이트 계층, 선택 목록, 위험 코드 등 카탈로그에 의존하는 경우가 많습니다. 이들 또한 로컬에 저장하고 참조 데이터 버전(또는 last_updated_at)을 추적하세요. 변경된 부분만 부분 업데이트할 수 있게 설계하면 전체를 다시 다운로드할 필요가 없습니다.
오프라인 사용자는 즉각적인 결과를 기대합니다. “사이트별”, “상태별”, “최근 업데이트” 및 자주 검색되는 식별자(자산 태그, 작업 지시 번호)에 대한 인덱스를 추가하세요. 이렇게 하면 로컬 DB가 몇 주간 성장해도 UI 반응성이 유지됩니다.
현장 팀은 사무실 사용자처럼 ‘폼을 채우는’ 것이 아닙니다. 비가 오고, 현장을 이동하고, 중단되는 상황에서 작동해야 합니다. 데이터 캡처가 연결 유무와 관계없이 끊기지 않도록 만드는 것이 목표입니다.
모든 키 입력을 가치 있게 취급하는 폼 엔진으로 시작하세요. 초안을 로컬에 자동 저장하고(제출 시만이 아님), 저장을 보이지 않게 만드세요: 스피너나 사용자를 차단하는 “잠시 기다려주세요” 대화상자 없음.
로컬에서 유효성 검사를 수행해 사용자가 네트워크 없이도 작업을 완료하게 하세요. 규칙은 단순하고 빠르게(필수 필드, 범위, 기본 형식) 유지하세요. 서버 검증이 필요한 일부 체크(예: ID 확인)는 "동기화 시 검증됨"으로 명확히 표시하고 사용자가 계속 진행할 수 있게 하세요.
무거운 화면을 피하세요. 긴 워크플로는 작은 단계로 나누어 진행 상태(예: "1/4")를 보여주세요. 이는 충돌 감소, 재개 용이성, 저사양 기기 성능 개선에 도움이 됩니다.
실제 검사는 종종 “항목 추가” 패턴을 포함합니다: 여러 자산, 판독값, 결함 등. 다음을 지원하세요:
조건부 질문은 오프라인에서 결정적이어야 합니다. 조건은 기기에 이미 있는 값(이전 답변, 사용자 역할, 선택된 사이트 유형)에만 의존하게 하세요. 서버 조회에 의존하면 안 됩니다.
관련될 때 앱이 맥락을 자동으로 수집하게 하세요:
이 신호들을 사용자 입력 값 옆에 저장하면 이후 레코드의 감사성과 신뢰성을 확보할 수 있습니다.
각 첨부파일을 작은 작업 단위로 취급하세요. 업로드 큐와 재시도/재개를 지원하고 파일별 상태(대기, 업로드 중, 실패, 업로드 완료)를 표시하세요. 백그라운드에서 첨부파일이 업로드되는 동안에도 사용자가 계속 작업할 수 있게 하고, 오프라인이면 폼 제출을 차단하지 마세요.
현장 팀은 보통 ‘폼만’ 사용하는 것이 아닙니다. 그들은 참조 정보—자산 목록, 고객 사이트, 장비 카탈로그, 선택 목록, 안전 체크리스트—도 필요하며, 종종 신호가 끊겨도 작동하는 지도를 필요로 합니다. 이런 것들을 1등 시민 기능으로 취급하세요.
워크플로우를 가능하게 하는 최소 참조 데이터 집합(예: 할당된 작업 지시, 자산 ID, 위치, 허용 값)을 식별하세요. 그런 다음 지역/프로젝트/팀/날짜 범위별 부분 다운로드를 지원해 기기가 모든 것을 저장하지 않도록 하세요.
실용적 접근은 “오프라인용 다운로드” 화면을 제공하는 것입니다. 이 화면은:
을 보여줍니다.
현장 기술자가 네비게이션과 컨텍스트를 필요로 한다면 선택된 영역의 타일을 프리페치해 오프라인 지도를 구현하세요(예: 작업 사이트 주변 바운딩 박스 또는 경로 구간). 총 용량과 영역별 한도를 강제해 무심코 저장 공간을 가득 채우는 일을 방지하세요.
다음과 같은 제어를 포함하세요:
빠른 조회 없이는 오프라인 접근이 답답합니다. 주요 필드(ID, 이름, 태그, 주소)에 인덱스를 추가하고 실제 작업에 맞는 필터(프로젝트, 상태, 내게 할당된 항목)를 지원하세요. “이번 주 내 사이트” 같은 저장된 쿼리는 탭 조작을 줄이고 오프라인을 더 효율적으로 만듭니다.
참조 데이터와 지도 영역의 “신선도”: 마지막 동기화 시간, 데이터셋 버전, 업데이트 대기 여부를 항상 표시하세요. 무언가가 오래되었다면 명확한 배너를 보여 제한사항을 알리고, 다음 연결 시 갱신을 큐에 넣을 수 있게 하세요.
동기화는 현장에서 일어난 일이 사무실에 전달되는 가교입니다. 신뢰 가능한 전략은 연결이 예측 불가능하고 배터리가 제한되며 사용자가 업로드 중 앱을 닫을 수 있음을 전제로 합니다.
팀마다 타이밍이 다릅니다. 일반적 트리거는:
대부분 앱은 기본적으로 백그라운드 동기화를 하고, 불안한 사용자를 위해 수동 옵션을 함께 제공합니다.
모든 생성/수정/삭제를 아웃박스 큐에 로컬 이벤트로 기록하세요. 동기화 엔진은 아웃박스를 읽어 서버로 변경을 전송하고 각 이벤트를 확인 표시합니다.
이 방식은 동기화를 회복력 있게 만듭니다: 사용자는 계속 작업할 수 있고, 어떤 항목이 아직 업로드되지 않았는지 항상 알 수 있습니다.
모바일 네트워크는 패킷을 잃고 사용자가 “동기화”를 여러 번 탭할 수 있습니다. 요청을 반복해도 레코드가 중복 생성되지 않도록 설계하세요.
실용적 전술:
하루 오프라인 후에는 업로드량이 많아질 수 있습니다. 타임아웃과 스로틀을 방지하려면:
진행 상황을 가시적으로 보여주세요(예: “120개 중 23개 업로드됨”)—현장 직원이 앱을 신뢰하고 다음 행동을 알 수 있게 합니다.
오프라인 작업은 동일 레코드의 두 가지 진실이 존재할 수 있음을 의미합니다: 기기에서 변경된 것과 누군가가 서버에서 변경한 것. 이 문제를 계획하지 않으면 설명할 수 없는 덮어쓰기, 누락 값, 재현 불가능한 지원 티켓이 생깁니다.
동일 레코드가 두 곳에서 편집되었을 때 앱이 어떻게 해야 하는지 정의하세요.
이 규칙들을 문서화하고 앱 전반에 일관되게 재사용하세요. “상황에 따라 다르다”는 괜찮지만, 레코드 유형별로 예측 가능해야 합니다.
검사나 서명처럼 가치가 높은 데이터는 무작정 자동 병합하면 안 됩니다. 충돌 UI는 두 가지 질문에 답해야 합니다:
사용자에게 선택권을 주세요: 내 것 유지, 서버 것 유지, 또는(지원하면) 필드별 선택. 전문 용어 대신 평이한 문구를 사용하세요—타임스탬프는 실제로 도움이 될 때만 보여주세요.
최고의 충돌은 애초에 발생하지 않는 충돌입니다. 가벼운 레코드 잠금, 작업 할당(한 사람이 작업을 소유), 또는 편집 창(제출 후 레코드를 읽기 전용으로) 같은 전술이 충돌을 줄입니다.
또한 로컬에서 서버와 동일한 유효성 검사를 수행하세요(필수 필드, 범위). 이는 “오프라인에서 수락되었지만 나중에 거부됨” 같은 깜짝 상황을 줄입니다.
동기화를 비즈니스 프로세스로 취급하고 로컬에 타임스탬프, 오류 코드, 재시도 횟수 등을 포함한 동기화 로그를 저장하세요. 사용자가 “내 업데이트가 사라졌다”고 보고하면 해당 레코드가 업로드 실패했는지, 충돌했는지, 서버 검증에서 거부되었는지 추적할 수 있어야 합니다.
현장 데이터 수집에는 고객 세부정보, 위치, 사진, 검사 메모가 포함되는 경우가 많습니다. 이러한 데이터가 오프라인 사용을 위해 로컬에 저장되면 폰 자체가 보안 경계의 일부가 됩니다.
민감하거나 규제 대상 정보를 수집한다면 로컬 DB와 첨부 파일 저장소를 암호화하세요. iOS와 Android에서는 플랫폼 기반의 키 저장소(Keychain / Keystore)를 사용해 암호화 키를 보호하세요—비밀을 하드코딩하거나 평문 환경설정에 키를 저장하지 마세요.
실용적 접근법은: 로컬 DB 암호화, 대형 첨부파일 별도 암호화, 사용자 로그아웃 또는 정책 필요 시 키 회전입니다.
강력한 인증과 단기 액세스 토큰을 사용하세요. 로그인 후 ‘오프라인’이 무엇을 의미하는지 계획하세요:
이렇게 하면 기기 분실 시 노출을 줄이고 캐시된 데이터에 무기한 접근하는 것을 방지합니다.
오프라인 앱은 창고, 현장, 로비 등 공공장소에서 사용됩니다—화면 단위 보호가 필요합니다.
오프라인 데이터는 동기화 전에 편집될 수 있습니다. 위변조 위험을 줄이려면 검증을 염두에 두고 설계하세요:
created_at, created_by, updated_at, device_id, 그리고 필요시 GPS 타임스탬프/출처이 조치들이 모든 위험을 없애진 못하지만 앱을 사용하기 어렵게 만들지 않으면서 오프라인 저장을 더 안전하게 합니다.
현장 사용자는 ‘기술’보다는 앱이 무슨 일이 일어나고 있는지 알려주고 계속 작업하게 해주는지를 더 중시합니다. 오프라인 우선 설계는 엔지니어링 만큼이나 UX 문제입니다: 사용자가 상태를 신뢰하지 못하면 자체적인 대체 방식(종이, 중복 제출, 스크린샷)을 만들 것입니다.
사용자가 자연스럽게 보는 위치에 연결 및 동기화 상태를 표시하되 시끄럽지 않게 하세요.
간단한 상태 표시(예: Offline / Syncing / Up to date)와 항상 표시되는 “마지막 동기화” 타임스탬프를 사용하세요. 문제가 발생하면 사용자가 해제하거나 해결될 때까지 유지되는 오류 배너를 보여주세요.
좋은 오프라인 지표는 사용자가 다음 질문에 답하게 돕습니다:
동기화가 가끔 정체되는 것은 정상입니다(열악한 네트워크, OS 백그라운드 제한, 서버 이슈). 실무에 맞는 제어를 제공하세요:
백그라운드 동기화를 지원한다면 큐 수(예: “3개 항목 대기 중”)를 표시해 사용자가 추측하지 않게 하세요.
“동기화 실패”처럼 모호한 오류 메시지를 피하고, 무슨 일이 일어났는지와 다음 단계(무엇을 해야 할지)를 평이한 언어로 설명하세요.
예시:
메시지에 “다시 시도”, “설정 열기”, “지원 문의” 같은 다음 단계 버튼을 연결해 사용자가 빠르게 복구할 수 있게 하세요.
현장 데이터 수집은 종종 구형 휴대폰, 제한된 저장소, 불규칙한 충전 환경에서 이루어집니다. 신뢰성을 위해 최적화하세요:
저연결 상태에서 예측 가능한 앱은 사용자의 신뢰를 얻어 도입이 쉬워집니다.
오프라인 현장 앱은 실험실에서 실패하지 않고 바람부는 도로변에서 실패합니다. 테스트는 모바일 오프라인 동기화, 첨부파일, GPS 캡처와 관련된 현실을 반영해야 합니다.
“인터넷 없음” 이상의 상황을 커버하세요. 반복 가능한 테스트 체크리스트를 작성하세요:
사용자가 계속 작업할 수 있는지, 로컬 DB가 일관성을 유지하는지, UI가 로컬 저장과 동기화된 상태를 명확히 구분하는지 검증하세요.
동기화 버그는 반복 재시도 후에야 드러나는 경우가 많습니다. 다음을 검증하는 자동화 테스트(단위 + 통합)를 추가하세요:
가능하다면 시간 초과, 500 에러, 지연 응답 등을 주입하는 스테이징 서버에서 이러한 테스트를 실행하세요.
“다일간 오프라인” 및 “모든 항목 동기화 동시 진행” 시나리오를 대비하세요. 수천 건의 레코드, 많은 첨부파일, 오래된 항목에 대한 편집으로 부하 테스트를 수행하세요. 저사양 폰에서의 배터리 소모, 저장소 증가, 동기화 시간을 측정하세요.
짧은 현장 파일럿을 실행하고 피드백을 즉시 수집하세요: 어떤 폼이 혼란스러운지, 어떤 유효성 검사 규칙이 작업을 막는지, 동기화가 느리다고 느끼게 하는 요소는 무엇인지. 전사적 배포 전에 폼 흐름과 충돌 해결 규칙을 반복적으로 개선하세요.
오프라인 현장 앱을 출시하는 것은 끝이 아니라 시작입니다—실제 연결, 기기, 사용자 행동 패턴이 드러나는 순간입니다. 첫 릴리즈를 학습 단계로 취급하고 명확한 메트릭과 빠른 피드백 루프를 운영하세요.
경량 텔레메트리를 추가해 빠르게 기본 질문에 답할 수 있게 하세요:
가능하면 동기화 실패 원인(인증 만료, 페이로드 과대, 서버 검증, 네트워크 타임아웃)을 민감한 필드 데이터는 기록하지 않고 수집하세요.
오프라인 앱 장애는 예측 가능한 방식으로 발생합니다. 다음을 진단하는 내부 런북을 작성하세요:
이 런북은 비엔지니어(지원/운영)가 쓸 수 있게 만들고, 사용자가 수행할 행동(예: Wi‑Fi에서 앱 열기, 포그라운드에서 2분 유지, 진단 로그 ID 캡처)을 포함하세요.
오프라인 우선 앱은 안전한 업그레이드가 필요합니다. 로컬 DB 스키마에 버전을 부여하고 테스트된 마이그레이션(컬럼 추가, 기본값 채우기, 재인덱스)을 포함하세요. 또한 API 계약에 버전 관리를 적용해 구형 앱이 필드를 조용히 누락하지 않도록 하세요.
현장 팀을 위한 짧은 교육 가이드를 만드세요: 데이터가 저장되었는지 확인하는 방법, “업로드 대기” 표시를 식별하는 방법, 언제 재시도해야 하는지 등.
내부 채택을 장려하려면 콘텐츠 작성 보상이나 추천 프로그램 같은 인센티브를 고려하세요. 예를 들어 Koder.ai는 플랫폼 관련 콘텐츠를 제작하면 크레딧을 주고 추천 링크 프로그램을 운영합니다—이런 제도는 빌드 접근법 문서화와 도입 촉진에 도움이 될 수 있습니다.
롤아웃이나 지원 범위 설정에 도움이 필요하면 이해관계자에게 /pricing 또는 /contact를 안내하세요.
다음과 같은 운영 목표를 먼저 적어보세요:
이 수치들이 로컬 저장소 요구사항, DB 성능, 동기화 방식(증분/배치/Wi‑Fi 전용 등)을 결정합니다.
다음 항목을 캡처하세요:
이를 ‘비행기 모드에서 전체 검사 생성’이나 ‘스피너 없이 작업 완료’ 같은 테스트 가능한 요구사항으로 바꾸세요.
대부분 팀이 시작하는 최소 루프는 다음과 같습니다:
오프라인 대시보드, 전체 대상 글로벌 검색, 복잡한 승인 흐름 같은 무거운 기능은 캡처+동기화 핵심이 안정화된 뒤로 미루세요.
리스크를 줄이는 단순한 규칙을 사용하세요:
UI에 규칙을 표시하세요(예: “초안 저장됨. 제출하려면 동기화 필요”).
신뢰할 수 있는 마이그레이션, 빠른 쿼리/인덱싱, 암호화 지원을 제공하는 로컬 DB를 선택하세요.
일반 선택지:
팀의 플랫폼과 저사양 기기에서의 예측 가능한 성능 필요성에 따라 선택하세요.
오프라인에서의 작업 흐름을 모델링하세요:
created_at, , , , 첨부파일을 별도의 작업으로 처리하세요:
폼 제출을 즉시 파일 업로드에 묶어두지 말고, 레코드 동기화는 하고 첨부파일은 연결이 회복되면 업로드되게 하세요.
다음과 같은 아웃박스 패턴을 사용하세요:
각 요청이 반복되어도 중복을 만들지 않도록 설계하세요(안정적인 클라이언트 ID, 고유 요청 ID, 업서트 API 등). 배경 동기화 + 사용자가 누를 수 있는 ‘Sync now’ 버튼의 조합이 실무에 유용합니다.
레코드가 두 곳에서 동시에 변경될 수 있다는 사실을 전제로 규칙을 정하세요:
중요한 레코드(검사, 서명 등)는 자동 병합 대신 충돌 화면을 보여주어 사용자가 로컬 vs 서버 중 어떤 것을 유지할지 선택하게 하세요.
기기 내 데이터 위험과 감사 가능성에 집중하세요:
보안 수준과 사용성의 균형을 맞추고, 필요 시 /contact로 문의해 범위 협의하세요.
updated_atdevice_iduser_idversion이렇게 하면 앱 재시작 후에도 오프라인 편집/삭제/재시도 동작이 예측 가능해집니다.