우리는 이전 편에서
봉제 생산 현장에서 사람의 움직임을 감지하는 게 왜 중요한 지에 대해 살펴봤어.
이번 편에서는 실제로 측정된 데이터들이 어떻게 서버에 올라가고
한국 본사 웹페이지에서 보이는 지 그 여정을 설명할게.
공장 안에서 1차 처리: 로컬 서버의 똑똑한 역할
모노로그 수백 대에서 동시에 올라오는 데이터를
그대로 한국까지 전송하면 어떻게 됐을까?
- 데이터양이 너무 많고,
- 인터넷 비용도 만만치 않고,
- 무엇보다 실시간 대응이 어려웠어.
그래서 공장 내부엔 “로컬 서버”라는 중간 처리 장치가 있었어.
이 서버는 모노로그로부터 데이터를 받아 1차로 가공, 필터링, 요약했지.
예를 들면,
- “진동이 기준 범위 안에 있다면 굳이 다 보낼 필요 없어. 요약만 하자.”
- “에러나 예외적인 진동은 강조해서 보내자.”
엣지 서버는 마치 뉴스 편집자 같았어. 수많은 기사(데이터) 중 중요한 것만 골라서 요약해서 전송했지.
이 구조 덕분에 클라우드엔 꼭 필요한 핵심 데이터만 도착했고, 네트워크 비용도 줄고, 시스템 전체가 더 가볍게 유지됐어.
데이터의 해외여행 – 공장에서 클라우드로
이전 편에서 우리는 베트남 의류 공장의 데이터를 얻는 방법에 대해 설명했어.
엣지 서버에서 정리된 데이터는 이제 한국 본사의 클라우드 서버로 전송됐어.
여기서도 단순히 “보낸다”로 끝나지 않았지.
보안은 어떻게 했냐고?
공장과 본사 사이엔 인터넷이 깔려 있으니, 보안이 중요했어.
- HTTPS 같은 암호화된 통신이 기본이었고,
- MQTT 프로토콜을 써서 데이터가 가볍고 빠르게 갔고,
- 전송 도중 끊겨도 복구 가능한 메시지 큐 시스템도 적용했어.
여행 가방에 담은 데이터는 어떤 모습이었냐면?
보통 이런 형태의 ‘JSON’ 포맷이었어:
이런 데이터들이 수백 개씩 초당으로 전송됐고, 클라우드에선 이걸 실시간으로 받아서 저장했어.
클라우드에서의 본격 정리 작업
클라우드에 도착한 데이터는 단계별로 관리됐어.
- 실시간 데이터 → Redis 같은 인메모리 저장소 → 지금 현재 상황을 빠르게 보여주기 위해
- 일별/월별 요약 데이터 → PostgreSQL, MySQL 같은 DB → 시간 단위로 추세를 분석하거나 보고서 만들려고
- 장기 백업 → S3 같은 객체 스토리지→ 나중에 문제 생기면 되돌아보려고
또한 이상 징후가 포착되면
- 슬랙 알림,
- 이메일 경고,
- 웹 알림으로 즉시 알려줬어.
웹페이지에서 데이터가 ‘보이는’ 순간- 데이터 시각화
마지막 단계, 사용자는 한국 본사의 웹사이트에 접속했어.
여기선 React나 Vue 같은 프론트엔드 프레임워크가 API 서버와 통신해서 데이터를 받아왔지.
예를 들면 이런 식이었어:
이 요청은 백엔드에서 DB를 조회해서, JSON 데이터로 응답하고 브라우저는 이걸 받아 표, 차트, 경고 메시지 등으로 시각화했어.
웹에선 이렇게 표현됐어:
- 현재 해당 라인, 공정의 생산량
- 목표 생산량 대비 현재 진행 상태
- 순 작업 시간과 손질 시간
이걸 보고 본사 담당자는
- 이 라인의 병목 공정이 있고 개선해야겠네.
- 특정 공정에서 순 작업시간 대비 손질 시간이 늘어나므로 작업 방법의 개선이 필요하네.
- 특정 라인이 특정 제품군의 생산성이 좋으니, 앞으로 생산성이 좋은 스타일을 배정해야겠네.
같은 판단을 빠르게 할 수 있었던 거야.
마무리 – 이 모든 과정이 단 몇 초 안에
정리해보면…
- 미싱기의 진동 한 번이
- 모노로그를 지나
- 엣지 서버에서 가공되고
- 클라우드를 타고 본사에 도착해
- 웹페이지로 시각화되는 데까지,
짧게는 1~3초면 충분했어.
우리가 브라우저에서 클릭 한 번으로 확인하는 그 데이터 뒤에는
수백 개의 장비, 수십 개의 기술,
그리고 보이지 않는 협업이 실시간으로 작동하고 있었던 거야.
다음에 공장 데이터 대시보드를 볼 때, 그 화면 뒤에 이렇게 복잡하고 멋진 여정이 있다는 걸 기억해줘.
