들어가며

이해를 돕기 위해 가상의 현장 장면을 하나 떠올려 보겠습니다. 아래의 설비 번호와 기록 내용은 문제를 설명하려고 만든 가상의 예시입니다.

어느 제조 공장의 야간 근무 중 점검 사건 E17이 열렸습니다. 현장 작업자는 설비 A-17의 외관을 찍은 사진 한 장과 10초짜리 현장 녹음을 남기면서 “옆 설비에서 나는 소리 같다"라고 짧은 음성 메모를 덧붙였습니다. 같은 시각 설비 감시 시스템에는 해당 구간의 온도 집계 데이터가 사내 비교 범위 안으로 기록되어 있었습니다.

다음 날 아침, 주간 근무자가 인수인계를 위해 시스템을 엽니다. 만약 사내 AI가 야간 기록들을 한데 모아 “설비 A-17에서 표면 변화와 이상 소음이 감지되었으나 온도는 정상 범위임"이라는 요약문만 보여준다면 어떨까요? 주간 근무자는 결국 퇴근한 야간 작업자에게 다시 전화를 걸어 자초지종을 물어야 합니다. 사진 속 설비가 정말 A-17이 맞는지, 10초 녹음에 담긴 소리가 A-17에서 난 것인지 옆 설비에서 난 것인지, 사진을 찍은 시각과 온도 센서의 집계 구간이 실제로 같은 시점인지 요약문만으로는 확인할 길이 없기 때문입니다. 작업자가 남긴 미확인 설명이 요약 과정에서 마치 확인된 사실처럼 뒤섞여 버린 셈입니다.

지난 글에서 숙련자의 암묵지를 다루려면 글로 적히지 않는 사진·음성·센서 같은 멀티모달 기록에 주목해야 한다고 말씀드렸습니다. 하지만 AI가 사진을 보고 음성을 텍스트로 바꿀 수 있다고 해서 현장에 쌓인 파일들이 저절로 재사용 가능한 지식이 되지는 않습니다.

사건을 조사할 때 쓰는 ‘사건철’을 한 번 떠올려 보시죠. 봉투 하나에 현장 사진, 녹음파일, 계측표, 목격자 진술서가 함께 들어 있어도 각 자료가 가리키는 대상과 시각이 서로 맞는지 먼저 확인해야 합니다. 누군가 요약 보고서를 잘 정리해 두었더라도 마찬가지입니다. 각 문장이 어느 원본 사진과 어느 녹음 구간에서 나온 말인지 즉시 되짚어볼 수 있어야 기록으로서 쓸모가 생깁니다.

이번 글에서는 현장의 사진·음성·센서 기록을 실무에서 다시 꺼내 쓰려면 왜 같은 설비·제품·시간·사건으로 연결해야 하는지, 원본 관측과 AI 추론, 사람의 설명을 어떻게 나누어 설계해야 하는지 구체적으로 살펴보겠습니다.

비슷한 자료 검색과 같은 설비 연결은 다릅니다

현장에 멀티모달 AI 도입을 검토할 때 두 가지 단정을 경계할 필요가 있습니다. 하나는 범용 AI 모델이 이미 현장의 모든 센서 신호와 기록 형식을 별도 처리 없이 다 이해할 것이라는 가정이고, 다른 하나는 반대로 기록 형식만 정리하면 모든 문제가 해결된다는 생각입니다. 실제 산업 현장에서는 심한 배경 소음이 섞인 오디오나 센서별 측정 주기·단위 차이를 다루는 일 자체가 여전히 까다로운 기술 과제입니다.

물론 여러 형태의 데이터를 하나의 공간에서 다루는 AI 연구는 빠르게 발전하고 있습니다. 예를 들어 메타(Meta)가 발표한 ImageBind 연구 소개 는 이미지와 영상, 텍스트, 오디오, 깊이(Depth), 열화상, 관성측정장치(IMU) 등 여섯 가지 모달리티를 공동 표현 공간에 묶어 교차 검색하는 기능을 설명합니다. 소리로 관련 장면을 찾거나 사진으로 비슷한 오디오를 찾는 식의 ‘의미 기반 검색’ 가능성을 보여준 것이죠.

다만 **‘닮은 설비나 비슷한 소리를 찾는 기능(의미 검색)’**과 **‘두 기록이 현장의 똑같은 설비 개체에서 나왔음을 확인하는 기능(자산 연결)’**은 별개로 설계해야 합니다.

