IoT 데이터를 설계하며 함께 생각하게 되는 것들

저는 IoT에서 데이터와 서비스를 설계한다는 것은, 워크플로우와 거버넌스를 확인하고 통합하는 일이라고 생각합니다.

어떤 데이터를 수집할지 생각하다 보면, 그 데이터가 누구의 판단에 쓰이고 어떤 업무로 이어지는지 궁금해집니다. 누가 볼 수 있는지, 무엇을 기준으로 판단하는지, 조치와 결과 확인은 누가 맡는지도 함께 묻게 됩니다.

저는 데이터 거버넌스 전문가는 아닙니다. 이 글은 IoT 데이터와 서비스를 설계하면서 함께 고민하게 되는 업무와 사람의 역할에 대한 생각입니다.

온도, 동작 상태, 사용 횟수 같은 수집 항목을 정의할 때도 저는 그 값이 쓰이는 장면을 먼저 떠올립니다. 현장 운영자가 상태를 확인하는 데 필요한지, 서비스 담당자가 원인을 조사하는 데 필요한지, 제품 담당자가 개선 여부를 판단하는 데 필요한지에 따라 함께 연결해야 할 정보가 달라지기 때문입니다.

고객·제품·현장의 맥락 속에서 데이터가 판단과 실행으로 이어지고, 그 결과를 다시 확인할 수 있도록 연결하는 것. 제가 생각하는 IoT 데이터·서비스 설계의 핵심입니다.

데이터가 쓰일 업무부터 살펴보기

예를 들어 어떤 장비에서 온도 이상이 감지되었다고 가정해 보겠습니다.

현장 운영자는 지금 사용을 계속해도 되는지 알고 싶습니다. 서비스 담당자는 설정이나 사용 환경의 영향인지, 부품 점검이 필요한지 확인해야 합니다. 제품 담당자는 같은 구성의 제품에서도 비슷한 문제가 발생하는지 살펴볼 수 있습니다.

같은 측정값을 보더라도 궁금한 점은 다를 것 같습니다. 제품 모델과 설정, 증상 전후의 동작 이력, 설치 환경, 최근 정비 내역을 함께 보면 각자의 질문에 답하는 데 도움이 될 수 있습니다.

그래서 수집 항목을 정할 때는 다음 질문을 함께 적어 봅니다.

• 이 데이터로 누가 무엇을 판단하는가?
• 판단에 필요한 제품·고객·현장 정보는 어디에 있는가?
• 어떤 조건에서 다음 업무를 시작하고, 누가 맡는가?
• 조치가 끝났다는 것은 무엇으로 확인하는가?

저는 이런 질문에서 수집할 정보의 범위를 좁혀 보려고 합니다. 고장 전후의 변화를 살펴보려면 이전 측정값도 필요할 테고, 정비 시점을 고민한다면 누적 사용량과 마지막 부품 교체 시점을 함께 보고 싶을 것입니다.

익숙한 ERP 업무 용어로 생각해 보기

이 관계를 설명할 때는 ERP에서 일반적으로 사용하는 업무 구분을 기준으로 생각해 볼 수 있습니다. 수주, 생산계획, 구매·재고, 생산·품질, 출하, 사후서비스입니다. 여기서는 업무를 설명하기 위한 공통 용어로 사용합니다.

이 표는 각 업무와 IoT 데이터를 연결해 생각하기 위한 예시입니다. 실제 업무 순서와 담당 범위는 조직에 따라 달라집니다.

업무 영역을 표로 나누어 보면 큰 범위를 잡는 데 도움이 됩니다. 다만 제가 데이터의 쓰임을 생각할 때 궁금한 부분은 그 사이의 연결입니다. 준비가 되지 않은 작업은 어디에서 기다리는지, 검사에 통과하지 못하면 어디로 돌아가는지, 현장의 문제를 조사할 때 어떤 이력을 다시 보게 되는지 같은 것들입니다.

아래에는 이런 관계를 담은 전체 도표를 실었습니다. 업무 단계와 분기, 재처리 경로, 정보 연결을 함께 따라가며 보려고 합니다.

전체 도표 크게 보기 · 원본 Graphviz DOT 파일

실선은 업무 흐름, 파란 점선은 정보 연결, 주황 점선은 재확인·재처리, 분홍 점선은 개선 검토를 나타냅니다. 업무 관계를 설명하는 개념도이며, 실제 구현 상태나 모든 단계의 자동화를 의미하지 않습니다.

저는 한 번에 모든 선을 읽기보다, 다음 순서로 질문을 나누어 보고 싶습니다.

1. 고객 요청과 제품·생산 기준: 고객이 요청한 내용은 제품 구성과 생산계획에 어떻게 이어질까?
2. 자재 확보와 작업 실행: 확보된 자재로 할 수 있는 일과 기다려야 하는 일은 어떻게 나뉠까? 구매나 자체조립으로 준비가 끝나면 어떤 작업을 다시 확인할까?
3. 검사와 출고: 검사에 통과하지 못했거나 고객·설치처·제품의 연결이 맞지 않을 때, 어디에서 확인하고 다시 진행할까?
4. IoT 운영과 사후지원: 현장의 이상이나 고객 문의를 조사할 때 제품·생산·운영 이력을 어떻게 함께 볼까? 정비나 교체 이후에는 어떤 기록을 갱신할까?
5. 조치 이후의 확인과 개선: 조치 결과는 어디에 남고, 제품이나 생산계획을 다시 검토할 때 어떻게 참고할까?

