- 현장 직원은 이미 휴대폰을 들고 다니지만, 대부분의 시스템은 나중에 사무실 책상에 돌아와 데이터를 입력하게 만듭니다.
- 좋은 어시스턴트는 한 손으로 쓸 수 있어야 합니다. 사진을 찍으면 알아보고, 말하면 대신 기록해 주고, 신호가 없을 때도 돌아가야 합니다.
- 측정할 수 있는 효과는 일이 현장에서 끝나 나중에 서류를 다시 만들 필요가 없고, 데이터도 전보다 정확해진다는 점입니다.
기존 웹사이트와 앱은 어디에서 멈춰 있을까
현장의 기사는 한 손만 쓸 수 있고, 장갑을 끼고 있고, 땡볕 아래 서 있고, 신호는 끊겼다 이어졌다 합니다. 그런데 회사가 쓰라고 준 시스템은 책상에 앉은 사람을 위해 만든 열 칸짜리 양식입니다. 그래서 결국 종이에 적어 두었다가 저녁에 돌아와 다시 입력합니다.
기존 현장 앱은 융통성 없는 체크리스트입니다. 직원이 어느 메뉴를 열어야 하는지 알아야 하고, 불편한 환경에서 긴 내용을 입력해야 하니 데이터가 늦게 들어오거나 빠집니다.
현장용 소프트웨어는 사무실 양식을 휴대폰 크기로 줄이는 데서 출발하는 경우가 많습니다. 사용자는 땡볕 아래 서 있거나, 장갑을 끼고 있거나, 시끄러운 곳이나 신호가 없는 곳에 있는데도 그렇습니다. 그래서 종이에 적고, 사진을 찍어 두었다가, 저녁에 돌아와 입력합니다. 데이터는 늦게 들어오고, 기억에서 빠지는 내용이 생기며, 시스템은 도움보다 짐으로 여겨집니다.
AI 모바일 현장 어시스턴트(AI Mobile Field Assistant)는 실제 작업 환경에서 출발해 설계해야 합니다. 맞는 매뉴얼을 열어 주고, 표지판이나 문서를 읽고, 음성 명령을 받고, 다음 단계를 제안하고, 작업 중에 증거를 기록할 수 있습니다. 다만 기사의 시선을 안전에서 빼앗거나, 조직의 전문가가 아직 확인하지 않은 조언을 믿게 만들어서는 안 됩니다.
| 기존 방식 | 새로운 AI 제품 방식 |
|---|---|
| 매뉴얼 표시, 양식 접수, 사진은 나중에 업로드 | 사진과 음성을 이해하고, 현재 작업에서 맥락을 가져오고, 대화하듯 점검 단계를 안내하며, 직원이 확인하는 정형 기록을 생성 |
현장 앱의 시스템 연동은 온라인일 때와 오프라인일 때를 모두 감당해야 합니다. 앱은 작업 패키지(Work Pack)와 증거를 기기에 안전하게 저장하고, 일부 AI 작업은 사용자 가까이에서 처리하며, 연결이 되면 API로 동기화(Sync)하되 충돌이 생기면 사람이 결정하도록 보여 줍니다.
기업이 쓸 수 있는 새로운 기능
그래서 실제로 쓸 수 있는 현장 어시스턴트는 작업의 실제 조건에서 출발합니다. 사진을 찍으면 시스템이 무엇인지 알아보고, 짧게 말하면 맞는 칸에 기록해 주고, 신호가 없어도 계속 돌아가다가, 신호가 잡히는 곳으로 돌아오면 그때 시스템에 올립니다.
프로젝트의 모습
앱은 매뉴얼과 스마트 작업 일지를 한 기기에 담은 것입니다. 사용자가 설비(Asset)를 고르거나 코드를 스캔하면, 시스템이 이력, 체크리스트, 관련 문서를 미리 불러옵니다. 작업 중에는 큰 버튼, 음성, 사진, 짧은 단계로 일을 진행하고, 네트워크가 없어도 누가 언제 무엇을 했는지 기록이 남습니다.
구체적인 기능
기능으로는 오프라인 작업 패키지, 음성 메모, OCR, 사진 주석, 안내형 점검, 부품 조회, 원격 전문가 연결, 안전 확인, 자동 보고서, 동기화 상태 표시가 있을 수 있습니다. AI가 확신하지 못하면 사진을 더 요청하거나 전문가를 불러야 하고, 데이터가 뒷받침하는 것보다 자신 있게 답해서는 안 됩니다.
현장에 맞는 기술
음성 인식, OCR, 캐시된 데이터 검색 같은 일부 작업은 기기 안에서(On-device) 처리해 빨리 응답하고 개인정보를 지킵니다. 최신 데이터가 필요한 작업은 네트워크가 있을 때 클라우드로 보냅니다. 앱에는 충돌 해결(Conflict Resolution), 암호화 저장소, 백그라운드 동기화, 기기 권한 관리가 있어야 하고, 회사 기기를 관리하기 위해 MDM과 연결할 수도 있습니다.
현장 직원에게 주는 효과
기사는 보고서에 쓰는 시간이 줄고, 매번 전화로 묻지 않아도 필요한 지식을 찾을 수 있으며, 처음부터 빠짐없는 증거를 전문가에게 보냅니다. 팀장은 밀린 작업과 이상 징후를 더 빨리 봅니다. 조직은 뛰어난 직원의 설명과 사진에 담긴 암묵지(Tacit Knowledge)를 모아 매뉴얼을 개선하되, AI가 현장 기술을 대신할 수 있다고 주장하지는 않습니다.
- 표지판, 바코드, 문서, 현장 상태를 읽는 카메라 어시스턴트(Camera Assistant)
- 손을 쓸 수 없을 때를 위한 음성 우선(Voice-first) 조작과 실시간 후속 질문
- 모든 데이터를 서버로 보내지 않고 일부 작업을 처리하는 온디바이스 AI(On-device AI)
- 작업을 저장해 두었다가 신호가 돌아오면 동기화하는 오프라인 우선(Offline-first)
가상 사례
실제로 쓰이는 모습
건물 점검 담당자가 설비를 사진으로 찍습니다. 앱은 코드를 읽고, 이력을 불러오고, 상태를 음성으로 묻고, 점검 기록(Inspection Record) 초안을 씁니다. 위험한 지점은 엔지니어에게 넘기고, AI가 안전을 인증하게 두지 않습니다.
이 가상 사례에서 한 기사가 신호가 약한 건물로 에어컨을 점검하러 갑니다. 설비를 스캔하면 앱이 미리 내려받아 둔 이력과 체크리스트를 엽니다. 기사는 측정값을 음성으로 기록하고 이상해 보이는 곳을 사진으로 찍습니다. 측정값 하나가 고객사 엔지니어링팀이 정한 범위를 벗어나자 시스템이 경고하고, 전문가 검토를 요청하는 단계를 추가합니다.
다시 온라인이 되면 앱은 증거를 동기화하고, 작업 지시서(Work Order)를 업데이트하고, 보고서 초안을 만듭니다. 기사는 보내기 전에 확인하고 고칩니다. 일부 데이터가 사무실에서 고친 내용과 충돌하면, 시스템은 조용히 덮어쓰지 않고 차이를 보여 주어 기사가 고르게 합니다. 이렇게 하면 현장 직원의 결정 권한은 그대로 두면서 반복 작업을 줄일 수 있습니다.
세 가지 맥락 확인(Three-context Check)
추천하기 전에 시스템이 사람(Person), 장소(Place), 작업(Task)을 확인하게 하십시오. 누가 어디에서 어떤 일을 하고 있는지입니다.
이 중 하나만 틀려도 올바른 매뉴얼이 틀린 조언이 될 수 있습니다.
범위, 위험, 성과 측정 방법
개발팀 참고 · 기술 지표
실제로 쓰는 기기, 조명, 소음, 장갑, 언어, 네트워크 환경에서 테스트하고, 어떤 데이터를 기기에 얼마 동안 저장해도 되는지 정해야 합니다. 지표로는 First-time Completion, Report Delay, Missing Evidence, Expert Call, Safety Stop을 보십시오. 속도에 안전이나 증거 품질보다 높은 점수를 주어서는 안 됩니다.
동의, 데이터 보관 기간, 배터리 사용량과 지연 시간, 기기 모델별 지원 여부, 모델을 쓸 수 없을 때의 수동 모드(Manual Mode)를 설계해야 합니다.
개발팀 참고 · 기술 지표
추적할 지표: Time-to-Record, Data Completeness, Offline Success, Expert Escalation, Unsafe Advice
- Discover: 실제 업무를 따라가며 일반 사례와 예외 사례를 모읍니다.
- Assist: AI가 초안을 쓰거나 추천하고, 통제는 사람이 계속 맡습니다.
- Act: 테스트 세트를 통과한 뒤 도구(Tool)를 하나씩 엽니다.
- Scale: 모니터링, 대체 경로(Fallback), 비용, 책임자가 갖춰지면 확대합니다.
앱이 사용자의 시선을 작업에서 빼앗거나, 동기화 중에 증거가 사라지거나, 위험 지점에서 조언이 모호하면 시범 운영을 멈추십시오. 빠른 보고서보다 안전과 빠짐없는 기록이 먼저입니다.
BUSINESS & PRODUCT READINESS
현장 AI는 웹사이트를 휴대폰에 줄여 넣는 대신 실제 환경에 맞춰 설계해야 합니다
기능보다 환경부터 조사하십시오. 사용자의 손이 비어 있습니까? 조명과 소음은 어떻습니까? 장갑이나 개인 보호 장비(PPE)를 착용합니까? 신호는 얼마나 오래 끊깁니까? 작업에 몇 초 안에 답이 필요합니까? 음성, 카메라, 큰 버튼, 기기 내 처리, 오프라인 대기열 중 무엇을 쓸지는 화면이 얼마나 보기 좋은지보다 이런 질문이 결정합니다.
개발팀 참고 · 기술 세부 사항
Device Matrix, Permission, Data Retention, Sync Conflict 처리, Manual Checklist를 준비하십시오. AI는 기록을 만들거나 절차를 찾는 일을 도와야 하지만, 안전에 영향을 주는 조언은 규칙과 전문가에게 맡겨야 합니다. Battery/Latency Budget을 정하고, 가장 까다로운 근무 조와 장소에서 테스트하십시오.
기기·환경 매트릭스(Device and Environment Matrix)를 만들어 상황을 나누십시오. 손이 비어 있는지, 빛이 충분한지, 얼마나 오래 오프라인으로 버텨야 하는지, 어떤 방식의 본인 확인이 필요한지 같은 것입니다. 그다음 상황마다 맞는 상호작용 방식을 고릅니다. 어떤 지점은 음성으로, 어떤 지점은 버튼 하나로 처리해야 하고, 어떤 지점에서는 화면을 아예 쓰지 않게 해야 합니다.
매뉴얼과 임계값(Threshold)은 고객사의 엔지니어링팀, 안전팀, 전문가 중 누군가가 책임져야 합니다. 시스템은 버전과 업데이트 날짜를 보여 주고, 수동 모드를 언제나 열어 두어야 합니다. 시범 운영은 매뉴얼이 분명하고 위험을 통제할 수 있는 작업으로, 실제 현장에서 피드백을 줄 준비가 된 소수의 사용자와 함께 시작하십시오.
손을 쓸 수 없는 작업은 무엇입니까?
절대 기기 밖으로 나가면 안 되는 데이터는 무엇입니까?
오프라인으로 얼마나 오래 버틸 수 있습니까?
전문가의 확인이 필요한 조언은 무엇입니까?
실제 기기의 맥락과 한계를 존중하는 현장 어시스턴트를 만듭니다
DNA Maker는 현장에 직접 나가거나 직원, 전문가와 맥락 인터뷰(Context Interview)를 진행해 그들의 동작, 도구, 신호 환경, 금지 사항을 이해한 뒤, 사람(Person), 장소(Place), 작업(Task)의 세 가지 맥락 지도(Three-context Map)를 만듭니다. 업무별 전문 지식은 계속 고객사가 확인하고, 저희는 그 지식을 휴대폰에 맞는 상호작용과 데이터 흐름으로 정리합니다.
저희는 클릭해 볼 수 있는 프로토타입과 카메라, 음성 프로토타입을 만들어 백엔드가 완성되기를 기다리지 않고 처음부터 실제 기기에서 테스트합니다. 그래서 버튼, 음성, 조명, 네트워크, 확인 단계의 문제가 아키텍처를 확정하기 전에 드러납니다.
DNA Maker는 기능을 고르기 전에 장소와 기기별 사용자 여정(User Journey)을 자세히 그립니다. 밝기, 소음, 버튼 크기, 한 손 사용, 오프라인 흐름을 기준으로 테스트하는 프로토타입을 만든 뒤, 속도, 개인정보 보호, 데이터의 최신성 사이에서 균형을 맞춘 온디바이스/클라우드 아키텍처를 설계합니다.
솔루션에는 네이티브 모바일 앱, 오프라인 동기화, OCR/음성, AI 현장 어시스턴트, 작업 지시서 연동, 전문가 콘솔이 들어갈 수 있고, 사용자를 방해하지 않는 텔레메트리도 함께 넣습니다. 기사가 매번 매뉴얼을 열고, 사진을 찍고, 보고서를 써야 하는 작업이 하나 있다면, 그 업무 흐름을 시범 운영으로 삼아 다른 기능을 더하기 전에 실제 현장에서 쓸 수 있는지 입증할 수 있습니다.
DNA Maker는 네이티브/크로스플랫폼 모바일 앱, 온디바이스/클라우드 AI, 오프라인 저장/동기화, 바코드/OCR, 음성, 백엔드와 시스템 연동을 개발할 수 있으며, 크래시, 지연 시간, 모델 모니터링도 함께 제공합니다.
직원이 작업 하나를 하면서 휴대폰을 들고 매뉴얼, 카메라, 종이를 번갈아 오가야 한다면, 그 작업을 가져와 이야기해 보십시오. 누구의 일도 늘리지 않으면서 시간과 데이터 완전성을 잴 수 있는 현장 시범 운영(Field Pilot)을 함께 설계하겠습니다.
SOFTWARE ENGINEERING GLOSSARY
소프트웨어 엔지니어링 용어집
현장용 소프트웨어가 무엇이 다른지 설명하는 용어입니다. 기기 내 처리와 오프라인 작업부터 여러 형식의 미디어, 응답 시간까지 다룹니다. 실제 현장 조건이 회의실과 전혀 다를 때 시스템이 어떻게 계속 돌아가고 데이터를 복구하는지 물을 때 쓰십시오.
| 용어 | 의미 | 쉬운 예시 | 개발팀에 물어봐야 할 질문 |
|---|---|---|---|
| On-device AI | 기기 자체에서 AI를 돌리는 방식. 속도, 개인정보 보호, 오프라인 작동이 필요한 일에 맞지만, 모델 크기, 배터리, 기기 모델별 성능을 고려해야 합니다. | 음성을 클라우드로 보내지 않고 메모 요약 | 어떤 기기 모델이 지원합니까? |
| Offline-first | 인터넷 연결 없이도 작동하도록 앱을 설계하는 방식. 처음부터 오프라인에서 데이터를 만들고 고칠 수 있게 하고, 동기화 상태를 보여 주며, 양쪽 데이터가 충돌할 때의 처리 방법을 갖춰야 합니다. | 점검 내용을 기록해 두고 나중에 동기화 | 동기화할 때 데이터가 충돌하면 어떻게 해결합니까? |
| Multimodal Prompt | 여러 형식의 미디어를 모델에 함께 보내 판단하게 하는 지시. 사진, 음성, 글이 각각 어떤 역할인지, 증거가 불분명하면 무엇을 해야 하는지 밝혀서 모델이 짐작하게 두지 않아야 합니다. | 설비 사진과 음성 질문을 함께 전달 | 어떤 미디어가 꼭 필요하고, 그에 대한 동의를 받았습니까? |
| App Intent | 시스템이 자연어로 호출할 수 있는 앱의 기능. 앱이나 외부 시스템이 미리 정한 작업을 실행하는 통로이므로, 입력, 권한, 기대 결과를 분명히 정해야 합니다. | 다음 점검 작업을 열어 달라고 요청 | 어떤 작업을 호출할 수 있게 열어 두어야 합니까? |
| Latency | 명령을 내린 뒤 응답이 올 때까지 기다리는 시간. 모델의 응답 시간만으로는 부족하고 전체 흐름에서 재야 합니다. 데이터 조회, API 호출, 동기화가 모두 사용자가 기다리는 시간을 늘리기 때문입니다. | 음성 안내는 현장 작업에 충분할 만큼 빨리 응답해야 함 | 몇 초 이상 늦으면 쓸 수 없습니까? |
더 읽을거리(원문 자료): https://developer.apple.com/documentation/foundationmodels/