공장 안에는 외관이 똑같이 생긴 펌프와 동일한 규격의 밸브들이 나란히 돌아갑니다. 시각·음향 모델이 사진 모양이나 주파수 패턴이 비슷하다고 해서 자료를 묶어주면 1라인의 A-17 설비 사진 옆에 이웃한 다른 설비의 소음 기록이 붙을 위험이 있습니다. AI 입장에서는 두 자료의 형태가 유사하니 연결했겠지만 현장 운영 입장에서는 서로 다른 설비의 기록이 섞인 것입니다. 멀티모달 모델이 데이터를 읽게 하는 작업과 별도로 각 기록에 고유한 설비 ID와 현장 별칭, 제품 개체, 사건 번호를 연결하는 구조를 마련해야 합니다.

같은 설비·시간·사건으로 묶는 세 가지 연결 고리

데이터 연결이 현장 지식화의 유일한 장애물은 아니지만 이 연결 고리가 빠져 있으면 이후의 검색이나 요약 결과도 맥락을 잃습니다. 흩어진 사진과 음성, 센서 구간을 하나의 사건철로 묶으려면 기록이 남는 순간부터 세 가지 기준을 맞춰야 합니다.

첫째, 설비의 공식 식별자와 현장에서 부르는 별칭을 이어주는 고리입니다. 현장 작업자가 음성 메모를 남길 때 전산 시스템의 긴 자산 번호를 그대로 읽기보다 “3호기 끝단"이나 “A-17 옆 라인"처럼 위치나 현장 별칭으로 말할 때가 있습니다. 사진 역시 설비 명판이 나오지 않게 문제 부위만 가까이 찍기 쉽습니다. 작업자에게 복잡한 코드를 외우게 하는 대신 점검 동선이나 위치 맥락, 작업 대상 선택 화면 등을 활용할 수 있습니다. 이런 방법으로 기록을 남기는 순간 해당 설비의 고유 ID와 사건 번호가 봉투 표지처럼 함께 붙도록 설계해야 닮은 설비와의 혼동을 줄일 수 있습니다.

둘째, 실제로 현상을 관찰한 시각과 시스템에 올라간 시각을 나누는 고리입니다. 작업자가 새벽 2시 10분에 설비 상태를 촬영·녹음한 뒤 교대 시간인 오전 8시 30분에 파일들을 일괄 업로드하는 상황을 가정해 보겠습니다. 만약 시스템이 업로드 시각인 오전 8시 30분을 기준으로 데이터를 묶는다면 새벽 2시 10분의 사진 옆에 오전 8시 30분의 센서 그래프가 붙게 됩니다. 관측 데이터 국제 표준인 OGC SensorThings API 표준 문서 는 현상이 실제로 일어난 관측 시각(phenomenonTime)과 결과가 생성된 시각(resultTime)을 명확히 구분합니다. 관측 시각이 생략될 때 서버 현재 시각을 채우는 규칙도 설명합니다. 현장 기록에서도 촬영·관측 시각과 업로드 시각을 나누어 저장하고 기기 간 시계 보정 오차나 누락 여부를 드러내야 센서 시계열 구간과 시간을 맞출 수 있습니다.

셋째, 음성 전사문 옆에 원음 구간과 환경 맥락을 남기는 고리입니다. 만약 음성인식(STT) 모델을 거친 텍스트 전사문만 남기고 원음 연결을 놓치면 두 가지 문제가 생깁니다. 우선 오픈AI의 Whisper 공식 모델 카드 에 명시되어 있듯 음성인식 출력에는 실제 오디오 입력에서 발화되지 않은 텍스트가 포함될 수 있으며(환각) 언어·억양·배경 소음에 따른 성능 한계도 있습니다. 또한 작업자가 말한 “여기”, “이 소리"가 구체적으로 무엇을 가리키는지는 전사된 글자만 보고 알 수 없습니다. 기계의 소리 역시 운전 조건이나 주변 소음, 녹음 환경이 바뀌면 다르게 들립니다. 그래서 전사문 바로 옆에서 원음 구간을 다시 들어보고 함께 찍은 사진을 대조할 수 있어야 잘못된 전사나 불분명한 지시어가 사실처럼 굳어지는 일을 막을 수 있습니다.

관측, AI 추론, 사람의 설명을 섞지 않는 기록 설계

기록들을 같은 사건 번호로 묶은 뒤에는 그 안의 내용을 어떻게 구분해 담을지가 중요해집니다. 원본 데이터와 AI가 추정한 결과, 그리고 작업자의 구두 설명을 구분하지 않고 하나의 요약문으로 합쳐버리면 다음 근무자는 어디까지가 기기가 측정한 사실이고 어디부터가 추정인지 가려낼 수 없습니다.