이렇게 따라가 보면 데이터를 수집하는 지점뿐 아니라, 그 데이터를 기다리는 업무와 사람이 함께 보일 것 같습니다.

저는 이런 업무 구분 위에서 데이터의 쓰임을 찾으려고 합니다. 사용 이력은 정비 필요성을 검토하는 근거가 될 수 있고, 반복되는 이상 징후는 품질 검토의 출발점이 될 수 있습니다. 그러면 자연스럽게 다음 질문이 생깁니다. 어떤 정보를 전달하면 좋을까, 그 정보를 받은 사람은 무엇을 판단하게 될까 하는 질문입니다.

숫자와 함께 알고 싶은 맥락

고객이 기대하는 결과, 제품이 제공하는 기능, 실제 사용하는 현장의 조건은 데이터를 해석하는 데 필요한 배경입니다.

같은 상태값이라도 사용 환경과 목적에 따라 해석이 달라질 수 있습니다. 그래서 저는 고객이 어떤 불편을 겪는지, 제품에는 어떤 특성이 있는지, 현장 상황은 어떤지도 함께 알고 싶습니다.

저는 서비스 설계에서 이 맥락을 누가 알고 있는지부터 확인하려고 합니다. 고객과 대화하는 사람, 제품을 이해하는 사람, 현장을 지원하는 사람이 가진 정보를 어떤 업무에서 함께 볼 수 있어야 하는지 살펴보는 것입니다.

그러다 보면 누구에게 어디까지 보여 주면 좋을지도 고민하게 됩니다. 업무에 필요한 정보가 무엇인지, 그 정보는 누가 관리하는지 담당자와 함께 확인하고 싶습니다.

시간이 지나면서 상황이 달라진다는 점도 마음에 걸립니다. 지금의 정보로 예전 일을 잘못 이해하지 않을까, 당시 상황을 알기 위해 어떤 기록을 남기면 좋을까 하는 고민입니다.

다음 일은 누가 맡게 될까

업무 흐름을 따라가다 보면 데이터를 확인한 다음이 궁금해집니다. 추가 확인이 필요할 때 누구에게 물어봐야 할지, 조치는 누가 맡을지 같은 것들입니다.

제가 거버넌스라는 말과 연결해서 생각하는 부분도 여기에 있습니다. 누가 정보를 보고, 누가 판단하고, 누가 다음 일을 맡는지에 대한 약속입니다. 저는 우선 이런 질문부터 담당자들과 나눠 보고 싶습니다.

• 이 정보는 누가 볼 필요가 있을까?
• 조치가 필요한지는 누가, 무엇을 보고 판단할까?
• 판단이 끝나면 다음 일은 누가 맡을까?
• 잘 해결되었는지는 누가 확인할까?

정보를 보는 일과 설정을 바꾸는 일은 맡는 사람이 다를 수 있습니다. 혼자 정하기 어려운 부분이라, 실제 업무를 맡는 사람의 이야기를 듣고 설계에 담으려고 합니다.

이상 징후에서 조치 결과 확인까지

앞서 이야기한 가상의 온도 이상 상황을 조금 더 생각해 보겠습니다.

알림을 받은 사람이 측정값과 사용 환경을 확인했다고 해 보겠습니다. 추가 점검이 필요해 보인다면 누구에게 전달하면 좋을까요? 점검을 맡은 사람은 어떤 정보를 더 필요로 할까요?

조치를 마친 뒤에도 궁금한 것이 남습니다. 실제로 상태가 나아졌을까, 얼마 동안 지켜보면 좋을까, 결과는 누가 확인해 줄 수 있을까 하는 것들입니다. 저는 이런 질문까지 서비스 안에서 이어지면 좋겠다고 생각합니다.

이 과정에서 저는 알림을 받는 사람, 판단하는 사람, 실행하는 사람, 결과를 확인하는 사람 사이에 업무가 이어지는지를 살펴봅니다. 한 사람이 여러 역할을 맡을 수도 있지만, 어느 부분이 비어 있는지는 알아보고 싶습니다.

결과를 확인하는 과정에서 반복되는 불편이나 안내의 부족함을 발견할 수도 있습니다. 이런 내용을 제품과 서비스의 개선 검토에 반영하면, 운영에서 배운 것이 다음 판단의 근거가 됩니다.

데이터·서비스 설계에서 제가 확인하려는 것

저는 수집할 데이터의 목록과 함께, 그 데이터가 통과할 판단과 업무의 경로를 설명할 수 있는지 확인하려고 합니다.

누가 그 정보를 필요로 하는지, 어떤 맥락에서 판단하는지, 판단 뒤에 누가 실행하는지, 그리고 결과를 누가 다시 확인하는지. 이 연결을 따라가며 필요한 데이터와 기록, 각자의 역할을 조금씩 구체화해 가려고 합니다.

고객·제품·현장의 맥락을 이해하고, 데이터가 판단과 실행으로 이어지며, 그 결과가 다시 다음 판단의 근거가 되도록 설계하는 것.

저는 그 과정을 IoT 데이터·서비스 설계라고 생각합니다.