W3C PROV 데이터 모델(PROV-DM) 은 데이터의 출처 관계를 다루는 웹 표준입니다. 데이터 개체(Entity)와 생성·변환 활동(Activity), 책임 주체(Agent), 그리고 파생 관계를 표현하는 개념 틀을 제시합니다. 물론 이 표준 자체가 특정 현장 분류를 의무화하지는 않습니다. 출처가 있다고 해서 내용의 진위를 보증해 주지도 않습니다. 다만 이 글에서는 이 출처 구분의 원리를 참고해 현장 사건철을 원본 관측, AI 추론, 사람의 설명이라는 세 칸으로 나누고 확인 여부를 함께 표시하는 설계를 제안합니다.

앞선 가상의 점검 사건 E17에 이 설계를 적용하면 기록은 성격이 다른 세 가지 정보로 나뉩니다.

• 원본 관측: 카메라가 찍은 설비 A-17의 사진 한 장, 10초짜리 현장 녹음 원음, 그리고 해당 시간대의 온도 센서 집계 범위입니다.
• AI 추론: 사진을 보고 모델이 붙인 ‘표면 변화 후보’라는 캡션이나 음성인식 모델이 생성한 전사문 같은 모델의 추정 결과입니다. 어느 원본 파일에서 파생되었는지 출처가 함께 표시됩니다.
• 사람의 설명: 작업자가 남긴 “옆 설비에서 나는 소리 같다"라는 현장 발언입니다. 사람의 설명 역시 그 자체로 귀중한 맥락이지만 현장 검증을 거치기 전까지는 확인 대상입니다.

이 구조에서 바람직한 검색 응답은 “설비 A-17의 문제 원인이 밝혀졌다"라고 단정하는 문장이 아닙니다. 사진의 해당 영역과 10초 원음 구간, 사내 비교 범위 안에 있는 온도 집계 구간을 나란히 제시하고 소리 발생원이 A-17인지 옆 설비인지는 아직 ‘미확인’ 상태라고 표시하는 것입니다.

외관, 온도, 음향에서 관측하는 물리적 속성은 서로 다릅니다. 온도 집계가 비교 범위 안에 있는데 작업자가 이상 소음을 언급했다고 해서 이를 자동으로 모순이라거나 특정 초기 결함의 증거라고 단정할 필요는 없습니다. 요약문이 차이를 임의로 지우지 않고 각 관측값과 미확인 항목을 그대로 남겨두면 다음 근무자가 대상 설비와 시간, 운전 조건이 맞는지 먼저 확인한 뒤 소리 발생원 연결만 정정하는 식으로 기록을 이어갈 수 있습니다.

공개 사례와 연구 데이터셋이 보여주는 조각들

그렇다면 실제 기업 현장과 연구계에서는 이런 멀티모달 기록을 어떻게 다루고 있을까요? 아래에 인용한 사례들은 저마다 의미 있는 진전을 보여주지만 이 글에서 제안하는 모든 연결 구조를 한꺼번에 실증한 사례는 아닙니다. 또한 공급사가 발표한 고객 도입 보고와 학술 연구 데이터셋은 그 성격을 구분해 살펴보아야 합니다.

첫 번째는 이미지와 음향 데이터의 저장 및 메타데이터 검색 기반을 보여주는 공급사 보고 사례입니다. AWS가 게시한 BMW 그룹의 VSAS(Vision and Sound Analytics Service) 사례 에 따르면 이 서비스는 기존 이미지 저장 기반을 음향 데이터로 확대해 메타데이터 검색과 음향 라벨링을 지원합니다. 제조 부품을 찾거나 새로운 모델을 학습시키는 데도 활용한다고 합니다. 이 사례에서처럼 현장의 사진과 소리를 재사용하려면 먼저 저장과 라벨링, 메타데이터 검색이 가능해야 합니다. 다만 공개된 본문은 시각·음향 데이터의 관리와 활용 기반을 다루며 작업자 발화나 공정 센서까지 단일 사건으로 검증해 묶은 시스템을 설명하지는 않습니다.

두 번째 공급사 보고에서는 숙련자의 대화를 녹음해 문서화하고 설비 데이터와 함께 활용하려는 시도를 볼 수 있습니다. AWS의 Georgia-Pacific 고객 사례 발표 와 2026년 1월 AWS 산업 블로그 에 따르면, 이 회사는 디지털 문서와 정비 기록, IoT 센서 데이터를 묶은 사내 챗봇(ChatGP)으로 운전원에게 설비 상태와 추세를 설명해 줍니다. 특히 문서가 부족한 약 50년 된 설비의 노하우를 다루기 위해 여러 전문가나 퇴직자의 대화를 녹음한 뒤 대규모 언어 모델(LLM)로 구조화된 기술 문서를 만들었습니다. 구두 설명을 설비 데이터와 같은 질의 맥락에 두려는 시도입니다. 다만 녹음된 발언과 센서 데이터를 어떤 자산 ID·시간 기준으로 연결했는지, 문서의 검토·승인 절차가 어떠했는지는 공개 자료에 구체적으로 나와 있지 않습니다.

세 번째는 학술 연구인 Ego-Exo4D 연구 데이터셋 입니다. 이 연구에서는 관측 영상과 전문가 해설을 같은 시간축에 나누어 수집했습니다. 동기화된 1인칭·외부 시점 영상과 오디오, IMU 센서 입력을 수집하면서 참가자의 시연 설명과 코치·교사의 ‘전문가 해설’은 별도의 주석으로 구분해 담았습니다. 이 데이터셋은 산업 현장 배포가 아니라 카메라 구성과 시간 동기화, 주석 수집에 별도로 투자한 연구 벤치마크입니다. 그럼에도 관측된 행동 영상과 숙련자의 설명을 하나로 섞지 않고 같은 시간축 위에 나란히 정렬한다는 점은 현장 기록 설계에 좋은 참고가 됩니다.

현장 지식을 살리는 작은 파일럿, 어떻게 시작할까

공개된 사례들 사이에는 빈칸이 남아 있습니다. 현장의 사진·음성·센서·설명을 같은 사건으로 연결하고 확인 여부를 관리하는 구조는 결국 우리 현장의 업무 흐름에 맞게 직접 설계해야 합니다. 처음부터 모든 설비를 통합하려 하면 논의만 길어지기 쉬우므로 범위를 좁힌 작은 파일럿으로 검증하는 방법을 제안합니다.

파일럿이 답해야 할 실무 질문은 이렇습니다.
“담당자가 자리를 비워도, 다음 사람이 한 사건의 사진·원음·센서 구간·설명을 찾아 당시 맥락과 미확인 사항을 확인할 수 있는가?”

첫째, 하나의 설비군과 이미 종료된 점검·인계 사건으로 범위를 좁힙니다. 설비 자율 제어나 고장 조치 방법을 지시하는 용도가 아니라 교대 근무나 일상 점검에서 특이사항을 넘기는 사건 하나를 골라 그 사건 번호 아래 기록들을 묶어보는 것부터 시작합니다.

둘째, 작업자에게 사진 촬영만 더 시키기보다 최소 연결 정보를 먼저 맞춥니다. 현장의 입력 부담이 커지면 기록 자체가 이어지기 어렵습니다. 사진 한 장과 짧은 음성 메모를 남길 때 설비 ID(또는 현장 별칭), 실제 관측 시각(phenomenonTime)과 업로드 시각, 사건 번호가 함께 기록되도록 만들고 전사문 옆에는 원음 구간을 남깁니다.

셋째, 화면에서 관측·AI 추론·사람의 설명을 다른 칸에 두고 확인 여부를 표시합니다. AI가 뽑은 키워드나 요약은 추론 후보로 표시하고 사람의 구두 설명도 현장 확인 전에는 ‘미확인’으로 구분해 둡니다. 각 문장이 어느 원본 파일에서 나왔는지도 바로 열어볼 수 있게 합니다.

넷째, 불명확한 비용 절감 추정치 대신 연결과 인계 과정의 실제 지표를 측정합니다. 기존 텍스트 검색 방식과 비교해 올바른 사건 검색률, 유사 설비 오연결률, 원본 자료 연결률, 검토 소요 시간, 작업자의 추가 입력 부담, 그리고 누락된 맥락을 보충하려면 추가 질문이 몇 번 필요한지를 담당자와 사전 합의해 점검해 보시기 바랍니다.

나가며

현장의 사진과 음성, 센서 기록을 다시 쓸 수 있는 지식으로 연결하는 일은 멀티모달 모델을 도입하는 것만으로 완성되지 않습니다. 원본 관측과 AI의 추론, 사람의 설명을 구분하고 이를 같은 설비·제품·시간·사건이라는 하나의 사건철로 묶어야 다음 근무자가 맥락을 되짚어볼 수 있는 기반이 생깁니다.

우리 현장의 설비 환경과 교대 업무 흐름에 맞춰 어떤 연결 기준부터 세워야 할지 고민되신다면 작은 설계와 파일럿에서 출발해 보시기 바랍니다. **엡실론델타(EpsilonDelta)**는 현장의 사진·음성·센서 기록을 실무 맥락과 하나의 사건 축으로 연결하는 구조 설계부터 단일 설비군을 대상으로 빠르게 실효성을 점검하는 파일럿 추진까지 함께 돕고 있습니다. 현장 기록을 실무에 연결하는 구체적인 설계와 파일럿 상담이 필요하시다면 언제든 contact@epsilondelta.ai 로 편하게 문의해 주시기 바랍니다.